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

В статье рассматривается опыт ООО «Аэроэкспресс» при использовании показателей контроля качества календарных планов, анализируются рекомендации DCMA (The USA Defense Contract Management Agency) по контролю качества календарных планов проектов, формируются рекомендации по развитию системы оценки планов в задачах проектного управления.

Уже внедряя систему управления проектами, мы в «Аэроэкспрессе» продолжали анализировать опыт и варианты построения информационных систем управления проектами (ИСУП). В одной из организаций нам представили ИСУП собственной разработки. Сразу оговоримся: компания была строительная; система, в отличии от нашей, строящейся на базе MS Project Server и SharePoint, строилась на базе программного обеспечения с открытым кодом.

Систему презентовал сам генеральный директор. Было видно, что он разбирается в функционале. При наличии достаточно качественных буклетов с описаниями, демонстрация проводилась «вживую» и на ведущихся проектах. Это еще больше вызывало уважение и подтверждало практическую возможность применения ИСУП. Но после первых восторгов, присмотревшись к данным на экране, заметили, что ряд работ, которые по плану должны были завершиться два–три месяца назад, не были завершены. Обратили на это внимание, стали вместе разбираться: почему и к чему может привести… благо на презентации присутствовали все ключевые руководители. Тут выяснились некоторые нюансы работы и особенности использования презентуемой ИСУП в принятии управленческих решений.

Тогда мы эту систему не купили. Поняли, что наша ИСУП, разрабатываемая совместно с ООО «Бастион Интегратор», не хуже. Но возникло чёткое понимание того, что отчёты по проекту нельзя даже рассматривать, если они построены на основе неактуальных данных. При этом, «ручные» проверки или фиксация новых требований в регламентах проблему не снимут.

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

Опыт и некоторые уроки применения оценок качества планов проектов в ООО «Аэроэкспресс»

Начав в ООО «Аэроэкспресс» использование функционала автоматизированного оценивания качества планов проектов с лета 2015 г. и с 6 показателей, количество оцениваемых показателей на конец 2016 г. возросло до 12.

1. Не актуальные строки плана — строки плана, которые на дату оценивания должны начаться, но фактически не начаты, или должны закончиться, но фактически не завершены. Устранение «проблемных» мест связано с корректировками дат начала/окончания в исполняемом плане, либо с вводом актуального % по фактическому исполнению.
2. Вехи без подтверждения — те завершенные вехи, по которым не прикреплены подтверждающие документы к строке плана. Проведённые доработки функционала совместной работы с документами позволили упростить прикрепление документов, размещенных на сайте проекта, к строкам календарного плана. Это сделало планы более пригодными для совместной работы с документами и облегчило администрирование исполнения задач. Устранение «проблемных» мест связано с размещением недостающих подтверждающих документов на сайт проекта и с их прикреплением к завершенным вехам.
3. Работы и вехи без взаимосвязей — «висящие» задачи, т.е. не содержащие предшественников и/или последователей в сетевой модели. Устранение «проблемных» мест связано с дополнением сетевой модели: корректировка логических взаимосвязей между задачами и добавлением новых задач, при необходимости.
4. Лишние взаимосвязи — взаимосвязи с блоками работ. Устранение «проблемных» мест связано с анализом необходимости таких взаимосвязей и их переключением на «внутренние» вехи/работы блока.
5. Неактивные строки плана — деактивированные строки плана. Устранение «проблемных» мест связано с анализом возможности исключения строк из исполнения в рамках реализации проекта.
6. Ручное планирование — строки плана с ручным режимом планирования. Устранение «проблемных» мест связано с анализом необходимости режима «ручное планирование» для соответствующих задач и с переключением режима планирования на автоматический.
7. Локальные ресурсы — работая с серверной версией MS Project мы исключаем возможность некорректного назначения «неучтенных» или фактически отсутствующих ресурсов на работы плана. Устранение «проблемных» мест связано с корректировкой пула ресурсов проекта и переназначением локальных ресурсов на корпоративные.
8. Недостаточная детализация работ — работы календарного плана ближайшего интервала планирования с длительностями более интервала планирования. Устранение «проблемных» мест связано с анализом необходимости/возможности декомпозиции работ и проведением соответствующей декомпозиции.
9. Блоки без вех — блоки календарного плана, в рамках которых не заданы вехи. Устранение «проблемных» мест связано с анализом необходимости фиксации контролируемого события/результата в рамках блока с соответствующим дополнением плана.
10. Блоки с назначенными ресурсами — блоки календарного плана, по которым назначены ресурсы. Проведённая разработка функционала матрицы ответственностей позволила назначать различные роли из числа участников проекта на блоки работ (например, ответственный исполнитель, принимает результат, информируется и проч.). Это позволило избежать возможных ошибок и несоответствий в расчетах исполнения, обусловленных назначением ресурсов на блоки, а также формировать дополнительные уведомления по блокам для соответствующих ролей на них назначенных. Устранение «проблемных» мест связано с удалением ресурсов с назначений на блоки и назначением ролевых ответственностей, при необходимости.
11. Декомпозиция блока 1 в 1 — блоки календарного плана, являющиеся единственными в рамках родительского блока. Устранение «проблемных» мест связано с анализом необходимости/возможности и уточнением структурной декомпозиции родительского блока.
12. Блок как веха — блоки календарного плана, помеченные как вехи. Устранение «проблемных» мест связано с удалением признака «веха» с блока работ.

