Управление программами проектов на основе стандарта PMI The Standard for Program Management. Изложение методологии и рекомендации по применению [3 ed.] 9785996329113

Citation preview

ПРОЕКТЫ ПРОГРАММЫ ПОРТФЕЛИ

А. Н. Павлов

Управление программами проектов на основе стандарта 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○ . Изложение методологии и рекомендации по применению [Электронный ресурс] / А. Н. Павлов. — 3-е изд. (эл.). — Электрон. текстовые дан. (1 файл pdf : 267 с.). — М. : БИНОМ. Лаборатория знаний, 2015. — (Проекты, программы, портфели). — Систем. требования: Adobe Reader XI ; экран 10". ISBN 978-5-9963-2911-3 R

Целью данной книги является обобщение многолетнего опыта автора по управлению крупными технологическими программами и проектами, а также разработки стандартов и методических рекомендаций, участия во многих международных и отечественных конференциях и симпозиумах, чтения лекций и учебных курсов в данной области. Большинству специалистов будут особенно интересны практический опыт и уроки, полученные в ходе управления программами проектов на основе использования стандарта 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. Формирование целей инноваций компании для реализации ее бизнес-стратегии 1

Project Management Institute. The Standard for Program Management®. Third Edition.

2

Project Management Institute. The Standard for Portfolio Management®. Third Edition.

Введение в управление инновациями

11

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

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

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

Павлов А. Н. Интеграция управления инновациями. Тезисы доклада на III Международной конференции Московского отделения PMI® по управлению проектами. М., 2006.

12

Введение в управление инновациями

Уровень портфелей компаний

Бизнесцели достигнуты

Необходимое условие успеха компании

Уровень программ

Стратегические выгоды получены

Необходимое условие успеха портфелей

Уровень проектов

Требования проектов удовлетворены

Необходимое условие успеха программ проектов

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

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

13

Введение в управление инновациями

Таблица 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.

2

Project Management Institute. The Standard for Program Management®. Third Edition.

Введение в управление программами проектов

15

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

16

Введение в управление программами проектов

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

Введение в управление программами проектов

17

 централизованную помощь по управлению изменениями и отслеживанию рисков и потенциальных проблем;  управление документацией программы. Интересен перечень основных проблем, возникающих при управлении программами, отмеченный в аналитической справке Министерства обороны США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.

18

Введение в управление программами проектов

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

Определение компонентов портфеля

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

Устав программы

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

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

Стратегическая бизнес-цель компании

Выгоды компании

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

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

Введение в управление программами проектов

19

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

1

Павлов А. Н. Интеграция управления инновациями. Тезисы доклада на III Международной конференции Московского отделения PMI® по управлению проектами. М., 2006.

2

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

20

Введение в управление программами проектов

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

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

Основные результаты этапа

Определение программы

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

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

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

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

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

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

Введение в управление программами проектов

21

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

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

22

Введение в управление программами проектов

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

Введение в управление программами проектов

23

Рис. 7. Взаимосвязь элементов согласования программы

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

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

    

План программы отражает: концепцию организации; видение программы; миссию программы; ожидаемые выгоды программы; цели и задачи программы.

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

24

Введение в управление программами проектов

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

Рис. 8. Пример дорожной карты программы

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

Введение в управление программами проектов

25

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

26

Введение в управление программами проектов

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

Рис. 9. Управление выгодами в ходе жизненного цикла программы

28

Введение в управление программами проектов

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

Введение в управление программами проектов

29

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

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

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

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

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

30

Введение в управление программами проектов

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

Введение в управление программами проектов

31

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

32

Введение в управление программами проектов

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

Введение в управление программами проектов

33

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

Рис. 10. Пример взаимосвязей заинтересованных сторон программы

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

34

Введение в управление программами проектов

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

Введение в управление программами проектов

35

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

36

Введение в управление программами проектов

Рис. 11. Матрица вовлеченности заинтересованных сторон программы

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

Введение в управление программами проектов

37

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

38

Введение в управление программами проектов

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

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

    

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

Введение в управление программами проектов

39

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

40

Введение в управление программами проектов

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

Введение в управление программами проектов

41

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

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

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

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

42

Введение в управление программами проектов

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

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

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

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

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

Введение в управление программами проектов

43

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

Рис. 13. Пример структуры высокоуровневого управления программы торгово-промышленной группы «Создание производства металлокомпозитов»

Рис. 14. Пример организационной структуры программы торгово-промышленной группы «Создание производства металлокомпозитов»

Рис. 15. Блок-схема жизненного цикла программы

Введение в управление программами проектов

47

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

48

Введение в управление программами проектов

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

Введение в управление программами проектов

49

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

50

Введение в управление программами проектов

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

Введение в управление программами проектов

51

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

52

Введение в управление программами проектов

