Проекта 1 страница

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

Управление интеграцией проекта включает в себя процессы, необходимые для гарантии того, что различные элементы проекта подходящим образом скоординированы. Это включает нахождение компромисса между конкурирующими предметами и выбор альтернатив, чтобы удовлетворить или превзойти нужды и ожидания стэйкхолдеров. В то время как все процессы управления проектами в той или иной степени интеграционны, процессы, описываемые в этой главе, являются основой интеграции. Рис. 4.1 обеспечивает обзор следующих основных процессов.
4.1. Создание (разработка) плана проекта - сбор результатов прочих процессов планирования и их объединение в согласованный, связный документ.
4.2. Исполнение плана проекта - осуществление плана проекта путем выполнения включенных в него действий (работ).
4.3. Всеобщий контроль изменений - координирование изменений во всем проекте.
Данные процессы взаимодействуют между собой, а также и с процессами из других областей знаний. Каждый процесс может включать усилия одного или нескольких индивидуумов или групп в зависимости от нужд проекта. Каждый процесс обычно встречается, по крайней мере, один раз в каждой фазе проекта.
Хотя процессы и представлены здесь как дискретные элементы с четкими взаимодействиями, на практике они могут пересекаться и взаимодействовать не указанными здесь путями. Взаимодействия между процессами детально описаны в третьей главе.
Процессы, инструментарий и технологии, используемые для интеграции процессов управления проектами, находятся в фокусе данной главы. Например, управление интеграцией проекта вступает в игру в момент, когда стоимостная оценка (смета) требуется для создания плана на случай непредвиденных обстоятельств или когда должны быть определены риски для различных вариантов набора персонала. В то же время для успешного завершения проекта интеграция должна осуществляться ив ряде других областей. Например:
• Деятельность по проекту должна быть интегрирована с основной (постоянной) деятельностью организации-исполнителя.
• Замысел проекта и замысел продукта должны быть интегрированы (разница между этими понятиями обсуждается во введении к пятой главе).
• Результаты деятельности различных функциональных областей (например, строительные, электрические и механические чертежи для инженерного проектирования) должны быть проинтегрированы.

4.1. Создание (разработка) плана проекта.
В процессе разработки плана проекта результаты других процессов планирования используются для создания единого связного документа, который может быть использован как руководство для управления исполнением проекта и для контроля. Разработка плана проекта обычно производится итерационным путем. Например, первоначальный план может содержать только виды ресурсов и не привязанные к календарю операции, а в финальном варианте будут определены конкретные ресурсы и точные даты. План проекта используют чтобы:
• направлять исполнение проекта;
• документировать предположения планирования проекта;
.документировать принятые решения планирования по выбору одной из возможных альтернатив;
• обеспечивать коммуникации между стэйкхолдерами;
•определять ключевые отчеты управления, относящиеся к содержан продолжительности и распределению во времени;
• обеспечивать базовые оценки исполнения и контроля проекта.

4.1.1. Входные данные для создания плана проекта
4.1.1.1. Результаты других процессов планирования. Все результаты процессов планирования в прочих областях являются входными для создания плана проекта (в разделе 3.3 приведен список этих процессов планирования). Результаты других процессов планирования включают как базовые документы вроде структуры декомпозиции видов деятельности, так и вспомогательные детали. Многие проекты также требуют специальных входных данных из прикладной области (например, большинство строительных проектов потребуют прогноза денежных потоков).
4.1.1.2. Историческая информация. Вся доступная историческая информация о проектах данной области (оценочные базы данных, записи выполнения других проектов) дате быть использована в других процессах планирования. Она также должна всегда быть рукой во время создания плана проекта для помощи при оценке предположений и выбор альтернатив, определяемых как части данного проекта.
4.1.1.3. Организационная политика. Любая или все организации, вовлеченные в проект могут иметь писаные и неписаные правила (политику), эффект от которых должен учитываться. Политика организаций, которая обычно должна учитываться, может включать (но не ограничиваться) нижеследующими пунктами.
• Управление качеством - процессы проверки, постоянное улучшение целей.
• Управление персоналом - ведение отчетности по приему на работу и увольнениям, отчеты о производительности труда работников.
• Финансовый контроль - отчеты об использовании времени, требуемые отчеты затратам и выплатам, учетные счета, условия стандартных контрактов.
4.1.1.4. Ограничения. Ограничения - это факторы, ограничивающие возможно команды управления проектом. Например, заранее определенный бюджет с высокой степенью вероятности будет ограничивать возможности команды в отношении замысла, расписан подбора персонала.
4.1.1.5. Предположения. Предположения - это такие факторы, которые для целей планирования будут считаться истинными, правильными или очевидными. Например, если дата, с которой необходимый для проекта человек сможет начать свою деятельность, определена, то команда проекта может предположить некую конкретную начальную дату. В общем случае предположения несут в себе определённую степень риска.

