Лаборатория знаний

ПРОЕКТЫ
ПРОГРАММЫ
ПОРТФЕЛИ
А. Н. Павлов
Управление
программами проектов
на основе стандарта PMI
The Standard for Program Management ®
Изложение методологии
и рекомендации
по применению
ПРОЕКТЫ
ПРОГРАММЫ
ПОРТФЕЛИ
Управление
на основе стандарта PMI
The Standard for Program Management®
Изложение методологии
и рекомендации
по применению
3-е издание
(электронное)
Москва
БИНОМ. Лаборатория знаний
2015
УДК 65.0
ББК 65.290-2
П12
С е р и я о с н о в а н а в 2010 г.
Павлов А. Н.
П12 Управление программами проектов на основе стан-
дарта PMI The Standard for Program Management○ . Из- R
ложение методологии и рекомендации по применению

[Электронный ресурс] / А. Н. Павлов. — 3-е изд. (эл.). —
Электрон. текстовые дан. (1 файл pdf : 267 с.). —
М. : БИНОМ. Лаборатория знаний, 2015. — (Проекты,
программы, портфели). — Систем. требования: Adobe
Reader XI ; экран 10".
ISBN 978-5-9963-2911-3
Целью данной книги является обобщение многолетнего
опыта автора по управлению крупными технологическими
программами и проектами, а также разработки стандартов
и методических рекомендаций, участия во многих между-
народных и отечественных конференциях и симпозиумах,
чтения лекций и учебных курсов в данной области. Большин-
ству специалистов будут особенно интересны практический
опыт и уроки, полученные в ходе управления программами
проектов на основе использования стандарта PMI The
Standard for Program Management○R . Помимо изложения
стандарта книга содержит ценные авторские комментарии
и рекомендации, существенно дополняющие и обогащающие
ее основное содержание.
Книга предназначена для менеджеров высшего и среднего
звена, руководителей программ и проектов и специалистов,
участвующих в проектах, во внедрении корпоративных
систем управления программами или в проведении крупных
комплексных проектов и программ.
УДК 65.0
ББК 65.290-2
Деривативное электронное издание на основе печатного

аналога: Управление программами проектов на основе
стандарта PMI The Standard for Program Management○R .
Изложение методологии и рекомендации по применению /
А. Н. Павлов. — 2-е изд., испр. и доп. — М. : БИНОМ. Лабо-
ратория знаний, 2014. — 264 с. : ил. — (Проекты, программы,
портфели). — ISBN 978-5-9963-0929-0.
В соответствии со ст. 1299 и 1301 ГК РФ при устранении

ограничений, установленных техническими средствами защиты
авторских прав, правообладатель вправе требовать от нарушителя
возмещения убытков или выплаты компенсации
ISBN 978-5-9963-2911-3 c БИНОМ. Лаборатория знаний, 2012

○
Посвящается моей супруге Инне –
любимому человеку и искреннему другу!
Предисловие
Развитие любой компании может быть обеспечено только ре-

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

управления программами проектов на основе использования
наиболее распространенных и общепризнанных во всем мире
стандартов PMI1. Книга предназначена для менеджеров выс-
шего и среднего звена, руководителей программ и проектов
и специалистов, участвующих в проектах. Книга может быть
особенно полезна специалистам, участвующим во внедрении
корпоративных систем управления программами или в прове-
дении крупных комплексных проектов и программ.
Структура книги полностью соответствует структуре стан-
дарта PMI The Standard for Program Management®, Third Edition.
Основное содержание книги посвящено изложению реко-
мендаций и описанию извлеченных уроков, полученных авто-
ром при практическом использовании стандарта.
Следуя структуре стандарта PMI The Standard for Program
Management®, каждый процесс представлен в качестве компо-
нента одной из трех фаз жизненного цикла программы:
1) определение программы;
2) достижение выгод программы;
3) завершение программы
и одной из девяти областей знаний стандарта:
1) управление интеграцией программы;
2) управление содержанием программы;
3) управление расписанием (сроками) программы;
4) управление финансами программы;
5) управление ресурсами программы;
6) управление качеством программы;
7) управление коммуникациями программы;
8) управление рисками программы;
9) управление поставками программы.
Процессы стандарта, рекомендованные к использованию
в каждой области знаний и в каждой фазе жизненного цикла
программы, представлены в табл. 12.
1 Project Management Institute. The Standard for Program Management®.
Third Edition.
2 PM Expert. Учебный курс. Управление программами проектов. M., 2013.
Таблица 1
Процессы управления программой стандарта PMI The Standard
for Program Management®, Third Edition
Определение Достижение выгод

Область знаний Завершение программы

программы программы
Управление коммуникаци- Планирование коммуни- Распространение инфор-

ями программы каций мации
Отчетность об исполнении
программы
Управление финансами Оценка стоимости про- Оценка стоимости ком- Закрытие финансирования
программы граммы понентов программы программы
Определение структуры Бюджетирование расходов
финансирования про- программы
граммы Мониторинг и управление
Разработка плана финан- финансами программы
сирования
Управление интеграцией Инициация программы Управление исполнением Передача результатов про-

программы Разработка плана управле- программы граммы и поддержка выгод
ния программой Мониторинг и контроль Закрытие программы
Разработка инфраструкту- исполнения программы
ры программы
Управление поставками Планирование закупок Осуществление закупок Закрытие закупок про-

программы программы программы граммы
Администрирование за-
купок программы
5
Окончание табл. 1 6
Определение Достижение выгод
Область знаний Завершение программы
Управление качеством Планирование качества Обеспечение качества про-

программы программы граммы
Контроль качества про-
граммы
Управление ресурсами Планирование ресурсов Приоритезация ресурсов

программы программы Управление взаимозависи-
мостью ресурсов
Управление рисками про- Планирование управления Идентификация рисков

граммы рисками программы программы
Анализ рисков программы
Планирование реагирова-
ния на риски программы
Мониторинг и контроль
над рисками программы
Управление сроками Разработка сроков Контроль сроков

программы программы программы
Управление содержанием Планирование содержания Контроль содержания про-

программы программы граммы
Предисловие 7
Перечень областей знаний и фаз жизненного цикла про-

граммы, приведенный в табл. 1, соответствует их изложению
в стандарте PMI The Standard for Program Management®, Third
Edition.
Введение книги посвящено описанию принципов управ-
ления инновациями организации, включающими концепции
портфелей, программ и проектов, и изложению пяти ключевых
составляющих управления программой — «доменов», описан-
ных в стандарте PMI The Standard for Program Management®:
1) согласование стратегии программы;
2) управление выгодами программы;
3) управление вовлеченностью заинтересованных сторон
программы;
4) руководство программой;
5) управление жизненным циклом программы.
Последующие девять глав книги посвящены авторской
интерпретации девяти областей знаний стандарта PMI The
Standard for Program Management®, в которых изложены:
 назначение областей знаний стандарта как ключевых ком-
петенций руководителя программы;
 последовательное описание всех обеспечивающих доме-
ны процессов стандарта в каждой из девяти глав (областей
знаний);
 рекомендации автора по практическому использованию
обеспечивающих процессов;
 уроки, извлеченные автором в ходе использования про-
цессов в реальных программах;
 бизнес-кейсы и проблемные ситуации, возникшие в круп-
ных комплексных программах, с анализом принятых ре-
шений и их последствий.
В заключении книги изложены выводы и окончательные

рекомендации автора по использованию стандарта PMI The
Standard for Program Management® в управлении комплексны-
ми программами.
Введение
в управление инновациями
…Вчера я докладывал владельцам компании

об успешном завершении программы
инфраструктурных проектов.
Они задали мне только один вопрос:
как результаты программы повлияли
на рыночную стоимость компании?
Я не смог ответить на этот вопрос…
Из разговора с директором проектного офиса
крупного финансово-промышленного холдинга
Необходимость инновационной деятельности. Успех биз-

неса любой коммерческой структуры непосредственно связан
с результатами инновационной деятельности компании. Не-
обходимость внедрения новейших разработок и технологий
обеспечивает темпы развития компаний, отвечающие запро-
сам растущего рынка и усилению конкурентной борьбы.
Проектная деятельность посвящена организации работ по
созданию за ограниченное время уникальных, инновационных
решений, методов, технологий, продуктов и услуг. Нововведе-
ние, или инновация, является результатом проектной деятель-
ности и не может быть результатом операционной деятельно-
сти, основанной на применении однотипных, повторяющихся
операций с тиражируемым результатом.
Интеграция результатов инновационной деятельности.
В бизнесе компании могут быть определены три уровня инно-
вационной деятельности (табл. 2):
1) уровень проектов — обеспечивает решение тактических
задач;
2) уровень программ — обеспечивает решение комплексных
проблем;
3) уровень портфелей — обеспечивает достижение превос-
ходства в бизнесе.
Введение в управление инновациями 9
Таблица 2
Уровни инновационной деятельности компании
Уровни
инновационной Проект Программа Портфель
активности
Цель Решение Решение Достижение

тактической комплексной превосходства
задачи проблемы в бизнесе
Способ Инновационный Инновационная Инновационный

достижения цели продукт, технология бизнес
результат, услуга
Результат Уникальное Ускорение Глобализация

решение возврата преимуществ
Повышение инвестиций
эффективности Повышение
Снижение дохода
стоимости Повышение
Повышение прибыли
качества Расширение
доли рынка
Расширение
партнерств
Удержание
заказчиков
Сегодня PMI® (Project Management Institute, USA) раз-

работаны стандарты, позволяющие эффективно управлять
инновационной деятельностью на всех трех уровнях. Однако
на практике часто возникает необходимость взаимодействия
между уровнями инноваций компаний.
Чем все-таки отличаются проекты от программ и портфе-
лей инноваций?
Управление проектами имеет целью приложение знаний,
навыков, инструментов и методов к операциям проекта для
удовлетворения требований, предъявляемых к проекту1.
1 A Guide to the project management body of knowledge (PMBOK® Guide).

Fifth Edition. Newtown Square, Pennsylvania.
10 Введение в управление инновациями
Стандарт по управлению проектами необходим руководи-

телям проектных команд, создающих уникальный продукт, ре-
зультат или услугу.
Управление программами имеет целью достижение стра-
тегических выгод и целей программы1.
Стандарт по управлению программами необходим:
 руководителям программ проектов — для извлечения вы-
год (benefits) в бизнесе компании;
 руководителям проектов, входящих в программы проек-
тов.
Управление портфелями имеет целью достижение опре-
деленных бизнес-целей организации2.
Стандарт по управлению портфелями необходим:
 владельцам бизнеса — для достижения стратегических
бизнес-целей компании;
 топ-менеджерам компаний — для реализации бизнес-стра-
тегий компании.
Обеспечение достижения стратегических целей компании
путем формирования трех уровней инноваций показано на
рис. 1.
Цель портфеля: Цель программы:

Цель компании:
достижение достижение выгод
реализация
стратегических в бизнесе
бизнес-стратегии
бизнес-целей компании
Цель проекта:
создание уникальных
продуктов, резуль-
татов, услуг
Рис. 1. Формирование целей инноваций компании

для реализации ее бизнес-стратегии

Third Edition.
2 Project Management Institute. The Standard for Portfolio Management®.
Third Edition.
Компонентами портфеля могут быть вложенные в порт-

фель подпортфели (sub-portfolios), программы и локальные
проекты, не входящие в какую-либо программу компании.
Компонентами программы могут быть входящие в нее под-
программы, проекты и операционная деятельность компании
(рис. 2).
Рис. 2. Структура портфелей, программ и проектов компании
Построение интерфейсов между уровнями инноваций в

виде процедур обмена данными и результатами работ сможет
повысить эффективность всей инновационной деятельности
компании. Без удовлетворения требований проектов не может
быть обеспечен успех программ, а успех программ обеспечи-
вает достижение бизнес-целей портфелей компании1.
В связи с этим необходима интеграция управления трех
уровней инноваций компании. Интеграция инноваций компа-
нии может быть обеспечена через передачу результатов ключе-
вых процессов управления на каждом из уровней (рис. 3).
1 Павлов А. Н. Интеграция управления инновациями. Тезисы доклада
на III Международной конференции Московского отделения PMI® по
управлению проектами. М., 2006.
12 Введение в управление инновациями
Уровень Бизнес- Необходимое

портфелей цели условие
компаний достигнуты успеха компании
Стратегические Необходимое
Уровень
выгоды условие
программ
получены успеха портфелей
Необходимое
Требования
Уровень условие успеха
проектов
проектов программ
удовлетворены
проектов
Рис. 3. Необходимость интеграции

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

бизнес-целей. Кто должен быть непосредственно заинтересо-
ван в достижении бизнес-целей? Конечно, владельцы бизнеса
(shareholders) — акционеры, собственники, владельцы имуще-
ства и активов предприятий.
Кто должен быть непосредственно заинтересован в успе-
хе проектной деятельности? Конечно, участники проектной
деятельности (stakeholders) — руководители портфелей, про-
грамм, проектов, их команды, заказчики, спонсоры, постав-
щики, подрядчики и др.
Проблема заключается в том, что требования участников
проектной деятельности (stakeholder requirements), как прави-
ло, не в полной мере соответствуют требованиям владельцев
бизнеса (shareholder requirements) (см. табл. 3).
Например, успешный проект, выполненный в установлен-
ные сроки, в рамках бюджета и при удовлетворении заказчи-
ка, необязательно принесет выгоды владельцам бизнеса, такие
как ускорение возврата инвестиций, повышение выручки в
Таблица 3
Отличия требований участников проектной деятельности

от требований владельцев бизнеса
Требования участников Требования владельцев бизнеса

проектной деятельности
Достижение успеха проекта Достижение успеха компании:

и его выполнение:  ускорение возврата инвестиций
 в установленные сроки; (return on investment — ROI);
 в рамках бюджета;  рост выручки в расчете на акцию
 при удовлетворении за- (earnings per share — EPS);
казчика  повышение рыночной стоимости
активов в расчете на выручку (price
per earnings — PPE);
 повышение чистой прибыли (profit
increase);
 увеличение доли рынка (increase
market share);
 удержание заказчиков (customer
retention)
расчете на акцию, повышение рыночной стоимости активов в

расчете на выручку и др.1
В связи с этим необходимо обеспечить ориентацию про-
ектной деятельности на достижение целей бизнеса. Такая ори-
ентация достигается за счет объединения проектов в програм-
мы портфелей организации.
1 Павлов А. Н. Стратегическое управление бизнесом в портфелях проек-

тов организаций. Тезисы доклада на II Международной конференции
по управлению проектами Санкт-Петербургского отделения PMI®.
СПб., 2007.
Введение в управление
…В стремлении реализовать все возможности

рынка мультипроектные организации зачастую
начинают проекты сразу, как только осознают
их необходимость, параллельно с другими
существующими и начинающимися проектами и,
к сожалению, часто без достаточного понимания
собственных возможностей…1
Программа или проект? Границы между программами и про-

ектами часто просто отсутствуют в реальном бизнесе… Дирек-
тор промышленного холдинга рассказывал мне, что недавно
принял решение об инициации крупного проекта, включаю-
щего этапы проектирования, строительства нового предпри-
ятия, его выхода на заданную проектную мощность, выпуска и
реализации продукции на рынке. ИТ-директор другого круп-
ного предприятия докладывал на совещании совета директо-
ров о программе перевооружения ИТ-инфраструктуры, вклю-
чающей проекты обновления оборудования вычислительного
центра и локальных сетей.
Однако в первом случае речь шла не о проекте, а о про-
грамме, включающей операционную деятельность созданного
предприятия, а во втором — о проекте, включающем подпро-
екты обновления оборудования центра и локальных сетей.
Для понимания четкого различия между проектами и про-
граммами следует придерживаться следующих принципиаль-
ных характеристик программ2:
 объединение проектов, связанных единой целью про-
граммы;
1 Patrick F. S. Program Management — Turning Many Projects into Few
Priorities with TOC. Project Management Institute Symposium. Philadelphia,
October, 1999.
Third Edition.
Введение в управление программами проектов 15
 получение выгод, доступных только при объединении про-

ектов в программу;
 наличие элементов операционной деятельности;
 достижение стратегических бизнес-целей программы.
Отдельные проекты организации следует объединять в
программу проектов, если выполняются определенные усло-
вия, среди которых можно назвать следующие:
 взаимозависимость задач разных проектов;
 общий результат (выгода, возможная только при объеди-
нении проектов в программу);
 повышение управляемости проектов, объединенных в
программу;
 общий заказчик, спонсор, потребитель, ресурс, техно-
логия;
 общие для всех проектов ограничения в ресурсах;
 централизованное управление рисками, влияющими на
ряд проектов;
 изменение общей организационной структуры.
Управление программой — это применение знаний, уме-
ний, инструментов и методов для удовлетворения требований,
предъявляемых к программе, и для получения выгод и степени
управляемости, недоступных при управлении проектами по
отдельности.
Управление программой обеспечивает:
 руководство и координацию всех действий и работ в про-
грамме;
 взаимодействие с заинтересованными сторонами (стейк-
холдерами) программы;
 проактивное реагирование на риски;
 обеспечение соответствия программы стратегии и целям
организации;
 разрешение вопросов по содержанию, стоимости, распи-
санию, качеству и рискам программы;
 адаптацию управления программой с учетом имеющихся
культурных, социально-экономических, политических и
других условий и обстоятельств выполнения программы.
16 Введение в управление программами проектов
Менеджер программы — руководитель среднего или выс-

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

и отслеживанию рисков и потенциальных проблем;
 управление документацией программы.
Интересен перечень основных проблем, возникающих
при управлении программами, отмеченный в аналитической
справке Министерства обороны США1:
 несинхронизированность приоритетов программ друг с
другом и с целями организации;
 недостаток авторитета и власти у менеджера программы;
 несоответствие ожиданий и различия в целях стейкхолде-
ров;
 ошибки в анализе осуществимости и при инициации про-
грамм.
Рассмотрим возможные пути решения этих проблем.
Инициация программы. По своей природе программы
являются инновациями более высокого стратегического уров-
ня, чем проекты. Поэтому основным источником инициации
программ является стратегический бизнес-план развития ор-
ганизации. Императивы стратегического бизнес-плана явля-
ются входами для портфелей инноваций организации, внутри
которых должны быть инициированы программы проектов.
Разработка подобных стратегических бизнес-планов, как
правило, начинается с разного рода стратегических сессий и
мозговых штурмов топ-менеджеров и (или) владельцев бизне-
са организации, на которых определяются видение, миссия,
стратегические бизнес-цели. Эти компоненты затем дора-
батываются до конкретных целей портфелей и уточняются в
виде целей и задач программ и проектов. Основная проблема
часто заключается в том, что результаты интенсивной страте-
гической сессии, проведенной в загородном пансионате, при
активном участии внешнего (и дорогостоящего!) фасилитато-
ра — в виде набора презентаций, обрывков бумаг и туманных
записок — ложатся на полку генерального директора компа-
нии (до следующей стратегической сессии).
1 Patrick F. S. Program Management — Turning Many Projects into Few
Priorities with TOC. Presentation at the national Project Management
Institute Symposium. Philadelphia. October, 1999.
Тем не менее наличие воли владельцев бизнеса компании

должно обеспечить доведение данного процесса до логиче-
ского завершения — появления осознанного стратегического
бизнес-плана. Данный план является основой процессов опре-
деления компонентов портфеля и инициации программы, в
результате которого появляется устав программы (рис. 4).
Стратегический Определение Процесс

бизнес-план компонентов инициации
компании портфеля программы
Устав
программы
Рис. 4. Процесс инициации программы
В уставе программы должны быть отражены:

 поддерживаемая программой стратегическая бизнес-цель;
 ключевые результаты, обеспечивающие достижение цели;
 выгоды, получаемые компанией в результате достижения
ключевых результатов программы (рис. 5).
Ключевые Стратегическая
результаты бизнес-цель Выгоды
программы компании компании
Рис. 5. Связь результатов процесса инициации программы
Дадим практические советы и рекомендации по тому, как

эффективно провести инициацию программы:
 в организации должен быть формализован этап опреде-
ления программы (program definition), обеспечивающий
критерии отбора программ, соответствующих целям стра-
тегического бизнес-плана, и процедуру их официального

утверждения1;
 этап определения программы должен использовать резуль-
таты анализа бизнес-кейса и инвестиционного плана про-
граммы, включающего исходные оценки объемов финан-
сирования проектов, входящих в программу;
 формальное достижение стратегической бизнес-цели мо-
жет не означать получение выгод бизнеса, для чего необ-
ходим этап достижения выгод программы (program ben-
efits delivery)2.
Можно сказать, что с проведением инициации программы
она является определенной инновацией, авторизованной ру-
ководством организации. Но перед окончательным определе-
нием существования программы, закрепленной в уставе, пред-
стоит пройти важный этап ее определения.
Определение программы является одной из трех фаз жиз-
ненного цикла программы:
 определение программы (program definition);
 достижение выгод программы (program benefits delivery);
 завершение программы (program closure).
Фаза определения программы включает деятельность по
определению задач и результатов программы, поддерживаю-
щих достижение стратегических бизнес-целей, и по обеспече-
нию одобрения программы руководством организации.
Фаза достижения выгод программы включает действия
по планированию, консолидации и обеспечению выгод про-
граммы.
Фаза завершения программы включает работы по прове-
дению контролируемого завершения программы.
1 Павлов А. Н. Интеграция управления инновациями. Тезисы доклада

на III Международной конференции Московского отделения PMI® по
управлению проектами. М., 2006.
2 Павлов А. Н. Стратегическое управление бизнесом в портфелях проек-
тов организаций. Тезисы доклада на II Международной конференции
по управлению проектами Санкт-Петербургского отделения PMI®.
СПб., 2007.
В табл. 4 представлены основные результаты каждого эта-

па жизненного цикла программы.
Таблица 4
Основные результаты каждого этапа жизненного цикла

программы
Этап жизненного
Основные результаты этапа
цикла программы
Определение программы Разработаны бизнес-кейс и стратеги-

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

программы ствии с задачами программы
Обеспечено соответствие результатов
компонентов установленным требова-
ниям программы
Завершение программы Проведено контролируемое завершение

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

ним из пяти ключевых элементов (доменов) управления
программой.
Домены управления программой. Компании иницииру-

ют и выполняют программы проектов для получения выгод,
обеспечивающих достижение их стратегических бизнес-целей.
В ходе выполнения работ каждой из трех фаз жизненного цик-
ла программы менеджер программы использует пять ключевых
элементов (доменов) управления программой:
1) согласование стратегии программы;
2) управление выгодами программы;
3) управление вовлеченностью заинтересованных сторон
программы;
4) руководство программой;
5) управление жизненным циклом программы.
Использование доменов управления программой являет-
ся критическим фактором успеха любой программы. Взаимо-
связь доменов управления программой представлена на рис. 6.
Рис. 6. Взаимосвязь доменов управления программой

Содержание каждого из пяти доменов содержит процедуры

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

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

события в программе.
Дорожная карта программы включает:
 ключевые зависимости между главными контрольными
событиями;
 связь между бизнес-стратегией и запланированными рабо-
тами;
 высокоуровневые ключевые контрольные события и точки
принятия решения.
Пример дорожной карты программы приведен на рис. 8.
Рис. 8. Пример дорожной карты программы
Анализ факторов окружающей среды позволяет выявить и

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

нести:
 экономические, политические, законодательные, социаль-
ные условия и ограничения выполнения программы;
 динамику рынка;
 активность конкурентов;
 условия внешнего финансирования;
 доступность и достаточность внешних ресурсов;
 технологии и технические средства вендоров и поставщи-
ков;
 внешние риски.
В плане управления программой используются результаты
согласования стратегии программы и объединяются все вспо-
могательные планы управления программой и планы управле-
ния компонентами программы.
Управление выгодами программы. Процедуры и процес-
сы данного домена управления программой позволяют обес-
печить запланированные выгоды и результаты программы.
Процессы и процедуры управления выгодами программы
включают:
 определение выгод программы и их ценности (benefit val-
ue) для организации;
 отслеживание взаимозависимостей между компонентами
программы (component interdependencies) и их влияния на
выгоды программы;
 анализ влияния запланированных изменений программы
на достижение выгод и результатов;
 определение полномочий и ответственности стейкхолде-
ров, обеспечивающих управление выгодами программы;
 согласование выгод программы с достижением стратегичес-
ких целей организации;
 обеспечение поддержки получения выгод программы (ben-
efit sustainment).
Выгода — это возможность, дающая организации преиму-
щество. Управление выгодами — это действия и методы, ис-
пользуемые для определения, создания, максимизации и под-
держки выгод, предоставляемых программой проектов.
Выгоды могут быть материальными и нематериальными.

Материальные выгоды делятся на прямые финансовые и
прямые нефинансовые. Прямые финансовые выгоды можно
количественно измерить и оценить (например, снижение ма-
териальных затрат, более эффективное управление денежны-
ми средствами, увеличение дохода, рост прибыли). Прямые
нефинансовые выгоды можно количественно измерить, но
трудно определить их ценность (например, повышение каче-
ства обслуживания, снижение текучести кадров, повышение
производительности).
Нематериальные выгоды являются косвенными выгода-
ми. Их можно выявить, но трудно измерить в количествен-
ном выражении (например, укрепление морального состоя-
ния сотрудников, удовлетворение клиентов, корпоративный
имидж).
Управление выгодами программы включает следующие
пять этапов:
1) идентификацию выгод;
2) анализ и планирование выгод;
3) достижение выгод;
4) передачу выгод;
5) поддержание выгод.
Управление выгодами в ходе жизненного цикла програм-
мы представлено на рис. 9.
Идентификация выгод — процесс анализа всей доступ-
ной информации о программе для определения и качествен-
ного анализа ожидаемых заинтересованными сторонами про-
граммы выгод. В процессе идентификации выгод программы
тщательному анализу подвергается организационная и бизнес-
стратегии, внутренние и внешние источники влияния и дви-
жущие силы программы.
Действия по идентификации выгод программы:
 определение целей и критических факторов успеха про-
граммы;
 идентификация и количественный анализ выгод для биз-
неса;
Рис. 9. Управление выгодами в ходе жизненного цикла программы
 разработка метрик и ключевых показателей эффективнос-

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

граммой для оценки хода выполнения программы и ее ком-
понентов по достижению запланированных выгод в бизнесе
организации.
! Комментарий из практики. Эффективные регулярные об-

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

запланированных и достигнутых выгод по ряду факторов, сре-
ди которых следует отметить фактор соответствия программы
стратегии организации, который фокусируется на связях и
взаимозависимостях планов программы и стратегических пла-
нов организации.
! Комментарий из практики. При анализе реализации выгод

программы полезно отвечать на вопросы:
 не «ушла» ли программа в сторону от стратегических целей
организации;
 соответствуют ли планы программы стратегическому плану
развития бизнеса организации?
Анализ ценности результатов программы позволяет удо-

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

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

ности мер по управлению рисками, влияющими на достиже-
ние выгод программы.
Анализ результативности программы и ее компонентов
обеспечивает меры по достижению максимально возможных
выгод программы и ее компонентов.
Достижение выгод программы включает следующие дей-
ствия:
 мониторинг организационного окружения (включая
внутренние и внешние факторы), целей программы и
реализации выгод с тем, чтобы выполнение программы
соответствовало достижению стратегических целей орга-
низации;
 инициацию, выполнение, передачу результатов и закрытие
проектных и подпрограммных компонентов и управление
взаимозависимостями между ними;
 оценку рисков программы и ключевых показателей эф-
фективности для управления выгодами;
 фиксацию хода выполнения программы в реестре выгод и
информирование заинтересованных сторон программы о
результатах в соответствии с планом коммуникаций про-
граммы.
Отчеты о реализации выгод включают анализ отклонений
полученных фактически выгод от заданных в плане реализа-
ции выгод. При необходимости по результатам анализа от-
четов по исполнению программы принимаются решения по
ускорению либо замедлению темпов работ или по проведению
общих работ программы в интересах нескольких компонентов
и т. п.
! Комментарий из практики. Выгоды программы могут быть

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

основными параметрами:
1) сроками реализации выгод;
2) ценностью реализации выгод (например, числом сэконом-
ленных часов рабочего времени, увеличением прибыли и
дохода организации, снижением противодействия конку-
рентов и т. п.).
Действия по передаче выгод должны обеспечить:
 проверку того, что интеграция, передача и закрытие про-
граммы и ее компонентов соответствуют или превышают
критерии выгод, установленные в отношении достижения
стратегических целей организации;
 разработку плана передачи выгод в операционное исполь-
зование для поддержки достигнутых выгод.
Действия по поддержке выгод (benefit sustainment) долж-
ны обеспечить:
 планирование операционных, финансовых и других изме-
нений, необходимых для пользователей результатов про-
граммы;
 внедрение необходимых изменений для обеспечения воз-
врата задействованных в программе ресурсов в операци-
онную деятельность организации;
 мониторинг эффективности продуктов, услуги или резуль-
татов программы с точки зрения надежности и пригоднос-
ти к использованию;
 взаимодействие с заказчиком программы в части обеспе-
чения поддержки полученных продуктов, услуг или ре-
зультатов;
 планирование и операционную поддержку продукта, услу-

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

к стейкхолдерам программы (они, скорее всего, заинтересова-
ны в крахе программы организации и могут оказывать нега-
тивное влияние на программу).
Пример взаимосвязей заинтересованных сторон програм-
мы приведен на рис. 10.
Рис. 10. Пример взаимосвязей заинтересованных

сторон программы
Управление вовлеченностью заинтересованных сторон

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

стейкхолдеров программы используются мозговые штурмы
членов команды управления программой, которые позволя-
ют определить состав стейкхолдеров, их роли, значимость для
программы, уровни влияния и интереса к программе. При об-
наружении негативного влияния программы на конкретных
стейкхолдеров необходима разработка плана реагирования,
позволяющего исключить либо максимально уменьшить дан-
ное влияние.
При планировании вовлеченности заинтересованных сто-
рон программы следует обеспечить условия:
 достижения максимального вклада стейкхолдеров в рабо-
ты и результаты программы;
 эффективных коммуникаций между стейкхолдерами про-
граммы;
 удовлетворения требований и ожиданий стейкхолдеров
программы;
 разрешения конфликтов, возникающих между стейкхолде-
рами.
Одной из задач менеджера программы является сниже-
ние риска пассивного вовлечения стейкхолдеров (risk of non-
participation by stakeholders) в работы программы, а также
минимизация негативного воздействия программы (если оно
имеется) на цели и задачи отдельных стейкхолдеров. Реализа-
ция этой задачи включает следующие шаги:
 подтверждение актуальности информации о программе,
которой располагает данный стейкхолдер;
 ограничение влияния мнения данного стейкхолдера на
мнения о программе других стейкхолдеров;
 разработка мер по исключению / минимизации негатив-
ного воздействия программы на стейкхолдера.
Коммуникации являются основным средством управления
стейкхолдерами программы и включают регулярные опове-
щения и отчеты о статусе программы, совещания, перегово-
ры, управление потенциальными проблемами и конфликтами.
Важны индивидуальные способности менеджера программы
воздействовать на убеждения, действия и намерения стейк-
холдеров программы. Источником влияния менеджера про-

граммы на других стейкхолдеров программы могут быть его
связи с влиятельными людьми — высшим руководством орга-
низации и владельцами бизнеса. При отсутствии таких связей
у стейкхолдеров возникает мнение, что менеджер программы
не обладает никаким влиянием, потому что он неизвестен «на
верху» и не имеет никаких связей с топ-менеджментом орга-
низации. При возникновении проблем в работах программы
он не сможет получить необходимой поддержки руководства,
потому что является неизвестной для них личностью.
В случае наличия связей менеджера программы с влия-
тельными людьми их влияние распространяется на влияние
самого менеджера программы.
Управление вовлеченностью в программу заинтересо-
ванных сторон является непрерывным процессом и одной из
главных задач руководителя программы на протяжении всего
жизненного цикла программы.
Основные документы, разрабатываемые в этом процессе:
 план управления вовлеченностью заинтересованных
сторон;
 реестр заинтересованных сторон.
При анализе основных заинтересованных сторон и раз-
работке плана их вовлечения в программу необходимо учиты-
вать:
 культурную среду организации и готовность к измене-
ниям;
 отношение стейкхолдера к программе и к ее спонсорам;
 ожидания стейкхолдера от управления выгодами про-
граммы;
 степень его поддержки или противодействия достижению
выгод программы;
 возможности влияния стейкхолдера на результаты про-
граммы.
При разработке плана управления вовлеченностью заин-
тересованных сторон программы полезно использовать мат-
рицу вовлеченности заинтересованных сторон программы
(рис. 11).
Рис. 11. Матрица вовлеченности заинтересованных

сторон программы
В этой матрице по вертикали растут полномочия и власть

определенного стейкхолдера в организации, а по горизонтали
возрастает степень его интереса к конкретной программе.
С помощью такой матрицы возможно разбиение все-
го множества стейкхолдеров программы на четыре фокусных
группы.
Первая фокусная группа (содержащая стейкхолдера А на
рис. 11) несет риск для программы, так как стейкхолдер А об-
ладает высокими полномочиями в организации и одновремен-
но не проявляет большого интереса к программе и ее резуль-
татам. Такое лицо может отдать распоряжение, блокирующее
поддержку программы ресурсами организации, или может
предложить решение руководящего комитета о закрытии про-
граммы. Менеджер программы обязан поддерживать удовлет-
ворение пусть небольшого, «тлеющего» интереса этого лица к
целям и результатам программы, чтобы создать условия повы-
шения этого интереса и миграции данного лица из первой во
вторую фокусную группу.
Вторая фокусная группа (содержащая стейкхолдеров B, H,
F на рис. 11) содержит союзников программы, в том числе ее
заказчиков и спонсоров. Эти лица обладают большой влас-
тью в организации и проявляют непосредственный интерес к

программе. Менеджер программы обязан тесно сотрудничать
с этими лицами, чтобы удовлетворять их высокий интерес и
опираться на их поддержку.
Третья фокусная группа (содержащая стейкхолдеров С и
Е на рис. 11) включает стейкхолдеров программы с низкими
полномочиями и непосредственным интересом к программе и
ее результатам. Это могут быть конечные пользователи резуль-
татов и продуктов компонентов программы, и менеджер про-
граммы обязан регулярно информировать их о статусе работ
программы, чтобы не допустить падения их интереса к резуль-
татам программы.
Четвертая фокусная группа (содержащая стейкхолдеров G
и D на рис. 11) включает стейкхолдеров с низкими уровнями
полномочий и интереса к программе и требует от менеджера
программы факультативного наблюдения за этими лицами с
минимальными усилиями. Тем не менее наблюдать следует за
теми лицами из этой фокусной группы, которые, например,
зачислены в кадровый резерв организации. Занятие этими
лицами руководящих постов в организации должно сопрово-
ждаться активными коммуникациями с ними со стороны ме-
неджера программы, чтобы обеспечить условия для их мигра-
ции во вторую, а не в первую фокусную группу.
Руководство программой. Руководство программой осу-
ществляет менеджер программы при поддержке спонсора
программы. Для высокоуровневого управления программой
в организации может быть создан программный комитет или
комитет управления программой (program governance board).
Члены программного комитета отвечают за высокоуровне-
вое управление всеми программами организации. Программ-
ный комитет является совещательным органом. Окончатель-
ные решения по всем обсуждаемым программным комитетом
вопросам принимает председатель программного комитета
(executive sponsor). Высокоуровневое руководство програм-
мой должно обеспечить принятие эффективных решений по
управлению программой для достижения ее целей и получе-
ния выгод организации.
Пример структуры высокоуровневого управления про-

