Данный материал написан на основании открытого вебинара Т. Федорука "How to close projects and take lessons forward for current projects."

Группа процессов закрытия в PMBoK — как бедный родственник. В этот раздел "книги знаний управления проектами" заглядывают редко, да и информации там всего на пару абзацев. Собственно вся группа процессов состоит из одного процесса "Закрытие проекта или фазы".

В 7-м издании PMBoK структура книги изменилась, так что теперь группа процессов закрытия несколько неявным входит в домен исполнения "Работа проекта", но она там есть.

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

• процесс закрытия довольно простой, не требует больших ресурсов на внедрение, он дополняет, а не меняет устоявшие практики (согласно принципам Канбан метода — начните с того что есть, и постепенно улучшайте)

• польза от него может быть не очевидной в моменте, но хорошой заметной в среднесрочной и долгосрочной перспективах

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

Цель процесса закрытия проекта и ключевые выгоды, как следует из PMBoK:

• обеспечение архивирования информации о проекте или фазе

• завершение запланированных работ

• высвобождение ресурсов организации для участия в новых начинаниях

Какие же практики и артефакты используются в процессе закрытия проекта или фазы?

Сбор данных от внешних заинтересованных лиц

На данном этапе мы собираем обратную связь от заказчика — ключевых заинтересованных лиц с его стороны. Как они оценивают завершенный проект, общий уровень сотрудничества с компанией, что понравилось или вызвало негативную реакцию. Удобно это делать в форме короткого опросника, например в Google Forms, состоящего из наскольких вопросов. Делать слишком большой опросник, больше 3-4 пунктов, не советую — есть риск что клиент вообще не станет его заполнять. Лучше дать ему возможность высказать любые подробности в отдельном текстовом поле, если сочтёт нужным.
Популярный формат опросника — 3 вопроса:

1. Как вы оцените завершенный проект? (Или последний раунд сотрудничества, зависит от того как часто вы хотите собирать обратную связь) — Оценка от 1 до 10

2. Почему вы поставили такую оценку? — Текстовое поле

3. Порекомендуете ли своим коллегам или партнерам нашу компанию для сотрудничества? — Оценка от 1 до 10
   Этот вопрос по сути является сбором метрики NPS — Net Promoter Score.

   Что такое NPS

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

Сбор данных от команды проекта

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

1. Эффективность внутрикомандной работы

2. Эффективность внешнего взаимодействия — заказчик, руководство, субподрядчики

3. В какой мере мы как команда реализовали ожидания заказчика

4. В какой мере мы как команда достигли целей проекта

5. Доставлены ли заказчику все необходимые компоненты поставки (deliverables)

6. Общее качество нашей работы как команды

Для простоты можно шкалу оценок сделать аналогичной клиентской, от 1 до 10.

Ретроспективная сессия с командой проекта.

Строго говоря, это правильнее было бы назвать Post-mortem анализ. Условная разница между ретроспективой и пост-мортем (посмертным) анализом — первая проводится во время работы над проектом и предложенные улучшения внедряются сразу же, второй — проводится после завершения работы, и выходом являются не локальные улучшения, а скорее вынесенные уроки (Lessons learned), которые должны быть сохранены в общей базы и могут быть использованы в масштабах всей компании для улучшения процессов.

Рекомендации для проведения сессии следующие:

• рассматриваем весь проект целиком

• все желающие должны иметь возможность высказаться и быть услышанными, у всех равные права

• руководитель проекта (или иной фасилитатор) старается сохранить позитивный настрой команды, не допускать споров или поисков виноватых на сессии. Говорить можно всё, но ретро — не место для персональных негативных фидбэков (если таковые есть, давать их нужно не публично), команда должна разойтись вдохновленной и готовой к новым свершениям

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

Для проведения сессии можно использовать формат встречи Open -> Navigate -> Close.

