Документирование контрольных функций проекта

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

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

Документирование проекта во время мониторинга и контроля раскладывается на “проверку результатов”, “учёт изменений” и “регулярную отчётность по проекту”.

Качество результатов

Как я уже говорил в статье по документированию качества проекта, качество подразделяются на “качество исполнения проекта” и на “качество продукта проекта”. Там же говорил, что “обеспечение качества” это долгосрочный повторяемый процесс. Следовательно мы не можем достичь идеального качества в проекте, поскольку проект выполняем только один раз. Придётся чем-то жертвовать. Поэтому давай оставим качество системы управления проектами на совести менеджеров по качеству всей компании и сотрудников Офиса Управления Проектами, а сами сосредоточимся на качестве продукта проекта.

Во время планирования, мы создали Метрика качества, План качества и Чек-листы, в ходе контроля нужно определить, соблюдаются ли установленные метрики, требования и стандарты качества, а также выявить причины и способы устранения неудовлетворительного исполнения. Для этого мы заполняем три шаблона документов:

1. Измерения контроля качества, к помощью которого мы фиксируем соответствие продукта и выполненной работы нашим метрикам качества, и, при необходимости, запускаем процесс профилактических и корректирующих действий.
2. Акт приёмки результатов, с помощью которого формально принимаются результаты соответствующие изначальным требования, либо запускается процесс исправления дефектов.
3. Отчёт о контроле качества. А это тот самый документ, который позволяет улучшить систему управления качеством проектов в целом по компании. С помощью него мы выявляем с одной стороны хорошие и лучшие практики, с другой – узкие места и недостатки, и на основании этого вырабатываем рекомендации по улучшению качества проектов.

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

Изменения

O! Это самое интересное в проекте. Мир меняется. Меняется с огромной скоростью. Соответственно, внешнее окружение проекта часто меняется быстрее, чем происходят изменения в самом проекте.

Именно в процессе управления изменениями скрывается успешность проектов. Но это лирика, относящиеся к управлению проектом, а что касается документирования проекта, то на протяжении всего проекта, необходимо регистрировать Запросы на изменения в Реестре изменений, оценивать их с точки зрения содержания, ресурсов, сроков, стоимости, качества и рисков, оценивать их влияние и пользу, а также получать одобрение на их реализацию.

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

Запрос на изменение может оформить любой участник проекта. В первоначальном заполненном варианте он включает:

• Описание запроса
• Рекомендуемый приоритет
• Предполагаемое влияние на проект

Далее, после анализа запроса, выносится резолюция: одобрить, вернуть на доработку или отклонить.

Каждый запрос на изменения параллельно вносится в таблицу Реестра изменений:

Где:

• Изменение – формально задокументированный Запрос на изменение, т.е. запрос на увеличение или уменьшение содержания проекта, изменение стратегий, процессов, планов или процедур, изменение цен или бюджетов или пересмотр расписаний.
• Инициатор – Ф.И.О. и контактные данные лица, инициировавшего Запрос на изменение. Такие запросы может подать любая заинтересованная сторона, вовлеченная в проект. Хотя изменения могут быть инициированы устно, они обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями и/или управления конфигурацией.
• Тип – запросы могут быть прямыми или косвенными, инициированными извне или изнутри, необязательными или обязательными по закону или контакту, а также могут включать в себя корректирующее воздействие, предупреждающее действие, исправление дефекта или обновления.
• Приоритет – определяет, на сколько важна реализация данного изменения относительно других изменений.
• Влияние – потенциальное влияние на проект в показателях сроков, стоимости и рисков, а так же изменение правил или процедур проекта, его содержания или качества.
• Дата – дата издания Запроса на изменение указывается с целью обеспечения своевременной обработки всех запросов, что представляет исключительную важность, так как медленные решения могут негативно повлиять на сроки, стоимость или выполнимость изменения.
• Ответственный – Ф.И.О. лица, ответственного за мероприятия по изменениям.
  Как правило, Запросы на изменения обрабатываются менеджером проекта или назначенным членом команды в соответствии с системой управления изменениями.
• Статус – текущее состояния Запроса на изменение. Обновления статуса показывают, что изменения одобрены, отклонены, отправлены на доработку или реализованы.

Если в компании существует информационная система управления проектами, то этот процесс можно легко автоматизировать, чтоб Запросы сразу попадали в Реестр. Если нет, то Запросы оформляются в Word, а Реестр ведётся в Excel.

Отчёты обеспечивают заинтересованных участников проекта, в том числе спонсора проекта, менеджера проекта и команду проекта, точным и актуальным описанием хода выполнения проекта.

В проектном управлении применяется модель DIKW (data, information, knowledge, wisdom) — информационная иерархия, где каждый уровень добавляет определённые свойства и ценности к предыдущему уровню:

• В основании находятся данные.
• Информация добавляет контекст.
• Знание добавляет ответ на вопрос «как?» (механизм использования).
• Мудрость добавляет ответ на вопрос «когда?» (условия использования).

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

• Данные об исполнении работ — «сырые» наблюдения и измерения, выявленные в ходе выполнения работ проекта. Например: процент физически завершённых работ; измерения технического исполнения; даты начала и окончания плановых операций; количество запросов на изменения; количество дефектов; фактические затраты; фактические длительности. О Данных я рассказывал в статье “Документирование проекта во время исполнения”.
• Информация об исполнении работ. Данные об исполнении работ анализируется и интегрируются на основании взаимосвязей между различными областями/этапами проекта. Например: статус результатов; статус реализации запросов на изменения; прогнозы до завершения.
• Отчёты об исполнении работ — физическое или электронное представление Информации об исполнении работ, предназначенное для принятия решений, освещения вопросов и проблем, выработки действий или осознания ситуации. Например: отчёты о статусе; обоснования; информационные записки; «приборные панели» проекта; рекомендации и обновления.