Упражнение: тесты по управлению расписанием проекта

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

• А. Метод критического пути
• В. Флоучарт
• С. Диаграмму предшественников
• D. ИСР

Ответ А. В вариантах только два ответа, имеющих отношение к расписанию: это предшественники, и метод критического пути. Диаграмма предшествеников это метод, который работает со связями задач, не с их гибкостью. Так что РМ анализирует критический путь.

2. Инженер-проектировщик помогает удостовериться, что зависимости внутри области ее экспертизы правильно отражены в проекте. Дизайн некоторых продуктов должен быть закончен прежде, чем производство начнется. Это пример какого типа зависимостей?

• А. Дискретная зависимость
• В. Внешняя зависимость
• С. Обязательная зависимость
• D. Зависимость по содержанию

Ответ С. Нет упоминаний о том, что зависимость приходит откуда-то извне проекта, так что она не внешняя. Зависимость по содержанию - вообще нет такого термина. Ключевые слова в вопросе, "должен быть закончен прежде". Поскольку зависимость требуется, она не дискретная, то есть обязательная.

Выходы процесса Контроля расписания

Одна из задач РМ - это обеспечение того, чтобы проект соответствовал своим целям. Даже если вы полностью отдавали себе отчет, что понимаете цели проекта на этапе планирования, во время исполнения могут случиться изменения, которые повлияют на изначальный план. Так что, есть стандартная практика переоценки оставшихся работ по крайней мере однажды в течение жизни проекта, для проверки, что проект соответствует расписанию, бюджету, и иным ограничениям, и последующая корректировка проекта если соответствие нарушено.
Процесс Контроля расписания выливается в:

1. Данные по исполнению работ
2. Прогнозы расписания
3. Запросы на изменение. Например, изменение в расписании может потребовать больших ресурсов, или изменений содержания. Такие изменения проводятся как часть Интегрированного контроля изменений
4. Обновления Плана управления проектом
5. Изменения базовых значений для измерения перфоманса
6. Реестр предположений
7. Реестр рисков
8. Реестр вынесенных уроков

Процесс Контроля расписания

Контроль означает измерение против плана. На хорошо спланированных проектах, РМ не тратит много времени на разбор проблем, поскольку большинство проблем разбираются на стадии планирования и работы с рисками.
Проект, равно как и РМ, будет неуспешен, если базовый план по расписанию не будет достигнут. Так что, усилия по контрою и мониторингу идут после усилий по измерению; также они включают предпринятие корректировочных и превентивных действий раз за разом в течение жизни проекта, чтобы дела оставались в соответствии с планом. Без этого, все усилия по созданию самого реалистичного расписания пойдут на выброс.
Контроль расписания также предполагает поиск вещей, которые влияют на изменение расписания, и воздействие на источники, то есть корневые причины проблем. Например, если есть сотрудник, или какой-то фактор, постоянно сбивающий проект, РМ должен разобраться с ним, вместо того, чтобы постоянно бороться с вызываемыми им проблемами. РМ должен быть проактивен.
Если все же сложилось, что проект в срок не явно не получится исполнить, а этот срок - реально критичное условие успеха, РМ должен рекомендовать завершить проект, чтобы не тратить более время и деньги компании. Иными словами, РМ должен иметь влияние на топ-менеджмент компании, чтобы контролировать проект. Контроль расписания - это не просто выпуск его обновлений!
Нужно быть уверенным, что вы понимаете, в чем состоит контроль расписания. Нужно думать о том, чтобы большие усилия, потраченные на планирование проекта, не были напрасны. Нужно постоянно быть начеку в отношении вещей, которые могут повлиять на расписание.
Ниже список прочих активностей, связанных с контролем расписания в plan-driven проектах:

1. Доступ к ИС управления проектами, для отслеживания текущего перфоманса работ, и сравнения его с запланированным
2. Переоценка еще неисполненных компонентов проекта
3. Проведение ревью перфоманса проекта, через формальный анализ исполнения проекта
4. Проведение анализа данных: анализ освоенных объемов, анализ трендов, анализ отклонений, что-если анализ
5. Проверка того, что активности критического пути исполняются в рамках базовых значений по расписанию. Если нет, то корректируем критический путь, лучше через наличие позитивного плавания
6. Корректируем будущие части проекта преимущественно через работу с задержками, вместо того чтобы просить больше времени (то есть используем техники сжатия расписания: быстрый проход, отсрочки и запаздывания, повышение срочности)
7. Можем вносить корректировки в ресурсы, для их оптимизации, чтобы улучшить перфоманс проекта
8. Нужно постоянно оптимизировать расписание
9. Корректируем метрики, которые не дают РМ нужной информации
10. Корректируем формат или требуемый контент отчетов, которые должны давать информацию для контроля и управления проектом
11. Выявляем все потребности к изменению, включая корректирующие и превентивные действия
12. Следуем интегрированному процессу контроля изменений

Усилия по контролю проекта с change-driven подходом:

1. Сравнение фактически исполненной работы с тем, что было запланировано на данную итерацию
2. Проведение ретроспектив, для выявления потенциальных улучшений проекта
3. Приоритезация бэклога проекта
4. Выявление изменений по мере возникновения, и управление ими

Данные расписания, и базовые значения расписания

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

1. Данные по расписанию включает все, что нужно для подготовки расписания, включая вехи, активности по проекту, атрибуты активностей, оценки продолжительности, зависимости, и предположения и ограничения, использованные в проекте
2. Базовые значения по расписанию - это версия расписания, против которой мы будем измерять прогресс. Помним, что базовые значения могут быть изменены только в результате формального запроса на изменение. Если проект может быть сделан быстрее, чем просит клиент, может быть разница между базовым значением расписания и желаемой датой для клиента. Эта разница - плавание проекта
3. Запросы на изменение. Любые изменения расписания могут повлиять на план управления проектом. Запросы на изменение разбираются через процесс Интегрированного контроля изменений
4. Обновления проектных документов. Процесс создания законченного и реалистичного расписания может вылиться в апдейты проектной документации, включая оценку продолжительности проекта, требования к ресурсам, атрибуты активностей, реестр рисков, реестр предположений, и реестр вынесенных уроков

Преимущества разных форматов представления расписания

На экзамене всегда будут вопросы, которые сложны, даже если вы очень крутой РМ, если вы не думали о них ранее! В том числе, таковы и вопросы по представлению расписания. Поэтому, ниже разбираем кейсы использования различных представлений расписания.

1. В каких случаях используем сетевую диаграмму? Тогда, когда надо понять зависимости между задачами
2. В каких случаях используем диаграмму вех? Когда нужно рапортовать менеджменту или заказчику
3. В каких случаях используем Ганта? Когда отслеживаем прогресс, и рапортуем команде

Документация: Расписание проекта

Расписание, и его сетевой анализ - это выход из процесса Управления расписанием. Расписание прорабатывается итеративно, вследствие проработки управления рисками и иных составляющих плана управления проектом, до тех пор пока оно не будет достигнуто в реалистичном и законченном виде. Реальное расписание, как итог итеративного его планирования, будет Базовым значением расписания, и станет частью Плана управления проектом.
Расписание проекта включает активности по проекту, с заданными датами каждой активности, и вехи, определенные РМ или менеджментом. Расписание проекта может быть показано с зависимостями задач или без них, и в одном из следующих представлений:

1. сетевая диаграмма
2. диаграмма вех
3. диаграмма Ганта

Сетевая диаграмма описана ранее.

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

Диаграмма Ганта. Это слабый инструмент планирования, но сильный инструмент отслеживания прогресса. Гант - это не часть плана управления проектом. Гант не позволяет организовать проект также эффективно, как это делает ИСР и сетевая диаграмма. так что и рисовать Ганта имеет смысл после них.

Выходы из процесса Разработки расписания

Процесс Разработки расписания завершается собственно Расписанием проекта, Базовыми значениями расписания, данными по расписанию, запросами на изменение, и апдейтами всех связанных документов проекта.

Анализ и симуляция данных