Запрос на передачу компонента может поступить в программный комитет либо вследствие завершения всех работ компонента, либо по инициативе остановки/замораживания работ компонента. ! Комментарий из практики. Причинами остановки/замораживания работ компонента могут быть изменения в содержании и целях программы, а также дефицит финансовых средств, возникший в бюджете программы. Отчет о реализации выгод используется для анализа полученных результатов компонента, обеспечивающих достижение выгод программы и их сравнения с утвержденным планом реализации выгод. В случае невозможности достижения плановых результатов и выгод программы может возникнуть необходимость остановки/замораживания работ компонента. По результатам рассмотрения запроса на передачу компонента и отчета о реализации выгод программы принимается решение о передаче результатов компонента заказчику программы либо об остановке/замораживании компонента. Решение о передаче компонента — официальное решение программного комитета о передаче результата компонента заказчику программы либо его остановке/замораживании — должно быть отражено в официальном документе — сертификате компонента. Фаза завершения программы позволяет провести контролируемое завершение всей программы и передать ее результаты заказчику программы. В ходе проведения данной фазы менеджер программы обязан обосновать и подтвердить достижение всех запланированных выгод программы и передачу результатов всех компонентов программы. Теперь рассмотрим подробно описания ключевых компетенций менеджера программы — девяти областей знаний стандарта PMI The Standard for Program Management®. Вниманию читателя предлагается последовательное изложение всех поддерживающих домены процессов стандарта в каждой из девяти областей знаний и рекомендации автора по их использованию на практике.

ГЛАВА 1

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

Значение области знаний «Управление интеграцией программы» стандарта PMI The Standard for Program Management®. В данной области знаний стандарта описана одна из девяти ключевых компетенций руководителя программы по интеграции всевозможных планов, работ, ресурсов и результатов программы. Семь процессов, рекомендованных стандартом в данной области знаний, относятся к фазам жизненного цикла определения, достижения выгод и завершения программы (табл. 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. Утверждение устава и обновленного бизнес-кейса спонсором и заказчиком программы необходимо провести в результате презентации менеджера программы, посвященной детальному изложению данных документов ключевым стейкхолдерам программы (включая руководство организации и/или владельцев компании) и обмена экспертными оценками.

Интеграция программы

57

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

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

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

58

Глава 1

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

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

Интеграция программы

59

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

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

60

Глава 1

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

Интеграция программы

61

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

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

62

Глава 1

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

Интеграция программы

63

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

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

64

Глава 1

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

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

Интеграция программы

65

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

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

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

66

Глава 1

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

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

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

Интеграция программы

67

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

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

68

Глава 1

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

Интеграция программы

69

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

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

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

70

Глава 1

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

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

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

Интеграция программы

71

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

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

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

72

Глава 1

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

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

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

73

Интеграция программы

Пример формата перечня потенциальных проблем приведен ниже:

№ п/п

Описание потенциальной проблемы

Владелец

Плановая дата решения

Статус Формупоиска лировка решения на и дата контроль- найденного ную дату решения

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

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

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

74

Глава 1

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

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

Интеграция программы

75

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

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

76

Глава 1

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

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

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

Интеграция программы

77

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

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

78

Глава 1

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

Интеграция программы

79

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

80

Глава 1

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

ГЛАВА 2

Содержание программы

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

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

Фаза жизненного цикла

Планирование содержания программы

Определение программы

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

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

Описания данных процессов и рекомендаций автора по их применению приводятся далее.

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

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

82

Глава 2

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

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

Содержание программы

83

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

84

Глава 2

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

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

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

Содержание программы

85

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

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

86

Глава 2

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

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

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

Содержание программы

87

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

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

88

Глава 2

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

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

Содержание программы

89

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

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

Рис. 16. Пример ИСР программы

Содержание программы

91

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

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

92

Глава 2

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

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

Роль 1

Роль 2

…

Роль M

Результат 1

Консультирует

Разрабатывает

Согласовывает

Результат 2

Разрабатывает

Согласовывает

Утверждает

… Результат N

Рис. 18. Пример матрицы ответственности

Содержание программы

93

! Комментарий из практики. Разработка матрицы ответственности позволяет менеджеру программы эффективно распределить ответственность за достижение результатов программы между различными членами команды программы. Строки матрицы ответственности показывают распределение индивидуального вклада различных ролей команды в достижение конкретного результата, а столбцы — ответственность конкретной роли в достижении определенных результатов программы. ИСР программы, являющаяся результатом данного процесса, дополняет описание содержания программы структурированным представлением ее работ в виде иерархической структуры, ориентированной на достижение результатов программы. Элементы такой иерархической структуры могут быть сгруппированы в матрице ИСР по направлениям работ (ветвям ИСР), либо по общим ресурсам или исполнителям работ, либо в любой другой форме, учитывающей специфику содержания конкретной программы. Извлеченные уроки процесса 2.1  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. Требования к программе часто меняются в ходе выполнения ее работ. Изменения в требованиях программы должны быть проанализированы с точки зрения их выполнимости и влияния на успех программы.

Содержание программы

95

 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. Разработка матрицы ответственности позволяет менеджеру программы эффективно распределить ответственность за достижение результатов программы между различными членами команды программы. Строки матрицы ответственности показывают распределение индивидуального вклада различных ролей команды в достижение конкретного результата, а столбцы — ответственность конкретной роли в достижении определенных результатов программы.

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

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

Содержание программы

97

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

98

Глава 2

Комитет по управлению изменениями программы

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

Изменения в содержании компонента, влияющие на содержание программы и/или ее компонентов

Комитет по управлению изменениями компонента программы

Рис. 19. Взаимодействие комитетов по управлению изменениями программы и ее компонентов

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

Содержание программы

99

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

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

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

100

Глава 2

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

Содержание программы

101

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

ГЛАВА 3

Сроки программы

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

Процессы и фазы жизненного цикла области знаний «Управление сроками программы» Процесс

Фаза жизненного цикла

Разработка сроков программы

Определение программы

Контроль сроков программы

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

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

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

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

Сроки программы

103

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

104

Глава 3

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

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

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

105

Сроки программы

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

Доходы и расходы программы, долл.

Доходы, расходы и упущенные выгоды программы представлены на рис. 20.

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

Упущенная выгода

0 Момент окупаемости

Расходы проекта

Сроки программы, Т

Доходы операционной деятельности от эксплуатации продукта проекта

Фактический срок завершения проекта программы Плановый срок завершения проекта программы и создания продукта

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

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

Доходы и расходы программы, долл.

106

Глава 3

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

0

^$ ^Т

«Т»

Расходы проекта

Упущенная выгода

Сроки программы, Т

Доходы операционной деятельности

Фактический срок завершения проекта программы Плановый срок завершения проекта программы

Рис. 21. Значения упущенной выгоды, выраженные в потерях прибыли (^$) и сроков (^T) на момент времени «T» жизненного цикла программы

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

Сроки программы

107

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

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

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

108

Глава 3

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

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

Сроки программы

109

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

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

110

Глава 3

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

Сроки программы

111

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

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

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

112

Глава 3

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

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

113

Сроки программы

Метрики могут определять допустимые, средние и критические периоды отставания (как и опережения) по срокам программы. Пример метрик расписания программы приведен в табл. 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 performance 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).

