Пм бук. Руководство pmbok ОлимпБизнес
 Скачать 4.06 Mb.
|
|
Анализ отклонений. Описан в разделе 4.5.2.2. Анализ отклонений можно исполь- зовать для совершенствования метрик организации путем сравнения плановых показателей с конечным результатом. 4.7.2.3 Совещания Совещания проводятся, чтобы утвердить принятие поставляемых результатов; подтвер- дить соблюдение критериев выхода; формально закрыть договоры; дать оценку удовлетворен- ности заинтересованных сторон; собрать извлеченные уроки; передать знания и информацию по проекту и торжественно отметить успешное завершение проекта. Участниками могут быть члены команды проекта и другие заинтересованные стороны, вовлеченные в проект или попа- дающие под его влияние. Совещания могут быть очными, виртуальными, формальными или неформальными. Виды проводимых совещаний включают в себя: итоговые отчетные совеща- ния, совещания с заказчиком для подведения итогов, совещания по извлеченным урокам и итоговые совещания об успешном окончании проекта. 4.7.3 Закрытие проекта или фазы: выходы 4.7.3.1 Обновления документов проекта В результате закрытия проекта все документы проекта могут быть обновлены и поме- чены как окончательные версии. Особый интерес представляет реестр извлеченных уроков, окончательный вариант которого должен включать в себя информацию по закрытию фазы или проекта. Итоговый вариант реестра извлеченных уроков может включать в себя информацию об управлении выгодами, выводах о точности бизнес-кейса, жизненных циклах проекта и раз- работки, управлении рисками и проблемами, вовлеченности заинтересованных сторон и дру- гих процессах управления проектом. 4.7.3.2 Передача конечного продукта, услуги или результата Поставленные по проекту продукт, услуга или результат могут быть переданы в другую группу или организацию, которые в дальнейшем берут на себя их эксплуатацию, техническое обслуживание и поддержку на протяжении всего их жизненного цикла. Данный выход относится к указанной передаче конечного продукта, услуги или резуль- тата, для производства которого был авторизован проект (в случае закрытия фазы это отно- сится к промежуточному продукту, услуге или результату данной фазы), одной командой дру- гой команде. 4.7.3.3 Итоговый отчет Итоговый отчет представляет обобщающие сведения об исполнении проекта. Он может содержать такую информацию, как: ♦ описание проекта или фазы на уровне обобщения; ♦ цели содержания, использованные критерии для оценки содержания и доказательства того, что критерии завершения проекта были соблюдены; ♦ цели по качеству, критерии, использованные для оценки качества проекта и продукта, фактические даты контрольных событий поставки и проверки и причины отклонений; ♦ цели по стоимости, включая предусмотренные границы диапазона стоимости, факти- ческие показатели стоимости и причины любого отклонения; ♦ сводная проверочная информация о готовом продукте, услуге или результате; . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 116 ♦ цели расписания, включая сведения о том, принесли ли полученные результаты те выгоды, ради которых был предпринят проект. Если выгоды не получены к моменту закрытия проекта, следует указать, в какой мере они были получены, и дать оценку перспектив реали- зации выгод в будущем. ♦ сводная информация о том, как конечный продукт, услуга или результат обеспечили бизнес-потребности, предусмотренные в бизнес-плане; Если бизнес-потребности к моменту закрытия проекта не удовлетворены, следует указать, в какой мере они были удовлетворены, и дать оценку сроков, когда бизнес-потребности будут удовлетворены в будущем. ♦ сводная информация о рисках и проблемах, с которыми пришлось столкнуться в ходе осуществления проекта, и какие меры были приняты для их устранения. 4.7.3.4 Обновления активов процессов организации Обновляемые активы процессов организации включают в себя, среди прочего, следую- щие: ♦ Документы проекта. Документация, оформленная по результатам операций про- екта, например, план управления проектом, документы о содержании, стоимости, расписании и календари проекта, а также документы по управлению изменениями. ♦ Операционные и вспомогательные документы. Документы, необходимые орга- низации для технического обслуживания, эксплуатации и технической поддержки продукта или услуги, поставленных в результате проекта. Это могут быть новые документы или обнов- ленные существующие документы. ♦ Документы закрытия проекта или фазы. Документы закрытия проекта или фазы, состоящие из формальной документации, подтверждающей завершение проекта или фазы и передачу поставляемых результатов завершенного проекта или фазы другим сторонам, напри- мер, в группу операционной деятельности или в следующую фазу. Во время закрытия проекта руководитель проекта проводит обзор документов предыдущей фазы, обзор документации по приемке заказчиком из процесса подтверждения содержания (раздел 5.5) и соглашения (если применимо), чтобы убедиться, что все требования проекта были выполнены до окончательного закрытия проекта. Если проект был прекращен до его завершения, то формальная докумен- тация содержит объяснения, почему проект был прекращен, и устанавливает процедуры пере- дачи завершенных и незавершенных поставляемых результатов отмененного проекта другим сторонам. ♦ Репозиторий извлеченных уроков. Извлеченные уроки и знания, полученные на протяжении всего проекта, передаются в репозиторий извлеченных уроков для использования в последующих проектах. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 117 5. Управление содержанием проекта Управление содержанием проекта включает в себя процессы, требуемые для обеспече- ния того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. Управление содержанием проекта непосредственно связано с определе- нием и контролем того, что включено и что не включено в проект. Управление содержанием проекта включает в себя следующие процессы: 5.1. Планирование управления содержанием – процесс создания плана управления содержанием, документирующего, каким образом содержание и продукта будет определяться, подтверждаться и контролироваться. 5.2. Сбор требований – процесс определения, документирования и управления потреб- ностями и требованиями заинтересованных сторон для достижения целей проекта. 5.3. Определение содержания – процесс разработки подробного описания проекта и продукта. 5.4. Создание иерархической структуры работ (ИСР) – процесс разделения постав- ляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управ- лять. 5.5. Подтверждение содержания – процесс формализованной приемки полученных поставляемых результатов проекта. 5.6. Контроль содержания – процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. На рис. 5–1 представлена общая схема процессов управления содержанием проекта. Про- цессы управления содержанием проекта представляются в виде дискретных процессов с опре- деленными границами, хотя на практике они накладываются и взаимодействуют такими спо- собами, которые не могут быть в полной мере детализированы в Руководстве PMBOK®. . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 118 Рис. 5–1. Общая схема управления содержанием проекта КЛЮЧЕВЫЕ КОНЦЕПЦИИ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ ПРОЕКТА В контексте проекта термин «содержание» может обозначать: ♦ Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат. ♦ Содержание проекта. Работы, которые необходимо выполнить, чтобы получить про- дукт, услугу или результат с заданными свойствами и функциями. Термин «содержание про- екта» иногда включает в себя содержание продукта. Жизненные циклы проекта могут варьироваться в широком диапазоне от предиктивных подходов с одной стороны, и до адаптивного или гибкого подхода с другой. В предиктивном жизненном цикле поставляемые результаты проекта определяются в начале проекта, а управ- ление всеми изменениями в содержании осуществляется последовательно в ходе осуществле- . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 119 ния проекта. В адаптивном или гибком (agile) жизненном цикле поставляемые результаты про- ходят разработку в ходе нескольких итераций, подробное содержание которых определяется и утверждается по отдельности в начале каждой их них. Проекты с адаптивными жизненными циклами предназначены для реагирования на высокий уровень изменений и требуют постоянной вовлеченности заинтересованных сторон. Общее содержание адаптивного проекта разбивается на набор требований, а работа, кото- рая должна быть выполнена, иногда называется бэклогом продукта (журналом незавершенных работ продукта). В начале итерации команда определяет, сколько высокоприоритетных эле- ментов из бэклога могут быть получены во время следующей итерации. Три процесса (сбор требований, определение содержания и создание ИСР) осуществляются для каждой итерации. С другой стороны, в предиктивном проекте указанные процессы исполняются перед началом проекта и обновляются по мере необходимости с использованием интегрированного процесса контроля изменений. В адаптивном или гибком жизненном цикле представители спонсора и заказчика должны быть постоянно вовлечены в проект для предоставления обратной связи о поставляемых результатах по мере их создания и обеспечения того, что бэклог (план незавершенных работ) отражает их текущие потребности. Два процесса (подтверждение содержания и контроль содержания) повторяются для каждой итерации. С другой стороны, в предиктивном про- екте процесс подтверждения содержания осуществляется при поставке каждого поставляе- мого результата или рассмотрении результатов фазы, а процесс контроля содержания является непрерывным процессом. В предиктивных проектах базовым планом проекта по содержанию является одобренная версия описания содержания проекта, иерархическая структура работ (ИСР) и соответствую- щий словарь ИСР. Базовый план может быть изменен только с помощью формальных процедур контроля изменений и используется как база для сравнения при исполнении процессов под- тверждения содержания и контроля содержания, а также других процессов контроля. В проек- тах с адаптивным жизненным циклом для отражения их текущих потребностей используются бэклоги (включая требования к продукту и спецификации пользователя). Реализация содержания проекта измеряется в сопоставлении с планом управления про- ектом, в то время как реализация содержания продукта измеряется в сопоставлении с требо- ваниями к продукту. Понятие «требование» означает по определению условие или характе- ристику, которую должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условия соглашения или другие официально установленные спецификации. Подтверждение содержания – процесс формализованной приемки полученных поставля- емых результатов проекта. Проверенные поставляемые результаты, полученные по результатам процесса контроля качества, являются входом процесса подтверждения содержания. Одним из выходов процесса подтверждения содержания являются принятые поставляемые результаты, приемка которых официально оформлена и одобрена уполномоченной заинтересованной сто- роной. Соответственно, заинтересованной стороне нужно включиться в работу на ранних ста- диях планирования (в некоторых случаях еще при инициации проекта) и предоставить поже- лания в отношении качества поставляемых результатов так, чтобы контроль качества мог дать оценку исполнения и рекомендации необходимых изменений. ТЕНДЕНЦИИ И ВНОВЬ ВОЗНИКАЮЩИЕ ПРАКТИКИ В ОБЛАСТИ УПРАВ- ЛЕНИЯ СОДЕРЖАНИЕМ ПРОЕКТА Требования всегда были предметом особого интереса при управлении проектом и про- должают привлекать все большее внимание специалистов. По мере того как глобальная среда приобретает все более сложный характер, организации начинают понимать, как сле- дует использовать бизнес-анализ для получения конкурентных преимуществ за счет операций . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 120 определения, управления и контроля требований. Мероприятия по бизнес-анализу могут быть начаты до инициации проекта и назначения руководителя проекта. В соответствии с доку- ментом Управление требованиями: практическое руководство (Requirements Management: A Practice Guide) [14], процесс управления требованиями начинается с оценки потребностей, к которой можно приступить в ходе планирования портфеля, планирования программы или в рамках организации отдельного проекта. Выяснение, документальное оформление и управление требованиями заинтересованных сторон проходит в рамках процессов управления содержанием проекта. Тенденции и вновь возникающие практики в области управления содержанием проекта отличаются, среди про- чего, особым вниманием к сотрудничеству со специалистами в области бизнес-анализа с целью: ♦ определить проблемы и выяснить бизнес-потребности; ♦ определить и рекомендовать осуществимые решения по удовлетворению указанных потребностей; ♦ выяснить, документально оформить требования заинтересованных сторон и управлять ими для достижения целей бизнеса и проекта; ♦ создать необходимые условия для успешного производства продукта, услуги или конечного результата программы или проекта [7]. Данный процесс завершается полным удовлетворением требований, что означает пере- дачу продукта, услуги или результата получателю для измерения, мониторинга, реализации и поддержания выгод с течением времени. Роль с ответственностью за проведение бизнес-анализа возлагается на ресурсы, облада- ющие достаточными навыками и экспертными знаниями в области бизнес-анализа. Если для участия в проекте назначен бизнес-аналитик, то относящиеся к требованиям операции входят в сферу ответственности этой роли. Ответственность за обеспечение учета относящейся к тре- бованиям работы в плане управления проектом, а также своевременного исполнения относя- щихся к требованиям операций в пределах установленного бюджета и создание ценности несет руководитель проекта. Отношения между руководителем проекта и бизнес-аналитиком должны носить харак- тер доверительного партнерства. Вероятность успешного завершения проекта будет выше при условии, что руководитель проекта и бизнес-аналитик полностью понимают роли и сферы ответственности друг друга в деле успешного достижения целей проекта. СООБРАЖЕНИЯ ПО АДАПТАЦИИ Поскольку каждый проект является уникальным, руководителю проекта необходимо адаптировать порядок применения процессов управления содержанием проекта. Соображения в отношении адаптации включают в себя, среди прочего, следующее: ♦ Управление знаниями и требованиями. Имеются ли в организации формальные или неформальные системы управления знаниями и требованиями? Какие инструкции должен дать руководитель проекта в области требований для последующего использования в будущем? ♦ Подтверждение и контроль. Имеются ли в организации действующие формаль- ные или неформальные относящиеся к подтверждению и контролю политики, процедуры или инструкции? ♦ Подход к разработке. Использует ли организация гибкие подходы при управлении проектами? Является ли подход к разработке итеративным или инкрементным? Используется ли предиктивный подход? Будет ли продуктивным гибридный подход? ♦ Стабильность требований. Имеются ли в проекте области с нестабильными требо- ваниями? Возникает ли необходимость из-за нестабильности требований использовать упро- . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 121 щенные (lean), гибкие или другие адаптивные методы в период, пока требования не станут стабильными и не будут хорошо определены? ♦ Руководство. Имеются ли в организации формальные или неформальные политики, процедуры и руководящие принципы в области аудита и руководства? СООБРАЖЕНИЯ ДЛЯ ГИБКИХ/АДАПТИВНЫХ СРЕД В проектах с постоянно развивающимися требованиями, с высоким уровнем риска или большой степенью неопределенности во многих случаях на начальной стадии проекта его содержание остается неясным или развивается по мере осуществления. На ранней ста- дии проекта при использовании гибких методов на определение и согласование содержания целенаправленно выделяется меньше времени, чем на организацию процесса непрерывного раскрытия и уточнения требований. Во многих средах с вновь возникающими требовани- ями становится понятно, что между реальными бизнес-требованиями и бизнес-требовани- ями, которые были изначально заявлены, существует определенный разрыв. В этой связи при использовании гибких методов с целью уточнения требований целенаправленно создаются и анализируются прототипы и версии. В результате определение и уточнение содержания про- исходит на всем протяжении проекта. При применении гибких подходов требования форми- руют бэклог. 5.1 Планирование управления содержанием Планирование управления содержанием – процесс создания плана управления содержа- нием, документирующего, каким образом содержание проекта и продукта будет определяться, подтверждаться и контролироваться. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления содержанием проекта на протяжении всего проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–2. На рис. 5–3 показана диаграмма потоков данных процесса. Рис. 5–2. Планирование управления содержанием: входы, инструменты и методы, выходы . Коллектив авторов. «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)» 122 Рис. 5–3. Планирование управления содержанием: диаграмма потоков данных План управления содержанием – компонент плана управления проектом или програм- мой, описывающий, каким образом содержание будет определяться, разрабатываться, отсле- живаться, контролироваться и подтверждаться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (см. раздел 4.1.3.1), последних одобренных вспомогательных планов плана управле- ния проектом (см. раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (см. раздел 2.3) и других соответствующих факторов среды предпри- ятия (см. раздел 2.2). |