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

1.6. Авиационная промышленность Израиля

В авиапромышленности Израиля трудится около 15 000 человек. Основная их деятельность — техническое обслуживание самолетов, осуществляющих пассажирские перевозки. Один из видов техобслуживания, так называемый «тип D», занимает в среднем по отрасли 46 дней. Штраф за превышение срока очень высок — $60 000 в день, поскольку авиакомпании должны вовремя получить свои самолеты, чтобы не срывать запланированные рейсы. Ежегодно обслуживающая компания выплачивала до $25 млн штрафов. В письме управляющего к Голдратту [18] говорится: «Нам удалось снизить среднее время проведения осмотров с трех месяцев до двух недель и увеличить число заказов — теперь они расписаны не на два месяца, а на год вперед».

1.7. Американское судостроение

Военно-морское ведомство США внедрило ССРМ на нескольких судостроительных предприятиях. Один из самых ярких примеров успеха — проводившееся в 2001 году техобслуживание военного корабля «Гарри Трумэн» — одного из крупнейших в мире. Применение некоторых приемов ТОС и ССРМ даже на базе традиционного программного обеспечения позволило команде реализовать этот грандиозный проект раньше срока и сэкономить свыше $20 млн. Последующее внедрение нового подхода на верфи Перл-Харбор вызвало повышение показателя соблюдения сроков с 40 до 90 % и рост производительности более чем на 100 % по другим, менее масштабным проектам по обслуживанию атомных подводных лодок США. Сейчас ВМС США внедряют ССРМ в рамках еще более крупных проектов на четырех государственных верфях и планируют то же самое для нескольких частных, с ними сотрудничающих.

1.8. Итоги

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

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

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

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

• все больше примеров свидетельствуют о том, что настоящая проблема находится в самой системе управления проектом, тем более что данная система не способна обеспечить эффективное управление неопределенностью;

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

• имеющееся немалое количество примеров не опровергает предположения, что выработанный Голдраттом метод критической цепи обеспечивает соответствие всем трем необходимым условиям успешной реализации проекта, приводя к улучшениям на 50 % и более при относительно небольших вложениях.

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

1. PMI, A Guide to the Project Management Body of Knowledge, Upper Darby, PA: PMI, 2000.

2. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдратт Элияху М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

3. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1997, p. 144 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

4. GAO/T-RCED-97-92, “Department of Energy: Improving Management of Major System Acquisitions,” Testimony, March 6, 1997.

5. GAO-03-570T. Status of Contract and Project Management Reforms. Statement of Robin M. Nazzaro, Director Natural Resources and Environment. March 20, 2003.

6. GAO/T-NSIAD-97-262, “Space Station: Deteriorating Cost and Scheduler Performance under the Prime Contract,” Testimony, September 18, 1997.

7. Lewis, James P., The Project Manager’s Desk Reference, Chicago: Irwin, 1995, с. 245.

8. Bromilow, F.J., “Measurement of Scheduling of Construction Time and Cost Performance in the Building Industry,” The Chartered Builder, Vol. 10, 1974.

9. Chun, Daniel W. M., and Mohan M. Kummaraswamy, “A Comparative Study of Causes of Time Overruns in Hong Kong Construction Projects,” S)263-7863(96)0039-7, International Journal of Project Management, Vol. 15, No. 1, February 1997.

10. Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates Have Improved by 50 %,” по адресу в Интернете http://www.standishgroup.com/press/article.php?id=2 (информация для книги взята с сайта 29 апреля 2004 года).

11. Leopold, Aldo, Game Management, Madison: University of Wisconsin Press, 1933.

12. Goldratt, Eliyahu M., Critical Chain, Great Barrington, MA: North River Press, 1997.

13. Lambert, L. R. “Cost/Schedule Control Criteria (C/SCSC): An Integrated Project Management Approach Using Earned Value Techniques,” The AMA Handbook of Project Management, New York: AMACOM, 1993.

14. Kahneman, Daniel, Paul Dlovic, and Amos Tvershky, Judgment under Uncertainty: Heuristics and Biases, Cambridge: Cambridge University Press, 1982.

15. Goldratt, Elyiahu, “My Saga to Improve Production,” New Haven, CT: Avraham Y. Goldratt Institute, 1994.

16. Honeywell Defense Avionics Systems, Albuquerque, New Mexico, Horizons, Vol. 5, No. 2, February 20, 1998.

17. Rizzo, Anthony, “The TOC Solution of R&D and Multi-Projects Organizations,” Lucent Technologies, Whippany, New Jersey, January 5, 1998.

18. См. http://www.Goldratt.com (веб-страница Института Голдратта AGI).

Глава 2

ТОС, РМВОК, бережливое производство и шесть сигм

Метод критической цепи в управлении проектами, которому посвящена эта книга, базируется на синтезе классического подхода к управлению (РМВОК [1]) и теории ограничений (ТОС). В свою очередь этот синтез осуществляется при помощи еще двух теорий: «бережливое производство» и «шесть сигм». В настоящей главе мы рассмотрим все эти дисциплины по порядку и увидим, какое отношение в целом они имеют к управлению проектами по методу критической цепи.

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

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

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