Сроки программы

115

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

116

Глава 3

Отчеты об исполнении расписания программы отражают статус расписания и сведения о соблюдении, опережении или отставании в сроках исполнения работ программы и критически важных контрольных событий компонентов. Как правило, программа состоит из ряда компонентов с различными статусами исполнения расписаний. Например, на момент подготовки отчета об исполнении расписания программы один из проектов программы может выполняться в установленные сроки, другой иметь опережение сроков на 10%, а третий — отставание на 15%. Что можно сказать в этом случае о статусе расписания программы в целом? Ответ на этот вопрос должен дать менеджер программы, учитывающий приоритеты отдельных компонентов и временные резервы высокоуровневого расписания программы. Извлеченные уроки процесса 3.2  LL-3.2.1. Менеджер программы должен стремиться к соблюдению здравого баланса между проводимым им контролем расписания компонентов и предоставлением руководителям компонентов определенной свободы в принятии решений по управлению расписаниями компонентов.  LL-3.2.2. Для своевременного обнаружения возможных срывов сроков контрольных событий полезно использовать технику ранних контрольных событий, сигнализирующих о приближении сроков завершения или старта критически важных работ компонентов.  LL-3.2.3. Если отставание по срокам программы однозначно является негативным результатом, то опережение сроков программы не всегда является позитивным результатом.  LL-3.2.4. Метод освоенного объема позволяет проводить интегрированный анализ как исполнения графика, так и бюджета программы по стоимостным показателям.  LL-3.2.5. Расчет отклонений по стоимости (CV), срокам (SV) и индексов выполнения бюджета (CPI) и графика (SPI) следует проводить по завершении этапа или достижении контрольной точки программы.

Сроки программы

117

 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 Management®. В данной области знаний стандарта описана одна из девяти ключевых компетенций руководителя программы по управлению финансами программы. Семь процессов, рекомендованных стандартом в данной области знаний, относятся к фазам жизненного цикла определения, достижения выгод и завершения программы (табл. 9). Таблица 9

Процессы и фазы жизненного цикла области знаний «Управление финансами программы» Процесс

Фаза жизненного цикла

Оценка стоимости программы

Определение программы

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

Определение программы

Разработка плана финансирования

Определение программы

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

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

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

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

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

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

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

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

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

120

Глава 4

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

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

Финансы программы

121

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

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

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

122

Глава 4

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

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

Финансы программы

123

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

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

124

Глава 4

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

Финансы программы

125

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

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

126

Глава 4

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

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

Финансы программы

127

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

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

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

128

Глава 4

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

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

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

Финансы программы

129

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

Резерв на непредвиденные обстоятельства должен быть включен в оценку расходов программы для использования при возникновении непредвиденных изменений и при реагировании на известные риски программы. Анализ резервов используется для определения достаточных (и не избыточных) резервов бюджета программы для своевременного реагирования на риски программы и на непредвиденные изменения в содержании программы и в окружающей среде. Компьютерные инструменты оценки стоимости (computer cost estimating tools) используются для анализа и вычислений общей стоимости материалов и человеческих ресурсов компонентов программы.

130

