Вы находитесь на странице: 1из 56

Second Edition

J. Rodney Turner

THE HANDBOOK OF PROJECT-


BASED MANAGEMENT
Improving the processes for achieving
strategic objectives
Дж. Родни Тернер

РУКОВОДСТВО ПО ПРОЕКТНО-
ОРИЕНТИРОВАННОМУ
УПРАВЛЕНИЮ
Усовершенствование процессов
управления для достижения
стратегических целей предприятия

Перевод с английского
под общей редакцией Воропаева В. И.

МОСКВА

2007
УДК 339.138
ББК 65.2902
Т35

Серия «Менеджмент»

Перевод с английского:
Каплан Л. Е.

Дж. Родни Тернер


Т35 Руководство по проектноориентированному управлению / Пер. с
англ. под общ. ред. Воропаева В. И. — М.: Издательский дом Гребен
никова, 2007. — 552 с.

ISBN 5938900271 (рус.)


ISBN 0077001612 (англ.)

Настоящее издание представляет собой универсальное собрание практи


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

Издание станет незаменимым справочником для всех профессионалов,


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

УДК 339.138
ББК 65.2902

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

© McGrawHill International (UK) Limited, 1999


© Каплан Л. Е., перевод на русский язык, 2006
© Оформление. ЗАО «Издательский дом
Гребенникова», 2007

ISBN 5938900271 (рус.)


ISBN 0077001612 (англ.)
Содержание
Предисловие к русскоязычному изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Предисловие ко второму изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Предисловие к первому изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Вступление ко второму изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Вступление к первому изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Благодарность ко второму изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Благодарность к первому изданию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

ЧАСТЬ I. ОКРУЖЕНИЕ ПРОЕКТОВ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Глава 1. Проекты и управление проектами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27


1.1. Управление изменениями с помощью проектов . . . . . . . . . . . . . . . . . . .27
1.2. Определения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
1.3. Три стороны проектноориентированного управления . . . . . . . . . . . . .30
1.4. Процессный подход . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
1.5. Стратегическое управление проектами . . . . . . . . . . . . . . . . . . . . . . . . . .49
1.6. Матрица целей и методов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
1.7. Сходство управления проектом с управлением парусной яхтой . . . . .55
1.8. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Глава 2. Проекты для реализации корпоративной стратегии . . . . . . . . . . . . . . .59


2.1. Вступление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
2.2. Процесс бизнеспланирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
2.3. Роль проектов и операций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
2.4. Выбор проектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
2.5. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Глава 3. Проекты и родительская организация . . . . . . . . . . . . . . . . . . . . . . . . . . .73


3.1. Вступление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
3.2. Стороныучастницы проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
3.3. Изменения в родительской организации . . . . . . . . . . . . . . . . . . . . . . . . .77
3.4. Внедрение проектноориентированного управления . . . . . . . . . . . . . .83
3.5. Создание культурной среды для управления проектами . . . . . . . . . . .88
3.6. Применение проектноориентированного управления . . . . . . . . . . . . .90
3.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Глава 4. Стратегическое управление проектами . . . . . . . . . . . . . . . . . . . . . . . . . .94


4.1. Вступление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
4.2. Оценка успеха проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
4.3. Недостатки в управлении проектом . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
4.4. Модель стратегического управления . . . . . . . . . . . . . . . . . . . . . . . . . . .105
4.5. Принципы успешного управления проектом . . . . . . . . . . . . . . . . . . . .111
4.6. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

ЧАСТЬ II. ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ УПРАВЛЕНИЯ ПРОЕКТАМИ . . . . .117

Глава 5. Управление предметной областью проекта . . . . . . . . . . . . . . . . . . . . .119


5.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
6 Содержание

5.2. Принципы управления предметной областью проекта . . . . . . . . . . . .120


5.3. Определение проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
5.4. Планирование на стратегическом уровне: планы контрольных
событий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
5.5. Планирование на более низких уровнях . . . . . . . . . . . . . . . . . . . . . . . .136
5.6. Применение планирования контрольных событий . . . . . . . . . . . . . . .143
5.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149

Глава 6. Управление организацией проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151


6.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
6.2. Принципы организации проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
6.3. Типы организационных структур проекта . . . . . . . . . . . . . . . . . . . . . .153
6.4. Схемы распределения ответственности . . . . . . . . . . . . . . . . . . . . . . . . .162
6.5. Включение в контракт объемов работы . . . . . . . . . . . . . . . . . . . . . . . . .169
6.6. Ведомости оборудования и чертежи . . . . . . . . . . . . . . . . . . . . . . . . . . .174
6.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175

Глава 7. Управление качеством . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177


7.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
7.2. Понятие качества в контексте проекта . . . . . . . . . . . . . . . . . . . . . . . . . .177
7.3. Обеспечение качества проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
7.4. Управление конфигурацией . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
7.5. Затраты на обеспечение качества . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
7.6. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197

Глава 8. Управление стоимостью . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200


8.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
8.2. Оценка стоимости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
8.3. Типы стоимостных оценок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
8.4. Когда осуществлять оценку стоимости . . . . . . . . . . . . . . . . . . . . . . . . .204
8.5. Структура стоимостной оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
8.6. Методы оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
8.7. Контроль затрат: как добиться эффективного расходования
средств . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
8.8. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227

Глава 9. Управление проектом по временным параметрам . . . . . . . . . . . . . . . .231


9.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
9.2. Планирование календарных сроков . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
9.3. Оценка продолжительности работ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
9.4. Расчет календарного плана с использованием сетевых моделей . . . .241
9.5. Гистограммы потребления ресурсов и выравнивание
потребности в них . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
9.6. Контроль сроков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
9.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258

Глава 10. Управление рисками . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260


10.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
10.2. Идентификация рисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
10.3. Оценка ущерба от рисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
10.4. Снижение рисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
10.5. Контроль рисков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Содержание 7

10.6. Методики PRAM и SCERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287


10.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287

ЧАСТЬ III. ПРОЦЕСС УПРАВЛЕНИЯ ПРОЕКТАМИ . . . . . . . . . . . . . . . . . . . . . . . .291

Глава 11. Определение проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293


11.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
11.2. Старт проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
11.3. Предложение и инициация проекта . . . . . . . . . . . . . . . . . . . . . . . . . .302
11.4. Выполнение исследования осуществимости проекта . . . . . . . . . . . .305
11.5. Проектирование и экспертиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
11.6. Стартовый семинар . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
11.7. Отчет об определении и руководство по реализации проекта . . . . .320
11.8. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325

Глава 12. Выполнение и контроль проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328


12.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
12.2. Обеспечение проекта ресурсами . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
12.3. Планирование выполнения проекта . . . . . . . . . . . . . . . . . . . . . . . . . .331
12.4. Распределение работ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
12.5. Требования к эффективному контролю . . . . . . . . . . . . . . . . . . . . . . .340
12.6. Сбор исходных данных и оценка хода выполнения проекта . . . . . .344
12.7. Принятие мер по ликвидации нежелательных отклонений . . . . . . .354
12.8. Цикл контроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .357
12.9. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358

Глава 13. Закрытие проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362


13.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362
13.2. Завершение работ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363
13.3. Передача продукта пользователям . . . . . . . . . . . . . . . . . . . . . . . . . . . .365
13.4. Получение выгоды . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
13.5. Расформирование команды . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368
13.6. Анализ проекта после его завершения . . . . . . . . . . . . . . . . . . . . . . . . .370
13.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371

ЧАСТЬ IV. ПРОЦЕДУРЫ УПРАВЛЕНИЯ ПРОЕКТАМИ . . . . . . . . . . . . . . . . . . . . .373

Глава 14. Управление программой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375


14.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375
14.2. Проблемы мелких проектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377
14.3. Управление программой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379
14.4. Управление проектами в масштабах всей компании . . . . . . . . . . . . .385
14.5. Офис сопровождения проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
14.6. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395

Глава 15. Процедуры и системы управления проектами . . . . . . . . . . . . . . . . . .398


15.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
15.2. Руководства по процедурам . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
15.3. Методологии и стандарты PRINCE 2, ISO 10006 и PMBoK . . . . . . . .407
15.4. Системы информации для управления проектом . . . . . . . . . . . . . . .412
15.5. Типы стандартных систем информации . . . . . . . . . . . . . . . . . . . . . . .421
15.6. Выбор и внедрение систем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424
8 Содержание

15.7. Предположения и риски . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427


15.8. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429

Глава 16. Проверки состояния и аудит проекта . . . . . . . . . . . . . . . . . . . . . . . . .431


16.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
16.2. Диагностика проектной направленности . . . . . . . . . . . . . . . . . . . . . .434
16.3. Диагностика успеха / провала . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
16.4. Проведение аудитов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
16.5. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453

Глава 17. Руководители и команды проектов . . . . . . . . . . . . . . . . . . . . . . . . . . . .455


17.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
17.2. Формирование и поддержка команды проекта . . . . . . . . . . . . . . . . .456
17.3. Мотивация команды проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460
17.4. Лидерство в проектах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .464
17.5. Успешный руководитель проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465
17.6. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .471

ЧАСТЬ V. ПРИМЕНЕНИЕ ПРОЕКТНООРИЕНТИРОВАННОГО


УПРАВЛЕНИЯ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473

Глава 18. Области приложения проектноориентированного управления . . .475


18.1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475
18.2. Управление жизненным циклом продукта . . . . . . . . . . . . . . . . . . . . .475
18.3. Разработка нового продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478
18.4. Технологические проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .485
18.5. Конкурентный инжиниринг . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .493
18.6. Проекты информационных систем . . . . . . . . . . . . . . . . . . . . . . . . . . .498
18.7. Реинжиниринг бизнеспроцессов . . . . . . . . . . . . . . . . . . . . . . . . . . . . .508
18.8. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509

Глава 19. Международные проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513


19.1. Вступление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513
19.2. Типы международных проектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513
19.3. Проблемы международных проектов . . . . . . . . . . . . . . . . . . . . . . . . .517
19.4. Культурные различия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .521
19.5. Реализация проектов в развивающихся странах . . . . . . . . . . . . . . . .531
19.6. Управление международными проектами . . . . . . . . . . . . . . . . . . . . . .535
19.7. Основные положения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .538

Глава 20. Заключение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540


20.1. Принципы управления проектом . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540
20.2. Составляющие успеха проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541

Предметный указатель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543


Предисловие к
русскоязычному изданию

Я с большим удовольствием представляю вашему вниманию предисло


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

Этот факт признают многие организации. Правительство Великобри


тании разработало стандарт PRINCE 2, который внедряет теперь в качест
ве обязательной части большинства проектов бизнесразвития, осуществ
ляемых в государственном секторе страны. Оно сознает значение
управления проектами для достижения целей развития страны, в связи с
чем в большинстве правительственных учреждений Великобритании соз
даны «центры обеспечения совершенства» (Centres of Excellence). Я много
работал в Китае, где управление проектами с энтузиазмом перенимается
как важное подспорье для стремительного роста и развития «экономики
тигра»*. В последнее время Китай занимает второе место в мире по разви
тию экономики и имеет шансы вскоре стать лидером, а эффективное уп
равление проектами внесло свой вклад в это достижение.
Уже доказано, что эффективное управление проектами позволяет на
30% сократить как стоимость, так и продолжительность проекта, что в
совокупности ведет к повышению результативности более чем на 50%.
Это означает, что при эффективном управлении проектами вы сможете

* «Экономика тигра» (англ. Tiger Economy) — полуофициальное обозначение для страны, пере
живающей быстрый экономический рост, обычно сопровождающийся повышением стандартов
жизни; применяется, как правило, в отношении «Восточноазиатских тигров» (Южной Кореи, Син
гапура, Гонконга, Тайваня, Китая) и «Кельтского тигра» (Ирландии). — Прим. ред.
10 Предисловие к русскоязычному изданию

за одни и те же деньги осуществить в два раза больше проектов и добить


