“Границы применимости CCPM” Перевод материалов блога Эли Шрагенхайма

Как я уже писал при публикации прошлого перевода, в пятницу 30 октября 2015 Эли Шрагенхайм опубликовал у себя пост, посвященный границам применимости метода Критической цепи.

Спасибо, компании Юнискан-Резерч, которая поддержала меня мощностью по переводу, что позволило подготовить пост к публикации в максимально короткие сроки.

Мне очень нравится в публикациях Эли тот факт, что он, как и положено, всегда задается вопросами границ применимости тех или иных методов Теории ограничений. Нет методов не правильных, есть не правильное, не своевременное или неуместное применение тех или иных инструментов.

Как обычно, ссылка на оригинал и картинка из поста автора.

Ваш Дмитрий Егоров

Управление проектами по методу Критической Цепи (Critical-Chain-Project-Management), CCPM, — наиболее успешное и широко известное решение TOC. Наиболее поразительной особенностью CCPM является работа с неопределенностью, а вторая удивительная черта — это понимание влияния показателей эффективности[i] на поведение людей и воздействие на саму эффективность.

project-ccpm1

Я поставил работу с неопределенностью на первое место, поскольку добавление наглядного буфера времени проекта в его конец — смелое заявление, что мы на самом деле не знаем точной даты окончания проекта. Это более очевидный буфер, чем буфер в методе ББК (Барабан-буфер-канат), который похож на обычное время выполнения проекта в совокупности с цепью операций. Концепция буфера проекта — значительный вклад в управление «обычной и ожидаемой неопределенностью».

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

Хотя CCPM является колоссальным прорывом в управлении, мы всегда обязаны спросить:

Где границы применимости данной методики?

 

Другими словами, когда использование CCPM полезно, а когда следует внести некоторые изменения?

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

 

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

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

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

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

Рассмотрим два примера:

Предположим, что клиент должен подтвердить определенные этапы в проекте и не торопится с этим. Два допущения неверны: четвертое и пятое. Четвертое недействительно, так как мы не можем заставить клиента придерживаться нашего графика. Пятое — так как весь проект находится в подвешенном состоянии до того, как клиент примет решение. Можно включить возложенную на клиента задачу в планирование и предположить примерно 50% времени[ii] на ее выполнение. Суть в следующем: если клиент откладывает сигнал о продолжении, каким образом участники проекта могут уложиться в срок?

В таком случае я советую разделить цельный проект на несколько подпроектов. Проектная команда контролирует процесс до тех пор, пока клиент не получает результаты и запрос на их утверждение; это завершает первый проект. Как только клиент подтверждает готовность двигаться дальше, даже вынеся новые требования, начинается второй проект.

Другой проблемный вид проекта – это проект с обязательным фиксированным сроком окончания и невозможностью отсрочки. В таком случае состав «готового проекта» может быть гораздо меньше первоначального плана, или же могут резко увеличиться затраты. Это означает, что третье допущение является недействительным. Буфер времени не защищает все действительно важные переменные. При планировании такого проекта следует сделать четкое разграничение между «обязательными»[iii] и «желательными»[iv] компонентами. Я вижу решение в установлении буфера желательных компонентов вдобавок к буферу проекта, защищающему обязательный срок завершения.[v]

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

В заключение анекдот: Мне повстречался руководитель высшего ранга огромной международной группы корпорации. Когда я упомянул отличную реализацию CCPM в Израиле, он прокомментировал: «Они раньше закончили НЕ ТОТ проект!»

Не должна ли ТОС не только участвовать в планировании и осуществлении проектов, но также проверять, что это ПРАВИЛЬНЫЕ проекты с правильными содержанием и требованиями?

Можем ли мы делать это, не участвуя в Стратегии организации?

 

[i] В оригинале «perforance» – прим. переводчика

[ii] Возможно речь идет о питающем буфере для этой задачи, равном 50% времени от защищаемой цепи, но это предположение не однозначно. – прим. переводчика

[iii] В тексте «must-have» – прим. переводчика

[iv] В тексте «nice-to-have» – неплохо-чтобы-было, в данном переводе я решил отказаться от этого варианта перевода. – прим. переводчика

[v] Подробнее об этом можно прочитать в другой статье Эли Шрагенхайма на эту тему, перевод которой опубликован у меня на сайте.


Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.