Все показатели объединяются в сводную таблицу (см. рис.1), и по каждому дополнительно формируется аналитическая таблица с указанием выявленных/возможных «проблемных» мест (см. рис.2). При этом, показатели разбиты на две группы:

1. Оцениваемые показатели — по данным показателям оценки должны находиться в «зеленой» зоне;
2. Информационные показатели — по данным показателям значения качества еще не установлены, либо сами оцениваемые критерии носят информационный характер.

Рис. 1. Сводная таблица оценивания календарного плана

Рис. 2. Примеры некоторых таблиц, указывающих на выявленные/возможные «проблемные» места в плане

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

Практика показала, что функционал автоматизированного оценивания планов полезен при подготовке регулярных статус–отчетов по проекту, а также при формировании планов на очередной период планирования. Время подтвердило и полезность данного функционала: начав с сотен «проблемных мест» по некоторым из показателей, что соответствовало 15–20% строк плана, сейчас по отчёту получаем единицы «проблемных мест», причем, практически ни одно из них проблемным и не является, а обусловлено особенностями конкретного проекта. Фактически можно говорить о развитии культуры планирования проектов.

Сейчас на повестке дня стоят следующие задачи:

• дальнейшее развитие и уточнение показателей и алгоритмов оценивания;
• внедрение критериальных требований к планированию в проекте для различных фаз управления (в т.ч. инициирование, открытие, реализация) и к качеству планов проекта для различных функциональных областей управления (в т.ч. управление сроками, управление затратами, управление закупками и проч.) с соответствующей поддержкой различным набором целевых и оценочных показателей;
• применение оценок к планам и отчётам, представляемых контрагентами по «своим» участкам/блокам выполняемых работ;
• освоение широким кругом руководителей и сотрудников организации подходов и принципов проектно–ориентированного планирования и управления в целом (см.,в частности [1 и 2]).

Стандарты / рекомендации оценивания качества планов

Какие еще подходы и параметры можно использовать для контроля качества проектов? В стандартах PMI нет прямых и точных рекомендаций по этому вопросу. Речь идет и о широко известном PMBОK [3] и о практических стандартах PMI (в частности, о Work Breakdown Structure Practice Standard, Practice Standard for Scheduling, Practice Standard for Project Estimating [5 – 7]).

Бо́льшей практической ценностью обладает подход, предлагаемый DCMA (см. [4]), основанный на проверках по 14 «точкам контроля». Приведем их с небольшими комментариями:

1. Логика сетевой диаграммы проекта. Есть очень емкое правило — все задачи должны быть связаны между собой. Каждая задача должна иметь предшественника или последователя. Исключения могут составлять не более 5% задач. Полагаем, что эта точка контроля недаром находится на первом месте. Сетевая диаграмма — основа календарного планирования и от её качества зависит весь календарный план.
2. Использование опережений. Конечно, у руководителя проекта может быть большой «соблазн» применять опережения для сжатия проекта. Но наличие опережений в плане признаётся недопустимым. Опережения вносят дополнительные риски инеопределенность в проект. В большинстве случаев, можно избавиться от опережения декомпозируя задачи и изменив связи между ними.

• Использование задержек. Количество задержек необходимо минимизировать. Не более 5% задач могут иметь задержки. В задержки ни в коем случае нельзя включать резервы на риски. Использование задержек должно ограничиваться технологическими моментами. Один из подходов — заменять опережения строками плана с соответствующим обозначением технологической задержки и указанием её длительности. Но это будет противоречить п.X (каждая работа должна быть обеспечена ресурсом, а какой ресурс у задержки?), либо, кроме фиктивной работы, придется создавать фиктивный ресурс.

