Как заставить MS Project работать за вас.

Часть 2. План? Модель!

Почему мы выбрасываем в мусорное ведро наш план проекта? Потому что план становится неактуальным.

Что означает фраза "План стал неактуальным"? Это означает, что картина проекта, отраженная в плане, перестала соответствовать картине проекта в реальном мире.

Эта рассинхронизация происходит по двум основным причинам:

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

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

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

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

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

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

• сетевого графика;
• материального измерения результата;
• опорных точек.

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

Принцип сетевого графика

Википедия дает нам простые и понятные правила построения сетевого графика (я чуть-чуть переформулировал их для адаптации к теме планирования):

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

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

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

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

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

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

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

А в варианте с соблюдением правил сетевого графика он будет выглядеть так:

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

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

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

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

На каком основании исполнитель задачи оценивает прогресс задачи как 46%? Почему не 45%, 47%, 146%?

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

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

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

Действительно, к примеру, разработка документа-чертежа – это задача, которая никак не поддается промежуточной оценке. Или, например, сопутствующая задача типа «принять стройплощадку».

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

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

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

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

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

Опорные точки – это всем известные «вехи».

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

В этом смысле очень логично использовать именно вехи как стартовую и конечную точки проекта:

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

• фундамент готов;
• несущие конструкции готовы;
• кровля готова;
• мехготовность достинута.

И так далее.

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

Будьте уверены – им такой подход понравится.

Заключение к статье

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

А мы к этому добавим: а это уже и не план проекта вовсе, дорогой наш руководитель проекта! Это уже МОДЕЛЬ проекта.

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

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

И ваша модель проекта всегда будет адекватна и актуальна. И вам не надо будет "перепланировать" проект.

Вам надо будет делать что положено вам по должностной инструкции: принимать управленческие решения.

Ну, или пить кофе… ☕️