ся удвоения темпов роста бизнеса. Надеюсь, что для специалистов в Рос
сии эта книга окажется полезной и поможет им выполнять лучшие, все
более эффективные проекты.
Профессор Владимир Воропаев возглавляет российскую отрасль уп
равления проектами более 20 лет, я же знаком с ним лет 15. Благодаря его
лидерству управление проектами в России является теперь развитой дис
циплиной, пользующейся признанием профессионалов, и вносит замет
ный вклад в развитие российской экономики. Я благодарен профессору
Воропаеву за усилия, предпринятые им при подготовке переводного из
дания моей книги. Надеюсь, что оно станет дальнейшим вкладом в разви
тие управления проектами как области знания и профессиональной сфе
ры в России.
Подход, заложенный в основу книги, восходит к «Своду знаний по уп
равлению проектами» (Project Management Body of Knowledge — PMBoK®)
Института управления проектами (Project Management Institute — PMI®).
В дальнейшем между этой книгой и PMBoK® появились расхождения, но,
по моему убеждению, это означает, что для специалистов, готовящихся к
получению сертификата в области управления проектами, как от PMI,
так и от Международной ассоциации управления проектами (International
Project Management Association — IPMA), книга послужит ценным подс
порьем. Ее англоязычное издание упоминается в качестве цитируемого
источника «Сводами знаний» обеих этих организаций.
Я преподаю управление проектами в разных странах мира и везде со
ветую своим слушателям искать книги, которые помогут им при обуче
нии и послужат руководством, когда они вернутся в рабочее окружение и
приступят к реализации проектов на практике. Всегда полезно иметь под
рукой книгу, к которой можно обратиться, — и самое лучшее, если это
твоя собственная книга. Надеюсь, у меня будет возможность преподавать
управление проектами и в России, и я смогу построить свой курс на осно
вании русскоязычного издания этой книги.

Успехов вашим проектам!

Родни Тернер
ИстХорсли, Суррей, Великобритания
26 ноября 2006 г.
Предисловие ко второму
изданию

С момента выхода в свет первого издания этой книги в 1993 г. управление


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

Эрик Габриэль (Eric Gabriel),


вицепрезидент Ассоциации управления проектами
(Association for Project Management)
Предисловие к первому
изданию

Книги по управлению проектами создают отчетливое впечатление, что


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

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


роль качества. Именно аспект качества требует большой заботы и внима
ния со стороны руководителя проекта, поскольку вопросы, связанные с ка
чеством, почти всегда критичны для стоимости проекта и сроков его
реализации.
Я нахожу идею «бездефектности» трудновыполнимой, отчасти потому,
что один человек сочтет изъяном то, что приемлемо для другого, а отчасти
по той причине, что требования заказчика не являются ни постоянными,
ни легко определимыми. Достаточно напомнить, что «лучшее — это враг
хорошего». Несмотря на это, раздел о качестве содержит чрезвычайно важ
ные мысли и может считаться весьма полезным.
Раздел о процедурах управления помещен ближе к концу, в части IV, что
своевременно и верно. Я совершенно уверен, что если вы считаете положения
и подходы, изложенные в частях I, II и III, ошибочными, то и самая лучшая в
мире система работать не будет. Если же эти мысли будут признаны правиль
ными, то, о чем говорится в части IV, само по себе не составит проблемы.
Я был особенно рад обнаружить в части V раздел о международных про
ектах и сведения о культурных факторах из исследований Дж. Хофстеда.
Об этом должны прочитать все, кто участвует в международных и меж
культурных проектах, связанных с изменениями, которые так отвечают из
менчивому характеру современного мира.
Эта книга включает в себя комплекс сведений по всему современному
спектру управления проектами применительно к управлению изменения
ми. Материал изложен без излишней схематичности или упрощения и, в
то же время, в легкодоступной форме. Книга читается с интересом от нача
ла и до конца, что является редким качеством для работы с таким глубоким
проникновением в тему и такой богатой информативностью. По любому
из рассмотренных вопросов можно легко найти ключевые моменты, спис
ки основных положений и практические примеры.
Эта книга содержит много полезного для всех тех, кто трудится в сферах
управления изменениями и управления проектами. Она поможет опыт
ным руководителям проектов добиться более полного понимания нюансов
деятельности, которые они осознают интуитивно, и, таким образом, повы
сить результативность работы.
С другой стороны, начинающие руководители проектов получат по
мощь в понимании основ этого предмета и, что более важно, правильные
приоритеты.
Книга будет полезной для всех, кто предоставляет услуги по управле
нию проектами в таких важных областях, как технологическое и календар
ное планирование, контроль затрат, управление материальными ресурса
ми, управление контрактами, и во многих других. Она поможет им понять
роль руководителя проекта и подскажет, как повысить качество информа
ции и услуг, которые они поставляют.
Эта книга займет достойное место на моей книжной полке. Я рекомен
дую ее всем, кто занимается и интересуется управлением изменениями и
современными идеями эффективного управления.

Эрик Габриэль (Eric Gabriel),


вицепрезидент Ассоциации управления проектами
(Association for Project Manegement)
Вступление ко второму
изданию

При подготовке второго издания автор придерживался первоначальной


концепции этой книги. Она структурирована так, чтобы читатели могли
либо прочитать ее от начала до конца, либо углубиться в нее настолько,
насколько им хочется овладеть представленным материалом или понять,
как подойти с его помощью к решению какойто конкретной проблемы.
Автор сохранил первоначальную структуру книги.
Часть I посвящена окружению, в котором реализуется проект.
Часть II описывает пять функциональных областей управления: управ
ление предметной областью проекта, организацией, качеством, стоимостью
и сроками осуществления проекта.
Часть III содержит описание фаз жизненного цикла проекта.
Часть IV посвящена методам управления проектом.
Часть V содержит примеры и иллюстрации того, как проектноориен
тированное управление применяется в различных условиях.

Некоторые главы остались в основном неизменными (за исключением


разницы в их нумерации, поскольку глав стало меньше). Это главы, посвя
щенные стратегии родительской организации (2), участникам проекта (3),
управлению предметной областью, организацией, стоимостью и срока
ми реализации проекта (5, 6, 8, 9), а также фазам жизненного цикла про
екта (11, 12, 13). Другие главы были откорректированы автором с учетом ре
зультатов новых исследований в развивающихся областях
проектноориентированного управления. К ним относятся главы, в которых
рассматриваются успех и стратегия проекта (4), управление качеством и
рисками (7, 10), роль руководителя проекта (17). Автор использовал новый
подход в части IV, рассматривающей управление программой (14), процеду
ры и системы (15), проверку состояния проекта (16). Автор изменил также
свой подход к части V. Не заявляя о своем несогласии с тем, что было сказа
но в первом издании, автор вместе с тем не выражает более уверенности,
что первоначально данная им классификация проектов приводит к выявле
нию полезных различий. Поэтому автор посвятил отдельную главу типам
проектов. Раздел, посвященный проектам разработки, включен в главу 12.
Автор добавил в эту же главу разделы по параллельному (конкурентному)
инжинирингу и реинжинирингу бизнеспроцессов, а также значительно
расширил главу по международным проектам (19). В целом, в этой книге на
три главы меньше, что, как надеется автор, делает ее более сфокусирован
16 Вступление ко второму изданию

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

Родни Тернер
ИстХорсли, Суррей, Великобритания
Июнь 1998 г.
Вступление к первому
изданию

В первой из книг серии об управлении предприятием, подготовленной в


Колледже управления Henley (см. Paul Thorn, The New General Manager,
McGrowHill, 1989), шла речь о бурных структурных изменениях, проис
ходящих в современных организациях, и давалось описание того, каким
образом данные изменения приводят к появлению совершенно новой
«породы» топменеджеров. Эти изменения были вызваны стремительным
развитием технологий, средств связи и возможностей доступа руководи
телей к информации. Вторая книга серии (Tony Knight and David Silk,
Managing Information, McGrowHill, 1990) объясняла ключевую роль ин
формации для успеха предпринимательской деятельности.
В обеих этих работах отмечался тот факт, что в результате быстрых из
менений в нынешних организациях проектное или проектноориентиро
ванное управление становится основным направлением управленческой
деятельности. Бюрократическая, административнокомандная организа
ция, принятая еще в XIX в. для обеспечения эффективности производства,
уже не отвечает условиям острой конкуренции, имеющей место в совре
менном бизнесе. Организации должны быть гибкими, чтобы быстро и эф
фективно реагировать на изменение внешних условий, а для этого требу
ются новые топменеджеры, способные управлять изменениями на основе
проектного подхода. С этой целью топменеджер осуществляет:
■ управление портфелями проектов с помощью команды руководи
телей проектов;
■ управление отдельными проектами в качестве руководителя проек
та с помощью команды сотрудников, которые в обычных условиях не
подчиняются ему непосредственно;
■ управление связями между этими проектами, остальной частью ор
ганизации и ее внешним окружением.

Эти изменения затронули не только мелкие организации. Корпора


ция British Telecom обнаружила, что половина ее деятельности является
проектноориентированной. Если обратится к экономическим показате
лям, окажется, что ежегодные расходы на реализацию проектов в Англии
составляют f300 млрд, а трудозатраты — 27 млн человеколет.
Таким образом, управление проектами превращается в область про
фессиональных компетенций, которыми должны обладать менеджеры
высшего звена наряду с владением более традиционными дисциплинами,
18 Вступление к первому изданию

такими как бухгалтерский учет и финансы, маркетинг и стратегическое


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

В книге описан структурированный подход к управлению проектом и


приведены пояснения в виде ссылок на реальные примеры проектов, в
которых участвовал автор. Она предназначена как для того, чтобы дать
общее представление о данном подходе, так и для использования в каче
стве руководства, в котором содержатся конкретные рекомендации о том,
как управлять некоторыми составляющими проектов и какие инструмен
ты и методы нужно для этого применять. Общая модель подхода (изло
женная в главе 1) вместе с оглавлением должны помочь читателям найти
в книге то, что важно именно для них, и выбрать главы для углубленного
изучения. Эта книга предназначена не только для руководителей, испы
тывающих острую нехватку времени, но и для более формального изуче
ния студентами и соискателями степени MBA или MSc (магистра естест
венных наук) по тематике, связанной с проектами.
Вводная глава 1 дает определение проектов и представление о структу
рированном подходе к управлению проектом, описанном в этой книге. В
части I приведено бизнесокружение, в котором осуществляется проект.
В ней описываются характеристики проектов, причины, по которым ор
ганизации занимаются ими, и воздействие, которое они оказывают на ор
ганизационную структуру, а также объясняется, как выбрать стратегии,
обеспечивающие успех проектов. В части II представлен комплекс перво
очередных методов реализации данного подхода: как выбрать проекты
для решения задач, необходимых для вашей предпринимательской дея
тельности; как управлять этапами работ, организационными формами,
обеспечивающими их выполнение, ограничениями по качеству, стоимос
ти, времени и рискам, внутренне свойственными проектам. В части III со
держится следующий комплекс методов данного подхода: процессы уп
равления, необходимые для осуществления проектов. В ней
прослеживается жизненный цикл проекта и показывается, как каждое из
заданий управляется на каждой фазе. В части IV рассказывается об
инструментах и методах, относящихся к специальным системам и проце
дурам управления, включая проектное администрирование и использо
вание компьютерных систем, а также описываются роль и профессио
нальные навыки руководителя проекта.
Вступление к первому изданию 19

Часть V, завершающая книгу, содержит описание некоторых конкрет


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

Родни Тернер
Вергрейв, Беркшир, Великобритания
Октябрь 1991 г.
Часть I

ОКРУЖЕНИЕ ПРОЕКТОВ
Глава 10

Управление рисками

10.1. ВВЕДЕНИЕ

В предыдущих пяти главах были описаны способы, средства и методы для


