Руководство по проектно ориентированному

Укажите регион, чтобы мы точнее рассчитали условия доставки

Начните вводить название города, страны, индекс, а мы подскажем

Например: 
Москва,
Санкт-Петербург,
Новосибирск,
Екатеринбург,
Нижний Новгород,
Краснодар,
Челябинск,
Кемерово,
Тюмень,
Красноярск,
Казань,
Пермь,
Ростов-на-Дону,
Самара,
Омск

Second Edition

J. Rodney Turner

THE HANDBOOK OF PROJECTBASED 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. Управление рисками

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

10.2. ИДЕНТИФИКАЦИЯ РИСКОВ Мы не в силах предсказать, с какими рисками столкнемся при управле нии проектами, однако мы можем познакомиться с двумя способами их классификации, которые, вероятно, помогут нам в выявлении рисков в наших собственных проектах. Риски можно классифицировать в соответ ствии со следующими факторами: ■ воздействие, которое они оказывают на проект; ■ источник регулирования рисков.

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

Я проводил серию семинаров для небольшой консалтинговой фирмы, у которой имелась проблема перерасхода выделенных ассигнований. (За трехлетний период компания сократила перерасход с 10%, что в два раза превышало годовую прибыль, примерно до 2%.) На первом семинаре директор фирмы передал мне перечень ста тей перерасхода. Он сгруппировал их по величине перерасхода в фунтах стерлин гов. Сначала в списке шли работы, оцененные в ?20 тыс., а при завершении стоив шие уже ?50 тыс. В последнюю группу были включены проекты с перерасходом в ?1–2 тыс., а завершал ее проект, оцененный в ?200 тыс., перерасход по которому

261

262

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

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

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

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

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

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

263

264

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

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

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

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

Нейлу Армстронгу в ходе интервью был задан вопрос: какой момент оказался са мым страшным при высадке на поверхность Луны — момент приземления лета тельного аппарата, когда он мог потерпеть аварию, спуск Армстронга с лестницы на лунную поверхность, момент старта с Луны, когда мощность ракет могла ока заться недостаточной? Нет, ответил он, самым страшным был миг на стартовой площадке мыса Канаверал, когда под ним находилось 2 тыс. комплектующих, каждая из которых могла быть закуплена по тендеру с предложением минималь ной цены! И одна из таких деталей действительно вышла из строя в 1986 г.

265

266

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

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

Несколько лет назад я принимал участие в проведении учебного курса, в рамках ко торого рассматривался «Закон об охране здоровья и соблюдении техники безопас ности на производстве». Один из присланных на учебу сотрудников рассказал, что на него возложена ответственность за тестирование и контроль программного обеспечения для реактивного истребителя, используемого в Королевских военно воздушных силах. Он заявил, что при достаточном времени можно протестиро вать 90% путей в этом программном обеспечении, которые охватывают 99,9%

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

всех возможных случаев. Однако для тестирования всех путей потребуется 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. Экспертное заключение дается на основе личной интуиции и осве домленности. В этом может помочь использование контрольных воп росов по определенным выше категориям.

267

268

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

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

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

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

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

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

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

269

270

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

10.3. ОЦЕНКА УЩЕРБА ОТ РИСКОВ Определив возможные источники рисков в проекте, мы должны оценить их воздействие на проект. Сначала следует рассчитать воздействие от дельных рисков, а затем их совместное воздействие.

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

Конечно, последствия землетрясения для атомной электростанции будут не столь суровы, как предполагается, однако их восприятие общественностью именно та ково. В 1980х гг. консалтинговая фирма в отрасли гражданского проектирования Ove Arap and Partners проделала большую работу по проектированию и тестиро ванию железнодорожных вагонов для перевозки низкоактивных ядерных отходов по стране. Было проведено несколько широко разрекламированных эксперимен тов, во время которых локомотив резко сталкивался с вагонами на скорости 100 миль в час. В этом случае вероятность аварии, которая привела бы к утечке ради ации, была мала, и последствия были также незначительными: никаких мгновен ных смертей — возможно, одиндва дополнительных случая заболевания раком, приводящих к ранней смерти через несколько лет. Однако эта проблема сильно взволновала общественность, следствием чего явилось требование создать совер шенно не подверженные разрушению вагоны. С другой стороны, смертоносные химикаты транспортируются всюду в сравнительно непрочных вагонах. В начале 1980х гг. я работал вблизи железной дороги, по которой каждый день проезжал электровоз, тащивший две цистерны с цианистым газом. Авария могла повлечь за

271

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

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

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

273

274

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

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

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

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

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