Концепция шести сигм и ее предшественник — всеобщее управление качеством, или TQM (total quality management), нацелены на непрерывное совершенствование процессов путем реализации соответствующих проектов с высоким показателем рентабельности инвестиций (ROI). Подразумевается, что наилучший способ усовершенствовать систему — это улучшить в ней каждый процесс. TQM базируется на четырех составляющих (имеется в виду система глубинных знаний доктора Деминга), которые позволяют лучше понять причины, возникающие при реализации проектов. TQM располагает набором инструментов для проведения анализа и выявления истинных причин неудач.

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

2.1. Свод знаний по управлению проектами (РМВОК)

[4]

С появлением в 1950-х и 1960-х гг. методов критического пути и диаграммы PERT управление проектами сделало громадный шаг вперед. PERT возникла в 1958 г. в ходе совместной работы ВМС США и консалтинговой фирмы Booz, Allen, Hamilton над проектом подлодки «Полярис». С распространением компьютеров эти методы укрепили свои позиции и успешно применялись в управлении проектом «Аполлон» по высадке человека на Луне (определенно, то был один из звездных часов человечества), а также во многих других крупных проектах оборонных ведомств.

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

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

В каждой из этих областей существует набор процессов, которые в РМВОК распределены по пяти группам:

1. Инициация.

2. Планирование.

3. Контроль.

4. Исполнение.

5. Завершение.

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

К общей координации действий по управлению проектом относятся разработка и выполнение проектного плана, а также общее управление изменениями на протяжении всего проекта.

К управлению содержанием проекта (project scope) относятся: инициация проекта, планирование, определение и подтверждение (scope planning, definition, verification), а также контроль изменения содержания (change control). Содержание проекта можно считать определенным, если разработаны устав проекта (project charter), иерархическая структура работ (work breakdown structure, WBS), подробное описание результатов проекта, или содержание работы (statements of work, SOW), особые функциональные и эксплуатационные требования (functional and operational requirements, F&OR) по исполнению проекта, зафиксированы исходные установки, допущения (assumptions), на основании которых формулировалось содержание, а также установлен процесс контроля за изменением самого содержания.

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

Управление сроками (project time management) предусматривает определение задач, или операций (activity), необходимых для выполнения заявленного содержания, их последовательности, оценку длительности операций, разработку расписания (schedule), то есть графика выполнения проекта и отслеживание выполнения графика. Для подготовки графика — на входе — нужны иерархическая структура работ, WBS и описание содержания проекта. В процессе разработки графика определяются требования к ресурсам по каждой операции и другие потенциальные ограничения. В РМВОК отмечается, что при оценке длительности работ должна указываться степень неопределенности, и делается отсылка на раздел по управлению рисками проекта, где говорится, как работать с неопределенностью. Также обсуждается необходимость выравнивания ресурсов (resource leveling) в плане проекта. Разграничение вариабельности, вызванной общими или специальными причинами, не производится (см. 2.5.2).

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

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

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

Методика оценки степени зрелости проектного управления в организации, или ОРМ3 (Organizational Project Maturity Model) [2], была опубликована PMI в 2003 году. Ее цель — «описать стандарт управления проектами и зрелости управления проектами». На мой взгляд, она разработана в соответствии с положениями модели CMM Института инжиниринга программного обеспечения SEI (Software Engineering Institute’s Capability Maturity Model) [3]. До того, как приступить к созданию ОРМ3, команда PMI рассмотрела 27 различных моделей и назначила специальные группы по 3 человека в каждой, чтобы детальнее изучить 17 из них. ОРМ3 содержит исчерпывающие вопросники для оценки организаций на соответствие характеристикам, присущим высокоэффективным проекто-ориентированным компаниям.

ОРМ3 — это значительный шаг вперед по сравнению с РМВОК, поскольку она охватывает организационную систему целиком, а не только некоторые элементы, необходимые для управления отдельным проектом. Сфера использования пяти групп процессов, выделенных в РМВОК, расширена здесь до управления программами и портфелями проектов. В каждой группе выделяются основные и вспомогательные процессы. Выделенные в методике ОРМ3 процессы в явном виде не структурированы по ТОС или ССРМ. Пока еще слишком рано делать выводы о полезности ОРМ3. Личный опыт использования модели SEI CMMTM при организации офиса управления проектами (project management office) в ИТ-компании заставляет меня думать, что модели приносят практическую пользу, только если применяются по отношению к факторам, способным повлиять на действующее в данный момент ограничение системы. Нужно быть очень осторожным, чтобы не потеряться в обилии деталей, появление которых может быть обусловлено подобным подходом. Скорее всего, ОРМ3 следует использовать именно таким образом (то есть в совокупности с направляющими шагами ТОС).

