Лоуренс Лич - Вовремя и в рамках бюджета

Это сигнал к действию. Пора реализовать подготовленный ранее план. В зависимости от того, какие изменения нужны, может потребоваться пересмотреть план в рамках установленной процедуры управления изменениями. Если меняется логика связи операций (например, «финишфиниш» вместо «старт-финиш»), следует обновить и план. Такие меры, как сверхурочные работы или наем контрактников, изменения плана не требуют.

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

Если у вас готов план пополнения буфера в конце проекта, ничего делать не нужно. Если плана нет, придется вносить в проект изменения. Возможно, нужно будет пересмотреть дальнейшие работы и пересчитать размеры необходимых буферов. Когда буфер растрачен более чем на 100%, а возможности пополнить его нет, он перестает быть инструментом контроля.

Некоторые считают, что метод ССРМ противоположен методу управления по контрольным событиям. Точно не знаю, на чем основано это заблуждение, но могу предположить, что причина в неправильной трактовке слов Голдратта о бессмысленности установления четких дат контрольных событий без одновременного добавления соответствующих буферов. В разделе 5.6 я говорил, что считаю контрольные события действенным инструментом в управлении проектом. Когда проект продолжительный, контрольные события помогают направлять работу команды и планировать вознаграждения. Я всегда стремлюсь к тому, чтобы каждый квартал был пройден хотя бы один значительный этап проекта (наступило одно из запланированных ключевых событий).

ССРМ может работать с двумя типами контрольных событий — «плавающими» и «фиксированными». У фиксированных (с жестко заданной датой выполнения) в плане должен быть заложен буфер. Размер его следует определять так же, как и у проектного буфера — исходя из длины цепочки, ведущей к наступлению данного события. Для оценки состояния дел ориентироваться на этот буфер не нужно. Его задача — обеспечить соблюдение заданных сроков.

«Плавающие» контрольные события в диаграмме проекта представляют собой ключевые технические этапы. Их нельзя привязывать к конкретным датам (ни к плановым, ни к фактическим). При составлении диаграммы проекта с их помощью можно отметить наступление ключевых событий (например, завершение разработки дизайна). Окончание этих этапов — тоже прекрасный повод порадоваться.

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

• изменением считается вмешательство в логику плана (например, добавление и удаление операций, изменение порядка расположения операций);

• изменением считается серьезный пересмотр объема работ по операции (продумайте, что вы будете понимать под словом «серьезный»);

• изменением считается серьезный пересмотр требований к исполнителям операций (по количеству или квалификации); возможно, после этого потребуется пересмотреть также критическую цепь;

• перерасход или экономия времени, выделенного на операцию, не считается изменением;

• перерасход или экономия средств, выделенных на операцию, не считается изменением;

• изменения плана могут потребоваться по достижении критических границ расходования буферов (проектного, на слияние путей, на затраты);

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

Не забывайте, что ваша задача — управлять не планом, а проектом при помощи плана. Например, нет необходимости вносить изменения в буфер на основании фактических данных о текущем статусе проекта.

1. Уже прошла половина проекта, а проектный буфер не тронут. Можно ли сократить его вдвое?

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

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

2. Почему список приоритетов операций у нас меняется каждый день?

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

3. Судя по списку приоритетов, я должен сначала выполнить менее важную работу и лишь потом приняться за более приоритетную. Как такое возможно?

Скорее всего, со списком все в порядке. Такое бывает, когда цепочка работ из менее приоритетного проекта (в которой находится ваша операция) требует большего расхода проектного буфера, чем цепочка работ более приоритетного проекта. Не забывайте, что расстановка приоритетов производилась во время «наладки конвейера проектов». Если вы возьметесь за выполнение операции из более приоритетного проекта, причем цепочка работ, в которой находится операция, не вызывает максимального расходования проектного буфера, это никак не отразится на общем времени завершения данного проекта. Однако это напрямую повлияет на дату окончания менее приоритетного проекта. Поэтому, чтобы не нарушить запланированного хода всех одновременных проектов, следуйте списку приоритетов.