Управление проектами на основе стандарта PMI PMBOK®. Изложение методологии и опыт применения (PDFDrive)

ПРОЕКТЫ
ПРОГРАММЫ
ПОРТФЕЛИ
А. Н. Павлов
Управление проектами
на основе стандарта
PMI PMBOK®
Изложение методологии
и опыт применения
4-е издание,
исправленное и дополненное
(электронное)
Москва
БИНОМ. Лаборатория знаний
2014
УДК 65.0
ББК 65.290-2
П12
С е р и я о с н о в а н а в 2010 г.
Павлов А. Н.
П12 Управление проектами на основе стандарта
PMI PMBOK○ . Изложение методологии и опыт приме-
R
нения [Электронный ресурс] / А. Н. Павлов. — 4-е изд.,

испр. и доп. (эл.). — М. : БИНОМ. Лаборатория знаний,
2014. — 271 с. : ил. — (Проекты, программы, портфели).
ISBN 978-5-9963-2355-5
В этой книге руководитель PM Expert — одной из лидиру-
ющих российских консалтинговых компаний в сфере проект-
ного менеджмента — подробно излагает положения наиболее
известного американского стандарта по управлению проек-
тами. Автор рассматривает пятую, последнюю, редакцию
PMBOK○R . Помимо собственно изложения стандарта книга
содержит ценные авторские комментарии и рекомендации,
существенно дополняющие и обогащающие ее основное со-
держание. Кроме того, в издание включен русско-английский
глоссарий по проектному управлению.
Книга будет полезна руководителям проектов, топ-
менеджерам компаний, руководителям функциональных под-
разделений, студентам, аспирантам и преподавателям вузов
экономико-управленческого профиля.
УДК 65.0
ББК 65.290-2
По вопросам приобретения обращаться:

«БИНОМ. Лаборатория знаний»
Телефон: (499) 157-5272
e-mail: binom@Lbz.ru, http://www.Lbz.ru
ISBN 978-5-9963-2355-5 c БИНОМ. Лаборатория знаний, 2011

○
Посвящается моему сыну Николаю —
растущему руководителю проектов!
Предисловие
Успех любого бизнеса непосредственно связан с инновацион-

ной деятельностью. Только внедрение новейших разработок и
технологий может обеспечить темпы развития компаний, отве-
чающие условиям растущего рынка и усиления конкурентной
борьбы.
Проектная деятельность – это организация работ по созда-
нию за ограниченное время уникальных, инновационных ре-
шений, методов, технологий, продуктов и услуг. Нововведение,
или инновация, — результат успешной проектной деятельнос-
ти компании. Но сложность проектов непрерывно возрастает,
и руководителям проектов все труднее добиться успеха. Вла-
дельцы бизнеса, сталкивающиеся с необходимостью внедрения
инноваций и развития своих компаний, вынуждены идти на
существенные риски, связанные с запуском новых проектов,
и крайне заинтересованы в высокоэффективном и профессио-
нальном управлении проектами.
Эффективному управлению проектами посвящены исследо-
вания ряда профессиональных ассоциаций и международных
сообществ, которые разрабатывают международные и нацио-
нальные стандарты в управлении проектами. Специфика таких
стандартов заключается в том, что они содержат не обязатель-
ные для исполнения требования, а, скорее, рекомендации по
наиболее эффективному управлению проектами, основанные
на обобщении лучшего мирового опыта. Наиболее известными
международными стандартами в управлении проектами (УП)
являются:
x PMBOK® (стандарт Project Management Institute, Ин-
ститута управления проектами, штаб-квартира в США) –
4 Предисловие
свыше 400 000 практикующих и сертифицированных чле-

нов в более чем 130 странах мира, включая Россию. Этот
стандарт является лидирующим в области управления
проектами. На его основе созданы многие региональные и
международные стандарты УП;
x ICB (стандарт IPMA, Международной ассоциации по
управлению проектами, штаб-квартира в Нидерландах) –
более 100 000 практикующих и сертифицированных чле-
нов, в том числе в России;
x Prince 2 (Британский стандарт управления проектами,
штаб-квартира в Великобритании) – около 30 000 практи-
кующих и сертифицированных членов.
Собственные национальные стандарты разработаны и

существуют в России, Австралии (Австралийский институт по
управлению проектами — AIPM, около 5100 практикующих
членов), Великобритании (Ассоциация по управлению проек-
тами — APM, около 13 000 практикующих членов), ряде других
стран.
Согласно проведенным исследованиям1, внедрение мето-
дов и технологий УП на основе использования международных
стандартов позволяет:
x повысить общую производительность труда на 30–32%;
x увеличить возврат от вложений (ROI) в проекты на 28%;
x согласовать отдельные выполняемые проекты со стратеги-
ческими целями развития бизнеса и скоординировать их
между собой, опираясь на единые принципы управления.
В то же время ряд аналитических исследований, проведен-
ных за последние несколько лет крупными международными
исследовательскими компаниями2, показывают, что:
x лишь 16–28% проектов реализуются точно в срок и в рам-
ках установленного бюджета;
1 Pennypacker J. Justifying the value of project management. Havertown (PA):

Center of Business Practices, 2002.
2 Rubenstein D. Standish group report: There’s less development chaos today.
SD Times (Mar. 1, 2007). Режим доступа: http://www.sdtimes.com/article/
story-20070301-01.html.
Предисловие 5
x около 49% проектов имеют существенные отклонения от

плана и бюджета. При этом превышение бюджета может
составлять от 45 до 180%, а по срокам — от 60 до 200% от
запланированных;
x лишь в 61% проектов цель проекта остается неизменной
до его завершения;
x порядка 23% проектов не доводятся до завершения.
Основными причинами этого являются:

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

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

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

по управлению крупными технологическими программами и
проектами, а также опыта разработки стандартов и методичес-
ких рекомендаций, участия в международных и отечественных
конференциях и симпозиумах, чтения лекций и учебных кур-
сов в данной области. В отличие от многих других публика-
ций, посвященных данной теме, в книге не делается попыток
переосмыслить или сравнить общепризнанные методологии
и традиционные методы управления проектами. По мнению
автора, значительный интерес для большинства специалистов
представляет сегодня практический опыт, полученный в ходе
управления проектами на основе использования наиболее рас-
пространенного и признанного во всем мире стандарта ANSI
PMI PMBOK®.
Структура книги полностью соответствует структуре стан-
дарта ANSI PMI PMBOK® «A Guide to the project management
body of knowledge (PMBOK® Guide), 5th ed.», опубликованного
Институтом управления проектами в 2013 г.1
Основное содержание составляют рекомендации и описание
уроков, извлеченных автором при практическом использова-
нии стандарта PMI PMBOK® более 10 лет, начиная с выпуска
первой редакции стандарта в 1996 г.
В соответствии со структурой стандарта PMI PMBOK®
каждый из 47 процессов стандарта представлен как компонент
одной из пяти групп процессов:
1) инициации;
2) планирования;
3) исполнения;
4) мониторинга и контроля;
5) завершения
и одной из десяти областей знаний стандарта УП:
1) управление интеграцией проекта;
2) управление содержанием проекта;
3) управление временем (сроками) проекта;
4) управление стоимостью проекта;
1 A Guide to the project management body of knowledge (PMBOK® Guide).

5th ed. Newtown Square, Pennsylvania, 2013.
Предисловие 7
5) управление качеством проекта;

6) управление человеческими ресурсами;
7) управление коммуникациями проекта;
8) управление рисками проекта;
9) управление поставками проекта;
10) управление заинтересованными сторонами проекта.
Процессы, рекомендованные стандартом к использованию
в каждой области знаний и группе процессов, представлены в
табл. 1.1.
Нумерация областей знаний и процессов УП в табл. 1 соот-
ветствует их нумерации в стандарте ANSI PMI PMBOK® Guide
редакции 2013 г.
Десять глав книги посвящены авторской интерпретации де-
сяти областей знаний управления проектами в стандарте PMI
PMBOK®. В них изложены:
x значение десяти областей знаний стандарта как ключевых
компетенций руководителя проекта;
x последовательное описание всех процессов стандарта
PMBOK в каждой из деcяти областей знаний;
x рекомендации автора по практическому использованию
процессов;
x уроки, извлеченные автором в ходе осуществления про-
цессов в реальных проектах;
x бизнес-кейсы и проблемные ситуации, возникавшие в
крупных комплексных проектах с анализом принятых ре-
шений и их последствий.
В заключение книги даются выводы и итоговые рекомен-
дации автора по использованию стандарта PMI PMBOK® в
управлении комплексными проектами и программами.
1 Учебный курс. Управление проектом на основе стандарта PMI PMBOK®

GUIDE (2013) / PM Expert. M., 2013.
Таблица 1 8
Процессы УП согласно ANSI PMI PMBOK® GUIDE

Область Инициация Планирование Исполнение Мониторинг Завершение
знаний и контроль
4. Управление 4.1. Разработка 4.2. Разработка плана 4.3. Руководство и 4.4. Мониторинг и 4.6. Закрытие
интеграцией устава проекта управления проектом управление рабо контроль над рабо проекта или
тами проекта тами проекта его фазы
4.5 Общее управле
ние изменениями
5. Управление 5.1. Планирование управ 5.5. Подтверждение
содержанием ления содержанием содержания
5.2. Сбор требований 5.6. Контроль со
5.3. Определение содер держания
жания
5.4. Создание иерархичес
кой структуры работ
6. Управление 6.1. Планирование управ 6.7. Контроль рас
временем ления расписанием писания
6.2. Определение опера
ций
6.3. Определение после
довательности операций
6.4. Оценка ресурсов
операций
6.5. Оценка длительности
операций
6.6. Разработка расписа
ния
7. Управление 7.1. Планирование управ 7.4. Контроль стои
стоимостью ления стоимостью мости
7.2. Оценка стоимости
7.3. Определение бюд
жета
8. Управление 8.1. Планирование управ 8.2. Обеспечение 8.3. Контроль каче

качеством ления качеством качества ства
9. Управление 9.1. Планирование управ 9.2. Набор коман
человеческими ления человеческими ды проекта
ресурсами ресурсами 9.3. Развитие ко
манды проекта
9.4. Управление
командой проекта
10. Управление 10.1. Планирование управ 10.2. Управление 10.3. Контроль ком
коммуникаци ления коммуникациями коммуникациями муникаций
ями
9
Окончание табл. 1 10
Область Инициация Планирование Исполнение Мониторинг Завершение

знаний и контроль
11. Управление 11.1. Планирование управ 11.6. Контроль над
рисками ления рисками рисками
11.2. Идентификация
рисков
11.3. Качественный анализ
рисков
11.4. Количественный
анализ рисков
11.5. Планирование реаги
рования на риски
12. Управление 12.1. Планирование управ 12.2. Организация 12.3. Контроль по 12.4. Закры
поставками про ления поставками проведения по ставок тие поставок
екта ставок
13. Управление 13.1. Иденти 13.2. Планирование управ 13.3. Управление 13.4. Контроль
заинтересован фикация заин ления заинтересованными вовлеченностью вовлеченности
ными сторонами тересованных сторонами заинтересованных заинтересованных
сторон сторон сторон
Единственный урок, который можно
извлечь из истории, состоит
в том, что люди не извлекают из истории никаких уроков.
Фридрих Гегель
Те, кто не может запомнить прошлое,

обречены повторять его.
Джордж Сантаяна
ГЛАВА 1
Управление интеграцией проекта
Значение области знаний «Управление интеграцией проек-

та» в стандарте PMI PMBOK®. Владение данной областью
знаний стандарта представляет собой одну из десяти ключевых
компетенций руководителя проекта и предполагает умение ин-
тегрировать всевозможные планы, работы, ресурсы и результа-
ты проекта. Шесть процессов, рекомендованных стандартом в
данной области знаний, относятся к группам процессов ини-
циации, планирования, исполнения, мониторинга/контроля и
завершения проекта (табл. 2).
Таблица 2
Процессы и группы процессов в области знаний
«Управление интеграцией проекта»
Процесс Группа процессов
Разработка устава проекта Инициация
Разработка плана управления про Планирование
ектом
Руководство и управление работами Исполнение
проекта
Мониторинг и контроль над работа Мониторинг и контроль
ми проекта
Общее управление изменениями Мониторинг и контроль
Закрытие проекта или его фазы Завершение
Описания данных процессов и рекомендации автора по их

применению приводятся далее.
14 Глава 1
4.1. Область знаний:

управление интеграцией проекта
Группа процессов: инициация
Процесс: разработка устава проекта
В стандарте ANSI PMI PMBOK® GUIDE входы, инструмен-
ты/методы и выходы процесса описываются следующим обра-
зом (рис. 1).
Рис. 1. Процесс разработки устава проекта в группе процессов

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

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

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

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

компании данный документ становится основанием для при-
нятия решения о старте проекта (go-no-go decision making) и
одним из входов процесса разработки устава проекта.
Другим важным входом данного процесса является описа-
ние работ по проекту, которое включает:
x бизнес-потребности проекта;
x содержание продукта проекта;
x соответствие проекта стратегическому плану компании.
На вход процесса поступают также различные соглашения

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

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

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

устава проекта (lessons learned – LL)
x LL-4.1.1. Во внешних проектах автором устава может быть
продавец, подписавший контракт с заказчиком. Во внут-
ренних проектах автором устава может быть инициатор
проекта (например, руководитель функционального под-
разделения или топ-менеджер компании).
! Комментарий из практики. Конечно, топ-менеджер органи-

зации вряд ли будет разрабатывать устав проекта. Скорее всего,
это сделает потенциальный руководитель проекта (пока не назна-
ченный официально, потому что инициация проекта еще не про-
ведена). Но участие в этом процессе «носителя идеи» будущего
проекта очень желательно, так как авторство устава формально
принадлежит ему. Эффективным процессом разработки устава
может быть беседа или ряд встреч будущего руководителя проек-
та с топ-менеджером, в ходе которых необходимо наполнить ос-
новные разделы шаблона устава сведениями о будущем проекте.
Шаблон устава проекта может включать следующие разделы:
y обоснование проекта;
y измеримые цели и соответствующие им критерии успешнос-
ти проекта;
y высокоуровневые требования;
y допущения и ограничения;
y высокоуровневое описание проекта и его границы;
y основные риски проекта;
y сводное расписание контрольных событий;
y сводный бюджет;
y список заинтересованных лиц;
y требования к процедурам утверждения в проекте;
y назначение менеджера проекта с описанием уровня ответ-
ственности и полномочий;
18 Глава 1
y имя и полномочия спонсора проекта (или другого лица, ут-

вердившего устав проекта).
x LL-4.1.2. Устав проекта не должен быть объемным. Как

правило, устав не должен превышать двух-трех страниц
текста. Более подробное описание проекта будет разраба-
тываться на основе устава в процессе определения содер-
жания проекта.
x LL-4.1.3. Официальное назначение руководителя проек-
та отражается в тексте устава. Крайне желательно участие
будущего (потенциального) руководителя проекта в рабо-
тах на предпроектной стадии, на этапах подготовки ком-
мерческого предложения и контракта с заказчиком (для
внешних проектов) или проекта приказа руководителя
организации (для внутренних проектов). Принцип во-
влечения потенциального руководителя проекта в работы
предпроектной стадии (PM early involvement) позволяет
руководящему органу учесть опыт и мнение руководителя
проекта при принятии решения о старте проекта или отка-
зе от него, обеспечить готовность руководителя проекта к
незамедлительному началу работ по организации проекта
после его инициации.

Группа процессов: планирование
Процесс: разработка плана УП
зом (рис. 2).
Основные цели разработки плана УП:
x интеграция всевозможных планов (календарного плана-
графика, бюджетного плана, плана по управлению качест-
вом, коммуникациями, рисками, персоналом, поставками
и др.) в единый план УП;
Рис. 2. Разработка плана УП в группе процессов планирования
x обеспечение согласованности и непротиворечивости все-

возможных планов внутри плана УП;
x отражение в плане УП требований организации по выпол-
нению, мониторингу и закрытию работ проекта.
Интерпретация процесса разработки плана УП и реко-

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

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

гих процессов планирования».
20 Глава 1
План проекта подвержен постоянным изменениям в ходе

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

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

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

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

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

плана УП
x LL-4.2.1. Итерационный процесс разработки плана управ-
ления проектом, основанный на методе «бегущей волны»
(moving wave), желательно применять по завершении каж-
дой фазы (этапа) проекта. Полученные результаты влияют
на содержание последующих этапов проекта.
x LL-4.2.2. Интеграция всевозможных планов проекта в
единый план УП должна обеспечивать их согласованность
и непротиворечивость. Например, календарный план-
график проекта (schedule) учитывается в плане привлече-
ния человеческих ресурсов для обеспечения наличия спе-
циалистов к определенному времени и на определенные
периоды. А план контрольных точек проекта (milestone
chart) учитывается в плане управления коммуникациями
проекта для обеспечения спонсоров проекта отчетами о
статусе контрольных точек.
22 Глава 1

Группа процессов: исполнение
Процесс: руководство и управление работами проекта
зом (рис. 3).
Рис. 3. Процесс управления исполнением проекта в группе про

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

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

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

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

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

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

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

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

появляются на выходе. Как достижение, так и отсутствие (на-
пример, задержка в получении) плановых результатов проекта
обсуждаются на заседаниях команды проекта, на которых про-
исходит обмен экспертными оценками и активно используется
(в качестве инструмента данного процесса) информационная
система управления проектом (ИСУП).
Современные ИСУП, реализованные в виде разнообразных
программных продуктов (например, Microsoft EPM, Primavera,
PlanView, Clarity и др.), позволяют эффективно анализировать
исполнение плана проекта, в том числе выявлять отклонения
по срокам, стоимости работ, оптимизировать распределение
ограниченных ресурсов, вносить одобренные изменения, от-
слеживать статус работ и выполнять другие функции.
Информация об исполнении работ на выходе данного про-
цесса должна включать отчеты о проекте. Рекомендуется ис-
пользовать три вида отчетов:
1) отчет о статусе проекта (project status report);
2) отчет о продвижении проекта (project progress report);
3) отчет о прогнозе проекта (project trend report).
Отчет о статусе проекта отвечает на вопрос: каково состоя-
ние проекта на данный момент?
Отчет о продвижении проекта отвечает на вопрос: что было

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

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

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

исполнением проекта
x LL-4.3.1. При управлении исполнением небольших и сред-
них проектов от руководителя проекта требуется наличие
глубокой технической экспертизы и знаний технологий
создания продуктов (hard skills). С возрастанием сложнос-
ти и объемов работ по проекту (как правило, требуется ин-
теграция различных продуктов и технологий) возрастают
требования к лидерским качествам руководителя проекта
и искусству управления людьми и коммуникациями про-
екта (soft skills). В крупных проектах и программах руко-
водитель делегирует многие технические задачи на уровень
ниже (руководителям подпроектов, ведущим разработчи-
кам продуктов), сосредоточивая основное внимание на
стратегических вопросах, связанных с определением при-
оритетов и оптимальным распределением ограниченных
ресурсов.
x LL-4.3.2. В крупных проектах возрастает роль администра-

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

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

показателей прогноза от плановых показателей могут быть
отсутствие своевременных решений по существенным из-
менениям базового плана либо некорректное прохожде-
ние проверок успеха проекта (kill points) по завершении
фаз проекта.

Группа процессов: мониторинг и контроль
Процесс: мониторинг и контроль над работами проекта
В стандарте ANSI PMI PMBOK® GUIDE входы, инструменты/
методы и выходы процесса описываются следующим образом
(рис. 4).
28 Глава 1
Рис. 4. Процесс мониторинга и контроля над работами проекта в

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

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

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

блюдение за ходом работ проекта и анализ происходящего в со-
ответствии с планом управления проектом. Мониторинг – это
наблюдение за ходом работ проекта путем получения и анализа
отчетов об исполнении плана проекта. Контроль – это срав-
нение фактического состояния работ проекта с плановым со-
стоянием на определенный момент. В случае несоответствия
фактического состояния работ проекта запланированному воз-
никает отклонение факта от плана.
Основным инструментом данного процесса является обмен
экспертными оценками на регулярных периодических совеща-
ниях команды о статусе проекта (project status review meetings).
В ходе таких совещаний заслушиваются отчеты членов коман-
ды и сравниваются фактические данные о ходе выполнения
работ и их результатах с данными плана управления проектом.
Сравнение текущих результатов с плановыми показателями
часто приводит к необходимости корректирующих и преду-
преждающих действий, а также к исправлению ошибок.
Корректирующие действия могут быть связаны с измене-
ниями планов проекта.
Предупреждающие (или проактивные) действия могут
быть направлены на управление рисками проекта, потенциаль-
ными проблемами или возможными будущими изменениями.
Исправление ошибок (или реактивные) действия могут
быть направлены на исправление неудовлетворительных ре-
зультатов работ проекта (например, дефектов в характеристи-
ках продукта).
NB! Регулярные совещания о статусе проекта могут не

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