Аналогичные списки были бы получены, если бы работа началась в декабре или январе с вероятностью, взвешенной для соответствующей большей продолжительности. При некоторых обстоятельствах подготов ка площадки становится критической, и в этом случае может оказаться полезным попытаться выполнить скоростное проектирование фундамен тов. Если работа будет закончена раньше, то возможны дополнительные финансовые издержки. Маловероятно, что стоимость проектной доку ментации возрастет сама по себе, однако появляется риск того, что ее придется переделывать. В этом случае вы можете принять решение по ситуации на сегодняшний день с учетом состояния проектирования стальных конструкций и других факторов. 3. Возможно, у вас есть два потенциальных поставщика стальных конструкций: один из них, предлагающий более высокую цену, мо жет выполнить поставку в течение одного или двух месяцев с равной вероятностью; другой, предлагающий более низкую цену, — в тече ние двух или трех месяцев, также с равной вероятностью. ■ один месяц — 25%; ■ два месяца — 50%; ■ три месяца — 25%. С чемто похожим мы сталкивались при проектировании. Однако си ла подхода «сверху вниз» заключается в следующем: вы можете решить, что делать сегодня, если знаете, сколько времени потрачено на проекти рование и насколько вы продвинулись в закладке фундамента. Для того чтобы понять это, нам необходимо рассмотреть четвертый риск.

275

276

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

4. Стальные конструкции нельзя монтировать при сильном ветре, а это происходит со следующей вероятностью: ■ февраль — 25%; ■ март — 50%. Продолжительность этой работы, как и работы по подготовке площад ки, будет зависеть от срока ее начала. Однако мы видим, что если разработ ка проектной документации будет закончена в конце октября, то будет луч ше воспользоваться услугами поставщика, предлагающего более высокую цену. В этом случае монтаж будет с 50%ной вероятностью начат в декабре и закончен в январе без какоголибо превышения планового срока или же с 50%ной вероятностью начнется в январе, в случае чего он с 75%ной веро ятностью закончится в феврале. Это, конечно, зависит от готовности фун дамента, и поскольку считается, что составление проектной документации на стальные конструкции будет закончено рано, имеет смысл закладывать фундамент в режиме скоростного строительства. С другой стороны, если проектирование займет четыре месяца, было бы лучше привлечь постав щика с низкой ценой и в этом случае просто запланировать начало монта жа стальных конструкций на апрель, сэкономив при этом дополнительные затраты на фундамент и на простой монтажников. Этот простой пример показывает, что подход «сверху вниз» дает воз можность анализировать взаимозависимости между элементами рисков и принимать управленческие решения на основе этого анализа и факти ческих результатов производства. Следуя подходу «сверху вниз», вы по лучаете возможность проработать дополнительные детали в некоторых областях. Например, в приведенном выше примере вы можете разделить проектирование на более низком уровне декомпозиции работы, чтобы определить, как можно ускорить проектирование. В разделе 4.4 говори лось о различии между скоростным выполнением и скоростным строи тельством, и именно о скоростном строительстве мы говорили сейчас как о способе снижения рисков. Требование разделения проекта на более мелкие пакеты работ делает необходимой выработку жестких проектных характеристик на верхнем уровне. Диаграммы влияния Диаграммы влияния являются инструментами, позаимствованными из системной динамики, и могут помочь в выполнении анализа методом «сверху вниз». Они показывают, как риски влияют друг на друга; некото рые риски усиливают другие (+), а некоторые снижают (–). На рис. 10.4 показан пример диаграммы влияния. Сила этого метода заключается в выявлении петель влияния. Ошибочные циклы имеют четное (или нуле вое) число отрицательных влияний, а устойчивые циклы — нечетное. На рис. 10.4 петля ADEKLIBA является ошибочной, а петля ADEGHJBA — ус тойчивой. В ошибочном цикле внешне обусловленное воздействие может неопределенно усиливаться. Подход «снизу вверх» Подход «снизу вверх» предусматривает анализ рисков на нижнем уровне [8]. Он может помочь определить несколько критических путей и рассчитать ряд результатов стоимости и продолжительности проекта, позволяющих

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

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

277

278

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

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

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

■ А–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». Этот проект повлек бы за со бой потерю расположения местной общественности, и поэтому его «стоимостью» является вся выгода, которую компания рассчитывала получить благодаря этому расположению. Очевидно, компания сочла, что ожидаемые доходы не оправдыва ют этой «стоимости».

279

280

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

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

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