пяти функциональных областей управления проектом — управления
предметной областью, организацией, качеством, стоимостью и сроками
выполнения проекта. Все они требуют от нас точных прогнозов, но мы зна
ем, что не можем предсказывать будущее. Все, что мы можем сделать, —
это выдвинуть верные предположения. На протяжении девяти глав было
неоднократно доказано, что чем больше усилий мы вкладываем в расчеты
(предположения) и чем больше фактической информации заложено в ос
нову этих расчетов, тем выше их точность. Однако если затратить на расче
ты слишком много ресурсов, то может настать момент, когда стоимость
расчетов превысит потери изза рисков, внутренне присущих любому про
екту. В условиях повторяющегося производства неопределенность может
быть сведена к очень низкому уровню, и внимание руководства сосредото
чивается на том, чтобы исключить любые отклонения от существующего
положения дел, поскольку отклонения снижают определенность и тем са
мым вносят риски. В условиях проектов, в связи с их уникальностью, неко
торая неопределенность неизбежна, и поэтому руководители должны уде
лять особое внимание управлению рисками. Можно предположить, что
управление рисками является сущностью управления проектами.
Тем не менее шесть лет тому назад, когда я работал над первым изда
нием этой книги, управление рисками было одной из наиболее слабо ис
следованных и документально описанных областей управления проекта
ми. Имелись книги по управлению рисками в больших проектах [1], но
фактически отсутствовали публикации по основам управления рисками,
доступные для любого руководителя проекта. В настоящее время ситуа
ция изменилась. Управление рисками превратилось в одну из наиболее
изученных и документально описанных областей [2–5] и было системати
зировано в методике анализа и управления рисками проекта (Project
Risk Analysis and Management Technology — PRAM) [2, 3].
В этой главе управление рисками описывается как процесс, включаю
щий четыре шага. Прежде всего следует выявить риски, присущие ваше
му проекту, и оценить их последствия — сначала для каждого риска в
Глава 10. Управление рисками 261

отдельности, а затем для всех рисков вместе. После этого необходимо разра
ботать стратегии снижения рисков, и, наконец, осуществлять мониторинг и
контроль рисков по мере их возникновения (или отсутствия) наряду с оцен
кой эффективности выбранных вами стратегий. Эти четыре шага будут
описаны в следующих четырех разделах. В последнем разделе будут крат
ко проанализированы методология PRAM и ее предшественница — мето
дика синергетической комбинированной оценки и анализа (Synergetic
Combined Evaluation and Research Technique — SCERT). Мы также рассмот
рим их взаимосвязь с описанным здесь четырехшаговым подходом.

10.2. ИДЕНТИФИКАЦИЯ РИСКОВ


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

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

Бизнесриски
Бизнесриск — это риск (или неопределенность), внутренне присущий
всем нашим оценкам. Люди склонны считать свои оценки характеристик
проекта предельно точными. Однако в действительности наши расчеты
представляют собой усредненную величину, и в реальности ситуация мо
жет оказаться лучше или хуже, чем предполагалось. (Удивительный факт:
в житейских ситуациях люди признают некоторую неопределенность сво
их оценок того, сколько времени займет то или иное дело, но, тем не ме
нее, полагают, что их оценки в рамках проектов совершенно точны — см.
пример 10.1). Бизнесриск (или неопределенность) — это «палка о двух
концах». Иногда наши проекты оказываются лучше, чем мы ожидали, и
мы получаем больше прибыли, а иногда хуже, и мы получаем меньше
прибыли или даже терпим убытки.
Пример 10.1. Неопределенность в оценках
Я проводил серию семинаров для небольшой консалтинговой фирмы, у которой
имелась проблема перерасхода выделенных ассигнований. (За трехлетний период
компания сократила перерасход с 10%, что в два раза превышало годовую прибыль,
примерно до 2%.) На первом семинаре директор фирмы передал мне перечень ста
тей перерасхода. Он сгруппировал их по величине перерасхода в фунтах стерлин
гов. Сначала в списке шли работы, оцененные в ?20 тыс., а при завершении стоив
шие уже ?50 тыс. В последнюю группу были включены проекты с перерасходом в
?1–2 тыс., а завершал ее проект, оцененный в ?200 тыс., перерасход по которому
262 Часть II. Функциональные области управления проектами

составил лишь чуть больше ?1 тыс. Я заметил, что в последнем случае перерасход
составил всего лишь 0,5%, и расчет нельзя было выполнить лучше. Однако дирек
тора мой вывод не удовлетворил.

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

Почему проекты терпят неудачу?


Как уже отмечалось, бизнесриски могут привести к тому, что результаты
окажутся лучше или хуже ожидаемых. Это объясняет, почему следует
включать в расчет непредвиденные расходы, описанные в разделе 8.5, и
почему проекты часто заканчиваются неудачей. Причина этого заключа
ется в следующем: то, что мы получили в результате оценки, есть усред
ненное значение показателя — как правило, наиболее вероятный резуль
тат выполнения работы. В действительности результат может быть лучше
или хуже, однако величина, на которую он может быть лучше, обычно ог
раничена, в то время как величина, на которую он может оказаться хуже,
не ограничена ничем, хотя вопрос о том, в какой точке отрицательный
результат превращается в страхуемый риск, является спорным. Поэтому
уровень ожидаемых результатов является асимметричным распределени
ем, находящимся на графике по большей части не ниже, а выше наиболее
вероятного результата. Существуют еще два усредненных показателя —
медиана (половина результатов будет больше, а половина — меньше этой
величины) и среднее значение, или среднее арифметическое (если мы
выполняем действие большое количество раз, то возьмем средний ре
зультат). Если распределение является асимметричным, то медиана ока
зывается в его асимметричной части относительно моды (наиболее веро
ятного значения), а среднее арифметическое — в асимметричной стороне
относительно медианы. В настоящее время методы оценки в проектах
заключаются в том, чтобы оценить затраты и продолжительность работ, а
затем объявить сумму затрат по всем работам ожидаемой стоимостью
проекта, а сумму продолжительностей последовательности работ, при
надлежащих критическому пути, — ожидаемой продолжительностью
проекта. Таким образом, мы утверждаем, что наиболее вероятный ре
зультат проекта является суммой наиболее вероятных промежуточных
результатов. Это неправильно — мы можем говорить только о том, что
ожидаемый результат проекта является суммой средних промежуточных
результатов. Это делает ожидаемый результат завышенным по сравне
нию с оценкой, полученной путем суммирования исходных расчетов, то
есть наши проекты почти неизбежно потерпят неудачу, если мы не учтем
непредвиденные расходы, как это было описано в разделе 8.5.
При расчете продолжительности работ вы часто будете сталкиваться
с так называемой формулой 1:4:1. Это очередная аксиома управления
проектами, истоки возникновения которой теряются во мраке прошло
го. В ранний период управления проектами, в 1950х гг., особенно при
Глава 10. Управление рисками 263

использовании методики PERT, считалось, что лучшие результаты


можно получить путем расчета продолжительности каждой работы по
формуле:
d = (to + 4tm + tp) / 6,
где d — продолжительность работы,
to — наиболее пессимистическая оценка,
tm — наиболее вероятный результат,
tp — наиболее оптимистическая оценка.
Версией этой формулы является формула 1:4:3 (пример 10.2):
d = (to + 4tm + 3tp) / 8.
Пример 10.2. Асимметричные оценки
В качестве примера асимметричных оценок я использую свою поездку в Колледж
управления Henley. Я живу в 40 милях от него, и наиболее вероятное время пути
составляет 55 минут. Я проделывал этот путь за 40 минут, и это время является наи
более оптимистичным. Однажды в пятницу вечером тот же путь занял 135 минут —
это превышение времени было обусловлено сложной ситуацией на дорогах (мы мо
жем назвать это страхуемым риском). Даже если не учитывать этот единичный
экстремальный случай, поездка может занять до 105 минут. Если я начинаю препо
давание с 9.00, то должен выезжать из дома в 7.15, чтобы быть совершенно уверен
ным в том, что приеду своевременно.
Путь домой в пятницу вечером может занять 90 минут, однако наиболее песси
мистическое время поездки составляет 105 минут. В этом случае имеет место рас
пределение, которое мы называем бимодальным (двухвершинным): существуют
два наиболее вероятных результата, один — это 55 минут в условиях простой до
рожной ситуации, и второй, менее вероятный, — это 90 минут при сложной до
рожной ситуации. Медианное время в пути составляет около 60 минут, а среднее
арифметическое — примерно 70 минут. Таким образом, если я езжу на работу
каждый день в течение рабочей недели, сколько времени я рассчитываю провести
в машине в течении 10 поездок: 400, 550, 600, 700, 900 или 1050 минут? Если я не
удачник и каждая моя поездка будет связана со стояниями в «пробках» (нонсенс, но
мы называем это время rushtime — «время спешки»!), то следует остановиться на
оценке около 900 минут. Но большинство из нас выбрало бы оценку около 700 ми
нут. В то же время стандартный расчет для проекта дал бы результат 550 минут,
что, как нетрудно увидеть, является большой недооценкой. Использование форму
лы 1:4:1 дает 610 минут, а формулы 1:4:3 — 720 минут. Последняя оценка является
более точной, что объясняется бимодальным распределением. Управление риска
ми стремится по возможности не связывать расчет времени моей поездки с замед
ленным движением и, таким образом, уходит от верхнего пика распределения.

Регулирование рисков

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


регулирование. Регулирование может быть внутренним и внешним по от
ношению к организации, в которой работает руководитель проекта, или
юридическим. Внутренние риски могут быть техническими или иными,
внешние риски — предсказуемыми или непредсказуемыми. Юридические
риски могут попадать под уголовное или гражданское законодательство,
264 Часть II. Функциональные области управления проектами

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


ноделиктному праву* (закону об административных правонарушениях).

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

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

* Административноделиктное право — подотрасль административного права; совокупность


норм, которые регулируют отношения, возникающие в связи с совершением административного
правонарушения (деликта). — Прим. ред.
Глава 10. Управление рисками 265

наводнение, потопление корабля). Превышение срока окончания проекта


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

Превращение внутренних рисков во внешние


Прежде чем перейти к описанию рисков, связанных с нарушением зако
нов, рассмотрим один момент, связанный с внутренними и внешними
рисками. Стандартной практикой договорной деятельности в Великобри
тании является попытка передать риски «вниз» по цепочке организаций,
связанных контрактами. Заказчик перекладывает риски на подрядчика, а
подрядчик — на субподрядчика. Иногда вам приходится брать на себя
риски, которые заказчик может контролировать, принимая меры для их
снижения, и превращать их в риски, внешние по отношению к организа
ции подрядчика. Все, что остается в таком случае подрядчику, это пре
дусмотреть непредвиденные расходы, поскольку контролировать подоб
ные риски он не в состоянии. После этого заказчик проводит обязательные
конкурсные торги и отдает заказ тому подрядчику, который предложит
минимальную наименьшую сумму. Однако это подрядчик, который пре
дусматривает наименьшие непредвиденные расходы, и поэтому он, скорее
всего, потерпит неудачу. Вернемся к примеру 10.2: вы отдадите заказ по пе
ревозке лектора в Колледж управления Henley и обратно подрядчику, кото
рый предложит сделать это за 400, 550, 600, 700, 900 или 1050 минут? Если
эту работу получит фирма, которая обещает уложиться в 400 минут и
обанкротится, когда вы находитесь на полпути к дому, у вас будет мало
возможностей для возмещения своих потерь, и придется потратить еще
300 минут на то, чтобы проделать остаток пути до дома.
В настоящее время наблюдается тенденция к анализу рисков, связан
ных с контрактами, и распределению их между теми сторонами, которые
наилучшим образом способны их контролировать. Это очень логичная и
обоснованная деловая практика. Возвращаясь к примеру 10.2: вы можете
счесть продолжительность поездки риском заказчика и отдать заказ под
рядчику, который предложит самую низкую стоимость за минуту поезд
ки, или же попросите подрядчика предложить ряд цен в зависимости от
плотности дорожного движения и каждый раз измерять плотность для
определения цены. Еще один вариант — предоставить подрядчику воз
можность выбирать время поездки, если это допустимо. Имеется ряд
предложений по рациональному распределению рисков. Пример 10.3 яв
ляется выдуманной историей, иллюстрирующей распределение рисков.
Пример 10.3. Распределение риска
Нейлу Армстронгу в ходе интервью был задан вопрос: какой момент оказался са
мым страшным при высадке на поверхность Луны — момент приземления лета
тельного аппарата, когда он мог потерпеть аварию, спуск Армстронга с лестницы
на лунную поверхность, момент старта с Луны, когда мощность ракет могла ока
заться недостаточной? Нет, ответил он, самым страшным был миг на стартовой
площадке мыса Канаверал, когда под ним находилось 2 тыс. комплектующих,
каждая из которых могла быть закуплена по тендеру с предложением минималь
ной цены! И одна из таких деталей действительно вышла из строя в 1986 г.
266 Часть II. Функциональные области управления проектами