статусе проекта заслушиваются отчеты всех членов команды, под-
чиненных непосредственно руководителю проекта. Удобной схе-
мой анализа отчета является следующая последовательность:
30 Глава 1
y факт (что сделано фактически на дату отчета);

y эталон (что могло быть сделано наилучшим, эталонным об-
разом на дату отчета);
y дельта (отличия факта от эталона);
y причина существования дельты;
y план ликвидации дельты;
y дата следующего отчета.
Пример.
y Факт: освоено 80% объема работ проекта.
y Эталон: освоение 90% объема работ.
y Дельта: 10%.
y Причина существования дельты: недостаток ресурсов.
y План ликвидации дельты: выделение дополнительных ресур-
сов.
y Дата следующего отчета: следующее регулярное совещание о
статусе проекта.
Другим важным инструментом данного процесса являются все-
возможные аналитические методы, среди которых следует отме-
тить:
y анализ основных причин отклонений от плана проекта;
y методы прогнозирования;
y анализ резервов по срокам и стоимости проекта;
y анализ тенденций развития работ проекта;
y анализ дерева отказов (метод, который может использовать-
ся, чтобы определить цепь событий, приводящих к отказу или
ошибке);
y управление освоенным объемом (метод будет подробно рас-
смотрен в главе 4).
Основным выходом данного процесса являются запросы на

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

и контроля над работами проекта
x LL-4.4.1. Регулярные совещания о статусе проекта реко-

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

Процесс: общее управление изменениями
В стандарте ANSI PMI PMBOK® GUIDE входы, инструменты/
методы и выходы процесса описываются следующим образом
(рис. 5).
Основные цели общего управления изменениями:
x отражение возникающих изменений в планах проекта;
x отслеживание влияния изменений на различные области
проекта;
x обеспечение согласованности и непротиворечивости ме-
няющихся планов проекта.
Интерпретация процесса общего управления изменения-
ми и рекомендации по его применению на практике. Общее
управление изменениями – это процесс анализа всех запросов
на изменения, утверждения изменений и управления измене-
ниями, касающимися результатов проекта, активов организа-
32 Глава 1
Рис. 5. Процесс общего управления изменениями в группе про

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

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

интересованных сторон проекта, включая организационные и
производственные ограничения. Инструменты используются
для управления запросами на изменение и решениями, прини-
маемыми комитетом по управлению изменениями.
Журнал изменений используется для документирования из-
менений, которые происходят во время проекта. Эти измене-
ния и их влияние на проект с точки зрения времени, затрат и
риска должны быть доведены до сведения соответствующих за-
интересованных сторон.
Прежде всего следует отличать несущественные изменения
плана управления проектом от существенных. Несуществен-
ные изменения являются изменениями рабочего плана проек-
та, а существенные изменения — изменениями базового плана.
Базовый план (project baseline) — это официально утверж-
денный документ, относительно которого оценивается выпол-
нение проекта и который используется для управления и кон-
троля за исполнением проекта.
В базовый план следует включать три основных плана: пла-
ны по управлению содержанием, сроками и стоимостью проек-
та. Однако в зависимости от специфики содержания конкрет-
ного проекта в базовый план могут быть включены и другие
планы. Например, если в проекте значительная часть работ вы-
полняется внешними поставщиками, то, очевидно, в базовый
план — в качестве дополнительного к трем перечисленным
выше — войдет также план по управлению поставками.
Рабочий (текущий) план проекта — это документ или на-
бор документов, который изменяется по мере выполнения про-
екта и поступления дополнительной информации. Рабочий
план, как правило, всегда отличается от базового.
Руководитель проекта может вносить несущественные изме-
нения в рабочий план в пределах своих полномочий по исполь-
зованию резервов (времени, стоимости, других возможных ре-
сурсов проекта).
В случае возникновения существенных изменений, превы-
шающих резервы руководителя проекта, необходима эскалация
руководителем проекта запроса на изменение базового плана
34 Глава 1
проекта. Эскалация рассматривается на заседании комитета

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

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

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

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

Группа процессов: завершение
Процесс: закрытие проекта или его фазы
зом (рис. 6).
Основные цели закрытия проекта:
x координация работ, необходимых для приемки результатов
проекта;
x определение формальных процедур и документов, необхо-
димых для официального закрытия проекта;
x в случае досрочной остановки проекта — определение и
документирование причин досрочной остановки проекта.
Интерпретация процесса закрытия проекта и рекомен-

дации по его применению на практике. Данный процесс
должен официально подтвердить и оформить факт получения
результатов проекта заказчиком. Официальное подтверждение
получения результатов проекта может включать приемо-сда-
точные испытания конечного продукта и подписание актов пе-
редачи продукта в операционную деятельность заказчика.
36 Глава 1
Рис. 6. Процесс закрытия проекта в группе процессов заверше

ния
В процессе завершения проекта также проводятся:

x проверка и документирование основных результатов про-
екта;
x взаимодействие с заказчиком и/или спонсором проекта в
целях придания результатам проекта официального ста-
туса;
x определение и документирование причин досрочного за-
вершения проекта.
Аналогичный процесс позволяет корректно завершить этап
(или фазу) проекта путем оценки и измерения его промежу-
точных результатов проекта (project deliverables). Формальным
подтверждением получения удовлетворяющих заказчика про-
межуточных результатов также является подписание акта их
приемки.
NB! Руководитель проекта обязан пройти процедуру под

тверждения успешного завершения этапа (или фазы) про
екта до начала работ по следующему этапу проекта (kill
point or stage gate review).
При этом необходимо ориентироваться на три критерия
успешности этапа проекта:
1) не превышены ли сроки работ этапа;
2) не превышена ли стоимость работ этапа;
3) удовлетворяют ли заказчика полученные промежуточные
результаты?
Положительные ответы на данные вопросы означают успеш-
ное завершение этапа и позволяют руководителю проекта при-
ступить к следующему этапу работ. В случае негативного отве-
та на любой из данных вопросов руководитель проекта обязан
эскалировать данную ситуацию спонсору проекта, который
будет принимать решение о продолжении, замораживании или
остановке проекта.
В случае негативных результатов этапа решение спонсора о
продолжении проекта может быть связано со стратегической
важностью проекта (или заказчика) для организации – испол-
нителя проекта.
Решение спонсора о «замораживании» проекта может
быть связано, например, с необходимостью приостановки ра-
бот над проектом на время до перемещения на проект ресур-
сов, высвобождающихся из других проектов.
Решение спонсора об остановке проекта может быть свя-
зано с невозможностью продолжить работу над проектом из-за
существенных потерь времени, денег, качества на промежуточ-
ных этапах проекта. При этом должны быть документированы
причины закрытия проекта до его завершения.
! Комментарий из практики. В случае досрочного закрытия

проекта, кроме документирования причин выхода из проекта, не-
обходимо подробно описать достигнутые результаты (deliverables)
и статус проекта на момент закрытия или заморозки работ. Тогда
в случае возобновления («разморозки») проекта в будущем (project
restart) команда сможет продолжить выполнение работ с точки
«заморозки», а не с самого начала проекта.
38 Глава 1
Извлеченные уроки, или что показал опыт закрытия

проекта
x LL-4.6.1. Обязательным условием закрытия проекта яв-
ляется пополнение базы данных извлеченных уроков.
Желательно пополнять данную базу оперативно в ходе
выполнения работ по проекту и по мере накопления как
положительных, так и отрицательных уроков. Однако час-
то руководители проектов забывают, не успевают или не
хотят этим заниматься. Одна из обязанностей эксперта по
качеству (QA, или Quality Assurance Function) – удосто-
вериться в пополнении базы данных извлеченных уроков
при закрытии проекта.
x LL-4.6.2. Корректное закрытие проекта включает: про-
верку и документирование полученных результатов, офи-
циальную передачу продукта заказчику с подписанием
актов приемки-передачи, проверку получения полной
оплаты работ заказчиком, а также проведение оплаты ра-
бот субподрядчикам и поставщикам. Административное
закрытие контракта предполагает проверку выполнения
исполнителем всех обязательств в отношении заказчика,
зафиксированных в контракте, и отсутствие претензий со
стороны заказчика.
/ Бизнес*кейс: проект «Фондовая биржа»

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

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

ния – системный интегратор, заключил с заказчиком, крупной
фондовой биржей, контракт на выполнение проекта, включаю-
щего этапы:
x поставки оборудования для вычислительного комплекса и
сетевого оборудования, его монтажа и наладки;
x разработки прикладного программного обеспечения авто-
матизированной системы фондовой биржи;
x гарантийного обслуживания поставленного оборудова-
ния.
Заказчик должен был использовать систему для работы с
ценными бумагами в 24-часовом режиме реального времени.
В контракте и техническом задании было указано, что в случае
сбоя в работе системы и оборудования в период торгов убытки
заказчика могут составить несколько сот тысяч долларов в ми-
нуту. Поэтому система должна была демонстрировать абсолют-
ную надежность при эксплуатации 24u7 в период торгов.
В ходе завершения работ по монтажу и наладке оборудования
системы исполнитель неожиданно получил от заказчика офи-
циальный запрос на изменение сроков данного этапа. Заказчик
высказал просьбу завершить этап наладки и монтажа оборудова-
ния на три недели раньше установленного срока. Спонсор про-
екта со стороны исполнителя, принимая во внимание стратеги-
ческую важность заказчика, принял решение удовлетворить его
просьбу и отдал распоряжение руководителю проекта завершить
этап на три недели раньше первоначального срока.
Руководитель проекта высказал свои сомнения относи-
тельно изменения сроков проекта. Спешка на этапе монтажа
и наладки оборудования могла привести к потере качества и
появлению риска сбоев в работе системы. Поскольку потери
заказчика за минуту простоя в период торгов составляют сот-
ни тысяч долларов и требование надежности системы 24×7 от-
ражено в контракте и техническом задании, в случае сбоя за-
казчик будет вправе потребовать от исполнителя компенсации
материальных потерь, в том числе в судебном порядке.
Выслушав руководителя проекта, спонсор принял решение
о проведении дополнительных переговоров с целью выясне-
40 Глава 1
ния причины, побудившей заказчика сократить сроки проекта.

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

изменения должна быть предпринята руководителем проекта с
целью сохранения согласованных планов и избежания рисков,
возникающих при изменении планов. Позиция руководителя
проекта при этом консервативна – он стремится не менять пла-
нов проекта! Этим руководитель проекта отличается от дирек-
тора программы (или портфеля) проектов, который призван не
отказываться от изменений, а, скорее, принимать их – во имя
достижения бизнес-целей компании в условиях динамично ме-
няющегося рынка!
ГЛАВА 2
Управление содержанием
проекта
Значение области знаний «Управление содержанием про-

екта» в стандарте PMI PMBOK®. В данной области знаний
стандарта описана одна из десяти ключевых компетенций ру-
ководителя проекта, связанная с определением состава работ,
необходимых для успешной реализации проекта, и контролем
за их выполнением. Шесть процессов, рекомендованных стан-
дартом в данной области знаний, относятся к группам процес-
сов планирования, мониторинга и контроля проекта (табл. 3).
Таблица 3
Процессы и группы процессов в области знаний
«Управление содержанием проекта»
Планирование управления содержанием Планирование
Сбор требований Планирование
Определение содержания Планирование
Создание иерархической структуры работ Планирование
Подтверждение содержания Мониторинг и контроль
Контроль содержания Мониторинг и контроль
Описание данных процессов и рекомендации автора по их

применению изложены ниже.
42 Глава 2

управление содержанием проекта
Процесс: планирование управления содержанием
В стандарте ANSI PMI PMBOK GUIDE® входы, инструмен-
зом (рис. 7).
Рис. 7. Процесс планирования управления содержанием в груп

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

x определение принципов и процедур определения, разра-
ботки, отслеживания и проверки содержания проекта;
x определение принципов и процедур анализа, приоритеза-
ции, учета, отслеживания и отчетности о состоянии удов-
летворения требований участников проекта к проведению
работ и результатам проекта.
Управление содержанием проекта 43
Интерпретация процесса планирования управления со-

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

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

Процесс: сбор требований
В стандарте ANSI PMI PMBOK GUIDE® входы, инструмен-
зом (рис. 8).
Рис. 8. Процесс сбора требований в группе процессов планиро

вания
46 Глава 2
Основные цели сбора требований:

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

дации по его применению на практике. Данный процесс
должен обеспечить полное и подробное описание требований
основных стейкхолдеров проекта к проведению работ и резуль-
татам проекта. Стейкхолдеры (project stakeholders) — это лица
или организации, участвующие в проекте. Их интересы могут
быть затронуты проектом: они могут как выиграть, так и по-
страдать.
NB! Следует отличать данный процесс сбора требований

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

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

требований, не закреплены в формальных документах и могут
отражать:
x ожидания конечных пользователей продуктов или резуль-
татов проекта (end-user expectations);
x ожидания заказчика, связанные с использованием резуль-
татов проекта, подразумеваемые им, но неизвестные ис-
полнителю (customer expectations).
! Комментарий из практики. Анализ ожиданий конечных

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

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

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

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

требованиями
x LL-5.2.1. Результаты сбора и анализа требований конечных
пользователей продукта могут привести к обсуждению с
представителями заказчика значительных изменений и до-
бавлений к характеристикам разрабатываемого в проекте
продукта. Это может быть связано с большим удобством
эксплуатации продукта в операционной деятельности.
Принятие таких изменений и дополнений представителя-
ми заказчика может стать причиной подписания дополни-
тельного соглашения к заключенному контракту.
50 Глава 2
x LL-5.2.2. Неточные или недостаточно обоснованные фор-

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

Процесс: определение содержания
В стандарте ANSI PMI PMBOK GUIDE ® входы, инструмен-
зом (рис. 9).
Рис. 9. Процесс определения содержания в группе процессов

планирования
Основные цели определения содержания:

x описание содержания проекта на основе исходной инфор-
мации, изложенной в уставе и требованиях участников
проекта;
x документирование границ содержания проекта (out of
scope);
x описание промежуточных результатов (deliverables) работ
проекта;
x описание основных характеристик продукта (features),
подлежащих разработке в ходе выполнения работ проекта;
x описание критериев приемки продукта.
Интерпретация процесса определения содержания и

рекомендации по его применению на практике. Данный
процесс должен обеспечить полное и детальное описание
работ проекта и их результатов. Такое полное и подробное
описание должно быть представлено в документе «Описание
содержания проекта» (project scope statement), являющемся
выходом данного процесса. Организация данного процесса
руководителем проекта требует детального анализа характе-
ристик продукта и альтернативных путей его разработки, об-
мена экспертными оценками и проведения вспомогательных
семинаров и совещаний. Ключевым является совещание по
определению содержания проекта (project kick-off meeting).
Его необходимо проводить для обсуждения содержания про-
екта с ключевыми стейкхолдерами и согласования общего
понимания целей, задач, ресурсов, ограничений и предполо-
жений проекта. Согласованный и формально утвержденный
протокол совещания является основой для разработки доку-
мента «Описание содержания проекта».
Стандарт рекомендует детально проработать шесть разделов
данного документа.
1. Описание содержания продукта.
2. Критерии приемки продукта.
3. Результаты проекта.
4. Границы (или исключения) проекта.
5. Ограничения проекта.
6. Допущения проекта.
52 Глава 2
NB! Основными целями совещания по определению со

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

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

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

фликтующих целей стейкхолдеров проекта представлен в дру-
гой работе автора1.
NB! Одной из причин разногласий стейкхолдеров часто яв
ляется отсутствие общего понимания того, что входит в со
держание работ по проекту и характеристики продукта, а
что — нет.
1 Павлов А. Н. Управление конфликтующими целями стейкхолдеров проек-

та / Управление проектами. 2005. № 3–4.
То, что входит в содержание работ проекта и характеристики

продукта (in scope), должно быть описано в первых трех разде-
лах описания содержания проекта.
1. Описание содержания продукта.
2. Критерии приемки продукта.
3. Результаты проекта.
То, что не входит в содержание работ проекта и характери-
стики продукта (out of scope), должно быть описано в разделе 4
описания содержания проекта.
4. Границы (или исключения) проекта.
Четвертый раздел должен описывать работы и результаты,
которые не будут выполнены и получены по различным причи-
нам (например, ввиду отсутствия у исполнителя или заказчи-
ка необходимых ресурсов, высокого риска в проведении работ,
недостаточного финансирования и т.п.).
При анализе разделов описания содержания проекта, по-
священных описанию ограничений и допущений, важно про-
вести обмен мнениями с поставщиками и субподрядчиками
проекта, так как активы организационных процессов этих
внешних стейкхолдеров могут быть неизвестны руководителю
проекта.
! Комментарий из практики. Раздел описания содержания

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

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

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

содержания проекта
x LL- 5.3.1. При фиксации границ мы указываем, что не вхо-
дит в содержание проекта. Формальные требования, как
правило, отражены в результатах работ и спецификациях
продукта.
x LL-5.3.2. Анализ выявленных ожиданий конечных поль-
зователей позволяет также уточнить границы проекта и
исключить из описания содержания проекта ошибочные,
завышенные ожидания заказчика и конечных пользова-
телей. Техники выявления и анализа ожиданий конеч-
ных пользователей основаны на интервью, опросах пред-
ставителей заказчиков, изучении требований заказчика
(customer requirements study), проведении неформальных
встреч с конечными пользователями продукта проекта.
x LL-5.3.3. Чтобы избежать эффекта «расползания содержа-
ния», необходимо жестко фиксировать границы содержа-
ния и строго соблюдать процедуры управления существен-
ными изменениями в базовом плане содержания проекта.

Процесс: создание иерархической структуры работ (ИСР)
зом (рис. 10).
Рис. 10. Процесс создания иерархической структуры работ в

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

бот:
x проведение декомпозиции целей и работ проекта и созда-
ние древовидной ИСР, описывающей полное содержание
проекта в заранее определенных рамках (in scope);
x формирование на нижнем уровне ИСР пакетов работ, вы-
полняемых в среднем за 80 рабочих часов (т. е. за две ра-
бочие недели).
56 Глава 2
Интерпретация процесса создания иерархической струк-

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

мелкие управляемые компоненты подразумевает выделе
ние на следующем, более низком уровне ИСР как минимум
двух работ, а как правило — более чем двух. Поэтому не
корректно представлять на следующем уровне ИСР только
одну работу (увы, такую некорректность мы часто видим на
практике!).
При использовании метода декомпозиции удобно опираться

на «принцип базиса» (термин предложен автором).
«Принцип базиса» заключается в соблюдении при исполь-
зовании метода декомпозиции для создания ИСР следующих
условий:
x число работ на каждом уровне ИСР является конечным;
x среди работ на каждом уровне ИСР нет повторений (дуб-
лей);
x выполнение всех работ на каждом уровне ИСР безусловно
обеспечивает выполнение работы более высокого уровня.
Рекомендуется завершать декомпозицию работ проекта на
уровне пакетов работ, выполняемых в течение 80 рабочих
часов (или двух рабочих недель). Данная рекомендация не слу-
чайна. В дальнейшем внутри пакетов работ будут определены
операции проекта, т. е. работы, которые выполняются менее
чем за 80 ч. Операции, или самые мелкие работы проекта, мо-
гут выполняться в течение нескольких дней, часов или минут.
Именно на уровне операций в дальнейшем должна проводить-
ся детальная оценка требуемых ресурсов.
NB! Если прекращать декомпозицию и построение ИСР на

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

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

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

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

ИСР используется в качестве входа во многих процессах стан-
дарта PMBOK. На основе ИСР разрабатывается расписание
проекта, оценивается стоимость, определяются риски, рас-
пределяется ответственность и др. Поэтому в любом проекте
важно уделить достаточное время на тщательную и детальную
разработку ИСР. При этом в разработке ИСР на основе деком-
позиции участвует вся команда проекта, так как в этом про-
цессе важны обмен экспертными оценками и палитра мнений
членов команды.
В аббревиатуре названия «иерархическая структура работ»,
или ИСР, важна буква «Р» (или буква «W» в аналогичной аб-
бревиатуре WBS, или Work Breakdown Structure). Наличие слова
«работы» определяет необходимость наличия в ИСР процессов,
требующих определенных ресурсов и определенного времени,
а не фактических результатов процессов. Например, наличие
в ИСР работ, связанных с разработкой технического задания
(ТЗ), корректно, а наличие результата данного процесса, т. е.
самого ТЗ, — нет. Поэтому некорректно включать в ИСР не ра-
58 Глава 2
боты, а результаты работ. Результаты работ определяются при

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

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

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