граммами и состава программного комитета организации при-
веден на рис. 12.
Рис. 12. Структура высокоуровневого управления программами

и состава программного комитета компании
К функциям программного комитета относятся:

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

 поддержка исполнения программы;
 мониторинг текущего состояния программы и необходи-
мости изменений;
 обзоры по завершении фазы;
 утверждение инициации или передачи компонентов про-
граммы;
 закрытие программы.
Офис управления программой (program management of-
fice — PMO) осуществляет методологическую, организаци-
онную, информационную и технологическую поддержку ме-
неджеру программы в принятии им решений по управлению
! Комментарий из практики. В крупных компаниях, ведущих

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

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

 краткий обзор целей программы;
 структура и состав программного комитета;
 распределение ролей и ответственности;
 план совещаний программного комитета;
 запланированные обзоры по завершении фазы;
 критерии инициации компонентов;
 критерии передачи результатов или закрытия компонен-
тов;
 порядок эскалации спорных вопросов;
 план проверок и аудитов.
План аудитов программы описывает цели и сроки про-
ведения аудитов программы, как правило, связанные с за-
вершением компонента, фазы программы либо достижения
контрольного события программы. План аудитов программы
разрабатывается для подтверждения выполнения менеджером
программы и командой управления программой всех про-
цессов и процедур организации по управлению программой.
Разработка плана аудитов компонентов производится для под-
тверждения выполнения руководителями компонентов всех
процессов и процедур организации по управлению компонен-
тами.
Аудит является необходимой процедурой подтверждения
корректного и эффективного управления любыми программа-
ми. Главными целями аудита в различных секторах экономики
являются:
 для государственных программ — проверка целевого осво-
ения бюджетных средств;
 для строительных программ — проверка целевого освое-
ния средств инвестора;
 для внутренних программ организации — проверка вы-
полнения всех процессов и процедур (в том числе финан-
совых) компании.
Внешний аудит программы осуществляется внешними
проверяющими органами по отношению к компании, выпол-
няющей программу. Внутренний аудит осуществляется аудито-
рами компании, выполняющей программу.
NB! Менеджер программы должен быть готов к проведе-

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

цессы и процедуры организации не требуются для управле-
ния конкретной программой. В этом случае отклонение от
процесса (process deviation) должно быть документировано и
эскалировано на решение программного комитета. В случае
получения позитивного решения по данной эскалации (т. е.
разрешения не использовать процесс) менеджер программы
может не использовать данный процесс в управлении про-
граммой.
! Комментарий из практики. Аудитор будет пытаться вы-

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

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

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

домлением менеджера программы о датах и содержании аудита
(перечне вопросов, подлежащих проверке), для всесторонней
подготовки менеджера программы и согласования дат аудита,
приемлемых для расписания текущих работ программы.
NB! Наряду с подготовкой к проведению плановых

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

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

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

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

причинам:
 конкуренции, возникающей между руководителям компо-
нентов программы из-за борьбы за использование лучших
(и ограниченных!) ресурсов;
 отличий в требованиях к целям и в ожиданиях от результа-
тов программы у различных стейкхолдеров;
 большого количества рисков и изменений, возникающих в
работах компонентов и программы в целом.
Высокоуровневое руководство программой осуществляет-
ся на протяжении всего ее жизненного цикла и требует нали-
чия в организации определенных политик и процедур, обеспе-
чивающих:
 общие процессы управления всеми компонентами про-
граммы;
 контроль эффективного применения процессов и про-
цедур;
 правила определения и документирования предположений
и решений;
 общие процессы управления изменениями, рисками, по-
тенциальными проблемами компонентов и программы в
целом.
На рис. 13 представлен пример структуры высокоуровне-
вого управления программы.
В организационной структуре программы должны быть
отражены уровни полномочий ответственных лиц в структуре
руководства программой.
Пример организационной структуры управления програм-
мой представлен на рис. 14.
Управление жизненным циклом программы. Жизненный
цикл программы включает три фазы:
 определение программы (program definition phase);
 достижение выгод программы (program benefits delivery
phase);
 завершение программы (program closure phase).
Блок-схема жизненного цикла программы представлена на
рис. 15.
Рис. 13. Пример структуры высокоуровневого управления программы торгово-промышленной группы
«Создание производства металлокомпозитов»
Рис. 14. Пример организационной структуры программы торгово-промышленной группы
«Создание производства металлокомпозитов»
Рис. 15. Блок-схема жизненного цикла программы
Два обзора по завершении фазы программы G1 и G2

(phase gate review) должны быть проведены после завершения
фазы программы и перед началом работ по следующей фазе
жизненного цикла программы. Такие обзоры позволяют про-
граммному комитету обосновать и принять одно из следую-
щих управленческих решений:
 о продолжении программы;
 продолжении программы с необходимыми изменениями;
 замораживании программы на определенное время;
 об остановке (прекращении) программы.
Для принятия обоснованного управленческого решения
программный комитет должен получить ответы менеджера
программы по следующим вопросам:
 соответствует ли программа проектов стратегии компании;
 соответствуют ли ожидаемые выгоды изначальному биз-
нес-плану;
 остается ли уровень риска на допустимом уровне толе-
рантности организации к рискам;
 эффективно ли управление программой;
 находят ли лучшие практики применение в управлении
программой?
Контроль со стороны руководства программой должен
обеспечить:
 мониторинг получения результатов программы и проверку
использования лучших практик в управлении программой;
 мониторинг соответствия выгод программы исходному
бизнес-плану и стратегическим целям компании.
Основные действия в этом процессе выполняет программ-
ный комитет (program committee) или руководящий комитет
программы (program steering committee) как орган высоко-
уровневого управления программой. Данный орган проводит
регулярные плановые совещания для обеспечения контроля
программы со стороны руководства организации.
В ходе таких совещаний рассматриваются запросы на ре-
шение по завершении фазы (gate review decision request), ко-
торые содержат всю необходимую документацию для рассмо-
трения на программном комитете и принятия обоснованного
решения для завершения фазы и перехода в следующую фазу

жизненного цикла программы. Для обсуждения запросов на
заседаниях программного комитета могут быть представлены
обзоры результатов подобных прошлых программ компании и
заслушаны мнения как внутренних, так и внешних экспертов.
В результате обзоров принимаются решения о продолжении/
прекращении программы/компонента. Такие решения прини-
маются по завершении фазы жизненного цикла программы/
компонента перед переходом в следующую фазу в ходе обзора
результатов фазы (phase gate review). По завершении послед-
него компонента программы программный комитет проводит
обсуждение результатов и достигнутых выгод программы, что-
бы выработать рекомендации по закрытию (в случае достиже-
ния требуемых результатов) либо по продолжению работ про-
граммы (в случае получения результатов, не достаточных для
удовлетворения заказчика программы).
Рассмотрим содержание фаз жизненного цикла по опреде-
лению программы, достижению выгод программы и заверше-
нии программы.
Фаза определения программы включает разработку биз-
нес-кейса и стратегического плана по достижению целей и
ожидаемых результатов программы и этапы формулирования
и подготовки программы.
В ходе процесса формулирования программы компания
назначает спонсора и «потенциального руководителя» про-
граммы. Окончательный менеджер программы назначается
при утверждении устава программы.
Спонсор и потенциальный руководитель программы:
 тесно работают над поиском источников и обеспечением
финансирования программы;
 инициируют исследования и оценку содержания, стоимос-
ти и ресурсов программы;
 выполняют предварительную оценку рисков программы;
 разрабатывают устав и дорожную карту программы.
В ходе подготовки программы определяется организация
программы и назначается команда по разработке плана управ-
ления программой.
Ключевые действия процесса:

 определение структуры руководства программой;
 определение начальной организации программы;
 разработка плана управления программой.
Фаза достижения выгод программы должна обеспечить
планирование и интеграцию управления компонентами про-
граммы для достижения ожидаемых выгод программы.
В ходе проведения работ данной фазы осуществляются
планирование и авторизация компонентов программы, мони-
торинг и интеграция компонентов и передача и закрытие ком-
понентов.
Планирование и авторизация компонентов программы
позволяют провести формализацию содержания работ по каж-
дому компоненту и определить результаты, соответствующие
целям и выгодам программы. В этом процессе используются
всевозможные планы, разработанные для выполнения компо-
нентов, например план управления проектом, план передачи
компонента, операционный план, план обслуживания или
другие планы в зависимости от содержания выполняемых ра-
бот компонента.
В процессе авторизации компонентов программы необхо-
димо:
 выполнить все управленческие действия по инициации
компонентов программы;
 назначить спонсора и руководителя компонента;
 выделить ресурсы (в том числе финансовые) для выполне-
ния работ компонента.
Данный процесс включает следующие действия и работы:
 разработку и утверждение бизнес-плана компонента про-
граммы;
 утверждение кандидатур спонсора и менеджера компонента;
 информирование стейкхолдеров об инициации компонента.
! Комментарий из практики. Процесс авторизации компо-

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

менеджера программы, руководителей компонентов или лю-
бых других стейкхолдеров программы и содержат обоснование
необходимости компонента для успеха программы и задание
на разработку бизнес-плана компонента. В ходе процесса ав-
торизации компонента команда управления программой про-
водит обзоры по анализу места и роли нового компонента
среди других компонентов программы. В результате данных
обзоров принимаются решения go/no-go — решения об ини-
циации либо об отказе в инициации компонента. В ходе об-
зоров и обмена экспертными оценками могут возникнуть за-
просы на изменения содержания компонента и программы в
целом. Такие запросы подлежат эскалации и рассмотрению на
заседании программного комитета.
! Комментарий из практики. При анализе влияния измене-

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

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

мы может быть получено либо от менеджера программы (для не-
значительных изменений плана управления программой), либо от
программного комитета (для изменений, существенно влияющих
на план управления программой) — в соответствии с установлен-
ными нормами делегирования полномочий менеджера програм-
мы. Как правило, уровень делегирования полномочий менеджера
программы не превышает 10% отклонений в сроках и бюджете
программы. Изменения в содержании работ программы, приво-
дящие к более значительным отклонениям в сроках и бюджете,
подлежат обязательной эскалации на рассмотрение программно-
го комитета.
Изменения, не получившие одобрения, являются откло-

ненными или отложенными. Отклоненные изменения счита-
ются нецелесообразными для достижения результатов и выгод
программы. Отложенные изменения должны быть проанали-
зированы более детально для определения их влияния на ре-
зультаты и выгоды программы и принятия окончательного ре-
шения по их принятию к реализации либо по их отклонению.
Процесс непрерывного мониторинга и интеграции ком-
понентов позволяет руководителю программы отслеживать
результаты компонентов и проводить их консолидацию для
обеспечения выгод программы. Процесс передачи и закры-
тия компонентов позволяет провести административное за-
вершение и закрытие компонента программы либо передать
ее эксплуатацию в другую программу, либо в операционную
деятельность компании.
В ходе данного процесса менеджер программы должен
обеспечить:
 принятие всех необходимых управленческих решений по
передаче результатов компонентов программы заказчику
программы;
 проведение обзоров по завершении последних фаз компо-
нентов программы (last phase gate reviews);
 высвобождение всех ресурсов завершенных компонентов
для их использования в компонентах других программ
компании.
Запрос на передачу компонента может поступить в про-

граммный комитет либо вследствие завершения всех работ
компонента, либо по инициативе остановки/замораживания
работ компонента.
! Комментарий из практики. Причинами остановки/замора-

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

ченных результатов компонента, обеспечивающих достижение
выгод программы и их сравнения с утвержденным планом ре-
ализации выгод. В случае невозможности достижения плано-
вых результатов и выгод программы может возникнуть необхо-
димость остановки/замораживания работ компонента.
По результатам рассмотрения запроса на передачу компо-
нента и отчета о реализации выгод программы принимается
решение о передаче результатов компонента заказчику про-
граммы либо об остановке/замораживании компонента.
Решение о передаче компонента — официальное реше-
ние программного комитета о передаче результата компонента
заказчику программы либо его остановке/замораживании —
должно быть отражено в официальном документе — сертифи-
кате компонента.
Фаза завершения программы позволяет провести контро-
лируемое завершение всей программы и передать ее результа-
ты заказчику программы.
В ходе проведения данной фазы менеджер программы
обязан обосновать и подтвердить достижение всех запланиро-
ванных выгод программы и передачу результатов всех компо-
нентов программы.
Теперь рассмотрим подробно описания ключевых компетен-
ций менеджера программы — девяти областей знаний стандарта
PMI The Standard for Program Management®. Вниманию читателя
предлагается последовательное изложение всех поддерживающих
домены процессов стандарта в каждой из девяти областей зна-
ний и рекомендации автора по их использованию на практике.
ГЛАВА 1
Интеграция программы
– Неужели для выполнения моей работы мне

потребуется так много знать?
– Да. Иначе Вы не сможете выполнять Вашу
работу в нашей организации.
Из беседы генерального директора консалтинговой
компании с кандидатом на позицию руководителя
программы проектов
Значение области знаний «Управление интеграцией про-

граммы» стандарта PMI The Standard for Program Mana-
gement®. В данной области знаний стандарта описана одна
из девяти ключевых компетенций руководителя программы по
интеграции всевозможных планов, работ, ресурсов и результа-
тов программы. Семь процессов, рекомендованных стандар-
том в данной области знаний, относятся к фазам жизненного
цикла определения, достижения выгод и завершения програм-
мы (табл. 5).
Таблица 5
Процессы и фазы жизненного цикла в области знаний

«Управление интеграцией программы»
Фаза жизненного
Процесс
цикла
Инициация программы Определение

Разработка плана управления программой программы
Разработка инфраструктуры программы
Управление исполнением программы Достижение выгод

Мониторинг и контроль исполнения программы программы
Передача результатов программы и поддержка Завершение

выгод программы
Закрытие программы
54 Глава 1
Описания данных процессов и рекомендации автора по их

применению приведены далее.
1.1. Область знаний:

управление интеграцией программы
Фаза жизненного цикла: определение программы
Процесс: инициация программы
Основные цели процесса инициации программы:

 определение и формальное признание существования про-
граммы компании;
 определение источников гарантированного финансирова-
ния программы;
 разработка стратегии получения желаемых выгод програм-
мы;
 назначение руководителя программы, поименованного в
уставе;
 наделение руководителя программы полномочиями по
привлечению и использованию необходимых ресурсов.
Интерпретация процесса инициации программы и ре-
комендации автора по его применению на практике. Ини-
циация программы заключается в определении потребностей
организации в ее проведении и анализе выгод от ее реализа-
ции. Результат инициации программы может быть как пози-
тивным, так и негативным. В случае позитивного результата
инициации принимается решение о запуске программы (go
decision) и утверждается устав программы. В случае негатив-
ного результата инициации принимается решение об отказе
от запуска программы (no go decision). В процессе инициации
программы тщательно анализируются данные, изложенные в
бизнес-кейсе, и стратегические директивы портфеля программ
компании с целью подготовки к последующему этапу плани-
рования программы.
Основные шаги процесса инициации программы:
 определение источника финансирования и спонсора;
 назначение менеджера программы;
Интеграция программы 55
 оценка содержания, ресурсов и стоимости;

 начальная оценка рисков;
 обновление бизнес-кейса программы;
 разработка дорожной карты и устава программы.
Основные результаты выполнения данных шагов должны
быть отражены в уставе и дорожной карте программы.
NB! При инициации программы необходимо учитывать

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

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

обновления бизнес-кейса, дорожная карта программы.
С момента утверждения устава спонсором и заказчиком
программы поименованный в данном документе менеджер
программы обретает официальные полномочия по руководству
программой, позволяющие ему разрабатывать планы програм-
мы и привлекать необходимые для их выполнения ресурсы.
Наряду с этими полномочиями менеджер программы начинает
нести ответственность за успех реализации программы перед
заказчиком и спонсором. В уставе отражается связь програм-
мы с текущей деятельностью компании и ее стратегическими
приоритетами. В случае негативного результата процесса ини-
циации и отказа компании от реализации программы это ре-
шение отражается в уставе и в базе данных извлеченных уро-
ков (lessons learned).
56 Глава 1
Устав программы включает следующие разделы:

 обоснование программы;
 стратегическое видение целей и результатов программы;
 соответствие программы бизнес-стратегии компании;
 результаты программы;
 содержание работ программы;
 стратегия получения выгод;
 допущения и ограничения;
 компоненты программы;
 риски и потенциальные проблемы;
 длительность и список контрольных точек;
 требуемые ресурсы;
 ключевые участники программы;
 руководство программой.
Анализ выгод от реализации и рисков в выполнении работ
программы проводится на этапе бизнес-планирования про-
граммы и предшествует ее инициации. Однако меняющиеся
директивы и стратегические цели компании могут привести к
существенным обновлениям бизнес-кейса и изменениям в ре-
зультатах программы и выгодах от ее реализации.
Дорожная карта программы как высокоуровневый до-
кумент является хронологическим представлением, в кото-
ром отражаются ключевые зависимости между компонентами,
вехи, точки принятия решений, проблемы и риски програм-
мы, а также связи программы с бизнес-стратегией компании.
Извлеченные уроки процесса 1.1 (lessons learned — LL)

 LL-1.1.1. Менеджер программы должен быть вовлечен в
процесс инициации программы как можно раньше.
 LL-1.1.2. Утверждение устава и обновленного бизнес-кейса
спонсором и заказчиком программы необходимо провести
в результате презентации менеджера программы, посвя-
щенной детальному изложению данных документов клю-
чевым стейкхолдерам программы (включая руководство
организации и/или владельцев компании) и обмена экс-
пертными оценками.

Процесс: разработка плана управления программой
Основные цели процесса разработки плана управления

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

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

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

необходимость поддержания их целостности, взаимной допол-
няемости и непротиворечивости в рамках «единого докумен-
та» — плана управления программой.
58 Глава 1
! Комментарий из практики. Изменения в одном плане,

входящем в план программы, часто вызывают изменения в ряде
других. Например, если спонсор требует сократить сроки про-
граммы, то для выполнения того же объема работ в более сжатые
сроки в программу необходимо привлечь дополнительные ресур-
сы, которые стоят денег (значит, необходимо увеличить бюджет
программы и изменить финансовый план). Работа в более сжатые
сроки может привести к падению качества результатов (значит,
надо усилить контроль качества и изменить план по управлению
качеством). Сокращение сроков потребует ускорения поставок
(значит, необходимо изменить план по управлению поставками
программы).
NB! Руководитель программы далеко не всегда способен

выявить все возможные изменения в множестве различ-
ных планов и обеспечить их согласованность.
Любые существенные изменения в плане управления про-

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

ственного — на уровне менеджера программы, так и сущест-
венного — на уровне комитета) рекомендуется выбирать одно
из трех управленческих решений:
1) принять изменение к реализации (accept) — в случае целе-
сообразности изменения в интересах успеха программы;
2) отклонить изменение (reject) — в случае отсутствия целе-
сообразности изменения;
3) отложить (postpone) — в случае необходимости проведе-
ния дополнительного анализа влияния изменения на про-
грамму и прежде всего его влияния на базовые планы про-
граммы.
NB! Изменения базовых планов программы, являющи-

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

вом программы в данном процессе. Такая библиотека может
включать:
 эффективные темплейты и шаблоны документов, реко-
мендованные к использованию офисом управления про-
граммой;
 наиболее эффективные решения проблемных ситуаций,
примененные в прошлых программах компании;
 рекомендации по эффективному использованию в про-
граммах ограниченных ресурсов компании.
Одним из основных инструментов процесса разработки
плана управления программой является информационная сис-
тема управления программой, которая обеспечивает сбор,
обработку, мониторинг и контроль всех данных по управле-
нию программой. Данная система является объединенным ре-
60 Глава 1
сурсом следующих важнейших процессов, процедур и инстру-

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

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

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

программой является обязанностью офиса управления про-
граммой (или программного офиса) — ядра инфраструктуры
программы. Основная задача офиса управления программой —
поддержка принятия решений по управлению программой и
ее компонентами. Менеджер программы является руководите-
лем офиса управления программой, выполняющего функции:
 разработки, ведения и обновления плана управления про-
граммой;
 отслеживания выполнения планов компонентов и получе-
ния консолидированных результатов программы;
 управления взаимодействием компонентов и разрешение
ресурсных конфликтов между их руководителями;
 сбора и анализа отчетов руководителей компонентов;
62 Глава 1
 организации совещаний менеджера программы с руково-

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

 LL-1.2.1. Взаимозависимости компонентов (component de-
pendencies) программы могут являться источниками кри-
тических рисков программы (а не только ее компонентов).
Важной обязанностью менеджера программы является
управление рисками, возникающими «на стыке» компо-
нентов программы и находящимися вне зон внимания ру-
ководителей компонентов.
 LL-1.2.2. Ресурсные конфликты между руководителями
компонентов могут быть разрешены с помощью приори-
тезации компонентов, основанной на весе индивидуаль-
ного вклада компонентов в достижение консолидирован-
ных результатов и выгод программы.

Процесс: разработка инфраструктуры программы
Основные цели процесса разработки инфраструктуры про-

граммы:
 исследование, оценка и планирование поддерживающей
структуры программы для обеспечения успешного дости-
жения ее целей;
 адаптация поддерживающей структуры программы при
изменении ее целей или содержания в ходе жизненного
цикла программы.
Интерпретация процесса разработки инфраструктуры
программы и рекомендации автора по его применению на
практике. В данном процессе менеджер программы обязан
организовать проведение работ, обеспечивающих:
 определение ролей и назначения основных исполнителей;
 разработку плана ресурсов программы;
 определение процедур управления программой;
 формирование офиса управления программой;
 создание информационной системы управления про-
граммой.
Данный процесс обычно происходит незамедлительно сра-
зу после успешной инициации программы с целью скорейшего
создания структуры, поддерживающей ее реализацию. Одна-
ко в ходе жизненного цикла программы возможны повторения
данного процесса с целью обновления и модификации инфра-
структуры программы. Изменения в инфраструктуре программы
должны быть одобрены комитетом по управлению программой.
Назначение основных исполнителей работ программы
включает определение (наряду с менеджером программы, по-
именованным уже в уставе программы) следующих ключевых
индивидуальных и коллективных стейкхолдеров программы:
 офиса управления программой;
 руководящего комитета программы;
 ключевых специалистов, разработчиков и консультантов.
64 Глава 1
NB! Необязательно все ключевые участники должны быть

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

и процедур по привлечению в программу людских, техноло-
гических, материальных, информационных и других организа-
ционных (но не финансовых) ресурсов.
При разработке плана ресурсов программы необходимо
учитывать ограничения в следующих областях:
 персонал;
 информационные источники;
 уровень компетенций;
 объемы финансирования;
 технологические возможности;
 объемы производства (для операционных компонентов
программы).
Основной объем ресурсов программы формируется на
уровне ее компонентов.
Процедуры управления программой включают контроль-
ные совещания по результатам выполнения работ программы,
которые проводятся с участием высшего руководства органи-
зации и членов программного комитета программы и на кото-
рых заслушиваются отчеты руководителей компонентов.
! Комментарий из практики. Директор портфеля проводит

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

процессов, необходимых для управления определенной ин-
фраструктурой программы.
! Комментарий из практики. К таким процессам могут от-

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

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

мирование офиса управления программой и создание инфор-
мационной системы управления программой (ИСУП). Офис
управления программой является ядром всей системы управ-
ления программой и обеспечивает поддержку всех процессов и
процедур по управлению и консолидации планов программы,
сбору и анализу информации о статусе, прогрессе и прогнозе
исполнения программы. Вся эта информация обрабатывается
в информационной системе управления программой, которая
содержит следующие компоненты:
 программные продукты, реализующие функции ИСУП;
 данные и программные документы;
 процессы и процедуры по управлению содержанием, сро-
ками, стоимостью, качеством, ресурсами, рисками и изме-
нениями программы;
 процессы и процедуры по управлению требованиями про-
граммы;
 другие требующиеся для конкретной программы средства,
процессы и процедуры.
66 Глава 1

 LL-1.3.1. Процесс разработки инфраструктуры программы
следует организовать незамедлительно сразу после успеш-
ной инициации программы с целью скорейшего создания
структуры, поддерживающей реализацию программы.
 LL-1.3.2. При разработке инфраструктуры программы не-
обходимо учитывать особенности внутренней организаци-
онной, технологической и информационной среды испол-
няющей программу компании.
 LL-1.3.3. При назначении ключевых участников програм-
мы следует анализировать состав не только индивидуаль-
ных, но и коллективных стейкхолдеров программы.
1.4. Область знаний: управление интеграцией

программы
Фаза жизненного цикла: достижение выгод программы
Процесс: управление исполнением программы
Основные цели процесса управления исполнением про-

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

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

деляют делегирование полномочий менеджера програм-
мы и руководителей компонентов для принятия обосно-
ванных решений по изменениям.
! Комментарий из практики. Кроме анализа изменений в от-

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

неджера программы по передаче компонента в другую про-
68 Глава 1
грамму или в операционную деятельность компании и о

закрытии компонента по его завершении или в случае необхо-
димости досрочного прекращения работ компонента.
Менеджер программы отвечает за соответствие всех дей-
ствий в ходе исполнения программы:
 требованиям к управлению программой и ее результатам;
 ожиданиям заинтересованных сторон;
 указаниям руководства компании;
 параметрам программы;
 ограничениям, отраженным в плане управления про-
граммой.
Выходами процесса являются:
 инициированные компоненты программы;
 запросы об изменении компонентов;
 результаты компонентов и компоненты, подготовленные к
передаче;
 завершенные или досрочно закрытые компоненты про-
граммы.
В этом процессе может использоваться также реестр по-
тенциальных проблем программы (program issues register).
В данном реестре отражаются не реальные, а пока еще по-
тенциальные проблемы или «открытые вопросы» программы,
которые желательно «закрыть», пока они еще не стали реаль-
ностью. Если же это произойдет, то может быть уже поздно, и
проблема нанесет программе непоправимый ущерб.
! Комментарий из практики. Как правило, реестр потенци-

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

 LL-1.4.1. Менеджер программы должен обеспечить со-
ответствие всех выполняемых работ программы плану
управления программой и исключить возможность вы-
полнения работ, не предусмотренных планом управления
программой и находящихся за пределами рамок содержа-
ния программы.
 LL-1.4.2. Изменения, возникающие во взаимосвязях и за-
висимостях между компонентами программы и находящи-
еся вне поля зрения руководителей отдельных компонен-
тов, могут привести к неудаче в объединении результатов
отдельных компонентов и достижении выгод программы.
Такие изменения должны быть предметом пристального
внимания менеджера программы.
 LL-1.4.3. Важна проактивная позиция менеджера програм-
мы по разрешению потенциальных проблем на ранних
стадиях их возникновения.
1.5. Область знаний: управление интеграцией

программы
Процесс: мониторинг и контроль исполнения программы
Основные цели процесса мониторинга и контроля испол-

нения программы:
 сбор, измерение и распространение информации об ис-
полнении и оценка всех трендов программы;
 проведение корректирующих, проактивных действий и ра-
бот по исправлению ошибок в управлении программой;
 управление изменениями, возникающими в ходе исполне-
ния программы.
Интерпретация процесса мониторинга и контроля ис-
полнения программы и рекомендации автора по его при-
менению на практике. Мониторинг и контроль исполнения
программы включает:
 анализ отклонений;
 анализ рисков;
70 Глава 1
 анализ потенциальных проблем;

 анализ трендов и вероятностный анализ;
 проведение корректирующих и проактивных действий по
управлению программой.
Корректирующие действия связаны с коррекцией планов
управления программой. Проактивные действия связаны с
превентивными шагами по управлению рисками и потенци-
альными проблемами программы.
! Комментарий из практики. Данные планов компонентов

программы, необходимые для эффективного мониторинга и кон-
троля хода выполнения программы, могут включать только:
 расписание контрольных точек (milestones) компонентов;
 базовый стоимостной план (cost baseline) компонентов.
Эти планы высокого уровня включают ориентиры по срокам
и стоимости этапов жизненного цикла каждого компонента, ко-
торые детализируются руководителями компонентов до уровня
пакетов работ и операций компонентов программы.
Отчеты об исполнении работ программы включают сведе-

ния, позволяющие менеджеру программы оценить:
 статус исполнения сроков и освоения бюджета про-
граммы;
 потенциальные проблемы и риски;
 ресурсные проблемы;
 проблемы с исполнением контрактов поставщиков;
 технические и организационные проблемы.
Анализ исполнения программы может включать четыре
вида анализа.
Анализ отклонений (gap analysis) — позволяет оценить от-
клонения в стоимости, расписании и достижении выгод про-
граммы.
Анализ рисков (risk analysis) — позволяет проводить не-
прерывный мониторинг и оценку состояния рисков програм-
мы, критически важные для успеха любой программы.
NB! Эффективный мониторинг и контроль рисков про-

граммы должен подтверждать адекватность и эффектив-
ность реализации планов реагирования на риски про-
граммы. В противном случае возникает необходимость
пересмотра рисков программы и изменения планов
реагирования.
Анализ потенциальных проблем (issue analysis) — позво-

ляет назначить потенциальным проблемам приоритеты и вла-
дельцев (issue owners), отвечающих за своевременное решение
потенциальной проблемы (пока она еще не стала проблемой
реальной). Анализ потенциальных проблем включает оцен-
ку их влияния на работы, ресурсы и результаты программы и
определение путей решения.
Потенциальная проблема, по определению стандарта
PMI, — незапланированное событие, обеспокоенность или
диспут, которые могут оказать влияние на стоимость, расписа-
ние, техническую архитектуру или другие области программы.
NB! Следует отличать потенциальную проблему от риска

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

носится в перечень потенциальных проблем (пример формата
этого документа представлен ниже) и должна быть проана-
лизирована офисом управления программой. Обзоры статуса
потенциальных проблем включают анализ данного перечня на
регулярной основе (например, один раз в две недели) с целью
отслеживания результатов работ по их разрешению.
72 Глава 1
NB! В случае возникновения срочных потенциальных

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

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

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

ден ниже:
Пла- Статус Форму-

Описание новая поиска лировка
№
потенциальной Владелец дата решения на и дата
п/п
проблемы реше- контроль- найденного
ния ную дату решения
Анализ трендов и вероятности успеха программы (trend

and probability analysis) — позволяет использовать различные
метрики программы, такие как отклонения по стоимости, сро-
кам, агрегированные оценки рисков, — в целях попытки пред-
видеть вероятности успеха и краха программы.
! Комментарий из практики. Анализ трендов и вероятности

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

нением программы являются отчеты об исполнении и про-
гнозы программы. Отчеты об исполнении программы часто
являются обобщением отчетов о результатах работ ее компо-
нентов.
74 Глава 1
! Комментарий из практики. Обязательными разделами от-

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

 LL-1.5.1. Эффективный мониторинг и контроль рисков
программы должен подтверждать адекватность и эффек-
тивность реализации планов реагирования на риски про-
граммы.
 LL-1.5.2. Анализ трендов и вероятности успеха программы
может использовать получаемые результаты компонентов
программы для оценки их вклада в достижение выгод про-
граммы на всех этапах ее жизненного цикла.
 LL-1.5.3. Следует отличать потенциальную проблему от
риска программы. Риск может быть описан двумя парамет-
рами: вероятностью возникновения и уровнем влияния.
Потенциальная проблема может быть описана только па-
раметром ее влияния на программу.
 LL-1.5.4. Владелец потенциальной проблемы, назначен-
ный менеджером программы, должен обладать необходи-
мыми полномочиями и средствами, позволяющими ему
своевременно разрешить потенциальную проблему.
 LL-1.5.5. Менеджеру программы следует принимать на
себя определенную ответственность для отсева тех потен-
циальных проблем, которые не могут представлять значи-
тельной угрозы для достижения целей программы.
 LL-1.5.6. Одним из решений по закрытию потенциальной
проблемы может быть ее принятие, не требующее каких-
либо действий. В случае принятия решения по проведе-
нию каких-либо действий и работ по закрытию проблемы
потребуется изменение плана управления программой.

Фаза жизненного цикла: завершение программы
Процесс: передача результатов программы и поддержка
выгод
Основные цели процесса передачи результатов программы

и поддержки выгод:
 передача отдельных результатов программы и поддержка
полученных выгод;
 поддержание удовлетворения заказчика программы ее ре-
зультатами и выгодами.
Интерпретация процесса передачи результатов про-
граммы и поддержки выгод и рекомендации автора по его
применению на практике. Некоторые компоненты програм-
мы могут завершаться одномоментным достижением выгоды,
в то время как другие компоненты могут обеспечивать про-
должительный процесс достижения выгод в бизнесе компании.
Например, открытие офиса компании в регионе и получение
определенной доли рынка (market share) может означать факт
получения выгоды по расширению присутствия компании на
рынке, а работа операционного компонента программы по
эксплуатации прибыльного производственного предприятия
может означать процесс получения выгоды компании по до-
ходу и прибыли. Определенные компоненты программы могут
потребовать передачи их результатов в компанию заказчика
программы и организации процесса поддержки эксплуатации
этих результатов для продолжительного извлечения выгоды
(on-going benefit). Например, процесс поддержки выгод (ben-
efit sustainment) может быть обеспечен в ходе операционной
эксплуатации продуктов проектов, гарантийного и послега-
рантийного обслуживания оборудования, инициации новых
проектов по повышению выгоды программы. После заверше-
ния программы поддержка выгод может быть передана в ком-
панию заказчика программы.
76 Глава 1
Выходами процесса являются переданные результаты

программы и оказанная поддержка полученных выгод.

 LL-1.6.1. Процесс поддержки излечения выгод программы
позволяет компании продолжительно эксплуатировать ре-
зультаты программы.
 LL-1.6.2. Инициация новых проектов в рамках программы
может повысить ее выгоды.

Процесс: закрытие программы
Основные цели процесса закрытия программы:

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

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

извлеченные в ходе ее выполнения уроки и заносятся в еди-
ную базу данных извлеченных уроков программ компании.
Наиболее значимые извлеченные уроки помещаются в заклю-
чительный отчет о закрытии программы.
Программа приходит к своему завершению при достиже-
нии ее результатов либо по рекомендации раннего завершения
программы в результате обзора результатов фазы программы
(phase gate review). В случае достижения результатов програм-
мы полученные при этом выгоды (benefits) могут быть уже
реализованы компанией или будут извлекаться в процессах
операционной эксплуатации результатов программы в течение
некоторого времени. Этот процесс должен быть описан в пла-
не передачи программы (program transition plan), одного из
входов процесса закрытия программы.
! Комментарий из практики. Программа может быть завер-

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

пенное высвобождение ее ресурсов.
78 Глава 1
В заключительном отчете программы отражаются сведе-

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

 LL-1.7.1. Процесс административного закрытия програм-
мы не должен ожидать формального закрытия всех ком-
понентов программы. Данный процесс выполняется при
завершении каждого компонента программы в целях:
– сбора информации о полученных результатах компо-
нента, влияющих на результаты программы в целом;
– информирования стейкхолдеров программы о заверше-
нии компонента;
– подписания акта завершения компонента ее спонсором
или заказчиком (в роли которого часто выступает ме-
неджер программы).
 LL-1.7.2. Программа может быть завершена и без переда-
