Вовремя и в рамках бюджета. Управление проектами по методу критической цепи

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

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

Определить проблему в общих чертах несложно. Менеджер проекта всегда должен выполнять требования заказчика вовремя и в рамках заложенного бюджета. Однако факты, излагавшиеся ранее, наглядно демонстрируют, что существующий подход не обеспечивает достижение данного результата. Соответственно, перед нами стоит задача — выработать теорию, которая была бы лучше имеющейся и приводила к появлению желаемого результата (ЖР).

Слушатели курса управления проектами в Институте Авраама Голдратта (Avraham Goldratt Institute — AGI) в ответ на вопрос о том, почему так сложно выполнить три необходимых для успеха проекта условия, перечисляют следующие факторы:

• непредсказуемые погодные условия;

• непредсказуемые трудности с поставщиками оборудования;

• превышение сроков в связи с необходимостью достижения соответствия требованиям законодательства;

• нереалистичный график;

• ненадежные (но предлагающие низкие цены) поставщики или подрядчики;

• сложности в подборе свободных исполнителей для задач проекта;

• непредсказуемые чрезвычайные ситуации и так далее.

Все перечисленное объединяет два момента: причина проблем находится вне зоны контроля менеджера проекта и является неким неожиданным событием.

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

1. Проектные работы можно строго определить. Анализ явлений действительности производится так, словно возможно дать единственную, однозначную и точную оценку параметрам работ. Получается, что проявления вариабельности являются следствием неправильной постановки и выполнения задач.

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

Один из путей к пониманию причин успехов и провалов проектов — изучение организационной системы и тех исходных установок, на которых она базируется. По словам Альдо Леопольда [11], который в своей профессиональной деятельности занимался вопросами, не связанными с проектами, мы, несомненно, могли бы выявить факторы, которые влияют на успешность реализации проектов. Факторы — это то, что более-менее прямо сказывается на успехе, то есть на степени соответствия трем необходимым условиям успеха проекта. Итак, факторы успеха — это:

1. правильный выбор задачи;

2. правильный подход к решению задачи;

3. разработка соответствующего проектного задания;

4. использование эффективной системы контроля выполнения проекта;

5. эффективная реализация проекта;

6. использование эффективного метода управления неопределенностью.

Эффективная система контроля выполнения проекта определяет:

• количество задействованных людских ресурсов;

• квалификацию людей, занятых на проекте;

• принципы работы;

• сам процесс управления проектом;

• используемые методы и инструменты;

• управление изменениями при реализации проекта.

Данный список не является полным, однако в него попали многие пункты, освещенные в различных исследованиях причин проектных неудач.

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

1. управление;

2. система оценок;

3. поощрения;

4. политики;

5. социальные нормы;

6. вариабельность в процессах, обеспечивающих результаты проекта.

Воздействиями, внешними по отношению к проектной команде, будут в том числе:

1. конкуренты;

2. поставщики;

3. заказчик;

4. законодательные органы;

5. пространство, на котором реализуется проект;

6. другие заинтересованные в реализации проекта стороны (например, общество).

Эти воздействия второго ряда могут сказываться на одном или нескольких факторах, которые, в свою очередь, непосредственно влияют на степень успешности проекта. Табл. 1.3 демонстрирует отношения между факторами и воздействиями, а также авторскую оценку степени влияния вторых на первые.

Обратите внимание, что факторы обоих типов не являются независимыми. Таким образом, существуют взаимосвязи между всеми переменными. Система реализации проекта — вещь по-настоящему сложная. Если добавить к этому определенное количество факторов, которые влияют на эту систему, становится понятно, почему называется такое большое количество самых различных причин неудач реализации проектов.

Системная теория, о которой речь пойдет в главе 2, показывает, что в вопросе совершенствования системы более значимую роль могут играть не столько сами факторы, сколько отношения между ними и те явления, действию которых они подвержены. Дело в том, что упомянутые нами воздействия могут влиять сразу на несколько факторов, а также в том, что иногда более реально работать с этими воздействиями, менять что-то в них, а не в самих факторах. Особенно это относится к таким управляемым воздействиям, как системы оценок и поощрений, политики компании.