Анализ Монте-Карло. Во время создания реалистичного и завершенного расписания, полезно спрашивать себя: "Что будет, если на проекте изменится такой-то фактор?". Поскольку, предположения по каждой активности могут измениться, а значит изменится и ее продолжительность. Один из способов посчитать влияние таких ситуаций, это анализ "что-если", или иначе, Анализ Монте-Карло. Эта техника подразумевает компьютерную симуляцию завершения проекта, основываясь на трехточечную оценку каждой активности (оптимистичная, наиболее вероятная, пессимистичная) для каждой активности на сетевой диаграмме. Симуляция может вам рассказать:

1. вероятность завершения проекта в каждую заданную дату
2. вероятность завершения проекта с определенными затратами
3. вероятность того, что какая-то из активностей окажется на критическом пути

Метод Монте-Карло - это такой способ консолидации трехточечных оценок в общую оценку проекта. Он более точен, чем иные методы, поскольку симулирует фактические детали проекта, и вычисляет вероятность.

Метод Монте-Карло поможет разобраться со "сходимостью путей", то есть местами сетевой диаграммы, где несколько предшественников сходятся в один последователь, добавляя тем самым рисков проекту.

Оптимизация ресурсов. Предполагает поиск путей корректировки использования ресурсов. Есть две техники, которые позволяют достичь такого результата.

1. Выравнивание ресурсов. Используется для разработки расписания в условиях ограничения ресурсов. Как правило, удлиняет расписание и увеличивает затраты, для того чтобы разобраться с ограничениями количества и доступности ресурсов. Эта техника редко используется в софте по управлению проектом, и тем не менее позволяет оценить пики загрузки и спокойные участки проекта от месяца к месяцу, делая проект более стабильным по ресурсам. Например, если в первом месяце у вас потребность в 5 единиц ресурсов, по втором 15, в третьем 3, и такие скачки неприемлемы.
2. Сглаживание ресурсов. Сглаживание - это модифицированная форма выравнивания, когда ресурсы перераспределяются только в рамках их плавания

Гибкое управление расписанием. В гибких change-driven проектах, работа по выпуску продукта проекта разбивается на релизы и итерации. Гибкое планирование релизов предполагает высокоуровневое расписание, с запланированными релизами, и итерациями по каждому релизу. Усилия по планированию выливаются в таймлайн, который определяет фичи, включенные в каждый релиз.

Упражнение: выбор варианта сжатия расписания

Допустим, есть проект, у которого плавание -3 месяца (то есть проект отстает от плана). Какие из активностей проекта лучше ускорить, при условии, что все они на критическом пути? И сколько это будет стоить проекту?

Для ответа, надо выявить все активности, которые сэкономят 3 месяца при условии ускорения. Это:

1. J + K, $14.000
2. J + N, $5.000
3. K + L, $16.000
4. N + L, $7.000
5. M, $9.000

Выбираем самый дешевый способ, J + N, $5.000.

Очень важно понять, что последняя колонка в табличке для отвлечения внимания! В ней нет данных, влияющих на ответ - такое на экзамене тоже надо фильтровать.

Возможный импакт вариантов сжатия расписания

Как может повлиять на проект каждый из вариантов сжатия расписания?

1. Быстрый проход (параллель):
1. всегда увеличивает риски
2. требует больше времени от РМ
2. Повышение срочности (ускорение исполнения задач за деньги):
1. всегда увеличивает стоимость
2. может увеличить риски
3. требует больше времени от РМ
3. Уменьшение содержания:
1. может вести к сокращению ресурсов, затрат, времени
2. может негативно сказаться на удовлетворенности заказчика
3. может увеличить риск
4. Сокращение качества:
1. для эффективного использования, требует хороших метрик по желаемом и текущему уровню качества
2. может негативно сказаться на удовлетворенности заказчика

Варианты сжатия расписания

Во время планирования проекта, его продолжительность оценена в 33 месяца. При этом спонсор настаивает на ограничении в 30 месяцев. Смотрим на сетевую диаграмму ниже, и выявляем пути сокращения продолжительности расписания.
Деталей в этом упражнении мало, так что все предположения делаем сами, так, чтобы подойти к максимальному количеству вариантов.

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

