Управление проектами критической цепи

Управление проектами критической цепочки ( CCPM ) - это метод планирования и управления проектами, который подчеркивает ресурсы (люди, оборудование, физическое пространство), необходимые для выполнения задач проекта . Он был разработан Элиягу М. Голдраттом . Он отличается от более традиционных методов, основанных на алгоритмах критического пути и PERT , которые подчеркивают порядок задач и жесткое планирование. Проектная сеть критической цепочки стремится поддерживать ресурсы на одном уровне и требует, чтобы они были гибкими во время запуска.

Происхождение

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

Управление проектами критической цепи основано на методах и алгоритмах, полученных из теории ограничений . Идея CCPM была представлена ​​в 1997 году в книге Элияху М. Голдратта « Критическая цепь» . Принято считать, что применение CCPM позволило реализовать проекты на 10-50% быстрее и / или дешевле, чем традиционные методы (например, CPM, PERT, Gantt и т. Д.), Разработанные с 1910 по 1950-е годы. ^[1]

Согласно исследованиям традиционных методов управления проектами, проведенным Standish Group и другими по состоянию на 1998 год, только 44% проектов обычно завершаются вовремя. Проекты обычно завершаются на 222% от первоначально запланированной продолжительности , 189% от первоначальной сметной стоимости, 70% проектов не достигают запланированного объема (техническое содержание предоставлено), а 30% отменяются до завершения. ^[2] CCPM пытается улучшить производительность по сравнению с этой традиционной статистикой.

Подробности

При использовании традиционных методов управления проектами 30% потерянного времени и ресурсов обычно расходуются на бесполезные методы, такие как плохая многозадачность (в частности, переключение задач ), синдром студента , закон Паркинсона , задержки при отправке сообщений и отсутствие приоритетов. ^[3]

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

Критическая цепочка - это альтернатива анализу критического пути . Основные характеристики, которые отличают критическую цепочку от критического пути:

1. Использование (часто неявных) зависимостей ресурсов . Неявный означает, что они не включены в сеть проекта, но должны быть идентифицированы путем анализа требований к ресурсам.
2. Отсутствие поиска оптимального решения - достаточно «достаточно хорошего» решения, потому что:
   1. Насколько известно, не существует аналитического метода поиска абсолютного оптимума (т. Е. Имеющего общую кратчайшую критическую цепочку).
   2. Неопределенность, присущая оценкам , намного больше, чем разница между оптимальным и почти оптимальным («достаточно хорошими» решениями).
3. Идентификация и вставка буферов :
   • Буфер проекта
   • Буферы для кормления
   • Буферы ресурсов (компании обычно неохотно выделяют больше ресурсов)
4. Мониторинг прогресса и работоспособности проекта путем отслеживания скорости использования буферов, а не выполнения отдельных задач по расписанию .

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

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

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

План проекта или иерархическая структура работ (WBS) создается почти так же, как и критический путь. План обрабатывается в обратном направлении от даты завершения, при этом каждая задача начинается как можно позже.

Каждой задаче назначается продолжительность. Некоторые реализации программного обеспечения добавляют вторую продолжительность: одну - «наилучшее предположение», или продолжительность с вероятностью 50%, и вторую «безопасную» продолжительность, которая должна иметь более высокую вероятность завершения (возможно, 90% или 95%, в зависимости от степени риска). что организация может принять). Другие реализации программного обеспечения выполняют оценку продолжительности каждой задачи и удаляют фиксированный процент, который нужно агрегировать в буферы.

Ресурсы назначаются каждой задаче, и план выравнивается по ресурсам с использованием агрессивной продолжительности. Самая длинная последовательность задач на уровне ресурсов, которая ведет от начала до конца проекта, затем определяется как критическая цепочка. Обоснование использования 50% оценок заключается в том, что половина задач будет завершена раньше, а половина - поздно, так что отклонения в ходе проекта должны быть нулевыми. ^{[ необходима цитата ]}

