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

Разберём, в чём суть — и какие есть подходы к его решению.

Конфликт:

Метод CCPM: режем оценки задач пополам, остальное в буфер.
Сервисная реальность: клиент платит за всю оценку, буферы его не интересуют.

- > Если заложим буфер — цена будет высокой, клиент не купит.
- > Если буфер не закладывать — риски ложатся на команду и компанию.

💣 Следствия:

Клиент видит 100 часов и не покупает.
Компания продаёт 50 часов (по CCPM), но не закладывает буфер.
— Ок, дешево. Но кто покроет перерасход, если не уложимся?

Буфер заложен, но скрыт.
— Тогда он либо "прячется" в других работах, либо выдается как рисковый запас.

Как можно решать это на практике

1. Переход от "фиксированной цены" к "фиксированному результату" с гибким бюджетом
Это сложно, но стратегически правильно.

Продаёшь фичу или результат, а не часы.
В цену включаешь буфер, но не афишируешь его как “дополнительные часы” — ты продаёшь ценность и уверенность в сроках.
Эту модель нужно объяснять клиенту, и она лучше работает на доверии и зрелых отношениях.

💬 «Мы не просто даём оценку — мы закладываем защиту проекта, чтобы вы получили результат вовремя. Это не подстраховка на всякий случай — это механизм управления рисками».

2. Внутренние буферы за счёт прибыли. Наиболее правильный вариант по моему мнению.
Продаёте 50 часов, но понимаете, что реальный срок может быть 70.

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

Для этого в компании нужны программные или портфельные менеджеры. Либо delivery менеджеры, как стало модным называть это в последнее время в такиих компаниях.
Это суть их работы по планированию программ и портфелей.

Они не просто фиксируют оценки от РП-ов, они меняют их из картины перераспределения рисков между портфелями проектов.