Рис. 4.1. обзор процессов управления интеграцией проекта

4.1.2. Инструментарий и технологии создания плана проекта
4.1.2.1. Методология планирования проекта. Методология планирования проекта - это структурированный подход, используемый для направления деятельности команды проекта во время создания плана проекта. Методы и формы могут быть как простые (стандартные формы и шаблоны, на бумаге или электронные, формальные или неформальные), так и настолько серьезные, как серии требуемого моделирования процессов (как, например, т.н. Анализ календарного риска Монте Карло). Большинство методологий планирования проекта используют сочетание “жестких” инструментов, таких как специальное программное обеспечение, и “мягких” инструментов типа вспомогательных, ранее оговоренных встреч.
4.1.2.2. Навыки и знания стэйкхолдеров. Каждый стэйкхолдер имеет навыки и знания, которые могут быть полезными в создании плана проекта. Команда управления проектом должна создать среду для внесения своей лепты каждым стэйкхолдером (см. также раздел 9.3 - Совершенствование команды). Кто, что внесет и как это будет сделано - все это различается для каждого отдельного случая. Например:
• Встроительный проект, осуществляемый в рамках контракта по единой, разовой цене, профессиональный инженер-экономист вносит основной вклад в дело доходности во время подготовки предложений, когда определяется размер контракта.
• Впроектах с заранее произведенным комплектованием отдельные работники могут значительно повлиять на соблюдение запланированных сроков и стоимости за счет проверки резонности продолжительности и усилий.
4.1.2.3. Информационная система управления проектами (ИСУП). ИСУП является сборником инструментария и технологий для сбора, интеграции и распределения результатов остальных процессов управления проектами. Она используется для поддержки всех аспектов проекта от инициирования до сворачивания и обычно включает как простые, так и автоматизированные системы.

4.1.3. Результаты создания плана проекта
4.1.3.1. План проекта. План проекта - официальный и утвержденный документ используемый для управления и контролирования исполнения проекта. Он должен распределен так, как это определено в плане управления коммуникаций (например, управление исполняющей организации может потребовать общего описания с небольшим количеством деталей, в то время как подрядчик может затребовать подробное описание по единственному предмету, вопросу). В некоторых прикладных областях применяется также термин “интегрированный план проекта”.
Должна быть проведена четкая граница между планом проекта и основой (базой) измерения хода выполнения проекта. План проекта - это документ или набор документов, в отношении которых должно предусматриваться изменение с течением времени по мере того, как становится доступной новая информация о проекте. Основы измерения исполнения проекта представляют собой инструмент управленческого контроля, который в общем случае изменяется незначительно, лишь в результате реакции на утвержденное изменение замысла.

