Финальной частью этапа выполнения работ является обзор проекта и заполнение документа «Форма обзора». Его стоит проводить всегда, вне зависимости от размера проекта. Форма обзора проекта должна содержать информацию о том, как проект продвигается к завершению, если он имеет проблемы на текущий день, и какие препятствия или риски были устранены. Следует особо отметить, были ли какие-то мероприятия официально запланированы.

Этап «Закрытие»

Мы подошли к завершающей стадии процесса управления проектом, заключительному этапу.

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

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

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

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

На протяжении всего написанного выше в данной главе, можно было заметить фразы «сделать проект успешным», «успешный проект» или «добиться успеха», но я совсем не писал о том, что означает слово «успех» в контексте управления проектами.

В то время как успех проекта в широком смысле определяется, как «обеспечение качественного и одобренного заказчиком результата», приведу далее разбор определения.

Термины «качество» и «одобрение клиента» определяются тремя факторами, между которыми руководитель проекта и проектная команда всегда должны держать проект в балансе между стоимостью, временем и объемом. Проектная команда с руководителем проекта не могут однозначно предсказать стоимость и время, необходимые для реализации проекта, но они действительно могут контролировать его объем. А вот уже исходя из объема можно установить сроки проекта и стоимость. Конечно, это грубое приближение к реальности, но суть верна. Объем определяет, за что отвечает проектная команда и, что не менее важно, за что она не отвечает. Только после того, как объем работ установлен, тогда цели, задачи и сроки могут быть четко определены. Попробую пояснить на примере, так как логика может быть не явно видна. У вас появился новы проект (иногда говорят «зашел» проект), из описания только «хотелки» клиента, а это значит конкретики, что делать и какова область применения (поговорим чуть ниже о ней) нет и, естественно, о сроках речи быть не может. Вы сначала формируете описание проекта, изучив которое можно спрогнозировать, какой может быть функционал проекта и его особенности, сколько может потребоваться времени на реализацию такого функционала (плюс риски), разбить на блоки и составить приблизительный план разработки проекта. После согласования проекта с клиентом можно будет приступить к проработке технического задания, а далее согласовать с клиентом. Функциональные блоки, в свою очередь, разбивают на задачи и подзадачи. Далее следует оценка задач с учетом рисков и временем на проверку, и тестирование. Руководитель проекта собирает их в список, планирует последовательность и расставляет приоритеты, далее следует этап проставления сроков (ведь мы понимаем, что временная оценка не равна сроку, через который будет сдача задачи заказчику). На этом этапе идет проставление сроков реализации с учетом отпусков, других проектов (если сотрудник задействован еще где-то) и рисков на пропуски рабочих дней (отгулы, болезнь и так далее). И вот тут, имея финальный объем работ и ресурсы, руководитель проекта может понять сроки на разработку проекта.