ИСР
x LL-5.4.1. При проведении разбиения (декомпозиции) ра-
бот следует стремиться к соблюдению «принципа базиса»:
набор работ, образуемых при декомпозиции вышестоящей
работы, должен обеспечивать ее выполнение.
x LL-5.4.2. В ИСР нет сроков работ! Сроки выполнения ра-
бот (длительность, даты старта и финиша) будут определе-
ны при разработке расписания проекта с использованием
ИСР.
x LL-5.4.3. Рекомендация о длительности пакетов работ
ИСР (80 ч) — единственный параметр времени, который
используется при создании ИСР.
x LL-5.4.4. При создании ИСР главное — обеспечить полно-
ту описания содержания работ проекта, не забыть какие-
либо из ветвей ИСР или работы внутри ветвей.
x LL-5.4.5. ИСР всегда является строгой древовидной струк-
турой, в которой запрещены горизонтальные связи между
вершинами и петли (циклы). Только после дальнейшей
декомпозиции пакетов работ и определения состава опе-
раций внутри пакетов — на нижнем уровне ИСР — между
операциями устанавливаются более сложные логические
зависимости, и древовидная структура ИСР преобразовы-
вается в сетевую.
x LL-5.4.6. В ИСР должны быть включены работы по управ-
лению проектом.
60 Глава 2

Процесс: подтверждение содержания
Рис. 11. Процесс подтверждения содержания в группе процес

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

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

и рекомендации по его применению на практике. Данный
процесс должен обеспечить приемку результатов и работ про-
екта участниками проекта (заказчиками, спонсорами) и подпи-
сание актов приемки работ.
Основным инструментом проверки содержания являются
инспекции, в ходе которых полученные и подтвержденные ре-
зультаты должны быть сопоставлены с планом проекта и доку-
ментированными требованиями участников проекта.
Инспекции — операции измерения, обследования и под-
тверждения, позволяющие определить, соответствуют ли рабо-
ты и результаты требованиям и критериям приемки продукта.
Инспекции выполняются во время исполнения проекта и ино-
гда называются проверками, проверками продукта, аудитами
или сквозным контролем.
Методы гуппового принятия решений — групповые твор-
ческие методы, среди которых следует отметить:
x мозговой штурм — генерация и сбор разнообразных идей,
связанных с требованиями к проекту и продукту;
x метод номинальных групп — к мозговому штурму добав-
ляется процесс голосования для ранжирования или рас-
становки приоритетов наиболее полезных идей;
x метод Дельфи — анонимное анкетирование выбранной
группы экспертов по обозначенным вопросам (пробле-
мам). Доступ к ответам для анализа имеет лишь коорди-
натор;
x составление интеллект-карт — объединение идей, воз-
никших во время мозгового штурма, с целью отражения
сходства и различия в понимании формирования новых
идей;
x диаграммы сходства — сортировка по группам полученных
идей для их обзора и анализа.
На выходе процесса возникают официально принятые
результаты проекта либо запросы на изменение, требующие
переработки и изменений полученных результатов, как не со-
ответствующих плану проекта и/или не удовлетворяющих до-
кументированным требованиям участников проекта.
62 Глава 2
NB! При досрочном завершении проекта необходимо до

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

ния содержания работ
x LL-5.5.1. В процессе подтверждения содержания полезным
документом является словарь ИСР, в котором должно быть
подробно отражено содержание работ проекта и их детали.
x LL-5.5.2. Контроль качества результатов проекта необхо-
димо проводить до проверки содержания.

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

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

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

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

в содержании проекта необходимо выполнить следующие шаги.
1. Определить источник, создающий отклонения в содержании
проекта.
2. Оценить производимое отклонениями влияние на проект.
3. Инициировать запрос на изменения содержания в случае по-
зитивного влияния отклонения.
4. Попытаться исключить источник отклонения в случае нега-
тивного влияния отклонения.
5. Инициировать запрос на изменение содержания в случае без-
успешной попытки исключения источника негативного вли-
яния отклонения.
Рассмотрим для примера ситуацию с позитивным влиянием от-
клонения.
y Определить источник, создающий отклонения в содержании
проекта.
Источник — изменение конфигурации проектируемой инфор-
мационной системы. Это изменение позволяет осуществить по-
ставку более дешевых компонентов системы.
y Оценить производимое отклонениями влияние на проект.
Влияние — позитивное, экономия бюджета проекта.
y Инициировать запрос на изменения содержания в случае по-
зитивного влияния отклонения.
Инициация запроса на изменение содержания проекта, плана
работ по поставкам компонентов системы и стоимостного плана
проекта.
Теперь рассмотрим ситуацию с негативным влиянием отклоне-
ния.
y Определить источник, создающий отклонения в содержании
проекта.
Источник — изменение конфигурации проектируемой инфор-

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

держания
x LL-5.6.1. В процессе контроля содержания полезным до-
кументом является словарь ИСР, в котором должно быть
подробно описано содержание работ проекта и дано тол-
кование их деталей.
x LL-5.6.2. Изменения, возникающие в содержании проек-
та, являются существенными и, как правило, влекут за со-
бой корректировку многих планов проекта (календарного
плана-графика, базового стоимостного плана, планов по
управлению качеством, поставками, персоналом, комму-
никациями и др.). В проведении таких корректировок мы
можем что-то не учесть, забыть, упустить. Поэтому серьез-
ные изменения содержания в ходе выполнения проекта
несут в себе потенциальные риски и крайне нежелательны.
Первым импульсом при возникновении таких изменений
должна быть попытка «погасить» источник изменений со-
держания. Если такая попытка оказывается успешной, то
содержание проекта остается неизменным и никаких но-
вых рисков не возникает.
x LL-5.6.3. Если «погасить» источник изменения содержания
невозможно, то содержание придется менять, используя
66 Глава 2
принцип интегрированного управления изменениями со-

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

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

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

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

стандарте PMI PMBOK®. В данной области знаний стан-
дарта описана одна из десяти ключевых компетенций руково-
дителя проекта по управлению временем, выделенным на вы-
полнение работ проекта, и завершение проекта в установлен-
ные сроки. Семь процессов, рекомендованных стандартом в
данной области знаний, относятся к группам процессов плани-
рования, мониторинга и контроля проекта (табл. 4).
Таблица 4
Процессы и группы процессов области знаний
«Управление сроками проекта»
Планирование управления расписанием Планирование
Определение операций Планирование
Определение последовательности операций Планирование
Оценка ресурсов операций Планирование
Оценка длительности операций Планирование
Разработка расписания Планирование
Контроль расписания Мониторинг и контроль

применению изложены далее.
Управление сроками проекта 69

управление сроками проекта
Процесс: планирование управления расписанием
Рис. 13. Процесс планирования управления расписанием в груп

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

x разработка правил, процедур и документации для плани-
рования, разработки, управления, исполнения и контроля
расписания проекта;
x обеспечение документирования процессов управления
расписанием и связанных с ними инструментов и мето-
дов.
70 Глава 3
Интерпретация процесса планирования управления

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

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

ния управления расписанием
x LL-6.1.1. В модели поддержки расписания необходимо
описать процедуры обновления расписания, учитываю-
щие принципы делегирования полномочий по обновле-
нию расписания при внесении в него рабочих (несуще-
ственных) изменений и существенных изменений базового
расписания проекта. Внесение рабочих изменений может
быть делегировано администратору проекта. Существен-
ные изменения должны быть эскалированы руководителю
проекта для принятия решений по изменениям на уровне
спонсора или комитета по управлению изменениями про-
екта.
x LL-6.1.2. Контрольные пороги в плане управления рас-
писанием могут информировать руководителя проекта об
использовании и остатках временных резервов расписа-
ния. Например, при резерве расписания в размере 10% от
72 Глава 3
общего срока проекта инструмент разработки расписания

может автоматически генерировать уведомление руково-
дителю проекта о достижении контрольного порога в 8%
резерва и остатке резерва в 2%.

Процесс: определение операций
Рис. 14. Процесс определения операций в группе процессов

Основные цели определения операций:

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

мендации по его применению на практике. Данный процесс
должен обеспечить полное и подробное описание операций
внутри каждого из пакетов работ на нижнем уровне ИСР.
При декомпозиции пакетов на операции (самые мелкие ра-
боты внутри пакетов) используется тот же метод декомпози-
ции, что и при построении ИСР. При этом следует использо-
вать «принцип базиса», который должен обеспечить соблюде-
ние трех условий:
1) число операций внутри каждого пакета является конеч-
ным;
2) среди операций внутри пакета нет повторений (дублей);
3) выполнение всех операций пакета безусловно обеспечи-
вает выполнение всего пакета.
Среди операций пакета следует определять контрольные со-
бытия, или вехи (milestones), свидетельствующие о достижении
значимых результатов пакета (deliverables).
NB! В каждом пакете следует определять финальное кон

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

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

операций
x LL-6.2.1. Состав операций, или элементарных работ про-
екта, определяемый при декомпозиции пакетов работ
ИСР, должен быть конечным, исключать дубли (повторе-
ние операций) и должен быть достаточным для выполне-
ния пакетов работ.
x LL-6.2.2. Контрольными событиями следует обозначать
операции, связанные с наиболее значимыми, существен-
ными результатами работ проекта.

Процесс: определение последовательности операций
Основные цели определения последовательности опера-
ций:
x определение логических взаимосвязей между операция-
ми и построение сетевой диаграммы расписания проекта
(project schedule network diagram);
x обновление списка плановых операций внутри пакетов ра-
бот и их параметров.
Интерпретация процесса определения последовательнос-

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

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

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

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

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

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

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

Процесс: оценка ресурсов операций
Основные цели оценки ресурсов операций:
x определение объемных (количественных) и качественных
характеристик ресурсов плановых операций (человечес-
ких, материальных, технологических и др.);
x определение доступности ресурсов к определенному вре-
мени и на определенные периоды – для выполнения пла-
новых операций.
Интерпретация процесса оценки ресурсов операций и

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

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

При оценке ресурсов каждой операции следует последова-

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

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

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

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

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

Процесс: оценка длительности операций
Рис. 17. Процесс оценки длительности операций в группе про

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

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

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

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

операций проекта, рекомендованные стандартом, которые по-
лезно применять в различных ситуациях.
1. Экспертные оценки, применяемые в случае отсутствия у
членов команды проекта опыта в выполнении подобных
операций.
NB! При анонимном итерационном опросе экспертов по

методу Дельфи необходимо обеспечить статистическую
82 Глава 3
значимость результатов за счет опроса достаточно боль

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

добной операции в прошлых проектах. Данная оценка яв-
ляется грубой, неточной и часто используется в тех случаях,
когда у команды просто нет времени для проведения более
точной оценки.
3. Параметрическая оценка, применяемая для расчета дли-
тельности рутинных операций, использующих однотипные
ресурсы. Например, если при ремонте офиса необходи-
мо настелить паркет в помещении площадью 100 кв. м, и
паркетчики кладут один квадратный метр паркета за один
час, то параметрическая оценка длительности операции по
укладке паркета во всем помещении составит 100 ч.
4. Оценка по трем точкам, или оценка PERT, применяемая для
оценки сложных комплексных операций и проектов и тре-
бующая опроса большого количества экспертов, каждый из
которых дает три оценки длительности — оптимистичную
(О), пессимистичную (Р) и наиболее вероятную (М). Расчет
оценки по трем точкам проводится по формуле, в которой
используются усредненные оценки экспертов:
Оценка PERT = (P + 4M + O) / 6.
NB! Оценка по трем точкам является более осторожной и

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

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

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

онным, т. е. повторяется с уточнением несколько раз на раз-
ных этапах проработки проекта. За несколько итераций можно
повысить точность оценки длительности операций в течение
жизненного цикла проекта.
Извлеченные уроки, или что показал опыт оценки дли-
тельности операций
x LL-6.5.1. Неверные оценки длительности дорогостоящих
операций приводят к перерасходу бюджета проекта. По-
этому иногда выгоднее потратить некоторую сумму из
бюджета и заплатить внешнему эксперту для получения
экспертной оценки длительности, чем потерять большие
средства из-за неверной оценки длительности.
x LL-6.5.2. Анализ временных резервов операций проводит-
ся на основе анализа рисков срыва сроков операций. При
отсутствии подобных оценок, когда риск задержек испол-
нения и завершения операций неясен, рекомендуемая ве-
личина резерва составляет 10% от плановой длительности
операции.

Процесс: разработка расписания
84 Глава 3
Рис. 18. Процесс разработки расписания в группе процессов

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

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

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

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

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

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

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

кий путь может меняться и в расписании могут появляться но-
вые критические пути.
Насущной потребностью при работе с расписанием проекта
является сокращение сроков работ проекта! Такая потребность
часто возникает по различным причинам:
x по требованию заказчиков;
x по требованию спонсоров проекта;
x в связи с необходимостью выполнить определенные рабо-
ты или проекты быстрее конкурентов;
x в связи с желанием успеть осуществить поставки в более
сжатые сроки по действующим ценам.
Стандарт рекомендует два основных метода сокращения
сроков проекта:
1) «сжатие» (crashing) — привлечение дополнительных ре-
сурсов для выполнения критических работ, приводящее к
сокращению их длительности и длительности проекта в
целом;
2) быстрый проход (fast tracking) — распараллеливание ра-
бот, лежащих на критическом пути, приводящее к сокра-
щению критического пути проекта.
Другой насущной потребностью при разработке расписа-
ния является выравнивание ресурсов проекта. Необходимость
в выравнивании ресурсов часто возникает при появлении тре-
бований функциональных руководителей разделить время, от-
веденное на участие специалистов в проекте, и время, отведен-
ное на их участие в операционной деятельности подразделения.
Выравнивание ресурсов, как правило, приводит к увеличению
длительности работ и общей продолжительности проекта.
Различные графические представления расписания удобны
для различных стейкхолдеров проекта.
Сетевая диаграмма содержит массу сведений и деталей об
операциях (название, порядковый номер, сроки старта и фи-
ниша, длительность, ресурсное обеспечение) и удобна для де-
тальной работы с расписанием команды проекта.
Диаграмма Ганта является наглядной формой, включа-
ющей ИСР (в левой колонке) и сетевую диаграмму (в правой
колонке). Представляет операции проекта в виде взаимосвя-
занных сегментов и контрольные точки в определенной шкале

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

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

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

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

с фактическим началом и окончанием выполнения работ для
определения, произошло ли отклонение. Базовый план по рас-
писанию — это компонент плана управления проектом.
Расписание проекта представляет связанные операции с
запланированными датами, длительностями, вехами и ресур-
сами. Расписание проекта включает как минимум запланиро-
ванные даты начала и даты окончания для каждой операции.
Если планирование ресурсов производится на ранней стадии,
то разработанное расписание проекта остается предваритель-
ным до тех пор, пока назначения ресурсов не подтверждаются
и не устанавливаются запланированные даты начала и оконча-
ния. Этот процесс обычно происходит не позднее завершения
планирования управления проектом.
Данные для модели расписания проекта содержат собран-
ную информацию для описания и контроля расписания. Дан-
ные о расписании включают, по меньшей мере, расписание
вех, расписание операций, атрибуты операций и документа-
цию всех известных предположений и ограничений.
Дополнительные данные о расписании содержат такие све-
дения, как:
x потребности в ресурсах на период, часто в виде гистограм-
мы ресурсов;
x альтернативные календарные планы, такие как оптимис-
тичные или пессимистичные, с выровненными и невыров-
ненными ресурсами либо с предопределенными датами
или без них;
x расписание на случай чрезвычайных ситуаций.
Календари проекта содержат сведения о рабочих днях и пе-
реносах рабочих дней, которые могут быть использованы для
привлечения ресурсов и выполнения запланированных опера-
ций. Модель расписания может использовать более одного ка-
лендаря проекта для планирования некоторых видов деятель-
ности в разные периоды.
расписания:
x LL-6.6.1. Желательно провести выравнивание человечес-
ких ресурсов (human resource leveling) до окончательного
утверждения расписания. При этом, по возможности, сле-

дует предусмотреть равномерную загрузку ресурсов в тече-
ние определенных интервалов времени: полную загрузку
(full time) или частичную (part time). В противном случае
при неровной, «рваной» загрузке возникают риски недо-
ступности ресурсов или переработок (overtime).
x LL-6.6.2. Сжатие времени проекта путем привлечения
дополнительных ресурсов производится путем выбора
самой дешевой работы на критическом пути проекта и
добавления на эту работу дополнительных ресурсов. Так
как работа получает дополнительные ресурсы, она вы-
полняется быстрее, и сроки всего проекта сокращают-
ся, потому что выбранная работа лежит на критическом
пути. В связи с этим «сжатие» приводит к сокращению
сроков проекта ценой дополнительных, но минимальных
издержек, поэтому мы выбираем самую дешевую работу
на критическом пути.
x LL-6.6.3. Сжатие времени проекта путем распараллелива-
ния работ (fast tracking), как правило, приводит к появле-
нию дополнительных рисков и поэтому обязательно тре-
бует пересмотра реестра рисков и методов реагирования.
6.7. Область знаний: управление сроками проекта

Процесс: контроль расписания
Основные цели контроля расписания проекта:
x управление отклонениями, возникающими в расписании
в связи с меняющимися длительностями, сроками, ресур-
сами и зависимостями работ;
x выявление и оценка факторов, создающих отклонения в
расписании, и попытка влияния на них с целью сохране-
ния первоначального расписания проекта.
90 Глава 3
Рис. 19. Процесс контроля расписания в группе процессов пла

нирования
Интерпретация процесса контроля расписания проекта

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

x определение текущего статуса расписания проекта;
x оказание влияния на факторы, которые могут привести к
изменениям в расписании;
x выявление фактов изменения расписания проекта;
x управление изменениями при их возникновении.
Ключевым инструментом в данном процессе является ана-
лиз исполнения проекта, включающий анализ отклонений и
анализ возможных сценариев изменения расписания.
Анализ отклонений подразумевает анализ источника от-
клонения в целях его исключения (при негативном влиянии
отклонения) или максимального использования (при позитив-
ном влиянии отклонения).
Анализ возможных сценариев изменения расписания под-
разумевает разработку и анализ нескольких вариантов распи-
сания при выборе различных решений по управлению откло-
нениями расписания:
x включения отклонения в расписание проекта;
x отказа от включения отклонения.
Включение существенного отклонения в расписание проек-
та может быть проведено после подготовки и утверждения за-
проса на изменение базового плана по расписанию, что приво-
дит, как правило, к корректировке многих планов проекта и к
обновлению плана управления проектом.
NB! Большое количество отклонений в расписании проек
та приводит к необходимости частого пересмотра всевоз
можных планов, входящих в план управления проектом, и
появлению рисков, связанных с потерей их согласован
ности.
Извлеченные уроки, или что показал опыт контроля
расписания
x LL-6.7.1. В регулярных отчетах о продвижении проекта
(progress reporting) необходимо представлять комментарии
о причинах отклонений в сроках работ и давать рекомен-
дации по корректировке расписания. Такие комментарии
упреждают, а часто и исключают, встречные вопросы за-
казчика и/или спонсора проекта.
92 Глава 3
x LL-6.7.2. В процессе принятия решений по управлению

расписанием полезно располагать сведениями о прошлом
(плановые и фактические сроки работ) и будущем (плано-
вые и прогнозные сроки работ).
Бизнес*кейс: проект «Строительство

/ торгово*развлекательного центра»
Проблемная ситуация. Управление временем проекта явля-
ется важнейшей компетенцией руководителя проекта. Срыв
сроков проекта приводит к задержке внедрения продукта в
операционную деятельность компании-заказчика и удорожа-
нию работ проекта при возрастании сроков работ. Увеличение
длительности проекта и сдвиг сроков его завершения приводят
также к потерянным выгодам владельцев бизнеса, увеличивают
сроки окупаемости проекта (breakeven point delay) и возврата
инвестиций. Возрастающая конкуренция часто приводит к не-
обходимости сокращения сроков проекта. Заказчики и спонсо-
ры требуют завершить проект быстрее. Однако в ряде случаев
сокращение сроков приводит к потерям выгоды при эксплуата-
ции продукта.
Описание бизнес-кейса. Компания-девелопер занималась

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

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

проекта может привести к обратному эффекту — увеличению
сроков и удорожанию работ! Распараллеливание работ часто
приводит к возникновению дополнительных рисков, перерас-
тающих в значительные проблемы.
ГЛАВА 4
Управление стоимостью проекта
Значение области знаний «Управление стоимостью проек-

та» в стандарте PMI PMBOK®. В данной области стандарта
описана одна из десяти ключевых компетенций руководителя
проекта по управлению работами проекта в рамках выделенно-
го бюджета. Четыре процесса, рекомендованных стандартом в
данной области знаний, относятся к группам процессов плани-
рования, мониторинга и контроля проекта (табл. 5).
Таблица 5
«Управление стоимостью проекта»
Планирование управления стоимостью Планирование
Оценка стоимости Планирование
Определение бюджета Планирование
Контроль стоимости Мониторинг и контроль


управление стоимостью проекта
Процесс: планирование управления стоимостью
Управление стоимостью проекта 95
Рис. 20. Процесс планирования управления стоимостью в груп

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

проекта:
x определение политики и процедур для планирования, управ-
ления, исполнения и контроля за расходами по проекту;
x определение процессов документирования управления
стоимостью и связанных с ними инструментов и методов.
Интерпретация процесса планирования управления сто-