Приступая к разработке метода критической цепи, Голдратт назвал причиной неудачных проектов саму систему. Он сформулировал вопрос так: «Что в существующей системе обрекает на неудачу такое большое количество проектов?» Опираясь на предшествующий опыт работы с производственными системами, он выдвигает гипотезу, согласно которой существующая система неэффективна для управления в условиях неопределенности.

За последние сорок лет была предложена масса вариантов улучшения методов управления проектами. Специалисты пытались добиться более успешного выполнения пожеланий заказчика в срок и в рамках бюджета. Как правило, упор делался на подробнейшем рассмотрении вопросов планирования, измерения и контроля. Усовершенствованные компьютерные программы для управления проектами приводят к выделению все большего количества операций. Программа помогает автоматически создать график, выделить критический путь, назначить ресурсы и измерить «процент выполнения» на любом уровне детализации.

Свою работу по критическим цепям [12] Голдратт начинает с рассказа о компании, которая хотела сократить время реализации проектов по разработке новой продукции. Консультантами была проведена огромная работа по анализу системы управления проектами, результатом которой стала масса рекомендаций по внесению изменений в существующие подходы. Но на вопрос, сколько же времени сэкономит компания, последовав всем этим рекомендациям, был получен ответ: «Может, процентов пять. А может, и меньше».

Использование концепции освоенного объема (earned value) и производной от нее системы контроля затрат и управления графиком (CSCS) приводит к увеличению детализации при разработке плана проекта и системы измерений. Процедуры, необходимые для использования компанией данной системы, зачастую достигают в объеме нескольких сотен страниц. Количество названий задач в графике проекта доходит до десятков тысяч. И иногда появляется требование минимизировать длительность выполнения задач, например до срока в «не более чем две недели».

Автору довелось работать с одним правительственным учреждением, где на протяжении двадцати лет использовался подход, требующий очень детального составления планов. И каждый раз при возникновении проблемы находили виноватого, выискивали причину и создавали все новые процедуры. На подготовку проекта уходило минимум лет семь, и это без учета времени на саму реализацию проекта! То есть только на составление плана закладывалось семь лет. Проводились технические исследования, составлялись отчеты о концепциях продукта — результата проекта, устраивались независимые оценки затрат, внедрялись системы CSCS. Но по мере реализации затраты росли, график сдвигался, и все чаще и чаще не выполнялись техзадания. Однажды проект был остановлен, когда не него уже ушло больше миллиарда долларов. А некоторые проекты идут с запозданием на десятки лет.

Как показало одно из исследований, при строительстве самого обычного офисного здания затраты на один квадратный фут в четыре раза превысили стоимость работ, производимых местными неправительственными подрядчиками. Кризисы при реализации проектов случались вновь и вновь. Несколько раз менялся базовый план, по три раза и более пересматривались сметы и графики. Крупные проекты останавливались, не дойдя до завершения, поскольку необходимость в них отпадала или поскольку, по новым оценкам, затраты превысили бы потенциальную выгоду от реализации и в продолжении работ просто не было смысла. Вот с этой проблемой и пытались бороться в первую очередь. Неужели мир вокруг такой уж изменчивый? Или же наши решения только усугубляют, а не улучшают ситуацию?

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

Такой подход часто ведет к появлению планов из десятков тысяч операций. Недавно мы работали с клиентом, который весьма гордился тем, что у них план проекта состоит из 30 000 операций.

Позже мы поговорим о том, какие факторы помогут вам определить степень детализации при создании плана. Иногда в случае с крупными проектами речь действительно может идти о тысячах операций. Забегая вперед, скажу: как правило, план должен быть более скромным по размерам — операций на 100. Простейшие подсчеты показывают, что одна операция в среднем составляет при этом 1 % от всего проекта (в долл., или в человеко-днях, или даже в днях). Большинство менеджеров проектов были бы счастливы, если бы реализация их проекта расходилась с планом всего на 1 %. Однако в основе проблем лежит нечто, вызывающее отклонения более чем на 1 %. Поэтому, на мой взгляд, увеличение детализации плана и количества составляющих его операций (чтобы их было более 100) никак не поможет добиться успеха. Дело должно быть в чем-то другом.

