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

Critical chain project management
«Критическая цепь» перенаправляется сюда. Для романа см. Критическая цепь (роман).

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

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

Управление проектами критической цепочки основано на методах и алгоритмах, полученных из Теория ограничений. Идея 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-х годах.[нужна цитата]

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

Рекомендации

  1. ^ «Управление проектами критической цепочки повышает производительность проекта». www.pmi.org. Получено 2017-01-27.
  2. ^ "Стэндиш Групп сообщает о хаосе" (PDF). www.projectsmart.co.uk. Получено 2017-07-20.
  3. ^ Харви Мэйлор, Управление проектами

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

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

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