Обязательно ли вовлекать подрядчиков в CCPM?

10 августа 2016, Елена Федурко

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

Вопрос, который регулярно поднимается компаниями, которые хотят использовать CCPM — управление проектами по методу Критической Цепи — при строительстве, в котором они являются заказчиками:

  • «Как проводить управление проектами по CCPM, если строительные работы делаются генподрядчиком, а он не знает о CCPM, ему ни к чему менять свой подход к работе, так у него нет недостатка в заказах и клиентах, он большой, а наш проект для него маленький, и он не будет менять то, как он работает, для НАШЕГО проекта?»

Отсюда вытекают еще два вопроса. Более обобщенные, так как они типичны для любой проектной среды, в которой есть аутсорсинг/субподряд.

  • Обязательно ли вовлекать подрядчика в CCPM?
  • Применим ли вообще подход CCPM (или имеет ли смысл его применять), если в проекте достаточно большое количество задач делается на аутсорсинге/субподряде?

Основная сложность состоит в самой сути плана проекта по CCPM. А именно в том, что то, в какую дату начнется каждая конкретная задача на этапе исполнения, не может и не должно совпадать с тем, в какую дату стоит начало задач в изначальном плане, который НЕ ПЕРЕПЛАНИРУЕТСЯ в ходе разворачивания проекта.

В CCPM вся длительность проекта делится на:

  • 2/3 длительности — сетевой график проекта, показывающий зависимость задач и Критическую Цепь
  • 1/3 длительности — буфер проекта, который прикрепляется к концу Критической Цепи И ДОЛЖЕН И БУДЕТ ПОСТЕПЕННО ИСПОЛЬЗОВАТЬСЯ по ходу исполнения проектами.

Когда конкретно, какая задача и сколько потребит из буфера — мы не знаем. Но знаем, что потребление из буфера будет точно. И ДОЛЖНО БЫТЬ, так как если потребления из буфера не будет, это означает, что мы оставили внутри каждой отдельной задачи слишком много подстраховки. Отсутствие потребления из буфера невозможно по умолчанию, так как на этапе планирования мы вводим в план длительность задач, равную всего 50% вероятности выполнения в указанную длительность. Статистически часть задач обязательно будет длиться дольше, чем указанная в плане длительность. Мы не знаем какие, и не знаем когда, и не знаем насколько дольше. Поэтому нам и нужен один общий буфер в конце проекта. И всем проектом мы управляем через этот буфер.

Назад к вопросу о плане работ (ген)подрядчика.

Если ваш (ген)подрядчик не использует CCPM и не заинтересован в том, чтобы делать для вас работу в формате CCPM, в котором вы внутри компании ведете управление вашим проектом, то самое эффективное: договориться с ним об общем графике зависимостей и о том, что вы будете их держать все время в осведомленности о том, через какое время новые задачи должны начаться  — за 2 недели, за неделю, за 3 дня. C (ген)подрядчиком нужно согласовать такой план работ на временной линии, в котором начало его задач будут в соотношении к графику CCPM по принципу каждые 2дня+1 день.

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

С (ген)подрядчиком решается:

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

Просьба к тем, кто РЕАЛЬНО использует CCPM в строительстве или в другой сфере в качестве заказчика, генподрядчика или субподрядчика, написать в комментариях к данному посту о том, каким образом вы решили или решаете этот вопрос.

И, поскольку мы хотим поделиться для общей пользы тем, что и КАК РАБОТАЕТ в рамках ТОС, просьба не писать без действительного знания и РЕАЛЬНОГО ОПЫТА.    

 

Опубликовано Еленой Федурко, 10 августа 2016

Читать/оставить комментарии

5 ответы
  1. Борис says:

    Здравствуйте, Елена. И привет Одеду) Задели за живое. В смысле, мы еще живы, не смотря на кризис отрасли. По существу. Мы — субподрядчик HVAC на промышленных (главным образом) и административных объектах. НЖЯ — типовые для проектной среды умноженные на особенности строительной отрасли — сырые проекты, низкокачественный менеджмент, неплатежи. Используем ССРМ для отдельного проекта (не для портфеля). Программное обеспечение — СС- Pulse. Проблемы, описанные выше, учитываем в плане проекта за счет ввода в задач типа «Строительная готовность по площадке Х», — это со стороны Заказчика / Генподрядчика. Если нанимаем своих субподрядчиков, то по ним планируем и работаем также как по своим собственным бригадам — обновляем прогноз по завершению задач на регулярной основе.

    Ответить
  2. Борис says:

    Продолжение.Дополнительно родившийся в практике инструмент — вводим в проект задачи типа «Хвост». На этапе планирования у этой задачи нулевая длительность, но если по определенному участку остаются незавершенные работы по причинам, связанным с Заказчиком или смежниками, мы отмечаем эти задачи как выполнненные, а прогнозируюмую длительность оставшегоя объма переносим в «Хвост». Это позволяет программе адекватней отражать проникновение в буфер. Используем в течении 2х лет — результаты не сказать, что потрясают, но уровень управления отклонениями вырос — потенциальные проблемы со сроками видны раньше. Раз в неделю проводим оперативку по отклонениям — оцениваем «лидеров» по проникновениям в буфер и необходимые управляющие воздействия.

    Ответить
    • Jelena Fedurko
      Jelena Fedurko says:

      Борис, спасибо! Рада слышать Вас. От Одеда большой привет. Интересно про «хвост». Можете чуточку пояснить? Куда Вы ставите в графике эти задачи, сколько таких задач в каждой цепи и как определяете сколько их надо?

      Ответить
  3. Борис says:

    Твердого правила нет. Хвост ставится последней задачей в блоке, как правило, объединненном функционально (например, все задачи по монтажу воздуховодов) или территориально (например, все задачи по работам на этаже). Последователем хвоста является первая задача следующего блока или интегральная задача (пусконаладка или сдача объекта) — как правило, это задача на КЦ. Хвост ставится тогда, когда при анализе проекта мы видим очень высокую верояность того, что часть работ будет подвисать до самого конца из-за низкой строительной готовности и плохой организации работ, с одной стороны и большого количества отдельных участков работ, с другой. Таким образом, хвост — это по сути способ более адекватного отражения действительности без перепланировки. Могу прислать какой-нибудь проект, чтобы наглядней было видно.

    Ответить
  4. Владимир says:

    Добрый день Борис! А не могли бы вы подсказать кто вам делал программное обеспечение? Был бы благодарен.

    Ответить

Ответить

Want to join the discussion?
Feel free to contribute!

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