Юридические риски
Имеется три типа юридических рисков: риски, обусловленные уголовным
правом, риски, обусловленные договорным правом, и риски, связанные с
административноделиктным правом. (Административноделиктное право
налагает на каждого из нас обязательство относиться к своим согражданам
с должной заботой. Даже если у нас нет контракта с кемлибо, мы обязаны
вести себя по отношению к нему ответственно и с достаточным внимани
ем.) Если наемный работник будет убит на рабочем месте, вас могут прив
лечь к суду на основании «Закона об охране здоровья и соблюдении техни
ки безопасности на производстве» или «Норм и правил строительства и
проектирования» (СDM), оштрафовать на сумму до ?2 тыс. и посадить в
тюрьму на два года. Вам может быть предъявлен иск на основании его
контракта о найме на работу или административноделиктного права. Если
на вашей площадке убит посетитель, то вас можно обвинить на основании
уголовного или административноделиктного права, даже если вы не связа
ны с этим лицом никаким контрактом. Это в равной мере применимо и к
сфере создания программного обеспечения, и к индустрии машинострое
ния. Во время ввода в эксплуатацию АЭС Sizewell B имело место множест
во дискуссий по поводу автоматизированной системы управления этой
станцией. Если бы на этой станции произошла авария (вероятность кото
рой, однако, равна нулю), поставщики были бы признаны виновными по
всем трем юридическим рискам.
В рамках уголовного права было предпринято несколько попыток
предъявить обвинение юридическим лицам в непредумышленном убий
стве, одна из них — после аварии в г. Зеебрюгге, хотя из этого ничего не
вышло. Только один процесс такого рода увенчался успехом обвинения,
и несмотря на что, что здесь приводить этот пример неуместно, я знаю,
что вину было очень трудно доказать. Один человек все еще несет ответ
ственность за несчастный случай, поскольку именно он отвечал за приня
тие решения, приведшего к аварии, что было бы не так, если бы авария
явилась следствием ряда оплошностей, как это имело место при авариях
в Зеебрюгге и Боубелле. Лейбористское правительство предлагает ввести
обвинение для юридических лиц за смерть на производстве, которое мог
ло бы базироваться на общей обстановке небрежности и безответствен
ности, а не на единственном неправильном решении.
В случае судебного разбирательства решение принимается на основе то
го, что должен был бы сделать достаточно подготовленный профессионал в
этих обстоятельствах. В примерах 10.4 и 10.7 описаны четыре случая, пока
зывающие, как это может произойти. Пример 10.6 доказывает, что закон не
обязательно является справедливым и логичным — он просто пытается
быть точным.
Пример 10.4. Испытание автоматизированной системы контроля
Несколько лет назад я принимал участие в проведении учебного курса, в рамках ко
торого рассматривался «Закон об охране здоровья и соблюдении техники безопас
ности на производстве». Один из присланных на учебу сотрудников рассказал, что
на него возложена ответственность за тестирование и контроль программного
обеспечения для реактивного истребителя, используемого в Королевских военно
воздушных силах. Он заявил, что при достаточном времени можно протестиро
вать 90% путей в этом программном обеспечении, которые охватывают 99,9%
Глава 10. Управление рисками 267

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

Пример 10.5. Требование компенсации ущерба через 50 лет


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

Пример 10.6. Закон несправедлив, но скрупулезно точен


Детям с замедленным ростом вводят гормон роста. До 1980 г. это была вытяжка из
мозга покойных. С июля 1978 г. правительству стало известно, что это может при
вести к заболеванию CJD — аналогу коровьего бешенства у человека, но переход на
синтетический аналог был совершен только в 1980 г. Семьи людей, страдавших CJD
по этой причине, подали в суд на правительство. Суды приняли решение, что все,
кому гормоны были впервые введены 1 июля 1978 г. или позже, должны получить
компенсацию. Все, кому их ввели 30 июня и раньше, компенсаций не получали,
поскольку правительство до этого дня не знало о существовании указанной пробле
мы. Одному из пострадавших, не получивших компенсации, гормон был введен
приблизительно 30 июня 1978 г., и все говорили, что это несправедливо, хотя скру
пулезно точно. (Когда я писал этот текст, это решение было опровергнуто Апелля
ционным судом, и теперь все люди, страдающие CJD, могут обращаться в суд. Лю
ди, не страдающие CJD, но подвергавшиеся риску этого заболевания, хотят подавать
в суд в связи со страхом, который они испытывали изза этой неопределенности.)

Пример 10.7. Нельзя судить за прошлое по сегодняшним стандартам


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

Методы идентификации рисков


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

2. Декомпозиция плана выявляет риски, внутренне присущие взаимоза


висимости работ. Любое событие, которое находится в начале или в
конце множества действий, является потенциально рискованным. Так
происходит в «узких местах» сетевой модели. При анализе плана вы
должны проанализировать все внешние связи, такие как внешние пос
тавки, для выявления потенциальных сбоев по вине третьих сторон.
3. Анализ предположений — это анализ выгод и потерь, сосредоточен
ный на событиях, которые могут быть определены. При этом рас
сматриваются события, возникновение которых мы считаем жела
тельным, но которые могут не произойти, и события, возникновение
которых мы считаем нежелательным, но которые могут произойти.
Для того чтобы прогнозировать такие события и гарантировать пол
ноту оценки, требуются экспертные заключения.
4. Драйверы решения — это воздействия, которые дают возможность
определить, могут или не могут иметь место определенные события
(внутренние или внешние по отношению к проекту). Для подготовки
контрольного перечня драйверов решений можно воспользоваться
анализом выгод и потерь. Вред особенно велик, если решения прини
маются по ложным причинам: политическим или маркетинговым, а
не техническим, краткосрочным, а не долгосрочным, на основании
новой технологии, а не прошлого опыта.
5. Мозговой штурм использует социальное взаимодействие для совер
шенствования вышеописанных методов.

«Ожидание неожиданностей»
Хорошие руководители проектов учатся осознавать риски и прогнозиро
вать неудачи даже тогда, когда их меньше всего можно ожидать. Есть из
вестный закон переполнения, или закон Мерфи, который иногда форму
лируют следующим образом.
Если неприятность может случиться, она случается. Если она не
может случиться, то все равно случается.
Ценность такой позиции заключается в следующем: если вы ожидаете,
что дела пойдут не так, как следует, то будете готовы встретиться с пробле
мами и сможете быстро на них реагировать. Неудачи могут быть теми, ко
торых вы ожидали, или теми, на которые вы меньше всего рассчитывали.
Если вы ожидаете проблем и планируете соответствующие непредвиден
ные расходы, вы не будете застигнуты врасплох, когда эти проблемы воз
никнут. Если случается непредвиденное, вы должны сосредоточить свои
управленческие усилия на тех областях, которые в данное время наиболее
уязвимы (пример 10.8). Эта позиция предвидения рисков и готовности на
них реагировать называется рисковым мышлением. Одни приходят к нему
естественным путем, другим для этого требуются структурированные ло
гические процессы выявления и анализа риска, которые упрощают реаги
рование на проблемную ситуацию.
Пример 10.8. «Ожидание неожиданностей»
В 1983 г. я руководил одной из областей работ по капитальному ремонту аммиач
ной установки. Мы увеличивали производительность системы пароснабжения, а
Глава 10. Управление рисками 269

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


работающими под давлением 0,05 кг/см2 и 0,03 кг/см2, как это показано на рис. 10.1.
Во время ремонта мы должны были сделать две врезки с каждого конца этой ли
нии. Она состояла из двух Тобразных участков с отсекающей задвижкой. После
включения установки новая линия должна была функционировать на участке
между двумя задвижками. Врезка в магистраль с давлением 0,03 кг/см2 была прос
той. Мы заранее, до начала капитального ремонта, сделали Тобразную секцию се
чением 15×20 мм. Во время ремонта оставалось лишь разрезать магистраль, вва
рить Тобразную секцию и установить отсекающую задвижку. Однако другая
врезка сопровождалась гораздо большими рисками — нужно было проложить ли
нию чуть ниже отсекающей задвижки, отделив магистраль установки от завод
ской магистрали. Эта задвижка не закрывалась в течение 12 лет, и мы не знали,
насколько плотно она закроется. Если бы задвижка не закрылась, работа стала бы
более сложной или даже невозможной. Мы затратили значительные усилия на то,
чтобы подготовить планы непредвиденных расходов на случай частичной или
полной протечки этой задвижки. В действительности она закрылась прекрасно.
Когда же дошло до врезки Тобразной секции с другого конца, обнаружилось, что
ее изготовили с ошибкой: сечение оказалось 15×15 мм вместо 15×20 мм. Поэтому
нам нужно было спешно изготовить новую Тобразную секцию, но трубы диамет
ром 15 мм, рассчитанной на нужное давление, в тот момент в наличии не оказа
лось. Эта работа совершенно разрушила все расчеты продолжительности ремонта.
Однако время на планирование другой работы не было потрачено впустую. Я был
настолько в этом убежден, что смог прекратить планирование, переключиться и
сосредоточить свое внимание на закупке 20миллиметровой трубы.

Рис. 10.1. Трассировка магистральных паропроводов на заводе по производству аммиака


270 Часть II. Функциональные области управления проектами

10.3. ОЦЕНКА УЩЕРБА ОТ РИСКОВ


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

Воздействие отдельных рисков


Воздействие риска зависит от вероятности его возникновения и тяжести
последствий в случае его возникновения:
воздействие риска = вероятность риска × последствия риска.
Для иллюстрации этой идеи рассмотрим вопрос о том, имеют ли зда
ния на Британских островах защиту от землетрясений. Приходится приз
нать, что для такой защиты сделано очень немного. Многоэтажные дело
вые кварталы в Лондоне никакой защиты не имеют. Землетрясение
силой семь баллов по шкале Рихтера в Лондоне унесло бы очень много
жизней. Однако вероятность такого землетрясения настолько мала (фак
тически равна нулю), что принимать меры предосторожности считается
ненужным. С другой стороны, есть типы зданий, сейсмическая защита
которых обязательна, — например, атомные электростанции. Вероят
ность землетрясения не меняется, однако последствия слишком серьез
ны. После землетрясения силой 7 баллов в районе АЭС Heysham г. Ливер
пуль станет необитаемым на 10 тыс. лет (так, по крайней мере, думает
общественность). Конечно, при оценке ущерба от риска мы должны учи
тывать восприятие риска общественностью (пример 10.9). На деле оценка
возможного ущерба от риска является в значительной мере иррациональ
ной (пример 10.10), и поэтому воздействие риска следует оценивать по
следующей формуле:
воздействие риска = вероятность риска × последствия риска × общест
венное восприятие.
Пример10.9. Восприятие риска общественностью
Конечно, последствия землетрясения для атомной электростанции будут не столь
суровы, как предполагается, однако их восприятие общественностью именно та
ково. В 1980х гг. консалтинговая фирма в отрасли гражданского проектирования
Ove Arap and Partners проделала большую работу по проектированию и тестиро
ванию железнодорожных вагонов для перевозки низкоактивных ядерных отходов
по стране. Было проведено несколько широко разрекламированных эксперимен
тов, во время которых локомотив резко сталкивался с вагонами на скорости 100
миль в час. В этом случае вероятность аварии, которая привела бы к утечке ради
ации, была мала, и последствия были также незначительными: никаких мгновен
ных смертей — возможно, одиндва дополнительных случая заболевания раком,
приводящих к ранней смерти через несколько лет. Однако эта проблема сильно
взволновала общественность, следствием чего явилось требование создать совер
шенно не подверженные разрушению вагоны. С другой стороны, смертоносные
химикаты транспортируются всюду в сравнительно непрочных вагонах. В начале
1980х гг. я работал вблизи железной дороги, по которой каждый день проезжал
электровоз, тащивший две цистерны с цианистым газом. Авария могла повлечь за
Глава 10. Управление рисками 271

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

Пример 10.10. Неразумная оценка риска