имостью и рекомендации по его применению на практике.
Данный процесс позволяет команде проекта ответить на воп-
рос: как будет осуществляться планирование, управление,
исполнение и контроль за всеми расходами по проекту? Испол-
нение данного процесса позволит команде проекта гаранти-
ровать заказчику и спонсору проекта детальное документиро-
вание процессов управления стоимостью и связанных с ними
инструментов и методов. Процессы управления стоимостью и
связанные с ними инструменты и методы описываются в плане
управления стоимостью.
96 Глава 4
Инструментами данного процесса являются экспертные

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

екта являются:
x уровень точности. Смета расходов на работы проекта может
придерживаться округления данных до предписанной точ-
ности (100 долл. США, 1000 долл. США), основанной на
сфере деятельности и масштабе проекта, и может включать
в себя сумму на случай непредвиденных обстоятельств;
x единицы измерения. Для каждого из ресурсов работ про-
екта определяется единица измерения (например, рабо-
чего времени персонала, рабочих дней, недель или общая
сумма без дифференциации составляющих);
x ссылки на процедуры организации. ИСР проекта опреде-
ляет рамки для плана управления расходами, обеспечи-
вая согласованность с оценками, бюджетом и контролем
над расходами. Компонент ИСР, используемый для уче-
та затрат проекта, называется учетной записью (control
account — CA). Каждой учетной записи элемента присва-
ивается уникальный код или номер счета, который связы-
вается непосредственно с системой бухгалтерского учета
исполняющей организации;
x контрольные пороговые значения. Могут быть указаны
определенные значения порогов допускаемых отклонений
стоимости для определения тех значений, которые допус-
каются до принятия некоторых необходимых действий.
Пороговые значения обычно выражаются в процентах от-
клонения от базового плана;
x правила измерения исполнения (производительности).
Устанавливаются правила управления освоенным объ-
емом (earned value management) для оценки результатов
работы. Например, план управления стоимостью может:
–определять точки, в которых выполняется измерение
контрольных учетных записей (CA);
–устанавливать используемые методы измерения освоен-
ного объема (например, взвешенные вехи, фиксирован-
ные формулы, процент завершения и т. д.);
–указывать методы отслеживания и формулы для ис-
числения освоенного объема при расчете прогнозируе-
мых оценок бюджета по завершении проекта (EAC) для
98 Глава 4
выполнения проверки достоверности контроля EAC

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

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

Процесс: оценка стоимости
Рис. 21. Процесс оценки стоимости в группе процессов плани

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

x оценка общей стоимости ресурсов, необходимых для вы-
полнения каждой плановой операции;
x оценка стоимостей операций с их обоснованием.
Интерпретация процесса оценки стоимости проекта и

100 Глава 4
процесс должен обеспечить полную и обоснованную оценку

стоимостей операций проекта.
NB! В данном процессе проводится оценка стоимости опе
раций, т. е. самых мелких работ внутри пакетов работ. По
грешность в оценке операций не должна быть столь вели
ка, так как работы не являются крупными по объемам при
влекаемых ресурсов. Тогда и общая оценка стоимостей
всех операций проекта, составляющая стоимость всех ра
бот проекта, будет достаточно точной.
Основными инструментами данного процесса являются:
x экспертная оценка;
x оценка по аналогии;
x параметрическая оценка;
x оценка «снизу вверх»;
x оценка по трем точкам.
Применение этих инструментов аналогично их применению
в предыдущей главе, посвященной управлению сроками про-
екта, с тем отличием, что в данной главе эти инструменты при-
меняются не для оценки длительности операций, а для оценки
их стоимости.
Другие инструменты, рекомендованные стандартом, учиты-
вают специфику данного процесса.
x Анализ резервов необходим для включения денежных ре-
зервов, которые могут потребоваться при выполнении
рискованных операций.
x Концепция стоимости качества позволяет провести
оценку затрат, необходимых для достижения приемлемого
для заказчика уровня качества.
x Анализ предложений исполнителей проводится в ходе
оценки и сравнения стоимостей предложений участников
тендеров.
Стандартом рекомендованы две итерации в процессе по-
степенного уточнения стоимости проекта как совокупной
стоимости всех операций проекта.
1. «Порядок величины» (order of magnitude) — оценка с допус-
тимым диапазоном отклонений в пределах 25% экономии и
75% перерасхода.
Применение на практике такой грубой исходной оценки

стоимости проекта возможно на этапе анализа целесообраз-
ности и осуществимости проекта (feasibility study) до принятия
решения о старте либо об отказе от проекта. Например, вла-
дельцы бизнеса могут запросить такую грубую оценку для вы-
яснения «порядка величины» затрат потенциального проекта.
2. Точная оценка (definitive estimate) — оценка с допустимым
диапазоном отклонений в пределах 5% экономии и 10% пе-
рерасхода.
Применение на практике точной оценки стоимости проекта
возможно для утверждения первоначального бюджета проекта
финансовым органом компании.
! Комментарий из практики. Вспомогательные данные (осно-

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

имости
x LL-7.2.1. Вспомогательные данные (основы для оценки
стоимости операций — supporting details) необходимы ру-
ководителю проекта для защиты стоимостей отдельных
работ перед заказчиком проекта или финансирующей ор-
ганизацией.
x LL-7.2.2. При определении ставок стоимости ресурсов
(determine resource cost rates) необходимо учитывать сто-
имость всех ресурсов, которые требуются для выполнения
работ по проекту. Например, стоимость 1 ч работы про-
граммиста плюс стоимость лицензии используемого им
программного обеспечения.
102 Глава 4

Процесс: определение бюджета
Рис. 22. Процесс определения бюджета проекта в группе про

Основные цели определения бюджета проекта:

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

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

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

гласовать объемы финансирования этапов работ и утвер
дить требования к финансированию проекта в финансовом
органе компании — заказчика проекта.
Разные этапы проекта могут потребовать различные объ-

емы финансирования, и требования к финансированию также
могут быть разными. Например, если первый этап интеграци-
онного ИT-проекта включает работы по поставке оборудова-
ния вычислительного комплекса, то поставщик оборудования
может потребовать 100%-ю предоплату для размещения заказа
на сборку оборудования на заводе-изготовителе. Если второй
этап проекта включает работы по созданию прикладного про-
104 Глава 4
граммного обеспечения, то разработчик прикладного продук-

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

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

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

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

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

Процесс: контроль стоимости
Основные цели контроля стоимости проекта:
x анализ отклонений по стоимости и срокам;
x расчет прогнозных значений (стоимость оставшихся невы-
полненными работ и стоимость всего проекта по его за-
вершении);
x расчет оценочных показателей (показатель эффективнос-
ти выполнения работ);
x актуализация и обновление бюджета проекта.
Интерпретация процесса контроля стоимости проекта
процесс должен обеспечить управление отклонениями в стои-
мости проекта и своевременные действия по выполнению ра-
бот проекта в рамках средств бюджета.
На практике в ходе контроля стоимости следует проводить
регулярный мониторинг освоения запланированных объемов
бюджета проекта с целью обнаружения и анализа отклонений
от базового стоимостного плана.
NB! Основной задачей руководителя проекта в процессе
контроля стоимости является проверка корректности от
клонений от базового плана по стоимости, которые должны
быть исключительно результатом утвержденного запроса
на изменение базового плана.
106 Глава 4
Рис. 23. Процесс контроля стоимости в группе процессов мони

торинга и контроля
Неверные, не соответствующие базовому стоимостному

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

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

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

объема включают отклонения по стоимости, срокам и индексы
выполнения бюджета и графика проекта.
Отклонение по стоимости (cost variance — CV):
CV = EV – AC.
Отклонение по срокам (schedule variance — SV):
SV = EV – PV.
Индекс выполнения бюджета (cost performance index —
CPI):
CPI = EV / AC.
Индекс выполнения календарного плана (schedule
performance index — SPI):
SPI = EV / PV.
Бюджет по завершении (budget at completion — BAC) явля-
ется итоговой плановой стоимостью работ проекта по его за-
вершении.
108 Глава 4
! Комментарий из практики. Расчет отклонений по стоимос-

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

ляются:
x ETC (Estimate to Completion) – прогнозная оценка стои-
мости оставшихся невыполненными работ проекта до его
завершения;
x EAC (Estimate at Completion) – прогнозная оценка стои-
мости всего проекта по его завершении.
Варианты расчетов прогнозных показателей ETC и EAC
представлены в табл. 6.
Таблица 6
ETC EAC Примечание
Новые оценки ACс + новые оценки Метод на основе новых оценок

оставшихся оставшихся работ оставшейся части работ — наибо
работ с — кумулятивное лее точный метод
значение
Метод на основе нетипичных от

клонений (если считается, что
BAC – EVс ACс + BAC – EVс
подобные отклонения не будут
иметь места в будущем)
Метод на основе типичных откло

(BAC – EVс) / ACс + ((BAC – EVс) /
нений (если считается, что откло
(CPIс u SPIс) (CPIс u SPIс ))
нения сохранятся и в будущем)
! Комментарий из практики. Расчет прогнозных показателей

стоимости оставшихся невыполненными работ проекта (ETC) и
стоимости всего проекта по его завершении (EAC) следует так-
же проводить по завершении этапа или достижении контрольной
точки проекта. Именно по завершении работ этапа или по до-
стижении контрольной точки спонсор проекта может попросить
руководителя проекта дать прогноз.
Показатель эффективности выполнения работ (to complete

performance index — TCPI) может быть раcсчитан в любой мо-
мент жизненного цикла проекта:
TCPI = (BAC – EV) / (BAC – AC).
В числителе данной дроби мы видим стоимостное выраже-
ние оставшихся невыполненными работ проекта, а в знамена-
теле – остаток неизрасходованного бюджета проекта.
! Комментарий из практики. Регулярные вычисления показа-

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

стоимости
x LL-7.4.1. При управлении стоимостью проекта руководи-
тель проекта пытается воздействовать на факторы, вызы-
вающие изменения базового стоимостного плана, и до-
биться того, чтобы потенциальное превышение стоимости
не привело к увеличению расходов сверх авторизованных
пределов финансирования.
x LL-7.4.2. Необходимо точно фиксировать и вести записи
всех соответствующих изменений в затратах, имеющих от-
личия от базового стоимостного плана.
x LL-7.4.3. Необходимо обеспечить соблюдение правил
использования утвержденных ресурсов или денежных
средств, чтобы в них не были внесены неверные, несоот-
ветствующие или неутвержденные изменения.
110 Глава 4
/ Бизнес*кейс: проект «Покупка компании»

Проблемная ситуация. Оценка стоимости проекта и раз-
работка базового стоимостного плана (project cost baseline)
предоставляют необходимые, но недостаточные результаты
для принятия окончательного решения о вхождении в проект
(gо-nо-gо decision making). Для окончательного решения об
инициации проекта, кроме оценок стоимости проекта, вла-
дельцам бизнеса необходимо также оценить доход, который
можно будет получить от эксплуатации продукта проекта в
ходе операционной деятельности компании, и сроки окупае-
мости проекта.
Описание бизнес-кейса. Владельцы компании (крупного

телекоммуникационного оператора) решили изучить возмож-
ность покупки и приобретения активов зарубежного операто-
ра связи. Перед руководителем проекта была поставлена задача
оценить и сравнить стоимость двух проектов покупки выбран-
ных компаний-операторов: одного в Европе и другого — в Азии.
Руководитель проекта провел итерационный анализ и расчет
двух оценок стоимости покупки как для европейского, так и
для азиатского операторов и получил в каждом случае «поря-
док величины» (order of magnitude) и точную оценку (definitive
estimate). Оказалось, что стоимость приобретения оператора в
Европе существенно ниже стоимости оператора в Азии. Соглас-
но точной оценке, покупка европейского оператора могла быть
гораздо дешевле, чем приобретение оператора в Азии.
Однако владельцы компании захотели оценить не толь-
ко стоимость приобретения актива, но и момент окупаемости
проекта (breakeven point) и будущую прибыль. Расчет момента
окупаемости проектов приобретения европейского и азиатско-
го операторов показал незначительные различия сроков воз-
врата инвестиций. Казалось, что в данной ситуации выгоднее
было отдать предпочтение покупке оператора в Европе, потому
что владельцы бизнеса должны были окупить свои инвестиции
как в Европе, так и в Азии примерно за одинаковое время. Тем
не менее расчет будущей прибыли от эксплуатации операто-
ров после наступления момента окупаемости проектов пока-
зал значительно большую прибыль от эксплуатации оператора

в Азии. Поэтому владельцы компании приняли окончательное
решение «gо» о покупке оператора в Азии.
Выводы и рекомендации. По рекомендациям стандарта,

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

в стандарте PMI PMBOK ®. В данной области стандарта
описана одна из деcяти ключевых компетенций руководителя
проекта по управлению качеством работ проекта и качеством
его результатов. Три процесса, рекомендованных стандартом
в данной области, относятся к группам процессов планирова-
ния, исполнения, мониторинга и контроля проекта (табл. 7).
Таблица 7
«Управление качеством проекта»
Планирование управления качеством Планирование
Обеспечение качества Исполнение
Контроль качества Мониторинг и контроль
Описания данных процессов и рекомендаций автора по их


управление качеством проекта
Процесс: планирование управления качеством
Управление качеством проекта 113
Рис. 24. Процесс планирования управления качеством в группе

процессов планирования
Основные цели планирования управления качеством

проекта:
x разработка плана управления качеством, включающего
стандарты качества для конкретного проекта;
x разработка вопросников и опросных листов процедур
обеспечения качества;
x разработка контрольных списков процедур контроля
качества;
114 Глава 5
x разработка базового плана по качеству (project quality

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

чеством проекта и рекомендации по его применению на
практике. Данный процесс должен обеспечить разработку
плана управления качеством проекта, включая требования к
качественным характеристикам продукта и работ, а также обес-
печение соответствия плана стандартам качества.
Основной подход PMI PMBOK к управлению качеством
проекта соответствует стандартам качества ISO 9000 и ISO
10000 и современным концепциям качества.
NB! При планировании качества следует учесть формаль
ные требования к качеству заказчика проекта, а также не
формальные (подразумеваемые) требования конечных
пользователей продукта. Изучение ожиданий конечных
пользователей продукта может привести к коррекции фор
мальных требований заказчика и корректировке / дополне
ниям формальных документов проекта, описывающих тре
бования заказчика к качеству.
Следует различать требования к качеству проекта и к качест-

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

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

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

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

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

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

заданиями для совершенствования процесса.
Метрики качества (metrics) должны быть разработаны для
проведения процедур обеспечения качества и могут включать
шаблоны вопросников и анкет. За процесс обеспечения каче-
ства (qaulity assurance) отвечает эксперт по качеству.
Для проведения процедур контроля качества характеристик
продукта должны быть разработаны контрольные списки по
качеству (check lists). За процесс контроля качества (quality
control) отвечает контролер качества.

ния управления качеством проекта
x LL-8.1.1. Роли эксперта по качеству и контролера качества
должны выполнять разные люди.
x LL-8.1.2. Эксперт по качеству проводит регулярное обсле-
дование качества работ и результатов работ проекта на ос-
нове созданных им вопросников и опросных листов про-
цедур обеспечения качества.
x LL-8.1.3. Контролер качества осуществляет проверку каче-
ства характеристик продукта проекта на основе созданных
им контрольных списков.
x LL-8.1.4. Метрики и контрольные листы должны соответ-
ствовать одним и тем же стандартам качества, выбранным
для конкретного проекта.

Процесс: обеспечение качества
118 Глава 5
Рис. 25. Процесс обеспечения качества в группе процессов пла

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

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

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

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

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

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

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

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

качества проекта
x LL-8.2.1. Эксперт по качеству проводит проактивный

аудит качества основных результатов проекта (deliverables)
в процессе их создания.
x LL-8.2.2. Эксперт по качеству является «виртуальным»
членом команды проекта и не подчиняется руководителю
проекта.
x LL-8.2.3. Эксперт по качеству имеет свободный доступ к
любым документам проекта.
x LL-8.2.4. Эксперт по качеству обладает правом эскалации
проблем проекта на любой уровень, включая спонсоров и
руководящий комитет проекта.

Процесс: контроль качества
Основные цели контроля качества проекта:
x контроль характеристик продукта контролером по качеству;
x возможное обновление базового плана по качеству;
x рекомендованные действия по переработке результатов
проекта;
x обнаружение и локализация причин дефектов с целью ис-
ключения их в будущем;
x утвержденные результаты проекта (validated deliverables).
Интерпретация процесса контроля качества проекта
процесс должен обеспечить требуемый уровень качества харак-
теристик продукта. Он основан на сравнении параметров про-
дукта с требуемыми параметрами качества.
В случае выявления характеристик продукта, не удовлетво-
ряющих предъявляемым требованиям по качеству, контролер
качества должен попытаться выявить и исключить источник
дефекта.
122 Глава 5
Рис. 26. Процесс контроля качества в группе процессов монито

ринга и контроля
! Комментарий из практики. Контролер качества, отвечаю-

щий за процесс проведения контроля качества, использует семь
основных инструментов контроля качества, которыми являют-
ся: причинно-следственная диаграмма, диаграмма зависимостей,
контрольные списки, контрольная диаграмма, диаграмма Парето,
гистограмма, диаграмма разброса.
Причинно-следственная диаграмма (fish-bone or cause and

effect diagram) позволяет графически выявить совокупность фак-
торов (причин), оказавших влияние на возникновение брака и
падение качества (следствия). Данная диаграмма («рыбья кость»)
иллюстрирует связь различных факторов (причин) с возможными
проблемами и следствиями.
Диаграмма зависимостей позволяет построить логическую
схему (блок-схему) последовательности событий и условий, кото-
рые привели к появлению брака.
Контрольные списки могут использоваться в качестве кон-
трольных листов при сборе данных. Они используются для орга-
низации фактов в форме, способствующей эффективному собира-
нию полезной информации о потенциальной проблеме качества.
Они особенно полезны для сбора данных атрибутов при выполне-
нии проверки для выявления дефектов. Например, данные о час-
тоте или последствия дефектов, собранные в контрольных спис-
ках, часто отображаются с помощью диаграмм Парето.
Контрольная диаграмма позволяет отследить результаты из-
мерений характеристик продукта во времени в пределах заданно-
го доверительного интервала значений, ограниченного верхним и
нижним контрольными уровнями (upper and lower control levels).
Попадание семи значений измерений за пределы доверительного
интервала свидетельствует об устойчивой тенденции некачествен-
ного поведения характеристики.
Диаграмма Парето позволяет расположить источники дефек-
тов по частоте их возникновения и определить 20% источников,
вызывающих 80% брака, и категоризировать следствия по частоте
или причинам.
Гистограмма — вертикальная столбиковая диаграмма, отобра-
жающая распределение переменных (параметров, свойств, при-
чин). Высота каждого столбика пропорциональна относительной
частоте реализации/возникновения свойств/причин.
Диаграмма разброса позволяет провести аппроксимацию из-
мерений двух связанных характеристик продукта и определить
степень стабильности их взаимного влияния. Является точечной
диаграммой, показывающей взаимосвязь между двумя дискретны-
ми переменными. При тесной связи точки группируются ближе к
некоторой корреляционной линии.
124 Глава 5
Основным выходом данного процесса являются результаты

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

чества проекта
x LL-8.3.1. Полезным является регулярное общение контро-
лера качества с экспертом по качеству, которое обеспечи-
вает более регулярное, эффективное и целенаправленное
наблюдение за работами проекта.
x LL-8.3.2. Обеспечение качества важнее, чем контроль ка-
чества. Если не обеспечить качество работ проекта, то ре-
зультат проекта (его продукт) не пройдет контроль каче-
ства и будет уже поздно!
x LL-8.3.3. В случае обнаружения дефектов продукта, кон-
тролер качества обязан локализовать причины появления
дефектов и проинформировать о них руководителя проек-
та. Руководитель проекта обязан описать причины дефек-
тов в базе извлеченных уроков для исключения появления
подобных причин дефектов в последующих проектах ор-
ганизации.
/ Бизнес*кейс: проект «Внедрение системы

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

ных потребителей использовать продукт.
Описание бизнес-кейса. Руководитель проекта отвечал за

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

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

сурсами проекта» в стандарте PMI PMBOK®. В данной
области стандарта описана одна из десяти ключевых компетен-
ций руководителя проекта по управлению одним из критичес-
ких ресурсов любого проекта — людьми, привлеченными для
выполнения работ проекта. Четыре процесса, рекомендован-
ные стандартом в данной области знаний, относятся к группам
процессов планирования и исполнения (табл. 8).
Таблица 8
«Управление человеческими ресурсами проекта»
Планирование управления человеческими ресурсами Планирование
Набор команды проекта Исполнение
Развитие команды проекта Исполнение
Управление командой проекта Исполнение
Описания данных процессов и рекомендаций автора по их

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

ресурсами проекта
Процесс: планирование управления человеческими
ресурсами
128 Глава 6
Рис. 27. Процесс планирования управления человеческими ре

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

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

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

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

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

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

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

ки маркетингового плана, то через две недели маркетолог
завершает работу в проекте и возвращается в отдел марке-
тинга при условии успешной разработки маркетингового
плана. Если же план не разработан и критерий высвобож-
дения ресурса не выполнен, маркетолог должен остаться в
проекте до завершения своей работы.
x Потребность в обучении членов команды.
x Системы мотивации (особенно важны стимулы для вы-
полнения критических работ проекта).
x Соответствие процедур управления персоналом проекта
политикам и процедурам управления кадрами организа-
ции, законодательным актам, отраслевым и правитель-
ственным распоряжениям.
x Вопросы безопасности — для управления персоналом, за-
нятым в работах проекта, представляющих риск для здо-
ровья и жизни людей.
NB! При наличии в проекте работ уникального характера,
не имеющих аналогов в операционной деятельности орга
низации, необходимо разработать описание данной роли
(job description) и определить сферу ответственности и
полномочия выполняющего ее специалиста.
Матрица ответственности (responsibility assignment matrix —

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

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

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

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

Процесс: набор команды проекта
Основные цели набора команды проекта:
x назначение персонала в команду проекта;
x обеспечение доступности человеческих ресурсов для рабо-
ты в проекте в соответствии с расписанием.
Интерпретация процесса набора команды проекта и ре-

комендации по его применению на практике. Данный про-
132 Глава 6
Рис. 28. Процесс набора команды проекта в группе процессов

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

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

вклад в результаты проекта. Если же назначить ему роль, не
соответствующую его психотипу, то он не сможет внести мак-
симальный вклад в проект, потому что находится «не в своей
тарелке».
Эффективные способы для определения психотипов членов
команды проекта дает теория ролевого поведения людей и их
взаимодействия с командой (team role theory) Рэймонда Мере-
дита Белбина, который выделяет девять психотипов:
x примиритель (team worker);
x контролер (completer);
x специалист (specialist);
x исполнитель (implementer);
x аналитик (monitor evaluator);
x координатор (coordinator);
x разработчик (resource investigator);
x организатор (shaper);
x инноватор (plant).
В результате соответствующего тестирования каждому члену
команды может быть назначена наиболее характерная для него
роль (например, аналитик получает роль аналитика, а не ис-
полнителя и т. п.).
NB! При проведении тестирования на выявление психоти
пов необходимо заранее получить согласие членов коман
ды на предоставление руководителю проекта результатов
теста для их анализа. Если такого согласия нет, то проведе
ние теста невозможно с этической точки зрения.
NB! При наборе команды руководитель проекта обязан

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

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

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

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

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

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

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

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

манды проекта
x LL-9.2.1. При необходимости организации виртуальных
команд желательно проводить с определенной периодич-
136 Глава 6
ностью очные встречи членов команды. Если это невоз-

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

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

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

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

исполнения
ление взаимодействия между ними для максимального по-

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

видеоконференции членов виртуальной команды.
Термин «тимбилдинг» (team building) имеет два значения:
x неформальная встреча с членами команды (данное значе-
ние широко известно и часто употребляется на практике);
x процесс построения команды.
Пять стадий процесса построения команды включают:
1) формирование;
2) возмущение;
3) стабилизацию;
4) выполнение;
5) расформирование.
NB! Уже на стадии формирования команды у ее членов мо

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