чи ее результатов в операционную деятельность органи-
зации. Это может произойти в случае, если полученные
в ходе работ программы выгоды уже реализованы компа-
нией либо по решению о раннем завершении программы
в результате обзора результатов фазы программы, свиде-
тельствующего о нецелесообразности ее продолжения для
компании.
 Бизнес-кейс «Программа технологического

перевооружения металлургического комбината»
Проблемная ситуация. Потенциальная проблема, по опреде-
лению стандарта PMI, — незапланированное событие, обес-
покоенность или диспут, которые могут оказать влияние на
стоимость, расписание, техническую архитектуру или другие
области программы. Можно сказать, что потенциальная про-
блема это «открытый вопрос», который надо постараться по-
быстрее «закрыть», пока он еще не перерос в реальную про-
блему.
Описание бизнес-кейса. Программа технологического
перевооружения металлургического комбината была посвяще-
на закупке, наладке и запуску новой технологической линии
основного производства с целью выпуска высококачественной
сталелитейной продукции и выхода комбината на мировые
рынки. На совещании команды управления программой руко-
водитель компонента наладки и запуска новой технологичес-
кой линии доложил менеджеру программы о потенциальной
проблеме в подготовке линии к сдаче в опытную эксплуата-
цию. Сжатые сроки, установленные менеджером программы
для завершения работ компонента, не позволяли провести все
процедуры контроля качества выпускаемой продукции. Ме-
неджер программы отклонил предложение руководителя ком-
понента по пересмотру сроков работ компонента, сославшись
на решение руководства комбината, утвердившего жесткие
сроки завершения всей программы. Тем не менее руководи-
тель офиса управления программой записал данную ситуацию
в журнал потенциальных проблем программы и назначил от-
ветственным руководителя компонента. Данный руководитель
не обладал необходимым уровнем полномочий для решения
данной проблемы и не смог повлиять на изменение сроков
работ компонента. В результате линия была сдана в опытную
эксплуатацию без прохождения всех необходимых процедур
контроля качества, и продукция комбината оказалась неудов-
летворяющей требованиям мировых стандартов качества. Цель
программы по выходу комбината на мировые рынки оказалась
недостигнутой. Этого можно было бы избежать, если бы ме-
80 Глава 1
неджер программы «взял на свои плечи» разрешение данной

потенциальной проблемы. Обладая необходимыми полномо-
чиями, он мог бы эскалировать данную ситуацию куратору
программы, программному комитету или руководству ком-
бината с целью пересмотра сроков завершения компонента
и всей программы из-за риска потери качества выпускаемой
продукции.
Выводы и рекомендации. Важно, чтобы владелец потен-
циальной проблемы, назначенный менеджером программы,
обладал необходимыми полномочиями и средствами, позво-
ляющими ему своевременно разрешить потенциальную про-
блему. В случае невозможности разрешения потенциальной
проблемы на уровне ее владельца инициируется эскалация
проблемы на более высокие уровни управления программой
вплоть до ее разрешения.
ГЛАВА 2
Содержание программы
Назначение области знаний «Управление содержанием

программы» стандарта PMI The Standard for Program
Management®. В данной области знаний стандарта описана
одна из девяти ключевых компетенций руководителя програм-
мы по управлению содержанием программы. Два процесса,
рекомендованных стандартом в данной области знаний, отно-
сятся к фазам жизненного цикла определения и достижения
выгод программы (табл. 6).
Таблица 6
Процессы и фазы жизненного цикла области знаний
«Управление содержанием программы»
Процесс Фаза жизненного цикла
Планирование содержания программы Определение программы
Контроль содержания программы Достижение выгод программы
Описания данных процессов и рекомендаций автора по их

применению приводятся далее.

управление содержанием программы
Процесс: планирование содержания программы
Основные цели процесса планирования содержания про-

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

практике. В ходе планирования содержания программы ее
менеджер должен организовать проведение работ, обеспечива-
ющих:
 анализ содержания работ программы и границ содержа-
ния;
 определение критериев приемки результатов;
 разработку описания содержания программы;
 разработку плана управления содержанием программы;
 разработку иерархической структуры работ программы.
Содержание программы принципиально отличается от
содержания продукта, который может быть результатом про-
граммы или ее компонента.
Содержание программы описывает состав работ про-
граммы, которые должны быть выполнены для получения
окончательного результата программы в виде финального про-
дукта, услуги или выгоды с заданными характеристиками.
Содержание продукта описывает состав характерис-
тик (или функций), обеспечивающих эксплуатацию оконча-
тельного результата программы в виде финального продукта
или услуги.
NB! Характеристики выгоды (benefit metrics) как оконча-

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

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

лении работ и целях программы, ее промежуточных и оконча-
тельных результатах и основных контрольных событиях.
При анализе содержания работ программы производят-
ся обмен экспертными оценками и активное использование
информационной системы управления программой.
Двумя основными методами обмена экспертными оценка-
ми являются:
1) мозговой штурм (brainstorm);
2) метод Дельфи.
Мозговой штурм является открытым, интенсивным обсуж-
дением вопроса, проблемы или определенной темы (напри-
мер, в данном процессе — темы плана управления содержа-
нием программы). Участниками мозгового штурма являются
эксперты, заранее ознакомленные с темой обсуждения. Зада-
ча ведущего (фасилитатора) мозгового штурма заключается в
«разогреве» воображения экспертов, фиксации всех высказы-
ваемых мнений и направлении общей дискуссии в конструк-
тивное русло поиска их согласованного мнения.
Метод Дельфи является анонимным (закрытым) и ите-
рационным обсуждением определенного вопроса, проблемы
или темы. Организатор опроса запрашивает мнения опреде-
ленного количества экспертов по определенной теме, полу-
чает ответы экспертов и знакомит каждого из них с ответами,
полученными от других экспертов, затем просит дать новые
варианты ответов экспертов (вторая итерация опроса), снова
знакомит их с мнениями других экспертов, просит снова дать
новые варианты ответов (третья итерация) и т. д. Число ите-
раций опроса экспертов в данном методе зависит от многих
факторов:
 числа опрашиваемых экспертов;
 уровня их компетенции по обсуждаемому вопросу;
 независимости от других экспертов;
 отсутствия конфликта интересов;
 доступа всех опрашиваемых экспертов к одной и той же
информации о программе.
84 Глава 2
! Комментарий из практики. Все опрашиваемые эксперты

должны иметь доступ к одной и той же и как можно более полной
информации о программе. Если кто-то из экспертов не ознаком-
лен с информацией о программе, известной другим экспертам,
его участие в опросе будет неполноценным. Полнота доступной
для экспертов информации о программе должна обеспечить до-
стоверность результатов экспертного опроса. В связи с этим в
данном процессе рекомендуется активное использование инфор-
мационной системы управления программой, содержащей все
известные на момент проведения экспертного опроса данные и
сведения о программе. Различные экспертные группы могут быть
организованы для обсуждения содержания видения решения про-
граммы, ограничений в ресурсах, потенциальных рисков или гра-
ниц содержания.
NB! Границы содержания программы (program boun-

daries) должны описывать те работы программы, кото-
рые не следует ожидать, потому что они не будут выпол-
нены по причинам отсутствия необходимых ресурсов,
высоких рисков или нежелания ключевых стейкхолдеров
их выполнять.
Границы содержания программы необходимо «закрепить»,

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

изменении требований заказчика и ожиданий конечных
пользователей (end-user expectations) результатов про-
граммы. После утверждения программным комитетом
новых границ содержания программы менеджер про-
граммы обязан придерживаться обновленных границ и не
выполнять работы, лежащие за их пределами.
! Комментарий из практики. Известен эффект «располза-

ния» границ содержания программы (scope creep), возникаю-
щий при частых изменениях содержания программы, не зафик-
сированных в планах программы и отчетах об изменениях. При
этом менеджер программы оказывается не в состоянии удержать
содержание программы в рамках ее четких границ… Неконтро-
лируемые (и неуправляемые) изменения содержания программы
и ее границ являются основным источником проблем и неудач
в управлении программами.
При определении содержания программы важно также

провести анализ требований заказчика по приемке результатов
программы. В целях достижения конечных целей программы
и удовлетворения ее заказчика необходимо определить задачи,
которые обеспечат:
 раннее выявление потенциальных проблем в процессе
приемки результатов программы заказчиком;
 улучшение результатов для удовлетворения требований за-
казчика;
 повышение уверенности заказчика в успешном достиже-
нии результатов программы.
Сбор и анализ требований к программе проводятся с по-
мощью интервью с опытными участниками и экспертами в
предметной области (subject matter experts), анкетирования и
опросов стейкхолдеров программы. Анализ и обзор собранных
требований должны подтвердить, что требования являются
полными, достоверными и непротиворечивыми и при необхо-
димости должны включать декомпозицию собранных требова-
ний высокого уровня на более мелкие компоненты с помощью
экспертов в предметной области программы.
Мозговые штурмы и обмен экспертными оценками стейк-
холдеров программы позволяют провести всесторонний сбор,
анализ и обзор требований программы.
Проверка и утверждение требований позволяют оконча-
тельно удостовериться, что определенные требования про-
граммы являются полными и точными.
86 Глава 2
NB! Требования к программе часто меняются в ходе вы-

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

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

ния ее выгод. Они могут включать требования бизнеса компа-
нии и внешней среды программы, а также требования техни-
ческого и юридического характера.
NB! Требования к программе не должны описывать тех-

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

ния программы, план управления содержанием программы и
иерархическая структура работ (ИСР программы).
Описание содержания программы (program scope state-
ment) — документ, отражающий содержание, ограничения и
предположения программы и влияние результатов программы
на бизнес компании. Стандарт рекомендует наличие следую-
щих разделов в данном документе:
 организационные нужды и требования;
 начальные, высокоуровневые требования к продукту;
 высокоуровневое видение решения поставленных задач;
 допущения и ограничения.
Допущения являются предположениями команды про-
граммы относительно наличия в будущем определенных ре-
сурсов, решений, документов, событий и т. п., не требующих
доказательств.
NB! Допущения (особенно не в достаточной степени

обоснованные) часто являются источниками рисков про-
граммы.
Ограничения описывают ресурсные ограничения програм-

мы (например, ограничения сроков, бюджета, доступности че-
ловеческих, материальных, технологических и других ресурсов).
! Комментарий из практики. Описание содержание програм-

мы может быть подготовлено в результате серии совещаний с клю-
чевыми стейкхолдерами программы (program kick-off meetings),
в ходе которых осуществляется активный обмен экспертными
мнениями. Основная задача таких совещаний — договориться с
ключевыми стейкхолдерами об общем понимании сути програм-
мы и ее содержания, «снять» потенциальные конфликты, которые
могут проявиться в будущих этапах планирования и выполнения
программы.
План управления содержанием программы является од-

ним из многих планов, входящих в общий план управления
программой. Основная задача данного плана — описание про-
цессов управления изменениями, возникающими в содержа-
нии программы в ходе ее планирования и выполнения. Дан-
ный план должен содержать ответы на вопросы «как»:
 как будут определяться и классифицироваться изменения
в содержании;
 как будет организован процесс управления изменениями
в содержании;
 как изменения в содержании будут отражаться в общем
плане управления программой?
В ходе процесса разработки ИСР программы (Work Break-
down Structure — WBS) используется метод декомпозиции —
разбиения целей программы, работ и фаз на более мелкие
управляемые компоненты.
NB! ИСР программы является основным документом, ис-

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

мониторинга и контроля работ программы и ее компонен-
тов. ИСР является ориентированной на результаты програм-
мы иерархической структурой, полностью описывающей со-
держание программы и продукты ее компонентов. Работы, не
включенные в состав элементов ИСР, находятся за пределами
границ содержания программы (out of scope). Работы, опи-
санные в качестве элементов ИСР, должны быть выполнены
в ходе жизненного цикла программы и находятся в пределах
границ содержания (in scope).
NB! Работы по управлению программой должны быть
описаны в качестве элементов одной из ветвей ИСР, в
том числе работы менеджера программы, офиса управ-
ления программой и программного комитета.
! Комментарий из практики. ИСР является ключевым ин-

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

да декомпозиции используется движение «сверху вниз» (top
down) — от целей программы на верхнем уровне ИСР к под-
целям, задачам, подзадачам на последующих более низких
уровнях ИСР. Движение «снизу вверх» (bottom up) по уровням
ИСР используется в других процессах стандарта, в том числе в
определении ресурсов и стоимости работ программы.
! Комментарий из практики. При формировании в ходе де-

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

декомпозиции завершается на уровне передачи управления
от менеджера программы к руководителям компонентов про-
граммы. Как правило, этот уровень является верхним уровнем
(или двумя верхними уровнями) ИСР компонентов програм-
мы, описывающим цели проектов, или блоков операционной
деятельности, входящих в программу. Данный уровень разде-
ляет ответственность менеджера программы за работы про-
граммы и ответственность руководителей ее компонентов.
Элементы данного уровня ИСР являются пакетами програм-
мы (program packages). После получения ИСР программы ру-
ководители компонентов могут проводить дальнейшую, более
детальную декомпозицию и разработку ИСР компонентов до
уровня пакетов работ (work packages) компонентов.
Пример ИСР программы представлен на рис. 16.
Уникальные результаты пакетов работ проектов, входя-
щих в программу, а также систематические результаты блоков
операционной деятельности программы консолидируются в
общие результаты программы, обеспечивающие достижение
бизнес-выгод компании (рис. 17).
NB! Менеджер программы несет ответственность за кон-

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

граммы (в том числе описание требуемых ресурсов, зависи-
мостей, воздействия внешних факторов и других полезных
комментариев) может быть представлено в отдельном доку-
менте — матрице ИСР (PWBS matrix).
В качестве входов данного процесса используются базо-
вая архитектура программы, описывающая взаимосвязи ком-
понентов, а также требования к программе и ее компонентам.
Основными инструментами процесса являются эксперт-
ные оценки, шаблоны ИСР, процессы управления планирова-
нием, матрица ответственности и система управления конфи-
гурацией.
Рис. 16. Пример ИСР программы
Рис. 17. Консолидация результатов компонентов

в общие результаты программы
Всякая декомпозиция основана на использовании экс-

пертных оценок членов команды и ключевых стейкхолдеров
программы.
92 Глава 2
NB! Для построения ИСР на основе проведения эффек-

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

программным офисом компании либо внешними професси-
ональными консалтинговыми компаниями. Процессы управ-
ления планированием должны обеспечить соответствие ре-
зультатов программы, отраженных в качестве элементов ИСР,
бизнес-целям компании. Матрица ответственности (responsi-
bility assignment matrix — RAM) фиксирует ответственность
ролей членов команды программы за достижение результатов
программы. По строкам такой матрицы представлены резуль-
таты работ программы, отраженных в ИСР, а по столбцам —
роли членов команды программы. На пересечении строк и
столбцов назначаются элементы — «легенды», описывающие
индивидуальные действия ролей по достижению коллектив-
ных результатов программы. Элементы легенды могут быть
различными, так как отражают специфику и предметную об-
ласть работ программы. Пример матрицы ответственности
представлен на рис. 18.
Роль 1 Роль 2 … Роль M
Результат 1 Консультирует Разрабатывает Согласовывает
Результат 2 Разрабатывает Согласовывает Утверждает
Результат N
Рис. 18. Пример матрицы ответственности

! Комментарий из практики. Разработка матрицы ответ-

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

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

 LL-2.1.1. Характеристики выгоды как окончательного ре-
зультата программы должны быть описаны в определен-
ных метриках (например, в денежных единицах дохода,
прибыли организации или временных характеристиках
периода возврата инвестиций, момента окупаемости
и т. п.).
 LL-2.1.2. Все опрашиваемые эксперты должны иметь дос-
туп к одной и той же и как можно более полной инфор-
мации о программе. Если кто-то из экспертов не озна-
комлен с информацией о программе, известной другим
экспертам, его участие в опросе будет неполноценным.
Полнота доступной для экспертов информации о про-
грамме должна обеспечить достоверность результатов экс-
пертного опроса.
 LL-2.1.3. Допущения (особенно не в достаточной степени
обоснованные) часто являются источниками рисков про-
граммы.
94 Глава 2
 LL-2.1.4. Описание содержание программы может быть

подготовлено в результате серии совещаний с ключевыми
стейкхолдерами программы, в ходе которых осуществля-
ется активный обмен экспертными мнениями. Основная
задача таких совещаний — договориться с ключевыми
стейкхолдерами об общем понимании сути программы и
ее содержания, «снять» потенциальные конфликты, кото-
рые могут проявиться в будущих этапах планирования и
выполнения программы.
 LL-2.1.5. Границы содержания программы должны описы-
вать те работы программы, которые не следует ожидать,
потому что они не будут выполнены по причинам отсут-
ствия необходимых ресурсов, высоких рисков или нежела-
ния ключевых стейкхолдеров их выполнять.
 LL-2.1.6. Границы содержания программы необходимо
«закрепить», чтобы исключить завышенные, неоправдан-
ные ожидания стейкхолдеров в проведении работ и полу-
чении результатов, которые не будут достигнуты.
 LL-2.1.7. Определение границ содержания программы спо-
собствует достижению удовлетворения заказчика програм-
мы ее результатами, описанными в четких рамках границ
содержания.
 LL-2.1.8. Границы содержания программы могут меняться
при изменении требований заказчика и ожиданий конеч-
ных пользователей результатов программы. После утверж-
дения программным комитетом новых границ содержания
программы менеджер программы обязан придерживаться
обновленных границ и не выполнять работы, лежащие за
их пределами.
 LL-2.1.9. Неконтролируемые (и неуправляемые) измене-
ния содержания программы и ее границ являются основ-
ным источником проблем и неудач в управлении програм-
мами.
 LL-2.1.10. Требования к программе часто меняются в ходе
выполнения ее работ. Изменения в требованиях програм-
мы должны быть проанализированы с точки зрения их
выполнимости и влияния на успех программы.
 LL-2.1.11. По мере получения результатов и продуктов

программы изменения в требованиях должны быть про-
анализированы и проверены на предмет их соответствия
заявленным требованиям. Официальное подтверждение
соответствия продуктов программы заявленным требова-
ниям может включать тесты и инспекции продуктов.
 LL-2.1.12. Требования к программе не должны описывать
технические требования к характеристикам продуктов ее
компонентов. Требования к компонентам программы яв-
ляются результатом декомпозиции высокоуровневых тре-
бований программы до уровня детальных требований по
созданию продуктов ее компонентов.
 LL-2.1.13. ИСР программы является основным докумен-
том, используемым менеджером программы для планиро-
вания, организации и управления работами программы.
 LL-2.1.14. Работы по управлению программой должны
быть описаны в качестве элементов одной из ветвей ИСР,
в том числе работы менеджера программы, офиса управ-
ления программой и программного комитета.
 LL-2.1.15. ИСР является ключевым инструментом для ор-
ганизации коммуникационных взаимодействий менеджера
программы и руководителей компонентов программы.
 LL-2.1.16. При формировании в ходе декомпозиции переч-
ня элементов на каждом из уровней ИСР полезно приме-
нять метод базиса, который должен обеспечить:
– конечное число элементов на каждом из уровней
ИСР;
– уникальность (отсутствие дублей) среди элементов ИСР
на каждом из уровней;
– обязательное выполнение элемента вышестоящего
уровня при полном выполнении всех элементов, входя-
щих в него на более низком уровне ИСР.
 LL-2.1.17. Уникальные результаты пакетов работ проектов,
входящих в программу, а также систематические результа-
ты блоков операционной деятельности программы консо-
лидируются в общие результаты программы, обеспечиваю-
щие достижение бизнес-выгод компании.
96 Глава 2
 LL-2.1.18. Разделение управления между менеджером про-

граммы и руководителями компонентов на уровне пакетов
программы ИСР обеспечивает их совместную ответствен-
ность — как «сверху», так и «снизу» за уровень компонен-
тов программы: ответственность («снизу») руководителей
компонентов за построение их ИСР и достижение резуль-
татов компонентов и ответственность («сверху») менеджера
программы за руководство руководителями компонентов.
 LL-2.1.19. Менеджер программы несет ответственность за
консолидацию результатов компонентов в общие результа-
ты программы, поддерживающие достижение бизнес-вы-
год компании.
 LL-2.1.20. Для построения ИСР на основе проведения эф-
фективной декомпозиции и обмена экспертными оценка-
ми необходимо наличие в команде программы экспертов
в предметной области программы, обладающих опытом в
проведении подобных программ.
 LL-2.1.21. Разработка матрицы ответственности позволяет
менеджеру программы эффективно распределить ответ-
ственность за достижение результатов программы между
различными членами команды программы. Строки мат-
рицы ответственности показывают распределение инди-
видуального вклада различных ролей команды в достиже-
ние конкретного результата, а столбцы — ответственность
конкретной роли в достижении определенных результатов
программы.

управление содержанием программы
Процесс: контроль содержания программы
Основные цели процесса контроля содержания программы:

 рассмотрение и контроль содержания программы в ходе
выполнения программы с точки зрения ее успешного за-
вершения;
 управление изменениями в содержании программы.
Интерпретация процесса контроля содержания про-

граммы и рекомендации автора по его применению на
практике. Контроль содержания программы должен обеспе-
чить «сохранность границ» содержания и достижение требу-
емых результатов и выгод программы. Изменения в содер-
жании программы могут повлиять на границы содержания
и результаты программы. Ответственностью менеджера про-
граммы является определение влияния изменения на цели,
содержание программы и критические для целей программы
изменения содержания ее компонентов. При положительном
решении о принятии изменения в содержании программы
менеджер программы должен учесть влияние этого измене-
ния и обновить описание содержания и ИСР программы.
Менеджер программы не должен отвечать за рабочие, теку-
щие изменения в содержании компонентов программы —
за контроль этих изменений отвечают руководители компо-
нентов.
Процесс контроля содержания является критически важ-
ным для успеха выполнения особенно крупных, сложных по
содержанию и длительных программ. Основными источника-
ми изменения содержания и значительного влияния на выпол-
нение компонентов или программы в целом могут быть:
 стейкхолдеры;
 внутренняя среда компании;
 внешняя среда (включая экономические, политические,
законодательные, конкурентные факторы).
Любое потенциальное изменение содержания программы
и ее компонентов должно быть проанализировано на предмет
выявления его влияния на достижение результатов и целей
программы.
NB! Процесс управления изменениями содержа-

ния программы основан на иерархической процедуре
эскалации изменений и взаимодействии комитетов по
управлению изменениями программы и ее компонентов
(рис. 19).
98 Глава 2
Комитет
по управлению изменениями
программы
Изменения в содержании
программы, влияющие
на содержание компонента
Изменения в содержании
компонента, влияющие
на содержание программы
и/или ее компонентов
Комитет
по управлению изменениями
компонента программы
Рис. 19. Взаимодействие комитетов по управлению

изменениями программы и ее компонентов
Существенные изменения в содержании компонента, вли-

яющие на содержание программы, должны быть эскалирова-
ны на заседание программного комитета. В то же время из-
менения в содержании программы, влияющие на содержание
компонента, должны быть направлены на рассмотрение ко-
митета по изменениям компонента для проведения детального
анализа его влияния на содержание компонента. Результаты
такого анализа должны быть направлены для рассмотрения
программного комитета и определения влияния изменения на
содержание других компонентов и на взаимодействие компо-
нентов.
Кроме управления запросами на изменения содержания
программы и ее компонентов в данном процессе также осу-
ществляется управление запросами на передачу компонентов
(component transition request). Данные запросы могут описы-
вать либо необходимость передачи компонента в другие на-
правления работ программы (например, в подпрограммы или
блоки операционной деятельности), либо необходимость фор-

мального закрытия компонента.
! Комментарий из практики. Запрос на формальное закры-

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

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

 LL-2.2.1. Процесс управления изменениями содержания
программы основан на иерархической процедуре эскала-
ции изменений и взаимодействии комитетов по управле-
нию изменениями программы и ее компонентов.
 LL-2.2.2. Запрос на формальное закрытие компонен-
та программы должен быть направлен на заседание про-
граммного комитета в случае завершения работ и полу-
чения требуемых результатов компонента либо в случае
необходимости остановки работ компонента из-за невоз-
можности/отсутствия необходимости их продолжения.
 Бизнес-кейс «Программа внедрения

системы оценки КПЭ сотрудников компании»
Проблемная ситуация. Описание содержания програм-
мы может быть подготовлено в результате серии совещаний
с ключевыми стейкхолдерами программы, в ходе которых
100 Глава 2
осуществляется активный обмен экспертными мнениями.

Основная задача таких совещаний — договориться с ключевы-
ми стейкхолдерами об общем понимании сути программы и ее
содержания, «снять» потенциальные конфликты, которые мо-
гут проявиться в будущих этапах планирования и выполнения
программы.
Описание бизнес-кейса. Программа внедрения систе-
мы оценки ключевых показателей эффективности (КПЭ)
(key performance indicators — KPI) была инициирована пре-
зидентом компании и имела целью значительное повышение
эффективности работы сотрудников на всех уровнях управле-
ния. Менеджером программы был назначен вице-президент
компании, курирующий работу основных производственных
подразделений. Для определения содержания программы ме-
неджер программы организовал проведение серии совещаний
с ключевыми стейкхолдерами программы, которыми явля-
лись руководители производственных подразделений, отделов
маркетинга и продаж, сбыта и рекламы, а также планового
отдела, бухгалтерии и отдела кадров. В ходе данных совеща-
ний выяснилось, что руководители различных подразделе-
ний по-разному понимают цели программы по повышению
эффективности управления компанией. Руководители про-
изводственных подразделений считали, что эффективность
управления должна быть измерена на основе таких КПЭ,
как объем и качество выпускаемой продукции. Руководители
маркетинга и продаж предложили КПЭ по увеличению про-
даж продукции на рынке, а руководитель отдела кадров наста-
ивал на КПЭ по снижению текучести кадров и повышению
морального климата в коллективах подразделений компании.
Менеджеру программы не удалось провести декомпозицию
цели программы на подцели и задачи отдельных подразделе-
ний и связать оценки выполнения задач с единой и строй-
ной системой КПЭ. В результате программа распалась на ряд
проектов структурных подразделений, не связанных в еди-
ный комплекс мероприятий по повышению эффективности
управления.
Выводы и рекомендации. Ключевыми обязанностями

менеджера программы в области управления содержанием
программы является организация работ по разработке описа-
ния содержания и ИСР программы. Для определения содер-
жания программы менеджер программы должен организовать
проведение активного обсуждения содержания с ключевыми
стейкхолдерами и добиться их единого понимания целей, задач
программы и способов достижения и оценки ее результатов.
Отсутствие такого единого понимания приводит к противоре-
чиям, конфликтам, грозящим распадом программы на незави-
симые локальные проекты и полной остановкой программы.
ГЛАВА 3
Сроки программы
Значение области знаний «Управление сроками програм-

мы» стандарта PMI The Standard for Program Manage-
ment®. В данной области знаний стандарта описана одна из
девяти ключевых компетенций руководителя программы по
управлению сроками программы. Два процесса, рекомендо-
ванных стандартом в данной области знаний, относятся к фа-
зам жизненного цикла определения и достижения выгод про-
граммы (табл. 7).
Таблица 7

«Управление сроками программы»
Разработка сроков программы Определение программы
Контроль сроков программы Достижение выгод программы

3.1. Область знаний: управление сроками

программы
Процесс: разработка сроков программы
Основные цели процесса разработки сроков программы:

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

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

мы и рекомендации автора по его применению на практи-
ке. В ходе разработки сроков программы менеджер програм-
мы должен организовать проведение работ, обеспечивающих:
 определение порядка выполнения, длительностей и взаи-
мозависимостей компонентов программы, необходимых
для достижения ее выгод;
 определение критических контрольных точек (milestones),
связанных с достижением критически важных результатов
программы;
 обновления расписания программы по мере разработки
расписаний ее компонентов.
Факторами, влияющими на сроки программы, являются:
 финансовые ограничения;
 доступность ресурсов;
 технические ограничения;
 контракты;
 жесткие временные рамки;
 трудовое законодательство;
 ограничения среды;
 другие внешние зависимости.
В ходе разработки сроков программы менеджер програм-
мы осуществляет координацию и интеграцию расписаний
компонентов для обеспечения выполнения всей программы в
установленные сроки (on time).
NB! Взаимные зависимости компонентов оказывают

значительное влияние на сроки программы. Задержки в
получении результатов компонентов, необходимых для
работ других компонентов, приводят к срыву сроков по-
лучения промежуточных результатов программы. Окон-
чательные результаты программы также не могут быть
получены вовремя, так как интеграция результатов всех
компонентов программы не может быть проведена из-за
отсутствия результатов каких-либо компонентов.
104 Глава 3
Менеджер программы не должен управлять расписаниями

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

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

ной деятельности могут привести к срыву сроков всей про-
граммы. Например, несмотря на завершение проекта по раз-
работке нового продукта в установленные сроки, серийное
производство продукта в операционной деятельности пред-
приятия может быть сорвано из-за срыва сроков поставки
комплектующих материалов, что приведет к срыву сроков
программы по выводу на рынок новой продукции.
Аналогично срыв сроков завершения проекта по разра-
ботке нового продукта приведет к задержке серийного про-
изводства продукта в операционной деятельности компании
и срыву сроков всей программы. Срыв сроков программы
не позволит компании вовремя получить запланированные
выгоды или даже упустить получение выгод программы на-
всегда.
Упущенные выгоды (lost benefits) могут возникнуть по
причинам:
 отставания от конкурентов по срокам вывода на рынок
нового продукта;
 потерь дохода и прибыли из-за задержек в начале продаж
новых продуктов;
 потери актуальности продукта и интереса рынка к его ис-
пользованию.
NB! Задержки в сроках любых компонентов программы

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

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

при срыве сроков завершения проекта и задержке
в операционной деятельности эксплуатации продукта
Значения упущенной выгоды, выраженные в потерях при-

были и сроков на момент времени «T» жизненного цикла про-
граммы, показаны на рис. 21.
106 Глава 3
Доходы и расходы программы, долл.
Прибыль
Выполнение Проведение
^$ Упущенная выгода
проекта операционной
программы деятельности ^Т
0
«Т»
Сроки
программы,
Т
Доходы операционной
деятельности
Расходы
проекта
Фактический срок завершения
проекта программы
Плановый срок завершения
проекта программы
Рис. 21. Значения упущенной выгоды, выраженные

в потерях прибыли (^$) и сроков (^T) на момент времени «T»
жизненного цикла программы
Исходное расписание программы обычно разрабатывает-

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

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

включает только даты старта и финиша и последовательность
работ компонентов, а также работы по управлению програм-
мой. При дальнейшей разработке более детальных расписаний
работ компонентов наиболее значимые работы отражаются
в высокоуровневом расписании программы (program master
schedule).
NB! Термин «высокоуровневое» расписание программы

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

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

ных компонентов должны быть отражены в высокоуров-
невом расписании программы и необязательно входят в
расписания компонентов.
108 Глава 3
Основным инструментом разработки расписания про-

граммы являются программные продукты календарного
планирования. При разработке расписания администратор
программного офиса вводит в используемый программный
продукт данные о работах программы и контрольные события
компонентов. Руководители компонентов используют назна-
ченные им контрольные события при разработке детальных
расписаний компонентов. Программный продукт календарно-
го планирования используется администратором программно-
го офиса для контроля сроков выполнения работ программы и
сроков получения основных результатов компонентов. Совре-
менные программные продукты календарного планирования
(как, например, Microsoft Project Server, Primavera, PlanView,
Spider, Mercury и др.) предоставляют развитые средства веде-
ния расписаний программ с глубокими уровнями вложенности
расписаний компонентов. Такие средства позволяют менедже-
ру программы наблюдать за сроками «высокоуровневого» рас-
писания программы и при необходимости увидеть детальное
расписание компонентов программы.
NB! В программах, включающих работы внешних постав-

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

ния являются анализ выгод и анализ денежных потоков про-
граммы.
Анализ выгод (benefit analysis) должен постоянно прово-
диться менеджером программы в течение всего жизненного
цикла программы, чтобы при необходимости скорректировать
сроки и ресурсы работ программы для достижения больших
или дополнительных выгод компании.
Анализ денежных потоков программы (cash flow analy-
sis) позволяет менеджеру программы отслеживать потоки дохо-
дов и расходов и планировать выплаты подрядчикам проектов
программы в сроки, согласованные с поступлением денежных
средств от операционных компонентов программы.
Основным выходом данного процесса является высоко-

уровневое расписание программы (program master schedule),
в котором наряду со сроками работ программы отражены сро-
ки контрольных событий компонентов и взаимосвязи между
компонентами.
NB! В высокоуровневом расписании программы должны

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

(или почти все) результаты программы, получение которых к
определенным срокам обеспечивает достижение выгод про-
граммы.
! Комментарий из практики. Недостаточное внимание ме-

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

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

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

 LL-3.1.1. Взаимозависимости компонентов оказывают зна-
чительное влияние на сроки программы. Задержки в по-
лучении результатов компонентов, необходимых для работ
других компонентов, приводят к срыву сроков получения
промежуточных результатов программы. Окончательные
результаты программы также не могут быть получены во-
время, так как интеграция результатов всех компонентов
программы не может быть проведена из-за отсутствия ре-
зультатов каких-либо компонентов.
 LL-3.1.2. Внимание менеджера программы должно быть
уделено не только соблюдению сроков выполнения про-
ектов, входящих в программу, но и соблюдению сроков
получения результатов операционной деятельности, входя-
щих в программу. Задержки в получении плановых резуль-
татов операционной деятельности могут привести к срыву
сроков всей программы.
 LL-3.1.3. Задержки в сроках любых компонентов програм-
мы (как проектов, так и операционной деятельности) при-
водят к упущенным выгодам в бизнесе компании.
 LL-3.1.4. Расписание программы должно включать только
те контрольные события расписаний компонентов, ко-
торые являются значимыми для достижения результатов
всей программы либо связывают результаты разных ком-
понентов программы.
 LL-3.1.5. Термин «высокоуровневое расписание» програм-
мы отражает возможность централизованной разработки
расписания программы только на высоком уровне и де-
тальной разработки расписаний только на уроне компо-
 LL-3.1.6. Взаимозависимости получения результатов раз-
личных компонентов должны быть отражены в высоко-
уровневом расписании программы и необязательно входят

в расписания компонентов.
 LL-3.1.7. В программах, включающих работы внешних
поставщиков и подрядчиков, необходимо использовать
единые для программного офиса и внешних подрядчиков
продукты календарного планирования.
 LL-3.1.8. В высокоуровневом расписании программы дол-
жны быть отражены критически важные внешние зависи-
мости сроков, ресурсов, работ и выгод программы.
 LL-3.1.9. Недостаточное внимание менеджера программы,
уделяемое анализу взаимозависимостей контрольных со-
бытий компонентов, приводит к срыву сроков результатов
программы и упущенным выгодам компании. Причина
этого факта заключается в необходимости своевременной
консолидации результатов компонентов в соответствии с
датами расписания программы, без проведения которой
невозможно достижение выгод компании.
3.2. Область знаний: управление сроками

программы
Процесс: контроль сроков программы
Основные цели процесса контроля сроков программы:

 обеспечение своевременного достижения требуемых воз-