Глава 4

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

Финансы программы

131

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

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

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

132

Глава 4

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

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

Финансы программы

133

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

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

134

Глава 4

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

Финансы программы

135

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

4.7. Область знаний: управление финансами программы Фаза жизненного цикла: завершение программы Процесс: закрытие финансирования программы

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

136

Глава 4

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

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

Финансы программы

137

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

ГЛАВА 5

Качество программы

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

Процессы и фазы жизненного цикла области знаний «Управление качеством программы» Процесс

Фаза жизненного цикла

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

Определение программы

Обеспечение качества программы

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

Контроль качества программы

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

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

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

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

Качество программы

139

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

140

Глава 5

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

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

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

Качество программы

141

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

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

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

142

Глава 5

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

Качество программы

143

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

144

Глава 5

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

ГЛАВА 6

Риски программы

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

Процессы и фазы жизненного цикла области знаний «Управление рисками программы» Процесс

Фаза жизненного цикла

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

Определение программы

Идентификация рисков программы

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

Анализ рисков программы

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

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

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

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

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

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

146

Глава 6

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

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

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

Риски программы

147

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

148

Глава 6

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

Риски программы

149

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

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

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

150

Глава 6

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

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

Риски программы

151

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

152

Глава 6

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

Риски программы

153

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

154

Глава 6

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

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

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

Риски программы

155

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

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

156

Глава 6

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

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

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

Рис. 22. Пример матрицы вероятностей и степени влияния рисков программы

158

Глава 6

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

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

Риски программы

159

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

Рис. 23. Пример матрицы корреляции иерархических структур работ (PWS) и рисков (RBS) программы

Рис. 24. Пример матрицы взаимного влияния рисков программы и проектов

162

Глава 6

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

Риски программы

163

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

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

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

164

Глава 6

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

! Комментарий из практики. Уклонение от риска часто связано с отказом от выполнения работ или от использования ресурса программы, содержащих риск. Если рискованная работа не выполняется или рискованный ресурс не используется, то и риск не происходит. 2. Передача риска (risk transference) — перенос последствий риска на третью сторону. Перенос не устраняет риск, а передает управление риском третьей стороне. Обычно за перенос риска взимается страховая премия. Пример — страхование основных средств, покупка опционов. ! Комментарий из практики. Передача управления риском третьей стороне должна быть зафиксирована в формальном документе. Например, передача риска срыва сроков поставки на плечи поставщика может быть зафиксирована в контракте с поставщиком путем определения штрафных санкций за срыв сроков поставки.

Риски программы

165

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), которые возникают вследствие реализации стратегий реагирования. Резервы на управление рисками — оцененные, одобренные и включенные в план программы необходимые резервы на управление рисками — бюджетные, временные, информационные, человеческие или организационные. Планы использования резервов включают сведения об условиях использования резервов, влияния использования резервов на бюджет и расписание программы, ресурсы, необходимые для использования резервов, и статус исполнения

Риски программы

167

плана (резерв запланирован, выделен, в стадии использования или использован). Запросы на изменения включают изменения в плане управления программой, которые могут потребоваться при реализации стратегий реагирования на риски программы. Извлеченные уроки процесса 6.4  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

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

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

Риски программы

169

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

! Комментарий из практики. Существенная экономия денежных резервов программы по ее завершении является результатом плохого планирования и некачественной оценки и анализа рисков программы. Владельцы бизнеса и высшее руководство компании могут обвинить менеджера программы в замораживании денежных средств в виде резервов на управление рисками программы, которые оказались невостребованными. Эти средства могли бы быть использованы в других программах и принести выгоды в бизнесе компании. Напротив, разумная доля экономии резервов может быть результатом профессионального управления рисками программы и источником вознаграждения менеджера программы и команды управления программой. Реестр потенциальных проблем программы используется для выяснения адекватности выбранной стратегии реагирования, послужившей возникновению потенциальной проблемы как материализовавшегося риска. ! Комментарий из практики. Отличия потенциальной проблемы (issue) от риска не всегда являются очевидными для членов команд управления программами. Главные различия заключаются в том, что риски могут быть как позитивными, так и негативными, в то время как потенциальная проблема несет в себе только негатив. Кроме того, любой риск имеет два основных параметра — вероятность возникновения и влияние, в то время как потенциальная проблема оценивается по параметру влияния и не всегда может иметь оценку вероятности возникновения.

170

Глава 6