Классическим примером неразумного восприятия риска является панический
страх перед заболеванием BSE. Вопервых, общественность повела себя необосно
ванно. Количество смертей, которое могло, причем лишь предположительно,
быть вызвано BSE, достигло 5% в год, то есть такого же количества, как смерти в
результате аллергической реакции на земляные орехи. Сотрудники BBC отправи
лись в местный супермаркет и взяли интервью у среднего покупателя, дымящего
сигаретой, с нагруженной пивом тележкой, которого поджидал изношенный авто
мобиль с лысыми шинами. «Вы едите говядину?» — спросили корреспонденты.
«Нет! — вскричал покупатель, — Это слишком опасно».
И вот, когда общественность вроде бы успокоилась, само правительство нача
ло вести себя неразумно. Оно, фактически, превратило продажу куска мяса для
жарки в столь же гнусное преступление, как торговля кокаином, поскольку, как
предполагалось, это могло привести к гибели одного человека раз в 20 лет. Ми
нистр сельского хозяйства появился на телевидении и заявил, что он обеспокоен
здоровьем общества! Если бы он действительно заботился об общественном здо
ровье, то должен был запретить земляные орехи, а уж потом объявлять войну
бифштексам.

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


приведенной выше формулы: выбираются числовые значения для веро
ятности, последствий и восприятия риска и перемножаются друг с дру
гом. В результате получается сводка рисков, связанных с проектом. В от
ношении каждого риска его вероятность, последствия и восприятие
могут быть оценены как высокие, средние, низкие, пренебрежимо малые,
или же по шкале от 0 до 3 (табл. 10.1). В противном случае каждому рис
ку придается числовой коэффициент (в действительности добавляются
логарифмы числовых значений), позволяющий оценить каждый риск по
шкале от 0 до 9. Это, однако, нецелесообразно по двум причинам. Вопер
вых, говорить о том, что риск с рейтингом 6 «хуже» риска с рейтингом 5,
но «лучше» риска с рейтингом 7, бессмысленно, поскольку выводы, сде
ланные на основании этих данных, более точны, чем оценки, на которых
они базируются. Вовторых, при таком подходе следующие два риска: один
с вероятностью 50%, оцениваемый в 0,5% от стоимости проекта, второй с

Таблица 10.1. Ранжирование факторов риска

Цифровой Вероятность,
Уровень Последствия Восприятие
балл %
Высокий 3 50 Р/2 Национальная проблема
Средний 2 5 Р / 20 Локальная проблема
Низкий 1 0,5 Р / 200 Проблема компании
Пренебрежимо малый 0 0,05 Р / 2 000 Отсутствие проблемы
272 Часть II. Функциональные области управления проектами

вероятностью 0,5% и стоимостью, равной 50% от стоимости проекта, —


должны быть оценены как равные. Фактически же второй риск является
более серьезным, поскольку он имеет намного более высокое распределе
ние возможных результатов. Вы должны задать себе вопрос: что является
более важным — ожидаемая стоимость риска или его предсказуемость? По
видимому, последняя чаще является предметом заботы руководителей [6].
В настоящее время рекомендуется использовать преимущественно ка
чественный, а не количественный подход к оценке риска [7]. При этом
параметрам рисков также присваиваются ранговые числовые значения
наподобие тех, которые приведены в табл. 10.1. Параметров, характери
зующих риски, может быть даже больше трех. Затем строится таблица
рисков и их параметров по аналогии с табл. 10.2 и проводится качествен
ная оценка этих рисков. Далее каждый риск оценивается по шкале с тем
же числом уровней, которое было присвоено параметрам. В результате
каждый риск определяется как высокий, средний, низкий или пренебре
жимо малый. Этот подход позволяет избежать ряда ложных выводов. С
его помощью А. Ван дер Мерве на 10% снизил ежегодные затраты Комис
сии ЮАР по энергоснабжению (Escom) на обеспечение безопасности сво
их подстанций [7].

Сочетание воздействия нескольких рисков


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

Подход «сверху вниз»


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

Таблица 10.2. Качественная оценка рисков

Риск Параметр 1 Параметр 2 Параметр 3 Параметр 4 Воздействие


R1 Высокий Средний Высокий Высокий Высокое
R2 Средний Высокий Средний Низкий Среднее
R3 Низкий Низкий Средний Низкий Низкое
Глава 10. Управление рисками 273

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


более тяжелых рисков [1]. Этот подход заключается в следующем: необ
ходимо взять элемент структурной декомпозиции проекта и развернуть
его на нижележащем сводном уровне, на котором насчитывается около
20 элементов декомпозиции. Выбор элементов декомпозиции зависит от
того, что именно, по нашим ожиданиям, будет порождать риски. Это мо
гут быть СДП, СДР, СДО, СДС или список материалов (СМ) для объекта.
Затем необходимо определить риски, связанные с каждым элементом, и,
что особенно важно, связи между рисками, то есть установить, делает ли
возникновение одного риска более или менее вероятным возникновение
другого. После этого вам нужно сосредоточить внимание либо на исклю
чении рисков, связанных с каждым элементом, либо на исключении свя
зей между рисками. Если вам удастся исключить связи, то вы сможете
изолировать каждый риск в схеме структурной декомпозиции. Причина
для ограничения количества элементов числом 20 заключается в следую
щем: если вы имеете опись каждого риска и каждой связи на отдельном
листе бумаги, то вам понадобится 420 листов. При 30 элементах листов
будет уже 930.
Наглядное графическое представление СДП, СДР и СДО на нужном
уровне можно получить с помощью двух средств, описанных ранее, —
плана контрольных событий (см. раздел 5.4) и схемы распределения ответ
ственности (см. раздел 6.4). План контрольных событий показывает СДП
на стратегическом уровне. Использование плана контрольных событий
иногда вызывает интересное последствие: может выявиться связь по рис
кам между двумя контрольными событиями, не соединенными логичес
кой связью. Такое случается, например, если при раннем контрольном со
бытии вы сделали определенные предположения по проекту, а при более
позднем контрольном событии вдруг выяснили, что выполнить эти пред
положения невозможно и что все контрольные события, зависящие от
этих предположений, являются недостижимыми. Подобной является, нап
ример, связь между контрольными событиями А2 и О5 на рис. 5.4: оба
они основываются на предположении о том, что нам известны площадки
1 и 2, и если это имеет место, то события не связаны между собой. Однако
если при свершении контрольного события А2 использование выбранных
площадок окажется невозможным, это отрицательно повлияет на конт
рольное событие О5. Схема распределения ответственности отображает
СДО, СДП и СДР на стратегическом уровне в одном документе. Она пока
зывает также, что все они зависят от одного элемента СДС — объема рабо
ты, а также от ее временных характеристик. Поэтому указанный документ
является очень мощным средством анализа методом «сверху вниз».
Подход «сверху вниз» можно проиллюстрировать на примере просто
го, состоящего из четырех пакетов работ проекта строительства склада
(рис. 10.2). Если предположить в этом проекте только наличие зависимос
тей типа «окончание / начало», то его продолжительность будет оценивать
ся в семь месяцев. Возможно осуществить скоростную реализацию проекта
путем совмещения выполнения этих пакетов работ по времени. Предполо
жим, однако, что это невозможно сделать на пути А–С–D: стальные
конструкции невозможно закупить до окончания этапа проектирования, и
все они поступят к нам одновременно; таким образом, монтаж нельзя на
чать до их поступления. Можно начать работы на площадке В до окончания
274 Часть II. Функциональные области управления проектами

Рис. 10.2. Простая сетевая модель предшествования в проекте строительства склада

проектирования, но в этом нет необходимости, поскольку продолжитель


ность будет определяться поставкой стальных конструкций.
Теперь рассмотрим риски. Предположим, что проект будет начат в на
чале сентября, после летних отпусков. В этом случае риски заключаются
в следующем.
1. Проектирование здания может занять больше или меньше трех меся
цев. На основе прошлого опыта мы можем говорить о том, что оно
займет два, три или четыре месяца со следующей вероятностью:
■ два месяца — 25%;
■ три месяца — 50%;
■ четыре месяца — 25%.

Таким образом, проектирование может быть закончено не ранее кон


ца октября и не позже конца декабря.

2. Подготовка площадки невозможна, если на земле лежит снег. Снег


выпадает в течение четырех месяцев в году со следующей вероят
ностью:
■ декабрь — 25%;
■ январь — 25%;
■ февраль — 50%;
■ март — 25%.

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


ли она начнется в октябре, то займет только два месяца; если в ноябре, то мо
жет иметь следующий диапазон значений продолжительности (рис. 10.3):
■ два месяца — 75%;
■ три месяца — 19%;
■ четыре месяца — 3%;
■ пять месяцев — 2%;
■ шесть месяцев — 1%.
Глава 10. Управление рисками 275

Рис. 10.3. Расчет продолжительности работ по пакету В при их начале в ноябре

Аналогичные списки были бы получены, если бы работа началась в


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

3. Возможно, у вас есть два потенциальных поставщика стальных


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

С чемто похожим мы сталкивались при проектировании. Однако си


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

4. Стальные конструкции нельзя монтировать при сильном ветре, а это


происходит со следующей вероятностью:
■ февраль — 25%;
■ март — 50%.

Продолжительность этой работы, как и работы по подготовке площад


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

Диаграммы влияния
Диаграммы влияния являются инструментами, позаимствованными из
системной динамики, и могут помочь в выполнении анализа методом
«сверху вниз». Они показывают, как риски влияют друг на друга; некото
рые риски усиливают другие (+), а некоторые снижают (–). На рис. 10.4
показан пример диаграммы влияния. Сила этого метода заключается в
выявлении петель влияния. Ошибочные циклы имеют четное (или нуле
вое) число отрицательных влияний, а устойчивые циклы — нечетное. На
рис. 10.4 петля ADEKLIBA является ошибочной, а петля ADEGHJBA — ус
тойчивой. В ошибочном цикле внешне обусловленное воздействие может
неопределенно усиливаться.

Подход «снизу вверх»


Подход «снизу вверх» предусматривает анализ рисков на нижнем уровне [8].
Он может помочь определить несколько критических путей и рассчитать
ряд результатов стоимости и продолжительности проекта, позволяющих
Глава 10. Управление рисками 277

Рис. 10.4. Диаграмма влияния


278 Часть II. Функциональные области управления проектами

руководителю проекта предусмотреть соответствующие непредвиденные


расходы. Однако это, по сути, негативный подход к рискам, поскольку он
предполагает, что элементы риска находятся вне контроля руководите
лей. Он ничего не дает руководителю для того, чтобы количественно оп
ределить или передать информацию для выработки соответствующей уп
равленческой реакции с целью снижения или исключения рисков.
При этом подходе на нижнем уровне декомпозиции разрабатывается
детальная модель проекта. Работам, как и в приведенном выше примере,
присваиваются вероятностные значения продолжительности и / или стои
мости. Однако на нижнем уровне невозможно рассчитать различные вари
анты конечных результатов вручную, как это было сделано выше. Вместо
этого мы выполняем анализ по методу МонтеКарло. Модель проекта ана
лизируется множество раз: обычно от 100 до 10 тыс., в зависимости от ве
личины модели. Каждый раз для каждого параметра получают случайное
число, для которого имеется ряд значений, и присваивают ему соответству
ющее значение. (Это ведет к упрощающему картину предположению о
том, что элементы рисков не взаимосвязаны, что может не соответствовать
действительности, см. рис. 10.4.) Затем на основе этих значений рассчиты
вают стоимость и продолжительность проекта, а также ряд его возможных
последствий. Фактически, производится выборка характеристик в процес
се выполнения многократного анализа проекта. Результаты анализа по ме
тоду МонтеКарло отображаются в виде вероятностного распределения
сроков выполнения и / или стоимости проекта. Это может быть простое
или интегральное распределение. На рис. 10.5 показаны оба распределе
ния для продолжительности проекта строительства склада (см. также
рис. 10.2). В этом простом проекте критический путь может пройти либо
через А–B–D, либо через A–C–D, и продолжительность может находиться в
интервале между 6 и 11 месяцами. Вероятность того, что каждый из этих
путей или они оба станут критическими, такова:

Рис. 10.5. Простое и интегральное вероятностное распределение для продолжительности


проекта строительства склада
Глава 10. Управление рисками 279