Существует множество путей создания и представления плана проекта, но все они
обычно включают нижеследующие пункты, подробное описание которых можно встретить где угодно.
• Устав Проекта.
• Описание подхода или стратегии управления проектами (сумма индивидуальных планов управления из других областей знания).
• Замысел, который включает основные предметы и цели проекта.
• Структура декомпозиции видов деятельности (WBS) до уровня, на котором будет осуществляться контроль.
• Сметы, календарные даты начала видов деятельности и распределение ответствен на уровнях WBS, на которых будет осуществляться контроль.
• Основа (база) измерения степени исполнения проекта по расписанию и стоимости.
• Основные вехи (этапы) и целевые даты для каждой.
• Ключевой или требуемый персонал.
• Основные риски (включая ограничения и предположения) и планы ответных действий на каждый случай.
• Планы вспомогательного управления, включающие план управления замыслом, план управления расписанием и им подобные.
• Список незакрытых (спорных) тем и неутвержденных решений.
Прочие результаты планирования проекта должны быть включены в формальный план, базируемый на нуждах отдельного проекта. Например, план проекта для большого проекта будет включать схему организации проекта.
4.1.3.2. Вспомогательные (поддерживающие) детали. для плана проекта они состоят из следующих элементов:
• Результатов других процессов планирования, не включенных в план проекта.
• дополнительной информации или документации, полученной во время создания плана проекта (например, ранее неизвестные ограничения и предположения).
• Технической документации - требования, спецификации и дизайны.
• документации по соответствующим стандартам.
Весь материал должен быть соответственно организован для удобства использования по ходу проекта.

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

4.2.1. Входные данные для исполнения плана проекта
4.2.1.1. План проекта. План проекта описывается в разделе 4.1.3.1. Планы вспомогательного управления (план управления замыслом, план управления риском, план управления поставками и т.д.) и базы измерения хода выполнения проекта являются ключевыми входными данными для процесса исполнения плана проекта.
4.2.1.2. Поддерживающие детали. Поддерживающие детали описаны в разделе 4.1.3.2.
4.2.1.3. Организационная политика. Вопросы организационной политики рассмотрены в разделе 4.1.1.3. Все и каждая из организаций - участников проекта могут иметь свои формальные и неформальные правила деятельности, могущие оказать влияние на исполнение плана проекта.
4.2.1.4. Корректирующее действие. Корректирующее действие- это что угодно, направленное на приведение ожидаемого выполнения проекта в соответствие с планом проекта. Данные действия являются результатами всевозможных процессов контроля, а в качестве входных данных для данного процесса они замыкают цикл обратной связи, необходимый для эффективного управления проектами.

4.2.2. Инструментарий и технологии для исполнения плана проекта
4.2.2.1. Навыки общего менеджмента. Такие навыки общего менеджмента, как лидерство, коммуникации и ведение переговоров, существенны для эффективного исполнения плана проекта. Навыки общего менеджмента описаны в разделе 2.4.
4.2.2.2. Навыки и знания, связанные с продуктом. Команда проекта должна иметь доступ к соответствующему набору навыков и знаний, связанных с продуктом проекта. Необходимые навыки определяются, как часть планирования (особенно при ресурсном планировании, описанном в разделе 7.1), и обеспечиваются посредством подбора персонала (раздел 9.2).
4.2.2.3. Система утверждения видов деятельности. Система утверждения видов деятельности - это формальный процесс для санкционирования видов деятельности по проекту, служащий для того, чтобы удостовериться в том, что все виды деятельности выполняются в должное время и в нужной последовательности. Основной механизм - письменное разрешение на начало деятельности над специфической работой проекта или пакетом работ.
При разработке системы утверждения видов деятельности ценность контроля должна уравновешивать затраты на его осуществление. Например, в малых проектах устное разрешение может быть вполне допустимым.
4.2.2.4. Собрания по обзору положения. Эти собрания планируются для регулярного обмена информацией о ходе проекта. В большинстве проектов они проводятся с разной частотой на различных уровнях организации. Команда управления проектом, например, может собираться еженедельно и ежемесячно встречаться с заказчиком.
4.2.2.5. Информационная система управления проектами. ИСУП описывается в разделе 4.1.2.3.
4.2.2.6. Организационные процедуры. Все организации-участники проекта могут имел формальные и неформальные процедуры, которые могут быть полезны при исполнении проекта.