Контракты с поставщиками компонентов программы анализируются для проверки эффективности управления рисками в работах с внешними поставщиками программы в соответствии с подписанными с ними контрактами. Любой контракт с внешним поставщиком состоит из двух частей: юридических условий и положений (terms & conditions) и заданий по работам поставщика (scope of works). Риски контракта могут содержаться в каждой из этих частей. ! Комментарий из практики. Менеджер программы и члены команды управления программой обязаны проводить мониторинг и контроль над рисками контрактов в части заданий по работам поставщика. К анализу рисков в части юридических условий и положений контрактов необходимо привлекать представителей юридической службы компании и менеджеров по контрактам (contract managers). Инструментами и методами данного процесса являются: совещания по текущему состоянию рисков, аудит рисков, анализ извлеченных уроков, мониторинг окружения программы, мониторинг изменений в сфере законодательства. Совещания по текущему состоянию рисков проводятся регулярно и посвящены анализу статуса существующих рисков и новых рисков программы, включая:  анализ статуса реестра рисков;  изменения в оценках вероятности возникновения и влияния рисков;  анализ предположений и допущений о возникновении рисков;  анализ эффективности стратегий реагирования на риски программы. Результатом совещаний могут быть принятые решения по изменениям в оценках, предположениях и допущениях относительно рисков, а также изменения стратегий реагирования на риски программы. Аудит рисков — проведение независимого от менеджера программы анализа рисков и выбранных стратегий реагирования на риски. Такой аудит проводится внешним независимым

Риски программы

171

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

172

Глава 6

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

Риски программы

173

там поставщика. К анализу рисков в части юридических условий и положений контрактов необходимо привлекать представителей юридической службы организации и менеджеров по контрактам.  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

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

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

Коммуникации программы

177

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

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

178

Глава 7

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

Коммуникации программы

179

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

180

Глава 7

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

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

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

Коммуникации программы

181

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

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

182

Глава 7

фективных презентаций (presentation skills). Обладание таким искусством позволит менеджеру программы наиболее эффективно донести результаты и проблемы программы до сведения высшего руководства и владельцев бизнеса, от решения которых зависит дальнейшая судьба программы. ! Комментарий из практики. Использование менеджером программы эффективных навыков коммуникаций должно обеспечить получение и верное понимание определенными стейкхолдерами определенной информации в определенное время. Методы распространения информации (information distribution methods) обеспечивают направление необходимой информации отправителем получателю по различным коммуникационным каналам, описанным выше. Проходя по коммуникационному каналу, информационное сообщение подвергается искажениям по причинам всевозможных барьеров и помех, возникающих в канале связи (например, физических шумов и помех в телефонном канале связи или языковых, культурных, ментальных различий между отправителем и получателем сообщения). Использование канала обратной связи позволяет получателю задать все необходимые дополнительные вопросы отправителю для уточнения понимания смысла полученного сообщения. Выходами процесса являются обновления данных информационной системы управления программой, извлеченные уроки; архивированные данные и инструкции по использованию архива. Обновления данных информационной системы управления программой содержат отчеты об исполнении, которые являются основным информационным источником, описывающим ход выполнения программы. Формат отчета, как правило, задан офисом управления программой как стандартный, но может быть дополнен новыми разделами в случае изменения информационных потребностей стейкхолдеров. Извлеченные уроки включают описания как успехов, так и неудач программы и рекомендации по улучшению управления

Коммуникации программы

183

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

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

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

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

184

Глава 7

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

185

Коммуникации программы

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

Пример регламента совещаний о статусе программы с различной частотой на различных уровнях управления программой Название совещания по статусу программы

Ведущий совещания

Участники совещания

Частота проведения

Совещание программного комитета

Председатель программного комитета

Члены программного комитета

Раз в месяц

Совещание команды управления программой

Менеджер программы

Команда управления программой

Раз в две недели

Совещания команды управления компонентом программы

Руководитель компонента

Команда управления компонентом

Раз в неделю

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

186

Глава 7

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

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

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

Коммуникации программы

187

 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

Поставки программы

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

Процессы и фазы жизненного цикла области знаний «Управление поставками программы» Процесс

Фаза жизненного цикла

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

Определение программы

Осуществление поставок программы

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

Администрирование поставок программы

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

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

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

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

190

Глава 8

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

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

Поставки программы

191

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

192

Глава 8

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

Поставки программы

193

– контракт с фиксированной ценой (fixed price contract); – контракт с возмещением стоимости (cost reimbursable contract); – контракт с оплатой стоимости затраченного рабочего времени и материалов (time & materials contract); ! Комментарий из практики. Контракты с фиксированной ценой и с оплатой стоимости затраченного рабочего времени и материалов активно используются на отечественном рынке, в то время как контракт с возмещением затрат является редкостью. Тем не менее такой контракт становится необходимым в условиях развитого рынка и высокой конкуренции, так как его применение позволяет заказчику «удержать» поставщика при возникновении риска его ухода к конкуренту. Это обеспечивается гарантией заказчика полностью компенсировать затраты поставщика и даже при определенных условиях выплатить поставщику дополнительное вознаграждение, составляющее его чистую прибыль, так как затраты уже компенсированы. Размер чистой прибыли может быть выше прибыли поставщика, заложенной в фиксированной цене его предложения конкуренту.  определения требуемых и имеющихся ресурсов — позволяет выявить недостаток ресурсов компании для выполнения работ программы и поиска недостающих ресурсов на рынке;  решения по источнику поставки (sourcing decisions) — позволяет определить очевидную необходимость внешних источников поставки из-за бессмысленности выполнения поставки ресурсами компании. Например, в случае необходимости для программы разработки автоматизированной системы редактора текстов может быть очевидна необходимость покупки такой готовой системы на рынке, а не разработки такой системы собственными силами компании;  определение общих поставок программы — позволяет выявить поставки, необходимые для всей программы или для ряда ее компонентов. Например, это может быть закупка партии ноутбуков для персонала команды управления программой и всех ее компонентов.