10.4. СНИЖЕНИЕ РИСКОВ После выявления и оценки рисков следует рассмотреть способы их сни жения. Существует три основных подхода [9]: 1) избегание риска: выявив риск, руководитель начинает перепланиро вание, чтобы избежать его; 2) перекладывание риска: руководитель пытается переложить риск на когото другого;

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

3) учет непредвиденных расходов в плане: руководитель не предприни мает никаких мер вплоть до возникновения отклонений, за исключе нием подготовки планов непредвиденных расходов в случае их появ ления. Д. Пим и M. Уайдмен [9] используют аналогию с человеком, в которо го стреляют. Он может спрятаться в укрытие для того, чтобы избежать пуль; он может перенаправить или сместить выстрел в другом направле нии, допуская, что они поразят когото другого; или же он может допус тить, что пули ранят его, и планировать устранить повреждение, надеясь, что у него будет на это время.

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

Перекладывание риска Имеется три способа перекладывания риска: 1) страхование: риск перекладывается на третью сторону; 2) гарантийные обязательства: принимаются обязательства по обеспе чению того, чтобы риск не проявился; 3) контракт: риск распределяется между владельцем проекта, подрядчи ком и субподрядчиком. Страхование Третья сторона принимает на себя страховые риски (раздел 10.2) за уплату страховой премии, которая отражает влияние риска, то есть его вероят ность вкупе с последствиями. Гарантийные обязательства Одна или обе стороны по контракту депонируют денежные средства на осо бый гарантийный счет с тем, чтобы в случае, если по вине обеих или одной из сторон риск реализуется, пострадавшая сторона могла получить эти средства в качестве компенсации. Это способ перекладывания риска на сто рону, виновную в невыполнении обязательств перед данной организацией. Контракты Посредством контрактов риски распределяются между владельцем про екта, подрядчиком и субподрядчиками. Существуют два общих принци па заключения контрактов. 1. Риск перекладывается на ту из сторон, которая больше всех спо собна его контролировать и заинтересована в этом. Нет никакого смысла перекладывать риски на подрядчика или субподрядчика, ес ли они не располагают возможностями и стимулами для их контроля. В настоящее время британское Общество инженеров гражданского

281

282

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

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

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

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

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

10.5. КОНТРОЛЬ РИСКОВ Определив способы снижения рисков, вы можете осуществить план конт роля их снижения. На рис. 7.2 были показаны основные шаги такого контроля: 1) составление плана; 2) мониторинг хода работ в сравнении с планом; 3) расчет отклонений; 4) принятие мер по преодолению отклонений План управления рисками План управления рисками определяет риски, связанные с проектом, сред ства для их оценки и стратегию их снижения. Основой документальной

283

284

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

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

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

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

285

286

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

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

287

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