■ А–B–D — 52%;
■ оба — 24%;
■ A–C–D — 24%.
Поскольку проект небольшой, эти расчеты можно проделать вруч
ную: у меня это заняло один час. Для более крупного проекта расчеты
должны проводиться с использованием метода МонтеКарло. Для данно
го проекта медиана результата составляет восемь месяцев (половина ре
зультатов меньше или равна этой величине), а в 90% результатов продол
жительность составляет менее девяти месяцев. Наиболее вероятная
продолжительность проекта (мода) составляет девять месяцев. Если де
вятимесячная продолжительность является приемлемой, то мы можем
принять эти цифры. Если же нет, то нам потребуется сократить продол
жительность проекта. Критический путь показывает, что наиболее эф
фективные усилия могут быть предприняты для сокращения пути A–B–D
и что можно осуществить скоростное проектирование фундамента. Од
нако данный анализ не показывает последствия обращения к каждому из
двух поставщиков. Это можно проанализировать только при использова
нии подхода «сверху вниз».

Взгляд владельца проекта на риски


Описанные количественные методы позволяют оценить стоимость про
екта. Однако действительная стоимость проекта — это не те цифры, кото
рые команда проекта получила в результате расчета с использованием
указанных методов, а та стоимость, которую владелец присваивает про
екту и которая отражает его восприятие рисков и, в определенной мере,
общественное восприятие (если владелец учитывает общественное мне
ние — см. пример 10.11).
Пример 10.11. Восприятие риска владельцем проекта
В начале 1980х гг. государственная компания NIREX предложила хранить проме
жуточные радиоактивные отходы в заброшенной шахте компании Imperial
Chemical Industries (ICI) возле г. Биллингема. Это было одно из самых безопасных
предложений по хранению таких отходов. Данный вариант не должен был стоить
для ICI ничего (впрочем, см. пример 10.12) и в то же время приносил бы компа
нии доход — привлекательный проект, не связанный с какимлибо риском. Одна
ко ICI не дала согласия на осуществление этого проекта, поскольку местное сооб
щество не рассматривало этот путь как возможный, а ICI была заинтересована в
благоприятном мнении местной общественности. Ирония ситуации заключалась
в том, что ICI эксплуатировала один из самых крупных частных ядерных источни
ков на площадке в Биллингеме.

Пример 10.12. Ценность общественного мнения о проекте и ущербе для окружаю


щей среды
Безусловной ошибкой было бы говорить о том, что проект, описанный в приме
ре 10.11, «ничего не будет стоить для компании ICI». Этот проект повлек бы за со
бой потерю расположения местной общественности, и поэтому его «стоимостью»
является вся выгода, которую компания рассчитывала получить благодаря этому
расположению. Очевидно, компания сочла, что ожидаемые доходы не оправдыва
ют этой «стоимости».
280 Часть II. Функциональные области управления проектами

Таково проявление общей установки, завоевывающей все больше привержен


цев. Окружающая среда сама по себе имеет ценность, и если проект, к которому
мы приступаем, снижает эту ценность, мы должны это учитывать при оценке его
стоимости. В случае, описанном в примере 10.11, потеря ценности имела денежное
выражение в виде падения цен на дома в Биллингеме. Таким образом, стоимость
проекта была бы возложена не только на компанию ICI, но и на местную общест
венность.
В данном случае падение ценности вызвано страхом перед всем, что связано с
ядерной физикой. Примером, в котором угроза окружающей среде привела к ре
альному снижению стоимости, является Адриатическое побережье Италии. За
силье синезеленых водорослей сократило возможность получения доходов от ту
ризма. Эти водоросли расплодились изза хозяйственной деятельности в верхней
части долины реки По, однако люди, которые получили прибыль от этой деятель
ности, не оплатили ее стоимость. Решением проблемы является налог на причине
ние ущерба окружающей среды — такой налог в Италии может быть собран. Возни
кает, однако, вопрос, должна ли, к примеру, Швейцария платить налог Германии за
сброс промышленных вод в Рейн? Ответ на этот вопрос не входит в содержание
этой книги.

Информирование участников проекта о результатах


анализа рисков

Конечной целью моделирования рисков является доведение информации


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

Чтобы служить эффективным средством коммуникации, модель рис


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

10.4. СНИЖЕНИЕ РИСКОВ


После выявления и оценки рисков следует рассмотреть способы их сни
жения. Существует три основных подхода [9]:
1) избегание риска: выявив риск, руководитель начинает перепланиро
вание, чтобы избежать его;
2) перекладывание риска: руководитель пытается переложить риск на
когото другого;
Глава 10. Управление рисками 281

3) учет непредвиденных расходов в плане: руководитель не предприни


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

Д. Пим и M. Уайдмен [9] используют аналогию с человеком, в которо


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

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

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

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

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

Контракты
Посредством контрактов риски распределяются между владельцем про
екта, подрядчиком и субподрядчиками. Существуют два общих принци
па заключения контрактов.
1. Риск перекладывается на ту из сторон, которая больше всех спо
собна его контролировать и заинтересована в этом. Нет никакого
смысла перекладывать риски на подрядчика или субподрядчика, ес
ли они не располагают возможностями и стимулами для их контроля.
В настоящее время британское Общество инженеров гражданского
282 Часть II. Функциональные области управления проектами

строительства (Institution of Civil Engineers) пересматривает стандарт


ные формы контрактной документации в соответствии с этим прин
ципом [10]. Существует четыре вида контрактов в соответствии с раз
личными подходами к распределению рисков. Выбор подходящего
типа является частью договорной стратегии владельца проекта, одна
ко эта тема не входит в содержание данной книги [11].
2. Риск распределяется между субподрядчиками, если он находится в
сфере их контроля. Для обеспечения этого используются контракты
взаимной поддержки; в эти контракты между владельцем и подрядчи
ком включаются те же статьи, что и в контракты между подрядчиком и
субподрядчиками. Я сталкивался с такими случаями, когда подрядчи
ки ощущали себя как между молотом и наковальней и принимали не
померно жесткие условия владельца для того, чтобы выиграть тендер,
опасаясь, однако, что субподрядчики с этими требованиями не согла
сятся, поскольку в заказе не заинтересованы. Это часто происходит с
подрядчиками в оборонном или государственном секторах. Чтобы из
бежать такого поворота событий, можно попытаться заставить субпод
рядчиков заключить контракт непосредственно с владельцем проекта и
использовать власть владельца для того, чтобы поставить субподрядчи
ка на место. Возможно, поставщик не дорожит бизнесом с данным под
рядчиком, но к собственнику проекта, он, возможно, относится с боль
шим пиететом.

Учет непредвиденных расходов


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

Увеличение сроков и / или стоимости проекта


Вы можете ввести этот резерв либо в виде единого цифрового коэффици
ента, рассчитанного методом «снизу вверх» (как объяснялось выше), либо с
разбивкой по работам. При любом подходе руководитель проекта должен
выполнить как минимум две оценки, как это было описано в разделах 8.5 и
9.2: исходную оценку без учета непредвиденных расходов и оценку с уче
том непредвиденных расходов. Первая называется базисной и доводится до
сведения команды проекта в качестве планового показателя; вторая произ
водится для собственника проекта, чтобы гарантировать обеспечение про
екта денежными средствами и ресурсами. Руководитель проекта также мо
жет после этого выполнить еще две оценки: наиболее вероятного
результата (показателя, с которым он работает) и текущую оценку, являю
щуюся базисной, которая включает некоторые уже понесенные непредви
денные расходы. Причина, по которой команде проекта сообщается имен
но базисная или текущая оценка, состоит в том, что если исполнители
будут знать сумму заложенных в бюджет непредвиденных расходов, то
Глава 10. Управление рисками 283

непременно ее используют. Собственнику же сообщается оценка, вклю


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

Планы действий в чрезвычайных ситуациях


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

Реализация таких альтернативные планов может быть или не быть бо


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

10.5. КОНТРОЛЬ РИСКОВ


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

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


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

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


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

Как уже говорилось, риски меняются в течение жизненного цикла про


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

Рис. 10.6. Формуляр для отслеживания позиций рисков


Глава 10. Управление рисками 285

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

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

Рис. 10.6. Формуляр для отслеживания позиций рисков (продолжение)


286 Часть II. Функциональные области управления проектами

Рис. 10.7. Ежемесячный отчет о рисках «первой десятки»


Глава 10. Управление рисками 287

являются стартовые семинары (см. главу 13). Для выполнения переоцен


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

10.6. МЕТОДИКИ PRAM И SCERT


В настоящее время управление рисками в проекте методом «снизу вверх»
систематизировано в виде методики анализа и управления рисками про
екта (PRAM) [2, 3]. В этом разделе кратко изложена методика PRAM, для
того чтобы показать, как она позволяет реализовать идеи, выдвинутые в
данной главе. Эта методика, несмотря на ее новизну, создана на основе
предшествующей ей методики синергетического комбинаторного анали
за и оценки (SCERT), которая была неоднократно описана [1, 11]. Однако
после десятилетних углубленных исследований эта методика была усо
вершенствована и получила более удобное для пользователей название.
Методика SCERT (табл. 10.3) реализуется в три этапа, каждый из кото
рых имеет две фазы [1, 11]. Методика PRAM в настоящее время является
девятишаговым процессом управления рисками (табл. 10.4).

10.7. ОСНОВНЫЕ ПОЛОЖЕНИЯ


1. Управление рисками включает пять шагов:
■ идентификация источников риска;
■ оценка воздействия отдельных рисков;

Таблица 10.3. Методика синергетического комбинаторного анализа и оценки (SCERT)

Раздел Шаг Фаза Действие


Детальная декомпозиция
Качественная
Определение, 10.2 Содержание Определение рисков
оценка
Определение реакций
Связи между реакциями на
Качественная риски
Определение, 10.2 Структуры
оценка Определение приоритетов
связей
Решение о том, что
Количественная измерять количественно
Оценка, 10.3 Отдельные риски
оценка Количественная оценка
неопределенности
Количественная Комбинированные
Оценка, 10.3 Комбинирование рисков
оценка риски
Определение необходимых
Планирование
Снижение, 10.4 Управление реакций
реакций
Планирование реакций
Управление, 10.6 Управление Мониторинг Мониторинг и контроль
288 Часть II. Функциональные области управления проектами

Таблица 10.4. Методика анализа и управления рисками проекта (PRAM)

Раздел Шаг
Определение проекта
В качестве части стратегии проекта Сосредоточение внимания на PRAM
Определение, 10.2 Определение рисков
Определение, 10.2 Структуризация рисков
Снижение, 10.4 Распределение прав
Оценка, 10.3 Оценка рисков
Оценка, 10.3 Анализ оценок
Снижение, 10.4 Планирование реакций
Управление, 10.5 Управление рисками

■ оценка совместного воздействия рисков;


■ определение возможных путей снижения рисков;
■ контроль выявленных рисков.
2. Существуют два типа риска:
■ бизнесриск;
■ страхуемый риск.
3. Существуют пять источников риска:
■ внешний непредсказуемый;
■ внешний предсказуемый;
■ внутренний технический;
■ внутренний нетехнический;
■ риск, связанный с нарушением действующего законодательства.
4. Методы выявления рисков включают в себя:
■ экспертные оценки;
■ декомпозицию планов;
■ анализ предположений;
■ анализ ключевых элементов решений;
■ групповой мозговой штурм.
5. Воздействие отдельных рисков является результатом вероятности по
явления рисковых событий, последствий в случае их наступления и
общественного восприятия этих последствий.
6. При оценке совместного воздействия нескольких рисков можно вос
пользоваться:
■ подходом «сверху вниз» — инструментом принятия управленчес
ких решений;
■ подходом «снизу вверх» и анализом по методу МонтеКарло;
■ диаграммами влияния.
7. Существуют три способа снижения риска:
■ избегание риска:
■ перекладывание риска;
■ резервирование непредвиденных расходов на риски.
8. Контракты должны заключаться на основании того, что риски долж
ны быть переданы той стороне, которая наиболее заинтересована в
этом и способна их контролировать.
Глава 10. Управление рисками 289

9. В контроле рисков выделяют четыре шага:


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

