MS Project vs маржа. Как превратить ваш MS Project в союзника в битве за прибыль

Проекты НИКОГДА не выполняются по плану.

Означает ли это, что PM обязан отслеживать взаимное влияние задач проекта, рассчитывать последствия отклонений, которые возникают вследствие выполнения задач не по плану? Да, и это его первостепенная задача, без ее выполнения он не сможет сдать проект в срок.

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

Может ли PM эффективно решить эту задачу самостоятельно? Может, если при разработке планов проектов он будет использовать три принципа:

сетевого графика;

материального измерения результата;

опорных точек.

Я не открыл Америку с этими принципами. Все, кто занимается планированием и отслеживанием проектов, о них слышали. Однако, одно дело знать термин и понимать, что он обозначает, и совсем другое – видеть, для чего он нужен здесь и сейчас, и почему без него в повседневной рутине никак нельзя обойтись.

Правила построения сетевого графика гласят:

начальная задача должна быть только одна;

конечная задача должна быть только одна;

все задачи, кроме начальной, должны иметь минимум одну предшествующую задачу;

все задачи, кроме завершающей, должны иметь минимум одну последующую задачу;

внутри плана не должно быть замкнутых контуров (групп задач со связями только внутри них самих).

Иными словами, сетевой график – это когда, ведя пальцем по графику от одной начальной задачи по тому или иному пути, последовательно, от задачи к задаче, мы обязательно доберемся к одной конечной задаче.

Рисунок 1. Не сетевой график

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

Рисунок 2. Сетевой график

Если же мы создадим связь у «Задачи 4», например, на «Задачу 5», то в графике все задачи будут удовлетворять правилам сетевого графика.

Что вы будете с этого иметь?

Представьте себе, что «Задача 4» из первого рисунка идет с большим опозданием (при этом вы точно знаете, да и логически это понятно, что «Задача 6» является последней в плане). В этом случае план будет выглядеть так:

Рисунок 3. Одна из задач в несетевом графике идет не по плану

Будьте уверены: если в плане много задач (к примеру, 500+), то эта ситуация будет для PM большой проблемой. А в варианте с соблюдением правил сетевого графика он будет выглядеть так:

Рисунок 4. Одна из задач в сетевом графике идет не по плану

…и мы видим влияние на весь проект абсолютно всех изменений плана, которые возникают в любом месте и в любой момент.

Принцип материального измерения результата

Из теории управления проектами мы знаем, что все метрики проекта можно разделить на «абсолютные» и «относительные». Например:

4 фактически забитые сваи – это абсолютная метрика;

5 свай по плану – это абсолютная метрика;

80% выполненной работы по задаче – это относительная метрика;

4 забитые сваи из 5 – это снова относительная метрика.

Как правило, программные продукты для управления проектами позволяют управлять обеими группами метрик. Но каждый знает, что нет ничего быстрее, чем просто вручную поставить «46%» на задачу.

Однако, легкость и быстрота имеет один очень серьезный недостаток: отсутствие точности оценки. И возникает очень важный вопрос:

На каком основании исполнитель задачи оценивает ее прогресс?

Почему именно 46%? Почему не 45%, 47%, 146%?

Если в ответ на такой вопрос исполнитель отвечает, что он «сделал сорок шесть квадратных метров из ста», то здесь есть объективность. Если же у исполнителя таких объективных данных нет, то мы должны просто поверить на слово, довериться компетенции. И так по каждому исполнителю, который отчитывается по задачам.

А если задач тысяча, а исполнителей пятьдесят? Какова в этом случае будет погрешность оценки результата?

Опытный читатель скажет: «есть задачи, где невозможно объективно измерить промежуточный результат». Например, задачи «разработать чертеж» и «принять стройплощадку» с большим трудом поддаются промежуточной оценке (промежуточная оценка чертежа – это натягивание совы на глобус, промежуточная оценка приемки площадки – это обычный чек-лист).

В этом случае, на помощь приходит бинарность: задача либо сделана (100%), либо нет (0%). Совершенно точно, что бинарная задача, отмеченная как невыполненная, не может навредить проекту в целом: лучше прогресс проекта в плане будет чуть меньше, чем в реальности, чем чуть больше.

Обеспечить выполнение принципа материального измерения результата на практике можно так:

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

фактические данные по задаче принимать только в единицах ресурсов, назначенных на задачу;

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

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

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

Принцип опорных точек

