Но согласен, фраза некорректная

Подача - вопрос не первый, главное, чтобы потом не прилетело в спину)

Буфера спасут мир

Видишь, мы обычно оцениваем проекты с учетом рисков, соответственно, можем назвать условно "минимальный  - ожидаемый - максимальный" срок исполнения. По этой фразе показалось, что речь идет о минимально возможном исполнении самой длительной цепочки операций проекта. Т.е. в духе "ну, мы точно это закончим к 10му декабря, если все будет за...ись". Однако, в бизнес-реальности подобные оценки не имеют смысла.

А вот что именно имели в виду разработчики 21500, хотелось бы узнать...

Ещё не забывай про критическую цепь, при расчёте сроков.
Критический путь это круто, но это не всё

Так... можно поподробнее, что тут имеется в виду?)

Ну...кроме критического пути есть ещё критическая цепь - это к вопросу правильного планирования ресурсов на некритичных маршрутах, особенно если есть конкуренция за ресурсы и особенно ресурсы из критичного пути

Пример: ты отдал ресурс (программиста) на задачу из критичного пути, поэтому он же не смогу выполнить задачу по некритичному пути и в итоге в точке слияния некритичный путь опаздал и профакапился срок по всему проекту

Хотя факап, вроде бы, на некритичном пути нестрашен....

Если правильно понял, то CCPM фактически расширяет поход CPM путем использования оценки рисков для каждой активности проекта и учета ресурсных буферов на кажду активность / ресурс. Вроде бы, это напрямую не требуется стандартом (да и понятно - требуется не всегда), поэтому в CPM риски не оцениватся напрямую, верно?

Ам...прости, тут куча странных аббревиатур, которых я не знаю. Поэтому не могу прокомментировать

Но если CCPM это критическая цепь, а CPM критический путь, то фраза вполне логичная

Определение достаточно точное. Минимально возможная продолжительность проекта определяется продолжительностью максимально длинной цепочки работ. Это два способа донести одну и ту же мысль. Нет противоречия ;)

Да, и насколько я помню, критический путь не оценивает риски.
Но в этом утверждении я сомневаюсь, коллеги, прошу поправить, если я не прав

Иван, в общем случае все верно :) Разночтение возникает, если мы начинаем учитвать риски непосредственно в оценке.

Чтобы избежать подобной проблемы нет необходимости в критической цепи. Достаточно использовать сравнительно простой поием под названием "выравнивание ресурсов". На самом деле подход критической цепи в общем случае не может быть использован одновременно с критическим путем (немного разная идеология). :)

Риски закладываются через резервы. Если делать это корректно (а не "раздуванием оценок"), разночтений не будет :)

Именно. Продолжительность некоторых работ на критическом пути может быть скорректирована на основании анализа рисков. Но в общем случае это так :)

Если говорить о "раздувании оценок", мы точно об одном и том же? )
С резервами в отдельном документе возникают нюансы, если проектные задачи взаимосвязаны между собой и, соответственно, связаны исполнители. Особенно интересно, если команда делает несколько проектов параллельно. В этом случае, если риски заложены непосредственно в задачи, упрощается (ИМХО) управление связями. Данное мнение прошу считать основанным исключительно на субъективном опыте)