4.2.3. Результаты исполнения плана проекта
4.2.3.1. Результаты деятельности. Результаты деятельности - результаты выполнении работ проекта. Информация о результатах деятельности - то, какие цели были достигнуты, какие - нет, до какой степени удовлетворены стандарты качества, какие издержки были совершены и каких удалось избежать, и т.д. - все это собирается как часть процесса исполнения плана проекта и “скармливается” процессу отчетности о ходе исполнения проекта (см. раздел 10.3 для более полного обсуждения этого процесса).
4.2.3.2. Требования изменений. данные требования (например, расширить или сжать замысел, пересмотреть смету или расписание и т.д.) часто определяются по ходу работ выполнения проекта.

4.3. Всеобщий контроль изменений
данный процесс имеет дело с: (а) влиянием на факторы, создающие изменения, с цель удостовериться в полезности изменений; (б) определением того, что произошли изменения, (в) управлением изменениями при их появлении. Всеобщий контроль изменений требует:
• Поддержания целостности основ (баз) измерения выполнения проекта – все подтвержденные изменения должны быть отражены в плане проекта, но только изменения замысла окажут влияние на эти основы.
• Подтверждения того, что изменения в замысле продукта отражены в определении замысла проекта (разница между замыслами продукта и проекта описана во введении пятой главе).
• Координирование изменений в различных областях знаний, как это изображено рис. 4.2. Например, при изменении расписания изменению могут подвергнуться области стоимости, риска, качества и персонала.

4.3.1. Входные данные всеобщего контроля изменений
4.3.1.1. План проекта. План проекта обеспечивает основу (базу), отклонения от которой и должны контролироваться. См. выше в разделе 4.1.3.1.
4.3.1.2. Отчеты о ходе выполнения. Отчеты о ходе выполнения (Описанные разделе 10.3) представляют информацию о выполнении проекта. Эти отчеты могут также предупредить команду проекта о предметах, которые могут вызвать проблемы в будущем.
4.3.1.3. Требования изменений. Требования могут проявляться во множестве форм - устно или письменно, прямо или косвенно, под действием внешних или внутренних причин, а также утвержденные руководством или необязательные.

Рис. 4.2. Координирование изменений в проекте в целом