ЛИТЕРАТУРА
1. Cooper, D. F., and Chapman, C. B. (1987). Risk Analysis for Large Projects: Models,
Methods and Cases. Wiley.
2. Chapman, C. B., and Ward, S. C. (1997). Project Risk Management: Processes,
Techniques and Insight. Wiley.
3. Simon, P., Hillson, D., and Newland, K. (1997). Project Risk Analysis and
Management Guide. Association for Project Management.
4. CCTA (1996). PRINCE 2: Project Management for Business. The Stationery Office.
5. Kahkonen, K., and Aarto, K. A., eds (1997). Managing Risks in Projects. Wiley.
6. Williams, T. M. (1996). «The two dimensionality of project risk». International
Journal of Project Management, 14 (3), June.
7. Turner, J. R. (1996). Editorial. International Journal of Project Management, 14 (3),
June.
8. Hertz, D. B., and Thomas, H. (1983). Risk Analysis and its Applications. Wiley.
9. Pym, D. V., and Wideman, R. M. (1987). «Risk management». The Revised Project
Management Body of Knowledge. Project Management Institute.
10. Institution of Civil Engineers (1995). The New Engineering Contract, 2nd edn. ICE.
11. Turner, J. R., ed (1995). The Commercial Project Manager, McGrawHill.
Предметный указатель

АББРЕВИАТУРЫ БСЗР — базисная стоимость запланированных


работ
BCG — Boston Consulting Group ВМТР — ведомость материальных и трудовых
C/SCSC — Cost and Schedule Control Systems ресурсов
Criteria («Критерии систем контроля затрат и МКП — метод критического пути
календарных планов») МСП — малые и средние проекты
PERT — Programme Evaluation and Review ОСП — офис сопровождения проекта
Technique («Метод оценки и обзора прог# ПОО — позиции основного оборудования
рамм») ПСВР — плановая стоимость выполненных работ
PRAM — Project Risk Analysis and Management ПСЗР — плановая стоимость запланированных
(«Анализ и управление рисками проекта») работ
SCERT — Synergistic Combinatorial Evaluation ПСО — «Персонал – системы управления – ор#
and Review Technique («Методика синергети# ганизационные схемы»
ческой комбинированной оценки и анализа») ПТС — перечень требований к системе
SSADM — Structured Systems Analysis and СДП — структурная декомпозиция продукта
Design Methodology («Методология структур# СДР — структурная декомпозиция работ
ного анализа и проектирования систем») СДС — структурная декомпозиция стоимости
СИУП — система информации для управления
АКП — анализ критического пути проектом
БСВР — базисная стоимость выполненных ра# ЧТС — чистая текущая стоимость
бот УОК — управление общим качеством

ТЕРМИНЫ В
Ведомость
А ■ исключений 393
Анализ ■ комплектации работ — см. Ведомость
■ PESTLE 106 комплектовочная, работ
■ PRAM — см. Методика анализа и управ ■ комплектовочная 174
ления рисками проекта — материалов 191, 340
■ «если, то…» 246, 253, 257, 412 — работ 236, 337–341, 391
■ методом Монте#Карло 278–279 ■ материальных и трудовых ресурсов,
■ проекта ВМТР 218
— после завершения 370 ■ расценок 218
■ риска 270–279 ■ расчетная 172, 241, 334–336
Аудит 431–433, 444, 449–453 Видение 100–102, 107, 152
■ внутренний 433 Владелец 33, 73–77, 110, 279–282
■ по завершении проекта 371, 433 Внештатные работники 86, 88
Время ожидания 240, 241
Б Выполнение
Базис — см. Базисный расчет ■ В. и контроль — см. Фазы жизненного
Базисная стоимость 200, 210, 222, 349–351 цикла проекта
Базисный расчет 235, 353 ■ скоростное 106
Базисный срок 235, 250, 333, 337, 338
Бюджет 210, 322, 353 Г
■ годовой Б. 62, 63 Гарантийные обязательства 281
544 Предметный указатель

Гарантия качества — см. Качество, гарантия Заказы и закупки — см. Материальнотехни


Гистограмма потребления ресурсов — см. Ре ческое обеспечение
сурсы, гистограмма потребления Законодательство 521
Закрытие [проекта] — см. Фазы жизненного
Д цикла проекта
Дата — см. Срок Затраты 207–227, 232, 351, 352, 356, 392, 419,
Делегирование 423
■ полномочий 400, 404 ■ контроль З. — см. Контроль затрат
■ принятия решений 87 ■ на обеспечение качества 195, 196
■ работ 122 ■ трудозатраты 207, 219, 220, 225, 348–351
Диагностика
■ проектной направленности 434–444 И
■ успеха / провала 444–449 Иерархия
Диаграмма ■ потребностей, А. Маслоу 462, 463
■ влияния 276, 277 ■ проекта — см. Уровни управления проек
■ Гантта 236 том
■ линейная 37, 236 ■ проектная 158
— вложенная 332, 337 ■ функциональная 84, 85, 157
Договор — см. Контракт ■ целей 32, 35
Документ Изменение
■ возвратный 341, 342, 344–348 ■ в родительской организации
Документация — см. Проектная документа — техническое 77–79, 494, 496
ция — корпоративной культуры — см. Изме
нение в родительской организации,
Ж культурное
Жизненный цикл — культурное 77–80
■ продукта 475–478 ■ контроль И. — см. Контроль изменений
■ проекта 37–43, 143, 194–196, 293, ■ организационное 508–510
296–298, 311, 451, 463, 482, 508 ■ планирование И. — см. Планирование
— фазы Ж. ц. п. — см. Фазы жизненного изменений
цикла проекта ■ сопротивление И. 81–83
■ разработки ■ управление И. — см. Управление измене
— программного обеспечения 498, 502, 503 ниями
— продукта 481, 482 Инвестор 75, 109
Жизнеспособность проекта 37, 41, 105, 201 Инжиниринг
■ оценка Ж. п. 201 — конкурентный 493–498
Инициация проекта — см. Проект, инициация
З Инновация 478, 479
Зависимости Исполнительные чертежи — см. Чертежи ис
■ «начало / начало» 243, 244, 248 полнительные
■ «начало / окончание» 243, 244, 248 Исследование
■ «окончание / начало» 243, 244 ■ диагностическое 425, 426
■ «окончание / окончание» 132, 243, 244, ■ осуществимости проекта 305–311
248
Заинтересованные стороны 76, 77, 80 К
Заказчик 33 Календарный план работ — см. План кален
■ коллективный 189, 304, 400 дарный, работ
■ требования — см. Требования заказчика Качество 177–181
— определение т. з. — см. Требования ■ гарантия К. 315, 400
заказчика, определение ■ контроль К. — см. Контроль качества
Предметный указатель 545

■ обеспечение К. 181–184 Кривая


— затраты на О. к. 195–197 ■ S#образная 227, 257, 353
— продукта 182 ■ обучения 204–206
— проекта 181 Критический путь 249
■ план К. 187 ■ анализ К. П., АКП 241, 421
■ процессов управления 186–187 ■ метод К. П., МКП 241, 421
■ управление общим К., УОК — см. Управ Куратор 75, 76
ление общим качество
Команда Л
■ мотивация К. 460–464 Лидерство 464, 465
■ проекта 455 ■ основанное на действии 455, 456
■ расформирование 368–370
■ руководитель К. — см. Руководитель ко М
манды Материально#техническое обеспечение 520,
■ уровни К. 457, 458 531
■ формирование К. 456, 458–460 Матрица
Коммуникация 491, 492, 530, 531 ■ BCG 63, 64
Контракт 113, 152, 153, 169, 281, 282, 395, 451, ■ Ансоффа 63, 64
468, 506, 531, 541 ■ влияния 379
Контролер ■ на базе временного прикомандирования
■ затрат 395 158
■ качества 395 ■ сбалансированная 157
■ проекта 394 ■ скоординированная 157
Контроль ■ целей и методов 52–54
■ затрат 221–227, 395 Методика
■ изменений 184, 193, 194, 354, 355, ■ контроля качества 197
357 ■ оценки и анализа программ, PERT — см.
■ качества 184–187 Модель сетевая, PERT
■ над предметной областью 354 ■ управления рисками
■ организации 353 — анализа и управления рисками проек#
■ период К. — см. Период контроля та, PRAM 260, 287, 288
■ работ 340–344 — синергетического комбинаторного
■ разработки продукта 483–485 анализа и оценки, SCERT 287
■ рисков 283–287 Методология
■ сроков 256, 257 ■ C/SCSC 37, 423
■ цикл К. — см. Цикл контроля Миссия 60, 61
Контрольное событие 44 Модель
■ вспомогательное 143, 148 ■ COCOMO 218, 220
■ выбор К. с. 133 ■ Code#and#Fix 498
■ план К. с. 44, 80, 130–137, 142–148, 166, ■ «владелец / подрядчик» 73, 74
244, 273, 308 ■ проекта 131, 304, 345
■ планирование К. с. — см. Контрольное ■ разработки программного обеспечения
событие, план — каскадная 499–502
Контрольный куб стоимости — 36, 210–212 — поэтапная 499
Контрольный период — см. Период контроля — спиральная 503–506
Конфигурация ■ семи движущих сил проектно#ориенти#
■ управление К. 188–195 рованного управления 95
■ успешная 541, 542 ■ сетевая 250–253
Координатор 75, 76, 301 — PERT 101, 263, 421, 422
Коэффициент дисконтирования 70 — вложенная 337
546 Предметный указатель

— гибридная 244 ■ эффективность О. 341, 342


— предшествования 243–245, 247, Офис сопровождения проекта, ОСП 390–395
251–253 Оценка
— с работами#стрелками 244, 245, ■ жизнеспособности проекта — см. Жиз
247–250 неспособность проекта, оценка
■ стратегического управления 105–106 ■ методы О.
Мониторинг — в инженерно#строительной отрасли
■ М. и контроль 165, 359, 484 213–216
■ процессов управления 187 — в строительстве 216–218
■ результатов 186 — в сфере информационных технологий
■ рисков 285 218–229
Мотивация 460, 462, 463 — сравнение М. о. 221
■ нереалистичная 101
Н ■ продолжительности работ — 201, 202, см.
Неопределенность 31, 102, 261, 521 также Работа, продолжительность
■ стоимости, стоимостная 200–212
О — методы О. с. — см. Оценка, методы
Области работ — см. Работа, область — структура О. с. 207–213
Обучение 91 — типы О. с. 202–204
■ кривая О. — см. Кривая обучения ■ управленческая 71
■ производственное 82, 365, 400, 428 ■ уровни О. 122, 123
Объект 32, 33 ■ успеха проекта 95–99
Окончание и закрытие — см. Фазы жизненно ■ хода выполнения проекта 344–349
го цикла проекта
Окружение проекта — см. Проект, окружение П
Окупаемость Пакет работ — см. Работа, пакет
■ коэффициент внутренней О. 70 Параллельное выполнение 105, 316
■ период О. 70 Параллельное проектирование 105
Оперативная группа 481 «Перевалочный пункт» 54, 301, 489
Определение проекта — см. Проект, определе Перепланирование 343
ние Период
Организация ■ контроля 338, 340, 357, 358
■ линейная 155, 156 ■ ожидания 174, 351
■ матричная 155, 156 ■ окупаемости 70
■ многоцелевая 159–161 ■ отчетный П. 227, 341, 342, 349
■ проекта План
— типы О. п. 156–158 ■ бизнес#п. — 99, см. также Планирование,
■ разработки продукта 479–481 бизнесП.
■ родительская 73, 77–79 ■ календарный 232–236, 241–243
Освоенный объем 223, 225, 351 — исследований 309
■ анализ О. о. 345, 349 — работ 44, 137, 166, 331, 334
■ метод О. о. 222 — сводный 380
Осуществимость — см. Исследование осуще — текущий 235
ствимости проекта ■ стратегический 65
Отчет ■ эффективность П. 341
■ о ходе работ 392 Планирование
■ об определении проекта 320–324 ■ бизнес#П. 60–63, 425
■ стартовый аналитический 290, 291 ■ выполнения проекта 331–337
Отчетность 113, 450, 541 ■ детальное 32, 33, 56, 100, 101, 121–123,
■ одностраничная 113, 138, 337 141, 232
Предметный указатель 547

■ изменений 80 ■ в развивающихся странах 531–535