ния команды может выражаться в эффективном определении и
распределении ролей в команде (этот процесс описан в преды-
дущей главе).
Говоря об инструментах поощрения и премирования, следу-
ет отметить фундаментальные модели мотивации, основанные
на теориях иерархии потребностей Абрахама Маслоу и мотиви-
рующих факторов Фредерика Херцберга.
Абрахам Маслоу предложил иерархическую модель потреб-
ностей личности. Наиболее значимы для понимания мотивации
членов команды пять основных уровней. Причем для удовлет-
ворения потребностей более высокого уровня необходимо удов-
летворение потребностей, лежащих на предыдущих уровнях.
5-й (самый высокий) уровень: потребность в самореализа-

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

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

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

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

сылкой получения экстраординарных результатов проекта.
Модель мотивирующих факторов Фредерика Херцберга
можно представить в виде пирамиды потребностей Абрахама
Маслоу, «разрезанной пополам».
x Базовые факторы предполагают удовлетворение потреб-
ностей, относящихся к 1-му, 2-му и 3-му уровням пирами-
ды потребностей Абрахама Маслоу.
x Мотивирующие факторы отвечают потребностям, отно-
сящимся к 4-му и 5-му уровням пирамиды потребностей
Абрахама Маслоу.
Базовые факторы являются необходимыми, но недостаточ-
ными условиями для мотивации члена команды. К базовым
факторам относятся:
x условия работы;
x зарплата;
x личная жизнь;
x отношения на работе;
x безопасность;
x статус.
Отсутствие удовлетворенности в отношении базовых фак-
торов ведет к снижению мотивации, однако удовлетворенность
на этом уровне не ведет к росту мотивации. В случае удовлет-
воренности базовых потребностей истинными мотивирующи-
ми факторами становятся:
x наличие ответственности и полномочий — для членов ко-
манды, стремящихся к административному росту;
x наличие возможностей самореализации, профессионально-
го роста, общественное признание достижений — для чле-
нов команды, стремящихся к профессиональному росту.
Другими важными инструментами данного процесса явля-
ются принципы, признание заслуг и вознаграждение и инстру-
менты оценки персонала.
Принципы — ясные и четкие правила поведения, приемле-
мые среди членов команды проекта. Все члены команды про-
екта принимают на себя обязанности по соблюдению установ-
ленных правил.
Признание заслуг и вознаграждение – стимулирование и

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

команды проекта
x LL-9.3.1. Планы по обучению следует согласовывать с
функциональными руководителями компании.
x LL-9.3.2. Для стратегически важных проектов необходимо
разрабатывать и согласовывать с отделом персонала спе-
циальные программы поощрения и премирования ключе-
вых членов команд.

Процесс: управление командой проекта
142 Глава 6
Рис. 30. Процесс управления командой проекта в группе про

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

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

процесс должен обеспечить постоянное наблюдение за работой

команды и регулярное ее обсуждение, своевременное разре-
шение проблемных и конфликтных ситуаций, возникающих в
коллективе, эффективные изменения плана управления персо-
налом и плана управления проектом.
Наблюдение за работой команды — постоянная обязанность
руководителя проекта. При обсуждении отчетов членов коман-
ды об исполнении работ необходим обмен мнениями членов
команды о полученных результатах и дальнейших планах. Ру-
ководителю проекта необходимо поддерживать атмосферу от-
крытости и взаимного доверия, которая способствует консоли-
дации коллектива команды и ее нацеленности на достижение
результатов проекта.
Важным условием консолидации команды является осозна-
ние ее членами общих целей проекта. Это условие не всегда вы-
полняется в небольших, краткосрочных проектах. Если проект
небольшой по объему, имеет длительность три-четыре недели
и в рабочей группе два-три человека, то вряд ли члены этого
небольшого коллектива осознают общие для них цели проекта.
В таком небольшом проекте их объединяют в рабочую группу
(а не в команду!) для быстрого выполнения несложных задач,
слабо связанных друг с другом. В крупном проекте с большим
объемом работ и сроками не в три-четыре недели, а в несколь-
ко месяцев или несколько лет необходима уже не рабочая груп-
па из двух-трех человек, а организованная команда из десятков
людей. Члены такой команды понимают, что их объединили в
единый коллектив на длительное время не случайно. Это дли-
тельное время является существенной частью их жизни, кото-
рую они хотят достойно прожить, получить результаты проекта
(причем результаты, необходимые не только для заказчика про-
екта, но и для них лично, для их дальнейшего роста и карьеры).
Такое понимание ведет к осознанию членами команды общих
для них целей проекта и к консолидации коллектива команды.
Другим важным условием консолидации команды являет-
ся регулярный обмен мнениями, в том числе по поводу работы
каждого. Успех взаимного обмена мнениями зависит от откры-
тости членов команды по отношению к коллегам и желания ока-
зать поддержку друг другу. Взаимный обмен мнениями вклю-
144 Глава 6
чает предоставление отзыва о работе коллеги (giving feedback)

и получение от коллеги отзыва о собственной работе (receiving
feedback) в случае горизонтального обмена мнениями.
! Комментарий из практики. Вертикальный обмен мнениями

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

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

но ранжировать по частоте их возникновения следующим об-
разом:
x сроки проекта;
x приоритеты проекта;
x ресурсы;
x технические решения;
x административные процедуры;
x стоимость;
x личные мотивы.
Перечислим основные методы управления конфликтами:
x уклонение — нежелание конфликтовать. Уклонение от
сложившейся или потенциально конфликтной ситуации.
Может быть связано с необходимостью выиграть время
или сохранить хорошие отношения с конфликтующей сто-
роной;
x сглаживание — умышленное подчеркивание совпадающих
позиций конфликтующих сторон и ослабление разногла-
сий за счет использования дополнительных аргументов;
x нахождение компромиссов — гибкое решение («золотая
середина»), при котором каждая из конфликтующих сто-
рон в чем-то выигрывает, а в чем-то проигрывает (win/
lose). Компромисс невозможен при необходимости поиска
решения, исключающего гибкость;
x принуждение — одна из конфликтующих сторон настаива-
ет на своей точке зрения и не соглашается идти на уступ-
ки, т. е. принуждает противоположную сторону принять ее
решение;
x сотрудничество/решение проблемы — поиск и нахожде-
ние согласованного решения, объединяющего сильные
стороны предложений конфликтующих сторон и удовлет-
воряющего обе стороны (win/win).
Журнал регистрации потенциальных проблем является цен-

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

значать ответственных за их решение и устанавливать сроки
для контроля.
При управлении командой руководителю проекта следует
проявлять ценные личные качества:
x лидерство;
x влияние;
x умение оперативно принимать решения.
Лидерские качества (leadership) особенно важны для управ-
ления крупными проектами. Лидерство не является крити-
ческим фактором при управлении небольшими проектами и
малым бизнесом. Руководитель небольшого проекта, органи-
зующий работу небольшой команды, должен быть эффектив-
ным менеджером. По мере роста объемов проекта и увеличе-
ния численности команды проекта руководитель проекта по-
степенно делегирует многие функции управления на уровень
ниже — своим заместителям, руководителям подпроектов, ад-
министраторам, стремясь прежде всего быть лидером1.
Основные качества лидера, отличающие его от менеджера:
x способность вести людей за собой (lead);
x понимание стратегии;
x авторитет;
x харизма.
NB! Надо признать, что эти качества даются «от Бога» и
очень немногим людям. В организации может быть мало
ярких лидеров — и это закон природы. Тем не менее попыт
ки руководителя проекта работать над собой и развивать
лидерские качества могут привести к положительным ре
зультатам. Проекты начинают выполняться с большей эф
фективностью! Важны попытки и стремление руководителя
проекта к воспитанию в себе качеств лидера.
Влияние (influence) – другое важное личное качество руко-
водителя крупного проекта. Влияние возникает при наличии у
1 Процесс признания лидера проекта членами команды описан автором в

работе: Павлов А. Н. Процесс формирования лидера — руководителя про-
екта. Выступление на XVII конгрессе IPMA по управлению проектами/Про-
ектно-ориентированные бизнес и общество. М., 2003.
руководителя проекта связей с высшим руководством органи-

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

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

мое качество руководителя проекта. Известен прием, который
используют многие менеджеры (не лидеры!), — непринятие ни-
каких решений. Вопрос, проблема остаются «в подвешенном»
состоянии. Это недопустимо в проектной деятельности! Нере-
шенные проблемы накапливаются и давят тяжким грузом на
проект, часто вызывая кризисные ситуации и провал проектов.
С ростом объема работ по проекту и увеличением числен-
ности команды падают требования к техническим знаниям ру-
ководителя проекта и повышаются требования к его лидерским
качествам1.
Перечислим основные виды власти руководителя проекта:
x формальная — руководитель проекта назначен приказом
директора организации;
x поощрительная — возможность поощрять членов команды;
x взыскательная — возможность взыскивать с членов
команды;
x экспертная — наличие у руководителя проекта опыта и
знаний;
x отсылочная — возможность сослаться на лицо или инфор-
мационный источник, к которому нет доступа у подчинен-
ных членов команды.
1 Павлов А. Н. Процесс формирования лидера — руководителя проекта.

Выступление на XVII конгрессе IPMA по управлению проектами/Про-
ектно-ориентированные бизнес и общество. М., 2003; Kerzner H. Project
Management. Danvers (MA), 2003.
148 Глава 6

командой проекта
x LL-9.4.1. В журнале регистрации потенциальных про-
блем (issue log) отражаются не проблемы (problems) как
таковые, а ситуации, чреватые возникновением проблем
(issues), которые пока что являются «открытыми вопроса-
ми». Если не «закрыть» такой вопрос, то он действитель-
но может стать проблемой. Журнал регистрации проблем
необходим руководителю проекта, чтобы не забыть о том,
что в команде проекта существует потенциальная пробле-
ма, и она требует решения. Между членами команды могут
быть сложные человеческие отношения и не всегда сразу
удается найти решение, тогда мы фиксируем потенциаль-
ную проблему в этом журнале.
x LL-9.4.2. Все пять основных видов власти должны быть в
арсенале руководителя проекта. Если какая-либо из них
отсутствует (например, у руководителя проекта нет экс-
пертной власти), то это значит, что у него нет полной вла-
сти в команде проекта.
/ Бизнес*кейс: проект «Строительство

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

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

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

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

ми проекта» в стандарте PMI PMBOK®. В данной облас-
ти стандарта описана одна из десяти ключевых компетенций
руководителя проекта по управлению коммуникационными
взаимодействиями между всеми стейкхолдерами проекта. Три
процесса, рекомендованных стандартом в данной области зна-
ний, относятся к группам процессов планирования, исполне-
ния, мониторинга и контроля (табл. 9).
Таблица 9
«Управление коммуникациями проекта»
Планирование управления коммуникациями Планирование
Управление коммуникациями Исполнение
Контроль коммуникаций Мониторинг и контроль


управление коммуникациями проекта
Процесс: планирование управления коммуникациями
Управление коммуникациями проекта 151
Рис. 31. Процесс планирования управления коммуникациями в

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

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

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

формацией по проекту: какая информация, в каком объеме,
кем должна быть подготовлена, кому направлена, как часто и
по какому коммуникационному каналу.
NB! 90% своего времени руководитель проекта посвящает

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

ков проекта позволяет выявить их потребности в тех или иных
документах о проекте, выяснить необходимый формат этих до-
кументов и периодичность их поступления по определенным
коммуникационным каналам. Например, спонсор проекта может
запросить еженедельные краткие отчеты о статусе проекта в виде
записки по электронной почте. Заказчик проекта может запро-
сить подробный ежеквартальный отчет о результатах проекта.
В фундаментальной модели коммуникаций присутствуют
элементы:
x отправитель сообщения;
x получатель сообщения;
x канал передачи сообщения;
x канал обратной связи.
Проходя по каналу передачи, сообщение претерпевает иска-
жения, причинами которых могут быть всевозможные барьеры.
Например, физические помехи и шумы в телефонном канале
или языковые, ментальные и культурные различия между от-
правителем и получателем сообщения.
В случае устных коммуникаций с визуальным контролем,
когда получатели сообщения слышат и видят отправителя:
x 7% содержания сообщения передается через слова;
x 38% — через тон голоса;
x 55% — через язык телодвижений (body language).
Поэтому язык телодвижений чрезвычайно важен при прове-
дении презентаций проекта для заказчиков и спонсоров.
Отправитель должен ясно и четко излагать суть сообщения,
чтобы по каналам обратной связи не приходили многочислен-
ные вопросы со стороны получателей. Например, в письмен-

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

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

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

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

муникационных связей внутри команды возрастает. Если в ко-
манде N членов, максимальное количество возможных комму-
никационных связей между ними определяется по формуле
N (N – 1)/2.
План управления коммуникациями должен описывать тре-
бования участников проекта к получению информации о про-
екте и технологии ее распространения. Должны быть указаны:
x требования участников проекта к типам коммуникаций
(устные, письменные, формальные, неформальные, вер-
тикальные, горизонтальные);
154 Глава 7
x требования к формату, содержанию и степени детализа-

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

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

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

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

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

проекта и рекомендации по его применению на практике.
Данный процесс должен обеспечить реализацию плана управ-
ления коммуникациями по своевременному предоставлению
участникам проекта необходимой для них информации в тре-
буемом объеме и формате. Одним из основных источников
для распространения информации о проекте являются регу-
лярные отчеты. В табл. 10 приведен фрагмент плана управле-
ния коммуникациями, относящийся к предоставлению отче-
тов по проекту.
156 Глава 7
Рис. 32. Процесс управления коммуникациями в группе процес

сов исполнения
Эффективность процесса распространения информации за-

висит от ряда факторов:
x надежности и качества используемых средств связи;
x стиля письменных коммуникаций — ясное выражение
мыслей на бумаге, отсутствие двусмысленности, крат-
кость, выразительный язык;
x стиля устных (визуальных) коммуникаций — эффективная
невербальная лексика, язык телодвижений;
x профессионального управления совещаниями — заранее
сообщенная участникам ясно сформулированная повест-
ка, ведение протокола, распространение принятых реше-
ний;
Таблица 10
Фрагмент плана управления коммуникациями
(предоставление отчетов по проекту)
Название отчета Лицо, готовя* Лицо, которому Периодичность
щее отчет направляется
отчет
Отчет о продви Руководитель Заказчик Раз в квартал

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

жении проекта проекта
Отчет о статусе Администратор Руководитель Раз в неделю по

проекта проекта проекта пятницам
Отчет о статусе Руководители Администратор Раз в неделю по

подпроектов подпроектов проекта четвергам

субподрядных субподрядчиков проекта четвергам
работ

поставок поставщиков проекта четвергам
x искусства публичных выступлений — методы эффектив-

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

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

риод;
x резюме одобренных изменений за определенный период.
На выходе данного процесса появляются обновленные ак-

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

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

коммуникациями
x LL-10.2.1. В коммуникациях с заказчиками проекта иногда
полезно создавать иллюзию, что «все идет хорошо!». Если
постоянно говорить с заказчиком о проблемах, то вы ста-
нете в его глазах «проблемным человеком», и он вряд ли
поручит вам другой проект в будущем. Если вы отмечаете
проблемы проекта, то надо предлагать пути их решения.
Тогда заказчик будет считать вас не «проблемным челове-
ком», а руководителем проекта, активно ищущим выходы
из проблемных ситуаций.
160 Глава 7
x LL-10.2.2. «Краткость — сестра таланта». В рабочей пере-

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

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

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

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

са, порталы и средства управления совместной работой.
Экспертные оценки могут потребоваться для технических
и/или управленческих деталей и могут даваться любой группой
или лицами со специальными знаниями или подготовкой:
x другими подразделениями исполняющей организации;
x консультантами;
x заинтересованными сторонами, включая клиентов или
спонсоров;
x профессиональными и техническими ассоциациями;
162 Глава 7
x промышленными группами;
x экспертами в предметной области;
x офисами управления проектами.
Менеджер проекта совместно с проектной группой затем
определяет меры, необходимые для обеспечения корректности
использования оценок в нужном месте и в нужное время.
Совещания – обсуждение и ведение диалога с командой
проекта для определения наиболее подходящего способа об-
новления и исполнения коммуникаций проекта, чтобы наи-
лучшим образом удовлетворить информационные потребности
всех заинтересованных сторон проекта.
На выходе процесса появляется информация о выполнен-
ных работах проекта, которая может включать:
x отчеты о статусе (текущем состоянии) проекта;
x отчеты о продвижении проекта (результатах, полученных
за определенный период);
x прогнозы (предсказания будущего состояния проекта);
x сведения об отклонениях от базовых планов проекта;
x отчет о тренде (улучшается или ухудшается ситуация);
x отчет об освоенном объеме бюджетных средств, включая рас-
четные показатели отклонений и индексы CV, SV, CPI, SPI;
x открытые презентации — публичные отчеты об исполне-
нии проекта.
! Комментарий из практики. Цель открытой презентации, по-

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

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

коммуникаций
x LL-10.3.1. Регулярные совещания о статусе проекта (project
status review meeting) следует проводить еженедельно и от-
водить на них один час. Повестка должна быть следующей:
сроки работ, освоение бюджета, качество результатов, от-
ношения с заказчиком, разное.
x LL-10.3.2. Регулярные публичные отчеты об исполнении
проекта способствуют повышению информированности о
проекте и расширению поддержки проекта на всех уров-
нях организации.
проект «Автомобильный концерн»
Проблемная ситуация. В виртуальных командах крупных
международных проектов возникает риск потери качества
коммуникаций из-за географической удаленности, языковых,
культурных и ментальных различий между членами команды.
Регулярные совещания членов команды часто невозможны из-
за больших расстояний между участниками, а переписка по
электронной почте и телефонные конференции не могут заме-
нить по эффективности непосредственного общения.
Описание бизнес-кейса. Один из ведущих в мире авто-

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