Признавая, что задачи, скорее всего, займут больше времени из-за закона Паркинсона , синдрома Стьюдента или по другим причинам, CCPM использует «буферы» для отслеживания графика проекта и финансовых показателей. «Дополнительная» продолжительность каждой задачи в критической цепочке - разница между «безопасной» продолжительностью и 50% продолжительностью - собирается в буфере в конце проекта. Таким же образом буферы собираются в конце каждой последовательности задач, которые входят в критическую цепочку. Дата в конце буфера проекта сообщается внешним заинтересованным сторонам в качестве даты поставки. Наконец, устанавливается базовый уровень, который позволяет осуществлять финансовый мониторинг проекта.

Альтернативная методология оценки продолжительности использует вероятностную количественную оценку продолжительности с использованием моделирования Монте-Карло . В 1999 г. исследователь ^{[ кто? ]}прикладное моделирование для оценки влияния рисков, связанных с каждым компонентом иерархической структуры работ по проекту, на продолжительность, стоимость и производительность проекта. Используя моделирование методом Монте-Карло, руководитель проекта может применять разные вероятности для различных факторов риска, влияющих на компонент проекта. Вероятность возникновения может варьироваться от 0% до 100% вероятности возникновения. Влияние риска вводится в имитационную модель вместе с вероятностью возникновения. Количество итераций моделирования методом Монте-Карло зависит от допустимого уровня ошибки и обеспечивает график плотности, иллюстрирующий общую вероятность воздействия риска на результат проекта.

Исполнение

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

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

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

Мониторинг

По мнению сторонников, мониторинг в некотором смысле является самым большим преимуществом метода критической цепи. Поскольку продолжительность отдельных задач отличается от 50%, нет смысла заставлять каждую задачу выполняться «вовремя»; оценки никогда не могут быть идеальными. Вместо этого мы отслеживаем буферы, созданные на этапе планирования. Можно создать и опубликовать диаграмму лихорадки или аналогичный график, чтобы показать потребление буфера в зависимости от завершения проекта. Если скорость использования буфера низкая, проект выполняется. Если уровень потребления таков, что в конце проекта, вероятно, будет мало буфера или его вообще не будет, тогда необходимо разработать корректирующие действия или планы восстановления для возмещения убытков. Когда скорость потребления буфера превышает какое-то критическое значение (примерно:скорость, при которой можно ожидать, что весь буфер будет израсходовандо окончания проекта, что приводит к позднему завершению), то эти альтернативные планы необходимо реализовать.

История

Критическая последовательность была первоначально определена в 1960-х годах. ^{[ необходима цитата ]}

Смотрите также

• Теория ограничений
• Методология цепочки событий

использованная литература

Цви Раз, Роберт Барнс и Дов Двир, Project Management Journal, декабрь 2003 г.

дальнейшее чтение

• Управление проектами в быстром переулке , ISBN 1-57444-195-7 
• Управление проектами критической цепи , ISBN 1-58053-074-5 
• Проекты за меньшее время: краткий обзор критической цепи , Марк Вёппель
• Критическая цепочка на практике: использование теории ограничений для управления проектами и портфелями , JPBernard & I.Icord, ISBN 978-2-35422-253-6 
• Критический взгляд на управление проектами критической цепи , Цви Раз, Роберт Барнс и Дов Двир, Журнал управления проектами , декабрь 2003 г.
• Теория и практика управления проектами критических цепей , Рой Страттон, 20-я ежегодная конференция POMS, май 2009 г.
• Критический обзор «Критического взгляда на критическую цепочку» , Скотт Баттон, исследовательский доклад EM 540, март 2011 г.

внешняя ссылка

• Онлайн-руководство по теории ограничений - описание буферизации проекта и управления буфером критической цепи
• Теория ограничений: база данных исследований
• Проекты Critical Chain - Веб-сайт, посвященный Critical Chain
• Викторина - викторина из 10 вопросов о Critical Chain