Финальное документирование проекта

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

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

Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов

Проект считается полностью завершённым, если получены три составляющие:

  1. Создан результат (продукт) проекта, формально передан заказчику и работает (эксплуатируется) у него.
  2. Формально завершены все контракты проекта – т.е. проплачены и получены все деньги, а также всё закрыто по бухгалтерии.
  3. Финализирована ВСЯ документация проекта, как техническая, так и управленческая, и подведены уроки опыта.

При таком подходе, у команды не остаётся “хвостов”. Теперь подробнее.

Финальное документирование результата

Есть неформальное правило в управлении проектами – “Чем больше бумаги, тем чище задница”. Невзирая на гротескную аллегорию, правило работает.

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

Оформляются промежуточные и финальные результаты проекта двумя актами: Акт приёмки результатов, о котором я писал в статье “Документирование контрольных функций проекта”, и Акт приёмки, суммирующий маленькие Акты и подтверждающий, что все необходимые промежуточные результаты проекта прошли проверку и были приняты. Формальное подписание этого Акта сторонами документирует передачу итогов проекта заказчику.

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

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

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

Финальное документирование контрактов

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

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

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

  1. Первоначальные запросы
  2. Предложения поставщиков
  3. Протоколы переговоров
  4. Корреспонденцию по контракту
  5. Подписанные контракты
  6. Счета и платежные поручения
  7. Акты приёмки

Понятное дело, что формируется эта папка документов на протяжение всего проекта, начиная с процессов планирования и проведения закупок. Но во время завершения проекта эта папка проходит финальную “вычитку” – сравнение того, что хотели и что в итоге получили.

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

С результатом и контрактами разобрались, но остаётся ещё жирный “хвост”, который свисает из-под шерсти команды, не до конца задокументировавшей свой проект. Он, конечно, может отсохнуть сам собой, но лучше доделать свою роботу.

Финализация документации и уроки опыта

Невзирая на то, что это мало кто делает в проектах, подведение финальных итогов проекта – это самое полезное, с точки зрения развития опыта команды и зрелости системы управления проектами (СУП). Выражается всё это в двух документах – в Отчёте о завершении проекта и в Уроках опыта.

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

Но это ретроспектива, так сказать, “патологоанатомия” завершённого проекта. Взяли все, выпущенные за время проекта отчёты, проанализировали их, сравнили полученные результаты, сроки и затраты с базовыми планами и всё внесли в итоговый документ. Но самое интересное кроется в развитии Системы УП.

Отвлекусь от документирования проектов и сделаю маленький экскурс в зрелость СУП. Организационная зрелость в управлении проектами разделяется на четыре основных уровня:

  1. Уровень I: В профессиональной деятельности компании установлен и используется профессиональный язык управления проектами. Что означает одинаковое понимание и использование понятийного аппарата и глоссария управления проектами всеми сотрудниками, участвующими в проектах.
  2. Уровень II: Сотрудники, участвующие в проектах, умеют самостоятельно управлять несложными проектами и/или эффективно работать в команде управления комплексными проектами.
  3. Уровень III: Создан пакет процедурно-регламентирующей документации, формализующий методологию управления проектами. Данная методология встроена в систему бизнес-процессов компании.
  4. Уровень IV: Установлены и применяются инструменты устойчивого развития – бенчмаркинг, реинжиниринг бизнес процессов, система управления качеством (с использованием базовых процессов управления проектами ISO10006 или ISO21500).

pmmm

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

Первый уровень зрелости

  1. В компании существует утверждённый глоссарий терминов по управлению проектами.
  2. Данный глоссарий легко доступен всем сотрудникам компании. Все новые сотрудники в обязательном порядке знакомы с данным глоссарием, т.е. HR-департаментом налажен процесс терминологической подготовки сотрудников при приёме на работу.
  3. Все сотрудники компании, прямо или косвенно участвующие в проектах, прошли базовое обучение по управлению проектами. При этом базовый тренинг должен быть изменён с учётом глоссария компании. Инструктор должен на тренинге применять терминологию управления проектами, принятую в компании.

Второй уровень зрелости

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

Третий уровень зрелости

  1. Существует и используется сотрудниками пакет регламентирующих процедур и шаблонов документов для инициации, планирования, исполнения, контроля и завершения проектов.
  2. В компании существует информационная система управления проектами, предоставляющая единое коммуникационное поле проектным командам.
  3. Компания прошла аудит, в результате которого продемонстрировала, что участники проектов используют методологию и информационную систему управления проектами.

Четвёртый уровень зрелости

  1. Налажен процесс внутреннего обучения новых сотрудников компании и новых участников проектов.
  2. Налажен процесс регулярной проверки знаний сотрудниками методологии управления проектами и используемой информационной системы управления проектами.
  3. Налажен процесс подведения уроков опыта каждого завершённого (в том числе и закрытых досрочно) проекта с выработкой рекомендаций и внесением согласованных изменений в методологию и информационные инструменты управления проектами.

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

Шаблоны документов для финализации документирования проекта:

Подведя Уроки опыта, мы замыкаем жизненный цикл проекта, и все знания, генерируемые в процессах реализации проекта, собираются, обрабатываются и используются во всех процессах управления ВСЕМИ проектами в организации.

Итого

С точки зрения документирования, итог закрытие проекта выглядит следующим образом:

  1. Акт приёмки, который формально, юридически завершает проект и переводит результаты проекта из ответственности команды проекта в ответственность команды поддержки.
  2. Завершённые поставки, которые фиксируют всю документацию по поставкам продуктов и услуг да проекта.
  3. Финальный Отчёт о ходе работ и Уроки опыта, которые содержат причины проблем и отклонений, обоснования в пользу выбора того или иного корректирующего воздействия и другие знания, накопленные в процессе реализации проекта. Накопленные знания оформляются в виде документов на протяжении всего жизненного цикла проекта (но обязательно, как минимум, в процессе завершения проекта) для того чтобы стать частью исторической базы данных как для данного проекта, так и для всей компании. Таким образом, указывается, были ли цели проекта достигнуты в запланированные сроки и бюджет. Эти документы являются входной исторической информацией для последующих проектов.

Все статьи цикла “Документирование проекта”, которые по совместительству являются главами будущей книги:

  1. Документирование проекта на старте
  2. Документирование проекта в процессе планирования:
  3. Документирование проекта во время исполнения
  4. Документирование контрольных функций проекта
  5. Финальное документирование проекта
1 ответить

Оставить ответ

Хотите присоединиться к дискуссии?
Не стесняйтесь вносить свой вклад!

Добавить комментарий