была обеспечить автоматизированный учет и контроль произ-
водства, распределения и замены запасных частей. Исполни-
тель проекта — разработчик автоматизированной системы —
включил в команду проекта десятки специалистов из разных
стран мира. Руководитель проекта разработал план управления
коммуникациями, предполагающий регулярный обмен отче-
тами по электронной почте и еженедельные телефонные кон-
ференции с руководителями подпроектов. Однако очень скоро
выяснилось, что участники проекта из разных стран не могут
понять причины решений и действий по управлению проектом.
В частности, возникла серия конфликтных ситуаций между
оффшорными программистами из Индии и системными архи-
текторами из Норвегии. Программисты не понимали сути рас-
поряжений и рекомендаций архитекторов. Причины лежали в
коренных различиях менталитета специалистов — представите-
лей «восточной» и «западной» культур! Телефонные конферен-
ции также не привели к взаимопониманию. Тогда руководитель
проекта принял решение о проведении регулярных видеокон-
ференций для членов команды. Такие конференции позволи-
ли участникам одновременно видеть и слышать друг друга. Тем
самым, обеспечивался зрительный контакт (eye contact) между
членами команды. Реализовались возможности устных визу-
альных коммуникаций, ведь оценка эффективности коммуни-
каций показала, что только 7% смысла передаются через слова
(как в случае коммуникаций по электронной почте), 38% пере-
дается через тон голоса (как в случае телефонных переговоров),
а 55% — на языке телодвижений. Когда члены виртуальной ко-
манды проекта получили возможность эффективно общаться в
режиме видеоконференции, повысились взаимопонимание и
сплоченность команды, уменьшилось количество конфликтов.
Выводы и рекомендации. При разработке плана управле-
ния коммуникациями необходимо рассмотреть возможность
личных контактов между членами виртуальных команд. Если
очные взаимодействия невозможны из-за географической уда-
ленности, то следует предусмотреть регулярное проведение ви-
деоконференций, которые особенно эффективны в междуна-
родных проектах.
ГЛАВА 8
Управление рисками проекта
Значение области знаний «Управление рисками проекта» в

стандарте PMI PMBOK®. В данной области знаний стан-
дарта описана одна из десяти ключевых компетенций руково-
дителя проекта по управлению рисками проекта, необходимая
для повышения вероятности и степени влияния положитель-
ных составляющих и снижения вероятности и степени влия-
ния негативных составляющих рисков. Шесть процессов, реко-
мендованных стандартом в данной области знаний, относятся
к группам процессов планирования, мониторинга и контроля
(табл. 11).
Таблица 11
«Управление рисками проекта»
Планирование управления рисками Планирование
Идентификация рисков Планирование
Качественный анализ рисков Планирование
Количественный анализ рисков Планирование
Планирование реагирования на риски Планирование
Контроль над рисками Мониторинг и контроль

166 Глава 8

управление рисками проекта
Процесс: планирование управления рисками
Рис. 34. Процесс планирования управления рисками проекта в

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

екта:
x определение подходов к управлению рисками конкретного
проекта;
x определение правил и процедур управления рисками;
x выбор и/или разработка форм шаблонов и отчетов по
управлению рисками.
Управление рисками проекта 167
Интерпретация процесса планирования управления ри-

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

1. Методология управления рисками. Описывается методоло-
гия, которой будет следовать команда проекта при управле-
нии рисками, или дается ссылка на документ, описывающий
подход к управлению рисками, который будет использован в
проекте (например, ссылка на стандарт PMI PMBOK).
2. Ответственность участвующих в управлении рисками. В
этом разделе плана может быть сказано, что для управления
рисками проекта будут назначены ответственные за риски
(risk owners). Ответственными за риски могут быть любые
участники проекта: руководитель проекта, члены команды,
поставщики или субподрядчики, кураторы. Задачами от-
ветственного за риски являются постоянное наблюдение за
рисками, отслеживание миграции рисков, изменение мето-
дов реагирования на риски. В случае идентификации рисков
в организации заказчика руководитель проекта может обра-
титься с просьбой к заказчику взять на себя данные риски и
нести за них ответственность.
3. Бюджет для управления рисками. В этом разделе плана мо-
жет быть сказано, что в бюджете проекта будет сформирован
резерв на возможные потери от известных рисков, а в случае
возникновения неизвестных рисков руководитель проекта
будет эскалировать просьбу куратору проекта о выделении
дополнительных финансовых средств из резерва руководства.
4. Периодичность процедур по управлению рисками. Пери-
одичность процедур по управлению рисками должна быть
168 Глава 8
четко определена в данном разделе плана. Например, мо-

жет быть сказано, что совещания команды по статусу рис-
ков проекта (project risk review meetings) будут проводить-
ся каждый третий четверг месяца, в 10:00. Или, например,
что аудит рисков будет проводиться риск-менеджером раз в
квартал. Конечно, в случае возникновения экстренной ситу-
ации, связанной с миграцией риска в зону критических ри-
сков или с появлением нового критического риска, следует
немедленно реагировать на риск и не ждать очередного за-
планированного совещания по рискам. Однако экстренные
решения по критическим рискам не отменяют регулярных
совещаний команды по статусу рисков проекта.
NB! На совещаниях, посвященных анализу статуса рисков
проекта, каждый ответственный за риск делает сообще
ние о своих рисках и сообщает их статус, в том числе дает
новые оценки вероятностей и влияния рисков, полученные
в результате мониторинга рисков, а также высказывает
предложения по выбору методов реагирования на риски.
Однако окончательное решение по методам реагирова
ния принимается после коллективного обсуждения статуса
рисков командой проекта. При выборе методов реагирова
ния на риски важна «палитра мнений» участников команды.
5. Пороговые критерии для распознавания наступления рис-

ка. Связаны с оценками вероятностей наступления риска.
Если на основе опыта команды могут быть установлены по-
роговые значения вероятности, при преодолении которых
событие однозначно происходит, то по мере приближения
к порогам в оценках вероятности риска растет уверенность
команды, что событие произойдет, и следует предпринимать
проактивные шаги по реагированию на риск.
6. Категории рисков. Рекомендуется разделять риски по кате-
гориям, учитывая четыре возможных источника рисков:
1) технические, связанные с работой оборудования, разра-
боткой новых технологий и технических продуктов;
2) внешние, связанные с внешней средой проекта — эконо-
мической, политической, социальной, конкурентной —
или внешними организациями заказчиков и поставщиков;
3) организационные, связанные со структурой компании,

организационными политиками и процедурами;
4) управленческие, связанные с отсутствием профессио-
нального управления проектом, планирования работ, не-
верными оценками содержания, сроков, стоимости, ре-
сурсов и качества результатов проекта.
7. Матрица вероятности и влияния рисков. Данная матрица
является приложением к плану управления рисками и ис-
пользуется при качественном анализе рисков для оценки па-
раметров риска (вероятности возникновения и степени вли-
яния) и определения величин рисков (произведения оценок
вероятностей и влияния). Пример матрицы вероятностей и
влияния рисков представлен на рис. 35.
Вероятность Величина = Вероятность х Влияние
0,9 0,045 0,09 0,18 0,36 0,72
0,7 0,035 0,07 0,14 0,28 0,56
0,5 0,025 0,05 0,1 0,2 0,4
0,3 0,015 0,03 0,06 0,12 0,24
0,1 0,005 0,01 0,02 0,04 0,08
0,05 0,1 0,2 0,4 0,8
Влияние
Рис. 35. Пример матрицы вероятностей и влияния рисков
По строкам данной матрицы показаны уровни вероятнос-

тей рисков, а по столбцам — уровни влияния. На пересечении
строк и столбцов в ячейках таблицы указаны величины рисков
как произведения оценок вероятностей и влияния.
В случае использования данной матрицы с определенными
значениями шкал влияния и вероятностей все риски проекта
могут быть разбиты на три категории по значениям их величин:
1) критические риски (с величинами, равными или больши-
ми 0,18);
170 Глава 8
2) умеренные риски (с величинами от 0,04 до 0,18);

3) незначительные риски (с величинами до 0,04).
NB! Экспертные оценки значений вероятностей и влияния
рисков должны быть качественными и обоснованными.
В противном случае применение данной матрицы не имеет
смысла. Для получения качественных оценок параметров
риска необходимо привлечь экспертов, обладающих опы
том работы в подобных проектах.
8. Форматы и шаблоны отчетов. Форматы и шаблоны отчетов
по управлению рисками основаны на использовании реес-
тра рисков, в котором в динамике отражаются названия рис-
ков, значения их параметров и величин, выбранные страте-
гии реагирования на риски и запланированные действия по
реализации выбранных стратегий. Примерный шаблон рее-
стра рисков представлен на рис. 36.
Название Вероят* Влияние Величина = Стратегия Действия

риска ность = Вероят* реагиро* по реа*
ность х вания лизации
х Влияние стратегии
Рис. 36. Шаблон реестра рисков
NB! План управления рисками — одна из важнейших сос

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

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

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

Процесс: идентификация рисков
Основная цель идентификации рисков проекта — опре-
деление рисков проекта, т. е. вероятных событий, способных
повлиять на работы и результаты проекта.
Интерпретация процесса идентификации рисков проек-

та и рекомендации по его применению на практике. Данный
процесс должен обеспечить итерационное определение и до-
кументирование рисков, способных повлиять на проект в тече-
ние всего его жизненного цикла.
Стандарт рекомендует разделять все идентифицированные
риски на три категории в зависимости от особенностей их вли-
яния на проект:
1) чистые риски (pure risks) — риски с негативным влияни-
ем, представляющие потенциальную угрозу для проекта;
2) возможности (opportunities) — риски с позитивным влия-
нием, являющиеся потенциально благоприятными собы-
тиями для проекта;
3) бизнес-риски (business risks) — возможные события в бу-
дущем, представляющие одновременно как угрозу, так и
благоприятную возможность для проекта.
172 Глава 8
Рис. 37. Процесс идентификации рисков в группе процессов

NB! Потенциально благоприятные возможности являются

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