Иногда в поддержку детализации слышатся следующие аргументы: проблема, хотя она и значительно больше 1 %, связана с тем, что при планировании мы что-то пропустили. Но недостающие 20 % не могут скрываться внутри имеющегося 1 %. Поиски крупных пропущенных составляющих среди деталей задачи, являющейся 1 % от проекта, напоминают анекдот о подвыпившем прохожем, который обронил ключи на углу улицы, но ищет их под фонарем, потому что там светлее, а на углу темно и ничего не видно. Если боитесь упустить что-то важное, лучше смотрите, чего не хватает между выделенными 100 операциями, а не пытайтесь разбить эти уже выявленные задачи на все более мелкие элементы.

В некоторых трудах о причинах возникновения и решениях проблем при реализации проектов приводятся примеры, призванные показать, что тот или иной предлагаемый способ уже помог улучшить показатели на ряде проектов. И хотя факты эти интересны, они никак не свидетельствуют о том, что автору идеи на самом деле удалось решить проблему, которая приводила к неудачам при выполнении проектов. И вот почему:

1. согласно теории познания, один или несколько примеров еще не доказывают состоятельности всей теории (см. также далее в главе 2);

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

3. работает житейский «закон зебры»: за чрезвычайно черной полосой, скорее всего, последует белая;

4. возможно, наблюдается Хоторнский эффект: психологическое явление, при котором лица, приглашенные участвовать в испытаниях нового метода, положительно высказываются о результатах любых изменений, даже если они не отличаются от тех, что наблюдались до проведения эксперимента.

Иными словами, предложенные теории не были критически осмыслены и экспериментально проверены авторами.

Всем известно, что операциям проекта свойственна изменчивость, или вариабельность, причем зачастую степень вариабельности характеризуется неопределенностью граничных условий. По определению проект — это то, чего раньше никто не делал, некая уникальная задача. В любом случае никто никогда не выполнял все те же задачи и тем же образом, как это требуется в рамках данного конкретного проекта. Чтобы успешно выполнить проект, необходимо принимать во внимание явления вариабельности и неопределенности. Способность человека точно оценить ситуацию зависит от нескольких факторов. Существует масса примеров, показывающих, что люди склонны переоценивать точность собственных прогнозов [14]. Как правило, длительность большинства проектных операций нельзя назвать с точностью выше, чем ±20 %.

На тренингах мы просим слушателей прикинуть длительность одной очень простой операции. Практически все соглашаются, что операция эта намного проще, чем большинство выполняемых по их проектам. Также все присутствующие на тренинге сходятся во мнении, что должны суметь оценить длительность данной операции не хуже, а может, и лучше, чем оценивают длительности реальных операций участники их проектов. Разброс оценок составляет до нескольких сотен процентов от средней величины, а стандартное отклонение — 30 %. На рис. 1.4 представлены суммарные результаты нескольких подобных экспериментов.

На рис. 1.5 степень точности оценки параметров отдельной операции дана как функция от количества усилий, затраченных на выработку этой оценки. Точность оценивается в процентах от средней величины оценочного значения, где абсолютно точная оценка будет иметь степень неопределенности равную нулю. Если для оценки не было приложено никаких усилий, то неопределенность составит как минимум 100 %, а может быть, и на порядки (на сотни процентов) выше. Как показывает кривая, обычно чем больше сил потрачено на выработку оценки, тем большей становится ее точность (и меньше неопределенность). Возможности улучшения ограничены нижним пределом, определяемым вариабельностью, присущей самому процессу, в рамках которого необходимо будет выполнять поставленную на проекте задачу. Это вариабельность, вызываемая так называемыми общими причинами, мы поговорим о ней далее в главе 2. Сколько бы сил вы ни прикладывали, вам никогда не сделать оценку точнее, чем позволяет характерная для данного процесса вариабельность. Снизить степень ее проявлений можно, лишь изменив что-то в соответствующем процессе.

Рассмотрим две части, на которые график на рис. 1.5 делится вертикальной пунктирной линией. Посмотрим на правую часть. Увеличение затрат на оценку не вызывает практически никакого увеличения ее точности. И чем правее находится отрезок шкалы, тем меньшая наблюдается зависимость между снижением затрат и ростом неопределенности. Слева же картина обратная — видна четкая связь между степенью неопределенности и количеством усилий, затраченных на оценку. Даже небольшое сокращение затрат повлечет за собой значительный рост неопределенности. А небольшое увеличение их вызовет радикальное улучшение качества оценки.

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

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