194

Глава 8

! Комментарий из практики. Определение общих поставок программы позволяет существенно снизить затраты и сэкономить бюджет программы. Невыявление общих поставок программы может привести к закупкам однотипных товаров по разным ценам для разных компонентов программы и появлению дополнительных издержек.  процедуры оценки предложений поставщиков — необходимы для объективной оценки предложений поставщиков и используют критерии оценки, такие как, например, скорость поставки, цена, качество или опыт поставщика в подобных поставках, его репутация и др.;  перечни квалифицированных поставщиков (qualified seller lists) — определяют методы анализа и отбора квалифицированных поставщиков на основе использования сведений о них из открытых источников, Интернета, отзывов заказчиков, встреч с представителями поставщиков и др. Обновления плана бюджетирования/финансирования программы могут потребоваться при необходимости выделения дополнительного финансирования для заключения контрактов с поставщиками программы. Извлеченные уроки процесса 8.1  LL-8.1.1. Для проведения сравнительного анализа поставщиков программы желательно привлекать специалистов подразделений компаний, непосредственно занимающихся организацией поставок в своей повседневной деятельности. Эти специалисты хорошо знают рынок и деятельность конкретных внешних компаний, способных осуществить необходимую для программы поставку.  LL-8.1.2. Максимальный риск возникает при необходимости привлечения внешнего поставщика для выполнения работ программы, в которых у команды управления программой нет собственных компетенций. В этом случае заказчик (менеджер программы или команда управления

Поставки программы

195

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

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

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

196

Глава 8

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

Поставки программы

197

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

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

198

Глава 8

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

Поставки программы

199

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

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

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

200

Глава 8

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

Поставки программы

201

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

202

Глава 8

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

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

Поставки программы

203

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

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

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

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

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

204

Глава 8

! Комментарий из практики. Менеджер программы обязан уведомить всех заинтересованных стейкхолдеров программы, включая руководителей компонентов, о закрытых контрактах для избегания запросов на очередные поставки программы по недействующим контрактам. Отчеты об исполнении поставок по закрытым контрактам содержат результаты обзора проведенных поставок и рекомендации по повышению их эффективности в будущих программах компании. Отнесение затрат при закрытии бюджета производится по всем закрытым контрактам после проведения всех окончательных платежей поставщикам. ! Комментарий из практики. Экономия затрат, понесенных компанией по обеспечению поставок программы, является источником пополнения резерва бюджета программы. Извлеченные уроки процесса 8.4  LL-8.4.1. В случае досрочного расторжения контракта по данной процедуре требуется документировать все выполненные и невыполненные обязательства поставщика на момент расторжения контракта и причины его досрочного расторжения. Менеджеру программы следует незамедлительно планировать и организовывать исполнение невыполненных обязательств альтернативными поставщиками.  LL-8.4.2. Сроки проведения финансовых аудитов компании, как правило, редко совпадают со сроками закрытия контрактов с поставщиками. Поэтому финансовая сверка и отнесение затрат на соответствующие центры финансовой ответственности являются необходимыми в процессе закрытия поставок.  LL-8.4.3. Менеджер программы обязан уведомить всех заинтересованных стейкхолдеров программы, включая руководителей компонентов, о закрытых контрактах для избегания запросов на очередные поставки программы по недействующим контрактам.

Поставки программы

205

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

206

Глава 8

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

ГЛАВА 9

Ресурсы программы

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

Процессы и фазы жизненного цикла области знаний «Управление ресурсами программы» Процесс

Фаза жизненного цикла

Планирование ресурсов программы

Определение программы

Приоритезация ресурсов

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

Управление взаимозависимостью ресурсов

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

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

208

Глава 9

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

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

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), часто возникающего в матричных организационных структурах при определении степени загрузки человеческих ресурсов в программе или в операционной деятельности компании. Ниже приведена последовательность действий по разрешению конфликта двойного подчинения: Ответственный

Действие

Руководитель программы

Запрос на человеческий ресурс (с указанием полной или частичной загрузки в программе)

Функциональный руководитель

Согласование выделения ресурса

Руководитель программы

Эскалация куратору программы (при отсутствии согласования выделения ресурса)

Генеральный директор

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

Офис управления программой

Обновление календаря ресурсов в соответствии с приказом

Руководитель программы

Высвобождение ресурса из программы по завершении работ

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

Ресурсы программы

211

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

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

212

Глава 9

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

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

Ресурсы программы

213

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

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

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

214

Глава 9

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

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

Ресурсы программы

215

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

216