В процессе создания ОРМ3 проявился интересный аспект, имеющий отношение даже не столько к самой модели ОРМ3, сколько к теме нашей книги — совершенствованию управлением проектами. В предисловии к изданию ОРМ3 сказано:

«До первого квартала 2000 года наша стратегия заключалась главным образом в классическом линейном принципе водопада: первоначальное исследование перешло в стадию разработки, разработка — в выполнение и тестирование и так далее. Однако мы никак не могли приступить к анализу результатов исследования, и PMI обратился к нашей команде с просьбой ускорить, насколько это возможно, выполнение проекта. Руководители проекта ОРМ3 модифицировали стратегию, перейдя со схемы “водопад” на модель, близкую к “быстрой разработке прототипа” (с. 55)».

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

2.2. Бережливое производство

В книге «Машина, которая изменила мир» (The Machine That Changed the World) [4] Д. Вумек, Д. Джонс и Д. Рус познакомили с понятием «бережливое производство». К принципам бережливого производства они отнесли:

• командную работу;

• процессы коммуникации;

• эффективное использование ресурсов и устранение потерь;

• непрерывное совершенствование.

Развивая эту тему, Вумек и Джонс фокусируются на проблеме потерь и указывают на необходимость:

• определить, что является ценностью для конечного пользователя;

• выявить поток создания ценности;

• сфокусироваться на движении материалов в процессе производства;

• внедрить «вытягивающую» систему производства;

• стремиться к совершенствованию.

Эти принципы очень хорошо соотносятся с положениями ТОС, если под «ценностью» мы будем понимать цель организации. Они также соответствуют концепции «шесть сигм», однако делают больший упор на системе, фокусируясь на потоке создания ценности и освещая идею «вытягивающего» производства (выпуск продукции производится только по требованию клиента) под иным углом, чем шесть сигм. ВМС США создали некий синтез двух концепций и назвали его «бережливые сигмы» (Lean Sigma).

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

У. Детмер приводит превосходное выражение, описывающее синергию при взаимодействии двух теорий [6]: «На уровне организации ТОС представляет собой своего рода систему наведения, позволяющую направить усилия организации по применению бережливого производства туда, где это будет полезней всего, и предотвратить использование его там, где это только навредит».

Детмер также указывает на преимущества совместного использования ТОС и бережливого производства, включая такие методы последнего, как:

• пока-ёкэ (метод предупреждения ошибок);

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

• непрерывное совершенствование;

• анализ характера и последствий отказов (FMEA);

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

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

• роли, ответственность и правила работы в команде;

• графическое представление рабочих инструкций;

• визуальный контроль;

• 5s (От японских слов seiri, seiton, seiso, seiketsu, shitsuke, что в переводе означает «сортировать, соблюдать порядок, содержать в чистоте, стандартизировать процедуры, совершенствовать». Первые три понятия относятся к общему поддержанию порядка на рабочем месте. Оставшиеся два — к самоорганизации работника, которая позволит ему придерживаться первых трех, а также к руководству, которое обязано следить за соблюдением перечисленных правил.)

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

2.3. Agile, или Облегченные методы управления проектами

Значительной доли внимания удостоились легкие, или гибкие (agile), методы, предлагаемые для решения проблем, характерных для проектов, связанных с информационными технологиями. В Википедии говорится [7]: «Методы Agile возникли в середине 1990-х годов отчасти в противовес чрезвычайно формализованным методам, таким как Rational Unified Process (рациональный унифицированный процесс, RUP), Prince[6], ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством». Причины, по которым в мире появились гибкие методы, описаны в главе 1: значительное превышение сроков и бюджета, неспособность добиться заявленных характеристик продукта в большинстве ИТ-проектов. Облегченные методы по ИТ-проектам включают:

1. быструю разработку приложений;

2. параллельную разработку приложений;

3. экстремальное программирование;

4. SCRUM[7].

Подробное рассмотрение этих методов не является нашей целью.

Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:

«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000… что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта… Существующая модель управления проектами по PMI/ISO 9000 устарела» (с. 60).

Несмотря на то, что далее Андерсон демонстрирует искусный подход к внедрению ССРМ в ИТ-проектах, по моим личным наблюдениям за ИТ-компаниями, столкнувшимися с трудностями при реализации проектов, многие из них не понимают традиционной методики, а если и применяют ее, то неправильно. Основные ошибки: неполное исходное определение содержания проекта (например, нет иерархической структуры работ) и использование неэффективного процесса управления изменениями или вообще полное отсутствие такового. Часть методов, которые называют альтернативой тяжеловесным технологиям РМВОК, на самом деле в этом своде знаний описаны. Наиболее яркий пример — подход «ускоренная спиральная разработка прототипов». И хотя гибкие методологии довольно эффективны в работе небольших команд над несложными системами программного обеспечения, я считаю, что в отношении масштабных проектов они играют скорее вспомогательную роль и не заменяют комплексных подходов, описанных в РМВОК и ОРМ3.

Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты, как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.

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