Управление проектами.-7

Глава 3

РУКОВОДСТВО К CВОДУ ЗНАНИЙ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ PMBOK® (PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMI)

Руководство к своду знаний по управлению проектами (A Guide to the Project Management Body of Knowledge — руководство PMBOK®) представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Стандарт — официальный документ, в котором описываются

установленные нормы, методы, процессы и практики.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Как и в других профессиональных областях, свод знаний опирается на передовой опыт специалистов-практиков в управлении проектами, которые внесли вклад в разработку данного стандарта [7]. Ниже приводятся краткие сведения основных областей знаний управления проектами, групп процессов управления (рис. 3.1), понятия и определения из этого стандарта.

Рис. 3.1 – Процессы и основные функции УП

3.1 Управление интеграцией проекта

Управление интеграцией [7] включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и действий по управлению проектом в рамках групп процессов управления проектами (рис. 3.2).

Рис. 3.2 – Интеграция основных функций управления проектами

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

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

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

2.Разработка плана управления проектом — процесс документирования действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов.

3.Руководство и управление исполнением проекта — процесс исполнения работ, определенных в плане управления проектом, для достижения целей проекта.

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

5.Осуществление общего управления изменениями — процесс проверки всех запросов на изменение, их утверждения и управления изменениями результатов, активов процессов организации, документов проекта и плана управления проектом.

6.Завершение проекта или фазы — процесс завершения всех операций всех групп процессов.

3.1.1 Разработка Устава проекта

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Разработка Устава проекта — это процесс разработки докумен-

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

Глава 3. Руководство к Cводу знаний по управлению

64проектами PMBOK® (Project Management Body of Knowledge, PMI)

•назначение или обоснование проекта;

•измеримые цели проекта и соответствующие критерии успеха;

•требования, описание проекта и риски высокого уровня;

•сводное расписание контрольных событий; сводный бюджет;

•требования к одобрению проекта (что составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает проект);

•назначенный менеджер проекта, уровень ответственности и полномочий; имя и полномочия спонсора или другого лица (лиц), утверждающего Устав проекта.

Рис. 3.3 – Структура процесса «Инициация проекта»

3.1.2 Разработка плана управления проектом

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Разработка плана управления проектом — это процесс докумен-

тирования действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

План управления проектом определяет, как будет исполняться проект, как будет проводиться его мониторинг, контроль и закрытие.

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

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

•выбранный для проекта жизненный цикл и процессы управления, которые будут применяться в каждой фазе;

ководство и управление исполнением проекта требует реализации одобренных изменений: корректирующее воздействие; предупреждающее действие; исправление дефекта.

3.1.4 Мониторинг и управление работами проекта

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Мониторинг и управление работами проекта — это процесс от-

слеживания, проверки и регулирования исполнения для достижения целей исполнения, определенных в плане управления проектом.

Мониторинг — это аспект управления проектом, осуществляе-

мый на протяжении всего проекта.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

•сравнение фактического исполнения проекта с планом управления проектом; оценка исполнения с целью рекомендации корректирующих или предупреждающих действий;

•выявление новых рисков и анализ, отслеживание, мониторинг существующих рисков проекта и исполнения планов реагирования;

•поддержание точной, своевременно обновляемой информационной базы относительно продуктов проекта и сопутствующей документации на всем протяжении выполнения проекта;

• предоставление прогнозов, позволяющих корректировать информацию о текущей стоимости и текущем расписании; мониторинг реализации изменений по мере их появления.

3.1.5 Осуществление общего управления изменениями

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Осуществление общего управления изменениями — это процесс

проверки всех запросов на изменение, их утверждения и управления изменениями результатов, активов процессов организации, документов проекта (рис. 3.4) и плана управления проектом.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Общее управление изменениями проводится с самого начала проекта и вплоть до его завершения.

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

•оказание влияния на приведение в исполнение только одобренных изменений; своевременный обзор, анализ и управление ими;

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