Глава 9

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

 принуждение (forcing).Утверждение одной точки зрения в ущерб другим; предполагает победу только одной стороны и авторитарное давление мнения этой стороны над другими мнениями;  сотрудничество (collaborating). Объединение множества точек зрения и мнений с различных сторон ведет к согласию; ! Комментарий из практики. Данный метод, основанный на постепенном, демократическом проявлении стремления менеджера программы объединить множество точек зрения и мнений с различных сторон, требует времени и длительных обсуждений позиций конфликтующих сторон. Применение такого метода возможно, если менеджер программы располагает таким временем, так как разрешение конфликта не является срочным и его можно отложить. Срочность разрешения конфликта может потребовать использование другого метода, например принуждения.  решение проблемы (problem solving). Менеджер программы относится к конфликту как к проблеме, которую нужно решить рассмотрением альтернатив (win/win) — все конфликтующие стороны выигрывают (win), так как в разрешении конфликта менеджеру программы удалось объединить их самые сильные предложения. ! Комментарий из практики. Данный метод, редко достижимый на практике, является наиболее эффективным способом разрешения конфликта, так как менеджеру программы удается найти сочетание самых сильных предложений конфликтующих сторон в интересах каждой из них и успеха программы в целом.

Ресурсы программы

217

Эффективное применение данных методов в управлении конфликтами руководителей компонентов программы позволяет обеспечить их конструктивное взаимодействие и получить на выходе данного процесса одобренные запросы на изменения, обновления плана управления программой и плана управления коммуникациями. Выходом данного процесса являются обновления ресурсного плана программы, учитывающие взаимозависимость ресурсов и результаты разрешения конфликтов между руководителями компонентов программы. Извлеченные уроки процесса 9.3  LL-9.3.1. Менеджер программы отвечает за организацию и управление эффективным взаимодействием ресурсов компонентов, но не за управление ресурсами самих компонентов. Такое управление является ответственностью руководителей проектов и блоков операционной деятельности, входящих в программу в качестве ее компонентов.  LL-9.3.2. При разработке дополнительных аргументов, сближающих позиции конфликтующих руководителей компонентов, менеджер программы может использовать неизвестную им информацию стратегического характера.  LL-9.3.3. Одобренные, отклоненные или отложенные изменения ресурсов программы заносятся в журнал управления изменениями программы (program change management log). Ведение данного журнала является обязанностью офиса управления программой.  LL-9.3.4. Компромисс является на практике наиболее частым выходом из конфликтной ситуации, но не самым эффективным. Компромисс возможен только в случае нахождения гибкого разрешения конфликта, сочетающего мнения конфликтующих сторон. При необходимости поиска строгого однозначного решения компромисс невозможен и выходом из конфликтной ситуации может быть только победа одной из сторон и принуждение противоположной стороны согласиться с победившей стороной.

218

Глава 9

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

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

Ресурсы программы

219

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

Заключение

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

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

Заключение

221

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

222

Заключение

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

Заключение

223

Ценные рекомендации Домен: руководство программой Менеджер программы должен быть готов к проведению как внешнего, так и внутреннего аудита программы. Для успешного прохождения аудита менеджер программы должен неукоснительно следовать всем процессам и процедурам компании по управлению программой. Наряду с подготовкой к проведению плановых аудитов менеджер программы должен быть постоянно готов к проведению внезапных, незапланированных аудитов. Область знаний: управление интеграцией программы При инициации программы необходимо учитывать стратегические цели и директивы компании, достижение которых должно быть поддержано результатами программы и выгодами, получаемыми компанией от ее реализации. Область знаний: управление содержанием программы Характеристики выгоды (benefit metrics) как окончательного результата программы должны быть описаны в определенных метриках (например, в денежных единицах дохода, прибыли организации или временных характеристиках периода возврата инвестиций, момента окупаемости и т. п.). Границы содержания программы (program boundaries) должны описывать те работы программы, которые не следует ожидать, потому что они не будут выполнены по причинам отсутствия необходимых ресурсов, высоких рисков или нежелания ключевых стейкхолдеров их выполнять. Границы содержания программы могут меняться при изменении требований заказчика и ожиданий конечных пользователей (end-user expectations) результатов программы. После утверждения программным комитетом новых границ содержания программы менеджер программы обязан придерживаться обновленных границ и не выполнять работы, лежащие за их пределами. Требования к программе часто меняются в ходе выполнения ее работ. Изменения в требованиях программы должны быть проанализированы с точки зрения их выполнимости и влияния на успех программы. Требования к программе не должны описывать технические требования к характеристикам продуктов ее компонентов.

224

Заключение

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

Заключение

225

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

226

Заключение

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

Заключение

227

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

228

Заключение

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

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

Заключение

229

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

230

Заключение

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

Заключение

231

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

232

Заключение

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

Заключение

233

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

234

Заключение

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

должна быть зафиксипередача риска срыва быть зафиксирована в штрафных санкций за

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

Заключение

235

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

236

Заключение

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

Заключение

237

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

238

Заключение

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

Заключение

239

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

240

Заключение

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

Заключение

241

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

242

Заключение

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

Заключение

243

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

244

Заключение

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

Заключение

245

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

246

Заключение

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

Заключение

247

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

248

Заключение

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

Заключение

249

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

250

Заключение

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

Заключение

251

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

252

Заключение

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

Заключение