можностей и выгод программы;
 контроль достоверности обновлений высокоуровнево-
го расписания программы (program master schedule up-
dates).
Интерпретация процесса контроля сроков программы
и рекомендации автора по его применению на практике.
Контроль сроков программы должен обеспечить отслежива-
ние и мониторинг сроков старта и финиша компонентов про-
граммы и работ по управлению программой, а также дости-
жения контрольных событий высокоуровневого расписания
программы.
112 Глава 3
NB! Менеджер программы должен стремиться к соблю-

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

цию о сроках контрольных событий компонентов, влияющих
на высокоуровневое расписание программы.
! Комментарий из практики. Для своевременного обнару-

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

личных компонентов может привести к «лавинообразному кас-
каду задержек» критически важных работ компонентов и срыву
сроков всей программы. Задачей менеджера программы являет-
ся раннее обнаружение признаков такого процесса и его устра-
нение. Эту задачу приходится решать также с помощью анали-
за реестра рисков, используемого в данном процессе. Резервы
времени, включенные в запланированные сроки компонентов
программы, могут быть использованы менеджеров программы
для управления данными рисками. Одобренные запросы на из-
менения сроков компонентов могут повлиять на решения:
 добавления/удаления задач внутри компонента;
 добавления/удаления/приостановки компонента програм-
мы.
В данном процессе активно используются метрики про-
граммы и управление освоенным объемом.
Метрики программы определяют специфические перио-
ды, относительно которых измеряется исполнение расписания
программы.
Метрики могут определять допустимые, средние и кри-

тические периоды отставания (как и опережения) по срокам
программы. Пример метрик расписания программы приведен
в табл. 8.
Таблица 8
Пример метрик расписания программы
Период отставания/ Значение Статус расписания

опережения метрики, программы (цветовой
расписания программы % индикатор)
Допустимый 0–3 Нормальный (зеленый)
Средний 3–5 Предупреждающий (желтый)
Критический 5–10 Опасный (красный)
В данном примере, если отставание по срокам программы

составляет 7%, то метрика указывает на критический период
отставания и статус исполнения расписания является опас-
ным, о чем должен свидетельствовать красный цвет индика-
тора статуса.
NB! Если отставание по срокам программы однозначно

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

грированного измерения статуса разработки содержания, ис-
полнения расписания и бюджета программы.
Данный метод использует три основных стоимостных по-
казателя:
1) planned value (PV) — плановая стоимость работ програм-
мы (план);
2) earned value (EV) — плановая стоимость выполненных ра-
бот программы (освоенный план);
3) actual cost (AC) — фактическая стоимость выполненных
работ программы (факт).
114 Глава 3
Метод освоенного объема позволяет проводить интегри-

рованный анализ как исполнения графика, так и бюджета
программы по стоимостным показателям.
К стоимостным показателям относятся следующие:
1) отклонение по стоимости (cost variance — CV):
CV = EV – AC;
2) отклонение по срокам (schedule variance — SV):
SV = EV – PV;
3) индекс выполнения бюджета (cost performance index —
CPI):
CPI = EV / AC;
4) индекс выполнения календарного плана (schedule perfor-
mance index — SPI):
SPI = EV / PV;
5) бюджет по завершении программы (budget at completion —
BAC).
! Комментарий из практики. Расчет отклонений по стоимос-

ти (CV), срокам (SV) и индексов выполнения бюджета (CPI) и
графика (SPI) следует проводить по завершении этапа или дости-
жении контрольной точки программы.
Расчет прогнозных показателей стоимости оставшихся

невыполненными работ программы (estimate to completion —
ETC) и стоимости всей программы по ее завершении (estimate
at completion — EAC) следует также проводить по завершении
этапа или достижении контрольной точки программы. Имен-
но по завершении работ этапа или по достижении контроль-
ной точки спонсор программы может попросить менеджера
программы дать прогноз.
Показатель эффективности выполнения работ (to complete
performance index — TCPI) может быть расcчитан в любой
момент жизненного цикла программы:
TCPI = (BAC – EV) / (BAC – AC).
В числителе данного дробного показателя мы видим стои-

мостное выражение оставшихся невыполненными работ про-
граммы, а в знаменателе — остаток неизрасходованного бюд-
жета программы.
! Комментарий из практики. Регулярные вычисления пока-

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

ления высокоуровневого расписания, реестра рисков и дорож-
ной карты программы.
Обновления высокоуровневого расписания программы
включают одобренные изменения расписания программы,
возникшие в результате анализа рисков или изменений сроков
компонентов. Также обновления могут включать контрольные
события новых компонентов, добавленных в программу или
влияющих на сроки контрольных событий других компонен-
тов и программы в целом. Данные обновления могут привес-
ти к изменениям в реестре рисков программы и обновлениям
дорожной карты программы. Анализ новых рисков и сроков
компонентов программы может привести к обновлениям рас-
писаний компонентов.
NB! Необходимость ускорения или замедления сроков

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

ют статус расписания и сведения о соблюдении, опережении
или отставании в сроках исполнения работ программы и кри-
тически важных контрольных событий компонентов. Как пра-
вило, программа состоит из ряда компонентов с различными
статусами исполнения расписаний. Например, на момент под-
готовки отчета об исполнении расписания программы один
из проектов программы может выполняться в установленные
сроки, другой иметь опережение сроков на 10%, а третий —
отставание на 15%. Что можно сказать в этом случае о статусе
расписания программы в целом? Ответ на этот вопрос дол-
жен дать менеджер программы, учитывающий приоритеты от-
дельных компонентов и временные резервы высокоуровневого
расписания программы.

 LL-3.2.1. Менеджер программы должен стремиться к со-
блюдению здравого баланса между проводимым им кон-
тролем расписания компонентов и предоставлением руко-
водителям компонентов определенной свободы в принятии
решений по управлению расписаниями компонентов.
 LL-3.2.2. Для своевременного обнаружения возможных
срывов сроков контрольных событий полезно использо-
вать технику ранних контрольных событий, сигнализиру-
ющих о приближении сроков завершения или старта кри-
тически важных работ компонентов.
 LL-3.2.3. Если отставание по срокам программы одно-
значно является негативным результатом, то опережение
сроков программы не всегда является позитивным резуль-
татом.
 LL-3.2.4. Метод освоенного объема позволяет проводить
интегрированный анализ как исполнения графика, так и
бюджета программы по стоимостным показателям.
 LL-3.2.5. Расчет отклонений по стоимости (CV), срокам
(SV) и индексов выполнения бюджета (CPI) и графика
(SPI) следует проводить по завершении этапа или дости-
жении контрольной точки программы.
 LL-3.2.6. Расчет прогнозных показателей стоимости остав-

шихся невыполненными работ программы (ETC) и стои-
мости всей программы по ее завершении (EAC) следует
также проводить по завершении этапа или достижении
контрольной точки программы. Именно по завершении
работ этапа или по достижении контрольной точки спон-
сор программы может попросить менеджера программы
дать прогноз.
 LL-3.2.7. Регулярные вычисления показателя TCPI в тече-
ние определенного периода позволяют судить об эффек-
тивности работ программы.
 LL-3.2.8. Необходимость ускорения или замедления сро-
ков исполнения компонентов может быть продиктована
меняющимися сроками получения выгод программы.
 Бизнес-кейс «Программа по созданию

производства металлокомпозитов»
Проблемная ситуация. Своевременная консолидация ре-
зультатов компонентов в соответствии с датами расписания
программы необходима для получения общего результата про-
граммы в установленные сроки. Отсутствие анализа взаимо-
зависимостей контрольных событий компонентов приводит к
срыву сроков получения окончательных результатов програм-
мы и к упущенным выгодам компании.
Описание бизнес-кейса. Программа торгово-промыш-
ленной группы «Создание производства металлокомпозитов»
включала следующие компоненты:
 проект подготовки промышленной площадки по развер-
тыванию линии;
 проект закупки, наладки и запуска линии в эксплуата-
цию;
 операционную деятельность по промышленной эксплуата-
ции линии;
 проект организации рекламы, маркетинга и сбыта продук-
ции;
 операционную деятельность по сбыту продукции.
118 Глава 3
В ходе выполнения программы менеджеру программы

удалось выдержать сроки выполнения компонентов 1 и 2 и
своевременно начать работы компонента 3 по операционной
эксплуатации линии. Серийное производство металлокомпо-
зитов удалось организовать в установленные сроки, и на склад
предприятия стала поступать новая продукция в значительных
объемах. Однако сроки завершения компонента 4 оказались
сорванными из-за задержек в организации логистических це-
почек сбыта продукции. Поэтому старт компонента 5 по опе-
рационной сбытовой деятельности продукции пришлось от-
ложить на три месяца. Это привело к упущенным выгодам и
потерям в бизнесе торгово-промышленной группы:
 затовариванию складов предприятия новой продукцией
металлокомпозитов;
 необходимости остановки запущенной линии и простою
занятых ресурсов;
 срыву сроков вывода новой продукции группы на рынок;
 потери планового дохода и прибыли предприятия от реа-
лизации на рынке новой номенклатуры продукции.
Выводы и рекомендации. Одной из основных обязан-
ностей менеджера программы является проведение анализа
взаимозависимостей между контрольными событиями компо-
нентов программы. Срывы сроков завершения одних компо-
нентов влияют на сроки старта других, приводят к срыву сро-
ков получения результатов всей программы и к упущенным
выгодам компании. Только консолидация результатов всех
компонентов программы, полученных в установленные сроки,
может обеспечить достижение общих результатов программы
и бизнес-выгод компании.
ГЛАВА 4
Финансы программы
Значение области знаний «Управление финансами про-

граммы» стандарта PMI The Standard for Program Man-
agement®. В данной области знаний стандарта описана одна
управлению финансами программы. Семь процессов, реко-
мендованных стандартом в данной области знаний, относятся
к фазам жизненного цикла определения, достижения выгод и
завершения программы (табл. 9).
Таблица 9

«Управление финансами программы»
Оценка стоимости программы Определение программы
Определение структуры финанси- Определение программы

рования программы
Разработка плана финансирования Определение программы
Оценка стоимости компонентов Достижение выгод

Бюджетирование расходов программы Достижение выгод

программы
Мониторинг и управление финансами Достижение выгод

Закрытие финансирования программы Завершение программы

120 Глава 4

управление финансами программы
Процесс: оценка стоимости программы
Основные цели процесса оценки стоимости программы:

 предварительная оценка расходов программы на всех ее
этапах;
 согласование предварительной оценки расходов програм-
мы с общим планом управления финансами программы.
Интерпретация процесса оценки стоимости программы
Оценка стоимости программы происходит постоянно в ходе
жизненного цикла программы. Исходная, грубая оценка стои-
мости программы (order of magnitude) определяется в бизнес-
кейсе до инициации программы и позволяет руководящему
органу компании принять решение о старте программы или
об отказе от ее инициации. Во многих компаниях аналогич-
ное решение о продолжении финансирования работ програм-
мы либо об отказе в финансировании и остановке программы
принимается после каждого обзора результатов фаз жизнен-
ного цикла программы (phase gate reviews). В ходе выполне-
ния работ программы исходная оценка стоимости постепенно
уточняется. Окончательная оценка стоимости крупной ком-
плексной программы (definitive estimate) может быть получена
на финальных стадиях работ программы, в том числе и в фазе
жизненного цикла завершения программы.
При проведении оценки стоимости программы необходи-
мо учитывать не только стоимость работ по управлению про-
граммой и стоимость компонентов программы, но и стоимость
работ по поддержке выгод программы (benefit sustainment).
Сумма всех этих стоимостей составляет полную стоимость
владения продуктом программы (total cost of ownership).
Полная стоимость владения продуктом программы срав-
нивается с оценкой финансовых выгод программы при при-
нятии решений об инициации или продолжении программы
в ходе обзоров результатов фаз жизненного цикла программы.
Финансы программы 121
Сравнение полной стоимости владения продуктом программ

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

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

Процесс: определение структуры финансирования
программы
Основные цели процесса определения структуры финанси-

рования программы:
 определение источников финансирования программы;
 определение способов управления финансированием про-
граммы.
Интерпретация процесса определения структуры фи-
нансирования программы и рекомендации автора по его
применению на практике. Бюджет программы включает
бюджеты всех ее компонентов, а также затраты на управление
программой и привлечение всех необходимых для этого про-
цесса ресурсов.
122 Глава 4
! Комментарий из практики. Бюджеты крупных программ

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

определена совместно с финансирующей компанией в начале
жизненного цикла программы.
В данном процессе проводится анализ источников финан-
сирования программы, целей финансирования, ограничений
финансирования и бизнес-кейса программы.
Источники финансирования программы могут быть раз-
личными и зависят от типа, масштаба и сложности програм-
мы. Источники финансирования могут отличаться принципи-
ально для международных и национальных программ, а также
для тех, которые финансируются самой компанией — заказчи-
ком программы, и для тех, которые требуют финансирования
внешних по отношению к заказчику компаний.
Различными моделями финансирования могут быть:
 внутреннее финансирование и управление программой
полностью одной компанией;
 внутреннее управление в рамках одной компании, но с
внешним финансированием;
 внутреннее финансирование с внешним управлением
(аутсорсинг);
 управление программой и ее финансирование внешней
(например, материнской) компанией.
Цели финансирования являются основанием финанси-
рования программы. Например, источник финансирования
может иметь цели получения стабильного дохода, скорейшего
возврата инвестиций или отсрочки выплат поставщикам про-
граммы.
NB! Менеджер программы должен иметь в виду, что цели

источника финансирования могут отличаться от целей
финансирования программы. Например, источник финан-
сирования может быть заинтересован в отсрочке плате-
жа поставщику программы, а интересы программы могут
заключаться в проведении 100% предоплаты поставщику
для проведения им приоритетных работ программы.
Ограничения финансирования могут включать, например,
требования проведения платежей в определенной валюте, гра-
фик и объемы платежей, рекомендации по пользованию услу-
гами определенных финансовых организаций и банков и т. п.
Бизнес-кейс программы может включать описание предо-
пределенных источников и схем финансирования программы.
В качестве основных инструментов процесса используют-
ся финансовый анализ программы, графики платежей и мето-
ды финансирования.
Финансовый анализ программы содержит важные дан-
ные, подтверждающие необходимость выполнения программы
с финансово-экономической точки зрения, в том числе:
 анализ прибыли/затрат программы (program cost/benefit
analysis);
 оценку возврата инвестиций программы (return on invest-
ment);
 текущую стоимость будущих денежных выплат (net present
value);
 анализ макроэкономических тенденций и трендов (trend
analysis).
Графики платежей содержат контрольные события или
вехи расписания программы (program schedule milestones),
при наступлении которых должны быть проведены расчеты и
оплата работ поставщиков.
Методы финансирования рассматриваются менеджером
программы для выбора наиболее эффективных методов и схем
финансирования программы, среди которых могут быть:
 финансирование программы компанией-заказчиком;
 финансирование программы государственной структурой;
 финансирование программы банком, венчурным фондом
или другим финансовым институтом.
124 Глава 4
Выходами данного процесса являются: структура финан-

сирования программы, обновления бизнес-кейса и планов
управления коммуникациями программы и вовлеченностью
заинтересованных сторон.
Структура финансирования программы представляет
собой план координации бюджета программы, включающий
описания доступных источников финансирования, ограниче-
ний финансирования и способов оплаты работ поставщиков.
Обновления бизнес-кейса могут возникнуть при анализе
методов финансирования и разработке структуры финансиро-
вания программы.
 LL-4.2.1. Источники финансирования программы могут
быть различными и зависят от типа, масштаба и сложнос-
ти программы. Источники финансирования могут отли-
чаться принципиально для международных и националь-
ных программ, а также для тех, которые финансируются
самой компанией — заказчиком программы, и для тех, ко-
торые требуют финансирования внешних по отношению к
заказчику компаний.
 LL-4.2.2. Менеджер программы должен иметь в виду, что
цели источника финансирования могут отличаться от це-
лей финансирования программы. Например, источник
финансирования может быть заинтересован в отсрочке
платежа поставщику программы, а интересы программы
могут заключаться в проведении 100% предоплаты по-
ставщику для осуществления им приоритетных работ про-
граммы.
 LL-4.2.3. Методы финансирования рассматриваются ме-
неджером программы для выбора наиболее эффективных
методов и схем финансирования программы, среди кото-
рых могут быть:
– финансирование программы компанией-заказчиком;
– финансирование программы государственной струк-
турой;
– финансирование программы банком, венчурным фон-
дом или другим финансовым институтом.

Процесс: разработка плана финансирования программы
Основные цели процесса разработки плана финансирова-

ния программы:
 документирование всех финансовых аспектов программы,
включая расписание финансирования, начальные бюдже-
ты, платежи по контрактам и сроки, финансовые процеду-
ры, механизмы и метрики;
 учет в плане финансирования программы стоимостей всех
компонентов, а также всех необходимых инфраструктур-
ных и операционных затрат программы.
Интерпретация процесса разработки плана финанси-
рования программы и рекомендации автора по его при-
менению на практике. Менеджеру программы необходимо
учесть ряд факторов, оказывающих влияние на процесс раз-
работки плана финансирования программы, среди которых
следует отметить:
 наличие различных источников финансирования про-
граммы;
 значительную длительность большинства программ;
 значительное количество поставщиков крупных программ
с различными типами контрактов, условий и графиков
платежей;
 различия в особенностях законодательства и юридических
норм в странах — участницах международных программ.
! Комментарий из практики. При разработке плана финан-

сирования программы необходимо использовать данные о фи-
нансовых резервах рисков программы, потенциальные проблемы
недостатка наличных средств (potential cash flow problems), дина-
мику обменных курсов валют, изменения цен на материалы, фи-
нансовые штрафы и вознаграждения в контрактах с поставщика-
ми, допустимые периоды отсрочки платежей поставщикам и др.
126 Глава 4
NB! Факторы внешней среды могут являться источниками

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

зу: структура финансирования программы, ИСР програм-
мы, ограничения финансирования и план управления про-
граммой.
Ограничения финансирования являются существенным
фактором, влияющим на процесс разработки плана финанси-
рования программы. Так как большинство крупных программ
имеет значительную длительность и большой бюджет, получе-
ние 100% финансирования в начале выполнения программы
является редкостью и, скорее, «исключением из правила». На
практике такие программы получают либо регулярный годо-
вой бюджет (особенно в случае государственных программ),
либо поэтапное финансирование работ программы, связанное
с достижением контрольных событий (program milestones).
Поэтому график платежей финансового плана программы
должен учитывать сроки годового или поэтапного финансиро-
Основными инструментами данного процесса являют-
ся: финансовый анализ программы, управление контрактами,
анализ операционных расходов.
Анализ операционных расходов необходим для оценки и
включения в финансовый план программы статей расходов
на инфраструктуру управления программой, включая компен-
сацию менеджеру программы и команде офиса управления
программой, затраты на поддержание и развитие технологи-
ческой, организационной и информационной инфраструктур
программы.

 план управления финансированием программы;
 расписание финансирования программы;
 расписания платежей по компонентам;
 операционные расходы программы;
 финансовые метрики программы.
План управления финансирования программы является
частью общего плана управления программой и включает раз-
делы, описывающие:
 объемы и вехи обеспечения бюджета программы из опре-
деленных финансовых источников;
 базовый бюджетный план программы (program baseline
budget);
 график платежей по контрактам с поставщиками;
 процедуру отчетности по освоению бюджета программы;
 финансовые метрики.
Финансовые метрики позволяют измерять и оценивать
достижение финансовых выгод программы.
NB! Результатом измерения и оценки достижения выгод

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

 LL-4.3.1. При разработке плана финансирования про-
граммы необходимо использовать данные о финансовых
резервах рисков программы, потенциальные проблемы
недостатка наличных средств, динамику обменных курсов
валют, изменения цен на материалы, финансовые штрафы
и вознаграждения в контрактах с поставщиками, допусти-
мые периоды отсрочки платежей поставщикам и др.
 LL-4.3.2. Факторы внешней среды могут являться источ-
никами непредсказуемых негативных воздействий на план
финансирования программы. Например, такими фактора-
ми могут быть негативные изменения в курсах валют или
неожиданные увеличения стоимости материалов.
128 Глава 4
 LL-4.3.3. Ограничения финансирования являются сущест-

венным фактором, влияющим на процесс разработки пла-
на финансирования программы. Так как большинство
крупных программ имеет значительную длительность и
большой бюджет, получение 100% финансирования в нача-
ле выполнения программы является редкостью и, скорее,
«исключением из правила». На практике такие программы
получают либо регулярный годовой бюджет (особенно в
случае государственных программ), либо поэтапное фи-
нансирование работ программы, связанное с достижением
контрольных событий. Поэтому график платежей финан-
сового плана программы должен учитывать сроки годово-
го или поэтапного финансирования программы.
 LL-4.3.4. Результатом измерения и оценки достижения
выгод программы с помощью применения финансовых
метрик может быть решение об остановке, замораживании
или изменении целей и содержания программы.

Процесс: оценка стоимости компонентов программы
Основные цели процесса оценки стоимости компонентов

программы:
 получение оценок стоимости для отдельных компонентов
программы;
 формирование бюджета для каждого компонента.
Интерпретация процесса оценки стоимости компонен-
тов программы и рекомендации автора по его применению
на практике. В этом процессе менеджер программы должен
организовать проведение работ по оценке стоимости ресурсов
компонентов и также использовать оценки аналогичных ресур-
сов компонентов из прошлых программ компании. В сложных
комплексных программах стоимость отдельных компонентов
может быть определена очень грубо в ходе фазы жизненного
цикла определения программы. Более точные оценки стоимос-

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

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

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

включен в оценку расходов программы для использования при
возникновении непредвиденных изменений и при реагирова-
нии на известные риски программы.
Анализ резервов используется для определения доста-
точных (и не избыточных) резервов бюджета программы для
своевременного реагирования на риски программы и на не-
предвиденные изменения в содержании программы и в окру-
жающей среде.
Компьютерные инструменты оценки стоимости (com-
puter cost estimating tools) используются для анализа и вычис-
лений общей стоимости материалов и человеческих ресурсов
компонентов программы.
130 Глава 4
! Комментарий из практики. Важным условием является тре-

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

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

 LL-4.4.1. Наиболее точная оценка расходов возможна в от-
носительно краткосрочных программах, в которых основ-
ным ресурсом являются люди. Наименее точная оценка
расходов может быть получена в долгосрочных програм-
мах, в которых основными ресурсами являются материалы
и оборудование.
 LL-4.4.2. В сложных комплексных программах оценка рас-
ходов не может быть выполнена без привлечения большо-
го числа контрагентов и субподрядчиков, выполняющих
своими силами значительный объем работ программы.
Только ответственные исполнители данных работ могут
оценить их стоимость. Поэтому оценка расходов таких
программ возможна только после отбора и привлечения
поставщиков.
 LL-4.4.3. В оценке расходов высоко рискованных про-
грамм должны быть учтены значительные финансовые ре-
зервы на управление рисками внешней среды, технологи-
ческими и организационными рисками.
 LL-4.4.4. Анализ затрат на организацию и проведение по-
ставок программы должен включать не только стоимость
контракта с поставщиком, но также и затраты офиса
управления программой на администрирование процессов
поставки.
 LL-4.4.5. Важным условием является требование по ис-

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

Процесс: бюджетирование расходов программы
Основные цели процесса бюджетирования расходов про-

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

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

мы, расписания платежей программы, расписания платежей
Базовый бюджет программы (program budget baseline)
отражает поток денежных средств во времени жизненного
цикла программы, поступающих в ее бюджет из определенных
источников и используемых для финансирования работ про-
граммы.
NB! С момента утверждения заказчиком базового бюд-

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

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

 LL-4.5.1. При анализе затрат программы необходимо про-
вести детальный анализ структуры затрат всех компонен-
тов программы, включающий такие статьи расходов ком-
понентов, как:
– объемы, сроки и ограничения финансирования;
– объемы и графики платежей по контрактам с постав-
щиками;
– расходы на управление программой.
 LL-4.5.2. Базовый бюджет программы отражает поток де-
нежных средств во времени жизненного цикла программы,
поступающих в ее бюджет из определенных источников и
используемых для финансирования работ программы.
 LL-4.5.3. С момента утверждения заказчиком базового
бюджета программы он становится главным финансовым
документом программы. Успех программы с точки зрения
финансовых показателей определяется исходя из результа-
тов освоения и расходов базового бюджета программы.

Процесс: мониторинг и управление финансами программы
Основные цели процесса мониторинга и управления фи-

нансами программы:
 мониторинг и контроль за соответствием поступлений и
затрат программы бюджету;
 своевременное выявление отклонений в бюджете про-
граммы.
Интерпретация процесса мониторинга и управление
финансами программы и рекомендации автора по его при-
менению на практике. При выполнении данного процесса
менеджер программы обязан обеспечить:
 определение факторов, оказывающих влияние на базовый
бюджет программы;
 управление изменениями базового бюджета программы;
 отслеживание платежей по контрактам поставщиков;
 определение влияния на программу и ее компоненты пе-
рерасхода и экономии средств бюджета программы;
 заблаговременное информирование аудиторов и руковод-
ство программы о необходимости изменений в базовом
бюджете программы;
 контроль расходов на управление программой.
Основными инструментами и методами данного процес-
са являются: система управления затратами, управление сто-
имостью контракта, отчеты по исполнению, методы прогно-
зирования затрат, анализ операционных расходов, управление
освоенным объемом.
Система управления затратами включает набор про-
цессов и процедур, позволяющих управлять изменениями,
возникающими в расходах программы и ее компонентов по
отношению к утвержденному базовому бюджету программы.
Отчеты по исполнению позволяют проводить регуляр-
ный обзор и анализ расходов программы и ее компонентов для
обеспечения их соответствия базовому бюджету программы.
134 Глава 4
Методы прогнозирования затрат включают регулярный

расчет показателей прогнозных оценок стоимости оставших-
ся не выполненными работ программы (estimate to comple-
tion) и стоимости всей программы по ее завершении (estimate
at completion) для сравнения с текущим базовым бюджетом
программы и общим бюджетом программы по ее завершении
(budget at completion).
Анализ операционных расходов обеспечивает постоянный
мониторинг и контроль расходов на управление программой.
Управление освоенным объемом используется для монито-
ринга прогресса в выполнении финансовых и временных пла-
нов программы и ее компонентов.
Выходами данного процесса являются: платежи по кон-
трактам, обновления базового бюджета программы, одобрен-
ные запросы на изменения, оценка стоимости по завершении,
обновления плана управления программой, корректирующие
действия.
Платежи по контрактам выполняются в соответствии
с условиями контрактов, подписанных с поставщиками про-
граммы по выполнению ими работ, принятых заказчиком (ме-
неджером программы).
Обновления базового бюджета программы производятся
по утвержденным изменениям базового бюджета программы.
Обновления плана управления программой осуществля-
ются в соответствии с измененным базовым бюджетом про-
граммы.
Корректирующие действия производятся в соответствии
с решениями по управлению непредвиденными изменениями
или возникшими проблемами.

 LL-4.6.1. Система управления затратами включает набор
процессов и процедур, позволяющих управлять измене-
ниями, возникающими в расходах программы и ее компо-
нентов по отношению к утвержденному базовому бюджету
программы.
 LL-4.6.2. Методы прогнозирования затрат включают регу-

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

Процесс: закрытие финансирования программы
Основные цели процесса закрытия финансирования про-

граммы:
 закрытие бюджета и подготовка итоговых финансовых от-
четов;
 возврат неиспользованных средств источнику финансиро-
Интерпретация процесса закрытия финансирования
практике. Менеджер программы должен начать данный про-
цесс после завершения всех плановых работ программы и ее
компонентов и достижения всех запланированных результатов
и выгод программы. В данном процессе необходимо учесть за-
траты на работы по поддержке достигнутых выгод (benefit sus-
tainment) в компании — заказчике программы.
 данные для итоговых отчетов по исполнению программы;
 обновления плана управления финансированием про-
граммы;
 данные для базы знаний организации;
 документация по использованным новым инструментам и
методам;
 документы закрытия финансирования;
 закрытый бюджет программы.
136 Глава 4
Закрытый бюджет программы оформляется по завер-

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

 LL-4.7.1. В процессе закрытия финансирования програм-
мы необходимо учесть затраты на работы по поддержке
достигнутых выгод в компании — заказчике программы.
 LL-4.7.2. Оставшиеся при закрытии бюджета программы
средства возвращаются источнику финансирования про-
граммы.
 Бизнес-кейс «Программа строительства

торгово-развлекательного центра»
Проблемная ситуация. В сложных комплексных программах
расходы не могут быть оценены без привлечения большого
числа контрагентов и субподрядчиков, выполняющих своими
силами значительный объем работ программы. Только ответ-
ственные исполнители данных работ могут оценить их стои-
мость. Поэтому оценка расходов таких программ возможна
только после отбора и привлечения поставщиков.
Описание бизнес-кейса. Генеральный подрядчик по-
лучил от инвестора приглашение к участию в тендере (RFP)
программы строительства торгово-развлекательного центра.
В RFP были указаны требования по проведению генеральным
подрядчиком всего комплекса строительно-монтажных работ
(СМР) для сдачи объекта недвижимости «под ключ» и пред-
ставления инвестору ценового предложения в течение одно-
го месяца. Генеральный подрядчик принял предложение по
участию в тендере и инициировал собственные тендеры для
отбора своих подрядчиков и поставщиков, необходимых для
проведения всех требуемых СМР. Для выполнения всех не-

обходимых СМР требовалось отобрать 15 организаций — под-
рядчиков и поставщиков. К концу месяца удалось завершить
только девять тендеров и отобрать их победителей. Менеджер
программы генерального подрядчика принял решение исполь-
зовать грубые оценки стоимости работ (order of magnitude)
поставщиков по оставшимся незавершенным шести тендерам
и включил эти примерные оценки в общее ценовое предло-
жение для инвестора. Инвестор отдал предпочтение предло-
жению генерального подрядчика и объявил его победителем
тендера программы строительства торгово-развлекательного
центра.
Приступив к работам по программе, генеральный подряд-
чик стал получать окончательные предложения от участников
шести оставшихся тендеров. Победителями этих тендеров ока-
зались шесть компаний, стоимость работ которых значитель-
но превышала грубые оценки работ, включенных менеджером
программы в ценовое предложение для инвестора. Генераль-
ный подрядчик был вынужден прекратить все работы по про-
грамме и заплатить неустойку инвестору за разрыв с ним кон-
тракта.
Выводы и рекомендации. Оценка стоимости компонен-
тов программы, выполняемых ответственными исполнителя-
ми — сторонними организациями (поставщиками програм-
мы), должна быть получена только от самих ответственных
исполнителей, после их определения по итогам проведенных
тендеров.
ГЛАВА 5
Качество программы
Значение области знаний «Управление качеством про-

граммы» стандарта PMI The Standard for Program Man-
agement®. В данной области знаний стандарта описана одна
управлению качеством программы. Три процесса, рекомендо-
Таблица 10

«Управление качеством программы»
Планирование качества программы Определение программы
Обеспечение качества программы Достижение выгод программы
Контроль качества программы Достижение выгод программы


управление качеством программы
Процесс: планирование качества программы
Основные цели процесса планирования качества программы:
 определение политики качества и идентификация стан-
дартов качества, соответствующих программе;
Качество программы 139
 установление требований метрик качества;

 оценка стоимости качества по компонентам и программе
в целом.
Интерпретация процесса планирования качества про-
практике. Планирование качества является первым шагом в
управлении качеством программы. В данном процессе необхо-
димо определить стандарты качества программы, релевантные
ее содержанию, и установить принципы их использования.
Различные стандарты и метрики качества могут быть приме-
нимы к различным компонентам программы в силу различий
в их содержании. К этим стандартам и метрикам необходи-
мо добавить стандарты и метрики, обеспечивающие качество
программы в целом.
Стоимость работ по соответствию программы требовани-
ям к качеству должна быть оценена в бизнес-плане программы
и в ходе процесса инициации программы. В ходе жизненного
цикла программы эта стоимость может меняться и уточнять-
ся. Менеджер программы должен стремиться к оптимизации
затрат на управление качеством всей программы путем ис-
ключения дублирующих процессов обеспечения и контроля
качества в компонентах программы.
Единые принципы планирования и управления качеством
программы должны также распространяться на работы внеш-
них поставщиков и подрядчиков программы.
Выходом процесса является план управления качеством
программы, который может включать следующие разделы:
 политика качества программы;
 стандарты качества программы;
 стоимость работ по соответствию программы требованиям
к качеству;
 метрики качества программы;
 проверочные списки качества (quality check list) про-
граммы;
 спецификации обеспечения качества (quality assurance) и
контроля качества (quality control) программы.
140 Глава 5

 LL-5.1.1. Менеджер программы должен стремиться к опти-
мизации затрат на управление качеством всей программы
путем исключения дублирующих процессов обеспечения и
контроля качества в компонентах программы.
 LL-5.1.2. Единые принципы планирования и управления
качеством программы должны распространяться на рабо-
ты внешних поставщиков и подрядчиков программы.

Процесс: обеспечение качества программы
Основные цели процесса обеспечения качества программы:

 аудит качества программы на регулярной основе для обес-
печения уверенности в том, что уровень качества про-
граммы соответствует политике и стандартам качества
компании;
 проведение непрерывного мониторинга и анализа качест-
ва на протяжении всего жизненного цикла программы.
Интерпретация процесса обеспечения качества про-
практике. Процесс обеспечения качества программы (pro-
gram quality assurance process) проводится непрерывно в ходе
жизненного цикла программы для обеспечения качества всех
текущих работ и процессов программы. Данный процесс обес-
печивает также обновление плана по качеству программы при
появлении новых законодательных актов и стандартов каче-
ства, релевантных содержанию программы.
Основным инструментом данного процесса является ау-
дит качества программы. Аудит качества программы от-
слеживает не только качество работ на уровне программы в
целом, но и взаимные влияния компонентов программы на
качество работ и результатов работ компонентов.
Для успешного прохождения аудита по качеству програм-

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

 LL-5.2.1. Процесс обеспечения качества программы вклю-
чает обновления плана по качеству при появлении новых
законодательных актов и стандартов качества, релевант-
ных содержанию программы.
 LL-5.2.2. Аудит качества программы отслеживает не толь-
ко качество работ на уровне программы в целом, но и вза-
имные влияния компонентов программы на качество ра-
бот и результатов работ компонентов.

Процесс: контроль качества программы
Основные цели процесса контроля качества программы:

 мониторинг результатов программы или отдельного ком-
понента на их соответствие требованиям качества для до-
стижения выгод программы;
142 Глава 5
 контроль качества характеристик наиболее значимых для

достижения выгод программы результатов и продуктов
Интерпретация процесса контроля качества програм-
мы и рекомендации автора по его применению на прак-
тике. Процесс контроля качества программы (program qual-
ity control process) проводится в целях контроля качества
результатов работ программы и ее компонентов. Результаты
программы включают продукты компонентов и программы в
целом, обеспечивающие достижение выгод программы, а так-
же результаты в управлении программой и реализации планов
программы.
Качество результатов программы и ее компонентов прове-
ряется в ходе инспекций, тестов и измерений достигнутых уров-
ней качества путем заполнения проверочных листов контроля
качества (quality control check list) и инспекционных отчетов.
Контроль качества программы включает также обзоры
удовлетворения заказчиков (customer satisfaction surveys) и ко-
нечных пользователей продуктов программы (end users satisfac-
tion surveys). Результаты таких обзоров могут привести к изме-
нениям в политике качества и стандартов качества программы.
 запросы об изменении качества;
 заполненные проверочные листы контроля качества и ин-