Open — приветствие, можно использовать какие-то ice breakers для создания открытой неформальной обстановки, даём контекст встречи: общий обзор завершенного проекта, можно сделать короткую презентацию по уставу проекта, если таковой имеется. Озвучить цели проекта, ограничения, допущения, основные этапы.
Navigate — фасилитируем обсуждение, можно показать таймлайн проекта или основые вехи, может быть даты поставки основных компонент, и просим по очереди высказаться о проекте. Можно попробовать использовать какой-нибудь тул для предварительного сбора мнений от команды (в т.ч. анонимного), например easyretro.io Если команда достаточно большая, можно попробовать для упорядочивания обсуждения использовать какие-то техники из Liberаtion Structures
Close — совместно формулируем вынесенные уроки (lessons learned), фиксируем фидбэки от членов команды (придерживаемся позитивного тона, или хотя бы конструктива), благодарим команду за работу. Пицца, пиво, все довольны ))

Организация собранных данных

Отчет о закрытии проекта (Close-out report)

На основании собранных с опросников и ретро-сессии данных составляем главный документ процесса — Отчет о закрытии (Close-out report). Хорошо если есть Устав проекта — можно использовать этот документ как основу для отчета, описывая в прошедшем времени сделанную работу, полученные результаты и т. п. И обязательно добавляя аналитику — достигнута ли цель проекта и в какой степени, какие риски сработали, насколько успешными были стратегии смягчения рисков, собранные метрики на проекте, успехи / неудачи / вынесенные уроки и тому подобное. Здесь пригодятся все имеющиеся документы проекта — реестр рисков, журнал изменений, журнал истории проекта, отчеты о поставках, бизнес-документы.

Хранилище выученных уроков (Lessons learned repository)

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

Для структурирования выученных уроков можно использовать следущие категории:

• Область знания. Некоторые используют для этого прямой копипаст Областей знаний из PMBoK:
  - Project Integration
  - Project Scope
  - Project Schedule
  - Project Cost
  - Project Quality
  - Project Resources
  - Project Communications
  - Project Risks
  - Project Procurement
  - Project Stakeholders

• Краткое описание проблемы и решение

• План действий по внедрению решения

• (опционально) Ключевые слова, кодовое название проекта и т. п.

Формализация завершения проекта

Финальный отчет заказчику

Отправляем заказчику финальный отчет, включающий:
- цели проекта
- достигнутые результаты
- критерии успешной приемки и завершения (success / exit criteria)
- перечень поставляемых компонент и/или адрес где они находятся

Внутреннее информационное письмо о завершении проекта

Часто бывает ситуация, когда о новых проектах информирование сотрудников успешно налажено, а вот о закрытии проектов сообщают редко. В информационном письме перечисляем членов проектной команды, благодарим всех за хорошую работу, можно приложить благодарственные письма от заказчика если таковые имеются. Этим письмом вы уведомляем о высвобождении ресурсов, используемых в проекте (сотрудники, инфраструктура, другие ресурсы).
Данное письмо также подводит некую логическую финальную черту для сотрудников, принимавших участие в проектах. Это достаточно важный аспект с психологической точки зрения, сильно влияющий на дальнейшую мотивацию сотрудников - ощутить логическое завершение проделанной работы, услышать благодарность за потраченные усилия и внутренне собраться для следующего этапа/проекта.
Адресаты — в зависимости от размера и структуры компании. В небольших компаниях до 250-300 человек, по моему мнению, есть смылс рассылать такие письма на всех. Если больше, можно ограничиться отделом или департаментом, включив туда отделы продаж, маркетинга, руководство.

Архивация проектной документации

Обычная формальность — помечаем как заархивированные пространства в Confluence, архивируем документы на дисках Google, закрываем каналы или группы в используемых мессенджерах, закрываем проект в Jira и так далее.

Использование накопленных знаний

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

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

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

В завершение финальный чеклист для проверки корректности завершения проекта:

• Форма обратной связи для заказчика создана и отправлена

• Форма обратной связи для команды создана и разослана

• Ретро-сессия (post-mortem анализ) проведена с командой, выученные уроки внесены в хранилище

• Отчет о закрытии проекта (Close-out report) написан

• Финальный отчет клиенту отправлен

• Внутреннее информационное письмо о завершении проекта разослано

• Проектная информация заархивирована