253

 Одобренные, отклоненные или отложенные изменения ресурсов программы заносятся в журнал управления изменениями программы (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 diagrams) — диаграммы причинно-следственных связей. 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) — текущая стоимость будущих денежных выплат.

Глоссарий

257

«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 — фаза определения программы.

258

Глоссарий

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) — запрос предложения по комплексной поставке решения.

Глоссарий

259

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 — участники проектной деятельности — руководители портфелей, программ, проектов, их команды, заказчики, спонсоры, поставщики, подрядчики и др.

260

Глоссарий

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 Процесс: разработка плана управления программой ........ 57 1.3. Область знаний: управление интеграцией программы...... 63 Фаза жизненного цикла: определение программы ............ 63 Процесс: разработка инфраструктуры программы ............ 63 1.4. Область знаний: управление интеграцией программы...... 66 Фаза жизненного цикла: достижение выгод программы ... 66 Процесс: управление исполнением программы ................. 66 1.5. Область знаний: управление интеграцией программы...... 69 Фаза жизненного цикла: достижение выгод программы ... 69 Процесс: мониторинг и контроль исполнения программы............................................................................ 69 1.6. Область знаний: управление интеграцией программы...... 75 Фаза жизненного цикла: завершение программы.............. 75 Процесс: передача результатов программы и поддержка выгод ......................................................................................75 1.7. Область знаний: управление интеграцией программы ...... 76 Фаза жизненного цикла: завершение программы.............. 76 Процесс: закрытие программы ........................................... 76 Бизнес-кейс «Программа технологического перевооружения металлургического комбината» .................................................. 79 Глава 2. Содержание программы.............................. 81 2.1. Область знаний: управление содержанием программы ..... 81 Фаза жизненного цикла: определение программы ............ 81 Процесс: планирование содержания программы ............... 81 2.2. Область знаний: управление содержанием программы..... 96 Фаза жизненного цикла: достижение выгод программы ... 96 Процесс: контроль содержания программы ....................... 96 Бизнес-кейс «Программа внедрения системы оценки КПЭ сотрудников компании» ................................................................ 99 Глава 3. Сроки программы .....................................102 3.1. Область знаний: управление сроками программы ........... 102 Фаза жизненного цикла: определение программы .......... 102 Процесс: разработка сроков программы .......................... 102

262

Оглавление

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

Оглавление

5.3. Область знаний: управление качеством программы ....... Фаза жизненного цикла: достижение выгод программы.......................................................................... Процесс: контроль качества программы........................... Бизнес-кейс «Программа внедрения системы делопроизводства в министерстве»..........................................

263

141 141 141 143

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

264

Оглавление

Фаза жизненного цикла: достижение выгод программы.......................................................................... 183 Процесс: отчетность об исполнении программы ............. 183 Бизнес-кейс «Программа многопрофильного финансово-промышленного холдинга» ....................................... 187 Глава 8. Поставки программы ................................ 189 8.1. Область знаний: управление поставками программы ..... 190 Фаза жизненного цикла: определение программы .......... 190 Процесс: планирование поставок программы ................. 190 8.2. Область знаний: управление поставками программы ..... 195 Фаза жизненного цикла: достижение выгод программы.......................................................................... 195 Процесс: осуществление поставок программы ................ 195 8.3. Область знаний: управление поставками программы ..... 199 Фаза жизненного цикла: достижение выгод программы.......................................................................... 199 Процесс: администрирование поставок программы ....... 199 8.4. Область знаний: управление поставками программы ..... 202 Фаза жизненного цикла: завершение программы............ 202 Процесс: закрытие поставок программы.......................... 202 Бизнес-кейс «Программа автоматизации процессов корпоративного и розничного бизнеса коммерческого банка» ............................................................................................ 205 Глава 9. Ресурсы программы ................................. 207 9.1. Область знаний: управление ресурсами программы........ 208 Фаза жизненного цикла: определение программы .......... 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: [email protected], http://www.pilotLZ.ru

А. Н. Павлов PMP ®, PME, канд. техн. наук Окончил факультет кибернетики и аспирантуру Московского инженерно-физического института. Имеет значительный опыт руководящей работы в институте атомной энергии им. И. В. Курчатова, ЦНИИАТОМИНФОРМ, компании IBM EAST EUROPE/ASIA, где занимал должность руководителя отдела системной интеграции, а также директора Учебного центра IBM. Прошел полный цикл курсов IBM по эффективному управлению людьми и лидерству, управлению проектами. С 2005 года занимал пост вице-президента Московского отделения PMI®. Является разработчиком и тьютором курсов «Современные технологии взаимодействия с заинтересованными лицами проекта» и «Антикризисное управление», учебных программ МВА «Политические и бизнес-коммуникации» Института коммуникационного менеджмента Государственного университета – Высшей школы экономики. Обладает значительным опытом управления проектами для таких ведомств и организаций, как Федеральная служба занятости РФ, Вертолетный завод ООО «МВЗ им. М. Л. Миля», инвестиционная финансовая компания «Домедко-Хаксли Лимитед» и др.