Границы CCPM

Границы CCPM

Управление проектами по методу Критической цепи (Critical Chain Project Management, CCPM) является наиболее успешным и широко известным приложением Теории ограничений (ТОС). Первой поразительной особенностью CCPM является управление неопределенностью, а второй – понимание, как влияют показатели производительности на поведение человека и на саму производительность.

Сначала я остановлюсь на управлении неопределенностью, потому что добавление временного буфера проекта в конце проекта – это весьма смелое заявление о том, что мы на самом деле НЕ знаем точную дату завершения проекта. Это более прозрачный буфер, чем буфер ББК, который выглядит как обычное время выполнения заказа, связанное с цепочкой операций. Эта концепция буфера проекта является значительным вкладом в управление «обычной и ожидаемой» неопределенностью.

Знаменитое высказывание Голдратта: «Скажи мне, как ты меня будешь оценивать, и я скажу тебе, как я буду себя вести», было придумано за десять лет до CCPM. Действительно, негативное влияние показателей производительности на поведение людей отчетливо проявляется в цехах, но еще более оно очевидно в проектной среде, где люди являются ключевыми ресурсами. Разрушительное использование многозадачности также связано с показателями производительности, которыми оценивают каждого менеджера проекта изолированно от всех менеджеров других открытых проектов и тем самым вынуждают каждого бороться за «свой» проект.

Хотя CCPM является прорывом и несет огромную ценность, всегда нужно спрашивать: Каковы границы данной методологии? Другими словами, когда использование CCPM выгодно, а когда необходимо внести определенные изменения?

Все сводится к проверке исходных посылок, лежащих в основе методологии, и определению, когда они недействительны.

Просто чтобы проиллюстрировать это, давайте представим программу по поиску лекарства от рака. Можно ли в начале такого исследования определить дату его завершения? Можно ли построить последовательность задач для всего проекта? Мы хотя бы примерно представляем, сколько времени это займет? Есть ли смысл в буфере проекта, если у нас даже нет даты, куда его можно вставить?

Вот мой список главных исходных посылок, лежащих в основе CCPM, которые иногда могут быть неверными в определенных ситуациях:

  1. У нас есть достаточно хорошая идея, как выполнить проект от начала до конца.
    • В частности, с самого начала проекта у нас есть хорошая идея, какие функции должны быть разработаны.
    • У нас нет условных точек в проекте (если…, то…, иначе…), которые могли бы кардинально изменить последующие операции или вернуть к более ранней задаче.
  2. Завершение проекта раньше или в установленный срок имеет первостепенное значение.
  3. Завершение проекта в срок не ставит под угрозу реализацию всех технических функций и бюджет.
  4. Контроль за ходом выполнения проекта и его сроками находится в наших руках.
  5. Мы планируем постоянно работать над критической цепью. Без этого определение критической цепи как самой длинной цепи, определяющей длительность проекта, бессмысленно.
Еще рекомендуем:  Управление проектами по методу Критической цепи

Что происходит, когда одна или несколько основных исходных посылок недействительны?

Давайте рассмотрим два примера. Предположим, клиент должен принять определенные этапы проекта, и для этого он должен потратить свое время. Тогда две посылки недействительны: четвертая и пятая. Четвертая недействительна, потому что у нас нет средств, чтобы заставить клиента придерживаться нашего графика. Пятая недействительна, так как весь проект находится в ожидании на время проверки клиента. Можно включить эту задачу клиента в план и выделить на нее до половины времени проекта. Но суть в том, что если клиент дает (не дает) сигнал о том, что можно двигаться дальше, как вы сможете соблюдать сроки?

Моя рекомендация для такого случая – разбить весь проект на подпроекты. Команда проекта контролирует ход выполнения до тех пор, пока клиент не получит выходные данные для подтверждения, что фактически является завершением проекта. Как только клиент «дает добро», начинается следующий проект. Даже если при приемке у клиента появляются новые требования, они входят уже в новый проект.

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

Общее замечание: я считаю CCPM наименее целостным методом в TOC. Он нацелен на решение проблемы, которая является довольно распространенной, но не обязательно ключевой проблемой организации. Меня беспокоит, что это решение для нежелательного явления (НЖЯ), без изучения общей картины. Вы можете улучшить управление проектами в организации, но организация не сможет достичь своей цели.

Хочу закончить историей в тему: недавно я встретил высокопоставленного руководителя огромного международного концерна. Когда я упомянул о хорошей реализации CCPM в израильском подразделении, он прокомментировал: «Да, они досрочно завершили НЕНУЖНЫЙ проект!».

Вот результат, когда TOC применялась только для планирования и выполнение проекта. Почему инструменты ТОС не были использованы, чтобы в начале убедиться, что это ПРАВИЛЬНЫЙ проект с правильным набором функций и спецификаций? Можно ли это сделать в отрыве от стратегии организации?

Источник: блог Эли Шрагенхайма

Эли Шрагенхайм
Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd

1 комментарий “Границы CCPM

  1. Виктор Вальчук

    В оправдание CCPM надо сказать, что ни один из методов управления проектами не ставит и не решает вопроса: нужно ли выполнять данный проект. Это не является задачей метода. Такие решения должны приниматься вне его. Когда мы выполняем внешний проект (для клиента), мы исходим из того, что клиент знает, что делает. А когда это наш внутренний проект, направленный на улучшение деятельности, в ТОС есть соответствующий инструмент — мыслительные процессы. Разработка новой продукции, выход на новые рынки — тут не обойтись без интуиции и экспериментов по ходу. Но тут и не выполняется первая исходная посылка CCPM, сформулированная Шрагенхаймом. А значит, это не сфера применения ТОС.

      Цитировать  Ответить

Давайте обсудим...

Ваш e-mail не будет опубликован. Обязательные поля помечены *