Управление проектами критической цепочки
Управление проектами критической цепочки ( CCPM ) — это метод планирования и управления проектами , в котором особое внимание уделяется ресурсам (людям, оборудованию, физическому пространству), необходимым для выполнения проектных задач . [1] Он был разработан Элияху М. Голдраттом . Он отличается от более традиционных методов, основанных на критическом пути и алгоритмах PERT , которые подчеркивают порядок задач и жесткое планирование. Сеть проектов критической цепочки стремится поддерживать баланс ресурсов и требует, чтобы они были гибкими во время запуска.
Происхождение
[ редактировать ]Управление проектами критической цепочки основано на методах и алгоритмах, заимствованных из Теории ограничений . Идея CCPM была представлена в 1997 году в книге Элияху М. Голдратта « Критическая цепь» . Считается, что применение CCPM позволяет реализовывать проекты на 10–50% быстрее и/или дешевле, чем традиционные методы (т. е. CPM, PERT, Gantt и т. д.), разработанные с 1910 по 1950-е годы. [2]
Согласно исследованиям традиционных методов управления проектами, проведенным Standish Group и другими компаниями по состоянию на 1998 год, только 44% проектов обычно завершаются вовремя. Проекты обычно завершаются в течение 222 % первоначально запланированной продолжительности , 189 % первоначальной бюджетной стоимости, 70 % проектов не достигают запланированного объема (доставленное техническое содержание), а 30 % отменяются до завершения. [3] CCPM пытается улучшить производительность по сравнению с этой традиционной статистикой.
Подробности
[ редактировать ]При использовании традиционных методов управления проектами 30% потерянного времени и ресурсов обычно тратятся на расточительные методы, такие как плохая многозадачность (в частности, переключение задач ), синдром студента , закон Паркинсона , задержки входящих сообщений и отсутствие расстановки приоритетов. [4]
В плане проекта критическая цепочка — это последовательность задач, зависящих как от приоритета , так и от ресурсов, которая не позволяет проект завершить в более короткие сроки при наличии ограниченных ресурсов. Если ресурсы всегда доступны в неограниченном количестве, то критическая цепочка проекта идентична его методу критического пути .
Критическая цепочка является альтернативой анализу критического пути . Основными особенностями, отличающими критическую цепочку от критического пути, являются:
- Использование (часто неявных) зависимостей ресурсов . Неявный означает, что они не включены в сеть проекта, но должны быть идентифицированы путем рассмотрения требований к ресурсам.
- Отсутствие поиска оптимального решения — достаточно «достаточно хорошего» решения, потому что:
- Насколько известно, не существует аналитического метода нахождения абсолютного оптимума (т. е. наличия самой короткой критической цепи в целом).
- неопределенность Присущая оценкам намного больше, чем разница между оптимальными и близкими к оптимальным («достаточно хорошими» решениями).
- Идентификация и установка буферов :
- Буфер проекта
- Питающие буферы
- Ресурсные буферы (компании обычно неохотно предоставляют больше ресурсов)
- Мониторинг хода выполнения и работоспособности проекта путем отслеживания скорости потребления буферов, а не выполнения отдельных задач по расписанию .
Планирование CCPM объединяет большое количество безопасного времени, добавленного к задачам в рамках проекта, в буферы, чтобы защитить выполнение задач в срок и избежать потери этого безопасного времени из-за плохой многозадачности , синдрома студента , закона Паркинсона и плохой синхронизации интеграции.
Управление проектами критической цепочки использует управление буферами вместо управления освоенным объемом для оценки эффективности проекта. Некоторые менеджеры проектов считают, что метод управления освоенной стоимостью вводит в заблуждение, поскольку он не отличает прогресс по ограничениям проекта (т. е. по критической цепочке) от прогресса по не-ограничениям ( т. е. по другим путям). Методология цепочки событий позволяет определить размер буферов проекта, питания и ресурсов.
Планирование
[ редактировать ]План проекта или иерархическая структура работ (WBS) создается практически так же, как и критический путь. План отрабатывается в обратном направлении от даты завершения, при этом каждая задача начинается как можно позже.
Каждой задаче назначается продолжительность. Некоторые реализации программного обеспечения добавляют вторую продолжительность: одну «наилучшую оценку» или продолжительность с вероятностью 50%, а вторую «безопасную» продолжительность, которая должна иметь более высокую вероятность завершения (возможно, 90% или 95%, в зависимости от степени риска). что организация может принять). Другие реализации программного обеспечения оценивают длительность каждой задачи и удаляют фиксированный процент для агрегирования в буферы.
Ресурсы назначаются каждой задаче, а план выравнивается с использованием агрессивной продолжительности. Самая длинная последовательность задач на уровне ресурсов, которая ведет от начала до конца проекта, затем определяется как критическая цепочка. Оправданием для использования оценок в 50 % является то, что половина задач завершится раньше, а половина — позже, так что отклонение в ходе проекта должно быть равно нулю. [5]
Признавая, что задачи, скорее всего, займут больше времени, чем меньше из-за закона Паркинсона , синдрома Стьюдента или других причин, CCPM использует «буферы» для мониторинга графика проекта и финансовых показателей. «Дополнительная» продолжительность каждой задачи в критической цепочке — разница между «безопасной» продолжительностью и продолжительностью 50 % — собирается в буфере в конце проекта. Таким же образом буферы собираются в конце каждой последовательности задач, поступающих в критическую цепочку. Дата в конце буфера проекта передается внешним заинтересованным сторонам в качестве даты поставки. Наконец, устанавливается базовый уровень, который позволяет осуществлять финансовый мониторинг проекта.
Альтернативная методология оценки продолжительности использует вероятностную количественную оценку продолжительности с использованием моделирования Монте-Карло . В 1999 году исследователь [ ВОЗ? ] прикладное моделирование для оценки влияния рисков, связанных с каждым компонентом иерархической структуры работ проекта, на продолжительность, стоимость и производительность проекта. Используя моделирование Монте-Карло, руководитель проекта может применять различные вероятности для различных факторов риска, влияющих на компонент проекта. Вероятность возникновения может варьироваться от 0% до 100% вероятности возникновения. Влияние риска вводится в имитационную модель вместе с вероятностью его возникновения. Количество итераций моделирования Монте-Карло зависит от уровня допуска ошибки и представляет собой график плотности, иллюстрирующий общую вероятность влияния риска на результат проекта.
Исполнение
[ редактировать ]Когда план завершен и проект готов к запуску, сеть проекта фиксируется, а размеры буферов «фиксируются» (т. е. их запланированная продолжительность не может быть изменена в ходе проекта), поскольку они используются для мониторинга расписания проекта. и финансовые показатели.
Без перерывов в продолжительности выполнения отдельных задач ресурсам рекомендуется сосредоточиться на текущей задаче, выполнить ее и передать следующему человеку или группе. Целью здесь является устранение плохой многозадачности. Это достигается путем предоставления приоритетной информации всем ресурсам. В литературе проводится аналогия с эстафетой. Каждому элементу проекта рекомендуется двигаться как можно быстрее: когда они выполняют свою «часть» проекта, они должны быть сосредоточены на выполнении назначенной задачи как можно быстрее, с минимизацией отвлекающих факторов и многозадачности. В некоторых тематических исследованиях, как сообщается, настоящие дубинки вешаются на столы людей, когда они работают над задачами критической цепочки, чтобы другие знали, что их нельзя прерывать. Цель здесь состоит в том, чтобы преодолеть тенденцию откладывать работу или выполнять дополнительную работу, когда кажется, что есть время. В литературе по CCPM это противопоставляется «традиционному» управлению проектами, при котором отслеживаются даты начала и завершения задач. CCPM призывает людей двигаться как можно быстрее, независимо от дат.
Поскольку продолжительность задачи запланирована с вероятностью 50%, ресурсы вынуждены выполнять задачи критической цепочки как можно быстрее, преодолевая синдром Стьюдента и закон Паркинсона.
Мониторинг
[ редактировать ]По мнению сторонников, мониторинг в некотором смысле является самым большим преимуществом метода критической цепочки. Поскольку продолжительность отдельных задач варьируется от оценки 50%, нет смысла пытаться заставить каждую задачу выполняться «вовремя»; оценки никогда не могут быть идеальными. Вместо этого мы отслеживаем буферы, созданные на этапе планирования. Можно создать и опубликовать диаграмму лихорадки или аналогичный график, чтобы показать потребление буфера в зависимости от завершения проекта. Если скорость потребления буфера низкая, проект достигает цели. Если темпы потребления таковы, что в конце проекта резерв, скорее всего, будет незначительным или вообще отсутствовать, то необходимо разработать корректирующие действия или планы восстановления для возмещения потерь. Когда скорость потребления буфера превышает некоторое критическое значение (примерно: скорость, при которой можно ожидать, что весь буфер будет израсходован до окончания проекта, что приводит к позднему завершению), тогда необходимо реализовать эти альтернативные планы.
История
[ редактировать ]Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( апрель 2010 г. ) |
Критическая последовательность была первоначально определена в 1960-х годах. [ нужна ссылка ]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Асана. «Основы управления проектами критической цепочки [2024] • Асана» . Асана . Проверено 18 июля 2024 г.
- ^ «Управление проектами критической цепочки повышает эффективность проекта» . www.pmi.org . Проверено 27 января 2017 г.
- ^ «Стэндиш-группа сообщает о хаосе» (PDF) . www.projectsmart.co.uk . Проверено 20 июля 2017 г.
- ^ Харви Мэйлор, Управление проектами
- ^ https://www.melbourne.pmi.org.au/wp-content/files/MWP1020_Critical_Chain.pdf
Цви Раз, Роберт Барнс и Дов Двир, Project Management Journal, декабрь 2003 г.
Дальнейшее чтение
[ редактировать ]- Управление проектами в ускоренном темпе , ISBN 1-57444-195-7
- Управление проектами критической цепочки , ISBN 1-58053-074-5
- Проекты за меньшее время: краткий обзор критической цепочки , Марк Веппель
- Критическая цепочка на практике: использование теории ограничений для управления проектами и портфелями , Дж. П. Бернард и И. Айкорд, ISBN 978-2-35422-253-6
- Критический взгляд на управление проектами критической цепи , Цви Раз, Роберт Барнс и Дов Двир, Project Management Journal , декабрь 2003 г.
- Теория и практика управления проектами критической цепи. Архивировано 17 августа 2018 г. в Wayback Machine , Рой Стрэттон, 20-я ежегодная конференция POMS, май 2009 г.
- Критический обзор книги «Критический взгляд на критическую цепочку» , Скотт Баттон, исследовательский документ EM 540, март 2011 г.
Внешние ссылки
[ редактировать ]- Онлайн-руководство по теории ограничений — описание буферизации проекта и управления буфером критической цепи
- Теория ограничений: исследовательская база данных
- Проекты критической цепи - Веб-сайт, посвященный критической цепочке
- Викторина — викторина из 10 вопросов по Critical Chain.