Анализ критического пути проекта

Critical Path (Критический путь) — это задача или последовательность задач, опре­деляющая дату окончания проекта. Если увеличить длительность задачи, лежащей на критическом пути, то длительность проекта тоже увеличится, а если уменьшить ее длительность, то длительность проекта тоже уменьшится.

MS Project «умеет» определять время, на которое можно задержать исполне­ние задачи без увеличения длительности проекта. Эта длительность хранится в поле Total Slack (Общий временной резерв), и если она меньше или равна нулю дней, то задача считается критической. Но в некоторых проектах крити­ческими могут считаться задачи, резерв которых больше, например, если он равен 1 дню. Чтобы определить для проекта размер временного резерва кри­тических задач, нужно с помощью команды меню Tools > Options (Сервис > Параметры) открыть диалоговое окно настройки параметров MS Project, перейти на вкладку Calculation (Расчеты) и указать нужное значение пара­метра Tasks are critical is slack is less or equal to... days (Считать критически­ми задачи, имеющие резерв не более... дней).

MS Project также относит к критическим задачи, имеющие ограничения типа Must Start On (Фиксированное начало), Must Finish On (Фиксированное окончание), As Late As Possible (Как можно позbже) в планируемых от даты начала проектах и As Soon As Possible (Как можно раbньше) в проектах, планируемых от даты окончания. Кроме того, критическими считаются задачи, дата окончания которых превыша­ет дату крайнего срока или совпадает с ней.

Для отображения критического пути проекта на диаграмме Ганта нужно вос­пользоваться мастером Gantt Chart Wizard (Мастер диаграмм Ганта), вызываемым од­ноименной командой в меню Format (Формат) или контекстном меню диаграммы Ганта. На втором шаге мастера (рис. 3.43) нужно выбрать переключатель Critical Path (Критический путь) и нажать кнопку Finish (Готово).

Рис. 3.43 Отображаем критический путь на диаграмме Ганта

После этого диаграмма Ганта перестроится, а задачи, лежащие на критическом пути (критические задачи), и связи между ними будут выделены красным цве­том (рис. 3.44, файл 6.mрр). Теперь можно переходить к уменьшению длитель­ностей задач, причем начать стоит с тех, что лежат на критическом пути. При этом следует помнить, что сокращение длительности задач может не только убрать их с критического пути, но и сделать критическими другие задачи.

Чтобы оставить на диаграмме Ганта только критические задачи, нужно воспользоваться фильтром Critical (Критические).

Рис. 3.44 Так выглядит наш план после форматирования диаграммы с помощью мастера и применения фильтра для отбора только критических задач

Для сокращения длительности задачи можно применить несколько методов: во-первых, можно сократить объем работы, требуемый для ее выполнения. Во-вто­рых, можно добавить ресурсы для ускорения выполнения работы при сохране­нии ее объема. Наконец, можно разбить задачу на подзадачи, выполняемые од­новременно разными сотрудниками.

В нашем случае мы сократили длительность двух задач: Подготовка редакционных заданий и Утверждение заданий авторами. Длительность первой задачи мы сократи­ли незначительно, а второй — в два раза (с 4 до 2 дней), поскольку на скорость ее выполнения можно повлиять административными мерами.

Но сокращение длительности этих задач не помогло уложиться в крайние сроки. И тогда мы разбили задачу Редактирование материалов на 3 подзадачи: Редактиро­вание раздела 1, 2 и 3 и спланировали их одновременное исполнение. Это воз­можно потому, что журнал состоит из трех разделов, и каждый из редакторов разделов отвечает за свой раздел и осуществляет редактирование материалов в нем независимо от других. Длительность каждой задачи была установлена рав­ной 10 дням, а загрузка ресурсов определена в 70% с ранним пиком в профиле загрузки. В результате бывшая задача и нынешняя фаза Редактирование материа­лов перестала быть критической (рис. 3.45, файл 7.mрр).

Рис. 3.45 Критический путь проекта после редактирования

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

В нашем случае превышение доступности снова возникло у Иванова, Петрова, Си­дорова и Галкиной (7.mрр) — наиболее активно задействованных в проекте ресур­сах. От него нужно избавиться, чтобы при анализе стоимости корректно учиты­вать трудозатраты и сверхурочную работу. Приемы выравнивания ресурсов вам уже известны, а в нашем случае мы использовали только перераспределение за­грузки (файл 8.mpp). Теперь, когда план работ и загрузка ресурсов нас устраива­ют, можно переходить к анализу и оптимизации стоимости проекта.