Jump to content

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

Управление проектами критической цепочки ( 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]

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

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

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

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

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

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

[ редактировать ]

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

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

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

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

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

Исполнение

[ редактировать ]

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

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

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

Мониторинг

[ редактировать ]

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

Критическая последовательность была первоначально определена в 1960-х годах. [ нужна ссылка ]

См. также

[ редактировать ]
  1. ^ Асана. «Основы управления проектами критической цепочки [2024] • Асана» . Асана . Проверено 18 июля 2024 г.
  2. ^ «Управление проектами критической цепочки повышает эффективность проекта» . www.pmi.org . Проверено 27 января 2017 г.
  3. ^ «Стэндиш-группа сообщает о хаосе» (PDF) . www.projectsmart.co.uk . Проверено 20 июля 2017 г.
  4. ^ Харви Мэйлор, Управление проектами
  5. ^ https://www.melbourne.pmi.org.au/wp-content/files/MWP1020_Critical_Chain.pdf

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

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

[ редактировать ]
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b716d5a2e1dfddd4d8956c93aa759285__1721266920
URL1:https://arc.ask3.ru/arc/aa/b7/85/b716d5a2e1dfddd4d8956c93aa759285.html
Заголовок, (Title) документа по адресу, URL1:
Critical chain project management - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)