Опорные точки – это всем известные «вехи». В терминологии PMI веха – это задача с нулевой длительностью. Вехами обычно отделяют блоки задач, чтобы была наглядна логическая структура проекта. Смысл вех несколько пересекается с суммарными задачами. Однако обычно не рекомендуется в суммарные задачи добавлять связи (хотя технически это возможно), а вехи для того и предназначены, чтобы быть узлами, в которую сначала входят, а затем и выходят одна или целые группы связей. В этом смысле очень логично использовать именно вехи как стартовую и конечную точки проекта:

Рисунок 5. Крайние вехи проекта

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

фундамент готов;

несущие конструкции готовы;

кровля готова;

мехготовность достинута.

И так далее.

Есть еще одна побочная выгода от использования вех: обзор прогресса проекта «по-крупному» для «крупного» руководства. Как правило, такое руководство интересует портфель проектов, и в отдельные задачи проекта они не заглядывают. И здесь очень поможет «План по вехам» – фильтр, показывающий план проекта «по-крупному»: как раз так, как обычно необходимо в таких ситуациях.

Рисунок 6. Как добраться до встроенного «Плана по вехам»

Выводы

Все, что я описал выше – это не что иное, как смена парадигмы восприятия плана-графика производства работ по проекту: необходимо перестать относиться к плану как к ДОКУМЕНТУ, и начать относиться к нему как к МОДЕЛИ проекта.

Я утверждаю, что, относясь к плану проекта только как к документу (который вы, напечатав на бумаге, вложите в договор или повесите на стену) вы потеряете в:

адекватности оценки реалий;

оперативности реакции на изменения;

общей оценке прогресса и рисков проекта.

Относясь же к плану проекта как к модели (соблюдая три принципа, применяя адекватную детализацию задач, вводя факт оперативно и точно), вы приобретете:

мгновенную и адекватную реакцию плана на любые изменения;

возможность выполнить адекватный план-фактный анализ;

возможность автоматически сформировать ПРОГНОЗ по тем разрезам, которые вы заложите в план (например, сроки или бюджет).

И ваша модель проекта будет адекватна и актуальна. И вам не надо будет вручную «перепланировать» проект.

Сдвиг восприятия плана-графика от документа к модели – это необходимое условие для возникновения возможности:

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

автоматизации контроля и прогнозирования в MS Project (да и в любом другом софте класса EPM).

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

Глава 2. Планирование и перепланирование

«Корабли лавировали, лавировали, да не вылавировали.»

(скороговорка)

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

Но в ней не было сказано ни слова об экономии времени и энергии. Однако, цель наша – не только сделать модель корректной, но и сэкономить время, нервы и энергию PM для других задач.

За счет чего?

А все очень просто: при соблюдении трех принципов, описанных в предыдущей главе, PM больше не нужно перепланировать задачи. MS Project все сроки смещает сам. Автоматически.

Понятно, что в каких-то ситуациях все же придется заниматься корректировкой сроков окончания задач (да и начала тоже). Но объем этих действий будет несопоставимо меньше, чем ранее.

Давайте разбираться как это работает.

Итак, у нас есть ресурс, который мы назначаем на задачу: один или несколько. Ресурс характеризуется неким количеством в некоторых единицах измерения (50 штук свай, 100 квадратных метров окрашиваемой стены, 5 кубов бетонного основания, 80 часов трудозатрат сотрудника и так далее). В момент назначения ресурса MS Project автоматически и равномерно распределяет количество единиц по длительности задачи.

Далее необходимо направить логику MS Project в нужное нам русло: определить тип задачи. Тип задачи – это правила, по которым MS Project обрабатывает задачу при вводе фактических данных.

Всего типов задачи три:

фиксированная длительность;

фиксированный объем ресурсов;

фиксированные трудозатраты.

Рисунок 7. Типы задач в MS Project

Тип «Фиксированная длительность» оставляет неизменной дату окончания задачи при вводе любых фактических данных. Мы можем вместо 10 единиц ресурсов в день вводить по 5, и все остатки будут равномерно распределяться на последующие дни задачи. Данный вариант имеет право на существование, но все же он достаточно экзотичен для повседневных реалий.

Рисунок 8. Плановые данные в представлении "Использование задач"

Рисунок 9. Поведение задачи типа "Фиксированная длительность" при вводе факта

Тип «Фиксированный объем ресурсов» работает так:

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

Рисунок 10. Посуточный факт равен плану, дата окончания остается неизменной

Если мы вводим факт за день, который меньше плана, то остаток (план минус факт) переносится на день, следующий за датой окончания задачи, а дата окончания задачи смещается вправо