спекционные отчеты;
 отчеты тестирования качества или результаты измерений
качества.

 LL-5.3.1. Результаты программы включают продукты ком-
понентов и программы в целом, обеспечивающие дости-
жение выгод программы, а также результаты в управлении
программой и реализации планов программы.
 LL-5.3.2. Результаты обзоров удовлетворения заказчиков и
конечных пользователей продуктов программы могут при-
вести к изменениям в политике качества и стандартов ка-
чества программы.
 Бизнес-кейс «Программа внедрения

системы делопроизводства в министерстве»
Проблемная ситуация. В обеспечении качества програм-
мы необходимо не только предусматривать удовлетворение
формальных требований заказчика, но также стремиться к
удовлетворению неформальных ожиданий конечных пользо-
вателей продуктов — результатов компонентов программы.
Формальные требования заказчика, как правило, отражены
в формальном документе — контракте, техническом задании,
приказе и т. п. Неформальные ожидания конечных пользо-
вателей продукта часто не отражены ни в одном документе.
Руководитель компонента — проекта программы, выполнив-
ший проект формально в соответствии с формальными тре-
бованиями заказчика, может столкнуться с проблемой отказа
конечных пользователей использовать продукт.
Описание бизнес-кейса. Менеджер программы отве-
чал за разработку и внедрение системы делопроизводства в
организации заказчика, которой являлся аппарат министер-
ства. Этап внедрения включал эксплуатацию разработанной
системы делопроизводства и поддержку выгод программы в
организации заказчика, которые должны были обеспечивать
сокращение документооборота, повышение скорости обра-
ботки, согласования и утверждения документов министерства.
Руководитель компонента программы — проекта по разработ-
ке системы делопроизводства получил из аппарата министер-
ства официальный документ, описывающий постановку задачи
и требования заказчика к организации и функциям системы
делопроизводства. Этим документом было техническое зада-
ние (ТЗ) на разработку и внедрение системы делопроизвод-
ства, подписанное официальным представителем заказчика —
ИТ-директором аппарата министерства. Руководитель ком-
понента программы принял ТЗ к исполнению и в тече-
ние нескольких месяцев вел работы проекта. По окон-
чании разработки руководитель компонента программы
провел инсталляцию продукта системы делопроизводства на
рабочих станциях конечных пользователей — сотрудников од-
ного из подразделений (бухгалтерии) бэк-офиса министерства.
144 Глава 5
Сотрудники бухгалтерии, попробовавшие использовать про-

дукт системы в своей работе, выразили категорический про-
тест и возражения против использования продукта системы.
Многие из них (женщины бухгалтерии) на повышенных тонах
высказывали жесткие замечания по работе отдельных функ-
ций системы, неудобству работы с интерфейсами, входными и
выходными формами, не соответствующими существующим в
организации заказчика внутренним процессам и процедурам.
Заместитель министра, являющийся спонсором программы в
организации заказчика, вызвал менеджера программы и руко-
водителя проекта и высказал им претензии конечных пользо-
вателей системы. Руководитель проекта программы ответил,
что вел разработку в полном соответствии с ТЗ, подписанным
ИТ-директором министерства. Тогда заместитель министра
вызвал к себе ИТ-директора. В ходе обсуждения сложившейся
ситуации выяснилось, что ТЗ было написано ИТ-директором,
совсем недавно пришедшим в аппарат министерства из друго-
го ведомства, и отражало подходы к организации системы де-
лопроизводства по прежнему месту работы ИТ-директора.
Заместитель министра поставил задачу по изучению тре-
бований и ожиданий конечных пользователей и переработке в
соответствии с ними ТЗ и продукта системы.
Выводы и рекомендации. Изучение неформальных ожи-
даний конечных пользователей на предпроектной стадии (до
подписания контракта и разработки технического задания)
может существенно повлиять на состав и содержание фор-
мальных требований заказчика. В случае, если такое изучение
проводится после подписания контракта, то возможно оформ-
ление дополнительных соглашений с заказчиком для удовлет-
ворения ожиданий конечных пользователей продукта компо-
нента программы.
ГЛАВА 6
Риски программы
Значение области знаний «Управление рисками програм-

мы» стандарта PMI The Standard for Program Manage-
ment®. В данной области знаний стандарта описана одна из
девяти ключевых компетенций руководителя программы по
управлению рисками программы. Пять процессов, рекомендо-
Таблица 11

«Управление рисками программы»
Планирование управления рисками Определение программы

программы
Идентификация рисков программы Достижение выгод программы
Анализ рисков программы Достижение выгод программы
Планирование реагирования Достижение выгод программы

на риски программы
Мониторинг и контроль над рисками Достижение выгод программы

программы

146 Глава 6

управление рисками программы
Процесс: планирование управления рисками программы
Основные цели процесса планирования управления риска-

ми программы:
 определение подхода по управлению рисками программы
с учетом специфики ее компонентов;
 определение методологических принципов управления
рисками программы с учетом ее значимости для компании;
 определение ресурсов, достаточных для управления риска-
ми программы.
Интерпретация процесса планирования управления
рисками программы и рекомендации автора по его при-
менению на практике. Менеджер программы должен начать
процесс планирования управления рисками программы как
можно раньше.
NB! В плане управления рисками программы не должны

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

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

совещание по анализу риска срыва сроков поставки оборудо-
вания в компоненте программы по строительству новой тех-
нологической линии предприятия.
План управления участниками программы используется
при планировании управления рисками для учета уровня то-
лерантности отдельных стейкхолдеров к рискам программы, а
также влияния на ход работ программы и методы реагирова-
ния на различные риски. Например, значительное влияние и
власть спонсора программы могут быть учтены при необходи-
мости выделения дополнительных ресурсов для снижения рис-
ка срыва сроков поставки оборудования.
База извлеченных уроков содержит уроки, извлеченные
менеджерами программ организации в прошлых программах,
которые могут быть использованы менеджером программы
при планировании управления рисками текущей программы.
Инструментами данного процесса являются совещания
по планированию и анализу и анализ извлеченных уроков.
Совещания по планированию и анализу должны быть
организованы менеджером программы с участием ключевых
стейкхолдеров для определения подходов и процедур по управ-
лению рисками программы.
Основные темы таких совещаний:
 выбор подходов и методологии управления рисками про-
граммы с учетом специфики ее содержания;
 определение принципов ответственности за управление
рисками (risk ownership);
 определение категорий и типов рисков программы и ее
компонентов;
 обсуждение и определение форматов шаблонов анализа
рисков и форм отчетов по управлению рисками.
Результаты совещаний и принятые решения отражаются в
плане управления рисками программы.
Анализ извлеченных уроков позволяет учесть при разра-
ботке плана управления рисками уроки, извлеченные при раз-
работке подобных планов в прошлых программах компании.
148 Глава 6
Выходом процесса является план управления рисками

программы, который включает следующие разделы:
 методологию управления рисками — описывает подход
команды к управлению рисками программы, использую-
щий результаты управления рисками ее компонентов;
 роли и ответственности участвующих в управлении риска-
ми — описывает процедуры назначения ответственных за
риски программы, включающие риски во взаимодействии
компонентов, риски на уровне управления всей програм-
мой, эскалированные руководителями компонентов и воз-
никающие вследствие применения методов реагирования
на риски программы;
 бюджет для управления рисками — включает описание
подходов по формированию резерва бюджета программы
на управление рисками (contingency reserve);
 определение периодичности процедур управления риска-
ми — определяет регламент и периодичность совещаний
менеджера программы с владельцами рисков по управле-
нию рисками программы;
 категории рисков — определяет принципы декомпозиции
при построении источников рисков по их категориям (risk
breakdown structure — RBS);
 матрицы вероятности и воздействия рисков — включает
шаблоны матриц вероятности и воздействия рисков;
 уровни толерантности к рискам стейкхолдеров програм-
мы — описывает допустимые уровни толерантности к рис-
кам, связанные со степенью рискованности бизнес-стра-
тегии компании;
 форматы и шаблоны отчетов — описывает структуру реес-
тра рисков программы (program risk register) и форматы
отчетов о статусе планов реагирования на риски;
 процедуры отслеживания рисков — описывает процедуры
аудита управления рисками программы;
 процедуры утверждения плана управления рисками —
описывает принятые в компании процедуры утверждения
планов управления рисками;
 описание соответствия плана корпоративной системе
управления рисками — подтверждает соответствие опи-
санных выше разделов плана принятым в компании про-

цедурам управления рисками.

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

Процесс: идентификация рисков программы
Основные цели процесса идентификации рисков про-

граммы:
 определение рисков, оказывающих влияние на программу;
 описание характеристик обнаруженных рисков программы.
150 Глава 6
Интерпретация процесса идентификации рисков про-

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

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

анализу описание содержания программы, план управления
рисками программы, план управления рисками компонентов
программы и базу усвоенных уроков.
Описание содержания программы является важным со-
держательным источником для идентификации рисков про-
граммы. Такие разделы данного документа, как допущения в
содержании программы (assumptions) и зависимости между
компонентами (dependencies), могут быть источниками значи-
тельных рисков программы.
План управления рисками программы активно использу-
ется в процессе идентификации рисков, который следует про-
водить с использованием утвержденной в плане методологии,
процедуры назначения ответственных за риски, выделенного
бюджета, запланированных регулярных совещаний по рискам
программы и определенных категорий рисков.
Планы управления рисками компонентов программы ис-
пользуются для анализа влияния рисков компонентов на риски
других компонентов программы. В случае обнаружения такого
влияния данные риски становятся рисками всей программы.
NB! Выполнение планов реагирования на риски компо-

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

извлеченных при идентификации рисков в прошлых програм-
мах компании.
Основными инструментами и методами процесса иден-
тификации рисков являются анализ документации, методы
сбора информации, анализ контрольных списков, анализ до-
пущений, методы отображения с помощью диаграмм, SWOT-
анализ, анализ сценариев.
Анализ документации проводится для выявления рисков
в официальных документах программы, включающих кон-
тракты с заказчиками и поставщиками, утвержденные планы
и отчеты, официальную корреспонденцию, протоколы сове-
щаний и др.
Методы сбора информации включают ряд методов для
идентификации рисков программы, в том числе:
 мозговые штурмы (brainstorming) — открытое обсуждение
рисков программы группой экспертов под руководством
модератора и с использованием категорий рисков про-
граммы;
 метод Дельфи (Delphi technique) — анонимный итера-
ционный опрос группы экспертов с целью постепенного
сближения их мнений относительно состава и формулиро-
вок рисков программы;
 интервьюирование экспертов (interviewing) — проведение
интервью с внутренними и внешними экспертами (вклю-
чая различных стейкхолдеров программы, а также руково-
дителей подобных программ) на предмет выявления рис-
ков программы;
 анализ основных причин (root cause identification) — вы-
явление существенных источников возникновения рисков
для определения их четких формулировок и объединения
рисков в подгруппы в случае существования общих при-
чин для возникновения нескольких рисков;
 анализ бизнес-кейса (business case analysis) — детальный
анализ бизнес-кейса программы для определения возмож-
ных внешних источников рисков программы, включая фи-
нансовые риски.
152 Глава 6
Анализ контрольных списков проводится с помощью

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

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

чать ряд методов, таких как:
 диаграммы причинно-следственных связей (cause-end-ef-
fect diagrams). Также известны как «диаграммы Ишикавы»
(Ishikawa diagrams) и «рыбья кость» (fishbone diagrams).
Используются для анализа совокупного влияния группы
причин, приводящих в качестве следствия к появлению
рисков программы;
 анализ зависимостей программы (program dependency analy-
sis) — позволяет выявлять зависимости программы от других
программ компании, являющиеся источниками рисков. Ти-
пичными зависимостями в таком анализе могут являться че-
ловеческие ресурсы, бюджеты, сервисные услуги, информа-
ционные источники или продукты компонентов программ;
 диаграммы влияния (influence diagrams). В графическом
виде позволяют идентифицировать риски программы, воз-
никающие из-за взаимного влияния сроков, содержания,
качества работ и результатов компонентов программы;
 диаграммы принадлежности рисков (affinity diagrams) —
позволяют определить источники рисков по отдельным
категориям.
SWOT-анализ позволяет определить риски программы на

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

 LL-6.2.1. При идентификации рисков важно описать, как и
почему риски могут повлиять на успех программы, и пред-
ставить достаточно подробную информацию для дальней-
шего процесса анализа и назначения рискам приоритетов.
 LL-6.2.2. Планы управления рисками компонентов про-
граммы используются для анализа влияния рисков компо-
нентов на риски других компонентов программы. В случае
обнаружения такого влияния такие риски становятся рис-
ками всей программы.
 LL-6.2.3. Выполнение планов реагирования на риски
компонентов программы может оказать влияние на рабо-
ты других компонентов программы. Задачами менеджера
программы являются обнаружение и отслеживание взаим-
ных влияний рисков различных компонентов программы.
154 Глава 6
 LL-6.2.4. В ходе жизненного цикла программы исходные

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

Процесс: анализ рисков программы
Основные цели процесса анализа рисков программы:

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

регламенты эскалаций рисков, матрицы вероятностей и влия-
ний, шаблоны отчетов по управлению рисками.
Реестр рисков программы содержит перечень рисков,
объединенных в категории.
База извлеченных уроков содержит опыт и уроки, извле-
ченные при анализе рисков в прошлых программах компании.
Основными инструментами и методами процесса явля-
ются: оценка качества данных о рисках, оценка вероятности и
степени влияния рисков, матрица вероятности и степени вли-
яния, категоризация рисков, оценка срочности реагирования
на риски, оценка влияния взаимозависимостей рисков, мето-
ды сбора и представления данных, методы количественного
анализа и моделирования, независимый анализ.
Оценка качества данных о рисках позволяет команде
управления программой удостовериться в качестве сведений,
данных и оценок рисков программы.
NB! Наличие качественных данных о рисках программы

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

при оценке качества данных о рисках:
 кто (или что) является источником риска;
 почему;
 каков может быть эффект от риска;
 как следует реагировать на риск команде программы;
 когда следует реагировать?
Отсутствие ответа на любой из этих вопросов может слу-
жить источником дополнительных рисков программы.
156 Глава 6
Оценка вероятности и степени влияния рисков обыч-

но производится с помощью обмена экспертными оценками
между членами команды управления программой и другими
ключевыми стейкхолдерами, а также экспертами в предметной
области (subject matter eхperts) содержания работ программы
и ее компонентов.
! Комментарий из практики. Кроме оценок вероятности

и степени влияния рисков полезно определять оценку степени
близости наступления риска. Данная оценка позволяет опреде-
лить момент, когда риск может произойти — очень скоро, скоро
или не очень скоро. При этом полезно отвечать на следующие
вопросы:
 имеет ли риск наибольшее влияние на программу в опреде-
ленный момент;
 существуют ли определенные даты, в которые наступление
риска нежелательно для программы;
 существуют ли даты, после наступления которых риск не мо-
жет оказать влияния на программу?
Матрица вероятности и степени влияния используется

для определения величин рисков на основе полученных экс-
пертных оценок вероятностей и влияния рисков программы.
По строкам матрицы определяются экспертные значения ве-
роятностей возникновения рисков, а по столбцам — уровни
влияния в определенных шкалах значений. На пересечении
строк и столбцов матрицы определяются значения величин
рисков как произведения значений вероятностей и влияния
рисков. Матрица включает значения величин как негативных
рисков (угроз), так и позитивных рисков (возможностей) про-
граммы, которые представлены в виде зеркального отображе-
ния значений величин рисков. Пример матрицы приведен на
рис. 22.
Рис. 22. Пример матрицы вероятностей и степени влияния рисков программы
158 Глава 6
! Комментарий из практики. Очень часто команды управ-

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

тегории для последующего детального анализа. Виды катего-
рий рисков могут быть связаны с предметной областью работ
программы или в общем случае могут включать организацион-
ные, технологические, внешние и управленческие категории
рисков. Категории рисков используются при построении ие-
рархической структуры рисков (risk breakdown structure) про-
граммы с помощью декомпозиции категорий на набор рисков
в каждой из них.
Оценка срочности реагирования на риски позволяет
определить наиболее критические риски, реагировать на ко-
торые следует незамедлительно. Как правило, критичность
риска определяется путем ранжирования в порядке убывания
значений величин рисков (т. е. произведений значений веро-
ятностей и влияния рисков). Риски с наибольшими значения-
ми величин являются наиболее критичными для программы и
требуют незамедлительного реагирования.
Оценка влияния взаимозависимостей рисков позволяет
выявить и оценить взаимные влияния и зависимости рисков
программы, которые могут быть:
 между различными рисками программы;
 между рисками программы и ее компонентов;
 между рисками компонентов программы;
 между рисками программы и рисками компании.
Синергетический эффект от совместного влияния рисков
компонентов на риски программы может быть как негатив-
ным, так и позитивным.
Методы сбора и представления данных используют об-

мен экспертными оценками и матрицы корреляций иерархи-
ческих структур работ и рисков программы (PWS–RBS ma-
trix). В таких матрицах по строкам представлены описания
рисков программы определенных категорий, а по столбцам —
описания пакетов работ программы. В ячейках матрицы за-
писывается количество рисков определенной категории, иден-
тифицированных в определенных пакетах работ программы.
Суммарное количество рисков по строкам матрицы показыва-
ет число рисков программы в каждой категории, а суммарное
количество рисков по столбцам — число рисков в каждом па-
кете работ (рис. 23).
Методы количественного анализа и моделирования ис-
пользуют матрицы взаимного влияния рисков программы и
проектов. В таких матрицах по строкам представлены риски
компонентов программы (или их коды), а по столбцам — коды
рисков программ. На пересечении строк и столбцов в ячейках
матрицы указывается степень влияния рисков компонентов на
риски программы (рис. 24). Методы количественного анализа
и моделирования рисков программы используют также мето-
ды финансового анализа и симуляционные модели, такие как
метод Монте-Карло, расчет ожидаемого денежного выигрыша
(expected monetary value), возврата инвестиций (return on in-
vestment) и др.
Независимый анализ основан на опросе независимых
внешних экспертов, компетентных в предметной области про-
граммы на предмет анализа ее рисков.
Выходом данного процесса являются обновления реестра
рисков программы, в которых отражаются результаты анали-
за рисков. Риски могут быть разбиты на группы критических
(красная группа), умеренных (желтая группа) и незначитель-
ных (зеленая группа) в зависимости от значений их величин.
Рекомендации по управлению рисками компонентов, оказы-
вающими влияние на риски программы, должны быть пред-
ставлены в обновленном реестре рисков.
Рис. 23. Пример матрицы корреляции иерархических структур работ (PWS)
и рисков (RBS) программы
Рис. 24. Пример матрицы взаимного влияния рисков программы и проектов
162 Глава 6

 LL-6.3.1. Наличие качественных данных о рисках про-
граммы является необходимым условием анализа рисков.
Некачественные данные о рисках (например, недостаточ-
но обоснованные оценки вероятностей возникновения и
влияния рисков) являются источником возникновения но-
вых рисков.
 LL-6.3.2. Полезно использовать следующие вопросы при
оценке качества данных о рисках:
– кто (или что) является источником риска;
– почему;
– каков может быть эффект от риска;
– как следует реагировать на риск команде программы;
– когда следует реагировать?
Отсутствие ответа на любой из этих вопросов может слу-
жить источником дополнительных рисков программы.
 LL-6.3.3. Кроме оценок вероятности и степени влияния
рисков полезно определять оценку степени близости на-
ступления риска. Данная оценка позволяет определить
момент, когда риск может произойти — очень скоро, ско-
ро или не очень скоро. При этом полезно отвечать на сле-
дующие вопросы:
– имеет ли риск наибольшее влияние на программу в
определенный момент;
– существуют ли определенные даты, в которые наступле-
ние риска не желательно для программы;
– существуют ли даты, после наступления которых риск
не может оказать влияния на программу?
 LL-6.3.4. Очень часто команды управления программами
уделяют основное внимание негативным рискам (угрозам),
забывая о наличии позитивных рисков (благоприятных
возможностей), использование которых может привести
к дополнительным преимуществам и выгодам программы.
 LL-6.3.5. Оценка влияния взаимозависимостей рисков по-
зволяет выявить и оценить взаимные влияния и зависимо-
сти рисков программы, которые могут быть:
– между различными рисками программы;
– между рисками программы и ее компонентов;

– между рисками компонентов программы;
– между рисками программы и рисками компании.
 LL-6.3.6. Синергетический эффект от совместного влия-
ния рисков компонентов на риски программы может быть
как негативным, так и позитивным.

Процесс: планирование реагирования на риски программы
Основные цели процесса планирования реагирования на

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

цесса являются стратегии реагирования на негативные риски
(угрозы), стратегии реагирования на позитивные риски (бла-
гоприятные возможности), подготовка плана реагирования на
непредвиденные обстоятельства и планирование действий по
реагированию на риски.
Различают несколько стратегий реагирования на нега-
тивные риски (угрозы).
1. Уклонение от риска (risk avoidance) — изменения плана
компонента или всей программы, направленные на устра-
нение риска либо на защиту от его воздействия.
NB! Уклонение от риска должно перевести риск в собы-

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

зано с отказом от выполнения работ или от использования ре-
сурса программы, содержащих риск. Если рискованная работа не
выполняется или рискованный ресурс не используется, то и риск
не происходит.
2. Передача риска (risk transference) — перенос последствий

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

третьей стороне должна быть зафиксирована в формальном до-
кументе. Например, передача риска срыва сроков поставки на
плечи поставщика может быть зафиксирована в контракте с по-
ставщиком путем определения штрафных санкций за срыв сро-
ков поставки.
3. Снижение риска (risk mitigation) — снижение вероятности

наступления риска или его последствий до приемлемого
уровня.
! Комментарий из практики. Снижение риска требует выде-

ления дополнительных ресурсов программы — бюджетных, вре-
менных, технологических, человеческих или организационных.
4. Принятие риска (risk acceptance) — отсутствие каких-либо

действий по реагированию на риск.
! Комментарий из практики. Принятие риска может быть

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

гоприятные возможности) относятся следующие.
1. Использование риска (risk exploit) — устранение неизвест-
ности, связанной с риском, реализуя возможность этого
риска. Этот метод включает привлечение лучших ресурсов
для сокращения срока выполнения, обеспечение лучшего
по сравнению с запланированным уровня качества.
2. Совместное использование риска (risk share) — частичная
или полная передача риска третьей стороне, способной
использовать его к наибольшей выгоде.
3. Усиление риска (risk enhance) — изменение «размера»
риска путем увеличения его вероятности и позитивного
результата.
4. Принятие риска (risk acceptance) — отсутствие каких-либо
действий по реагированию на риск.
! Комментарий из практики. Принятие позитивного риска

командой программы подразумевает отсутствие каких-либо воз-
можностей повышения положительного эффекта от риска или
невозможность повысить уровень эффекта имеющимися в распо-
ряжении команды ресурсами и средствами.
166 Глава 6
Подготовка плана использования резервов (contingency

plan preparation) — планирование необходимых резервов ре-
агирования на риски: бюджетных, временных, информацион-
ных, человеческих или организационных.
Планирование действий по реагированию на риски —
разработка действий и мероприятий по реализации выбран-
ных стратегий реагирования.
NB! Работы по реализации стратегий реагирования на
риски должны быть интегрированы в план управления
! Комментарий из практики. Действия по реализации стра-

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

реестра рисков, резервы на управление рисками, планы ис-
пользования резервов, запросы на изменения.
Обновления реестра рисков могут включать изменения
следующих разделов реестра:
 владельцы рисков;
 стратегии реагирования;
 действия по реализации стратегий реагирования;
 симптомы наступления рисков;
 остаточные риски (residual risks), которые остаются акту-
альными для программы, несмотря на предпринятые стра-
тегии реагирования;
 вторичные риски (secondary risks), которые возникают
вследствие реализации стратегий реагирования.
Резервы на управление рисками — оцененные, одобрен-
ные и включенные в план программы необходимые резервы
на управление рисками — бюджетные, временные, информа-
ционные, человеческие или организационные.
Планы использования резервов включают сведения об
условиях использования резервов, влияния использования
резервов на бюджет и расписание программы, ресурсы, не-
обходимые для использования резервов, и статус исполнения
плана (резерв запланирован, выделен, в стадии использования

или использован).
Запросы на изменения включают изменения в плане
управления программой, которые могут потребоваться при ре-
ализации стратегий реагирования на риски программы.

 LL-6.4.1. Уклонение от риска должно перевести риск в
событие с нулевой вероятностью, которое не может про-
изойти. Например, отчет менеджера программы спонсору
программы об уклонении от риска является гарантией, что
риск не произойдет ни при каких обстоятельствах.
 LL-6.4.2. Передача управления риском третьей стороне
должна быть зафиксирована в формальном документе.
Например, передача риска срыва сроков поставки на пле-
чи поставщика может быть зафиксирована в контракте с
поставщиком путем определения штрафных санкций за
срыв сроков поставки.
 LL-6.4.3. Снижение риска требует выделения дополни-
тельных ресурсов программы — бюджетных, временных,
технологических, человеческих или организационных.
 LL-6.4.4. Принятие риска может быть связано с незначи-
тельными уровнями вероятности и влияния риска либо
с невозможностью команды программы реагировать на
риск, например из-за отсутствия необходимых для реаги-
рования ресурсов.
 LL-6.4.5. Принятие позитивного риска командой програм-
мы подразумевает отсутствие каких-либо возможностей
повышения положительного эффекта от риска или невоз-
можность повысить уровень эффекта имеющимися в рас-
поряжении команды ресурсами и средствами.
 LL-6.4.6. Работы по реализации стратегий реагирования
на риски должны быть интегрированы в план управления
 LL-6.4.7. Действия по реализации стратегий реагирования
могут привести к необходимости изменения содержания
программы или приоритетов ее компонентов.
168 Глава 6

Процесс: мониторинг и контроль над рисками программы
Основные цели процесса мониторинга и контроля над рис-
ками программы:
 обновление планов реагирования для управления новыми
и измененными старыми рисками;
 мониторинг вторичных и остаточных рисков;
 оценка эффективности и пересмотр стратегий реагирова-
ния на риски;
 аудит выполнения политик и процедур в области управле-
ния рисками;
 анализ и пересмотр резервов на управление рисками.
Интерпретация процесса мониторинга и контроля над
рисками программы и рекомендации автора по его приме-
нению на практике. Данный процесс выполняется непрерыв-
но в ходе жизненного цикла управления программой.
В данном процессе подвергаются тщательному анализу:
базовая архитектура программы, план управления рисками
программы, реестр рисков программы, отчеты об исполнении
программы, резервы на управление рисками, реестр потенци-
альных проблем программы, контракты с поставщиками ком-
понентов программы.
Базовая архитектура программы используется для оцен-
ки актуальности определенных рисков и идентификации но-
вых рисков программы.
План управления рисками программы содержит инфор-
мацию о владельцах рисков и действиях по реагированию на
риски.
Реестр рисков программы — основной источник инфор-
мации о рисках, необходимый для проведения мониторинга и
контроля над рисками.
Отчеты об исполнении программы содержат информа-
цию о статусе программы и ходе выполнения плана управле-
ния программой, необходимую для всестороннего мониторин-
га и контроля рисков.
Резервы на управление рисками анализируются на пред-

мет их обоснованности, достаточности (либо избыточности) и
эффективности использования.
NB! Любые резервы, выделенные на управление про-
граммой, могут быть выражены в доле бюджета програм-
мы (т. е. в денежном выражении). Недостаток денежных
резервов требует их пополнения за счет выделения до-
полнительных средств бюджета. Избыток денежных ре-
зервов ведет к неэффективному управлению финансовы-
ми средствами организации.
! Комментарий из практики. Существенная экономия денеж-

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

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

блемы (issue) от риска не всегда являются очевидными для членов
команд управления программами. Главные различия заключаются
в том, что риски могут быть как позитивными, так и негативны-
ми, в то время как потенциальная проблема несет в себе толь-
ко негатив. Кроме того, любой риск имеет два основных пара-
метра — вероятность возникновения и влияние, в то время как
потенциальная проблема оценивается по параметру влияния и не
всегда может иметь оценку вероятности возникновения.
170 Глава 6
Контракты с поставщиками компонентов программы

анализируются для проверки эффективности управления рис-
ками в работах с внешними поставщиками программы в соот-
ветствии с подписанными с ними контрактами.
Любой контракт с внешним поставщиком состоит из двух
частей: юридических условий и положений (terms & condi-
tions) и заданий по работам поставщика (scope of works). Рис-
ки контракта могут содержаться в каждой из этих частей.
! Комментарий из практики. Менеджер программы и члены

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

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

щимся менеджеру программы.
! Комментарий из практики. Риск-менеджер является, как

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

граммы учесть опыт мониторинга и контроля над рисками в
прошлых программах компании.
Мониторинг окружения программы необходим для от-
слеживания влияния окружающей среды на риски программы
и стратегии реагирования, которые могут быть изменены под
воздействием внешних факторов.
Мониторинг изменений в сфере законодательства не-
обходим для своевременного учета и отражения в стратегиях
реагирования на риски программы изменений в сфере зако-
нодательства.
Основными выходами процесса являются: превентив-
ные действия, обновления реестра рисков, обновления плана
управления рисками, обновления базы усвоенных уроков.
Превентивные действия могут выражаться в использова-
нии резервов, инициации запросов на изменения планов про-
граммы, вовлечения дополнительных ресурсов — по результа-
там мониторинга и контроля рисков программы.
Обновления реестра рисков могут включать изменения в
оценках вероятностей и влияния рисков, стратегий реагирова-
ния, владельцев рисков, действий по реализации выбранных
стратегий реагирования.
Обновления плана управления рисками могут включать
изменения в процессах и процедурах управления рисками,
172 Глава 6
форматах ведения реестра рисков и формах отчетов по управ-

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

 LL-6.5.1. Любые резервы, выделенные на управление про-
граммой, могут быть выражены в доле бюджета програм-
мы (т. е. в денежном выражении). Недостаток денежных
резервов требует их пополнения за счет выделения допол-
нительных средств бюджета. Избыток денежных резервов
ведет к неэффективному управлению финансовыми сред-
ствами компании.
 LL-6.5.2. Существенная экономия денежных резервов
программы по ее завершении является результатом пло-
хого планирования и некачественной оценки и анализа
рисков программы. Владельцы бизнеса и высшее руко-
водство компании могут обвинить менеджера программы
в замораживании денежных средств в виде резервов на
управление рисками программы, которые оказались не-
востребованными.
 LL-6.5.3. Отличия потенциальной проблемы от риска не
всегда являются очевидными для членов команд управле-
ния программами. Главные различия заключаются в том,
что риски могут быть как позитивными, так и негативны-
ми, в то время как потенциальная проблема несет в себе
только негатив. Кроме того, любой риск имеет два основ-
ных параметра — вероятность возникновения и влияние,
в то время как потенциальная проблема оценивается по
параметру влияния и не всегда может иметь оценку веро-
ятности возникновения.
 LL-6.5.4. Менеджер программы и члены команды управ-
ления программой обязаны проводить мониторинг и кон-
троль над рисками контрактов в части заданий по рабо-
там поставщика. К анализу рисков в части юридических

условий и положений контрактов необходимо привлекать
представителей юридической службы организации и ме-
неджеров по контрактам.
 LL-6.5.5. Риск-менеджер является, как правило, экс-
руководителем программы, обладающим огромным опы-
том и «чутьем» в управлении рисками. Он должен иметь
полномочия, позволяющие ему получать любые докумен-
ты и сведения о ходе выполнения программы, и быть не-
зависимым в своих суждениях и рекомендациях. Часто его
рекомендации позволяют менеджеру программы изменить
оценки рисков и выбранные стратегии реагирования на
более эффективные и обнаружить новые значительные
риски, не известные команде управления программой.
 Бизнес-кейс «Программа по выводу

на рынок нового фармацевтического препарата»
Проблемная ситуация. Планы управления рисками компо-
нентов программы используются для анализа влияния рисков
компонентов на риски других компонентов программы. В слу-
чае обнаружения такого влияния данные риски становятся
рисками всей программы.
Описание бизнес-кейса. Крупная фармацевтическая ком-
пания инициировала программу по выводу на рынок нового
лекарственного препарата. Основными целями программы
были:
 вывод препарата на рынок полусинтетических антибиоти-
ков с долей рынка (market share) в 10%;
 рост объема продаж (+70%).
Основными компонентами программы являлись:
1) операционная задача регистрации препарата;
2) проект разработки стратегии продвижения;
3) операционная задача заказа производства;
4) проект переговоров с дистрибьюторами;
5) проект создания спроса;
6) операционная задача по организации продаж.
174 Глава 6
Команды управления компонентами программы иденти-

фицировали следующие основные риски:
1) срыв сроков получения регистрационного удостоверения
на лекарственное средство;
2) отказ в получении разрешения на выпуск препарата на
российский рынок;
3) невозможность проведения качественного анализа рынков
центральных городов и регионов и потребительских пред-
почтений в каждом из них;
4) увеличение активности конкурентов из-за недостаточной
рекламы продукта;
5) длительный анализ конкурентных преимуществ продукта,
способный сорвать сроки его вывода на российский рынок.
В ходе работ компонента (1) удалось получить регистра-
ционное удостоверение на лекарственное средство в установ-
ленные сроки и ввести новую позицию в прайс-листы дистри-
бьюторов по компоненту (4). В работах компонента (3) было
обеспечено подтверждение заказа на производство, и препарат
поступил в серийное производство компании. Объемные по-
ставки препарата стали проходить таможенное оформление и
поступать на фармацевтический склад компании. В это время
руководитель компонента (1) информировал менеджера про-
граммы о наступлении риска (2) и получении официального
отказа в разрешении выпуска препарата на российский рынок.
Работы всех компонентов программы были срочно останов-
лены, и компания была вынуждена возвращать все поставки
препарата на склады заводов-изготовителей для реализации на
рынках других стран.
Выводы и рекомендации. Выполнение планов реагиро-
вания на риски компонентов программы может оказать вли-
яние на работы других компонентов программы. Задачами
менеджера программы являются обнаружение и отслеживание
взаимных влияний рисков различных компонентов програм-
мы. В случае обнаружения таких взаимных влияний рисков
компонентов необходим дополнительный анализ их влияния
на результаты программы в целом. Результатом такого анализа
может быть решение о переводе рисков компонентов в реестр
рисков всей программы.
ГЛАВА 7
Коммуникации программы
Значение области знаний «Управление коммуникация-

ми программы» стандарта PMI The Standard for Program
Management®. В данной области знаний стандарта описана
одна из девяти ключевых компетенций руководителя програм-
мы по управлению коммуникациями программы. Три процес-
са, рекомендованных стандартом в данной области знаний,
относятся к фазам жизненного цикла определения и достиже-
ния выгод программы (табл. 12).
Таблица 12

«Управление коммуникациями программы»
Планирование коммуникаций Определение программы
Распространение информации Достижение выгод программы
Отчетность об исполнении Достижение выгод