1. Переоценка. Может случиться например как следствие снизившихся рисков. Мы должны пересмотреть оценки, и выявить те, которые включают снизившиеся риски, так что длительность активностей станет короче, а сам проект пойдет быстрее. Никогда не рассматриваем переоценку просто как способ сократить проект на 10%.
2. Выполнить активности С и Н в параллели. Это быстрый проход. Но, мы предполагаем, что зависимость между Н и С дискретная, что одна не зависит прямо от другой.
3. Добавить ресурсов (изнутри компании) к активности G. Это повышение срочности расписания. Оно добавит затрат к проекту. Мы предполагаем, что добавление ресурсов к активности G будет полезным, и ресурсы эти у нас есть.
4. Сократить активность Н. То есть уменьшить содержание. Хотя это и не первый вариант к выбору, поскольку скорее всего повлияет на заказчика, сокращение содержания тоже вариант.
5. Нанять консультантов, чтобы помогли с активностями G, Н и С (за доп.расходы к проекту). Это сжатие расписания, через повышение срочности. Мы предполагаем, что добавление ресурсов к активности G будет полезным, и ресурсы эти мы можем закупить.
6. Поставить более опытных людей на активности критического пути (G, Н и С). Это сжатие расписания. Мы предполагаем, что сейчас эти активности критического пути исполняются менее опытными коллегами.
7. Просто сократить время, снизив требования к качеству. Не первый вариант, поскольку качество - это ограничение проекта; но манипуляции с ним тоже вариант.
8. Сказать нет, сказать что проект можно сделать за 33 месяца и точка. Это последний вариант к выбору.
9. Забить на все, ничего ни с кем не согласовывать, и планомерно опоздать. Это вообще не вариант (разве что совсем крайний) - см. выше сколько нормальных вариантов выхода из ситуации.

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

Повышение срочности расписания

Эта техника предполагает привлечение новых, или корректировку имеющихся ресурсов, чтобы сократить расписание и при этом сохранить содержание проекта. Повышение срочности по определению повышает стоимость проекта, и может повысить риски. Эта техника продает время за деньги.
Например, можно заменить у активности на критическом пути свой ресурс на законтрактованный. Или, купить какой-то софт, который поможет команде работать лучше, сберегая ее время.
Если на вашем проекте негативное плавание, что означает оценочную дату завершения после желаемой, то ваша первая мысль - сказать клиенту, что мы опоздаем? Нет; сначала нужно подумать, можем ли мы исправить положение, сократив расписание. Нужно рассмотреть быстрый проход и повышение срочности, и возможно выбрать что-то из этого либо их комбинацию, так, чтобы это имело минимальный импакт на проект. Этого подхода нужно придерживаться и на экзамене.
В реальных проектах, многие РМ используют сетевые диаграммы для управления ежедневными операциями проекта, и для внесения корректировок когда случаются изменения. Нужно быть готовым к этому на экзамене, в виде множества вопросов. включающих сетевые диаграммы, вычислениях, и сценариях "Что бы вы сделали в таких ситуациях?".

Быстрый проход расписания

Эта техника предполагает запараллеливание активностей критического пути, которые ранее были последовательны - полностью или частично. Например, на рисунке ниже можно запараллелить активности Н и С (остальные нельзя по причине сложных связей):

Быстрый проход обычно выливается в переработки, увеличивает риски, и требует более ответственного подхода у управлению коммуникациями.

Сжатие расписания

Одна из самых частых проблем на проектах - нереальные сроки. Проблема может возникнуть во время планирования, когда менеджмент дает нереальные сроки, или во время исполнения, когда РМ пытается вернуть проект в расписание, или включает в него новые изменения. Многие РМ винят в том спонсоров или руководство, но это неверно. У РМ профессиональная ответственность за борьбу с нереальными сроками, предоставление опций, и обеспечение того, что проект будет исполнен в заданном расписании, поскольку верно спланирован, и к нему применены техники сетевого анализа, такие как сжатие расписания.
Также имеем ввиду, что сжатие расписания - это способ утилизации плавания, через быстрый проход активностей на критическом пути. Это означает корректировку сетевой диаграммы так, что активности критического пути, которые были однажды спланированы исполняться последовательно, теперь будут исполняться параллельно. Быстрый проход экономит время, но и рисков тоже добавляет.
Во время планирования проекта, РМ может использовать сжатие расписания, чтобы определить, может ли быть достигнута желаемая дата, а если нет, то что нужно изменить, чтобы достигнуть.
Далее на проекте, сжатие расписания может быть использовано во время исполнения Интегрированного контроля изменений, и Контроля расписания, чтобы оценить возможности управлять влиянием изменений. Цель техники сжатия - управлять расписанием без изменений базовых значений расписания. Это не всегда возможно, но пробовать надо.
На эту тему в экзамене более 10 вопросов.