•документирование полного воздействия запросов на изменение.

3.1.6 Завершение проекта или фазы

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Завершение проекта — это процесс завершения операций всех

групп процессов управления проектом в целях формального завершения проекта или фазы.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

•для удовлетворения критериев завершения или выхода для проекта;

•передачи продуктов, услуг, результатов проекта в следующую фазу или в производство и/или операционную деятельность;

Глава 3. Руководство к Cводу знаний по управлению

68проектами PMBOK® (Project Management Body of Knowledge, PMI)

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

3.2 Управление содержанием проекта

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

1.Сбор требований — процесс документирования потребностей заинтересованных сторон проекта для достижения целей проекта.

2.Определение содержания — процесс разработки подробного описания проекта и продукта.

3.Создание иерархической структуры работ (ИСР) — процесс разделения результатов проекта и работ проекта на более мелкие элементы, которыми легче управлять.

4.Подтверждение содержания — процесс формализованной приемки завершенных результатов проекта.

5.Управление содержанием — процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию. В контексте проекта термин «содержание» может обозначать:

•содержание продукта — свойства и функции, которые характеризуют продукт, услугу или результат;

•содержание проекта — работы, которые необходимо выполнить для создания продукта, услуги или результата с указанными характеристиками и функциями.

Процессы, используемые для управления содержанием проекта, а также вспомогательные инструменты и методы различаются в зависимости от прикладной области и обычно определяются как часть жизненного цикла проекта. Одобренное подробное описание содержания проекта вместе с ИСР и словарем ИСР представляют собой базовый план проекта по содержанию. Далее содержание, оформленное в базовом плане, отслеживается, подтверждается и контролируется на всем протяжении жизненного цикла проекта.

3.2.1 Сбор требований

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Сбор требований — процесс определения и документирования по-

требностей заинтересованных сторон проекта для достижения целей проекта.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

На успех проекта напрямую влияет тщательность сбора и управления требованиями к проекту и продукту. Сбор требований представляет собой определение

ожиданий заказчика и управление ими. Требования становятся базой для ИСР. Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта и в Реестре заинтересованных сторон проекта.

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

•Мозговой штурм. Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту.

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

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

•Диаграмма сходства. Метод позволяет отсортировать по группам большое количество идей для их анализа.

Элементы документов по требованиям могут включать в себя:

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

•цели бизнеса и проекта для возможности контроля;

•функциональные требования, описывающие бизнес-процессы, взаимодействие с продуктом, которые могут быть документированы в текстовой форме в списке требований;

•нефункциональные требования, такие как уровень обслуживания, производительность, безопасность, надежность, соответствие нормам, наличие технической поддержки, длительное использование/чистка;

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

3.2.2 Определение содержания

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Определение содержания — процесс разработки подробного опи-

сания проекта и продукта. Основывается на основных результатах, допущениях и ограничениях, документированных во время инициации проекта.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Содержание проекта определяется во время планирования (рис. 3.5) и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты; дополнительные риски, допущения и ограничения добавляются по мере необходимости.

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

врамки проекта. Детальное описание содержания проекта включает в себя:

•Описание содержания продукта последовательно уточняет характеристики продукта, услуги или результата, описанного в Уставе проекта или в документах по требованиям.

•Критерии приемки продукта — определение процесса и критериев приемки завершенных продуктов, услуг или результатов.

•Результаты проекта включают как выходы, содержащие продукт или услугу проекта, так и отчеты, и документы по управлению проектом.

•Исключения проекта — описание того, что не входит в содержание проекта, помогает управлять ожиданиями заинтересованных сторон.

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

Рис. 3.5 – Структура процесса «Планирование содержания»

3.2.3 Создание иерархической структуры работ (ИСР)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Создание иерархической структуры работ — это процесс разде-

ления результатов проекта и работ по проекту на более мелкие элементы, которыми легче управлять.

Иерархическая структура работ — это ориентированная на ре-

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .