Календарно-сетевая модель и критические цепочки
В данной статье мы продолжим рассматривать отличие календарно-сетевой модели от календарно-сетевого графика и поговорим о критических цепочках проекта. А также о том, чем отличается метод критического пути от метода критических цепочек.
Все знают, что критический путь в графике есть, что необходимо осуществлять контроль за работами, которые находятся на данном критическом пути, но есть ряд нюансов, которые способны превратить критический путь в пустую формальность. В ходе рассмотрения сегодняшней темы я буду опираться на графические материалы из учебных курсов компании PM Expert и на авторские материалы, которые в том числе использую в своих курсах.
Итак, давайте начнем с «легенд» критического пути. Какие из них сразу, навскидку приходят в голову? Ну, как минимум две самые распространенные:
- Критический путь в проекте может быть только один;
- Критический путь не изменяется с ходом реализации проекта.
Что тут можно возразить? Во-первых, критический путь в проекте может быть и не один. Их может быть и два и три, и более – в зависимости от того, сколько технологических цепочек вы запланировали в своей календарно-сетевой модели. Во-вторых, критический путь живет динамичной жизнью в рамках жизненного цикла проекта и может изменяться даже ежедневно, при условии, что вы на ежедневной основе вносите фактические данные об исполнении работ календарно-сетевой модели и проводите перерасчет модели. Порой интересно наблюдать ситуацию, когда в кабинете той или иной команды проекта на стене висит распечатанный в цвете график проекта, с выделенным красным цветом критическим путем, и команда проекта в течение уже почти года осуществляет мониторинг хода реализации своего проекта по данному критическому пути. Конечно же, это неправильный подход.
На какие нюансы необходимо обращать внимание при построении календарно-сетевой модели и дальнейшей работе с ней, чтобы быть уверенным, что те сигналы, которые мы с вами получаем от нашей КСМ, действительно верные? Конечно же, желательно, чтобы у всех задач вашей календарно-сетевой модели были предшественники и последователи. Если нет возможности привязать их к явной задача/работе – установите связь с вехами начала или завершения проекта, или иными промежуточными вехами результатов. Постарайтесь использовать как можно меньше связей с опережением или запаздыванием – они мешают точности расчета. Ну и конечно же, считается «плохим тоном» использование жестких ограничения на задачах («прибивание их гвоздиками»). При исполнении указанных условий мы с вами можем быть уверены, что критический путь построен корректно, и мы получаем правильные сигналы от календарно-сетевой модели. Все это справедливо при соблюдении правил определения предшественников/последователей, то есть при грамотном определении технологических взаимозависимостей между задачами/работами проекта.
А теперь давайте рассмотрим, в чем состоит отличие метода критического пути от метода критической цепочки. Ключевое отличие соответствует разнице в определении календарно-сетевого графика и календарно-сетевой модели. Помните, в предыдущей статье? «Календарно-сетевой график – это инструмент планирования сроков реализации проекта, который оперирует только датами начала (завершения) задач проекта и длительностями исполнения данных задач. С учетом технологических взаимозависимостей между задачами проекта. Календарно-сетевая модель, помимо указанных для календарно-сетевого графика подходов, использует также информацию по ресурсам проекта, стоимостным параметрам задач/работ проекта, использует при своем построении метод критических цепочек и построена с применением специализированного программного обеспечения». Это мы вспомнили. И раз уж речь зашла о методе критического пути либо методе критических цепочек, давайте рассмотрим их отличия на примерах…
Рисунок 1.
Из определения, отображенного на рисунке 1, мы видим, что метод критической цепи уже оперирует таким понятием, как ресурсы. Что это значит? Давайте пойдем дальше и посмотрим на рисунок 2.
Рисунок 2.
Давайте представим себе, что у нас имеется под управлением проект, состоящий из 10 задач/работ, и мы должны построить календарно-сетевой график этого проекта. Используя метод определения дат раннего начала и окончания, а также позднего начала и окончания задач/работ проекта, а также понимая технологические последовательности и имея данные по длительностям работ, мы выстраиваем сетевую диаграмму проекта. Теперь мы как минимум уже понимаем, что наш проект имеет длительность 13 дней. И можем наблюдать, что те задачи, у которых даты раннего и позднего начал равны между собой, а также даты раннего и позднего окончаний также равны между собой (то есть это работы у которых нет резерва) – эти работы и являются работами критического пути. Он подсвечивается красным цветом. Теперь мы с вами просто обязаны обратить внимание на эти работы при управлении проектом, потому что понимаем, что увеличение длительности любой из задач/работ критического пути хотя бы на один день (!) приведет к увеличению сроков реализации всего проекта минимум на этот один день. Отлично. Посмотрели. В работу приняли. Но напомню – мы сейчас пока работаем в рамках создания календарно-сетевого графика и оперируем только датами, длительностями и технологическими взаимосвязями. Чего-то тут не хватает… Может, попробуем назначить на работы имеющиеся у нас ресурсы и перейдем в режим работы с календарно-сетевой моделью? Решили – выполнили. Давайте на рисунке 3 посмотрим итоги нашей деятельности уже с календарно-сетевой моделью.
Рисунок 3.
Мы можем наблюдать, что при назначении ресурсов мы столкнулись с проблемой, при которой две из работ, которые должны выполняться параллельно, используют один и тот же ресурс. И мы уже работаем по методу критической цепи. Обратимся к рисунку 4.
Рисунок 4.
На рисунке 4 детально показана почасовая загрузка наших ресурсов на работах проекта. Да, мы хотели, чтобы эти работы были выполнены за два дня, но у нас есть ограничения по ресурсу «Аналитик» - он у нас один. И теперь перед нами возникла дилемма, связанная с вариантами нашего реагирования на данную ситуацию. Основных вариантов действий – два: либо докупать еще один ресурс «Аналитик» на этот день, либо распараллеливать наши работы. Представим себе гипотетическую ситуацию, при которой существуют жесткие ограничения по бюджету проекта, поэтому возможности привлечь еще одного аналитика у нас нет. Что делать в этом случае? Тогда, в соответствии с предложениями, отображенными на рисунке 4, мы будем вынуждены распараллелить наши работы и увеличить длительность проекта. Произойдут ли изменения в нашей критической цепи? Как изменится длительность? Давайте посмотрим на рисунок 5.
Рисунок 5.
Мы с Вами наблюдаем ситуацию, при которой длительность всего проекта увеличилась на тот самый один день, и произошло перестроение критической цепи. Теперь длительность нашего проекта составляет 14 дней. И появился новый перечень задач/работ проекта, требующих первоочередного внимания со стороны руководителя проекта и всей команды проекта. А если бы мы не стали назначать ресурсы и работали, полагаясь на старый добрый «Авось»? Вот именно поэтому и полезно использовать в работе именно календарно-сетевую модель проекта. Использовать метод критической цепи. Именно тогда мы можем быть уверены в правильности тех сигналов, которые нам выдает календарно-сетевая модель.
Важно понимать, что хотя календарно-сетевая модель - это и есть именно тот инструмент, который позволяет адекватно управлять нашим проектом и считывать сигналы, это еще не вся прикладная польза от календарно-сетевой модели. Давайте еще раз внимательно посмотрим на рисунок 5. Мы видим новую критическую цепочку, которая теперь проходит через иные работы, чем на рисунках 2 и 3. Мы понимаем, что теперь эти работы - самые приоритетные. Представим себе ситуацию, когда возникли проблемы с ресурсами для своевременного выполнения работ по задаче «С», например, один из сотрудников заболел. Рассмотрим это на рисунке 6.
Рисунок 6.
Обратите внимание: задачи/работы «С» и «D» теперь исполняются в одни и те же временные периоды. Только задача «С» лежит на критической цепи, и любая ее сдвижка по дате начала или по длительности окажет влияние на срок завершения всего проекта в целом, а работа «D» имеет резерв в 2 дня. Я могу начать ее (самое раннее) на 4й день, а могу (самое позднее) начать на 6 день, и ничего с проектом не случится. Тут главное не увлечься и не начать на 7 день… Тогда работа «D» сама уже встанет на критическую цепочку и изменит срок завершения нашего проекта. Таким образом, имея данные о резерве по задаче «D» в два дня и предполагая, что на данной работе задействованы такие же ресурсы, что и на задаче «С», я как руководитель проекта имею полное право и возможность хоть полностью остановить выполнение работы «D» в рамках сроков раннего начала и окончания, перевести эти ресурсы на работу «С», красиво ее завершить на 5й день (согласно нашей модели), забрать с нее ресурсы и на 6 день поставить их снова на работу «D» и таким образом, спасти проект от нарушения сроков. Но что необходимо для того, чтобы уметь вот так ориентироваться и действительно получать правильные сигналы? Несколько ключевых пунктов:
- Грамотно построенная календарно-сетевая модель: без «гвоздиков», без отсутствия связей «предшественник-последователь» (то есть без работ с открытыми концами), без ресурсных конфликтов.
- Использование метода критической цепи, для определения приоритетов выполнения работ по проекту.
Но и это еще не вся польза, которую команда проекта может получить от календарно-сетевой модели. А об этом - уже в следующих материалах.