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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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