176 Глава 7

управление коммуникациями программы
Процесс: планирование коммуникаций
Основные цели процесса планирования коммуникаций

программы:
 определение коммуникационных потребностей стейкхол-
деров программы в своевременном получении информа-
ции о ее работах и результатах;
 получение ответов на вопросы: какая информация о про-
грамме, в каком виде, кому нужна, кто должен ее готовить
и направлять, как часто и по какому коммуникационному
каналу;
 обеспечение своевременного получения точной и полной
информации о работах и результатах компонентов про-
граммы.
Интерпретация процесса планирования коммуникаций
практике. При планировании коммуникаций программы ме-
неджеру программы необходимо учитывать следующие осо-
бенности:
 длительность и сложность программ сказывается на зна-
чительном изменении состава стейкхолдеров и их комму-
никационных потребностей в ходе жизненного цикла про-
граммы;
 в коммуникациях крупных и международных программ
могут возникнуть барьеры, связанные с языковыми, куль-
турными, ментальными различиями стейкхолдеров;
 тщательное планирование коммуникаций является одним
из ключевых факторов успеха любой программы.
NB! Всевозможные коммуникации со стейкхолдерами

программы (формальные и неформальные, вертикаль-
ные и горизонтальные, письменные и устные, внутренние
и внешние) занимают до 90% рабочего времени менед-
жера программы.
Коммуникации программы 177
Формальные коммуникации имеют документальное под-

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

ции с вышестоящими руководителями и подчиненными кон-
кретного стейкхолдера программы, а горизонтальными — его
коммуникации с коллегами на том же уровне подчиненности.
В крупных комплексных программах принимает участие
большое количество стейкхолдеров, и число коммуникаци-
онных взаимодействий и связей, возникающих между ними в
ходе выполнения работ программы, может быть огромным.
Максимальное количество коммуникационных каналов,
возникающих в команде управления программой из N членов,
может быть подсчитано по формуле: N  (N – 1) / 2. Напри-
мер, если в команде 20 членов, то максимальное число комму-
никационных каналов равно 190, а если в команде 40 членов,
то максимальное число коммуникационных каналов равно
780.
Поэтому чрезвычайно важно эффективно управлять ком-
муникациями в команде управления программой, и для это-
го прежде всего необходимо разработать качественный план
управления коммуникациями.
В ходе данного процесса необходимо проанализировать
требования к коммуникациям и реестр участников про-
граммы.
178 Глава 7
Требования к коммуникациям должны быть выявлены,

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

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

грамме могут быть подвержены значительным изменениям.
 LL-7.1.1. Всевозможные коммуникации со стейкхолдерами
программы (формальные и неформальные, вертикальные
и горизонтальные, письменные и устные, внутренние и
внешние) занимают до 90% рабочего времени менеджера
программы.
 LL-7.1.2. Неформальные коммуникации являются источ-
никами рисков программы. Все решения по управлению
программой должны быть подтверждены документально в
целях контроля и проверки их исполнения, а также воз-
можности последующего аудита управления программой.
 LL-7.1.3. Чрезвычайно важно эффективно управлять ком-
муникациями в команде управления программой, и для
этого прежде всего необходимо разработать качественный
план управления коммуникациями.
 LL-7.1.4. План коммуникаций обеспечивает постоянный
обмен только той информацией, которая представляет
ценность для достижения успеха программы, или той ин-
формацией, отсутствие которой может привести к нега-
тивному результату программы.

Процесс: распространение информации
Основные цели процесса распространения информации

программы:
 реализация плана управления коммуникациями програм-
мы путем доведения до сведения стейкхолдеров информа-
ции о выполнении программы;
 обеспечение регулярного обмена информацией о про-
грамме между заказчиками, спонсорами и руководителями
Интерпретация процесса распространения информа-

ции программы и рекомендации автора по его применению
на практике. Информация о программе может включать сле-
дующие сведения:
 отчеты о статусе выполнения программы на определенный
момент (т. е. на дату отчета);
 отчеты о прогрессе программы (результатах, полученных
за определенный прошедший период, например за про-
шедший месяц или квартал);
 заполненные шаблоны запросов на изменения программы
и ее компонентов;
 отчеты об освоении бюджета программы;
 внешнюю информацию о программе, подготовленную для
государственных и надзорных органов в соответствии с за-
конодательными нормами;
 сообщения о программе, интервью и публикации для СМИ.
В данном процессе активно используются: план управ-
ления коммуникациями и коммуникационные сообщения о
программе, направляемые регулярно различным стейкхолде-
рам программы в соответствии с данным планом.
NB! При появлении большого количества запросов
стейкхолдеров на получение внеплановой информации
о программе менеджеру программы необходимо внести
изменения в план управления коммуникациями для удов-
летворения информационных потребностей стейкхолде-
ров, не получивших отражения в данном плане.

са являются навыки коммуникаций и методы распростране-
ния информации.
Навыки коммуникаций (communication skills) должны
быть непременным качеством менеджера программы для эф-
фективных коммуникаций на всех уровнях управления про-
граммой — как на уровне высшего руководства компании и
программного комитета, так и на уровне руководителей ком-
понентов.
Среди таких навыков особенно важным для руководите-
ля крупной программы является искусство проведения эф-
182 Глава 7
фективных презентаций (presentation skills). Обладание таким

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