ные.
Известные риски (known unknown — «известная неизвест-

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

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

ное снижение вероятности возникновения неблагоприятных
рисков и предупреждение потенциального ущерба от них, а
также максимальное повышение вероятности возникновения и
влияния благоприятных возможностей.
Детальному анализу с точки зрения выявления рисков про-
екта прежде всего подвергаются официальные документы —
контракты с заказчиком и поставщиками, технические зада-
ния, официальные протоколы и др. Однако стоит обратить
внимание и на другие источники сведений о потенциальных
рисках проекта, в том числе:
174 Глава 8
x описания продуктов;
x допущения и предположения;
x информация о рисках подобных проектов в прошлом.
Рассмотрим основные методы получения данных о рисках.

1. Мозговой штурм.
! Комментарий из практики. При проведении мозговых штур-

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

ума и воображения» (mind games and imaginations) у чле
нов команды, чтобы они попытались «заглянуть в будущее».
Риски проекта являются вероятными событиями, которые
могут произойти, а могут и не произойти в будущем. Члены
команды смогут «заглянуть в будущее» при условии доста
точных интеллектуальных усилий и креативности мышле
ния.
2. Метод Дельфи. Данный метод предполагает анонимный
опрос экспертов с целью определения их мнений по переч-
ню рисков проекта и итерационное сближение мнений экс-
пертов. Каждый эксперт готовит свой перечень рисков, за-
тем он получает анонимные перечни рисков других экспер-
тов. Анализ этих перечней влияет на мнения экспертов, и
при следующей итерации они готовят измененные перечни
рисков. За несколько итераций можно получить перечень
рисков проекта, согласованный с большинством опрошен-
ных экспертов. Число итераций опроса экспертов зависит:
x от числа экспертов;
x их опыта и компетенции;
x независимости;
x отсутствия предвзятости мнений.
3. Интервьюирование участников проекта. В ходе интервьюи-
рования участников проекта следует выяснить причины их
предположений о наличии в проекте тех или иных рисков.
4. SWOT-анализ. Проведение данного анализа часто осно-
вано также на мозговом штурме, в ходе которого выявля-
ются внутренние факторы — сильные и слабые стороны
организации (strengths and weaknesses) — и внешние фак-
торы — возможности и угрозы во внешней среде проекта
(opportunities and threats). Сильные стороны и возможности
являются источниками позитивных рисков, а слабые сторо-
ны и угрозы — негативных.
! Комментарий из практики. При идентификации рисков мо-

жет быть выявлено большое количество рисков. Например, может
оказаться, что в проекте 50 рисков, а в команде всего пять человек.
Конечно, такая команда не может управлять всеми 50 рисками,
ресурсов явно недостаточно. В этом случае необходимо ранжи-
ровать риски по приоритетности. Например, в ходе дальнейшего
качественного анализа рисков команда может оценить значения
вероятности, влияния, подсчитать величину рисков для каждого
из них и распределить риски по значениям их величин. Первые 10
рисков с самыми высокими значениями величин (Top ten) долж-
ны быть в поле пристального внимания команды. Риски, начиная
с 11-го в этом списке, как правило, уже не представляют значи-
тельной угрозы (для негативных рисков) и не открывают больших
возможностей (для позитивных рисков), за ними можно оставить
факультативное наблюдение. Тем не менее это наблюдение долж-
но иметь место, так как риски — явления с высокой динамикой,
и в любой момент риск с 20-й позиции может переместиться на
пятую, и наоборот.
Миграция рисков — изменение приоритетов рисков в ходе

проекта.
176 Глава 8
Миграция рисков возможна в случае:

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

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

ции рисков
x LL-11.2.1. Идентификация рисков должна быть результа-
том коллективного обсуждения в команде проекта, жела-
тельно в форме мозгового штурма.
x LL-11.2.2. Если руководитель проекта не советуется с чле-
нами команды по вопросам управления рисками, тем са-
мым он привносит в проект дополнительные риски, свя-
занные с доминированием его личного мнения и субъек-
тивных представлений.
x LL-11.2.3. При идентификации рисков проекта необхо-
димо анализировать не только официальные документы
проекта, но и любые другие информационные источники,
относящиеся к проекту и его окружению (в том числе не-
официальные и не подкрепленные документами).
x LL-11.2.4. При большом количестве идентифицирован-
ных рисков проекта желательно проводить ранжирование
рисков по принципу первой десятки. В нее входят риски
с наибольшими значениями величин (произведения оце-
нок вероятности и влияния). Рискам внутри первой де-
сятки в обязательном порядке должны быть назначены от-
ветственные за них (risk owners). Как правило, риски, не

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

Процесс: качественный анализ рисков
Рис. 38. Процесс качественного анализа рисков в группе про

178 Глава 8
Основные цели качественного анализа рисков проекта

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

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

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

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

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

рисков необходимо провести анализ их параметров и величин и
определить:
y перечни рисков, сгруппированных по категориям (например,
по влиянию на различные области проекта или относящиеся
к различным этапам проекта);
y риски, требующие особого внимания, реагировать на кото-
рые необходимо в короткие сроки (это могут быть, например,
первые три риска из первой десятки);
y риски, для которых необходим дальнейший дополнительный
анализ;
y перечень рисков c низкими значениями величин, за кото-
рыми будет выполняться факультативное наблюдение (watch
lists).
Извлеченные уроки, или что показал опыт качественно-

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

лению рисками. Причиной некачественных оценок пара-
метров риска может быть отсутствие экспертной власти у
x LL-11.3.2. При обнаружении и идентификации нового
риска проекта важно проанализировать его влияние на
параметры старых (идентифицированных ранее) рисков
внутри первой десятки (top ten). Новый риск может как
усилить, так и ослабить влияние старых рисков.
x LL-11.3.3. Совместное влияние негативных рисков может
оказаться губительным для проекта. Поэтому важно про-
анализировать эффекты, возникающие при одновремен-
ном действии различных рисков внутри первой десятки.
Может возникнуть ситуация, при которой чистые риски
(возможно, никак не связанные друг с другом по сути) при
одновременном возникновении «убивают» проект своим
совместным влиянием.

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

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

деление лучшего способа управления ими в условиях неопре-

деленности.
Основными инструментами количественного анализа рис-
ков являются следующие.
1. Анализ чувствительности. Он показывает, какие риски об-
ладают наибольшим потенциальным влиянием на проект.
Применение данного метода позволяет команде проекта
оценить, как изменяются показатели проекта при различ-
ных значениях заданных переменных, необходимых для
расчета. Этот анализ позволяет определить критические пе-
ременные (sensitive factors), которые в наибольшей степени
могут повлиять на результаты проекта, его осуществимость
и эффективность.
182 Глава 8
2. Анализ ожидаемой денежной величины (expected monetary

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

и рискованного, но приводящего к большему выигрышу,
или, наоборот, более благоразумного и осторожного, но
приводящего к меньшему проигрышу) связан с уровнем то
лерантности компании к рискам и с выбранной стратегией
ведения бизнеса — агрессивной или консервативной.
3. Метод Монте-Карло. Это сложная методика, основанная на

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

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

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

Процесс: планирование реагирования на риски
Основные цели планирования реагирования на риски
проекта:
x выбор стратегии (или нескольких стратегий) реагирования
на риски проекта;
x разработка плана работ по реализации выбранных страте-
гий реагирования.
184 Глава 8
Рис. 40. Процесс планирования реагирования на риски проекта

в группе процессов планирования
Интерпретация процесса планирования реагирования

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

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

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

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

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

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

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

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

часто необходимо использовать стратегию снижения риска, ко-
торая требует привлечения дополнительных ресурсов. Любой
ресурс стоит денег, поэтому для реагирования на чистые риски
необходимо формировать резервы бюджета проекта.
Резерв бюджета проекта, используемый руководителем про-
екта для реагирования на известные риски (contingency reserve),
формируется по результатам качественного и количественного
анализа рисков. Суммарная величина всех чистых известных
рисков, выраженных в денежных единицах, составляет резерв
бюджета проекта на известные риски. При отсутствии точных
оценок и обоснований рекомендуемая величина данного ре-
зерва составляет порядка 10% от бюджета проекта, т. е. от сово-
купной стоимости работ проекта. В случае несложного содер-
жания проекта и хорошо известных рисков, когда можно про-
извести более точные расчеты и обосновать размер резерва, его
величина может составить и менее 10% от бюджета проекта. Но
если проект сложный и точно рассчитать риски невозможно,
рекомендуемая величина резерва на известные риски составля-
ет порядка 10% от бюджета проекта.
NB! В сложных комплексных проектах чистые известные ри

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

ства (management reserve), используемый для реагирования на
неизвестные риски.
NB! Резерв на известные риски является резервом руково

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

риски, приводящие к финансовым потерям в проекте, рекоменду-
ются четыре типа действий (рис. 41).
Рис. 41. Действия при реагировании на чистые риски
1. Поиск альтернативного решения. При высокой вероятности

риска и относительно низких финансовых потерях рекомендуется
искать альтернативное решение, чтобы избежать данного риска.
Хотя потери бюджета и не велики, тем не менее альтернативное
188 Глава 8
решение (например, выбор альтернативного поставщика, альтер-

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

реагирования.
x Использование риска (risk exploit), т. е. максимальное ис-
пользование положительного эффекта риска в интересах
проекта. Использование требует привлечения лучших ре-
сурсов проекта на выполнение тех работ, в которых иден-
тифицирован позитивный риск.
x Совместное использование риска (risk share), т. е. ис-
пользование эффекта от позитивного риска совместно с
заказчиками, партнерами, конечными пользователями ре-
зультатов проекта. Примером совместного использования
риска может быть акционирование компании, продажа
акций на фондовом рынке, привлечение новых партнеров.
x Усиление риска (risk enhance), т. е. увеличение риска пу-
тем проведения действий, повышающих вероятность воз-
никновения риска и его влияние. Усиление риска также
требует привлечения дополнительных ресурсов на выпол-
нение тех работ, в которых идентифицирован позитивный
риск.
x Принятие риска (acceptance) при наличии бизнес-риска.
Это стратегия, при которой команда осознанно идет на
риск и не предпринимает шагов по управлению данным
вероятным событием. Это событие может не представлять
значительной угрозы либо интересной возможности и не
сулить проекту какого-то серьезного ущерба или приоб-
ретения. Стратегия принятия также возможна в ситуации,
когда, несмотря на значительную угрозу, компания вынуж-
дена идти на риск и принимать его ради достижения важ-
ных для нее целей, например расширения доли рынка или
удержания стратегического заказчика.
Стратегии реагирования на предопределенные события раз-
рабатываются для реагирования на риск, возникающий только
при определенном событии (например, срыве сроков опреде-
ленной работы или повышении приоритета определенной по-
ставки и т. п.).
Остаточные риски — это риски, которые остаются, не-
смотря на применение стратегий реагирования, и требуют
190 Глава 8
дополнительных способов реагирования. Например, попытка

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

ния реагирования на риски проекта
x LL-11.5.1. План реализации выбранных стратегий реагиро-
вания становится частью плана проекта и требует выделе-
ния ресурсов проекта на его выполнение.
x LL-11.5.2. Иногда руководители проекта настолько увле-
каются управлением рисками проекта, что забывают об
управлении самим проектом.

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

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

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

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

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

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

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

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

рисками проекта
x LL-11.6.1. Аудит планов реагирования на риски проекта
является функцией риск-менеджера, обладающего полно-
той полномочий и независимостью от локального менедж-
мента компании.
x LL-11.6.2. Решение по анализу миграции рисков и изме-
нению планов реагирования принимается коллегиально
после обмена мнениями между ответственными за риски,
руководителем проекта и риск-менеджером.
/ Бизнес*кейс: проект «Разработка и

внедрение CRM*системы»
Проблемная ситуация. Выбор стратегии реагирования на
риски должен учитывать ресурсоемкость и стоимость работ,
необходимых для реализации выбранной стратегии. Слишком
дорогая или длительная в реализации стратегия реагирования
становится бессмысленной. Если принятие последствий риска
неприемлемо для проекта, то следует выбирать альтернативу с
наименьшей стоимостью и/или длительностью реализации.
Описание бизнес-кейса. Руководитель проекта отвечал

за разработку и внедрение у заказчика CRM-системы (систе-
194 Глава 8
мы управления взаимодействиями с клиентами — Customer

Relationship Management — CRM), включая поставку оборудо-
вания и разработку программного обеспечения. Субподрядчик
проекта, отвечающий за разработку программного продукта,
сообщил руководителю проекта о невозможности завершения
работ в запланированные сроки и о необходимости дополни-
тельного финансирования, чтобы привлечь дополнительные
ресурсы и выдержать график. Размер дополнительного фи-
нансирования должен был составить порядка 10% от полной
стоимости разработки. Заказчик проекта отказался выделять
дополнительные средства. Тогда руководитель проекта предло-
жил завершить разработку основных функций системы к уста-
новленному сроку, а незначительные сервисные функции отла-
дить позднее.
Этот вариант оказался приемлемым для заказчика. Руко-
водитель проекта переработал план разработки программного
продукта таким образом, что сроки сдачи основного функци-
онала, необходимого для обеспечения работоспособности сис-
темы, остались прежними, а сдача вспомогательных сервисных
функций была отложена на полтора месяца. План был согла-
сован с заказчиком и субподрядчиком, и разработка системы
была завершена в соответствии с ним.
Выводы и рекомендации. На многие чистые риски про-

екта приходится реагировать методом снижения рисков (risk
mitigation). Снижение требует привлечения дополнительных
ресурсов и вызывает удорожание проекта. Но можно поискать
компромиссное решение, устраивающее стейкхолдеров проек-
та и не требующее привлечения дополнительных ресурсов.
ГЛАВА 9
Управление закупками проекта
Значение области знаний «Управление закупками проек-

та» в стандарте PMI PMBOK®. В данной области стандарта
описана одна из десяти ключевых компетенций руководителя
проекта по управлению закупками продуктов и услуг, которые
осуществляют внешние по отношению к проекту организации.
Четыре процесса, рекомендованные стандартом в данной об-
ласти, относятся к группам процессов планирования, исполне-
ния, мониторинга/контроля и завершения (табл. 12).
Таблица 12
«Управление закупками проекта»
Планирование управления закупками Планирование
Организация проведения закупок Исполнение
Контроль закупок Мониторинг и контроль
Закрытие закупок Завершение


управление закупками проекта
Процесс: планирование управления закупками
196 Глава 9
Рис. 43. Процесс планирования управления закупками проекта в

Основные цели планирования управления закупками

проекта:
x провести анализ: покупать или производить самим (make
or buy);
x определить: если покупать, то у кого, когда, в каких объ-
емах и на основе какого контракта.
Интерпретация процесса планирования управления за-

купками проекта и рекомендации по его применению на
Управление закупками проекта 197
практике. Данный процесс должен определить подходы к

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

ководитель проекта должен активно взаимодействовать
со специалистами подразделений организации, отвеча
ющими за операционную деятельность по закупкам и по
ставкам, которые являются экспертами в данной области.
Это могут быть административные, хозяйственные отде
лы или отделы материальнотехнического обеспечения
(purchasing and procurement departments).
Решение производить самим или покупать «на стороне»

(make or buy decision) является результатом анализа ряда воп-
росов, в том числе:
x что дешевле;
x насколько объемной является поставка;
x содержат ли результаты поставки конфиденциальные све-
дения организации заказчика;
x есть ли на рынке надежные поставщики?
NB! В данном процессе руководитель проекта является за

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

щиками.
1. Контракты с фиксированной ценой (fixed price). Заклю-
чаются при заказе продуктов, обладающих четкими физиче-
скими характеристиками. Контракт c фиксированной ценой
является контрактом с наименьшим риском для заказчика и
с максимальным риском для поставщика. В таком контракте
цена зафиксирована и представляет конечную величину. Если
198 Глава 9
по каким-либо причинам стоимость работ поставщика возрас-

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

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

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

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

рон — как покупатель, так и продавец — стремится снизить
свои риски.
Основными источниками оценки рисков продавца и поку-
пателя при заключении контракта являются:
x описание продукта поставки;
x тип контракта;
x критерии приемки результатов поставки.
Важными инструментами данного процесса являются также
экспертные оценки, анализ рынка и совещания.
Экспертные оценки часто используются для оценки вхо-
дов и выходов из этого процесса. Экспертные оценки покупки
также используются для разработки или изменения критериев,
которые будут применяться для оценки предложений продав-
цов. Экспертная юридическая оценка может включать услуги
юрисконсульта организации для оказания помощи по вопро-
сам уникальных закупок и условий. Такие оценки, включая де-
ловые и технические экспертизы, могут применяться к техни-
ческим деталям приобретаемых товаров, услуг или результатов
и к различным аспектам процессов управления закупками.
Анализ рынка включает изучение отрасли и возможностей
конкретных поставщиков. Закупочные команды могут исполь-
зовать информацию, полученную на конференциях, из онлай-
новых обзоров и различных источников для выявления рыноч-
ных возможностей. Команда может также уточнять задачи кон-
кретных закупок с учетом развивающихся технологий во время
балансировки рисков, учитывая число поставщиков, которые
могут предоставить желаемые материалы или услуги.
Исследования сами по себе не могут представить конкрет-
ную информацию для разработки стратегии закупок без допол-
нительного взаимодействия с потенциальными участниками
торгов. Совещания с потенциальными участниками торгов при
покупке материалов или услуг могут принести пользу компа-
нии, в то же время поставщик может влиять на взаимовыгод-
ный подход или результат.
Основным результатом данного процесса является получе-
ние ответов на следующие вопросы.
200 Глава 9
x Что и в каких количествах приобретать у внешних постав-

щиков?
x Когда приобретать (в соответствии с расписанием про-
екта)?
x Какой тип контракта выбрать?
x Каким может быть круг потенциальных поставщиков?

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

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

Интерпретация процесса организации проведения заку-

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

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

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

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

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

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

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

проведения закупок проекта
x LL-12.2.1. Для участия в конференции контрагентов долж-
ны быть приглашены все потенциальные участники тенде-
204 Глава 9
ра, чтобы они одновременно получили всю дополнитель-

ную информацию и был соблюден принцип их равного
участия в конкурсе (equal footing principle).
x LL-12.2.2. В составлении списка аттестованных поставщи-
ков принимают участие службы безопасности компании,
отсеивающие неблагонадежных поставщиков (screening
procedure).

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

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

ринга и контроля
x анализ и документальное оформление текущей и прошлой

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

ставки означает освоение объема поставки, т. е. появле
ние оcвоенного объема плановых работ (earned value), и
206 Глава 9
дает поставщику возможность выставить заказчику счет

на оплату поставки. Факт оплаты принятых работ будет
означать появление фактических расходов проекта (actual
cost).
Основные обязанности руководителя проекта в данном про-

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

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

купок проекта
x LL-12.3.1. Оплата поставки может быть отнесена на сле-
дующий за текущим финансово-отчетный период. В этом
случае руководитель проекта должен оповестить о необ-
ходимости оплаты поставки в следующем за текущим фи-
нансово-отчетном периоде финансовый орган компании
(accruals request).

Группа процессов: завершение
Процесс: закрытие закупок
Основные цели закрытия закупок проекта — подтверж-
дение содержания закупки и административное завершение
контракта.
Интерпретация процесса закрытия закупок проекта и

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

шения
NB! Досрочное завершение контракта является частным

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

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

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

включать:
x первоначальный запрос на предложение (request for pro-
posal) и все его модификации;
x копии предложения и всех поправок к нему;
x протоколы переговоров;
x корреспонденцию по контракту;
x подписанные оригиналы (или ксерокопии) контракта и
всех дополнительных соглашений к нему;
x акты сдачи-приемки;
x счета и платежные поручения.
Извлеченные уроки, или что показал опыт закрытия за-

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

плексное обеспечение сети гипермаркетов торговым обору-
210 Глава 9
дованием, включая поставку автоматизированных кассовых

аппаратов (point of sale, POS), заключила с компанией – раз-
работчиком POS наименее рискованный контракт с фиксиро-
ванной ценой (fixed price). Однако при подготовке поставки
выяснилось, что поставщик POS собирается разорвать подпи-
санный контракт. Причина заключалась в том, что конкури-
рующая сеть гипермаркетов предложила купить у поставщика
большую партию POS по более высокой цене, также заключив
с ним контракт с фиксированной ценой. Возник риск потерять
поставщика POS. Руководитель проекта решил провести с по-
ставщиком дополнительные переговоры и предложил отказать-
ся от контракта с фиксированной ценой и заключить контракт
с возмещением стоимости (cost reimbursable contract). Условия
данного контракта гарантируют поставщику полную компенса-
цию стоимости работ (cost), и, более того, в случае досрочной
поставки POS (без потери качества оборудования) поставщик
получает дополнительное вознаграждение, составляющее его
чистую прибыль. Поставщик POS оценил новое предложение
и быстро пришел к выводу, что выгоднее сохранить существу-
ющего заказчика, так как на поставке по контракту с возмеще-
нием стоимости он сможет заработать больше, чем по контрак-
ту с фиксированной ценой для конкурирующей сети гипермар-
кетов.
Руководителю проекта удалось избежать потери поставщика
оборудования POS.
Выводы и рекомендации. Несмотря на дополнительные

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

сторонами проекта» в стандарте PMI PMBOK®. В данной
области стандарта описана одна из десяти ключевых компетен-
ций руководителя проекта по управлению заинтересованными
сторонами (стейкхолдерами) проекта. Четыре процесса, реко-
мендованные стандартом в данной области, относятся к груп-
пам процессов инициации, планирования, исполнения, мони-
торинга/контроля (табл. 13).
Таблица 13
Процессы и группы процессов области знаний «Управление
заинтересованными сторонами проекта»
Идентификация заинтересованных сторон Инициация
Планирование управления заинтересованны

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

ных сторон Исполнение
Контроль вовлеченности заинтересованных

сторон Мониторинг и контроль

212 Глава 10
13.1. Область знаний: управление

заинтересованными сторонами проекта
Группа процессов: инициация
Процесс: идентификация заинтересованных сторон проекта
Рис. 47. Процесс идентификации заинтересованных сторон про

екта в группе процессов инициации
Основные цели идентификации заинтересованных сто-

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

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

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

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

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

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

интересованными сторонами и рекомендации по его при-
менению на практике. Данный процесс позволяет команде
Рис. 48. Процесс планирования управления заинтересованными

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

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

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

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

ния управления заинтересованными сторонами проекта
x LL-13.2.1. Активные коммуникации со стейкхолдерами,
занимающими нейтральную позицию по отношению к
проекту, могут создать условия для их миграции в группу
стейкхолдеров, поддерживающих проект. Отсутствие таких
активных коммуникаций приводит к риску их миграции в
группу стейкхолдеров, не поддерживающих, а препятству-
ющих развитию проекта.
x LL-13.2.2. Следует уделять внимание тем стейкхолдерам,
которые определены руководством в качестве членов кад-
рового резерва организации. Активные коммуникации с
ними и целенаправленное информирование о полезности
и выгодах проекта для организации могут способствовать
поддержке проекта при их назначении на руководящие по-
зиции.
218 Глава 10

Процесс: управление вовлеченностью заинтересованных
сторон проекта
Рис. 49. Процесс управления вовлеченностью заинтересован

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

ванных сторон проекта:
x активное общение и работа с заинтересованными сторо-

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

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

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

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

вовлеченностью заинтересованных сторон проекта
x LL-13.3.1. Руководитель проекта отвечает за участие и
управление различными заинтересованными сторонами в
рамках проекта и может обратиться при необходимости за
помощью к спонсору проекта.
x LL-13.3.2. Способность заинтересованных сторон влиять
на проект высока на начальных этапах и снижается в про-
цессе исполнения проекта.

Процесс: контроль вовлеченности заинтересованных
сторон проекта
Основные цели контроля вовлеченности заинтересован-
ных сторон проекта:
Рис. 50. Процесс контроля вовлеченности заинтересованных

сторон проекта в группе процессов мониторинга и контроля
x мониторинг общих отношений заинтересованных сторон

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

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

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

влеченности заинтересованных сторон проекта
x LL-13.4.1. Для обеспечения всеобъемлющей идентифика-
ции и учета вновь появляющихся заинтересованных сто-
рон может выполняться пересмотр текущего состава заин-
тересованных сторон.
x LL-13.4.2. Информация о решенных проблемах и одобрен-
ных изменениях регулярно предоставляется заинтересо-
ванным сторонам проекта.
/ Бизнес*кейс: проект «Внедрение ERP*

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

ная группа инициировала проект по внедрению ERP-системы
(enterprise resource planning) в штаб-квартире группы и на
пяти промышленных и торговых предприятиях. Инициатором
внедрения системы выступил генеральный директор группы,
который обосновал владельцам бизнеса необходимость такой
системы, позволяющей консолидировать всю проектную и
операционную деятельность группы через единую систему пла-
нирования и финансовой отчетности.
Руководителем проекта был назначен директор проектно-
го офиса группы, который уже на этапе инициации проекта
провел идентификацию заинтересованных сторон и разрабо-
тал план управления стейкхолдерами проекта. Ключевое вни-
мание в этом плане уделялось регулярным коммуникациям с
генеральным директором — заказчиком проекта и основным
акционером — спонсором проекта. Руководитель проекта ре-
гулярно докладывал им о статусе работ проекта и эскалировал
возникающие проблемы, оперативное разрешение которых
свидетельствовало о значительной организационной поддерж-
224 Глава 10
ке проекту со стороны заказчика и спонсора. Однако многие

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

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

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

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

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

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

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

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

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

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

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

анализ рисков проекта, которому посвящены отдельные совещания о
статусе рисков (в процессе мониторинга и контроля за рисками проекта).
Процесс: общее управление изменениями (4.5)
Изменения базового плана проекта, являющиеся результатом приня

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

шение этапа (или фазы) проекта до начала работ следующего этапа.
Процесс: сбор требований (5.2)
Следует отличать данный процесс сбора требований стейкхолдеров

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

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

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

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

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

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

ти работ, даты старта и финиша появятся позже — при разработке на
основе ИСР расписания проекта.
По завершении создания ИСР в проекте формируется базовый план

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

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

ное событие (веху), которое свидетельствует о выполнении всех опе
раций пакета.
Процесс: определение последовательности операций (6.3)

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

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

кроме финансовых ресурсов. Оценка финансовых ресурсов и форми
рование бюджета проекта проводятся при оценке стоимости опера
ций в процессе стоимостной оценки проекта.
Процесс: оценка длительности операций (6.5)
Наибольший риск возникает при оценке длительности уникальных опе

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

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

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

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

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

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

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

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

финансирования этапов работ и утвердить требования к финансиро
ванию проекта в финансовом органе компании — заказчика проекта.
Процесс: контроль стоимости (7.4)
Основной задачей руководителя проекта в процессе контроля стои

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

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

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

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

бот проекта. Устранять ошибки и брак в характеристиках продукта не
придется, если предотвратить появление ошибок в работах проекта.
Процесс: обеспечение качества (8.2)
Обеспечение качества предполагает аудит процесса создания про

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

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

(9.1)
Организационная диаграмма проекта, представляющая в графи

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

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

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

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

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

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

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

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

та — его стремление стать известной личностью в организации и
приобрести связи и влияние.
Процесс: планирование управления коммуникациями (10.1)

90% своего времени руководитель проекта посвящает всевозмож

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

котором самих рисков нет. Риски появляются на выходе другого про
цесса — идентификации рисков.
На совещаниях команды проекта, посвященных анализу статуса рис

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

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

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

рисками проекта, потому что существует риск упустить эти возмож
ности и, как правило, уже навсегда.
Составляющая неизвестности, неопределенности всегда присутству

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

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

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

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

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

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

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

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

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

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

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

виртуальным членом команды проекта.
Процесс: планирование управления поставками (12.1)
В процессе планирования поставок руководитель проекта должен

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

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

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

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

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

ние фактических расходов проекта.
Процесс: закрытие поставок (12.4)
Досрочное завершение контракта является частным случаем процес

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

этапов проекта с финансовым органом компании — заказчика про
екта необходимо для обеспечения наличия финансовых средств для

оплаты выполненных этапов в соответствии с расписанием проекта.
Изменения стоимости работ проекта, не затрагивающие изменения

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

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

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

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

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

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

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

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

(9.1)
В организационной диаграмме проекта желательно отражать при

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

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

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

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

Для выявления мотива признания у члена команды необходимо опре

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

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

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

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

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

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

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

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

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

ство рисков. Например, в проекте может быть идентифицировано 50
рисков, а в команде всего пять человек. Конечно, с такой командой
невозможно управлять всеми 50 рисками, ресурсов явно недостаточ
но. В этом случае необходимо определить приоритетность рисков.
В ходе дальнейшего качественного анализа рисков команда может
оценить вероятность для каждого из них, влияние на проект и ран
жировать риски по этим величинам. Первые 10 рисков с самыми вы
сокими значениями (top ten) должны быть в зоне пристального вни
мания команды. Риски, начиная с 11го в этом списке, как правило,
уже не представляют значительной угрозы (для негативных рисков)
или большой возможности (для позитивных рисков), за ними можно
оставить факультативное наблюдение. Тем не менее это наблюдение
должно иметь место, так как риски отличаются высокой динамикой и
в любой момент риск с 20й позиции может переместиться на пятую
и наоборот.
Процесс: качественный анализ рисков (11.3)
Иногда в ходе качественного анализа рисков возникает ситуация, при

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

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

При реагировании на чистые риски, приводящие к финансовым поте

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

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

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

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

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

Во внешних проектах автором устава может быть продавец, подпи

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

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

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

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

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

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

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

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

за от плановых показателей могут быть отсутствие своевременных
решений по существенным изменениям базового плана либо некор
ректное прохождение проверок успеха проекта (kill points) по завер
шении фаз проекта.
Регулярные совещания о статусе проекта рекомендуется проводить

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

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

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

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

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

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

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

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

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

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

Результаты сбора и анализа требований конечных пользователей

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

проекта могут породить неоправданно завышенные ожидания заказчи
ка. Например, заказчик может ожидать по результатам проекта повыше
ния эффективности операционных процессов на 5%, а реальное повы
шение составит лишь 1%. Согласится ли он принять такой результат?
При фиксации границ проекта мы указываем, что не входит в содер

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

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

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

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

даты старта и финиша) будут определены при разработке расписа
ния проекта на основе ИСР.
Рекомендация о длительности пакетов работ ИСР (80 ч) — един

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

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

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

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

проверки содержания.
Процесс: контроль содержания (5.6)
В процессе контроля содержания полезным документом является

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

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

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

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

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

мировать руководителя проекта об использовании и остатках вре
менных резервов расписания. Например, при резерве расписания в
размере 10% от общего срока проекта инструмент разработки рас
писания может автоматически генерировать уведомление руково
дителю проекта о достижении контрольного порога в 8% резерва и
остатке резерва в 2%.
Состав операций (элементарных работ проекта), определяемый при

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

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

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

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

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

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

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

потерять бîльшие средства изза неверной оценки длительности.
Анализ временных резервов операций проводится на основе анализа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

продукта проекта на основе созданных им контрольных списков.
Метрики и контрольные листы должны соответствовать одним и тем

же стандартам качества, выбранным для конкретного проекта.
Процесс: обеспечение качества (8.2)
Эксперт по качеству проводит проактивный аудит качества основных

результатов проекта в процессе их создания.
Эксперт по качеству является «виртуальным» членом команды проек

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

проекта.
Эксперт по качеству обладает правом эскалации проблем проекта на

любой уровень, включая спонсоров и руководящий комитет проекта.
Процесс: контроль качества (8.3)
Регулярные коммуникации контролера качества с экспертом по

качеству позволяют обеспечить более целенаправленные и эффек
тивные обзоры работ проекта.
Обеспечение качества важнее, чем контроль качества. Если не обес

печить качество работ проекта, то результат проекта (его продукт) не
пройдет контроль качества и будет уже поздно!
В случае обнаружения дефектов продукта контролер качества обязан

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

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

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

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

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

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

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

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

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

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

никациями несет администратор проекта.
Процесс: управление коммуникациями (10.2)
В коммуникациях с заказчиками проекта иногда полезно создавать ил

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

почте желательно быть предельно кратким и ясным. Максимальный
объем сообщения не должен превышать половины экрана.
Процесс: контроль коммуникаций (10.3)
Регулярные совещания о статусе проекта следует проводить ежене

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

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

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

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

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

суждения в команде проекта. Обсуждение может проводиться в фор
ме «мозгового штурма».
Если руководитель проекта не советуется с членами команды по воп

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

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

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

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

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

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

одновременном возникновении «убьют» проект своим совместным
влиянием.
Процесс: количественный анализ рисков (11.4)
Количественный анализ рисков требует существенной и статистичес

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

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

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

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

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

вания принимается коллегиально ответственными за риски, руково
дителем проекта и рискменеджером.
Процесс: планирование управления закупками (12.1)
В процессе планирования закупок важно использовать экспертные

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

работ по организации проведения тендеров и поставок.
Процесс: осуществление закупок (12.2)
Для участия в конференции контрагентов должны быть приглашены

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

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

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

ставок на этапах организации и проведения тендеров, а также заклю
чения контрактов, выполнения поставок и проведения оплаты приня
тых поставок.
Процесс: идентификация заинтересованных сторон (13.1)
Реестр участников динамично меняется в ходе жизненного цикла

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

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

нами (13.2)
Активные коммуникации со стейкхолдерами, занимающими ней

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

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

рон (13.3)
Руководитель проекта отвечает за участие и управление различными

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

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

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

лярно предоставляется заинтересованным сторонам проекта.
Глоссарий
Acceptance – одобрение планов, результатов работ проекта

или запросов на изменение.
Accruals request – оповещение руководителем проекта финан-
сового органа компании о необходимости оплаты поставки
в следующем за текущим финансово-отчетном периоде.
Bid conference – конференция контрагентов.
Black lists – черный список, содержащий перечни компаний с
сомнительной репутацией на рынке.
Body language – язык телодвижений.
Bottom-up – оценка «снизу вверх».
Business risk – риск, представляющий одновременно и угрозу,
и возможность.
Change control board – комитет по управлению изменениями.
Change request form – форма запроса на изменение.
Check lists – контрольные списки по качеству.
Contingency reserve – резерв руководителя проекта на управ-
ление рисками проекта.
Cost reimbursable contract – контракт с возмещением
стоимости.
Crashing – «сжатие расписания» путем привлечения дополни-
тельных ресурсов для выполнения критических работ, при-
водящее к сокращению их длительности и длительности
проекта в целом.
Customer expectations – ожидания заказчика от использова-
ния результатов проекта.
Definitive estimate – точная оценка.
Expected Monetary Value (EMV) – ожидаемая денежная ве-
личина.
End-user expectations – ожидания конечных пользователей
продуктов от результатов проекта.
Глоссарий 261
Equal footing principle – принцип равного участия в конкурсе

всех контрагентов.
Face to face communications – регулярные личные встречи.
Fast tracking – «быстрый проход» расписания путем распарал-
леливания работ, лежащих на критическом пути, приводя-
щий к сокращению критического пути проекта.
Finish-to-finish – зависимость между операциями проекта
типа «окончание к окончанию» (логическая взаимосвязь,
при которой завершение одной работы невозможно до за-
вершения другой работы).
Finish-to-start – зависимость между операциями проекта типа
«окончание к началу» (логическая взаимосвязь, при которой
работа начинается после того, как заканчивается предыду-
щая).
Fish-bone or cause and effect diagram – причинно-следствен-
ная диаграмма.
Fixed price contract – контракт с фиксированной ценой.
Full time – полная загрузка ресурса.
Giving feedback – процесс предоставления отзыва о работе
коллеги.
Go-no-go decision making – принятие решения о старте про-
екта (go) либо об отказе от проекта (no go).
Hard skills – техническая компетентность специалиста и зна-
ние им технологий создания продуктов.
Human Ressources (HR) – служба персонала компании.
In scope – то, что входит в утвержденное содержание работ
проекта и относится к утвержденным характеристикам про-
дукта.
Influence – влияние.
Issue log – журнал регистрации потенциальных проблем.
Job description – должностная инструкция.
Kill points or stage gates – этапы, на которых проверяется
успешность хода проекта и принимаются решения о целесо-
образности его продолжения.
Known unknown – неопределенность, характер которой извес-
тен.
Leadership – лидерство.
262 Глоссарий
Lessons learned – извлеченные уроки.

Make-or-buy decision – решение о собственном производстве
или закупке.
Management reserve – резерв руководства на управление рис-
ками проекта.
Metrics – метрики качества.
Milestone chart – план вех, контрольных точек проекта.
Mind games and imaginations – «игра ума и воображения»
Moving wave – разработка плана управления проектом на ос-
нове метода «бегущей волны» и постепенного уточнения
планов последующих этапов проекта по мере получения ре-
зультатов предыдущих этапов.
Multinational project team – многонациональная команда
проекта.
Opportunities and threats – возможности и угрозы внешней
среды проекта.
Opportunity – возможность, позитивный риск.
Order of magnitude – оценка «порядок величины».
Out of scope – то, что не входит в утвержденное содержание
работ проекта и не относится к списку утвержденных харак-
теристик продукта.
Over time – сверхурочная работа.
Overlapping activities – наложение групп процессов друг на
друга в ходе жизненного цикла проекта.
Part time – частичная загрузка ресурса.
Postpone – решение отложить рассмотрение изменения.
Program Evaluation Review Technique (PERT) – оценка по
трем точкам.
Progress reporting – регулярные отчеты о продвижении про-
екта.
Project baseline – базовый план проекта, официально утверж-
денный документ, относительно которого измеряется вы-
полнение проекта и который используется для управления
проектом и контроля за его исполнением.
Project deliverables – промежуточные измеримые и проверяе-
мые результаты этапов проекта.
Рroject feasibility study – технико-экономическое обоснова-

ние проекта, включающее анализ выгодности, выполнимос-
ти, привлекательности будущего проекта и его результатов,
соответствия целей проекта целям и задачам организации.
Project key stakeholders – ключевые участники проекта.
Project kick-off meeting – совещание по определению содер-
Project office – администратор проекта.
Project progress report – отчет о продвижении проекта.
Project re-start – возобновление работ проекта.
Project risk review meetings – регулярные совещания команды
по статусу рисков проекта.
Project schedule – календарный план-график проекта.
Project scope statement – документ, описывающий содержа-
ние проекта.
Project stakeholders – лица или организации, участвующие в
проекте. Их интересы могут быть затронуты проектом: они
могут как выиграть, так и пострадать.
Project status report – отчет о статусе проекта.
Project status review meetings – периодические совещания ко-
манды о статусе проекта.
Project trend report – отчет о прогнозе проекта.
Purchasing and procurement department – отдел материально-
технического обеспечения и т. п.
Pure risk – чистый, негативный риск.
Quality assurance – обеспечение качества работ проекта (роль
эксперта по качеству).
Quality control – контроль качества характеристик продукта
проекта (роль контролера качества).
Responsibility Assignment Matrix (RAM) – матрица ответ-
ственности.
Receiving feedback – процесс получения отзыва о собственной
работе от коллеги.
Reject – решение отклонить изменение.
Risk acceptance – принятие риска.
Risk avoidance – избежание риска.
Risk enhance – усиление риска.
264 Глоссарий
Risk exploit – использование риска.

Risk mitigation – снижение риска.
Risk owners – ответственные за риски.
Risk share – совместное использование позитивного риска.
Risk transference – передача риска.
Scope creep – «расползание» границ проекта, т. е. эффект, при
котором содержание проекта или характеристики продукта
перестают соответствовать утвержденным.
Screening – процедуры поиска сведений о неблагонадежных
поставщиках.
Sensitive factors – критические переменные.
Soft skills – навыки межличностного общения (лидерские ка-
чества руководителя проекта и его умение управлять риска-
ми, изменениями, людьми и коммуникациями проекта).
Start-to-finish – зависимость между операциями проекта типа
«начало к окончанию» (логическая взаимосвязь, при кото-
рой завершение одной работы зависит от начала предше-
ствующей работы).
Start-to-start – зависимость между операциями проекта типа
«начало к началу» (логическая взаимосвязь, при которой на-
чало одной работы зависит от начала другой работы).
Strengths and weaknesses – сильные и слабые стороны орга-
низации.
Time and materials contract – с оплатой стоимости затрачен-
ного рабочего времени и материалов.
Top ten – первые десять рисков в проранжированном реестре
рисков.
Top-down – движение «сверху вниз» при декомпозиции работ,
ресурсов и рисков проекта.
Unknown unknown – неопределенность, характер которой не-
известен.
Uplift – надбавка к цене контракта.
Upper and lower control levels – верхний и нижний контроль-
ные уровни.
Watch list – перечень рисков c низкими значениями величин,
за которыми будет выполняться факультативное наблюде-
ние.
Win/lose – стратегия «выигрыш-проигрыш», при которой каж-

дая из сторон в чем-то выигрывает, а в чем-то проигрывает.
Win/win – стратегия «выигрыш-выигрыш» с выгодой для обе-
их сторон.
Work Breakdown Structure (WBS) – иерархическая структура
работ (ИСР).
Wrong customer expectations – неоправданные/неадекватные
ожидания заказчика и конечных пользователей.
Оглавление
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Глава 1. Управление интеграцией проекта . . . . . . . . . . . . . . 13

4.1. Область знаний: управление интеграцией проекта . . . . 14
Группа процессов: инициация . . . . . . . . . . . . . . . . . . . . . . . . 14
Процесс: разработка устава проекта . . . . . . . . . . . . . . . . . . 14
Группа процессов: планирование . . . . . . . . . . . . . . . . . . . . . 18
Процесс: разработка плана УП . . . . . . . . . . . . . . . . . . . . . . . 18
Группа процессов: исполнение . . . . . . . . . . . . . . . . . . . . . . . 22
Процесс: руководство и управление работами проекта 22
Группа процессов: мониторинг и контроль . . . . . . . . . . . 27
Процесс: мониторинг и контроль над работами проекта 27
Процесс: общее управление изменениями . . . . . . . . . . . . 31
Группа процессов: завершение . . . . . . . . . . . . . . . . . . . . . . . 35
Процесс: закрытие проекта или его фазы . . . . . . . . . . . . . 35
Бизнес-кейс: проект «Фондовая биржа» . . . . . . . . . . . . . . . . 38
Глава 2. Управление содержанием проекта . . . . . . . . . . . . . 41

5.1. Область знаний: управление содержанием проекта . . . 42
Процесс: планирование управления содержанием . . . . . 42
Процесс: сбор требований . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Процесс: определение содержания . . . . . . . . . . . . . . . . . . . 50
Оглавление 267

Процесс: создание иерархической структуры работ
(ИСР) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Процесс: подтверждение содержания . . . . . . . . . . . . . . . . . 60
Процесс: контроль содержания . . . . . . . . . . . . . . . . . . . . . . . 62
Бизнес-кейс: проект «Стратегический бомбарди-
ровщик» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Глава 3. Управление сроками проекта . . . . . . . . . . . . . . . . . . 68

6.1. Область знаний: управление сроками проекта . . . . . . . . 69
Процесс: планирование управления расписанием . . . . . 69
Процесс: определение операций . . . . . . . . . . . . . . . . . . . . . . 72
Процесс: определение последовательности операций . 74
Процесс: оценка ресурсов операций . . . . . . . . . . . . . . . . . . 77
Процесс: оценка длительности операций . . . . . . . . . . . . . 80
Процесс: разработка расписания . . . . . . . . . . . . . . . . . . . . . 83
Процесс: контроль расписания . . . . . . . . . . . . . . . . . . . . . . . 89
Бизнес-кейс: проект «Строительство торгово-развле-
кательного центра» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
268 Оглавление
Глава 4. Управление стоимостью проекта . . . . . . . . . . . . . . . 94

7.1. Область знаний: управление стоимостью проекта . . . . . 94
Процесс: планирование управления стоимостью . . . . . . 94
Процесс: оценка стоимости . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Процесс: определение бюджета . . . . . . . . . . . . . . . . . . . . . . . 102
Процесс: контроль стоимости . . . . . . . . . . . . . . . . . . . . . . . . 105
Бизнес-кейс: проект «Покупка компании» . . . . . . . . . . . . . . 110
Глава 5. Управление качеством проекта . . . . . . . . . . . . . . . . 112
8.1. Область знаний: управление качеством проекта . . . . . . . 112
Процесс: планирование управления качеством . . . . . . . . 112
Процесс: обеспечение качества . . . . . . . . . . . . . . . . . . . . . . . 117
Процесс: контроль качества . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Бизнес-кейс: проект «Внедрение системы делопроизвод-
ства в министерстве» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Глава 6. Управление человеческими ресурсами . . . . . . . . . 127
9.1. Область знаний: управление человеческими ресурсами
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Процесс: планирование управления человеческими ре-
сурсами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Процесс: набор команды проекта . . . . . . . . . . . . . . . . . . . . . 131

проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Процесс: развитие команды проекта . . . . . . . . . . . . . . . . . . 136
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Процесс: управление командой проекта . . . . . . . . . . . . . . 141
Бизнес-кейс: проект «Строительство международного
аэропорта» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Глава 7. Управление коммуникациями проекта . . . . . . . . . 150
10.1. Область знаний: управление коммуникациями про-
екта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Группа процессов: планирование . . . . . . . . . . . . . . . . . . . 150
Процесс: планирование управления коммуника-
циями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
екта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Группа процессов: исполнение . . . . . . . . . . . . . . . . . . . . . 155
Процесс: управление коммуникациями . . . . . . . . . . . . . 155
екта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Группа процессов: мониторинг и контроль . . . . . . . . . . 160
Процесс: контроль коммуникаций . . . . . . . . . . . . . . . . . . 160
Бизнес-кейс: проект «Автомобильный концерн» . . . . . . . . 163
Глава 8. Управление рисками проекта . . . . . . . . . . . . . . . . . . 165
11.1. Область знаний: управление рисками проекта . . . . . . . 166
Процесс: планирование управления рисками . . . . . . . . 166
Процесс: идентификация рисков . . . . . . . . . . . . . . . . . . . 171
Процесс: качественный анализ рисков . . . . . . . . . . . . . . 177
270 Оглавление

Процесс: количественный анализ рисков . . . . . . . . . . . . 180
Процесс: планирование реагирования на риски . . . . . 183
Процесс: контроль над рисками проекта . . . . . . . . . . . . 190
Бизнес-кейс: проект «Разработка и внедрение CRM-
системы» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Глава 9. Управление закупками проекта . . . . . . . . . . . . . . . . 195
12.1. Область знаний: управление закупками проекта . . . . . 195
Процесс: планирование управления закупками . . . . . . 195
Процесс: организация проведения закупок . . . . . . . . . . 200
Процесс: контроль закупок . . . . . . . . . . . . . . . . . . . . . . . . . 204
Группа процессов: завершение . . . . . . . . . . . . . . . . . . . . . . 207
Процесс: закрытие закупок . . . . . . . . . . . . . . . . . . . . . . . . . 207
Бизнес-кейс: проект «Оборудование для сети гипермар-
кетов» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Глава 10. Управление заинтересованными сторонами
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
13.1. Область знаний: управление заинтересованными сто-
ронами проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Группа процессов: инициация . . . . . . . . . . . . . . . . . . . . . . 212
Процесс: идентификация заинтересованных сторон
проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
ронами проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Процесс: планирование управления заинтересован-

ными сторонами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
ронами проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Процесс: управление вовлеченностью заинтересо-
ванных сторон проекта . . . . . . . . . . . . . . . . . . . . . . . . . 218
ронами проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Процесс: контроль вовлеченности заинтересованных
сторон проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Бизнес-кейс: проект «Внедрение ERP-системы торгово-
промышленной группы» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Заключение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Комментарии из практики . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Извлеченные уроки, или что показал опыт . . . . . . . . . . 245
Глоссарий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Учебное электронное издание
Серия: «Проекты, программы, портфели»
Павлов Александр Николаевич
УПРАВЛЕНИЕ ПРОЕКТАМИ НА ОСНОВЕ СТАНДАРТА

PMI PMBOK○R
ИЗЛОЖЕНИЕ МЕТОДОЛОГИИ И ОПЫТ ПРИМЕНЕНИЯ
Ведущий редактор Ю. Серова

Художник Н. Новак
Иллюстрации: С. Белаш
Технический редактор Е. Денюкова
Корректор Е. Клитина
Компьютерная верстка: Е. Голубова
Подписано 31.01.14. Формат 60×90/16.
Усл. печ. л. 16,94.
Издательство «БИНОМ. Лаборатория знаний»
125167, Москва, проезд Аэропорта, д. 3
Телефон: (499) 157-5272
e-mail: binom@Lbz.ru, http://www.Lbz.ru
Минимальные системные требования определяются соответствую-

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

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

Управление проектами на основе стандарта PMI PMBOK®. Изложение методологии и опыт применения (PDFDrive)

Загружено:

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

Оригинальное название

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

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

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

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

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

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

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

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

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

Управление проектами на основе стандарта PMI PMBOK®. Изложение методологии и опыт применения (PDFDrive)

Загружено:

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

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

ПРОЕКТЫ

нения [Электронный ресурс] / А. Н. Павлов. — 4-е изд.,

По вопросам приобретения обращаться:

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

Успех любого бизнеса непосредственно связан с инновацион-

свыше 400 000 практикующих и сертифицированных чле-

Собственные национальные стандарты разработаны и

1 Pennypacker J. Justifying the value of project management. Havertown (PA):

x около 49% проектов имеют существенные отклонения от

Основными причинами этого являются:

Однако главной причиной низкой эффективности проект-

Очевидно, что существует определенный разрыв между те-

Целью книги было обобщение многолетнего опыта автора

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

5) управление качеством проекта;

