Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство Коллектив авторов

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

3.5.3. Интеграция на контекстном уровне

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

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

3.5.4. Интеграция и сложность

Некоторые проекты могут относиться к категории сложных и считаться трудными для управления. Проще говоря, «сложные» и «трудные» – это понятия, которые часто используются для описания вещей, которые считаются запутанными и трудными.

Сложность в проектах является результатом поведения системы организации, поведения людей и неопределенности, существующей в организации или в окружающей среде. В документе «Работа в сложных условиях: практическое руководство» (Navigating Complexity: A Practice Guide) [13], эти три измерения сложности определены следующим образом:

 Поведение системы. Факторы взаимозависимости компонентов и систем.

 Поведение человека. Взаимодействие между разными людьми и группами.

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

Сложность сама по себе – это восприятие человеком, основанное на его личном опыте, наблюдениях и навыках. Более точно определить проект можно не как сложный, а как содержащий сложность. Портфели, программы и проекты могут содержать элементы сложности.

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

 содержащий множество частей;

 имеющий ряд связей между частями;

 демонстрирующий динамические взаимодействия между частями;

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

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

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

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

 распределения ресурсов,

 нахождения баланса конкурирующих требований,

 изучения альтернативных подходов,

 адаптации процессов для достижения целей проекта,

 управления взаимозависимостями между областями знаний по управлению проектом.

Управление интеграцией проекта включает следующие процессы:

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

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

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

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

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

4.6. Интегрированный контроль изменений – это процесс анализа всех запросов на изменения, их одобрения и управления изменениями поставляемых результатов, активов процессов организации, документов проекта и плана управления проектом, а также предоставления информации о решениях.

4.7. Закрытие проекта или фазы – это процесс завершения всех операций по проекту, фазе или договору.

На рис. 4–1 представлена общая схема процессов управления интеграцией проекта. Процессы управления интеграцией проекта представляются в виде дискретных процессов с определенными границами, хотя на практике они накладываются и взаимодействуют такими способами, которые не могут быть в полной мере детализированы в Руководстве PMBOK®.

Рис.19 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство

Рис. 4–1. Общая схема управления интеграцией проекта

КЛЮЧЕВЫЕ КОНЦЕПЦИИ УПРАВЛЕНИЯ ИНТЕГРАЦИЕЙ ПРОЕКТА

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

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

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

В задачи управления интеграцией проекта входит:

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

 предоставление плана управления проектом для достижения целей проекта;

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

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

 принятие интегрированных решений в отношении ключевых изменений, влияющих на проект;

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

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

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

 управление переходом от фазы к фазе по мере необходимости.

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

ТЕНДЕНЦИИ И ВНОВЬ ПОЯВЛЯЮЩИЕСЯ ПРАКТИКИ В ОБЛАСТИ УПРАВЛЕНИЯ ИНТЕГРАЦИЕЙ ПРОЕКТА

Область знаний «управление интеграцией проекта» требует объединения результатов, полученных во всех других областях знаний. Развивающиеся тенденции в процессах интеграции включают в себя, среди прочего:

 Использование автоматизированных инструментов. С учетом объема данных и информации, которые руководителям проектов требуется интегрировать, возникает необходимость в использовании информационной системы управления проектами (PMIS) и автоматизированных инструментов для сбора, анализа и использования информации, необходимых для достижения целей и реализации выгод проекта.

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

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

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

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

СООБРАЖЕНИЯ ПО АДАПТАЦИИ

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

 Жизненный цикл проекта. Что такое целесообразный жизненный цикл проекта? Какие фазы должен включать жизненный цикл проекта?

 Жизненный цикл разработки. Какой жизненный цикл разработки и подход к ней являются целесообразными для данного продукта, услуги или результата? Какой подход является целесообразным – предиктивный или адаптивный? Если адаптивный, то как следует разрабатывать продукт – инкриментно или итеративно? Или лучше использовать гибридный подход?

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

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

 Изменение. Как будет осуществляться управление изменениями в проекте?

 Руководство. Какие органы, комитеты и другие заинтересованные стороны являются частью проекта? Каковы требования к отчетности о статусе проекта?

 Извлеченные уроки. Ккую информацию следует собирать в ходе реализации и по завершении проекта? Как историческая информация и извлеченные уроки будут доводиться до персонала будущих проектов?

 Выгоды. Когда и как предоставляется отчетность о выгодах – в конце проекта или по окончании каждой итерации или фазы?