1. Типы связей. Если проект планируется от начала, то следует придерживаться простого правила — максимально использовать связь типа «Финиш–Старт». В хорошем плане проекта не менее 90% задач должны быть связаны этим типом связи. В большинстве случаев удается избавиться от связей типа «Старт-Старт», «Финиш-Финиш» и «Старт-Финиш». Использование «Финиш-Старт» облегчает анализ сетевой диаграммы.
2. Типы ограничения задач. Задача должна начинаться как можно раньше (ASAP) — это основной тип ограничения, который нужно использовать, если проект планируется от начала. Допускается не более 5% задач, у которых установлен другой тип ограничения. Данный пункт обеспечивает сразу два момента:
   1. Минимизирует ручное планирование, что безусловный плюс;
   2. Уменьшает риски срыва сроков.
3. Общий временной резерв. Здесь речь идет о резерве, который рассчитывается методом критического пути. Такой резерв не должен быть более 44 рабочих дней (2 месяца). Превышение этого значения с высокой вероятностью означает пропущенные связи между задачами. Не более 5% задач могут быть с резервом более 2-х месяцев.

• Негативный временной резерв. По сути, негативный временной резерв означает нарушение директивной даты получения важного промежуточного или окончательного результата проекта. Наличие негативного резерва является недопустимым. В информационной системе этот пункт отлично срабатывает при сдвиге сроков критической задачи и наличия в конце проекта вехи с фиксированной датой. Руководителю проекта приходится либо разрабатывать мероприятия реагирования, либо задействовать резерв по времени.
• Большая продолжительность задачи. Продолжительность считается слишком большой, если задача длится более 44 рабочих дней (2 месяца). Пункт относится в первую очередь к разработки ИСР. Если в плане проекта есть задачи с большой продолжительностью — их необходимо декомпозировать.

1. Некорректные даты. В плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате. Другими словами, необходимо отчитываться о реальном состоянии проекта.
2. Ресурсы. Все задачи проекта должны быть обеспечены ресурсами или стоимостями. Очень правильный пункт: есть работа — должен быть тот, кто её выполнит. Если в проекте присутствует задача не обеспеченная ресурсами, значит план проекта сделан некачественно.
3. Отстающие задачи. Не более 5% задач могут отставать от базовых сроков. Считается, что если количество отстающих задач превышает указанный процент, это не дает возможности руководителю сосредоточиться на всех проблемах проекта. Отмечаем, что речь идет не только о критических задачах.

• Тест критического пути. При сдвиге сроков критической задачи срок проекта должен пропорционально сдвинуться.
• Индекс критического пути (CriticalPath Length Index — CPLI), рассчитываемый по формуле:

Целевое значение этого индекса равно единице. Допускается снижение до 0,95. Работы с индексом критического пути (CPLI) по сути направлена на снижение Общего временного резерва.

• Индекс выполнения базового плана (Baseline Execution Index — BEI), рассчитываемый по формуле:

Назначение этого индекса — контролировать эффективность работы подрядчика при выполнении контрольных точек. Целевое значение этого индекса также равно единице. Также допускается снижение до 0,95.

В одной из компаний применяется подход, основанный на описанных «точках контроля». Первоначально оценивание качества плана происходило «в ручном» режиме. Календарный план создается в MS-Project и достаточно поставить фильтр на соответствующих полях, чтобы проверить «точку контроля». Например, чтобы проверить «Логику сети» (п.I) нужно установить фильтр на поля «Предшественники», «Последователи» и сделать подсчет задач с пустым значением этих полей. Если количество таких задач превышает 5% — тест не пройден. Стоит упомянуть, что к точкам контроля подошли осмысленно — к примеру, если говорить о «Логике сети», то связи между суммарными задачами не проверялись.

Следующим шагом стала разработка автоматической процедуры, которая позволяет оценить качество плана. В соответствии с регламентом, прежде чем утверждается базовый план, проект проходит процедуру контроля. Пункты IX и XI автоматически будут пройдены — они актуальны для проекта, который уже выполняется. Далее, эта же процедура проводится каждый раз перед представлением руководству отчетности по проекту.

В этой процедуре, на данный момент, из «точек контроля» [4] были исключены 2 последних пункта: «Индекс критического пути» и «Индекс выполнения базового плана». Возможно, в дальнейшем они будут применяться.

В результате получается не просто констатация факта («тест пройден» или «тест не пройден»), но конкретно указаны ошибки, которые, в свою очередь, отсортированы по пунктам. Каждая ошибка привязана к конкретной строке в плане проекта, что акцентирует внимание планировщика на конкретной проблеме. На рис.3 и 4 показаны примеры работы этой системы оценивания.

Рис. 3. Пример фрагмента анализа проекта. Проблемы с большим резервом.

Рис. 4. Пример фрагмента анализа проекта. Негативный резерв.

***

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

Использование предложенных в статье подходов позволит сформирует условия для использования плана проекта в качестве одного из основных инструментов поддержки принятия управленческих решений по проекту.