1 Учебный курс. Управление проектом на основе стандарта PMI PMBOK®

Процессы УП согласно ANSI PMI PMBOK® GUIDE

8. Управление 8.1. Планирование управ 8.2. Обеспечение 8.3. Контроль каче

Область Инициация Планирование Исполнение Мониторинг Завершение

Те, кто не может запомнить прошлое,

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

Значение области знаний «Управление интеграцией проек-

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

4.1. Область знаний:

Рис. 1. Процесс разработки устава проекта в группе процессов

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

тель идеи будущего проекта. Очень часто идея будущего проек-

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

В случае утверждения бизнес-кейса руководящим органом

На вход процесса поступают также различные соглашения

NB! В крупных проектах уже в уставе важно указать исход

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

Извлеченные уроки, или что показал опыт разработки

! Комментарий из практики. Конечно, топ-менеджер органи-

y имя и полномочия спонсора проекта (или другого лица, ут-

x LL-4.1.2. Устав проекта не должен быть объемным. Как

4.2. Область знаний:

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

x обеспечение согласованности и непротиворечивости все-

Интерпретация процесса разработки плана УП и реко-

NB! Под единым документом понимается план, объединя

Поэтому стандарт и рекомендует использовать «выходы дру-

План проекта подвержен постоянным изменениям в ходе

NB! Особенно неприятны частые изменения требований

Поэтому руководителю проекта желательно придерживать-

! Комментарий из практики. Изменения в одном плане часто

NB! Руководитель проекта далеко не всегда способен вы

Извлеченные уроки, или что показал опыт разработки

4.3. Область знаний:

Рис. 3. Процесс управления исполнением проекта в группе про

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

x подбор и обучение команды проекта, управление челове-

Интерпретация процесса управления исполнением про-

NB! Отклоненные или отложенные запросы на изменения

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

Как мы уже знаем, изменения часто являются причиной

NB! Руководитель проекта не исполняет работы, а управля

Поэтому на входе процесса нет результатов работ — они

Отчет о продвижении проекта отвечает на вопрос: что было

NB! База данных извлеченных уроков является единым,

Всякий раз, когда в проекте возникает сложная, нестандарт-

Извлеченные уроки, или что показал опыт управления

x LL-4.3.2. В крупных проектах возрастает роль администра-

8. Управление 8.1. Планирование управ 8.2. Обеспечение 8.3. Контроль каче

NB! В крупных проектах уже в уставе важно указать исход

NB! Под единым документом понимается план, объединя

NB! Руководитель проекта далеко не всегда способен вы

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

NB! Руководитель проекта не исполняет работы, а управля

Рис. 5. Процесс общего управления изменениями в группе про

NB! Изменения базового плана проекта, являющиеся ре

Рис. 6. Процесс закрытия проекта в группе процессов заверше

NB! Руководитель проекта обязан пройти процедуру под

NB! При возникновении существенного изменения жела

Рис. 7. Процесс планирования управления содержанием в груп

Рис. 8. Процесс сбора требований в группе процессов планиро

NB! Основными целями совещания по определению со

NB! Нежелание руководителя проекта посвятить достаточ