4.3.2. Инструментарий и технологии для всеобщего контроля изменений
4.3.2.1. Система контроля изменений. Система контроля изменений - это набор формальных документированных процедур, который определяет шаги, посредством которых могут быть изменены официальные документы проекта. Она включает бумажную работу, системы слежения и уровень утверждения, необходимый для подтверждения изменений.
Во многих случаях исполняющие организации имеют систему контроля изменений, которая может быть принята для использования в проекте как есть’. Но если подходящая система отсутствует, то команде придется создать её как составную часть проекта.
Большинство подобных систем включает комиссию контроля изменений (ККИ = Сhange Соntгоl Воагd = ССВ), ответственную за принятие запросов об изменениях или соответственно за отказ. Полномочия и ответственность ККИ должны быть определены и согласованы между ключевыми стэйкхолдерами. В больших комплексных проектах •может быть несколько комиссий с различной ответственностью.
Система контроля изменений должна также включать процедуры, позволяющие управлять изменениями, которые можно утверждать без предварительной проверки, например, в результате непредвиденных (чрезвычайных) обстоятельств. В общем случае система контроля изменений позволяет ‘автоматически” утверждать определенные виды изменений. Такие изменения все равно должны быть зафиксированы, чтобы позже по ходу выполнения проекта они не вызвали проблем.
4.3.2.2. Конфигурационный менеджмент. Конфигурационный менеджмент подразумевает любую документированную процедуру, используемую для применения технического и административного управления и надзора в следующих целях:
• Определение и документирование функциональных и физических характеристик объекта или системы.
• Контроль любых изменений этих характеристик.
• Запись и отчет об изменении и статусе его осуществления.
• Проверка объектов и системы для выявления соответствия требованиям [4.11.
Во многих прикладных областях конфигурационный менеджмент является подмножеством системы контроля изменений и используется, чтобы удостовериться в том, что продукт проекта создан правильно и полностью. В то же время в других областях данный термин используется для описания любой строгой системы контроля изменений.
4.3.2.3. Измерение хода выполнения проекта. Технологии измерения хода выполнения типа техники выполненной стоимости, освоенного объёма (см. раздел 10.3.2.3) помогают понять, требуют ли отклонения от плана корректирующих действий.

4.3.2.4. Дополнительное планирование. Проекты редко выполняются точно по плану. Грядущие изменения могут требовать новых или пересмотра старых смет, модификаций последовательности выполнения работ, анализа действий в рисковых ситуациях или корректировок плана проекта.
4.3.2.5. Информационная система управления проектами (ИСУП). Информационные системы управления проектами описаны в разделе 4.1.2.3.

4.3.3.Результаты всеобщего контроля изменений
4.3.3.1. Дополнения плана проекта. Дополнениями плана проекта являются любые изменения содержания плана или вспомогательных деталей (соответственно описанные в разделах 4.1.3.1 и 4.1.3.2). Соответствующие стзйкхолдеры должны быть уведомлены в необходимом порядке.
4.3.3.2. Корректирующие действия. Корректирующие действия описаны разделе 4.2А.4.
4.3.3.3. Извлеченные уроки. Причины отклонений, обоснование выбранных корректирующих действий и другие виды извлеченных уроков должны быть документально оформлены, для того чтобы стать частью исторической базы данных как для этого проекта, так и для других проектов исполняющей организации.

5 Управление замыслом
проекта

Управление замыслом проекта включает процессы, необходимые для подтверждения того, что проект включает все виды деятельности и только виды деятельности, необходимые для успешного завершения проекта [5.1]. Основная его задача состоит в определении и проверке того, что включено или не включено в проект. Рис. 5.1 обеспечивает обзор основных процессов управления замыслом проекта.
5.1. Инициирование - побуждение организации к началу следующей фазы проекта.
5.2. Планирование замысла - создание письменного документа замысла как основы для последующих решений проекта.
5.3. Определение замысла - разбиение основных целей проекта на более мелкие и легко управляемые компоненты.
5.4. Подтверждение замысла - формализация принятия замысла проекта.
5.5. Контроль за изменениями замысла - контроль изменений в замысле проекта.
Данные процессы могут взаимодействовать друг с другом, а также с процессами из других областей знания. Каждый процесс может привлекать усилия индивидуумов или групп людей в зависимости от потребностей проекта. Каждый процесс проявляется, по крайней мере, один раз в каждой фазе проекта.
Хотя процессы представлены здесь как дискретные элементы с четкими взаимодействиями, на практике они могут пересекаться и взаимодействовать не указанными здесь путями. Взаимодействие процессов детально обсуждено в главе 3.
В контексте проекта термин “замысел” относится к следующему:
• Замысел продукта - характеристики и функции, которые должны быть включены в продукт или услугу.
• Замысел проекта - деятельность, которую необходимо осуществить для того, чтобы получить продукт со специфическими характеристиками и функциями.
В фокусе данной главы находятся инструментарий и технологии, используемые для управления замыслом проекта. Инструментарий и технологии управления замыслом продукта разнятся в зависимости от области деятельности и обычно описываются как составляющие жизненного цикла проекта (жизненный цикл проекта обсуждается в разделе 2.1).
Проект состоит из единичного продукта, но продукт может включать составные элементы, каждый со своим отдельным, но увязанным с проектом в целом замыслом продукта. Например, новая телефонная система в общем случае будет включать четыре основные части: оборудование, программное обеспечение, подготовку персонала и использование.
Достижение замысла продукта измеряется по отношению к требованиям, тогда как достижение замысла проекта - по отношению к плану. Оба типа управления замыслом должны быть хорошо интегрированы для подтверждения того, что деятельность по проекту обеспечит создание требуемого продукта.

Рис. 5.1. Обзор процессов управления замыслом проекта

5.1. Инициирование
Инициирование - это процесс формального распознавания того, что существует новый проект или что существующий проект должен перейти в новую фазу (см. раздел 2.1 для детального обсуждения фаз проекта). Данное формальное инициирование соединяет проект с постоянной деятельностью исполняющей организации. В некоторых организациях проект обычно формально не утверждается до завершения исследования возможное осуществления, до создания предварительного плана или другой схожей формы анализа, которая была инициирована отдельно. Некоторые типы проектов, а особенно проекты по оказанию услуг внутри компании или проекты создания новых продуктов, обычно инициируются неформально, при этом проводится некоторый ограниченный объём работ для получения одобрений, необходимых для формального инициирования. Проекты обычно утверждаются в результате одного или нескольких нижеперечисленных факторов.
• Требование рынка (нефтеперерабатывающая компания строит новый нефтеперегонный завод из-за хронических нехваток бензина).
• Деловая необходимость (компания по подготовке кадров утверждает проект создан нового курса для повышения своего дохода).
• Требования клиента (электрическая компания утверждает проект постройки нов подстанции для обслуживания нового индустриального парка).
• Технологический прорыв (фирма по производству электроники утверждает проект создания приставки для видеоигр после появления видеомагнитофона).
• Юридические требования (производитель красок утверждает проект по определению правил обращения с токсичными материалами).
Данные стимулы могут также именоваться проблемами, возможностями или потребностями бизнеса. Центральной темой во всех этих терминах является то, что управленческий персонал должен принять ответное решение.

5.1.1. Входные данные для инициирования
5.1.1.1. Описание продукта. Описание продукта документирует характеристики продукта или услуги, для создания которых был предпринят проект. Обычно в ранних фазах проекта описание продукта будет иметь меньше деталей, чем в более поздних, по мере прогрессирующей наработки характеристик продукта.
Данное описание должно также определять отношение между создаваемым продуктом или услугой и деловой необходимостью либо иными стимулами из вышеприведенного списка, породившими проект. Хотя форма и содержание описания продукта будут меняться, оно всегда должно иметь достаточно деталей для поддержания проектного планирования последующих стадиях.
Многие проекты включают одну организацию (Продавца), производящую работу по контракту с другой (Покупателем). В данных обстоятельствах начальное описание продукта обычно предоставляется Покупателем. Если деятельность Покупателя также является проектом, то описание продукта будет определением вида деятельности, описанным в разделе 12.1.3.2.
5.1.1.2. Стратегический план. Все утвержденные проекты должны поддерживатьстратегические цели организации, осуществляющей проекты, - ее стратегический план должен быть учтен как фактор при выборе решений проекта.
5.1.1.3. Критерии выбора проекта. Критерии в основном определяются в терминах продукта проекта и могут покрывать весь спектр проблем, о которых заботится менеджмент (финансовая отдача, доля на рынке, то, как люди примут продукт, и т.д.).
5.1.1.4. Историческая информация. Вся информация о результатах принятия решений и качестве выполнения проектов подобного рода в прошлом должна быть учтена настолько, насколько это возможно. Когда инициирование включает утверждение для следующей фазы проекта, информация о результатах предыдущих фаз часто является определяющей.

5.1.2. Инструментарий и технологии инициирования
5.1.2.1. Методы проектного выбора. Данные методы обычно попадают в одну из двух широких категорий [5.2]:
•. Методы измерения пользы - сравнительные подходы, модели с подсчетом очков, модели полезности вклада или экономические модели.
• Методы ограниченной оптимизации - математические модели, использующие линейные, нелинейные, динамические, целочисленные и многообъектные алгоритмы программирования.
На данные методы часто ссылаются, как на модели решений. Модели решений включают как основные технологии - деревья решений, вынужденный выбор и др., так и специальные технологии - процесс аналитической иерархии, анализ логической схемы и др. Применение комплексных критериев выбора проекта в сложной модели часто считается отдельной фазой проекта.
5.1.2.2. Экспертная оценка. Экспертная оценка может быть привлечена для того, чтобы отобрать входные данные для данного процесса. Такая экспертиза может осуществляться любым лицом или группой лиц с соответствующими знаниями или подготовкой и исходить из различных источников, включая нижеприведённые:
• Отделы внутри исполняющей организации.
• Консультанты.
• Профессиональные и технические ассоциации.
• Индустриальные Группы.

Дата добавления: 2015-04-29