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

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

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

♦ Журнал проблем. Описан в разделе 4.3.3.3. Журнал проблем используется, чтобы показать, произошло ли обновление каких-либо открытых проблем, которое требует внесения обновлений в реестр рисков.

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

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

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

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

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

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

♦ Анализ технического исполнения. При анализе технического исполнения получаемые в процессе исполнения проекта технические результаты сопоставляются с запланированными. Для этого требуется определение объективных количественных показателей технического исполнения, которые могут быть использованы для сравнения фактических результатов с целевыми показателями. К таким показателям технического исполнения могут относиться вес, сроки транзакций, число допущенных дефектов, объемы хранилища и др. Отклонения могут показывать потенциальное воздействие угроз или благоприятных возможностей.

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

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

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

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

Описаны в разделе 4.3.3.4. Процесс мониторинга рисков может привести к запросу на изменение базового плана по стоимости, базового расписания или других компонентов плана управления проектом. Запросы на изменения проходят проверку и направляются в соответствии с процессом интегрированного контроля изменений (см. раздел 4.6).

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

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

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

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

♦ Журнал проблем. Описан в разделе 4.3.3.3. В случаях выявления проблем в ходе процесса мониторинга рисков эти проблемы регистрируются в журнале проблем.

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

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

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

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

♦ шаблоны для плана управления рисками, реестра рисков и отчета по рискам;

♦ иерархическую структуру рисков.

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

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

12.1. Планирование управления закупками – это процесс документирования решений по проекту в отношении закупок, установления подхода и определения потенциальных продавцов.

12.2. Проведение закупок – это процесс получения ответов от продавцов, выбора продавца и заключения договора.

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

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

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

Рис. 12-1. Общая схема управления закупками проекта

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

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

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

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

Договор купли-продажи содержит основные положения и условия сделки и может включать в себя другие требования покупателя относительно того, что именно продавец должен произвести или поставить. Обязанности команды управления проектом – работая с отделом закупок для обеспечения соблюдения политики закупок в организациях, убедиться, что все закупки соответствуют конкретным потребностям проекта. В зависимости от прикладной области, соглашение может быть договором, соглашением об уровне услуг (SLAs), меморандумом о договорах (MOAs) или заказом на покупку.

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

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

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

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

Победитель тендера может управлять работой как проектом. В таких случаях:

♦ Покупатель становится клиентом субподрядчиков, поставщиков и поставщиков услуг и, следовательно, является заинтересованной стороной проекта с точки зрения продавца.

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

♦ Положения и условия договора и описание работ(SOW) на закупку становятся ключевыми входами многих процессов управления со стороны продавца. Договор может фактически содержать входы (например, основные поставляемые результаты, ключевые контрольные события, целевую стоимость), либо может ограничивать варианты выбора для команды проекта (например, в интеграционных информационно-технических проектах во многих случаях требуется одобрение покупателем решений по обеспечению проекта персоналом). Описание работ (SOW) на закупку может иметь другое название, например, «техническое описание работ».

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

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

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

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

ТЕНДЕНЦИИ И ФОРМИРУЮЩИЕСЯ ПРАКТИКИ В ОБЛАСТИ УПРАВЛЕНИЯ ЗАКУПКАМИ

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

♦ Совершенствование инструментов. Достигнут значительный прогресс в создании инструментов для управления закупками и фазами реализации проекта. Интернет-инструменты для осуществления закупок обеспечивают теперь покупателям единое место, где можно давать объявления о закупках и сообщать продавцам единственный источник для поиска закупочной документации и ее оформления в режиме онлайн. В области строительства / инженерии / инфраструктуры было показано, что расширение использования информационного моделирования здания (Building Information Model, BIM) в программных инструментах дает значительную экономию времени и средств в проектах, которые ее используют. Данный подход может существенно снизить количество претензий в строительстве, что позволяет сократить как затраты, так и сроки. Ведущие компании и государственные органы по всему миру начинают вводить обязательное использование BIM при осуществлении крупных проектов.

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

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

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

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

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

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

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

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

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

♦ Руководящая и нормативно-правовая среда. Интегрированы ли местные законы и нормативные акты в сфере закупочной деятельности в политики организации по закупкам? Как это отражается на требованиях к аудиту договоров?

♦ Доступность подрядчиков. Доступны ли подрядчики, которые способны выполнить требуемые работы?

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

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

Крупные проекты могут использовать адаптивный подход для некоторых поставляемых результатов и более стабильный подход для других частей. В таких случаях может использоваться генеральное соглашение, например, генеральный договор об оказании услуг (Master Services Agreement, MSA), для определения объема работ в целом, а адаптируемые работы выносятся в приложение или дополнение к договору. Это позволяет вносить изменения в адаптируемое содержание без последствий для договора в целом.