СООБРАЖЕНИЯ ДЛЯ ГИБКИХ/АДАПТИВНЫХ СРЕД

Итеративный и гибкий подходы способствуют вовлечению членов команды как локальных экспертов в управление интеграцией. Порядок интеграции планов и компонентов определяют члены команды.

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

4.1. Разработка устава проекта

Разработка устава проекта – процесс разработки документа, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Ключевые выгоды от этого процесса состоят в том, что он обеспечивает связь между проектом и стратегическими целями организации, позволяет документально оформить проект и показывает обязательство организации в отношении проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 4–2. На рис. 4–3 показана диаграмма потоков данных процесса.

Рис.20 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство

Рис. 4–2. Разработка устава проекта: входы, инструменты и методы, выходы

Рис.21 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство

Рис. 4–3. Разработка устава проекта: диаграмма потоков данных

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

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

4.1.1. Разработка устава проекта: входы

4.1.1.1. Бизнес-документы

Источниками информации о целях проекта и его вкладе в достижение бизнес-целей являются бизнес-кейс (см. описание в разделе 1.2.6.1) и план управления выгодами (см. описание в разделе 1.2.6.2). Хотя разработка бизнес-документов производится до начала осуществления проекта, они время от времени пересматриваются.

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

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

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

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

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

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

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

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

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

4.1.1.2. Соглашения

Описаны в разделе 12.2.3.2. Соглашения используются для определения первоначальных намерений в отношении проекта. Соглашения могут принимать форму договора, меморандума о взаимопонимании (MOU), соглашения об уровне услуг (SLA), письма-соглашения, письма о намерениях, устных договоренностей, электронного сообщения или других письменных соглашений. Обычно договор используется, если проект выполняется для внешнего заказчика.

4.1.1.3. Факторы среды предприятия

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

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

 юридические или регуляторные требования и/или ограничения;

 ситуацию на рынке;

 культуру организации и политический климат;

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

 ожидания заинтересованных сторон и пороги риска.

4.1.1.4. Активы процессов организации

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

 стандартные политики, процессы и процедуры организации;

 модель руководства портфелем, программой и проектом (функции руководства и процессы для обеспечения управления и принятия решений);

 методы мониторинга и отчетности;

 шаблоны (например, шаблон устава проекта);

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

4.1.2. Разработка устава проекта: инструменты и методы

4.1.2.1. Экспертная оценка

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

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

 стратегия организации,

 управление выгодами,

 отраслевые технические знания и главная область проекта,

 оценка длительности и бюджета,

 идентификация рисков.

4.1.2.2. Сбор данных

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

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

 Фокус-группы. Описаны в разделе 5.2.2.2. Фокус-группы объединяют в своем составе заинтересованные стороны и экспертов по предметным областям для изучения преполагаемых рисков, критериев успеха и других тем в форме диалога с более широким составом участников, чем при индивидуальных интервью.

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

4.1.2.3. Навыки межличностных отношений и работы с командой

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

 Управление конфликтами. Описано в разделе 9.5.2.1. Навык управления конфликтами может потребоваться для достижения согласованного понимания заинтересованными сторонами целей, критериев успеха, высокоуровневых требований, описания проекта, укрупненных контрольных событий и других элементов устава.

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

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

4.1.2.4. Совещания

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

4.1.3. Разработка устава проекта: выходы

4.1.3.1. Устав проекта

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

 назначение проекта;

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

Страницы: «« 12345

Читать бесплатно другие книги:

Книга Юаньхай Цзыпин считается первой книгой по китайской астрологии (Ба цзы), написанной во времена...
Для чего нужен личный алтарь? Это сакральное пространство, место силы для занятий духовными практика...
Северные окраины штата – не самое лучшее место для жизни, но с появлением нового детектива атмосфера...
Что важнее: любовь или чары? Как ответить на этот вопрос? Из-за встречи со мной молодой заклинатель,...
Рано или поздно каждому воздастся по делам его. Ли Джексон, инспектор полиции, никогда не верила в э...
«Без трех чашек кофе я даже не могу приступить к работе». «Опять с мужем поссорилась, у тебя ведь ес...