являются стартовые семинары (см. главу 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.3

Количественная оценка

Отдельные риски

Решение о том, что измерять количественно Количественная оценка неопределенности

Оценка, 10.3

Количественная оценка

Комбинированные риски

Комбинирование рисков

Снижение, 10.4

Управление

Планирование реакций

Определение необходимых реакций Планирование реакций

Управление, 10.6

Управление

Мониторинг

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

Определение, 10.2

Качественная оценка

Определение, 10.2

Качественная оценка

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. Управление рисками

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.

289

Предметный указатель АББРЕВИАТУРЫ

АКП — анализ критического пути БСВР — базисная стоимость выполненных ра# бот

БСЗР — базисная стоимость запланированных работ ВМТР — ведомость материальных и трудовых ресурсов МКП — метод критического пути МСП — малые и средние проекты ОСП — офис сопровождения проекта ПОО — позиции основного оборудования ПСВР — плановая стоимость выполненных работ ПСЗР — плановая стоимость запланированных работ ПСО — «Персонал – системы управления – ор# ганизационные схемы» ПТС — перечень требований к системе СДП — структурная декомпозиция продукта СДР — структурная декомпозиция работ СДС — структурная декомпозиция стоимости СИУП — система информации для управления проектом ЧТС — чистая текущая стоимость УОК — управление общим качеством

ТЕРМИНЫ

В

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 («Методология структур# ного анализа и проектирования систем»)

А Анализ ■ PESTLE 106 ■ PRAM — см. Методика анализа и управ ления рисками проекта ■ «если, то…» 246, 253, 257, 412 ■ методом Монте#Карло 278–279 ■ проекта — после завершения 370 ■ риска 270–279 Аудит 431–433, 444, 449–453 ■ внутренний 433 ■ по завершении проекта 371, 433

Б Базис — см. Базисный расчет Базисная стоимость 200, 210, 222, 349–351 Базисный расчет 235, 353 Базисный срок 235, 250, 333, 337, 338 Бюджет 210, 322, 353 ■ годовой Б. 62, 63

Ведомость ■ исключений 393 ■ комплектации работ — см. Ведомость комплектовочная, работ ■ комплектовочная 174 — материалов 191, 340 — работ 236, 337–341, 391 ■ материальных и трудовых ресурсов, ВМТР 218 ■ расценок 218 ■ расчетная 172, 241, 334–336 Видение 100–102, 107, 152 Владелец 33, 73–77, 110, 279–282 Внештатные работники 86, 88 Время ожидания 240, 241 Выполнение ■ В. и контроль — см. Фазы жизненного цикла проекта ■ скоростное 106

Г Гарантийные обязательства 281

544

Гарантия качества — см. Качество, гарантия Гистограмма потребления ресурсов — см. Ре сурсы, гистограмма потребления

Д Дата — см. Срок Делегирование ■ полномочий 400, 404 ■ принятия решений 87 ■ работ 122 Диагностика ■ проектной направленности 434–444 ■ успеха / провала 444–449 Диаграмма ■ влияния 276, 277 ■ Гантта 236 ■ линейная 37, 236 — вложенная 332, 337 Договор — см. Контракт Документ ■ возвратный 341, 342, 344–348 Документация — см. Проектная документа ция

Ж Жизненный цикл ■ продукта 475–478 ■ проекта 37–43, 143, 194–196, 293, 296–298, 311, 451, 463, 482, 508 — фазы Ж. ц. п. — см. Фазы жизненного цикла проекта ■ разработки — программного обеспечения 498, 502, 503 — продукта 481, 482 Жизнеспособность проекта 37, 41, 105, 201 ■ оценка Ж. п. 201

З Зависимости ■ «начало / начало» 243, 244, 248 ■ «начало / окончание» 243, 244, 248 ■ «окончание / начало» 243, 244 ■ «окончание / окончание» 132, 243, 244, 248 Заинтересованные стороны 76, 77, 80 Заказчик 33 ■ коллективный 189, 304, 400 ■ требования — см. Требования заказчика — определение т. з. — см. Требования заказчика, определение

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

Заказы и закупки — см. Материальнотехни ческое обеспечение Законодательство 521 Закрытие [проекта] — см. Фазы жизненного цикла проекта Затраты 207–227, 232, 351, 352, 356, 392, 419, 423 ■ контроль З. — см. Контроль затрат ■ на обеспечение качества 195, 196 ■ трудозатраты 207, 219, 220, 225, 348–351

И Иерархия ■ потребностей, А. Маслоу 462, 463 ■ проекта — см. Уровни управления проек том ■ проектная 158 ■ функциональная 84, 85, 157 ■ целей 32, 35 Изменение ■ в родительской организации — техническое 77–79, 494, 496 — корпоративной культуры — см. Изме нение в родительской организации, культурное — культурное 77–80 ■ контроль И. — см. Контроль изменений ■ организационное 508–510 ■ планирование И. — см. Планирование изменений ■ сопротивление И. 81–83 ■ управление И. — см. Управление измене ниями Инвестор 75, 109 Инжиниринг — конкурентный 493–498 Инициация проекта — см. Проект, инициация Инновация 478, 479 Исполнительные чертежи — см. Чертежи ис полнительные Исследование ■ диагностическое 425, 426 ■ осуществимости проекта 305–311

К Календарный план работ — см. План кален дарный, работ Качество 177–181 ■ гарантия К. 315, 400 ■ контроль К. — см. Контроль качества

545

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

обеспечение К. 181–184 — затраты на О. к. 195–197 — продукта 182 — проекта 181 ■ план К. 187 ■ процессов управления 186–187 ■ управление общим К., УОК — см. Управ ление общим качество Команда ■ мотивация К. 460–464 ■ проекта 455 ■ расформирование 368–370 ■ руководитель К. — см. Руководитель ко манды ■ уровни К. 457, 458 ■ формирование К. 456, 458–460 Коммуникация 491, 492, 530, 531 Контракт 113, 152, 153, 169, 281, 282, 395, 451, 468, 506, 531, 541 Контролер ■ затрат 395 ■ качества 395 ■ проекта 394 Контроль ■ затрат 221–227, 395 ■ изменений 184, 193, 194, 354, 355, 357 ■ качества 184–187 ■ над предметной областью 354 ■ организации 353 ■ период К. — см. Период контроля ■ работ 340–344 ■ разработки продукта 483–485 ■ рисков 283–287 ■ сроков 256, 257 ■ цикл К. — см. Цикл контроля Контрольное событие 44 ■ вспомогательное 143, 148 ■ выбор К. с. 133 ■ план К. с. 44, 80, 130–137, 142–148, 166, 244, 273, 308 ■ планирование К. с. — см. Контрольное событие, план Контрольный куб стоимости — 36, 210–212 Контрольный период — см. Период контроля Конфигурация ■ управление К. 188–195 ■ успешная 541, 542 Координатор 75, 76, 301 Коэффициент дисконтирования 70 ■

Кривая ■ S#образная 227, 257, 353 ■ обучения 204–206 Критический путь 249 ■ анализ К. П., АКП 241, 421 ■ метод К. П., МКП 241, 421 Куратор 75, 76

Л Лидерство 464, 465 ■ основанное на действии 455, 456

М Материально#техническое обеспечение 520, 531 Матрица ■ BCG 63, 64 ■ Ансоффа 63, 64 ■ влияния 379 ■ на базе временного прикомандирования 158 ■ сбалансированная 157 ■ скоординированная 157 ■ целей и методов 52–54 Методика ■ контроля качества 197 ■ оценки и анализа программ, PERT — см. Модель сетевая, PERT ■ управления рисками — анализа и управления рисками проек# та, PRAM 260, 287, 288 — синергетического комбинаторного анализа и оценки, SCERT 287 Методология ■ C/SCSC 37, 423 Миссия 60, 61 Модель ■ COCOMO 218, 220 ■ Code#and#Fix 498 ■ «владелец / подрядчик» 73, 74 ■ проекта 131, 304, 345 ■ разработки программного обеспечения — каскадная 499–502 — поэтапная 499 — спиральная 503–506 ■ семи движущих сил проектно#ориенти# рованного управления 95 ■ сетевая 250–253 — PERT 101, 263, 421, 422 — вложенная 337

546

— гибридная 244 — предшествования 243–245, 247, 251–253 — с работами#стрелками 244, 245, 247–250 ■ стратегического управления 105–106 Мониторинг ■ М. и контроль 165, 359, 484 ■ процессов управления 187 ■ результатов 186 ■ рисков 285 Мотивация 460, 462, 463

Н Неопределенность 31, 102, 261, 521

О Области работ — см. Работа, область Обучение 91 ■ кривая О. — см. Кривая обучения ■ производственное 82, 365, 400, 428 Объект 32, 33 Окончание и закрытие — см. Фазы жизненно го цикла проекта Окружение проекта — см. Проект, окружение Окупаемость ■ коэффициент внутренней О. 70 ■ период О. 70 Оперативная группа 481 Определение проекта — см. Проект, определе ние Организация ■ линейная 155, 156 ■ матричная 155, 156 ■ многоцелевая 159–161 ■ проекта — типы О. п. 156–158 ■ разработки продукта 479–481 ■ родительская 73, 77–79 Освоенный объем 223, 225, 351 ■ анализ О. о. 345, 349 ■ метод О. о. 222 Осуществимость — см. Исследование осуще ствимости проекта Отчет ■ о ходе работ 392 ■ об определении проекта 320–324 ■ стартовый аналитический 290, 291 Отчетность 113, 450, 541 ■ одностраничная 113, 138, 337

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

■ эффективность О. 341, 342 Офис сопровождения проекта, ОСП 390–395 Оценка ■ жизнеспособности проекта — см. Жиз неспособность проекта, оценка ■ методы О. — в инженерно#строительной отрасли 213–216 — в строительстве 216–218 — в сфере информационных технологий 218–229 — сравнение М. о. 221 ■ нереалистичная 101 ■ продолжительности работ — 201, 202, см. также Работа, продолжительность ■ стоимости, стоимостная 200–212 — методы О. с. — см. Оценка, методы — структура О. с. 207–213 — типы О. с. 202–204 ■ управленческая 71 ■ уровни О. 122, 123 ■ успеха проекта 95–99 ■ хода выполнения проекта 344–349

П Пакет работ — см. Работа, пакет Параллельное выполнение 105, 316 Параллельное проектирование 105 «Перевалочный пункт» 54, 301, 489 Перепланирование 343 Период ■ контроля 338, 340, 357, 358 ■ ожидания 174, 351 ■ окупаемости 70 ■ отчетный П. 227, 341, 342, 349 План ■ бизнес#п. — 99, см. также Планирование, бизнесП. ■ календарный 232–236, 241–243 — исследований 309 — работ 44, 137, 166, 331, 334 — сводный 380 — текущий 235 ■ стратегический 65 ■ эффективность П. 341 Планирование ■ бизнес#П. 60–63, 425 ■ выполнения проекта 331–337 ■ детальное 32, 33, 56, 100, 101, 121–123, 141, 232

547

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

изменений 80 исследований 308, 309 ■ календарное 250–253 — работ — см. План календарный, ра бот — ресурсов 253, 400, см. также Ресурсы, гистограмма потребления — старта проекта 302, 303 ■ контрольных событий 130–136, 143–149 — вспомогательных К. с. 143 ■ корпоративное 63 ■ методом «бегущей волны» 100, 241, 332, 498, 505 ■ недостатки в П. 99–101 ■ передачи продукта пользователям 365 ■ проекта 489, 490, 541 ■ работ 80, 346, 387, 388 ■ разработки продукта 481–483 ■ результата 367 ■ сетевое 246–250, 421, 423 ■ системы П. и контроля 109, 110, 419, 420 ■ точность П.123 ■ уровни П. 43, 44, 66, 388, см. также Уров ни управления проектом — интегративный 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 Предложение и инициация — см. Фазы жиз ненного цикла проекта Предметная область проекта — см. Проект, предметная область Приемочные испытания 324 Приоритет 67–69, 90–92, 99, 377–381 Проверка состояния 431–434, см. также Аудит внутренний Программа 63, 65, 90, 91, 379–388, 391, 421 ■ директор П. 381–384 ■ управление П. 375, 376, 379–381, 385, 388, 421 Продукт ■ новый — разработка 478–485 ■ передача пользователям 365, 366 Продуктивность 534, 535 Проект 28–34 ■ аудит П. — см. Аудит

в развивающихся странах 531–535 жизнеспособность П. — см. Жизнеспо собность проекта ■ заказчик П. — см. Заказчик ■ инициация П. 295 ■ информационных систем 498–507 ■ исследований и разработок 485–493 ■ классификация П. 386–388 ■ команда П. — см. Команда проекта ■ координатор П. — см. Координатор ■ куратор П. — см. Куратор ■ международный 513–517 — проблемы 517–519 — типы 514–517 — управление П. м. 535–538 ■ мелкий 377, 378 ■ модель П. — см. Модель проекта ■ назначение 125 ■ П. НИОКР — см. Проект исследований и разработок ■ обеспечение ресурсами 329, 330 ■ «оздоровление» 354–357 ■ окружение П. 49, 460–462 ■ определение П. 124, 293, 294 — отчет об О. п. — см. Отчет об опре делении проекта — семинар по О. п. — см. Семинар по определению проекта ■ организация П. — см. Организация про екта ■ планирование П. – см. Планирование проекта ■ портфель П. 375–379 ■ предметная область П. 125, 126, см. также Функциональные области управления проектом ■ ПСО 78, 79, 88, 90 ■ руководитель П. — см. Руководитель проекта ■ совет П. 189, 410, 411 ■ содержание П. — см. Проект, предмет ная область ■ сопровождение П. — отдел С. п. — см. Отдел сопровожде ния проекта ■ старт П. 294–302 ■ стратегия П. — см. Стратегия проекта ■ технологический — см. П. исследований и разработок ■ типы П. 53, 54

■

■

■

■

548

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

управление П. — см. Управление проек том ■ уровни П. — см. Уровни управления про ектом ■ фазы П. — см. Фазы жизненного цикла проекта ■ экспертиза П. 317 Проектирование и экспертиза — см. Фазы жизненного цикла проекта Проектная документация — см. также Проек тирование и экспертиза ■ исполнительная П. д. 192 ■ проектно#сметная 107, 108, 194, 328, 432 ■ рабочая П. д. 44, 328, 392, 393 ■ стандартная 127 Проектная направленность ■ диагностика П. н. — см. Диагностика проектной направленности Проход ■ обратный 248 ■ прямой 248 Процедура ■ адаптация П. к требованиям проекта 406, 407 ■ руководство по П. — см. Руководство по процедурам ■ управления проектами 425, 426 — ISO 10006 409, 412–414 — PMBoK 412, 415–417 — PRINCE 2 407–411 Процент готовности 223, 225, 256, 350, 351 Процессный подход 46–48 Путь ■ критический 234, 235, 249, 257 ■ подкритический 257 ■ результирующий 132–134 ■

Р Работа ■ ведомость комплектации Р. — см. Ведо мость комплектации работ ■ завершение Р. 363 ■ контроль Р. — см. Контроль работ ■ критическая 234, 257 ■ область Р. 132 ■ объем Р. 169–171 ■ пакет Р. 31, 122, 124, 142, 143, 240, 241 ■ содержание П. р. 142 — выписка из содержания П. р. 185, 241 ■ план Р. – см. План календарный, работ

подкритическая 235, 257 продолжительность Р. 236–241 ■ распределение Р. 337 ■ стоимость Р. — см. Стоимость работ ■ структурная декомпозиция Р. — см. Структурная декомпозиция работ ■ утверждение Р. 333, 334 Разработка ■ программного обеспечения — см. Про ект информационных систем ■ продукта — см. Продукт новый, разра ботка Разрешение ■ на проект 317, 495 ■ на осуществление меры 343 Расчет — см. Оценка Расчетная себестоимость — см. Базисный расчет Резерв времени 233–236 Результативность 443, 460 Реинжиниринг бизнес#процессов 508, 509 Ресурсы ■ гистограмма потребления Р. 173, 253–256 ■ календарь Р. 173, 174 ■ обеспечение проекта Р. — см. Проект, обеспечение ресурсами ■ потребность в Р. — выравнивание П. в р. 253–256 ■ распорядитель Р. 102, 330, 376, 381–384 ■ распределение Р. 201 ■ расходование Р. 169, 222, 391 ■ централизованный пул Р. 329, 376, 377 Риск ■ анализ Р. — см. Анализ риска ■ бизнес#р. 261 ■ внешний 264, 265 ■ внутренний 264, 265 ■ восприятие Р. 279, 280 ■ идентификация Р. 261, 267–269 ■ контроль Р. — см. Контроль рисков ■ объединение Р. 272 ■ регулирование Р. 263 ■ снижение Р. 280–283 ■ страхуемый 262 ■ технический 107, 108, 264, 268 ■ юридический 266, 267 Руководитель ■ команды 123 ■ линейный 368 ■ проекта 455, 465–469 — культурный профиль Р. п. 525–528 ■ ■

549

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

производства 88–90, 157–159, 365 функциональный 84, 86–88, 157 Руководство ■ по процедурам 399, 402–406 ■ по реализации проекта 323, 324 ■ разработка Р. 401 ■ стиль Р. 468, 469 ■ ■

С Семинар ■ стартовый 318–320 ■ по определению проекта 299, 318, 319 Система ■ информации для управления проектом, СИУП 412, 417–421, 424–428 — выбор и внедрение 426, 427 — проектирование СИУП 419 ■ перечень требований к С., ПТС 425 ■ сетевого планирования 138, 421, 423 ■ управления затратами и ресурсами 423 Сопровождение проекта — см. Отдел сопро вождения проекта Спецификации — см. Технические условия Срок ■ базисный 235 ■ календарный 235 ■ начала [выполнения работ] — поздний 234, 235, 237, 246–250 — ранний 234, 235, 237, 246–250 — фактический 232–235 ■ плановый 235 ■ окончания [выполнения работ] — поздний 234, 235, 237, 246–250 — ранний 234, 235, 237, 246–250 — фактический 232–235 Старт проекта — см. Проект, старт Стартовый семинар — см. Семинар стартовый Стоимость ■ базисная 222, 349 — выполненных работ, БСВР 349 — запланированных работ, БСЗР, 222, 349 ■ контрольный куб С. — см. Контрольный куб стоимости ■ оценка С. 213–221 ■ плановая — выполненных работ, ПСВР 223 — запланированных работ, ПСЗР 222, 225, 349

прогноз С. по завершении проекта 351 проекта 200–209, 225, 279–283, 349–353 ■ работ — базисная — см. Стоимость базисная — плановая — см. Стоимость плановая — фактическая 350 ■ сметная выполненных работ 223, 225, 350, 351 ■ чистая текущая, ЧТС 70 Стратегия проекта 49, 131, 134, 136, 182, 305, 306, 311 Строительство ■ скоростное 106, 276 Структурная декомпозиция 111–113, 120, 210 ■ организации, СДО 35, 152, 211 ■ продукта, СДП 35, 112, 120, 191, 211 ■ работ, СДР 36, 71, 100, 120–124, 127, 136, 213–215, 272, 322, 541 ■ стоимости, СДС 36, 210–213 ■ уровни С. д. — см. Планирование, уровни Субподряд 208 Схема распределения ответственности 162–168 ■ ■

Т Тендер 202, 205, 496 Технические условия 178, 179, 183 Требования 14, 48, 161 ■ заказчика 14, 48, 161, 178–180, 183–186, 312 — отчет об определении Т. з. 299, 321 ■ к директорам программ 381 ■ к распорядителям ресурсов 383 ■ к руководителям проектов 382 ■ клиента — см. Требования заказчика ■ пользователя 499, 506, 507 ■ сбалансированность Т. 384 Треугольник «сроки – стоимость – качество» 35

У Управление ■ жизненным циклом — см. Жизненный цикл ■ иерархическое 46–49, 84 ■ изменениями 27–30, 59, 73, 90, 91 ■ качеством — см. Функциональные облас ти управления проектами ■ конфигурацией — см. Конфигурация, уп равление ■ культурными различиями 528–531 ■ линейное — см. Управление иерархическое

550

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

матричное 86–88, 110 общим качеством, УОК 37, 196, 377 ■ организацией — см. Функциональные об ласти управления проектами ■ отношениями с пользователями 317 ■ предметной областью — см. Функцио нальные области управления проектами ■ проектно#ориентированное 83–88, 90, 91, 475 ■ программой — см. Программа, управле ние ■ проектом 37–43 — в масштабах всей компании 385 — международным — см. Проект меж дународный, управление — по временным параметрам 231, также см. Управление сроками — принципы У. п. 540, 541 — стратегическое 49–52 — уровни У. п. — см. Уровни управле ния проектом — функциональные области У. п. — см. Функциональные области управ ления проектами ■ процессом экспертизы 317 ■ рисками 260, 261 ■ ситуационное 470 ■ сроками — см. Функциональные облас ти управления проектами ■ стили У. — 87, 470, 471, см. также Руково дство, стиль ■ стоимостью — см. Функциональные об ласти управления проектами ■ стратегическое 94 ■ типы У. 47 Уровни управления проектом ■ административный — см. Уровни управ ления проектом, стратегический ■ детальный — см. Уровни управления про ектом, тактический ■ интегративный 43, 49, 50 ■ оперативный — см. Уровни управления проектом, тактический ■ стратегический 44, 49, 50 ■ тактический 44, 49, 50 ■ укрупненный — см. Уровни управления проектом, интегративный ■ ■

Ф Фазы жизненного цикла проекта ■ выполнение и контроль 328, 329 ■ окончание и закрытие 362–364 ■ предложение и инициация 302–304 ■ проектирование и экспертиза 310–316 Функциональные области управления проектами 34–37 ■ качество 177 ■ организация 151–153, см. также Органи зация ■ предметная область 119–124 ■ сроки 316, 317 ■ стоимость 200–202

Ц Цели бизнес#ц., Ц. бизнеса 53, 63, 119, 124, 425 групповые 30, 35 ■ иерархия Ц. 30, 32, 33, 35 ■ качественные 29, 43 ■ количественные 29, 43 ■ личные 30, 35, 76, 98, 460, 461 ■ скрытые 73, 76, 77 ■ явные 76, 77 Ценности культурные 465 Ценность 97, 280, 304, 313, 465 ■ добавленная 487, 492, 493 Цикл ■ жизненный — см. Жизненный цикл ■ контроля 357, 358 ■ решения проблемы 39–42 ■ ■

Ч Чертежи 174 ■ исполнительные 366, 370 ■ рабочие 39

Э Эксплуатация 107, 363–367 ■ ввод [объекта] в Э. 49, 70, 74, 119, 120, 126, 184, 192, 340, 365, 367, 464 Эффект ■ сокращения масштаба времени 219 Эффективность 341–343

Я Язык 530

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Тернер, Джон Родни — Руководство по проектно-ориентированному управлению: усовершенствование процессов управления для достижения стратегических целей предприятия

Проектно-ориентированная модель управления

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

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

• стратегическая ступень – включает планирование периодом от 6 лет, с контролем не менее 1 раза в год;
• тактическая ступень – включает планирование на время от 1 до 6 лет, с контролем не менее 1 раза в квартал;
• оперативная ступень – включает планирование периода от 3 месяцев до 1 года, с контролем не реже 1 раза в месяц;
• операционная ступень – включает планирование периода 1день – 3 месяца, с контролем не менее 1 раза в неделю.

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

«Проектно-ориентированная модель управления в организации» 👇

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

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

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

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

• стратегическое управление;
• тактическое управление;
• управление проектами.

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

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

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

Типы проектов в управленческой модели

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

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

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

С целью наиболее эффективного управления и обеспечения выполнения целей органов исполнительной власти, проекты могут объединяться в портфели проектов. В таком случае, чтобы внедрить процесс портфельного управления, рекомендуют пользоваться Национальным стандартом Российской Федерации ГОСТ Р 54870-2011 под названием «Проектный менеджмент. Требования к управлению портфелем проектов».

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

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