Тут недавно возник вопрос, а так ли необходимо закрывать проект, если "все всё понимают". Проектное управление лишь исходит из гипотезы, что понимают не все и не всё, а поэтому давайте зафиксируем, кто кого за что хватал.

В закрытии проекта, в целом, есть два варианта:

• Простой, то есть закрываем проектные задачи и распускаем команду
• Продвинутый или проактивный, когда мы пытаемся как-то проанализировать опыт проекта, сделать из этого выводы на будущее

Простой вариант закрытия проекта

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

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

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

Дальше собираются все заинтересованные лица, как минимум, заказчик и спонсор проекта, руководитель проекта от подрядчика (если есть подрядчик) и в самом простом случае руководитель проекта объявляет, что проект закрыт. С оставшимися проектными результатами есть вариант перевести их на этап после проекта. Но тут надо понимать, что это означает: заказчик сделает это сам, без проектной команды, без руководителя проекта. Обычно так поступают с достижением бизнес-показателей, когда требуется время, и проектную команду (из-за отсутствия проектных задач) никто держать не будет.

Вроде бы два простых шага: подготовиться ко встрече по закрытию проекта и провести её, огласив закрытие проекта. К сожалению, многие заказчики верят, что после такой встречи проектная команда останется и будет что-то доделывать. Есть вариант гарантийных работ, и они также чем-то фиксируются. В целом эта встреча (а лучше до неё) – это ровно то время и место, когда заказчику нужно озвучить все свои опасения, боли по итогам проекта. И тут могут возникнуть варианты:

• Все задачи выполнены, но бизнес-заказчик не доволен результатом, потому что его требования изменились; нужно было вовремя приходить с проектными изменениями, а проект в таком случае всё равно закрывают.
• Все задачи выполнены, но их выполнение не позволило достичь того результата, который мы ожидали; проект всё равно закрывают, поскольку проектный план (надеюсь) подтверждали все вместе.
• По итогам завершения этого проекта бизнес-заказчику требуется сделать ещё пару-тройку проектов; проект закрывают, поскольку его закрытие никак не связано со стартом следующих проектов.

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

Продвинутый вариант закрытия проекта

Если мы ставим перед собой такие задачи, как накопление опыта проектной командой, то полезно ретроспективно рассмотреть:

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

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

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