программы эффективных навыков коммуникаций должно обес-
печить получение и верное понимание определенными стейкхол-
дерами определенной информации в определенное время.
Методы распространения информации (information dis-

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

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

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

 LL-7.2.1. При появлении большого количества запросов
стейкхолдеров на получение внеплановой информации о
программе менеджеру программы необходимо внести из-
менения в план управления коммуникациями для удовлет-
ворения информационных потребностей стейкхолдеров,
не получивших отражения в данном плане.
 LL-7.2.2. Использование менеджером программы эффек-
тивных навыков коммуникаций должно обеспечить полу-
чение и верное понимание определенными стейкхолдера-
ми определенной информации в определенное время.
 LL-7.2.3. Обязанностью менеджера программы является
организация проведения сессии по анализу извлеченных
уроков в случае фактов возникновения серьезных ошибок
в управлении программой.

Процесс: отчетность об исполнении программы
Основные цели процесса отчетности об исполнении про-

граммы:
 консолидация данных по исполнению работ программы,
чтобы обеспечить стейкхолдеров информацией об исполь-
зовании ресурсов компании для достижения результатов
программы;
184 Глава 7
 консолидация данных по исполнению ключевых работ

компонентов программы — как проектных, так и опера-
ционных — для обеспечения стейкхолдеров информацией
о ходе выполнения критических работ компонентов.
Интерпретация процесса отчетности об исполнении
практике. В данном процессе используются отчеты об испол-
нении компонентов программы и отчеты об отклонениях.
Отчеты об исполнении компонентов программы консо-
лидируются офисом управления программой в отчет об испол-
нении программой в целом.
Отчеты об отклонениях — как позитивных, так и нега-
тивных — возникают в случаях, когда фактические результаты
программы не соответствуют плановым и могут включать:
 отклонения по стоимости;
 отклонения по срокам;
 отклонения в содержании;
 отклонения по качеству;
 отклонения от утвержденных требований заказчика.
В результате анализа отклонений могут быть приняты ре-
шения по корректирующим действиям (corrective actions), на-
правленным на коррекцию планов и ресурсов программы.
Основными инструментами данного процесса являются
сбор и систематизация информации о статусе программы и
совещания по статусу программы.
Сбор и систематизация информации о статусе про-
граммы обеспечивает наличие полной и достоверной инфор-
мации о статусе программы, получаемой из следующих основ-
ных источников:
 отчеты о программе (включающие отчеты о статусе про-
граммы, прогрессе и прогнозы, извлеченные уроки, жур-
налы потенциальных проблем, отчеты о закрытии компо-
нентов);
 архивы программы (включающие официальную коррес-
понденцию и переписку с заказчиками, поставщиками,
внешними стейкхолдерами);
 презентации о программе;
 отзывы стейкхолдеров;
 сообщения стейкхолдерам (в том числе о разрешенных
проблемах, одобренных запросах на изменения, реализа-
ции планов по управлению рисками программы).
Совещания по статусу программы проводятся регулярно
с определенной периодичностью в целях обмена информацией
о ходе выполнения программы. Частота проведения совеща-
ния о статусе программы зависит от его уровня и снижается по
мере повышения уровня совещания. Пример регламента сове-
щаний о статусе программы с различной частотой на различ-
ных уровнях управления программой представлен в табл. 13.
Таблица 13
Пример регламента совещаний о статусе программы

с различной частотой на различных уровнях
управления программой
Название
Ведущий Участники Частота
совещания по
совещания совещания проведения
статусу программы
Совещание Председатель Члены про- Раз в месяц

программного программного граммного
комитета комитета комитета
Совещание команды Менеджер Команда Раз

управления программы управления в две недели
программой программой
Совещания команды Руководитель Команда Раз

управления компо- компонента управления в неделю
нентом программы компонентом
Выходами процесса являются: отчеты по выполнению

программы, исполнению контрактов, ответы на запросы за-
казчика или спонсора программы, регулярные отчеты, пре-
зентации по ключевым показателям исполнения.
Отчеты по выполнению программы и исполнению кон-
трактов консолидируют результаты работ программы и ее
186 Глава 7
NB! Степень детализации отчетов об исполнении про-

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

нии должны включать различные возможные формы представле-
ния данных: круговые и столбчатые диаграммы, накопительные
кривые стоимостей ресурсов программы (S-curves), гистограммы
и таблицы, данные освоенного объема (earned value data).
Презентации по ключевым показателям исполнения со-

держат информацию о выполнении плана реализации выгод
программы (benefits realization plan), регулярно предоставля-
емую на рассмотрение комитета по управлению программой.
! Комментарий из практики. Результатами регулярной подго-

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

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

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

ные возможные формы представления данных: круговые и
столбчатые диаграммы, накопительные кривые стоимос-
тей ресурсов программы, гистограммы и таблицы, данные
освоенного объема.
 LL-7.3.3. Результатами регулярной подготовки, анализа и
предоставления отчета о реализации выгод программы мо-
гут быть решения комитета по управлению программой об
ускорении, приостановке, прекращении работ отдельного
компонента либо об инициации нового компонента про-
граммы.
 LL-7.3.4. Несовпадение значений метрик из плана и от-
чета о реализации выгод может послужить причиной из-
менения содержания отдельных компонентов программы
или программы в целом.
 Бизнес-кейс «Программа многопрофильного

финансово-промышленного холдинга»
Проблемная ситуация. В отличие от проекта, порождающего
уникальные результаты и продукты, программа должна обес-
печить получение выгоды в бизнесе компании. Значительная
часть материальных финансовых выгод возникает в ходе экс-
плуатации продуктов проектов в операционной деятельности
компании. Отслеживание выгод обеспечивается в ходе регу-
лярной подготовки, анализа и предоставления отчета о реа-
лизации выгод комитету по управлению программой (program
board). На основе сопоставления данных отчета с планом ре-
ализации выгод программы (benefits realization plan) комитет
по управлению программой может принять решение об уско-
рении, приостановке, прекращении работ отдельного компо-
нента либо об инициации нового компонента программы.
Программа многопрофильного финансово-промышленно-
го холдинга включала компоненты:
 А — операционная деятельность по производству и сбыту
основной продукции холдинга;
 В — операционная деятельность по производству и сбыту
дополнительной продукции холдинга;
188 Глава 7
 С — проект по монтажу, наладке и сдаче в промышленную

эксплуатацию новой производственной линии.
Отчет о реализации выгод программы, представленный на
заседании комитета по управлению программой, включал сле-
дующие данные:
Плановое Фактическое
Метрика программы значение значение
метрики метрики
Готовность по сдаче новой 70% 30%

производственной линии С
в промышленную эксплуатацию
Объем реализации продукции А 1 млрд руб. 2,6 млрд руб.
Объем реализации продукции В 0,8 млрд руб. 0,1 млрд руб.
На основе представленного отчета комитет по управлению

программой принял следующее решение.
1. Прекратить работы компонента В программы по произ-
водству и сбыту дополнительной продукции холдинга из-
за значительного отставания от плана и неоправданных
ожиданий по потребностям рынка в данной продукции.
2. Передать ресурсы компонента В в компоненты А и С
в целях:
 дальнейшего производства и сбыта основной продук-
ции холдинга, востребованной на рынке;
 ликвидации отставания по срокам сдачи новой произ-
водственной линии С в промышленную эксплуатацию.
Выводы и рекомендации. Регулярные подготовка, ана-
лиз и предоставление отчета о реализации выгод комитету по
управлению программой позволяют обеспечить наиболее эф-
фективное использование ограниченных ресурсов компании
в целях получения выгод программы путем принятия реше-
ний об ускорении, приостановке, прекращении работ отдель-
ного компонента либо об инициации нового компонента про-
граммы.
ГЛАВА 8
Поставки программы
Значение области знаний «Управление поставками про-

управлению поставками программы. Четыре процесса, реко-
мендованных стандартом в данной области знаний, относятся
к фазам жизненного цикла определения, достижения выгод и
завершения программы (табл. 14).
Таблица 14

«Управление поставками программы»
Планирование поставок программы Определение программы
Осуществление поставок программы Достижение выгод программы
Администрирование поставок Достижение выгод программы

программы
Закрытие поставок программы Завершение программы

190 Глава 8

управление поставками программы
Процесс: планирование поставок программы
Основные цели процесса планирования поставок про-

граммы:
 тщательный анализ и планирование поставок в целях ра-
ционального использования и экономии бюджета про-
граммы;
 обеспечение качественной интеграции поставок компо-
нентов программы;
 обеспечение качественного документирования процес-
сов поставок, включая контроль заключения договоров с
внешними поставщиками.
Интерпретация процесса планирования поставок и ре-
комендации автора по его применению на практике. Дан-
ный процесс позволяет менеджеру программы определить, ка-
кие поставки внешних компаний должны быть осуществлены,
когда и на основе каких стратегий организации поставок.
В данном процессе должны быть проанализированы: фак-
торы внешней среды, распределение бюджета программы,
описание содержания компонентов, устав программы.
Факторы внешней среды включают специфику законода-
тельства в сфере условий и положений контрактов с постав-
щиками программы.
Распределение бюджета программы отражает распреде-
ление бюджета программы между ее компонентами.
Описания содержания компонентов используются для
определения содержания работ по поставкам в контрактах с
внешними поставщиками.
Устав программы необходим для согласования плана по-
ставок с целями программы и ее компонентов.
Инструментами и методами процесса являются: анализ
поставщиков услуг, планирование поставок, экспертные оцен-
ки, оценка возможностей компании, анализ «производить са-
мим или покупать на стороне».
Поставки программы 191
Анализ поставщиков услуг позволяет определить имею-

щихся на рынке потенциальных поставщиков путем их срав-
нительного анализа.
! Комментарий из практики. Для проведения сравнительного

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

управления поставками, в котором участвует менеджер про-
граммы, руководители компонентов, специалисты подразделе-
ний компании, непосредственно занимающиеся организацией
поставок (сотрудники подразделений материально-техничес-
кого снабжения, административно-хозяйственных отделов
и др.), представители юридической службы, финансовых ор-
ганов и другие стейкхолдеры программы, компетентные в во-
просах поставок внешних компаний.
Экспертные оценки могут быть получены от специалис-
тов в предметной области поставок и специфики конкретных
продуктов или услуг поставки, а также от представителей юри-
дической службы компании (в области подготовки контрактов
с поставщиками).
Оценка возможностей компании позволяет определить
области поставок программы, которые не могут быть обеспе-
чены ресурсами компании.
Необходимость привлечения внешних поставщиков воз-
никает в большинстве крупных комплексных программ, так
как компания оказывается не в состоянии выполнить весь
объем работ программы собственными силами. Такая необхо-
димость возникает по причинам:
 отсутствия свободных ресурсов компании;
 отсутствия собственных компетенций в определенных ра-
ботах программы и ее компонентах;
192 Глава 8
 недостаточности собственных ресурсов для выполнения

работ программы в установленные сроки;
 более дешевой стоимости внешней поставки по сравнению
с выполнением работ поставки собственными силами.
! Комментарий из практики. Максимальный риск возникает

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

(«make or buy» analysis) позволяет принять окончательное ре-
шение по определению перечня работ программы и/или по-
ставки определенных продуктов и услуг программы, которые
следует покупать на стороне.
Выходы процесса: стандарты по поставкам программы;
план по поставкам программы; обновления плана бюджетиро-
вания/финансирования программы.
План по поставкам программы должен включать стан-
дарты по закупкам программы и описание всех работ и их ре-
зультатов по определению, интеграции и координации поста-
вок программы. Основные разделы плана:
 обновления содержания работ компонентов программы
(component statements of works updates) — включают ди-
рективы руководителям компонентов по выполнению от-
дельных работ внешними поставщиками или собствен-
ными ресурсами, а также указания при необходимости
взаимодействия с руководителями других компонентов
при организации комплексной поставки в интересах про-
граммы;
 типы контрактов с поставщиками — включают решения
по выбранным контрактам с поставщиками следующих
основных типов:
– контракт с фиксированной ценой (fixed price contract);

– контракт с возмещением стоимости (cost reimbursable
contract);
– контракт с оплатой стоимости затраченного рабочего
времени и материалов (time & materials contract);
! Комментарий из практики. Контракты с фиксированной

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

выявить недостаток ресурсов компании для выполнения ра-
бот программы и поиска недостающих ресурсов на рынке;
 решения по источнику поставки (sourcing decisions) — по-
зволяет определить очевидную необходимость внешних
источников поставки из-за бессмысленности выполнения
поставки ресурсами компании. Например, в случае не-
обходимости для программы разработки автоматизиро-
ванной системы редактора текстов может быть очевидна
необходимость покупки такой готовой системы на рын-
ке, а не разработки такой системы собственными силами
компании;
 определение общих поставок программы — позволяет вы-
явить поставки, необходимые для всей программы или для
ряда ее компонентов. Например, это может быть закуп-
ка партии ноутбуков для персонала команды управления
программой и всех ее компонентов.
194 Глава 8
! Комментарий из практики. Определение общих поставок

программы позволяет существенно снизить затраты и сэкономить
бюджет программы. Невыявление общих поставок программы
может привести к закупкам однотипных товаров по разным це-
нам для разных компонентов программы и появлению дополни-
тельных издержек.
 процедуры оценки предложений поставщиков — необхо-

димы для объективной оценки предложений поставщиков
и используют критерии оценки, такие как, например, ско-
рость поставки, цена, качество или опыт поставщика в по-
добных поставках, его репутация и др.;
 перечни квалифицированных поставщиков (qualified
seller lists) — определяют методы анализа и отбора ква-
лифицированных поставщиков на основе использования
сведений о них из открытых источников, Интернета, от-
зывов заказчиков, встреч с представителями поставщи-
ков и др.
Обновления плана бюджетирования/финансирования
программы могут потребоваться при необходимости выделе-
ния дополнительного финансирования для заключения кон-
трактов с поставщиками программы.

 LL-8.1.1. Для проведения сравнительного анализа постав-
щиков программы желательно привлекать специалистов
подразделений компаний, непосредственно занимаю-
щихся организацией поставок в своей повседневной де-
ятельности. Эти специалисты хорошо знают рынок и де-
ятельность конкретных внешних компаний, способных
осуществить необходимую для программы поставку.
 LL-8.1.2. Максимальный риск возникает при необходимос-
ти привлечения внешнего поставщика для выполнения
работ программы, в которых у команды управления про-
граммой нет собственных компетенций. В этом случае
заказчик (менеджер программы или команда управления
программой) оказывается не в состоянии оценить содер-

жание и качество поставки.
 LL-8.1.3. Контракты с фиксированной ценой и с оплатой
стоимости затраченного рабочего времени и материалов
активно используются на отечественном рынке, в то вре-
мя как контракт с возмещением затрат является редкос-
тью. Тем не менее такой контракт становится необходи-
мым в условиях развитого рынка и высокой конкуренции,
так как его применение позволяет заказчику «удержать»
поставщика при возникновении риска его ухода к конку-
ренту. Это обеспечивается гарантией заказчика полностью
компенсировать затраты поставщика и даже при опреде-
ленных условиях выплатить поставщику дополнительное
вознаграждение, составляющее его чистую прибыль, так
как затраты уже компенсированы. Размер чистой прибы-
ли может быть выше прибыли поставщика, заложенной в
фиксированной цене его предложения конкуренту.
 LL-8.1.4. Определение общих поставок программы позво-
ляет существенно снизить затраты и сэкономить бюджет
программы. Невыявление общих поставок программы мо-
жет привести к поставкам однотипных товаров по разным
ценам для разных компонентов программы и появлению
дополнительных издержек.

Процесс: осуществление поставок программы
Основные цели процесса осуществления поставок про-

граммы:
 руководство и обеспечение внешних поставок, необхо-
димых для выполнения работ и достижения целей про-
граммы;
 обеспечение всех необходимых внутренних поставок про-
граммы, выполняемых структурными подразделениями
компании.
196 Глава 8
Интерпретация процесса осуществления поставок

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

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

планы поставок компонентов, план управления программой.
Активы программы основаны на использовании политик
и процедур, принятых в компании по управлению поставками
внешних контрагентов.
! Комментарий из практики. Политики и процедуры, при-

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

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

предложений, процедуры управления контрактами, процедуры
управления изменениями, выбор поставщиков.
Конференции контрагентов (bidder conferences) — сове-
щания с участием потенциальных поставщиков до подготовки
ими предложений по поставкам для заказчика. Целью таких
совещаний является обеспечение единого и ясного понимания
всеми потенциальными поставщиками требований по постав-
ке, включая технические и контрактные требования к поставке.
! Комментарий из практики. Как правило, конференции

контрагентов проводятся в виде сессий «вопрос — ответ» между
представителями заказчика поставки (например, членами тендер-
ного комитета) и потенциальными поставщиками. Члены тендер-
ного комитета отвечают на вопросы поставщиков относительно
условий и требований по организации проведения поставки.
NB! Важно, чтобы все потенциальные поставщики были

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

ставщиков об условиях поставки и запрашивают предложения
К основным видам запросов на предложения относятся:
 запрос исходной информации о поставщике (Request for
Information — RFI);
 запрос предложения по комплексной поставке решения
(Request for Proposal — RFP);
 запрос предложения по закупке товаров (Request for Quo-
tation — RFQ).
Дальнейшая разработка списка аттестованных про-
давцов позволяет определить перечень поставщиков, которым
будут направлены запросы на предложения.
198 Глава 8
! Комментарий из практики. Полезными сведениями для

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

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

 LL-8.2.1. Политики и процедуры, принятые в компании по
управлению поставками, могут ограничивать возможные
управленческие решения менеджера программы в этой об-
ласти, в частности:
– требовать заключения контракта определенного типа
при цене поставки, превышающей определенный ли-
мит;
– ограничивать количество участников тендера;
– допускать к участию в тендере поставщиков, подтверж-
дающих свой опыт свыше определенного количества лет.
 LL-8.2.2. Как правило, конференции контрагентов прово-
дятся в виде сессий «вопрос — ответ» между представите-
лями заказчика поставки (например, членами тендерного
комитета) и потенциальными поставщиками. Члены тен-
дерного комитета отвечают на вопросы поставщиков от-
носительно условий и требований по организации прове-
дения поставки.
 LL-8.2.3. Важно, чтобы все потенциальные поставщи-
ки были приглашены и приняли участие в конференции
контрагентов. Отсутствующий на данной конференции
потенциальный поставщик оказывается лишенным всей
дополнительной информации по условиям поставки и на-
ходится не в равных условиях конкурса с другими потен-
циальными поставщиками.

Процесс: администрирование поставок программы
Основные цели процесса администрирования поставок

программы:
 обеспечение проведения поставки в соответствии с кон-
трактом, заключенным между заказчиком и поставщиком;
 проведение необходимых действий в случае нарушения ус-
ловий и положений контракта.
200 Глава 8
Интерпретация процесса администрирования поставок

В ходе данного процесса менеджер программы должен органи-
зовать проведение работ и мероприятий по обеспечению про-
ведения поставок программы в соответствии с заключенными
контрактами с поставщиками.
В данном процессе используются: контракты, одобренные
запросы на изменения, отчеты об исполнении, одобренные
запросы на платежи.
Одобренные запросы на изменения — любые изменения
в контрактах с поставщиками, прошедшие процедуру согласо-
вания сторон и утверждения, после завершения которой они
являются одобренными.
Отчеты об исполнении содержат информацию о выпол-
нении поставщиком своих обязательств перед заказчиком по
поставке в соответствии с заключенным контрактом.
Одобренные запросы на платежи должны быть оформле-
ны менеджером программы (или руководителем компонента) и
направлены в финансовый орган компании в случае принятия
результатов поставки и отсутствия претензий к поставщику.
Основными инструментами и методами процесса явля-
ются: управление поставщиками, система контроля платежей,
инспекции и аудиты, система управления бюджетом.
Управление поставщиками включает ряд компонентов,
среди которых ключевыми являются:
 контракты с поставщиками;
 план управления контрактами;
 план управления поставками;
 отчеты о поставках;
 система управления изменениями.
! Комментарий из практики. В крупных международных про-

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

разрешать вопросы, возникающие в связи с оплатой выпол-
ненных поставок и в частности исключать дублирование пла-
тежей. Данная система должна включать процедуры получения
согласований и разрешений на проведение платежей постав-
щикам программы.
Инспекции и аудиты позволяют получить подтверждение
выполнения поставщиком всех его обязательств по контрак-
ту о поставке. В случае обнаружения отклонений от условий
контракта аудитор может инициировать запрос на изменение
планов поставки либо исправлений результатов поставки.
Система управления бюджетом должна обеспечить эко-
номию и наличие финансовых средств программы для свое-
временной оплаты поставок и также исключить дублирование
оплат по выполненным поставкам.
Выходами процесса являются всевозможные обновления
базового бюджета, плана управления поставками, контрактов,
отчеты об освоенном объеме, ежемесячные отчеты о прогрес-
се, отчеты об исполнении контрактов подряда по ключевым
показателям, а также одобренные платежи и обновления гра-
фика платежей.
Одобренные платежи должны быть направлены в финан-
совую службу компании для проведения платежей поставщи-
кам за выполненные и принятые поставки программы.
 LL-8.3.1. В крупных международных программах постав-
щик может осуществлять работы по поставке программы
из зарубежного государства. В таком случае в контракте с
поставщиком должно быть сказано, по законодательству
какой страны будут разрешаться споры между заказчиком
и поставщиком, включая рассмотрение апелляций и пре-
тензий в судебных инстанциях и в арбитраже.
 LL-8.3.2. Система контроля платежей призвана своевре-
менно разрешать вопросы, возникающие в связи с опла-
той выполненных поставок и в частности исключать дуб-
лирование платежей. Данная система должна включать
процедуры получения согласований и разрешений на про-
ведение платежей поставщикам программы.
202 Глава 8

Процесс: закрытие поставок программы
Основные цели процесса закрытия поставок программы:

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

вершении поставки либо в случае досрочного расторжения
контракта в соответствии с контрактными условиями и поло-
жениями.
! Комментарий из практики. В случае досрочного расторже-

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

их работ в базе извлеченных уроков и в будущих поставках.
Финансовая сверка при отнесении затрат необходима
для исполнения финансовой дисциплины, политик и проце-
дур компании и будущих финансовых аудитов.
! Комментарий из практики. Сроки проведения финансовых

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

ты, отчеты об исполнении поставок по закрытым контрактам,
отнесение затрат при закрытии бюджета, обновленные извле-
ченные уроки.
Закрытые контракты должны быть помещены в архив
компании в соответствии с действующими процедурами дело-
производства. Сроки хранения закрытых контрактов в архивах
компании определяются действующим законодательством.
204 Глава 8
! Комментарий из практики. Менеджер программы обязан

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

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

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

 LL-8.4.1. В случае досрочного расторжения контракта по
данной процедуре требуется документировать все выпол-
ненные и невыполненные обязательства поставщика на
момент расторжения контракта и причины его досрочного
расторжения. Менеджеру программы следует незамедли-
тельно планировать и организовывать исполнение невы-
полненных обязательств альтернативными поставщиками.
 LL-8.4.2. Сроки проведения финансовых аудитов компа-
нии, как правило, редко совпадают со сроками закрытия
контрактов с поставщиками. Поэтому финансовая сверка
и отнесение затрат на соответствующие центры финансо-
вой ответственности являются необходимыми в процессе
закрытия поставок.
 LL-8.4.3. Менеджер программы обязан уведомить всех за-
интересованных стейкхолдеров программы, включая ру-
ководителей компонентов, о закрытых контрактах для из-
бегания запросов на очередные поставки программы по
недействующим контрактам.
 Бизнес-кейс «Программа автоматизации

процессов корпоративного и розничного
бизнеса коммерческого банка»
Проблемная ситуация. Определение общих поставок про-
граммы позволяет существенно снизить затраты и сэкономить
бюджет программы. Невыявление общих поставок программы
может привести к поставкам однотипных товаров по разным
ценам для разных компонентов программы и появлению до-
полнительных издержек.
Описание бизнес-кейса. Крупный коммерческий банк
инициировал программу автоматизации бизнес-процессов,
включающую две подпрограммы:
 автоматизации процессов корпоративного бизнеса банка;
 автоматизации процессов розничного бизнеса банка.
В каждой из подпрограмм были инициированы следую-
щие компоненты:
 проект разработки архитектуры ИT-системы;
 проект разработки продукта ИТ-системы;
 проект установки и внедрения ИT-системы;
 операционный компонент обучения пользователей;
 операционный компонент опытной эксплуатации сис-
темы;
 операционный компонент передачи системы в промыш-
ленную эксплуатацию и выхода на запланированные по-
казатели эффективности.
В каждом компоненте были назначены руководители и
сформированы команды специалистов. Для обеспечения рабо-
ты компонентов потребовалось запланировать и осуществить
поставки ноутбуков и рабочих станций. Руководители компо-
нентов подготовили запросы на закупки (RFQ) ноутбуков и
рабочих станций разных производителей с различными кон-
фигурациями, ценами, условиями и сроками поставок. На со-
вещании с руководителями компонентов менеджер програм-
мы попытался убедить их в необходимости проведения общей
закупки всей партии ноутбуков и рабочих станций у опреде-
ленных производителей, но не смог этого сделать. В результа-
206 Глава 8
те закупки и поставки оборудования были проведены децен-

трализованно для разных компонентов программы у разных
вендоров и по различным ценам. Финансовый аудит оценил
существенные потери в бюджете программы из-за отказа от
общей закупки оборудования.
Выводы и рекомендации. Менеджер программы должен
добиваться признания руководителями компонентов необхо-
димости проведения общих поставок в интересах программы
в целом и экономии сроков, стоимости поставок и бюджета
программы.
ГЛАВА 9
Ресурсы программы
Значение области знаний «Управление ресурсами про-

управлению ресурсами программы. Три процесса, рекомендо-
Таблица 15

«Управление ресурсами программы»
Планирование ресурсов программы Определение программы
Приоритезация ресурсов Достижение выгод программы
Управление взаимозависимостью Достижение выгод программы

ресурсов

208 Глава 9

управление ресурсами программы
Процесс: планирование ресурсов программы
Основные цели процесса планирования ресурсов про-

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

сурсах программы: человеческих, финансовых, материальных,
технологических и др. Менеджер программы отвечает за управ-
ление ресурсами на уровне всей программы, а не на уровне
ее компонентов. Однако менеджер программы (выступающий
в ряде случаев в качестве куратора компонентов программы)
оказывает административную и любую организационную под-
держку руководителям компонентов по обеспечению ресур-
сами компонентов программы. Менеджер программы и руко-
водители компонентов выясняют необходимость изменений в
ресурсах. Наличие ресурсов, необходимых для программы или
ее компонента, подтверждается (или не подтверждается) в ходе
анализа перечней доступных ресурсов.
NB! Доступность человеческих ресурсов определяется в

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

инициалы 14 15 16 17 18 19 20
Иванов И. И.
Петров П. П.
Сидоров С. С.
Программа A — 100% времени (full time)
Программа В — 50% времени (half time)
Проект В5 — 25% времени (part time)
Операционная деятельность — 100% времени (full time

operations workload)oop
210 Глава 9
В ресурсном плане программы может содержаться инфор-

мация о приоритетных ресурсах, используемых для выполне-
ния приоритетных работ программы.
Приоритеты программы используются для разрешения
конфликта двойного подчинения (two bosses syndrome), часто
возникающего в матричных организационных структурах при
определении степени загрузки человеческих ресурсов в про-
грамме или в операционной деятельности компании.
Ниже приведена последовательность действий по разре-
шению конфликта двойного подчинения:
Ответственный Действие
Руководитель программы Запрос на человеческий ресурс

(с указанием полной или частич-
ной загрузки в программе)
Функциональный руководитель Согласование выделения ресурса
Руководитель программы Эскалация куратору программы

(при отсутствии согласования
выделения ресурса)
Генеральный директор Приказ о разделении времени

ресурса на программную и опера-
ционную деятельность
Офис управления программой Обновление календаря ресурсов

в соответствии с приказом
Руководитель программы Высвобождение ресурса из про-

граммы по завершении работ
Информационная система управления программой ис-

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

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

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

 LL-9.1.1. Менеджер программы отвечает за обеспечение
доступности и достаточности основных ресурсов на уров-
не компонентов программы, но не за процедуры задей-
ствования необходимых ресурсов в работах компонентов
программы (это задача руководителей компонентов, а не
руководителя программы).
 LL-9.1.2. Полномочия менеджера программы должны быть
достаточными для выполнения процедур, принятых в ком-
пании по управлению материальными ресурсами програм-
мы (например, закупок оборудования, списания затрат на
амортизацию оборудования, лизинговых платежей или
сервисного гарантийного обслуживания).
212 Глава 9

Процесс: приоритезация ресурсов программы
Основные цели процесса приоритезации ресурсов про-

граммы:
 назначение приоритетов критическим и недостаточным
ресурсам программы;
 оптимизация использования критических ресурсов в ком-
понентах программы.
Интерпретация процесса приоритезации ресурсов и ре-
комендации автора по его применению на практике. В ходе
выполнения программы потребность в использовании различ-
ных ресурсов в компонентах программы меняется. Поэтому
данный процесс тесно связан с процессом управления спро-
сом и предложением программы.
! Комментарий из практики. Менеджер программы управля-

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

понентами основано на приоритетах компонентов. Приоритет
компонента соответствует вкладу компонента в достижение
целей и выгод программы. Чем выше вклад компонента в вы-
годы программы, тем выше приоритет компонента. Компо-
ненты программы с самыми высокими приоритетами в пер-
вую очередь получают все необходимые ресурсы компании.
NB! Ограниченность ресурсов компании диктует необхо-

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

быть отражены в обновленном ресурсном плане программы.
Выходами данного процесса являются приоритеты ресур-
сов программы и обновления ресурсного плана программы.

 LL-9.2.1. Достижение баланса в распределении ресурсов
между компонентами основано на приоритетах компонен-
тов. Приоритет компонента соответствует вкладу компо-
нента в достижение целей и выгод программы.
 LL-9.2.2. Приоритеты, назначенные ресурсам программы,
должны быть отражены в обновленном ресурсном плане
программы.

Процесс: управление взаимозависимостью ресурсов
Основные цели процесса управления взаимозависимостью

ресурсов программы:
 исключение влияния взаимозависимостей ресурсов на
плановое достижение целей и выгод программы;
 контроль графика использования ограниченных и дефи-
цитных ресурсов в компонентах программы;
 управление взаимодействием между проектами и опера-
ционными блоками, являющимися компонентами про-
граммы;
 соблюдение границ содержания программы при отслежи-
вании взаимного влияния компонентов.
Интерпретация процесса управления взаимозависимос-
тью ресурсов и рекомендации автора по его применению
на практике. В ходе данного процесса менеджер программы
организует проведение работ, обеспечивающих своевременное
выявление, определение и анализ взаимного влияния ресурсов
214 Глава 9
компонентов программы на выполнение плана управления

программой. Анализ взаимного влияния ресурсов компонен-
тов может быть проведен для определения:
 статуса получения результатов компонентов, необходимых
для получения результатов других компонентов програм-
мы и достижения целей программы;
 всевозможных изменений, принятых в содержании, сро-
ках, стоимости, качестве компонентов и влияющих на
планы работ других компонентов и план управления про-
граммой;
 рисков программы, возникающих вследствие взаимного
влияния ресурсов компонентов.
NB! Менеджер программы отвечает за организацию и

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

стигается при условии обеспечения взаимной поддержки их
руководителей. На практике далеко не всегда удается добиться
такой поддержки. Каждый руководитель проекта отвечает за
организацию работ и достижение целей своего проекта и не
заинтересован делиться ресурсами (всегда ограниченными!) с
другими проектами программы. Между руководителями ком-
понентов возникают конфликты, часто связанные как раз с
нехваткой ресурсов, борьбой за лучшие и дефицитные ресур-
сы для их проектов, или из-за взаимных претензий по поводу
срыва сроков или низкого качества результатов компонентов
программы. Поэтому важным инструментом данного процесса
является управление конфликтами, возникающими между ру-
ководителями компонентов программы. Менеджер программы
часто является «арбитром» в разрешении таких конфликтов и
обязан стремиться к созданию атмосферы взаимной поддерж-
ки и сотрудничества в команде управления программой и ее
компонентами.
Основными методами управления конфликтами являются:

 уклонение (avoiding). Уклонение от сложившейся или по-
тенциальной конфликтной ситуации. Менеджер програм-
мы пытается «развести» конфликтующих руководителей
компонентов и убедить их сохранить между ними дружес-
кие отношения. Или, например, «выиграть время», чтобы
подготовить аргументы для сохранения этих отношений;
 сглаживание (smoothing). Акцентирование внимания на
сферы согласия, а не на сферы разногласий. В этом методе
менеджер программы должен пытаться найти совпадающие
моменты в позициях конфликтующих руководителей ком-
понентов программы и разработать убедительные аргументы
для их усиления и одновременно ослабления разногласий;
! Комментарий из практики. При разработке дополнитель-

ных аргументов, сближающих позиции конфликтующих руково-
дителей компонентов, менеджер программы может использовать
неизвестную им информацию стратегического характера. На-
пример, менеджер программы может использовать в этих целях
результаты обсуждений программы на заседаниях программного
комитета, распоряжения спонсора программы и высшего руковод-
ства компании, неизвестные руководителям компонентов. Такие
аргументы, убедительно представленные менеджером программы,
позволяют сблизить позиции конфликтующих сторон за счет рас-
ширения и углубления совпадений в их позициях и ослабления
противоположных позиций, являющихся источником конфликта.
 нахождение компромиссов (sompromising, win/lose) —

каждая из конфликтующих сторон в чем-то выигрывает
(win), но в чем-то проигрывает (lose), что является опре-
деленным удовлетворением всех конфликтующих сторон;
! Комментарий из практики. Компромисс является на практике

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

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

ущерб другим; предполагает победу только одной стороны
и авторитарное давление мнения этой стороны над други-
ми мнениями;
 сотрудничество (collaborating). Объединение множества то-
чек зрения и мнений с различных сторон ведет к согласию;
! Комментарий из практики. Данный метод, основанный на

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

граммы относится к конфликту как к проблеме, которую
нужно решить рассмотрением альтернатив (win/win) —
все конфликтующие стороны выигрывают (win), так как
в разрешении конфликта менеджеру программы удалось
объединить их самые сильные предложения.
! Комментарий из практики. Данный метод, редко достижи-

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

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

 LL-9.3.1. Менеджер программы отвечает за организацию
и управление эффективным взаимодействием ресурсов
компонентов, но не за управление ресурсами самих ком-
понентов. Такое управление является ответственностью
руководителей проектов и блоков операционной дея-
тельности, входящих в программу в качестве ее компо-
нентов.
 LL-9.3.2. При разработке дополнительных аргументов,
сближающих позиции конфликтующих руководителей
компонентов, менеджер программы может использовать
неизвестную им информацию стратегического характера.
 LL-9.3.3. Одобренные, отклоненные или отложенные из-
менения ресурсов программы заносятся в журнал управ-
ления изменениями программы (program change manage-
ment log). Ведение данного журнала является обязанностью
офиса управления программой.
 LL-9.3.4. Компромисс является на практике наиболее
частым выходом из конфликтной ситуации, но не самым
эффективным. Компромисс возможен только в случае на-
хождения гибкого разрешения конфликта, сочетающего
мнения конфликтующих сторон. При необходимости по-
иска строгого однозначного решения компромисс невоз-
можен и выходом из конфликтной ситуации может быть
только победа одной из сторон и принуждение противопо-
ложной стороны согласиться с победившей стороной.
218 Глава 9
 LL-9.3.5. «Сотрудничество», основанное на постепенном,

демократическом проявлении стремления менеджера про-
граммы объединить множество точек зрения и мнений
с различных сторон, требует времени и длительных об-
суждений позиций конфликтующих сторон. Применение
такого метода возможно, если менеджер программы рас-
полагает таким временем, так как разрешение конфликта
не является срочным и его можно отложить. Срочность
разрешения конфликта может потребовать использования
другого метода, например принуждения.
 LL-9.3.6. «Решение проблемы», редко достижимое на
практике, является наиболее эффективным способом раз-
решения конфликта, так как менеджеру программы уда-
ется найти сочетание самых сильных предложений кон-
фликтующих сторон в интересах каждой из них и успеха
 Бизнес-кейс «Программа внедрения ERP

системы финансово-промышленного холдинга»
Проблемная ситуация. При разработке дополнительных ар-
гументов, сближающих позиции конфликтующих руководите-
лей компонентов, менеджер программы может использовать
неизвестную им информацию стратегического характера.
Описание бизнес-кейса. В программе внедрения ERP-
системы (Enterprise Resource Planning) финансово-промыш-
ленного холдинга были инициированы работы восьми компо-
нентов, включающие разработку отдельных модулей системы,
их отладку и операционную эксплуатацию на предприятиях
холдинга. На очередном совещании команды управления про-
граммой возник конфликт между двумя руководителями ком-
понентов, отвечающими за разработку отдельных модулей
системы, обеспечивающих работу финансовых служб холдин-
га. Причиной конфликта была борьба за очередность исполь-
зования лучших и ограниченных ресурсов бизнес-аналитиков
в компонентах программы А и В по разработке двух модулей
системы. Оба компонента обладали одинаковым высоким
приоритетом и оба руководителя компонентов А и В не же-

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

пов управления программами проектов, представлены свод-
ные таблицы, включающие ценные рекомендации, коммента-
рии из практики и извлеченные уроки, изложенные в книге
по каждому процессу стандарта PMI The Standard for Program
Management®, Third Edition.
Опыт внедрения в организациях принципов

управления программами проектов
Рекомендации и особенности применения на практике.

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

 создайте прочную связь между формулировкой стратегии
и программой преобразований, направленных на ее реа-
лизацию, с одной стороны, и программами и проектами
компании, с другой:
– необходим тщательный анализ затрат и результатов;
– отслеживая выгоды, полученные благодаря програм-
мам, оценим степень приближения к воплощению
стратегии;
 сдерживайте свои амбиции исходя из реальности:
– в первую очередь надо реализовывать быстрые, легко-
достижимые выгоды (fast wins) и преимущества;
– необходимо заручиться поддержкой и доверием руково-
дителей среднего звена;
– реализовывать выгоды на ранних этапах программы и
затем создать цикл, в котором удача влечет за собой
другие, еще более значительные успехи;
 создавайте равновесие власти:
– программа пользуется достаточной поддержкой, если
работа над ее реализацией входит в число приоритет-
ных задач функциональных руководителей;
– руководители программ должны иметь достаточные
полномочия по сравнению с функциональными руко-
водителями;
– привлекайте к работе в программе лиц, пользующихся
авторитетом в компании;
 обеспечьте соответствие ожиданий и целей заинтересован-
ных лиц: все участники и их руководители должны офи-
циально подтвердить свою приверженность целям про-
граммы. Это особенно важно при участии в работе над
программой сотрудников разных компаний;
 определите структуру принятия решений:
– необходим ответ на вопрос — кто может и кто должен
участвовать в принятии ключевых решений;
– необходима ясная и контролируемая система отчетно-
сти;
222 Заключение
 создайте гибкую и динамичную структуру управления про-

граммой:
– на этапах планирования работ программы — за счет
коллективного принятия решений и совместной работы
по планированию;
– на этапах разработки и дизайна решений — за счет ра-
бочих потоков отчетности и механизмов контроля;
– при внедрении результатов и достижении выгод про-
граммы — за счет механизмов управления рисками и
разрешения проблем;
 обеспечьте минимальное соотношение «время — выгоды»:
– скорейшая реализация выгод;
– сокращение количества одновременно выполняемых
видов деятельности (особенно при превышении ресур-
сов, необходимых для выполнения программы над име-
ющимися ресурсами);
 своевременно устраняйте причины и предотвращайте воз-
никновение конфликтов:
– проведение массового обучения управлению конфлик-
тами;
– наличие четких процедур разрешения конфликтов;
 управляя программой, ориентируйтесь на ее результаты и
выгоды;
 эффективно осуществляйте мониторинг и контроль над
работами программы;
 будьте готовы проявить гибкость перед изменяющимися
обстоятельствами;
 прежде чем остановить или заморозить программу, попы-
тайтесь доказать получение выгод для компании в резуль-
тате ее выполнения;
 выделите необходимое время и ресурсы, чтобы изучить
опыт других и применить его в вашей программе.
Ценные рекомендации
Домен: руководство программой
Менеджер программы должен быть готов к проведению как внешнего,

так и внутреннего аудита программы. Для успешного прохождения ау-
дита менеджер программы должен неукоснительно следовать всем про-
цессам и процедурам компании по управлению программой.
Наряду с подготовкой к проведению плановых аудитов менеджер про-

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

цели и директивы компании, достижение которых должно быть поддер-
жано результатами программы и выгодами, получаемыми компанией от
ее реализации.
Область знаний: управление содержанием программы
Характеристики выгоды (benefit metrics) как окончательного результата

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

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

бований заказчика и ожиданий конечных пользователей (end-user
expectations) результатов программы. После утверждения программным
комитетом новых границ содержания программы менеджер программы
обязан придерживаться обновленных границ и не выполнять работы,
лежащие за их пределами.
Требования к программе часто меняются в ходе выполнения ее работ.

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

к характеристикам продуктов ее компонентов.
Допущения (особенно не в достаточной степени обоснованные) часто

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

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

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

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

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

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

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

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

тия расписаний компонентов, которые являются значимыми для дости-
жения результатов всей программы либо связывают результаты разных
Термин «высокоуровневое» расписание программы отражает возмож-

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

должны быть отражены в высокоуровневом расписании программы и
необязательно входят в расписания компонентов.
В программах, включающих работы внешних поставщиков и подрядчи-
ков, необходимо использовать единые для программного офиса и внеш-
них подрядчиков продукты календарного планирования.
В высокоуровневом расписании программы должны быть отражены
критически важные внешние зависимости сроков, ресурсов, работ и
Менеджер программы должен стремиться к соблюдению здравого ба-
ланса между проводимым им контролем расписания компонентов и
предоставлением руководителям компонентов определенной свободы в
принятии решений по управлению расписаниями компонентов.
Если отставание по срокам программы однозначно является негатив-
ным результатом, то опережение сроков программы не всегда является
позитивным результатом. Например, преждевременный набор специ-
алистов для работ в программе может привести к их простою.
Метод освоенного объема позволяет проводить интегрированный ана-
лиз как исполнения графика, так и бюджета программы по стоимост-
ным показателям.
Необходимость ускорения или замедления сроков исполнения компо-
нентов может быть продиктована меняющимися сроками получения
выгод программы. Например, досрочное завершение строительства
завода может привести к ускорению сроков его вывода на проектную
мощность выпуска продукции и дополнительным приобретенным вы-
годам от ускоренной реализации продукции на рынке.
Область знаний: управление финансами программы
Менеджер программы должен иметь в виду, что цели источника фи-
нансирования могут отличаться от целей финансирования программы.
Например, источник финансирования может быть заинтересован в от-
срочке платежа поставщику программы, а интересы программы могут
заключаться в проведении 100% предоплаты поставщику для осущест-
вления им приоритетных работ программы.
Факторы внешней среды могут являться источниками непредсказуемых
негативных воздействий на план финансирования программы. Напри-
мер, такими факторами могут быть негативные изменения в курсах ва-
лют или неожиданные увеличения стоимости материалов. Тогда менед-
жер программы оказывается вынужденным использовать финансовые
резервы программы или, в случае их недостаточности или отсутствия,
запрашивать дополнительное финансирование программы в программ-
ном комитете.
Результатом измерения и оценки достижения выгод программы с по-

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

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

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

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

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

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

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

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

интегрированы в план управления программой.
Любые резервы, выделенные на управление программой, могут быть

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

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

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

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

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

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

 не «ушла» ли программа в сторону от стратегических целей компании;
 соответствуют ли планы программы стратегическому плану развития
бизнеса компании?
Критически важным является наличие всех необходимых ресурсов, гото-

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

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

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

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

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

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

бой фазе жизненного цикла программы, кроме фазы ее завершения.
При анализе влияния изменения на план управления программой не-

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

жера программы (для незначительных изменений плана управления
программой), либо от программного комитета (для изменений, суще-
ственно влияющих на план управления программой) — в соответствии с
установленными нормами делегирования полномочий менеджера про-
граммы. Как правило, уровень делегирования полномочий менеджера
программы не превышает 10% отклонений в сроках и бюджете програм-
мы. Изменения в содержании работ программы, приводящие к более
значительным отклонениям в сроках и бюджете, подлежат обязательной
эскалации на рассмотрение программного комитета.
Причинами остановки/замораживания работ компонента могут быть
изменения в содержании и целях программы, а также дефицит финан-
совых средств, возникший в бюджете программы.
Несмотря на то что назначение менеджера программы является одним
из результатов процесса инициации, желательно осуществить его на-
значение как можно раньше в ходе процесса инициации программы. В
таком случае, опытный и квалифицированный менеджер программы
сможет принять непосредственное участие в детальной и качественной
разработке устава и обновлении бизнес-кейса программы.
Все опрашиваемые эксперты должны иметь доступ к одной и той же и
как можно более полной информации о программе. Если кто-то из экс-
пертов не ознакомлен с информацией о программе, известной другим
экспертам, его участие в опросе будет неполноценным. Полнота до-
ступной для экспертов информации о программе должна обеспечить
достоверность результатов экспертного опроса.
Границы содержания программы необходимо «закрепить», чтобы ис-
ключить завышенные, неоправданные ожидания стейкхолдеров в про-
ведении работ и получении результатов, которые не будут получены.
Определение границ содержания программы способствует достижению
удовлетворения заказчика программы ее результатами, описанными в
четких рамках границ содержания.
Известен эффект «расползания» границ содержания программы (scope
creep), возникающий при частых изменениях содержания программы,
не зафиксированных в планах программы и отчетах об изменениях. При
этом менеджер программы оказывается не в состоянии удержать содер-
жание программы в рамках ее четких границ… Неконтролируемые (и не-
управляемые) изменения содержания программы и ее границ являются
основным источником проблем и неудач в управлении программами.
По мере получения результатов и продуктов программы они должны быть

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

те серии совещаний с ключевыми стейкхолдерами программы (program
kick-off meetings), в ходе которых происходит активный обмен эксперт-
ными мнениями. Основная задача таких совещаний — договориться с
ключевыми стейкхолдерами об общем понимании сути программы и ее
содержания, «снять» потенциальные конфликты, которые могут проя-
виться в будущих этапах планирования и выполнения программы. ИСР
является ключевым инструментом для организации коммуникацион-
ных взаимодействий менеджера программы и руководителей компонен-
тов программы.
При формировании в ходе декомпозиции перечня элементов на каждом

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

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

направлен на заседание программного комитета в случае завершения
работ и получения требуемых результатов компонента либо в случае
необходимости остановки работ компонента из-за невозможности/
отсутствия необходимости их продолжения. При этом в запросе долж-
на быть аргументирована необходимость отказа от компонента и ее
полной остановки либо временного «замораживания» работ компо-
нента на определенный срок.
Внимание менеджера программы должно быть уделено не только со-

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

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

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

нения бюджета (CPI) и графика (SPI) следует проводить по завершении
этапа или достижении контрольной точки программы.
Расчет прогнозных показателей стоимости оставшихся невыполненны-

ми работ программы (estimate to completion — ETC) и стоимости всей
программы по ее завершении (estimate at completion — EAC) следует
также проводить по завершении этапа или достижении контрольной
точки программы. Именно по завершении работ этапа или по достиже-
нии контрольной точки спонсор программы может попросить менедже-
ра программы дать прогноз.
Регулярные вычисления показателя TCPI в течение определенного пе-

риода позволяют судить об эффективности работ программы:
 возрастание показателя свидетельствует о растущем дефиците остав-
шихся средств бюджета для выполнения оставшихся работ программы;
 снижение показателя свидетельствует о растущей экономии средств
бюджета для выполнения оставшихся работ программы.
Бюджеты крупных программ должны обеспечить достаточное и ста-
бильное финансирование длительных, как правило, многолетних работ
до получения первых результатов и выгод программ. Поэтому инвесто-
ры и заказчики крупной программы уделяют пристальное внимание ра-
ботам менеджера программы по управлению затратами программы на
протяжении всего жизненного цикла программы.
При разработке плана финансирования программы необходимо ис-
пользовать данные о финансовых резервах рисков программы, потен-
циальные проблемы недостатка наличных средств (potential cash flow
problems), динамику обменных курсов валют, изменения цен на матери-
алы, финансовые штрафы и вознаграждения в контрактах с поставщи-
ками, допустимые периоды отсрочки платежей поставщикам и др.
Анализ затрат на организацию и проведение поставок программы дол-
жен включать не только стоимость контракта с поставщиком, но и за-
траты офиса управления программой на администрирование процессов
поставки.
Важным условием является требование по использованию единых ком-
пьютерных инструментов оценок стоимостей во всех компонентах и
поставках программы, исключающее разнообразие и несовместимость
форм, отчетов, единиц измерения и т. п.
При анализе затрат программы необходимо провести детальный ана-
лиз структуры затрат всех компонентов программы, включающий такие
статьи расходов компонентов, как:
 объемы, сроки и ограничения финансирования;
 объемы и графики платежей по контрактам с поставщиками;
 расходы на управление программой.
В ходе жизненного цикла программы исходные предположения могут
измениться и стать источниками рисков программы. Кроме того, ри-
ски программы могут возникнуть из допущений, являющихся необо-
снованными, нестабильными или неполными. Например, допущение о
наличии ресурсов для выполнения работ программы в установленные
сроки может оказаться несостоятельным, если существует вероятность
использования тех же ресурсов в другой, более приоритетной програм-
ме компании в те же сроки.
Кроме оценок вероятности и степени влияния рисков полезно опреде-

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

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

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

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

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

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

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

обходимости изменения содержания программы или приоритетов ее
Существенная экономия денежных резервов программы по ее завер-

шении является результатом плохого планирования и некачественной
оценки и анализа рисков программы. Владельцы бизнеса и высшее
руководство компании могут обвинить менеджера программы в замо-
раживании денежных средств в виде резервов на управление риска-
ми программы, которые оказались невостребованными. Эти средства
могли бы быть использованы в других программах и принести выгоды
в бизнесе компании. Напротив, разумная доля экономии резервов мо-
жет быть результатом профессионального управления рисками про-
граммы и источником вознаграждения менеджера программы и ко-
манды управления программой.
Отличия потенциальной проблемы (issue) от риска не всегда являются
очевидными для членов команд управления программами. Главные от-
личия заключаются в том, что риски могут быть как позитивными, так и
негативными, в то время как потенциальная проблема несет в себе толь-
ко негатив. Кроме того, любой риск имеет два основных параметра —
вероятность возникновения и влияние, в то время как потенциальная
проблема оценивается по параметру влияния и не всегда может иметь
оценку вероятности возникновения.
Менеджер программы и члены команды управления программой обяза-
ны проводить мониторинг и контроль над рисками контрактов в части
заданий по работам поставщика (scope of works). К анализу рисков в ча-
сти юридических условий и положений (terms & conditions) контрактов
необходимо привлекать представителей юридической службы органи-
зации и менеджеров по контрактам (contract managers).
Риск-менеджер является, как правило, экс-руководителем программы,
обладающим огромным опытом и «чутьем» в управлении рисками. Он
должен обладать полномочиями, позволяющими ему получать любые
документы и сведения о ходе выполнения программы, и быть независи-
мым в своих суждениях и рекомендациях. Часто его рекомендации по-
зволяют менеджеру программы изменить оценки рисков и выбранные
стратегии реагирования на более эффективные и обнаружить новые
значительные риски, не известные команде управления программой.
Использование менеджером программы эффективных навыков комму-
никаций должно обеспечить получение и верное понимание определен-
ными стейкхолдерами определенной информации в определенное время.
Регулярные отчеты об исполнении должны включать различные воз-
можные формы представления данных: круговые и столбчатые диаграм-
мы, накопительные кривые стоимостей ресурсов программы (S-curves),
гистограммы и таблицы, данные освоенного объема (earned value data).
Результатами регулярной подготовки, анализа и предоставления от-

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

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

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

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

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

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

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

«вопрос — ответ» между представителями заказчика поставки (напри-
мер, членами тендерного комитета) и потенциальными поставщиками.
Члены тендерного комитета отвечают на вопросы поставщиков отно-
сительно условий и требований по организации проведения поставки.
Полезными сведениями для определения аттестованных поставщиков

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

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

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

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

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

программы является источником пополнения резерва бюджета про-
граммы.

Данные информационной системы управления программой позволяют
менеджеру программы на ранних стадиях определять и оценивать из-
менения, риски и потенциальные проблемы ресурсного обеспечения
программы. При этом важна проактивная позиция менеджера програм-
мы по разрешению потенциальных конфликтов, возникающих между
руководителями компонентов программы в их борьбе за использование
лучших и дефицитных ресурсов.
Менеджер программы управляет ресурсами на уровне программы и вза-
имодействует с руководителями компонентов, управляющими ресур-
сами компонентов для обеспечения баланса в распределении ресурсов
программы между компонентами.
При разработке дополнительных аргументов, сближающих позиции кон-
фликтующих руководителей компонентов, менеджер программы может
использовать не известную им информацию стратегического характера.
Например, менеджер программы может использовать в этих целях ре-
зультаты обсуждений программы на заседаниях программного комитета,
распоряжения спонсора программы и высшего руководства компании,
неизвестные руководителям компонентов. Такие аргументы, убедительно
представленные менеджером программы позволяют сблизить позиции
конфликтующих сторон за счет расширения и углубления совпадений в
их позициях и ослабления противоположных позиций, являющихся ис-
точником конфликта.
Компромисс является на практике наиболее частым выходом из кон-
фликтной ситуации, но не самым эффективным. В случае компромисса
конфликтующие стороны находят удовлетворение, так как в решении
конфликта используется определенная удовлетворяющая их часть пози-
ции, и они готовы уступить другую определенную часть своей позиции
в конфликте.
Метод разрешения конфликта, основанный на постепенном, демокра-
тическом проявлении стремления менеджером программы объединить
множество точек зрения и мнений с различных сторон, требует времени
и длительных обсуждений позиций конфликтующих сторон. Приме-
нение такого метода возможно, если менеджер программы располагает
таким временем, так как разрешение конфликта не является срочным и
его можно отложить. Срочность разрешения конфликта может потребо-
вать использования другого метода, например принуждения.
Метод «решение проблемы» (problem solving), редко достижимый на
практике, является наиболее эффективным способом разрешения кон-
фликта, так как менеджеру программы удается найти сочетание самых
сильных предложений конфликтующих сторон в интересах каждой из
них и успеха программы в целом.
Извлеченные уроки
 Менеджер программы должен быть вовлечен в процесс инициации

программы как можно раньше.
 Утверждение устава и обновленного бизнес-кейса спонсором и за-
казчиком программы необходимо провести в результате презента-
ции менеджером программы, посвященной детальному изложению
данных документов ключевым стейкхолдерам программы (включая
руководство компании и/или владельцев компании) и обмена экс-
пертными оценками.
 Характеристики выгоды (benefit metrics) как окончательного ре-

зультата программы должны быть описаны в определенных метри-
ках (например, в денежных единицах дохода, прибыли компании
или временных характеристиках периода возврата инвестиций, мо-
мента окупаемости и т. п.).
 Все опрашиваемые эксперты должны иметь доступ к одной и той же
и как можно более полной информации о программе. Если кто-то
из экспертов не ознакомлен с информацией о программе, извест-
ной другим экспертам, его участие в опросе будет неполноценным.
Полнота доступной для экспертов информации о программе должна
обеспечить достоверность результатов экспертного опроса.
 Допущения (особенно не в достаточной степени обоснованные) ча-
сто являются источниками рисков программы.
 Описание содержания программы может быть подготовлено в ре-
зультате серии совещаний с ключевыми стейкхолдерами программы
(program kick-off meetings), в ходе которых происходит активный
обмен экспертными мнениями. Основная задача таких совеща-
ний — договориться с ключевыми стейкхолдерами об общем по-
нимании сути программы и ее содержания, «снять» потенциальные
конфликты, которые могут проявиться в будущих этапах планиро-
вания и выполнения программы.
 Границы содержания программы (program boundaries) должны опи-
сывать те работы программы, которые не следует ожидать, потому
что они не будут выполнены по причинам отсутствия необходимых
ресурсов, высоких рисков или нежелания ключевых стейкхолдеров
их выполнять.
 Границы содержания программы необходимо «закрепить», чтобы
исключить завышенные, неоправданные ожидания стейкхолдеров в
проведении работ и получении результатов, которые не будут полу-
чены.
 Определение границ содержания программы способствует достиже-

нию удовлетворения заказчика программы ее результатами, описан-
ными в четких рамках границ содержания.
 Границы содержания программы могут меняться при изменении тре-
бований заказчика и ожиданий конечных пользователей (end-user
expectations) результатов программы. После утверждения программ-
ным комитетом новых границ содержания программы менеджер про-
граммы обязан придерживаться обновленных границ и не выполнять
работы, лежащие за их пределами.
 Неконтролируемые (и неуправляемые) изменения содержания про-
граммы и ее границ являются основным источником проблем и не-
удач в управлении программами.
 Требования к программе часто меняются в ходе выполнения ее работ.
Изменения в требованиях программы должны быть проанализирова-
ны с точки зрения их выполнимости и влияния на успех программы.
 По мере получения результатов и продуктов программы изменения в
требованиях должны быть проанализированы и проверены на пред-
мет их соответствия заявленным требованиям. Официальное под-
тверждение соответствия продуктов программы заявленным требо-
ваниям может включать тесты и инспекции продуктов.
 Требования к программе не должны описывать технические требо-
вания к характеристикам продуктов ее компонентов. Требования
к компонентам программы являются результатом декомпозиции
высокоуровневых требований программы до уровня детальных тре-
бований по созданию продуктов ее компонентов.
 ИСР программы является основным документом, используемым ме-
неджером программы для планирования, организации и управления
работами программы.
 Работы по управлению программой должны быть описаны в каче-
стве элементов одной из ветвей ИСР, в том числе работы менед-
жера программы, офиса управления программой и программного
комитета.
 ИСР является ключевым инструментом для организации комму-
никационных взаимодействий между менеджером программы и
руководителями компонентов программы.
 При формировании в ходе декомпозиции перечня элементов на
каждом из уровней ИСР полезно применять метод базиса, который
должен обеспечить:
– конечное число элементов на каждом из уровней ИСР;
– уникальность (отсутствие дублей) среди элементов ИСР на каж-
дом из уровней;
– обязательное выполнение элемента вышестоящего уровня при
полном выполнении всех элементов, входящих в него на более
низком уровне ИСР.
 Уникальные результаты пакетов работ проектов, входящих в про-

грамму, а также систематические результаты блоков операционной
деятельности программы консолидируются в общие результаты про-
граммы, обеспечивающие достижение бизнес-выгод компании.
 Разделение управления между менеджером программы и руководи-
телями компонентов на уровне пакетов программы ИСР обеспечи-
вает их совместную ответственность — как «сверху», так и «снизу»
за уровень компонентов программы: ответственность («снизу»)
руководителей компонентов за построение их ИСР и достижение
результатов компонентов и ответственность («сверху») менеджера
программы за руководство руководителями компонентов.
 Менеджер программы несет ответственность за консолидацию
результатов компонентов в общие результаты программы, поддер-
живающие достижение бизнес-выгод компании.
 Для построения ИСР на основе проведения эффективной деком-
позиции и обмена экспертными оценками необходимо наличие в
команде программы экспертов в предметной области программы,
обладающих опытом в проведении подобных программ.
 Разработка матрицы ответственности позволяет менеджеру програм-
мы эффективно распределить ответственность за достижение резуль-
татов программы между различными членами команды программы.
Строки матрицы ответственности показывают распределение ин-
дивидуального вклада различных ролей команды в достижение кон-
кретного результата, а столбцы — ответственность конкретной роли
в достижении определенных результатов программы.
 Процесс управления изменениями содержания программы основан
на иерархической процедуре эскалации изменений и взаимодей-
ствии комитетов по управлению изменениями программы и ее ком-
понентов.
 Запрос на формальное закрытие компонента программы должен
быть направлен на заседание программного комитета в случае завер-
шения работ и получения требуемых результатов компонента либо в
случае необходимости остановки работ компонента из-за невозмож-
ности/отсутствия необходимости их продолжения.
 Взаимозависимости компонентов оказывают значительное влияние

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

соблюдению сроков выполнения проектов, входящих в программу,
но и соблюдению сроков получения результатов операционной дея-
тельности, входящих в программу. Задержки в получении плановых
результатов операционной деятельности могут привести к срыву сро-
ков всей программы.
 Задержки в сроках любых компонентов программы (как проектов,
так и операционной деятельности) приводят к упущенным выгодам
в бизнесе компании.
 Расписание программы должно включать только те контрольные со-
бытия расписаний компонентов, которые являются значимыми для
достижения результатов всей программы либо связывают результаты
разных компонентов программы.
 Термин «высокоуровневое» расписание программы отражает воз-
можность централизованной разработки расписания программы
только на высоком уровне и детальной разработки расписаний толь-
ко на уровне компонентов программы.
 Взаимозависимости получения результатов различных компонентов
должны быть отражены в высокоуровневом расписании программы
и необязательно входят в расписания компонентов.
 В программах, включающих работы внешних поставщиков и подряд-
чиков, необходимо использовать единые для программного офиса и
внешних подрядчиков продукты календарного планирования.
 В высокоуровневом расписании программы должны быть отражены
критически важные внешние зависимости сроков, ресурсов, работ и
 Недостаточное внимание менеджера программы, уделяемое анализу
взаимозависимостей контрольных событий компонентов, приводит
к срыву сроков результатов программы и упущенным выгодам ком-
пании. Причина этого факта заключается в необходимости своев-
ременной консолидации результатов компонентов в соответствии с
датами расписания программы, без проведения которой невозможно
достижение выгод компании.
 Менеджер программы должен стремиться к соблюдению здравого ба-
ланса между проводимым им контролем расписания компонентов и
предоставлением руководителям компонентов определенной свобо-
ды в принятии решений по управлению расписаниями компонентов.
 Для своевременного обнаружения возможных срывов сроков кон-
трольных событий полезно использовать технику ранних контроль-
ных событий (early milestones), сигнализирующих о приближении
сроков завершения или старта критически важных работ компо-
нентов.
 Если отставание по срокам программы однозначно является негатив-
ным результатом, то опережение сроков программы не всегда являет-
ся позитивным результатом.
 Метод освоенного объема позволяет проводить интегрированный

анализ как исполнения графика, так и бюджета программы по стои-
мостным показателям.
 Расчет отклонений по стоимости (CV), срокам (SV) и индексов вы-
полнения бюджета (CPI) и графика (SPI) следует проводить по за-
вершении этапа или достижении контрольной точки программы.
 Расчет прогнозных показателей стоимости оставшихся невыполнен-
ными работ программы (estimate to completion — ETC) и стоимости
всей программы по ее завершении (estimate at completion — EAC)
следует также проводить по завершении этапа или достижении кон-
трольной точки программы. Именно по завершении работ этапа или
по достижении контрольной точки спонсор программы может по-
просить менеджера программы дать прогноз.
 Регулярные вычисления показателя TCPI в течение определенного
периода позволяют судить об эффективности работ программы.
 Необходимость ускорения или замедления сроков исполнения ком-
понентов может быть продиктована меняющимися сроками получе-
ния выгод программы.
 При проведении оценки стоимости программы необходимо учиты-

вать не только стоимость работ по управлению программой и стои-
мость компонентов программы, но и стоимость работ по поддержке
 Полная стоимость владения продуктом программы сравнивается с
оценкой финансовых выгод программы при принятии решений об
инициации или продолжении программы.
 Источники финансирования программы могут быть различными
и зависят от типа, масштаба и сложности программы. Источники
финансирования могут отличаться принципиально для междуна-
родных и национальных программ, а также для тех, которые фи-
нансируются самой организацией — заказчиком программы и для
тех, которые требуют финансирования внешних по отношению к
заказчику компаний.
 Менеджер программы должен иметь в виду, что цели источника фи-
нансирования могут отличаться от целей финансирования програм-
мы. Например, источник финансирования может быть заинтересован
в отсрочке платежа поставщику программы, а интересы программы
могут заключаться в проведении 100% предоплаты поставщику для
проведения им приоритетных работ программы.
 Методы финансирования рассматриваются менеджером программы

для выбора наиболее эффективных методов и схем финансирования
программы, среди которых могут быть:
– финансирование программы организацией-заказчиком;
– финансирование программы государственной структурой;
– финансирование программы банком, венчурным фондом или
другим финансовым институтом.
 При разработке плана финансирования программы необходимо
использовать данные о финансовых резервах рисков программы,
потенциальные проблемы недостатка наличных средств (potential
cash flow problems), динамику обменных курсов валют, изменения
цен на материалы, финансовые штрафы и вознаграждения в кон-
трактах с поставщиками, допустимые периоды отсрочки платежей
поставщикам и др.
 Факторы внешней среды могут являться источниками непредсказу-
емых негативных воздействий на план финансирования программы.
Например, такими факторами могут быть негативные изменения в
курсах валют или неожиданные увеличения стоимости материалов.
 Ограничения финансирования являются существенным фактором,
влияющим на процесс разработки плана финансирования програм-
мы. Так как большинство крупных программ имеет значительную
длительность и большой бюджет, получение 100% финансирования
в начале выполнения программы является редкостью и, скорее, «ис-
ключением из правила». На практике такие программы получают
либо регулярный годовой бюджет (особенно в случае государствен-
ных программ), либо поэтапное финансирование работ программы,
связанное с достижением контрольных событий (program milestones).
Поэтому график платежей финансового плана программы должен
учитывать сроки годового или поэтапного финансирования про-
граммы.
 Результатом измерения и оценки достижения выгод программы с
помощью применения финансовых метрик может быть решение об
остановке, замораживании или изменении целей и содержания про-
граммы.
 Наиболее точная оценка расходов возможна в относительно кратко-
срочных программах, в которых основным ресурсом являются люди.
Наименее точная оценка расходов может быть получена в долгосроч-
ных программах, в которых основными ресурсами являются матери-
алы и оборудование.
 В сложных комплексных программах оценка расходов не может быть
выполнена без привлечения большого число контрагентов и субпо-
дрядчиков, выполняющих своими силами значительный объем работ
программы. Только ответственные исполнители данных работ могут
оценить их стоимость. Поэтому оценка расходов таких программ воз-
можна только после отбора и привлечения поставщиков.
 В оценке расходов высоко рискованных программ должны быть учте-

ны значительные финансовые резервы на управление рисками внеш-
ней среды, технологическими и организационными.
 Анализ затрат на организацию и проведение поставок программы
должен включать не только стоимость контракта с поставщиком, но и
затраты офиса управления программой на администрирование про-
цессов поставки.
 Важным условием является требование по использованию единых
компьютерных инструментов оценок стоимостей во всех компонен-
тах и поставках программы, исключающее разнообразие и несовме-
стимость форм, отчетов, единиц измерения и т. п.
 При анализе затрат программы необходимо провести детальный ана-
лиз структуры затрат всех компонентов программы, включающий та-
кие статьи расходов компонентов, как:
– объемы, сроки и ограничения финансирования;
– объемы и графики платежей по контрактам с поставщиками;
– расходы на управление программой.
 Базовый бюджет программы (program budget baseline) отражает по-
ток денежных средств во времени жизненного цикла программы, по-
ступающих в ее бюджет из определенных источников и используемых
для финансирования работ программы.
 С момента утверждения заказчиком базового бюджета программы
он становится главным финансовым документом программы. Успех
программы с точки зрения финансовых показателей определяется
исходя из результатов освоения и расходов базового бюджета про-
граммы.
 Система управления затратами включает набор процессов и проце-
дур, позволяющих управлять изменениями, возникающими в рас-
ходах программы и ее компонентов по отношению к утвержденному
базовому бюджету программы.
 Методы прогнозирования затрат включают регулярный расчет пока-
зателей прогнозных оценок стоимости оставшихся невыполненными
работ программы (estimate to completion) и стоимости всей програм-
мы по ее завершении (estimate at completion) для сравнения с теку-
щим базовым бюджетом программы и общим бюджетом программы
по ее завершении (budget at completion).
 Оставшиеся при закрытии бюджета программы средства возвраща-
ются источнику финансирования программы.
 В процессе закрытия финансирования программы необходимо
учесть затраты на работы по поддержке достигнутых выгод (benefit
sustainment) в компании заказчика программы.
Область знаний: управление качеством программы

 Менеджер программы должен стремиться к оптимизации затрат на
управление качеством всей программы путем исключения дублирую-
щих процессов обеспечения и контроля качества в компонентах про-
граммы.
 Единые принципы планирования и управления качеством програм-
мы должны распространяться на работы внешних поставщиков и
подрядчиков программы.
 Процесс обеспечения качества программы включает обновления
плана по качеству при появлении новых законодательных актов и
стандартов качества, релевантных содержанию программы.
 Аудит качества программы отслеживает не только качество работ на
уровне программы в целом, но и взаимные влияния компонентов
программы на качество работ и результатов работ компонентов.
 Результаты программы включают продукты компонентов и про-
граммы в целом, обеспечивающие достижение выгод программы, а
также результаты в управлении программой и реализации планов
программы.
 Результаты обзоров удовлетворения заказчиков (customer satisfaction
surveys) и конечных пользователей продуктов программы (end-users
satisfaction surveys) могут привести к изменениям в политике каче-
ства и стандартов качества программы.
 В плане управления рисками программы не должны быть представ-
лены риски программы, которые являются результатом следующего
за разработкой данного плана процесса идентификации рисков.
 План управления рисками программы является, прежде всего, до-
кументом методологического характера, в котором должны быть из-
ложены подходы управления рисками с учетом целей и содержания
конкретной программы.
 Совещания по планированию и анализу управления рисками про-
граммы — должны быть организованы менеджером программы с
участием ключевых стейкхолдеров для определения подходов и про-
цедур по управлению рисками программы. Основные темы таких со-
вещаний:
– выбор подходов и методологии управления рисками программы с
учетом специфики ее содержания;
– определение принципов ответственности за управление рисками
(risk ownership);
– определение категорий и типов рисков программы и ее компонен-
тов;
– обсуждение и определение форматов шаблонов анализа рисков и
форм отчетов по управлению рисками.
 При идентификации рисков важно описать, как и почему риски мо-

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

оценить взаимные влияния и зависимости рисков программы, кото-
рые могут быть:
– между различными рисками программы;
– между рисками программы и ее компонентов;
– между рисками компонентов программы;
– между рисками программы и рисками компании.
 Синергетический эффект от совместного влияния рисков компонен-
тов на риски программы может быть как негативным, так и позитив-
ным.
 Уклонение от риска должно перевести риск в событие с нулевой ве-
роятностью, которое не может произойти. Например, отчет менедже-
ра программы спонсору программы об уклонении от риска является
гарантией, что риск не произойдет ни при каких обстоятельствах.
 Передача управления риском третьей стороне должна быть зафикси-
рована в формальном документе. Например, передача риска срыва
сроков поставки на плечи поставщика может быть зафиксирована в
контракте с поставщиком путем определения штрафных санкций за
 Снижение риска требует выделения дополнительных ресурсов про-
граммы — бюджетных, временных, технологических, человеческих
или организационных.
 Принятие риска может быть связано с незначительными уровнями
вероятности и влияния риска либо с невозможностью команды про-
граммы реагировать на риск, например из-за отсутствия необходи-
мых для реагирования ресурсов.
 Принятие позитивного риска командой программы подразумевает
отсутствие каких-либо возможностей повышения положительного
эффекта от риска или невозможность повысить уровень эффекта
имеющимися в распоряжении команды ресурсами и средствами.
 Работы по реализации стратегий реагирования на риски должны
быть интегрированы в план управления программой.
 Действия по реализации стратегий реагирования могут привести к
необходимости изменения содержания программы или приоритетов
ее компонентов.
 Любые резервы, выделенные на управление программой, могут быть
выражены в доле бюджета программы (т. е. в денежном выражении).
Недостаток денежных резервов требует их пополнения за счет выде-
ления дополнительных средств бюджета. Избыток денежных резер-
вов ведет к неэффективному управлению финансовыми средствами
компании.
 Существенная экономия денежных резервов программы по ее завер-

шении является результатом плохого планирования и некачествен-
ной оценки и анализа рисков программы. Владельцы бизнеса и выс-
шее руководство компании могут обвинить менеджера программы
в замораживании денежных средств в виде резервов на управление
рисками программы, которые оказались невостребованными.
 Отличия потенциальной проблемы (issue) от риска не всегда являют-
ся очевидными для членов команд управления программами. Глав-
ные различия заключаются в том, что риски могут быть как позитив-
ными, так и негативными, в то время как потенциальная проблема
несет в себе только негатив. Кроме того, любой риск имеет два основ-
ных параметра — вероятность возникновения и влияние, в то время
как потенциальная проблема оценивается по параметру влияния и не
всегда может иметь оценку вероятности возникновения.
 Менеджер программы и члены команды управления программой
обязаны проводить мониторинг и контроль над рисками контрактов в
части заданий по работам поставщика (scope of works). К анализу ри-
сков в части юридических условий и положений (terms & conditions)
контрактов необходимо привлекать представителей юридической
службы компании и менеджеров по контрактам (contract managers).
 Риск-менеджер является, как правило, экс-руководителем про-
граммы, обладающим огромным опытом и «чутьем» в управлении
рисками. Он должен иметь полномочия, позволяющие ему полу-
чать любые документы и сведения о ходе выполнения программы,
и быть независимым в своих суждениях и рекомендациях. Часто его
рекомендации позволяют менеджеру программы изменить оценки
рисков и выбранные стратегии реагирования на более эффектив-
ные и обнаружить новые значительные риски, неизвестные коман-
де управления программой.
 Всевозможные коммуникации со стейкхолдерами программы (фор-

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

информацией, которая представляет ценность для достижения успе-
ха программы, или той информацией, отсутствие которой может
привести к негативному результату программы.
 При появлении большого количества запросов стейкхолдеров на
получение внеплановой информации о программе менеджеру про-
граммы необходимо внести изменения в план управления коммуни-
кациями для удовлетворения информационных потребностей стейк-
холдеров, не получивших отражения в данном плане.
 Использование менеджером программы эффективных навыков ком-
муникаций должно обеспечить получение и верное понимание опре-
деленными стейкхолдерами определенной информации в определен-
ное время.
 Обязанностью менеджера программы является организация прове-
дения сессии по анализу извлеченных уроков в случае фактов воз-
никновения серьезных ошибок в управлении программой.
 Степень детализации отчетов об исполнении программы должна
быть определена требованиями стейкхолдеров программы, отражен-
ными в плане управления коммуникациями.
 Отчеты об исполнении должны включать различные возможные фор-
мы представления данных: круговые и столбчатые диаграммы, нако-
пительные кривые стоимостей ресурсов программы (S-curves), гисто-
граммы и таблицы, данные освоенного объема (earned value data).
 Результатами регулярной подготовки, анализа и предоставления от-
чета о реализации выгод программы могут быть решения комитета по
управлению программой об ускорении, приостановке, прекращении
работ отдельного компонента либо об инициации нового компонен-
та программы.
 Несовпадение значений метрик из плана и отчета о реализации выгод
может послужить причиной изменения содержания отдельных ком-
понентов программы или программы в целом.
Область знаний: управление закупками программы
 Для проведения сравнительного анализа поставщиков программы
желательно привлекать специалистов подразделений компании, не-
посредственно занимающихся организацией поставок в своей по-
вседневной деятельности. Эти специалисты хорошо знают рынок и
деятельность конкретных внешних организаций, способных осуще-
ствить необходимую для программы поставку.
 Максимальный риск возникает при необходимости привлечения
внешнего поставщика для выполнения работ программы, в которых
у команды управления программой нет собственных компетенций.
В этом случае заказчик (менеджер программы или команда управле-
ния программой) оказывается не в состоянии оценить содержание и
качество поставки.
 Контракты с фиксированной ценой и с оплатой стоимости затра-

ченного времени и материалов активно используются на отечествен-
ном рынке, в то время как контракт с возмещением затрат является
редкостью. Тем не менее, такой контракт становится необходимым в
условиях развитого рынка и высокой конкуренции, так как его при-
менение позволяет заказчику «удержать» поставщика при возникно-
вении риска его ухода к конкуренту. Это обеспечивается гарантией
заказчика полностью компенсировать затраты поставщика и даже,
при определенных условиях, выплатить поставщику дополнительное
вознаграждение, составляющее его чистую прибыль, так как затра-
ты уже компенсированы. Размер чистой прибыли может быть выше
прибыли поставщика, заложенной в фиксированной цене его пред-
ложения конкуренту.
 Определение общих поставок программы позволяет существенно
снизить затраты и сэкономить бюджет программы. Невыявление об-
щих поставок программы может привести к закупкам однотипных
товаров по разным ценам для разных компонентов программы и по-
явлению дополнительных издержек.
 Политики и процедуры, принятые в компании по управлению по-
ставками, могут ограничивать возможные управленческие решения
менеджера программы в этой области, в частности:
– требовать заключения контракта определенного типа при цене по-
ставки, превышающей определенный лимит;
– ограничивать количество участников тендера;
– допускать к участию в тендере поставщиков, подтверждающих
свой опыт свыше определенного количества лет.
 Как правило, конференции контрагентов проводятся в виде сес-
сий «вопрос — ответ» между представителями заказчика поставки
(например, членами тендерного комитета) и потенциальными по-
ставщиками. Члены тендерного комитета отвечают на вопросы по-
ставщиков относительно условий и требований по организации про-
ведения поставки.
 Важно, чтобы все потенциальные поставщики были приглашены и
приняли участие в конференции контрагентов. Отсутствующий на
данной конференции потенциальный поставщик оказывается ли-
шенным всей дополнительной информации по условиям поставки и
находится не в равных условиях конкурса с другими потенциальны-
ми поставщиками.
 В крупных международных программах поставщик может осущест-
влять работы по поставке программы из зарубежного государства.
В таком случае в контракте с поставщиком должно быть сказано, по
законодательству какой страны будут разрешаться споры между за-
казчиком и поставщиком, включая рассмотрение апелляций и пре-
тензий в судебных инстанциях и в арбитраже.
 Система контроля платежей призвана своевременно разрешать во-

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

программы заносятся в журнал управления изменениями программы
(program change management log). Ведение данного журнала является
обязанностью офиса управления программой.
 Компромисс является на практике наиболее частым выходом из кон-
фликтной ситуации, но не самым эффективным. Компромисс воз-
можен только в случае нахождения гибкого разрешения конфликта,
сочетающего мнения конфликтующих сторон. При необходимости
поиска строгого однозначного решения компромисс невозможен, и
выходом из конфликтной ситуации может быть только победа одной
из сторон и принуждение противоположной стороны согласиться с
победившей стороной.
 «Сотрудничество», основанное на постепенном, демократическом
проявлении стремления менеджера программы объединить множе-
ство точек зрения и мнений с различных сторон, требует времени и
длительных обсуждений позиций конфликтующих сторон. Примене-
ние такого метода возможно, если менеджер программы располагает
таким временем, так как разрешение конфликта не является сроч-
ным и его можно отложить. Срочность разрешения конфликта может
потребовать использования другого метода, например принуждения.
 «Решение проблемы», редко достижимое на практике, является наи-
более эффективным способом разрешения конфликта, так как ме-
неджеру программы удается найти сочетание самых сильных предло-
жений конфликтующих сторон в интересах каждой из них и успеха
Глоссарий
Accept change — решение принять изменение к реализации.

Actual cost (AC) — фактическая стоимость выполненных работ
программы (факт).
Affinity diagrams — диаграммы определения источников рис-
ков.
Architecture/cost tradeoff analysis — анализ соотношения ар-
хитектуры программы/стоимость программы с точки зрения
выгод и потерь.
Avoiding — уклонение от конфликта.
Budget at сompletion (BAC) — бюджет по завершении про-
граммы.
Benefits — выгоды.
Benefit analysis — анализ выгод.
Benefit deliverables — достижение выгод программы.
Benefit metrics — характеристики выгоды.
Benefits packages — пакеты выгод программы.
Benefits realization plan — план реализации выгод.
Benefit sustainment — поддержка получения выгод программы.
Benefit value — ценность выгоды программы.
Bidder conferences — конференции контрагентов.
Brainstorm — мозговой штурм.
Business case analysis — анализ бизнес-кейса.
Cash flow analysis — анализ денежных потоков программы.
Cause-end-effect diagrams (Ishikawa diagrams, fishbone dia-
grams) — диаграммы причинно-следственных связей.
Cost baseline — базовый стоимостной план компонентов.
Collaborating — сотрудничество.
Communication skills — навыки коммуникаций.
Глоссарий 255
Component dependencies — взаимные зависимости компонен-

тов.
Component interdependencies — зависимости между компо-
нентами программы.
Component milestones — вехи компонентов.
Component transition request — запрос на передачу компонен-
тов.
Computer cost estimating tools — компьютерные инструменты
оценки стоимости.
Conformance cost — затраты на обеспечение соответствия про-
граммы требованиям по качеству.
Contingency plan — план использования резервов.
Contingency reserve — резерв бюджета программы на управле-
ние рисками.
Contract manager — менеджер контракта.
Corrective actions — корректирующие действия.
Cost/benefit analysis — анализ выгод и затрат программы.
Cost reimbursable contract — контракт с возмещением стои-
мости.
Cost performance index (CPI) — индекс выполнения бюджета.
Customer retention — удержание заказчика.
Cost variance (CV) — отклонение по стоимости.
Definitive estimate — окончательная оценка стоимости про-
граммы.
Deliver of program benefits — получение выгод программы.
Delphi technique — метод Дельфи.
Estimate at сompletion (EAC) — прогнозная стоимость всей
программы по ее завершении.
Early milestones — ранние контрольные события.
Earned value (EV) — плановая стоимость выполненных работ
программы (освоенный план).
Earned value Datа — данные освоенного объема.
End-user expectations — ожидания конечных пользователей.
Earnings per share (EPS) — выручка в расчете на акцию.
Estimate to сompletion (ETC) — прогнозная стоимость остав-
шихся невыполненными работ программы.
Executive ownership — директор программ организации.
Executive sponsor — председатель программного комитета.
256 Глоссарий
Expected monetary value — ожидаемый денежный выигрыш.

Fixed price contract — контракт с фиксированной ценой.
Focus groups — фокусные группы стейкхолдеров программы.
Forcing — принуждение.
Gap analysis — анализ отклонений.
Gate review decision request — запрос на решение по заверше-
нии фазы программы.
«Go» decision — решение об инициации компонента програм-
мы.
«Go/no-go» decision — решение об инициации либо об отказе
в инициации компонента программы.
Governance plan — план по руководству программой.
High level road map — исходный план, описывающий ключе-
вые ориентиры программы.
In scope works — работы, описанные в качестве элементов ИСР
и находящиеся в пределах границ содержания программы.
Influence diagrams — диаграммы влияния.
Information distribution methods — методы распространения
информации.
Interviewing — интервьюирование экспертов.
Issue acceptance — принятие потенциальной проблемы.
Issue analysis — анализ потенциальных проблем.
Issue log (program issue register) — журнал (реестр) потенци-
альных проблем.
Issue owner — владелец потенциальной проблемы.
Knowledge transition — передача знаний.
Last phase gate reviews — обзоры по завершении последних
фаз компонентов программы.
Lessons learned — база данных извлеченных уроков.
Lost benefits — упущенные выгоды.
«Make or buy» analysis — анализ «производить самим или по-
купать на стороне».
Market share — доля рынка.
Milestones — критические результаты, контрольные события,
вехи программы.
Net present value (NPV) — текущая стоимость будущих денеж-
ных выплат.
«No-go» decision — решение об отказе от запуска программы

или инициации компонента программы.
Nonconformance cost — затраты на переработку результатов
программ, несоответствующих требованиям по качеству.
Order of magnitude — исходная оценка примерной стоимости
программы.
«Out of scope» works — работы, не включенные в состав эле-
ментов ИСР и находящиеся за пределами границ содержания
программы.
Phase gate review — обзор результатов фазы программы.
Planned value (PV) — плановая стоимость работ программы.
Program management office (PMO) — офис управления про-
граммой.
Postpone change — решение отложить изменение.
Potential cash flow problems — потенциальные проблемы недо-
статка наличных средств.
Price per earnings (PPE) — рыночная стоимость активов в рас-
чете на выручку.
Pre-program preparation — предварительная подготовка про-
граммы.
Pre-program set-up — этап предварительного определения
программы.
Presentation skills — навыки эффективных презентаций.
Problem solving — решение проблемы.
Process deviation — отклонение от процесса управления про-
граммой.
Profit icrease — повышение прибыли.
Program architects — архитекторы программного решения.
Program boundaries — границы содержания программы.
Program budget baseline — базовый бюджет программы.
Program change management log — журнал управления изме-
нениями программы.
Program closure — завершение программы.
Program benefits delivery phase — фаза достижения выгод про-
граммы.
Program closure phase — фаза завершения программы.
Program definition phase — фаза определения программы.
Program dependency analysis — анализ зависимостей програм-

мы.
Program governance board — комитет управления программой.
Program initiation — инициация программы.
Program kick-off meeting — совещание с ключевыми стейкхол-
дерами по определению содержания и запуску программы.
Program management board — комитет по управлению про-
граммой.
Program management office (PMO) — офис управления про-
граммой.
Program packages — пакеты программы.
Program risk owners — ответственные за риски программы.
Program risk register — реестр рисков программы.
Program setup — формирование программы.
Program scope assumptions — допущения в содержании про-
граммы.
Program scope statement — описание содержания программы.
Program steering committee — руководящий комитет програм-
мы.
Program transition plan — план передачи программы.
Program scope baseline — базовый план управления содержа-
нием программы.
Program work breakdown structure (PWBS) — иерархическая
структура работ (ИCР) программы.
PWBS matrix — матрица ИСР программы.
PWS-RBS Matrix — матрица корреляций иерархических
структур работ и рисков программы.
Requirements — требования.
Reject change — решение отклонить изменение.
Residual risks — остаточные риски.
Responsibility assignment matrix (RAM) — матрица ответ-
ственности.
Return on investment — возврат инвестиций.
Request for information (RFI) — запрос исходной информации
о поставщике.
Request for proposal (RFP) — запрос предложения по ком-
плексной поставке решения.
Request for quotation (RFQ) — запрос предложения по закупке

товаров.
Risk acceptance — принятие риска.
Risk analysis — анализ рисков.
Risk avoidance — уклонение от риска.
Risk breakdown structure (RBS) — иерархическая структура
рисков программы.
Risk enhance — усиление риска.
Risk exploit — использование риска.
Risk mitigation — снижение риска.
Risk of non-participation by stakeholders — риск пассивного
вовлечения стейкхолдеров.
Risk ownership — принципы ответственности за управление
рисками.
Risk share — совместное использование риска.
Risk transference — передача риска.
Return on investment (ROI) — возврат инвестиций.
Root cause identification — анализ основных причин.
Scope creep — эффект «расползания» границ содержания про-
граммы.
Scope of works — задания по работам поставщика.
S-curves — накопительные кривые стоимостей ресурсов про-
граммы.
Secondary risks — вторичные риски.
Shareholders — акционеры, собственники, владельцы имущест-
ва и активов предприятий.
Smoothing — сглаживание конфликта.
Sourcing decisions — решения по источнику поставки.
Schedule performance index (SPI) — индекс выполнения ка-
лендарного плана.
Stakeholder checklist — контрольный список участников про-
граммы.
Stakeholder impact and issue tracking and prioritization tool —
инструмент отслеживания влияния, потенциальных проблем
участников и их приоритезации.
Stakeholders — участники проектной деятельности — руково-
дители портфелей, программ, проектов, их команды, заказ-
чики, спонсоры, поставщики, подрядчики и др.
Schedule variance (SV) — отклонение по срокам.

Subject matter experts — эксперты в предметной области про-
граммы.
Sub-portfolio — подпортфель, входящий в портфель иннова-
ций.
SWOT-анализ — анализа сильных и слабых сторон компании
(внутренних факторов) в совокупности с возможностями
и угрозами для работ и результатов программы (внешними
факторами).
To complete performance index (TCPI) — показатель эффек-
тивности выполнения работ программы.
Terms & conditions — юридические условия и положения кон-
тракта.
Time & materials contract — контракт с оплатой стоимости за-
траченного времени и материалов.
Top down — движение «сверху вниз» — от целей программы на
верхнем уровне ИСР к подцелям, задачам, подзадачам на по-
следующих более низких уровнях ИСР.
Total cost of ownership analysis — анализ полной стоимости
владения продуктом программы.
Trend analysis — анализ макроэкономических тенденций и
трендов.
Trend and probability analysis — анализ трендов и вероятности
успеха программы.
Work packages — пакеты работ компонентов.
Оглавление
Предисловие .......................................................... 3
Введение в управление инновациями ......................... 8
Введение в управление программами проектов...........14
Глава 1. Интеграция программы ............................... 53
1.1. Область знаний: управление интеграцией программы ..... 54
Фаза жизненного цикла: определение программы ............ 54
Процесс: инициация программы ........................................ 54
1.2. Область знаний: управление интеграцией программы...... 57
Процесс: разработка плана управления программой ........ 57
Процесс: разработка инфраструктуры программы ............ 63
Фаза жизненного цикла: достижение выгод программы ... 66
Процесс: управление исполнением программы ................. 66
Процесс: мониторинг и контроль исполнения
программы............................................................................ 69
Фаза жизненного цикла: завершение программы.............. 75
Процесс: передача результатов программы и поддержка
выгод ......................................................................................75
1.7. Область знаний: управление интеграцией программы ...... 76
Фаза жизненного цикла: завершение программы.............. 76
Процесс: закрытие программы ........................................... 76
Бизнес-кейс «Программа технологического перевооружения
металлургического комбината» .................................................. 79
Глава 2. Содержание программы.............................. 81
2.1. Область знаний: управление содержанием программы ..... 81
Процесс: планирование содержания программы ............... 81
2.2. Область знаний: управление содержанием программы..... 96
Процесс: контроль содержания программы ....................... 96
Бизнес-кейс «Программа внедрения системы оценки КПЭ
сотрудников компании» ................................................................ 99
Глава 3. Сроки программы .....................................102
3.1. Область знаний: управление сроками программы ........... 102
Фаза жизненного цикла: определение программы .......... 102
Процесс: разработка сроков программы .......................... 102
262 Оглавление
3.2. Область знаний: управление сроками программы ........... 111

Фаза жизненного цикла: достижение выгод
программы........................................................................... 111
Процесс: контроль сроков программы .............................. 111
Бизнес-кейс «Программа по созданию производства
металлокомпозитов» ................................................................... 117
Глава 4. Финансы программы ................................. 119
4.1. Область знаний: управление финансами программы ...... 120
Процесс: оценка стоимости программы ........................... 120
4.2. Область знаний: управление финансами программы ..... 121
Процесс: определение структуры финансирования
программы.......................................................................... 121
Процесс: разработка плана финансирования
программы.......................................................................... 125
программы.......................................................................... 128
Процесс: оценка стоимости компонентов программы .... 128
программы.......................................................................... 131
Процесс: бюджетирование расходов программы ............. 131
программы.......................................................................... 133
Процесс: мониторинг и управление финансами
программы.......................................................................... 133
4.7. Область знаний: управление финансами программы...... 135
Фаза жизненного цикла: завершение программы............ 135
Процесс: закрытие финансирования программы ............ 135
Бизнес-кейс «Программа строительства
торгово-развлекательного центра» .......................................... 136
Глава 5. Качество программы ................................. 138
5.1. Область знаний: управление качеством программы ........ 138
Процесс: планирование качества программы .................. 138
5.2. Область знаний: управление качеством программы ....... 140
программы.......................................................................... 140
Процесс: обеспечение качества программы ..................... 140
Оглавление 263
5.3. Область знаний: управление качеством программы ....... 141

программы.......................................................................... 141
Процесс: контроль качества программы........................... 141
Бизнес-кейс «Программа внедрения системы
делопроизводства в министерстве».......................................... 143
Глава 6. Риски программы...................................... 145
6.1. Область знаний: управление рисками программы ........... 146
Процесс: планирование управления рисками
программы.......................................................................... 146
6.2. Область знаний: управление рисками программы .......... 149
программы.......................................................................... 149
Процесс: идентификация рисков программы ................. 149
6.3. Область знаний: управление рисками программы ......... 154
программы.......................................................................... 154
Процесс: анализ рисков программы ................................ 154
программы.......................................................................... 163
Процесс: планирование реагирования на риски
программы ......................................................................... 163
программы.......................................................................... 168
Процесс: мониторинг и контроль над рисками
программы.......................................................................... 168
Бизнес-кейс «Программа по выводу на рынок нового
фармацевтического препарата» ............................................... 173
Глава 7. Коммуникации программы ......................... 175
7.1. Область знаний: управление коммуникациями
программы ................................................................................ 176
Процесс: планирование коммуникаций ........................... 176
программы ................................................................................ 180
программы.......................................................................... 180
Процесс: распространение информации.......................... 180
программы ................................................................................ 183
264 Оглавление

программы.......................................................................... 183
Процесс: отчетность об исполнении программы ............. 183
Бизнес-кейс «Программа многопрофильного
финансово-промышленного холдинга» ....................................... 187
Глава 8. Поставки программы ................................ 189
8.1. Область знаний: управление поставками программы ..... 190
Процесс: планирование поставок программы ................. 190
программы.......................................................................... 195
Процесс: осуществление поставок программы ................ 195
программы.......................................................................... 199
Процесс: администрирование поставок программы ....... 199
Фаза жизненного цикла: завершение программы............ 202
Процесс: закрытие поставок программы.......................... 202
Бизнес-кейс «Программа автоматизации процессов
корпоративного и розничного бизнеса коммерческого
банка» ............................................................................................ 205
Глава 9. Ресурсы программы ................................. 207
9.1. Область знаний: управление ресурсами программы........ 208
Процесс: планирование ресурсов программы .................. 208
9.2. Область знаний: управление ресурсами программы ....... 212
программы.......................................................................... 212
Процесс: приоритезация ресурсов программы ................ 212
9.3. Область знаний: управление ресурсами программы ....... 213
программы.......................................................................... 213
Процесс: управление взаимозависимостью ресурсов ...... 213
Бизнес-кейс «Программа внедрения ERP системы
финансово-промышленного холдинга» ....................................... 218
Заключение........................................................ 220
Опыт внедрения в организациях принципов управления
программами проектов ............................................................ 220
Ценные рекомендации ............................................................ 223
Комментарии из практики ...................................................... 228
Извлеченные уроки.................................................................. 239
Глоссарий .......................................................... 254
Минимальные системные требования определяются соответ-
ствующими требованиями программы Adobe Reader версии
не ниже 11-й для платформ Windows, Mac OS, Android, iOS,
Windows Phone и BlackBerry; экран 10"
Учебное электронное издание
Серия: «Проекты, программы, портфели»
Павлов Александр Николаевич
УПРАВЛЕНИЕ ПРОГРАММАМИ ПРОЕКТОВ НА ОСНОВЕ
СТАНДАРТА PMI THE STANDARD FOR PROGRAM MANAGEMENT○R
ИЗЛОЖЕНИЕ МЕТОДОЛОГИИ И РЕКОМЕНДАЦИИ ПО ПРИМЕНЕНИЮ
Ведущий редактор Ю. А. Серова
Художник Н. А. Новак
Технический редактор Е. В. Денюкова
Корректор Е. Н. Клитина
Компьютерная верстка: С. А. Янковая
Подписано к использованию 19.03.15. Формат 125×200 мм
Издательство «БИНОМ. Лаборатория знаний»
125167, Москва, проезд Аэропорта, д. 3
Телефон: (499) 157-5272
e-mail: info@pilotLZ.ru, http://www.pilotLZ.ru
PMP ®, PME, канд. техн. наук
Окончил факультет кибернетики и аспиран-
туру Московского инженерно-физического
института. Имеет значительный опыт руково-
дящей работы в институте атомной энергии
им. И. В. Курчатова, ЦНИИАТОМИНФОРМ,
компании IBM EAST EUROPE/ASIA, где
занимал должность руководителя отдела
системной интеграции, а также директора
Учебного центра IBM. Прошел полный цикл
курсов IBM по эффективному управлению людьми и лидерству,
управлению проектами. С 2005 года занимал пост вице-прези-
дента Московского отделения PMI®.
Является разработчиком и тьютором курсов «Современные тех-

нологии взаимодействия с заинтересованными лицами проекта»
и «Антикризисное управление», учебных программ МВА «Поли-
тические и бизнес-коммуникации» Института коммуникационно-
го менеджмента Государственного университета – Высшей школы
экономики. Обладает значительным опытом управления проектами
для таких ведомств и организаций, как Федеральная служба занято-
сти РФ, Вертолетный завод ООО «МВЗ им. М. Л. Миля», инвестици-
онная финансовая компания «Домедко-Хаксли Лимитед» и др.

Лаборатория знаний

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Лаборатория знаний

Загружено:

Авторское право:

Доступные форматы

ПРОЕКТЫ

ложение методологии и рекомендации по применению

Деривативное электронное издание на основе печатного

В соответствии со ст. 1299 и 1301 ГК РФ при устранении

ISBN 978-5-9963-2911-3 c БИНОМ. Лаборатория знаний, 2012

Развитие любой компании может быть обеспечено только ре-

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

Определение Достижение выгод

Область знаний Завершение программы

Управление коммуникаци- Планирование коммуни- Распространение инфор-

Управление интеграцией Инициация программы Управление исполнением Передача результатов про-

Управление поставками Планирование закупок Осуществление закупок Закрытие закупок про-

Управление качеством Планирование качества Обеспечение качества про-

Управление ресурсами Планирование ресурсов Приоритезация ресурсов

Управление рисками про- Планирование управления Идентификация рисков

Управление сроками Разработка сроков Контроль сроков

Управление содержанием Планирование содержания Контроль содержания про-

Перечень областей знаний и фаз жизненного цикла про-

В заключении книги изложены выводы и окончательные

…Вчера я докладывал владельцам компании

Необходимость инновационной деятельности. Успех биз-

Уровни инновационной деятельности компании

Цель Решение Решение Достижение

Способ Инновационный Инновационная Инновационный

Результат Уникальное Ускорение Глобализация

Сегодня PMI® (Project Management Institute, USA) раз-

1 A Guide to the project management body of knowledge (PMBOK® Guide).

Стандарт по управлению проектами необходим руководи-

Цель портфеля: Цель программы:

Рис. 1. Формирование целей инноваций компании

1 Project Management Institute. The Standard for Program Management®.

Компонентами портфеля могут быть вложенные в порт-

Рис. 2. Структура портфелей, программ и проектов компании

Построение интерфейсов между уровнями инноваций в

Уровень Бизнес- Необходимое

Рис. 3. Необходимость интеграции

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

Отличия требований участников проектной деятельности

Требования участников Требования владельцев бизнеса

Достижение успеха проекта Достижение успеха компании:

расчете на акцию, повышение рыночной стоимости активов в

1 Павлов А. Н. Стратегическое управление бизнесом в портфелях проек-

…В стремлении реализовать все возможности

Программа или проект? Границы между программами и про-

 получение выгод, доступных только при объединении про-

Менеджер программы — руководитель среднего или выс-

 централизованную помощь по управлению изменениями

Тем не менее наличие воли владельцев бизнеса компании

Стратегический Определение Процесс

Рис. 4. Процесс инициации программы

В уставе программы должны быть отражены:

Рис. 5. Связь результатов процесса инициации программы

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

тегического бизнес-плана, и процедуру их официального

1 Павлов А. Н. Интеграция управления инновациями. Тезисы доклада

В табл. 4 представлены основные результаты каждого эта-

Основные результаты каждого этапа жизненного цикла

Определение программы Разработаны бизнес-кейс и стратеги-

Достижение выгод Инициированы компоненты в соответ-

Завершение программы Проведено контролируемое завершение

Управление жизненным циклом программы является од-

Домены управления программой. Компании иницииру-

Рис. 6. Взаимосвязь доменов управления программой

Содержание каждого из пяти доменов содержит процедуры