■ исследований 308, 309 ■ жизнеспособность П. — см. Жизнеспо
■ календарное 250–253 собность проекта
— работ — см. План календарный, ра ■ заказчик П. — см. Заказчик
бот ■ инициация П. 295
— ресурсов 253, 400, см. также Ресурсы, ■ информационных систем 498–507
гистограмма потребления ■ исследований и разработок 485–493
— старта проекта 302, 303 ■ классификация П. 386–388
■ контрольных событий 130–136, 143–149 ■ команда П. — см. Команда проекта
— вспомогательных К. с. 143 ■ координатор П. — см. Координатор
■ корпоративное 63 ■ куратор П. — см. Куратор
■ методом «бегущей волны» 100, 241, 332, ■ международный 513–517
498, 505 — проблемы 517–519
■ недостатки в П. 99–101 — типы 514–517
■ передачи продукта пользователям 365 — управление П. м. 535–538
■ проекта 489, 490, 541 ■ мелкий 377, 378
■ работ 80, 346, 387, 388 ■ модель П. — см. Модель проекта
■ разработки продукта 481–483 ■ назначение 125
■ результата 367 ■ П. НИОКР — см. Проект исследований и
■ сетевое 246–250, 421, 423 разработок
■ системы П. и контроля 109, 110, 419, 420 ■ обеспечение ресурсами 329, 330
■ точность П.123 ■ «оздоровление» 354–357
■ уровни П. 43, 44, 66, 388, см. также Уров ■ окружение П. 49, 460–462
ни управления проектом ■ определение П. 124, 293, 294
— интегративный 388 — отчет об О. п. — см. Отчет об опре
— стратегический 112, 130, 388 делении проекта
— тактический 388 — семинар по О. п. — см. Семинар по
Планируемый разрыв 69, 476 определению проекта
Подпроект 127, 131, 145, 148, 378 ■ организация П. — см. Организация про
Подрядчик 33, 73–76, 96, 110, 111, 202, 514 екта
Пользователь 76, 317, 365–367, 499, 506 ■ планирование П. – см. Планирование
Предложение и инициация — см. Фазы жиз проекта
ненного цикла проекта ■ портфель П. 375–379
Предметная область проекта — см. Проект, ■ предметная область П. 125, 126, см. также
предметная область Функциональные области управления
Приемочные испытания 324 проектом
Приоритет 67–69, 90–92, 99, 377–381 ■ ПСО 78, 79, 88, 90
Проверка состояния 431–434, см. также Аудит ■ руководитель П. — см. Руководитель
внутренний проекта
Программа 63, 65, 90, 91, 379–388, 391, 421 ■ совет П. 189, 410, 411
■ директор П. 381–384 ■ содержание П. — см. Проект, предмет
■ управление П. 375, 376, 379–381, 385, ная область
388, 421 ■ сопровождение П.
Продукт — отдел С. п. — см. Отдел сопровожде
■ новый ния проекта
— разработка 478–485 ■ старт П. 294–302
■ передача пользователям 365, 366 ■ стратегия П. — см. Стратегия проекта
Продуктивность 534, 535 ■ технологический — см. П. исследований
Проект 28–34 и разработок
■ аудит П. — см. Аудит ■ типы П. 53, 54
548 Предметный указатель

управление П. — см. Управление проек


■ ■ подкритическая 235, 257
том ■ продолжительность Р. 236–241
■ уровни П. — см. Уровни управления про ■ распределение Р. 337
ектом ■ стоимость Р. — см. Стоимость работ
■ фазы П. — см. Фазы жизненного цикла ■ структурная декомпозиция Р. —
проекта см. Структурная декомпозиция работ
■ экспертиза П. 317 ■ утверждение Р. 333, 334
Проектирование и экспертиза — см. Фазы Разработка
жизненного цикла проекта ■ программного обеспечения — см. Про
Проектная документация — см. также Проек ект информационных систем
тирование и экспертиза ■ продукта — см. Продукт новый, разра
■ исполнительная П. д. 192 ботка
■ проектно#сметная 107, 108, 194, 328, 432 Разрешение
■ рабочая П. д. 44, 328, 392, 393 ■ на проект 317, 495
■ стандартная 127 ■ на осуществление меры 343
Проектная направленность Расчет — см. Оценка
■ диагностика П. н. — см. Диагностика Расчетная себестоимость — см. Базисный расчет
проектной направленности Резерв времени 233–236
Проход Результативность 443, 460
■ обратный 248 Реинжиниринг бизнес#процессов 508, 509
■ прямой 248 Ресурсы
Процедура ■ гистограмма потребления Р. 173, 253–256
■ адаптация П. к требованиям проекта ■ календарь Р. 173, 174
406, 407 ■ обеспечение проекта Р. — см. Проект,
■ руководство по П. — см. Руководство по обеспечение ресурсами
процедурам ■ потребность в Р.
■ управления проектами 425, 426 — выравнивание П. в р. 253–256
— ISO 10006 409, 412–414 ■ распорядитель Р. 102, 330, 376, 381–384
— PMBoK 412, 415–417 ■ распределение Р. 201
— PRINCE 2 407–411 ■ расходование Р. 169, 222, 391
Процент готовности 223, 225, 256, 350, 351 ■ централизованный пул Р. 329, 376, 377
Процессный подход 46–48 Риск
Путь ■ анализ Р. — см. Анализ риска
■ критический 234, 235, 249, 257 ■ бизнес#р. 261
■ подкритический 257 ■ внешний 264, 265
■ результирующий 132–134 ■ внутренний 264, 265
■ восприятие Р. 279, 280
Р ■ идентификация Р. 261, 267–269
Работа ■ контроль Р. — см. Контроль рисков
■ ведомость комплектации Р. — см. Ведо ■ объединение Р. 272
мость комплектации работ ■ регулирование Р. 263
■ завершение Р. 363 ■ снижение Р. 280–283
■ контроль Р. — см. Контроль работ ■ страхуемый 262
■ критическая 234, 257 ■ технический 107, 108, 264, 268
■ область Р. 132 ■ юридический 266, 267
■ объем Р. 169–171 Руководитель
■ пакет Р. 31, 122, 124, 142, 143, 240, 241 ■ команды 123
■ содержание П. р. 142 ■ линейный 368
— выписка из содержания П. р. 185, 241 ■ проекта 455, 465–469
■ план Р. – см. План календарный, работ — культурный профиль Р. п. 525–528
Предметный указатель 549

■производства 88–90, 157–159, 365 ■прогноз С. по завершении проекта 351


■функциональный 84, 86–88, 157 ■проекта 200–209, 225, 279–283, 349–353
Руководство ■ работ
■ по процедурам 399, 402–406 — базисная — см. Стоимость базисная
■ по реализации проекта 323, 324 — плановая — см. Стоимость плановая
■ разработка Р. 401 — фактическая 350
■ стиль Р. 468, 469 ■ сметная выполненных работ 223, 225,
350, 351
С ■ чистая текущая, ЧТС 70
Семинар Стратегия проекта 49, 131, 134, 136, 182, 305,
■ стартовый 318–320 306, 311
■ по определению проекта 299, 318, 319 Строительство
Система ■ скоростное 106, 276
■ информации для управления проектом, Структурная декомпозиция 111–113, 120, 210
СИУП 412, 417–421, 424–428 ■ организации, СДО 35, 152, 211
— выбор и внедрение 426, 427 ■ продукта, СДП 35, 112, 120, 191, 211
— проектирование СИУП 419 ■ работ, СДР 36, 71, 100, 120–124, 127, 136,
■ перечень требований к С., ПТС 425 213–215, 272, 322, 541
■ сетевого планирования 138, 421, 423 ■ стоимости, СДС 36, 210–213
■ управления затратами и ресурсами ■ уровни С. д. — см. Планирование, уровни
423 Субподряд 208
Сопровождение проекта — см. Отдел сопро Схема распределения ответственности 162–168
вождения проекта
Спецификации — см. Технические условия Т
Срок Тендер 202, 205, 496
■ базисный 235 Технические условия 178, 179, 183
■ календарный 235 Требования 14, 48, 161
■ начала [выполнения работ] ■ заказчика 14, 48, 161, 178–180, 183–186,
— поздний 234, 235, 237, 246–250 312
— ранний 234, 235, 237, 246–250 — отчет об определении Т. з. 299, 321
— фактический 232–235 ■ к директорам программ 381
■ плановый 235 ■ к распорядителям ресурсов 383
■ окончания [выполнения работ] ■ к руководителям проектов 382
— поздний 234, 235, 237, 246–250 ■ клиента — см. Требования заказчика
— ранний 234, 235, 237, 246–250 ■ пользователя 499, 506, 507
— фактический 232–235 ■ сбалансированность Т. 384
Старт проекта — см. Проект, старт Треугольник «сроки – стоимость – качество» 35
Стартовый семинар — см. Семинар стартовый
Стоимость У
■ базисная 222, 349 Управление
— выполненных работ, БСВР 349 ■ жизненным циклом — см. Жизненный
— запланированных работ, БСЗР, 222, цикл
349 ■ иерархическое 46–49, 84
■ контрольный куб С. — см. Контрольный ■ изменениями 27–30, 59, 73, 90, 91
куб стоимости ■ качеством — см. Функциональные облас
■ оценка С. 213–221 ти управления проектами
■ плановая ■ конфигурацией — см. Конфигурация, уп
— выполненных работ, ПСВР 223 равление
— запланированных работ, ПСЗР 222, ■ культурными различиями 528–531
225, 349 ■ линейное — см. Управление иерархическое
550 Предметный указатель

матричное 86–88, 110


■ Ф
общим качеством, УОК 37, 196, 377
■ Фазы жизненного цикла проекта
■ организацией — см. Функциональные об ■ выполнение и контроль 328, 329
ласти управления проектами ■ окончание и закрытие 362–364
■ отношениями с пользователями 317 ■ предложение и инициация 302–304
■ предметной областью — см. Функцио ■ проектирование и экспертиза 310–316
нальные области управления проектами Функциональные области управления проектами
■ проектно#ориентированное 83–88, 90, 91, 34–37
475 ■ качество 177
■ программой — см. Программа, управле ■ организация 151–153, см. также Органи
ние зация
■ проектом 37–43 ■ предметная область 119–124
— в масштабах всей компании ■ сроки 316, 317
385 ■ стоимость 200–202
— международным — см. Проект меж
дународный, управление Ц
— по временным параметрам 231, также Цели
см. Управление сроками ■бизнес#ц., Ц. бизнеса 53, 63, 119, 124, 425
— принципы У. п. 540, 541 ■групповые 30, 35
— стратегическое 49–52 ■ иерархия Ц. 30, 32, 33, 35
— уровни У. п. — см. Уровни управле ■ качественные 29, 43
ния проектом ■ количественные 29, 43
— функциональные области У. п. — ■ личные 30, 35, 76, 98, 460, 461
см. Функциональные области управ ■ скрытые 73, 76, 77
ления проектами ■ явные 76, 77
■ процессом экспертизы 317 Ценности культурные 465
■ рисками 260, 261 Ценность 97, 280, 304, 313, 465
■ ситуационное 470 ■ добавленная 487, 492, 493
■ сроками — см. Функциональные облас Цикл
ти управления проектами ■ жизненный — см. Жизненный цикл
■ стили У. — 87, 470, 471, см. также Руково ■ контроля 357, 358
дство, стиль ■ решения проблемы 39–42
■ стоимостью — см. Функциональные об
ласти управления проектами Ч
■ стратегическое 94 Чертежи 174
■ типы У. 47 ■ исполнительные 366, 370
Уровни управления проектом ■ рабочие 39
■ административный — см. Уровни управ
ления проектом, стратегический Э
■ детальный — см. Уровни управления про Эксплуатация 107, 363–367
ектом, тактический ■ ввод [объекта] в Э. 49, 70, 74, 119, 120,
■ интегративный 43, 49, 50 126, 184, 192, 340, 365, 367, 464
■ оперативный — см. Уровни управления Эффект
проектом, тактический ■ сокращения масштаба времени 219
■ стратегический 44, 49, 50 Эффективность 341–343
■ тактический 44, 49, 50
■ укрупненный — см. Уровни управления Я
проектом, интегративный Язык 530

Оценить