Управление проектами критической цепочки ( CCPM ) - это метод планирования и управления проектами, который подчеркивает ресурсы (люди, оборудование, физическое пространство), необходимые для выполнения задач проекта . Он был разработан Элиягу М. Голдраттом . Он отличается от более традиционных методов, основанных на алгоритмах критического пути и PERT , которые подчеркивают порядок задач и жесткое планирование. Проектная сеть критической цепи стремится поддерживать ресурсы на одном уровне и требует, чтобы они были гибкими во время запуска.
Происхождение
Управление проектами критической цепочки основано на методах и алгоритмах, полученных из теории ограничений . Идея CCPM была представлена в 1997 году в книге Элияху М. Голдратта « Критическая цепь» . Принято считать, что применение CCPM позволило реализовать проекты на 10-50% быстрее и / или дешевле, чем традиционные методы (например, CPM, PERT, Gantt и т. Д.), Разработанные с 1910 по 1950-е годы. [1]
Согласно исследованиям традиционных методов управления проектами, проведенным Standish Group и другими по состоянию на 1998 год, только 44% проектов обычно завершаются вовремя. Проекты обычно завершаются на 222% от первоначально запланированной продолжительности , 189% от первоначальной сметной стоимости, 70% проектов не достигают запланированного объема (техническое содержание предоставлено), а 30% отменяются до завершения. [2] CCPM пытается улучшить производительность по сравнению с этой традиционной статистикой.
Подробности
При использовании традиционных методов управления проектами 30% потерянного времени и ресурсов обычно расходуются на бесполезные методы, такие как плохая многозадачность (в частности, переключение задач ), синдром студента , закон Паркинсона , задержки при отправке сообщений и отсутствие приоритетов. [3]
В плане проекта , то критическая цепь представляет собой последовательность как старшинства - и зависящих от ресурсов задачи, предотвращающий проект от завершается в более короткие сроки, учитывая ограниченные ресурсы. Если ресурсы всегда доступны в неограниченном количестве, критическая цепочка проекта идентична методу критического пути .
Критическая цепочка - это альтернатива анализу критического пути . Основные характеристики, которые отличают критическую цепь от критического пути:
- Использование (часто неявных) зависимостей ресурсов . Неявный означает, что они не включены в сеть проекта, но должны быть идентифицированы путем анализа требований к ресурсам.
- Отсутствие поиска оптимального решения - достаточно «достаточно хорошего» решения, потому что:
- Насколько известно, не существует аналитического метода для поиска абсолютного оптимума (т. Е. Имеющего общую кратчайшую критическую цепочку).
- Неопределенность, присущая оценкам , намного больше, чем разница между оптимальным и почти оптимальным («достаточно хорошими» решениями).
- Идентификация и вставка буферов :
- Буфер проекта
- Буферы для кормления
- Буферы ресурсов (компании обычно неохотно выделяют больше ресурсов)
- Мониторинг прогресса и работоспособности проекта путем отслеживания скорости использования буферов, а не выполнения отдельных задач по расписанию .
Планирование CCPM объединяет большое количество безопасного времени, добавляемого к задачам в рамках проекта, в буферы - чтобы защитить своевременность выполнения и избежать потери этого безопасного времени из-за плохой многозадачности , синдрома студента , закона Паркинсона и плохо синхронизированной интеграции.
Управление проектами критической цепочки использует управление буферами вместо управления освоенной стоимостью для оценки эффективности проекта. Некоторые руководители проектов считают, что метод управления прибавленной стоимостью вводит в заблуждение, потому что он не отличает прогресс по ограничению проекта (т. Е. По критической цепочке) от прогресса по не-ограничениям ( т. Е. По другим направлениям). Методология цепочки событий может определять размер буферов проекта, подпитки и ресурсов.
Планирование
План проекта или иерархическая структура работ (WBS) создается почти так же, как и критический путь. План обрабатывается в обратном направлении от даты завершения, при этом каждая задача начинается как можно позже.
Каждой задаче назначается продолжительность. Некоторые реализации программного обеспечения добавляют вторую продолжительность: одну - «наилучшее предположение», или продолжительность с вероятностью 50%, и вторую «безопасную» продолжительность, которая должна иметь более высокую вероятность завершения (возможно, 90% или 95%, в зависимости от степени риска. что организация может принять). Другие реализации программного обеспечения оценивают продолжительность каждой задачи и удаляют фиксированный процент, который нужно агрегировать в буферы.
Ресурсы назначаются каждой задаче, и план выравнивается по ресурсам с использованием агрессивной продолжительности. Самая длинная последовательность задач на уровне ресурсов, которая ведет от начала до конца проекта, затем определяется как критическая цепочка. Обоснование использования 50% оценок заключается в том, что половина задач будет завершена раньше, а половина - поздно, так что отклонения в ходе проекта должны быть нулевыми. [ необходима цитата ]
Признавая, что задачи, скорее всего, займут больше времени из-за закона Паркинсона , синдрома Стьюдента или по другим причинам, CCPM использует «буферы» для отслеживания графика проекта и финансовых показателей. «Дополнительная» продолжительность каждой задачи в критической цепочке - разница между «безопасной» продолжительностью и 50% продолжительностью - собирается в буфере в конце проекта. Таким же образом буферы собираются в конце каждой последовательности задач, которые входят в критическую цепочку. Дата в конце буфера проекта сообщается внешним заинтересованным сторонам в качестве даты поставки. Наконец, устанавливается базовый уровень, который позволяет осуществлять финансовый мониторинг проекта.
Альтернативная методология оценки продолжительности использует вероятностную количественную оценку продолжительности с использованием моделирования Монте-Карло . В 1999 г. исследователь [ кто? ] примененное моделирование для оценки воздействия рисков, связанных с каждым компонентом структурной декомпозиции работ по проекту, на продолжительность, стоимость и производительность проекта. Используя моделирование методом Монте-Карло, руководитель проекта может применять различные вероятности для различных факторов риска, влияющих на компонент проекта. Вероятность возникновения может варьироваться от 0% до 100% вероятности возникновения. Влияние риска вводится в имитационную модель вместе с вероятностью возникновения. Количество итераций моделирования методом Монте-Карло зависит от допустимого уровня ошибки и обеспечивает график плотности, иллюстрирующий общую вероятность воздействия риска на результат проекта.
Исполнение
Когда план завершен и проект готов к запуску, сеть проекта фиксирована, а размеры буферов «заблокированы» (т. Е. Их запланированная продолжительность не может быть изменена во время проекта), потому что они используются для отслеживания графика проекта. и финансовые показатели.
При отсутствии провалов в продолжительности отдельных задач ресурсы поощряются к тому, чтобы сосредоточиться на текущей задаче, чтобы завершить ее и передать следующему человеку или группе. Цель здесь - устранить плохую многозадачность. Это достигается за счет предоставления приоритетной информации всем ресурсам. В литературе проводится аналогия с эстафетой. Каждый элемент в проекте поощряется как можно быстрее двигаться: когда они выполняют свою «ногу» в проекте, они должны быть сосредоточены на выполнении поставленной задачи как можно быстрее, с минимизацией отвлекающих факторов и многозадачности. В некоторых тематических исследованиях сообщается, что настоящие дубинки подвешивают к столам людей, когда они работают над задачами критической цепочки, чтобы другие знали, что их нельзя прерывать. Цель здесь - преодолеть тенденцию откладывать работу или делать дополнительную работу, когда кажется, что есть время. В литературе по CCPM это противопоставляется «традиционному» управлению проектами, которое отслеживает даты начала и завершения задач. CCPM призывает людей двигаться как можно быстрее, независимо от дат.
Поскольку продолжительность задачи была запланирована с вероятностью 50%, ресурсы вынуждены выполнять задачи критической цепи как можно быстрее, преодолевая синдром студента и закон Паркинсона.
Мониторинг
По мнению сторонников, мониторинг в некотором смысле является самым большим преимуществом метода критической цепи. Поскольку продолжительность отдельных задач отличается от 50%, нет смысла заставлять каждую задачу выполняться «вовремя»; оценки никогда не могут быть идеальными. Вместо этого мы отслеживаем буферы, созданные на этапе планирования. Можно создать и опубликовать диаграмму лихорадки или аналогичный график, чтобы показать потребление буфера в зависимости от завершения проекта. Если скорость использования буфера низкая, проект выполняется. Если уровень потребления таков, что в конце проекта, вероятно, будет мало буфера или его не будет вообще, тогда необходимо разработать корректирующие действия или планы восстановления для возмещения убытков. Когда скорость потребления буфера превышает какое-то критическое значение (грубо говоря: скорость, при которой можно ожидать, что весь буфер будет израсходован до конца проекта, что приведет к позднему завершению), тогда необходимо реализовать эти альтернативные планы.
История
Критическая последовательность была первоначально определена в 1960-х годах. [ необходима цитата ]
Смотрите также
Рекомендации
- ^ «Управление проектами критической цепи улучшает производительность проекта» . www.pmi.org . Проверено 27 января 2017 .
- ^ "Стендиш Групп Отчет Хаос" (PDF) . www.projectsmart.co.uk . Проверено 20 июля 2017 .
- ^ Харви Мэйлор, Управление проектами
Цви Раз, Роберт Барнс и Дов Двир, Project Management Journal, декабрь 2003 г.
дальнейшее чтение
- Управление проектами в быстром темпе , ISBN 1-57444-195-7
- Управление проектами критической цепочки , ISBN 1-58053-074-5
- Проекты за меньшее время: краткий обзор критической цепочки , Марк Вёппель
- Критическая цепочка на практике: использование теории ограничений для управления проектами и портфелями , JPBernard & I.Icord, ISBN 978-2-35422-253-6
- Критический взгляд на управление проектами критической цепи , Цви Раз, Роберт Барнс и Дов Двир, Журнал управления проектами , декабрь 2003 г.
- критический обзор «Критического взгляда на критическую цепочку» , Scott Button, Research Paper EM 540, март 2011 г.
- «Бережливое производство, гибкость и управление ИТ на основе шести сигм» , Питер Гавами (2008)
- Теория и практика управления проектами критических цепей , Рой Страттон, 20-я ежегодная конференция POMS, май 2009 г.
Внешние ссылки
- Онлайн-руководство по теории ограничений - описание буферизации проекта и управления буфером критической цепи
- Теория ограничений: база данных исследований
- Критические цепочки проектов - Веб-сайт, посвященный методу