Добавление задач в план проекта увеличивает количество потенциальных связей между ними на порядки, превышающие число этих новых записей. Так, если вы прибавили всего одну строку в проект, в котором их уже 100, вы потенциально внесли и 200 новых связей между задачами, поскольку каждая операция, уже имеющаяся в плане, будет потенциально предшествовать новой или следовать за ней. А дополнительные взаимосвязи, возникающие при появлении новых задач, значительно увеличивают риск ошибок в сетевой диаграмме.

Из обсуждавшихся до сих пор возможных причин неудачных проектов вы могли сделать вывод, что это неопределенность вызывает проблемы при реализации. Если бы было именно так, то можно было бы предположить, что любой проект, существующий в ситуации неопределенности, обречен на провал. Основываясь же на определении проекта и нашем с вами знании жизни, можно утверждать, что неопределенность свойственна всем проектам. Следовательно, все проекты неминуемо должна постигнуть неудача. Во многих случаях это утверждение справедливо, но не во всех. Более того, есть примеры успешной реализации проектов в условиях максимальной неопределенности. В своей работе под названием «Критическая цепь» (Critical Chain) Голдратт описывает проект по созданию аэроплана, опровергающий высказанный нами ранее вывод. Разработчики сделали новую модель с непревзойденными характеристиками за 8 месяцев — вместо 10 лет, которые обычно уходят на подобные проекты. Есть и другие случаи. Соединенным Штатам удалось достичь поставленной президентом Кеннеди цели по отправке человека на Луну до конца десятилетия. Данный проект был самым неопределенным из всех, что выпадали на долю человечества. Подобным же проектом было создание атомной бомбы, завершившееся в рекордно короткие сроки.

Немалые силы брошены на то, чтобы снизить степень неопределенности при оценке параметров проекта и вариабельности при выполнении задач по проекту. Существуют прекрасные инструменты для оценки длительности проектов и составляющих задач. Они, без сомнений, помогают повысить точность оценки и, что еще важнее, собрать данные для оценки вариабельности проектных задач. Наблюдаются улучшения в сфере выполнения проектов — путем применения таких методологий, как шесть сигм. К сожалению, среди примеров неудач встречаются данные и о таких компаниях, в которых применяются подобные технологии снижения вариабельности. Говоря в общем и целом, к значительным улучшениям они не привели.

Особенность научного метода заключается в том, что ни один ученый никогда не сумеет доказать, будет ли какая-либо научная теория или закон продолжать действовать в будущем, но вот опровергнуть теорию он может, проведя всего один соответствующий эксперимент. Ряд случаев свидетельствует о том, что неопределенность сама по себе не может быть причиной неудач при реализации проектов.

Если фактор неопределенности сам по себе не объясняет, почему срываются проекты, можно ли как-нибудь подогнать существующую теорию под имеющиеся примеры? Мы знаем, что иногда при реализации проектов используются разные средства управления неопределенностью. Например, на проект «Аполлон» были приглашены три разных компании, которые предложили три разных решения по очень сложным разработкам. Выбран был один основной поставщик, а два других остались в качестве запасных — на случай, если решение первого не сработает. Была запланирована масса тестов и повторных проверок (и в ходе их проведения случился ряд весьма зрелищных срывов). Да, это затратный метод управления неопределенностью, но он работает. Руководствуясь теми же рассуждениями, Голдратт предположил, что причиной большинства неудач на проектах является отсутствие эффективного управления неопределенностью. В главе 3 мы рассмотрим эту гипотезу более тщательно. Если он прав, то решением может стать создание такой проектной системы, которая способна справиться с неопределенностью.

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

В очерке «Сага об улучшении производства» (My Saga to Improve Production) [15] Голдратт пишет:

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

Похожий феномен наблюдается и при многочисленных попытках улучшить качество управления проектами, и выясняется, что бороться с ним нужно будет практически всякий раз, когда компания решает внедрить ССРМ. Многие сразу же сосредотачиваются на софте как на панацее. Однако софт сам по себе никогда не является решением, и если сфокусироваться на нем, то больших улучшений не достичь. В других случаях решения по улучшению существующей системы трактуются как требования все большей детализации и создания все новой документации. При этом часто запускается новая база данных или программа для управления проектами. Все это лишь еще больше отвлекает людей от реализации проекта. И мало что меняется в лучшую сторону. Конечно, если изо всех сил внедрять дефектную систему, больших улучшений не произойдет. В главе 10 дается эффективный план по внедрению системы ССРМ.