Ситуации на понимание критического пути

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

1. Может ли у проекта быть более одного критического пути? Да запросто, это несколько веток с максимальной продолжительностью
2. Это хорошо? Нет, несколько критических путей сильно повышает риск
3. Может ли меняться критический путь? Да, может в ходе проекта
4. Может ли быть отрицательное плавание? Да; это означает, что мы отстали
5. Каково плавание критического пути? При планировании, плавание критического пути - ноль. По мере исполнения проекта, если активность была исполнена раньше или позже против плана, будет возникать позитивное или негативное плавание. Негативное плавание на критическом пути требует корректировок либо внесения изменений в проект, чтобы привести его в соответствие с планом
6. Меняется ли сетевая диаграмма с изменением конечной даты? Автоматически нет, но РМ должен выполнять действия типа сжатия расписания или быстрого прохода, чтобы расписание всегда соответствовало новой дате, а вслед за этим корректировать и сетевую диаграмму
7. Можно ли оставить проект с негативным плаванием? Нет, нужно сжимать расписание. Если усилия по сжатию расписания не выливаются в нулевое или позитивное плавание, нужно отправить запрос на изменение базовых значений

Упражнение: снова рисуем сетевую диаграмму

Даны вводные:

1. Какова длина критического пути?
2. Каково плавание активности В?
3. Каково плавание активности Е?
4. Каково плавание активности D?
5. Для сокращения проекта, спонсор предложил убрать активность Е из проекта, сделав D предшественником G и F. Каков будет эффект.

Нарисуем сетевую диаграмму:

То есть ответы:

1. Критический путь 33 мес
2. Плавание В составляет 15 мес
3. Плавание Е 1 мес
4. Плавание D 1 мес
5. Устранение Е эффекта не принесет никакого:

Упражнение: рисуем сетевую диаграмму

Вводные:

1. Активность 1 начинается немедленно, и продлится 3 недели
2. Активность 2 начинается после активности 1, и продлится 3 недели
3. Активность 3 начинается после активности 1, и продлится 6 недель
4. Активность 4 начинается после активности 2, и продлится 8 недель
5. Активность 5 начинается после активности 3 и активности 4, и продлится 4 недели

Нужно построить сетевую диаграмму, и ответить на вопросы:

1. Какова длина критического пути?
2. Какое плавание у активности 3?
3. Какое плавание активности 2?
4. Каково плавание пути с максимальным плаванием?
5. Ресурс на активность 3 заменен другим, менее расторопным, так что активность займет 10 дней. Как это повлияет на проект?
6. Менеджмент решает добавить в проект Активность 6. Она займет 11 недель, и должна быть исполнена после активности 3 и перед активностью 5. Один говорит, что это удлинит проект на 11 недель другой - что менее чем на 11 недель. Кто прав? Предыдущий пункт не учитываем тут.
7. По п.6 - насколько дольше займет проект?

Нарисуем сетевую диаграмму, посчитаем цифры:

1. Критический путь составит 18 дней
2. Плавание активности 3 составит 5 дней
3. Плавание активности 2 составит 0. Активности на критическом пути обычно не имеют плавания
4. Плавание пути с максимальным плаванием - это макс сумма плаваний всех путей кроме критического. У нас это 0 + 5 + 0 = 5.
5. Проект не изменит свою длину (но вообще повысятся риски, оба пути станут критическими):

      6. Активность не на критическом пути, то есть проект удлинится не на 11 недель, а меньше

      7. Он удлинится на 24 - 18 = 6 недель:

Использование метода критического пути

Посмотрим, как это работает. Пусть у нас вот такая сетевая диаграмма; критический путь на ней отмечен красными стрелками:

Нам нужно понять самую раннюю и самую позднюю даты, в которые каждая активность должна начаться, и аналогично самую раннюю и самую позднюю даты, в которые она должна закончиться. Для этого, нужно пройти по сетевой диаграмме от начала до конца, и наоборот. "Ранние" цифры вычисляем, двигаясь вперед (прямой проход), "поздние" - назад (обратный проход).
Первую активность берем за ноль. Отмечаем дни вот так:

Результат прямого прохода:

Обращаем внимание на те активности, у которых более одного предшественника - нужно учитывать их все! См.задачи F и G.

Теперь считаем с конца, обратный проход:

Теперь обращаем внимание на те активности, у которых более одного последователя - например показательна F.

Далее считаем плавание, как LS - ES, или LF - EF:

Задачи с нулевым плаванием - на критическом пути.

Как критический путь помогает вам как РМ?

Критический путь:

1. помогает проверить, как много времени займет проект
2. показывает, какие активности плавают, и соответственно могут быть отложены без откладывания проекта
3. дает информацию, нужную для сжатия расписания проекта, во время планирования, или в случае, если что-то изменится
4. помогает определить, на чем фокусировать ваши усилия по управлению проектом
5. помогает определить, с какими активностями связан наибольший риск
6. помогает определить, есть ли отложенные активности

Сетевой анализ расписания

Сетевой анализ расписания используется для создания модели расписания, и в итоге, для финализации расписания проекта. Он может использовать одну или несколько представленных техник:

1. метод критического пути
2. сжатие расписания
3. анализ что-если (Монте-Карло)
4. оптимизация ресурсов
5. гибкое планирование релизов

Метод критического пути. Предполагает вычисление самого длинного трека на сетевой диаграмме, самой ранней и самой поздней точки, когда каждая активность должна стартовать, и самой ранней и самой поздней точки, когда она должна закончиться. Для понимания этого метода, нужно разобраться со следующими базовыми концептами:

1. Критический путь. Это - самый длинный трек на сетевой диаграмме, и он определяет кратчайшее время, в которое может быть исполнен проект. Самый легкий способ найти критический путь, это выявить все треки сети, и добавить к каждому продолжительность. Перед экзаменом, лучше попрактиковаться в таком вручную
2. Путь ближайший к критическому пути. Это путь, самый близкий по продолжительности к критическому. Может случиться что-то, что укоротит критический путь, или удлинит путь ближайший к критическому, так, что ближайший путь сам станет критическим. Чем меньше разница критического и ближайшего к критическому путей, тем выше риски проекта. Путей, ближайших к критическому, может быть несколько. На проекте нужно фокусироваться и на критическом пути, и на ближайших к нему, чтобы не допустить отсрочки
3. Плавание (гибкость расписания). Нужно понимать, что это такое, и уметь вычислить на экзамене вручную. Имеем ввиду, что термины "плавание" (float) и "слабина" (slack) означают одно и то же, второй термин просто более исторически ранний. Есть три типа плавания, с которыми можно столкнуться на экзамене:
1. тотальное плавание - это оценка времени, на которое активность может быть отложена без вреда для конечной даты проекта, или его промежуточной вехи, оставаясь при этом в рамках ограничений по расписанию
2. свободное плавание - оценка времени, на которое активность может быть отложена без откладывания ее последователей, оставаясь при этом в рамках ограничений по расписанию
3. проектное плавание (иначе, общее позитивное плавание, positive total float) - это время, на которое может быть отложен весь проект, без сдвига внешне обозначенной даты завершения проекта, требуемой заказчиком или менеджментом, или даты, на которую прежде закоммитился РМ

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

Когда вы понимаете критический путь, и пути ближайшие к критическому, плавание можно использовать для наилучшего распределения ресурсов. Например, самые неопытные ресурсы можно ставить на задачи с максимальным плаванием - даже если они будут делать работу дольше, проект сильно не отстанет!

Понимание плавания также позволяет участникам команды работать на нескольких проектах одновременно. Им конечно нужен аппрувал РМ на отвлечение, но плавание показывает, насколько они могут отсрочить задачу.

Иногда, вопросы экзамена составлены так, что прямо заявляют плавание, но чаще нужно его вычислять. Расчет:

1. Float = Late Start (LS) - Early Start (ES)
2. Float = Late Finish (LF) - Early Finish (EF)

Какую формулу выбирать, смотрим от доступной информации.