Закрытие проекта в результате дополнения предполагает что
Процесс закрытия проекта и его составляющие
Тема 10. Закрытие проекта
1)Сущность закрытия проекта;
2)Процесс закрытия проекта и его составляющие.
Сущность закрытия проекта
Одна из основных особенностей проекта – временный его характер, т.е. проект когда-то должен закончиться. Желательно, чтобы он завершился успешно: заказчик доволен, команда проекта получила премию. Команда проекта упорно и серьезно работает, чтобы были достигнуты поставленные перед нею цели.
Иногда окончание проекта бывает досрочным, когда принимается решение прекратить проект до его завершения по графику (например, по причине изменения рыночной ситуации; просчетов при планировании и в ходе выполнения проекта; возникновении условий, которые делают продолжение проекта бесполезным).
Процессы закрытия проекта – финальные процессы в ходе управления проектом.
Закрытие проекта– стадия процесса управления проектом, результатом которой является подтверждение и документальное оформление завершения всех работ проекта и окончательное разрешение всех спорных вопросов.
При закрытии проекта его руководитель должен выполнить ряд управленческих мероприятий, содержание которых зависит от характера и предметной области проекта.
Если в проекте использовалось оборудование, необходимо произвести его инвентаризацию и, возможно, передать его для нового применения.
В контрактном проекте необходимо определить, удовлетворяют ли результаты условиям контракта; составить окончательные отчеты, а промежуточные отчеты по проекту организовать в виде архива.
Процессы закрытия проекта должны обеспечить формальное авторизованное завершение проекта.
Основными задачами процессов закрытия проекта являются:
1) сдача-приемка результатов проекта заказчику;
2) подготовка и передача проектной документации, оценка ее качества и полноты;
3) разрешение спорных и конфликтных вопросов;
4) утверждение и архивирование результатов проекта для будущего использования;
5) документирование и анализ опыта;
6) извлечение уроков и обмен опытом;
7) оценка работы членов проектной команды, распределение поощрений;
8) роспуск команды проекта, возвращение персонала по подразделениям;
9) помощь в переводе персонала на другие проекты или должности.
Одной из важнейших управленческих задач менеджера проекта является извлечение уроков из прошедшего проекта. Это важно не только для него и команды проекта (необходимо, чтобы эти выводы стали доступны другим участникам проектного управления в организации, в частности менеджерам профильных проектов).
В некоторых компаниях в ходе закрытия проекта менеджер проекта обязан подготовить презентацию по итогам проекта и провести внутреннюю учебу с менеджерами проектов по теме «Уроки моего проекта».
Презентация имеет строгую структуру и шаблон.
Основными информационными блоками такой презентации являются:
— сложности, проблемы и риски, с которыми столкнулись проект и команда;
— способы, технологии и инструменты, с помощью которых сложности проекта были преодолены;
— основные выводы и рекомендации по итогам проекта, «уроки проекта».
Процесс закрытия проекта и его составляющие
В общем виде процессы закрытия проекта представлены на рисунке 1.
Рисунок 1 – Процессы закрытия проекта
Закрытие проекта или фазы
Целью процесса закрытия проекта или фазы является обеспечение четкого, авторизованного прекращения работ по проекту или фазе и формальной передачи результатов и продукта проекта заказчику.
Все процессы проекта, как содержательные, так и управленческие, должны быть проверены на соответствие их результатов предъявляемым требованиям.
Временные проектные структуры и системы должны быть закрыты и разобраны, команда распущена.
Закрытию может быть подвержен весь проект или его фаза. Результаты выполнения фазы проекта также проверяют на соответствие плану проекта. Заказчик осуществляет приемку промежуточных результатов.
Значительная часть работы в ходе процессов закрытия проекта или фазы – это работа с документами:
— подписание актов сдачи-приемки, ввода в эксплуатацию заказчиком;
— обмен документами – актами выполнения работ, табелями учета рабочего времени, счетами-фактурами и т.п.;
— подготовка архива проекта;
— подготовка и выпуск приказов и распоряжений, формально завершающих проект.
Помимо этого в задачи менеджера проекта входят:
1) сдача результатов заказчику;
2) решение всех спорных и конфликтных вопросов;
3) поощрение отличившихся участников проекта (фазы);
4) наказание или лишение премии;
5) роспуск команды проекта;
6) решение организационных вопросов;
7) организация возврата в подразделения участников проекта;
8) демонтаж (при необходимости) информационной системы управления проектами и иных элементов временной проектной инфраструктуры (офиса, списков рассылки и т.п.).
Результатом процесса закрытия проекта или фазы является обоснованное прекращение работ, сопровождаемое достижением запланированных результатов, подтвержденным всеми необходимыми решениями и документами.
Извлечение уроков и закрытие проекта
Проект – мероприятие уникальное (опыт, приобретаемый в ходе проекта, зачастую тоже является уникальным).
Целью процесса извлечения уроков и закрытия проекта является обеспечение возможностей для использования опыта и знаний, полученных в ходе выполнения проекта, и создание условий для получения выгод от их применения в будущих проектах организации.
Основными задачами в ходе процесса извлечения уроков и закрытия проекта являются:
1) систематизация и обобщение опыта, приобретенного в ходе выполнения проекта;
2) обмен знаниями и полученными уроками между участниками проектов;
3) подготовка итогового отчета по проекту;
4) документирование и анализ полученного опыта;
5) проведение итогового совещания по проекту.
Очень часто в практике проектно ориентированных компаний проводятся итоговые совещания по проекту.
На них обязательно присутствуют все основные заинтересованные лица.
Команде проекта сообщают результаты проекта, заказчик излагает свое мнение по поводу успешности проекта.
Подобным образом явно фиксируется факт, что проект завершен, что списание затрат на проект более не допускается, команда завершает свою работу.
После этого закрытие проекта происходит в более неформальной обстановке (возможно даже – с фуршетом и бокалом вина).
Результатами процесса извлечения уроков и закрытия проекта являются увеличение объема и структуризация знаний и опыта, полученных в ходе выполнения проекта, а также оптимизация среды для их эффективного использования.
Текст книги «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)»
Автор книги: Коллектив авторов
Жанр: Зарубежная деловая литература, Бизнес-Книги
Текущая страница: 10 (всего у книги 46 страниц) [доступный отрывок для чтения: 12 страниц]
Документы проекта, которые могут быть обновлены в результате процесса интегрированного контроля изменений, включают в себя все документы, подверженные процессу формального контроля изменений.
4.6. Закрытие проекта или фазы
Закрытие проекта или фазы – это процесс завершения всех операций всех групп процессов управления проектом в целях формального завершения проекта или фазы. Ключевая выгода данного процесса состоит в предоставлении извлеченных уроков, формальном завершении работ проекта и высвобождении ресурсов организации для участия в новых начинаниях. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 4-12. На рис. 4-13 показана диаграмма потоков данных процесса.
Рис. 4-12. Закрытие проекта или фазы: входы, инструменты и методы, а также выходы
Рис. 4-13. Диаграмма потоков данных закрытия проекта или фазы
При закрытии проекта руководитель проекта рассматривает всю предыдущую информацию, полученную во время закрытия предыдущих фаз, позволяющую удостовериться в том, что все работы по проекту завершены и проект достиг своих целей. Так как содержание проекта определяется планом управления проектом, руководитель проекта производит анализ базового плана по содержанию, чтобы удостовериться, что он выполнен, перед тем как констатировать закрытие проекта. Процесс закрытия проекта или фазы также устанавливает процедуры, исследующие и документирующие причины предпринятых действий, если проект прекращен до завершения. Чтобы достичь в этом успеха, руководитель проекта должен вовлекать в процесс все соответствующие заинтересованные стороны.
Это включает в себя все запланированные операции, необходимые для административного закрытия проекта или фазы, включая пошаговые методики, направленные на:
• действия и операции, необходимые для удовлетворения критериев завершения или выхода для фазы или проекта;
• действия и операции, необходимые для передачи продуктов, услуг или результатов проекта в следующую фазу или в производство и/или операционную деятельность;
• операции, необходимые для сбора записей проекта или фазы, аудита успеха или неудачи проекта, аккумулирования извлеченных уроков и архивирования информации проекта для будущего использования организацией.
4.6.1. Закрытие проекта или фазы: входы 4.6.1.1. План управления проектом
Описан в разделе 4.2.3.1. План управления проектом становится соглашением между руководителем проекта и спонсором проекта, определяющим, что именно составляет завершение проекта.
4.6.1.2. Принятые поставляемые результаты
Описаны в разделе 5.5. Принятые поставляемые результаты могут включать в себя одобренные спецификации продукта, расписки в получении и документы по исполнению работ. Также могут быть включены частичные или промежуточные поставляемые результаты для отмененных проектов или проектов, разбитых на фазы.
4.6.1.3. Активы процессов организации
Описаны в разделе 2.1.4. Активы процессов организации, которые могут оказывать влияние на процесс закрытия проекта или фазы, включают в себя, среди прочего:
• руководящие указания или требования к закрытию проекта или фазы (например, административные процедуры, аудиты проекта, оценки проекта и критерии передачи);
• историческую информацию и базу накопленных знаний (например, записи и документы проекта, всю информацию и документацию по закрытию проекта, информацию о результатах решений по отбору предыдущих проектов наряду с информацией о выполнении предыдущих проектов, а также информацию, полученную при управлении рисками).
4.6.2. Закрытие проекта или фазы: инструменты и методы 4.6.2.1. Экспертная оценка
Экспертная оценка применяется при выполнении операций по административному закрытию. Привлекаемые эксперты подтверждают, что закрытие проекта или фазы производится в соответствии с необходимыми стандартами. Экспертиза может быть получена из различных источников, включая, среди прочего, следующие:
• другие руководители проектов в рамках организации;
• офис управления проектами (ОУП);
• профессиональные и технические ассоциации.
4.6.2.2. Аналитические методы
Описаны в разделе 4.4.2.2. Примеры аналитических методов, используемых при закрытии проекта:
Описаны в разделе 4.3.2.3. Совещания могут быть очными, виртуальными, формальными или неформальными. Участниками могут быть члены команды проекта и другие заинтересованные стороны, вовлеченные в проект или попадающие под его влияние. Типы совещаний, среди прочего, включают в себя обзор извлеченных уроков, совещания групп пользователей, совещания по закрытию проекта и совещания по обзору проекта.
4.6.3. Закрытие проекта или фазы: выходы 4.6.3.1. Передача конечного продукта, услуги или результата
Данный выход относится к передаче конечного продукта, услуги или результата, для производства которого был авторизован проект (или в случае закрытия фазы это относится к промежуточному продукту, услуге или результату данной фазы).
4.6.3.2. Обновления активов процессов организации
Активы процессов организации, которые обновляются в результате процесса закрытия проекта или фазы, включают в себя, среди прочего:
• Файлы проекта – документы, полученные в результате операций проекта, например, план управления проектом, содержание, стоимость, расписание и календари проекта, реестры рисков и другие реестры, документация по управлению изменениями, запланированные мероприятия по реагированию на риски и воздействие рисков.
• Документы закрытия проекта или фазы – документы закрытия проекта или фазы, состоящие из формальной документации, указывающей на завершение проекта или фазы и передачу поставляемых результатов завершенного проекта или фазы, например в группу операционной деятельности или в следующую фазу. Во время закрытия проекта руководитель проекта проводит обзор документов предыдущей фазы, документации по приемке заказчиком из процесса подтверждения содержания (раздел 5.4) и договора (если применимо), чтобы убедиться, что все требования проекта выполнены до окончательного закрытия проекта. Если проект был прекращен до завершения, формальная документация объясняет, почему проект был прекращен, и устанавливает процедуры передачи завершенных и незавершенных поставляемых результатов отмененного проекта другим лицам.
• Историческая информация – историческая информация и информация об извлеченных уроках передается в базу накопленных знаний для использования в будущих проектах или фазах. Сюда может входить информация по проблемам и рискам, а также по успешно примененным методам, которые могут быть использованы в будущих проектах.
5
Управление содержанием проекта
Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект.
На рис. 5–1 представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее:
5.1 Планирование управления содержанием – процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться.
5.2 Сбор требований – процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта.
5.3. Определение содержания – процесс разработки подробного описания проекта и продукта.
5.4 Создание иерархической структуры работ (ИСР) – процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять.
5.5 Подтверждение содержания – процесс формализованной приемки полученных поставляемых результатов проекта.
5.6 Контроль содержания – процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию.
Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний (подробное описание см. в разделе 3 и Приложении А1).
В контексте проекта термин «содержание» может обозначать:
• Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат.
• Содержание проекта. Работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта.
Процессы, используемые для управления содержанием проекта, а также обеспечивающие их выполнение инструменты и методы могут различаться в зависимости от проекта. Базовым планом проекта по содержанию являются одобренная версия описания содержания проекта, иерархическая структура работ (ИСР) и соответствующий словарь ИСР. Базовый план может быть изменен только с помощью формальных процедур контроля изменений и используется как база для сравнения при исполнении процессов подтверждения содержания и контроля содержания, а также других процессов контроля.
Выполнение содержания проекта измеряется относительно плана управления проектом (раздел 4.2.3.1). Реализация содержания продукта измеряется относительно требований к продукту (раздел 5.2). Процессы управления содержанием проекта должны быть хорошо интегрированы с процессами всех остальных областей знаний, чтобы работы проекта привели к созданию заданного содержания продукта.
Рис. 5–1. Общая схема управления содержанием проекта
5.1. Планирование управления содержанием
Планирование управления содержанием – процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления содержанием проекта на протяжении всего проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–2. На рис. 5–3 показана диаграмма потоков данных процесса.
Рис. 5–2. Планирование управления содержанием: входы, инструменты и методы, а также выходы
Рис. 5–3. Диаграмма потоков данных планирования управления содержанием
План управления содержанием – компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), последних одобренных вспомогательных планов плана управления проектом (раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (раздел 2.1.4) и других соответствующих факторов среды предприятия (раздел 2.1.5). Данный план помогает снизить риск расползания содержания проекта.
5.1.1. Планирование управления содержанием: входы 5.1.1.1. План управления проектом
Описан в разделе 4.2.3.1. Одобренные вспомогательные планы плана управления проектом используются для создания плана управления содержанием и оказывают влияние на подход, применяемый для планирования содержания и управления содержанием проекта.
5.1.1.2. Устав проекта
Описан в разделе 4.1.3.1. Устав проекта используется для предоставления контекста проекта, необходимого для планирования процессов управления содержанием. Он предоставляет высокоуровневое описание проекта и характеристики продукта из описания работ проекта.
5.1.1.3. Факторы среды предприятия
Описаны в разделе 2.1.5. Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:
5.1.1.4. Активы процессов организации
Описаны в разделе 2.1.4. Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:
• политики и процедуры,
• историческую информацию и базу накопленных знаний.
5.1.2. Планирование управления содержанием: инструменты и методы 5.1.2.1. Экспертная оценка
Экспертная оценка – это суждение, полученное от знающих и опытных сторон. Экспертное заключение могут давать как группы, так и отдельные лица, имеющие специальное образование, знания, навыки, опыт или подготовку в области разработки планов управления содержанием.
Команды проекта могут участвовать в совещаниях проекта по разработке плана управления проектом. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за какие-либо процессы управления содержанием, и, при необходимости, другие лица.
5.1.3. Планирование управления содержанием: выходы 5.1.3.1. План управления содержанием
План управления содержанием – компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. План управления содержанием – это основной вход процесса разработки плана управления проектом и остальных процессов управления содержанием. Компоненты плана управления содержанием включают в себя:
• процесс подготовки подробного описания содержания проекта;
• процесс, который позволяет создавать ИСР из подробного описания содержания проекта;
• процесс, который определяет, как ИСР будет поддерживаться и одобряться;
• процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта;
• процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений (раздел 4.5).
План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта.
5.1.3.2. План управления требованиями
План управления требованиями – это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Взаимосвязи между фазами, описанные в разделе 2.4.2.1, существенно влияют на порядок управления требованиями. Руководитель проекта выбирает наиболее эффективный тип взаимосвязей для проекта и документирует данный подход в плане управления требованиями. Многие компоненты плана управления требованиями основаны на этом типе взаимосвязей.
Компоненты плана управления требованиями могут включать в себя, среди прочего:
• порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;
• действия по управлению конфигурацией, такие как порядок инициирования изменений продукта, порядок анализа воздействий, их выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений;
• процесс приоритезации требований;
• используемые метрики продукта и обоснование их использования;
• структуру отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания.
5.2. Сбор требований
Сбор требований – процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.
Рис. 5–4. Сбор требований: входы, инструменты и методы, а также выходы
Рис. 5–5. Диаграмма потоков данных сбора требований
На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), в реестре заинтересованных сторон (раздел 13.1.3.1) и в плане управления заинтересованными сторонами (раздел 13.2.3.1).
Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя:
• Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят.
• Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон.
• Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования:
– Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом.
– Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.
• Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем.
• Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект.
• Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту.
5.2.1. Сбор требований: входы 5.2.1.1. План управления содержанием
Описан в разделе 5.1.3.1. План управления содержанием разъясняет то, как команда проекта будет определять, какой тип требований необходимо собрать для проекта.
5.2.1.2. План управления требованиями
Описан в разделе 5.1.3.2. План управления требованиями задает процессы, используемые в рамках процесса сбора требований для определения и документирования потребностей заинтересованных сторон.
5.2.1.3. План управления заинтересованными сторонами
Описан в разделе 13.2.3.1. План управления заинтересованными сторонами используется для понимания требований заинтересованных сторон к коммуникациям и уровня их вовлечения с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований.
5.2.1.4. Устав проекта
Описан в разделе 4.1.3.1. Устав проекта используется для предоставления высокоуровнего описания продукта, услуги или результата, позволяющего разработать детальные требования.
5.2.1.5. Реестр заинтересованных сторон
Описан в разделе 13.1.3.1. Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. Реестр заинтересованных сторон также включает в себя важнейшие требования и основные ожидания заинтересованных сторон, которые они могут иметь в отношении проекта.
Данное произведение размещено по согласованию с ООО «ЛитРес» (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.