1.3. Добиваемся успеха при помощи ССРМ

Мы сформулировали проблему и показали, что существующие теории нуждаются в совершенствовании. Следующим шагом должна стать разработка нового подхода к управлению проектом — ССРМ. Ожидается, что эта новая теория также будет критически осмыслена и при применении обеспечит стабильно более высокий уровень качества реализации проектов. Хотелось бы видеть улучшение не на 5, а на 50 %. Опираясь на данную теорию, мы также должны суметь объяснять причины уже имевших место успехов и неудач и делать оправдывающиеся прогнозы по готовящимся проектам. Опыт применения данного подхода демонстрирует гораздо больше преимуществ, чем обычно ожидается при внедрении новых методов. И все они тоже объясняются новой теорией. Вот перечень этих преимуществ (по сравнению с методом критического пути).

Увеличение количества успешно завершенных проектов:

• проекты всегда завершаются вовремя;

• проекты решают все поставленные задачи;

• проекты завершаются в рамках бюджета;

• проекты приводят к усилению положения компании на рынке и росту бизнеса.

Сокращение времени реализации проектов:

• работы завершаются вдвое (а иногда и более) быстрее, чем ранее при реализации подобных проектов;

• объем плана проекта сокращается как минимум на 25 %;

• значительно уменьшается длительность сложных проектов;

• снижается количество изменений на проектах;

• коммерческие проекты раньше начинают приносить прибыль;

• инвестиционные проекты окупаются быстрее.

Повышение степени удовлетворенности проектной команды:

• уменьшается путаница от возникновения множества пересекающихся задач;

• появляется возможность заниматься одновременно лишь одной задачей;

• снижается количество изменений;

• снижается количество переделок;

• снижается давление на проектную команду со стороны менеджеров отдельных проектов;

• снижается количество ситуаций типа «если не сделаешь, нам конец» (то есть задач, жестко привязанных к конкретным датам);

• исполнители пользуются информацией о буфере, чтобы определить приоритетность своих задач;

• снижается количество случаев внезапного появления новых приоритетных задач;

• упрощается система измерений;

• статус выполнения плана определяется легко и быстро;

• имеется информация о фактическом статусе проекта, то есть нет необходимости дожидаться появления финансовых отчетов;

• можно мгновенно получить статусный отчет по буферу, по цепи и по задаче;

• отчет по буферу определяет дальнейшие решения;

• отчетность по буферу вынуждает при принятии решений фокусироваться на приоритетах руководства (они видны по датам начал работ в графике).

Упрощение управления проектом:

• менеджеру проекта предельно ясно, на чем необходимо сосредоточить усилия (критическая цепь, сокращение случаев раннего старта);

• упрощение планов проектов уменьшает количество бумажной работы;

• упрощается процесс отчетности по статусу проекта;

• дальнейшее планирование или действия зависят от результатов измерений;

• приоритетность ресурсов зависит от результатов измерений.

Увеличение производительности проекта при неизменности ресурсов:

• снижается количество споров за ресурсы;

• больше проектов завершается за меньшее время при тех же ресурсах;

• сокращается необходимость привлекать новые незаменимые ресурсы;

• уменьшается количество задержек из-за проблем с ресурсами;

• улучшается картина движения денежных средств по проекту;

• увеличивается показатель рентабельности инвестиций ROI.

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

1.4. Honeywell Defense Avionics Systems [16]

«Команде, работающей на Королевские ВВС Нидерландов, поступило задание, на выполнение которого обычно закладывалось 13 месяцев, однако результат был получен уже спустя полгода… в экспериментальном режиме используется новый метод составления графиков программ с использованием концепции критической цепи. С этой концепцией также знаком и поддерживает ее Boeing».

1.5. Lucent Technologies [17]

Lucent Technologies использует ССРМ в качестве основной технологии управления своими проектами. (Автор данной книги проводил для компании соответствующий тренинг и оказывал помощь при внедрении).

«В 1996 году специалисты одной родственной компании заявили Lucent Technologies Advances Technology Systems (теперь в составе General Dynamics), что реализовать планировавшийся тогда проект длительностью один год — совершенно нереально… тогда тот проект выбрали в качестве пилотного, чтобы испытать методы управления проектами по ТОС. В июне 1997 года проект был завершен раньше срока».