Чтобы перейти от абстрактных представлений к схеме деятельности, можно воспользоваться моделью соответствия этапов жизненного цикла проекта и групп процессов, выполняемых на этих этапах.
Это соответствие условно и не является догмой для любого проекта. Однако оно дает общее представление о том, как использовать знания о процессах для определения работ на разных стадиях.
Дальнейшее рассмотрение будет строиться именно так: мы будем разбирать области знаний, необходимые для управления проектами, реализуемые в них процессы и их распределение по жизненному циклу.
Управление интеграцией: общий обзор
Первая область знаний —
управление интеграцией (Project Integration Management). Это действия менеджера по объединению всех планов, работ, процессов и задач в единое целое. Например, если автономно планировать архитектуру информационной системы и процедуры её тестирования, то на выходе можно получить продукт, а процесс его проверки займет неоправданно много времени. Интеграция позволяет избежать таких проблем.
В разных стандартах эта область рассматривается по-разному.
Управление интеграцией в PMBOK 2000
В стандарте
PMBOK (Project Management Body of Knowledge, Свод знаний по управлению проектами) версии 2000 года управление интеграцией включает три основных процесса. Они не привязаны жестко к одному этапу жизненного цикла и относятся к планированию, исполнению и контролю:
1.
Создание плана проекта. Хотя этот процесс относится к этапу планирования, он выполняется многократно. После запуска проекта происходят сбои и изменения, которые вынуждают перепланировать и корректировать планы в течение всего проекта.
2.
Исполнение плана проекта. Организация выполнения запланированных работ.
3.
Интегрированный контроль изменений. Все изменения в проекте должны синхронизироваться и объединяться по содержанию.
Рассмотрим эти процессы детальнее. Для каждого будет использоваться схема: входные данные (исходная информация), содержание процесса (действия) и выходные данные (результаты).
Процесс 1. Создание плана проекта
План проекта создается на основе:
• результатов планирования по частным областям;
• опыта команды проекта.
Это происходит благодаря использованию методологий планирования, навыков сотрудников, информационной системы управления проектами и методики освоенного объема.
На выходе получается
план проекта — это не один документ, а множество согласованных по содержанию и синхронизированных по времени документов. Примерный состав плана включает несколько блоков.
1.
Документы, определяющие общие характеристики: Устав проекта, стратегия управления, описание содержания и рамок проекта.
2.
Документы, описывающие конкретные работы:
o
Иерархическая структура работ (ИСР) — описание всего комплекса работ.
o Для существенных этапов определяются
контрольные точки, для которых задаются: стоимость, результат, ответственный, конкретные документы или материальные результаты.
3.
Базовый план. Определяет порядок исполнения проекта и его ключевые контрольные точки. Он составляется один раз и может изменяться только по решению уполномоченных органов. Менеджер проекта не имеет права менять базовый план, его задача — исполнить его, варьируя оперативные планы.
4.
Частные планы по отдельным аспектам управления (рисками, содержанием, персоналом и т.д.).
Метод разработки плана: «бегущая волна»
Разработать детальный план для всего проекта сразу невозможно. Это аксиома. Поэтому используется метод
«бегущей волны»: уровень детализации зависит от того, насколько скоро начнется фаза работ.
•
Детальный план (до уровня конкретных операций) составляется только для ближайшей фазы.
•
Менее подробный план — для следующей фазы (выделяются только пакеты работ).
•
План верхнего уровня (только фазы) — для отдаленного будущего.
Это позволяет на старте определить общие сроки и стоимость проекта, которые затем будут уточняться.
Виды планов по времени создания
1.
Предварительный план. Создается менеджером на этапе до начала проекта. Носит общий характер и служит для принятия решения о целесообразности запуска проекта.
2.
Базовый план. Основа для исполнения проекта.
3.
Рабочий (текущий) план. Оперативные планы, которыми менеджер может управлять для обеспечения исполнения базового плана.
Правила разработки реалистичного плана
Чтобы план был реалистичным и исполнимым, нужно соблюдать следующие правила.
• Назначение ответственного. За каждую часть работы должно быть назначено конкретное ответственное лицо из команды проекта. Это фиксируется в
матрице ответственности — документе, в компактной форме показывающем, кто за что отвечает.
• Коллективная разработка. Базовый план проекта не должен разрабатываться менеджером в одиночку. Это результат творчества всего коллектива. Это привносит знания разных участников, делает план объективнее и создает эффект соучастия: люди, участвовавшие в планировании, берут на себя моральную ответственность за его исполнение.
• Формальное согласование. Разработанный план официально согласовывается с заказчиком и спонсором, что обычно завершается подписанием документов.
В результате такого подхода можно добиться принятия обязательств по плану на моральном уровне от каждого члена команды и зафиксировать контрольные события для отслеживания прогресса.
Процесс 2. Исполнение плана проекта и авторизация работ
Процесс исполнения плана опирается на навыки общего менеджмента и знание продукта (предметной области). Без них менеджер не сможет эффективно организовать и контролировать работу.
Ключевой элемент —
авторизация работ. Это правила, по которым инициируются и запускаются действия в проекте. Основное средство авторизации —
наряд на работу.
Наряд должен быть эффективным и полезным документом, содержание которого варьируется в зависимости от задачи. Типовой наряд включает:
• Понятное исполнителю описание работы.
• Место работы в иерархической структуре работ (ИСР).
• Возможные (допустимые) затраты и шифры для их списания.
• Место для подписи должностного лица, запускающего работу, и лица, ответственного за её выполнение.
Содержание наряда должно быть адаптировано под задачу. Для прокладки кабельной сети крайне важно приложить схему, чтобы не повредить существующие коммуникации. Для закупки материалов — акцентировать внимание на финансовых параметрах. Шаблон — это руководство, а не догма.
Процесс 3. Интегрированный контроль изменений
Реальное исполнение проекта никогда полностью не соответствует плану. Поэтому критически важно управлять возникающими изменениями по формальным правилам, чтобы не разрушить логику проекта.
Для контроля менеджер использует системы управления проектами (например, Spider, Microsoft Project). В них базовый план отображается как эталон (например, серым фоном), на который накладываются фактические результаты. Это позволяет визуально оценить, идет ли объем работ по графику. Однако это не отвечает на вопрос, насколько хорошо исполняется план — это более сложный анализ.
Для сбора фактических данных менеджер в рамках
управления коммуникациями создает правила отчетности. Эти правила должны обеспечивать поступление информации об изменениях в содержании, календарном плане, стоимости, качестве, рисках и снабжении проекта.
На основе этой информации и осуществляется
интегрированный контроль изменений. Эта процедура включает:
1.
Установление правил внесения изменений в проектную документацию.
2.
Управление конфигурацией создаваемого продукта.
3.
Управление изменениями, которое ведет к перепланированию.
На выходе процесса появляются:
• Обновленные планы проекта.
• Корректирующие воздействия для приведения работ и продукта в соответствие с планом.
• Извлеченные уроки — анализ причин отклонений для их предотвращения в будущем.
Для всего этого необходимы:
• формальные правила внесения изменений;
• регламент изменения официальных документов;
• уполномоченный орган для принятия решений об изменениях —
комитет по управлению изменениями (в малых проектах это может быть один человек);
• критерии для отнесения ситуации к одному из двух вариантов: либо требуется корректирующее воздействие менеджера (чтобы войти в рамки базового плана), либо нужно изменение, требующее решения комитета.
Управление конфигурацией — это отдельная часть, касающаяся не деятельности, а продукта. Она включает:
• фиксацию целевых характеристик продукта;
• контроль этих характеристик у создаваемых элементов;
• проверку соответствия результатов требованиям;
• принятие решения о необходимости изменений в продукте.
Эволюция стандарта: PMBOK 2004
В версии PMBOK 2004 управление интеграцией рассматривается шире — как основа для всех процедур проекта. Вместо трех процессов здесь их семь. Ключевые дополнения касаются этапа инициации:
• Разработка Устава проекта.
• Разработка предварительного описания содержания проекта. В версии 2000 года этот этап фактически отсутствовал. Его появление признало необходимость детального предварительного анализа перед запуском проекта. Это позволяет объективнее оценивать будущие затраты и ресурсы, что делает проект более прогнозируемым и эффективным.
Таким образом, общая схема управления интеграцией по PMBOK 2004 выстраивается в логическую цепочку, охватывающую весь проект от начала до завершения:
1.
До начала / на этапе инициации:
o Разработка Устава.
o Разработка предварительного описания содержания.
2.
В процессе исполнения:
o
Разработка плана управления проектом. Запускает детальное планирование по всем областям знаний.
o
Руководство и управление исполнением проекта. На основе планов создаются конкретные результаты, фиксируемые в отчетности.
o
Мониторинг и управление работами проекта. Сравнение факта исполнения с базовым планом и принятие оперативных решений.
o
Общее управление изменениями. Обработка возникших изменений, которая ведет к корректировке планов и характеристик проекта.
3.
На этапе закрытия:
o
Закрытие проекта. Финальный процесс.
Краткие итоги
Центральная идея заключается в том, что проект не является механической суммой разрозненных планов и действий, а представляет собой единую, взаимосвязанную систему. Управление интеграцией — это та клейкая субстанция, которая соединяет части проекта в целостный организм, и роль менеджера здесь не просто административная, а архитектурная. Переход от простой модели PMBOK 2000 к расширенной версии 2004 года отражает практический сдвиг в понимании этой роли: интеграция из набора реагирующих процедур трансформировалась в проактивный фундамент, закладываемый с первых мгновений инициации проекта.
Ключевым концептуальным инструментом, обеспечивающим этот фундамент, является иерархия планов, разделенных по назначению и времени создания. Предварительное описание содержания, концепция базового плана как незыблемой конституции проекта и гибкие рабочие планы как тактические маневры — эта триада создает сбалансированную систему, где стабильность стратегических целей сочетается с адаптивностью к неизбежным отклонениям. Метод «бегущей волны» в планировании становится здесь не техническим приемом, а прагматичным признанием неопределенности будущего: инвестировать усилия в детализацию стоит лишь там, где наступила ясность.
Практическая реализация этих идей вращается вокруг двух осей: исполнения и изменений. Первая ось требует от менеджера перенести фокус с общего контроля на точечную авторизацию работ через формальный и одновременно адаптивный наряд на работу. Вторая ось превращает контроль изменений из бюрократической фиксации отклонений в механизм принятия осознанных решений. Через критерии оценки ситуации и работу комитета по изменениям менеджер получает рычаг, позволяющий отличить допустимые корректирующие действия от критических изменений, требующих пересмотра самого базового плана, и тем самым защитить проект от хаоса.
1. Управление интеграцией — ключевая функция менеджера, объединяющая все элементы проекта в единую и согласованную систему.
2. План проекта — это не один документ, а комплекс синхронизированных по содержанию и срокам документов.
3. Детальное планирование всего проекта в начале невозможно, поэтому применяется метод «бегущей волны».
4. Существует три вида планов: предварительный (для оценки жизнеспособности), базовый (неизменный эталон) и рабочие (гибкий инструмент менеджера).
5. Базовый план — это конституция проекта; менеджер не может менять его сам, а лишь адаптирует оперативные планы для его достижения.
6. Реалистичный план создается коллективно, с персональным закреплением ответственности за каждый фрагмент работы.
7. Формальный наряд на работу — основной инструмент авторизации, содержание которого должно быть адаптировано под специфику конкретной задачи.
8. Поскольку проект всегда отклоняется от плана, необходим формальный процесс управления изменениями, а не стихийное реагирование.
9. Критически важно различать управление изменениями в деятельности и управление конфигурацией продукта.
10. Для принятия решений по изменениям нужны четкие критерии, позволяющие отличить корректирующие действия от изменений, требующих одобрения комитета.
11. Переход от PMBOK 2000 к PMBOK 2004 отразил необходимость более глубокого и формализованного анализа на этапе инициации проекта.
12. Разработка предварительного содержания до старта проекта позволяет более объективно оценить параметры проекта и избежать дорогостоящих ошибок.
1. В чем заключается основная задача управления интеграцией в проекте?
2. Почему процесс «Создание плана проекта» является итерационным, а не однократным действием?
3. В чем ключевое различие между базовым и рабочим планами проекта с точки зрения полномочий менеджера?
4. Как метод планирования «бегущей волны» помогает справиться с неопределенностью в долгосрочных проектах?
5. Какие две главные причины требуют коллективной разработки базового плана проекта?
6. Почему содержание наряда на работу должно варьироваться в зависимости от типа поручаемой задачи? Приведите пример.
7. Какую проблему решает создание комитета по управлению изменениями?
8. Опишите разницу между объектами управления в процедурах «управление изменениями» и «управление конфигурацией».
9. Какие ключевые процессы были добавлены в управление интеграцией в версии PMBOK 2004 по сравнению с PMBOK 2000 и почему?
10. Для чего необходимо разрабатывать предварительное описание содержания проекта до его официального старта?
11. На основе какой информации менеджер проекта может определить, что исполнение идет не по плану, и какие действия он должен предпринять?
12. Почему, глядя на график сравнения факта с планом, можно сделать вывод только об объеме выполненных работ, но не об успешности исполнения плана в целом?
