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

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

Учебное пособие

1
ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ............................................................................................................................5

ГЛАВА 1. ИСТОРИЯ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ.....................................................6


Некоторые исторические вехи проектной деятельности человечества.................................................................6

Управление проектами в России....................................................................................................................................6

Этапы формирования современного представления дисциплины «Управление проектами» на Западе.......8

Становление практикующего менеджмента................................................................................................................9

ГЛАВА 2. ОПЫТ И ЗНАНИЯ.............................................................................................10


ОБЪЕКТЫ УПРАВЛЕНИЯ...........................................................................................................................................10
Проект............................................................................................................................................................................10
Классификация проектов.............................................................................................................................................11
Программа.....................................................................................................................................................................13
Портфель проектов.......................................................................................................................................................14
Цели и стратегия проекта.............................................................................................................................................15
Критерии успехов и неудач проекта...........................................................................................................................15
Жизненный цикл проекта.............................................................................................................................................16
Окружение проекта.......................................................................................................................................................20
Структуры проекта.......................................................................................................................................................21

СУБЪЕКТЫ И ИНСТРУМЕНТАРИЙ УПРАВЛЕНИЯ..........................................................................................23


Участники проекта........................................................................................................................................................23
Родительская организация...........................................................................................................................................24
Команда проекта...........................................................................................................................................................25
Управляющий проектом...............................................................................................................................................28
Организационные структуры родительских предприятий.......................................................................................29
Организационная структура проекта..........................................................................................................................38
Руководство и лидерство.............................................................................................................................................41
Решение проблем..........................................................................................................................................................42
Конфликты в команде проекта....................................................................................................................................42
Переговоры, деловые встречи.....................................................................................................................................43
Информационные технологии в проекте....................................................................................................................44
Стандарты и нормы......................................................................................................................................................46
Правовое обеспечение проекта....................................................................................................................................48

ГЛАВА 3. ПРОЦЕССЫ УПРАВЛЕНИЯ.............................................................................49


Управление проектом.....................................................................................................................................................49

Проектно-ориентированное управление.....................................................................................................................50

Системная модель управления проектом...................................................................................................................51

2
Применение проектного управления...........................................................................................................................52

Процессы управления проектом..................................................................................................................................53


Процессы инициации....................................................................................................................................................57
Процессы планирования..............................................................................................................................................58
Процессы организации выполнения работ.................................................................................................................60
Процессы контроля.......................................................................................................................................................61
Анализ и регулирование выполнения проекта..........................................................................................................62
Процессы завершения..................................................................................................................................................64

Управление системами...................................................................................................................................................65

Применение управления проектами............................................................................................................................66

Управление документооборотом и интеграцией.......................................................................................................67

Управление содержанием проекта...............................................................................................................................72

Управление границами и изменениями......................................................................................................................83

Управление проектом по временным параметрам...................................................................................................88

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

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

Управление рисками проекта.....................................................................................................................................112

Управление человеческими ресурсами в проекте..................................................................................................130

Управление взаимодействием в проекте..................................................................................................................138

Управление поставками и контрактами в проектах..............................................................................................145

Управление информацией...........................................................................................................................................152

Управление безопасностью..........................................................................................................................................158

Управление конфликтами в проекте.........................................................................................................................165

Управление контролем исполнения..........................................................................................................................168

ГЛАВА 4. СИСТЕМА СЕРТИФИКАЦИИ IPMA...............................................................173

ГЛАВА 5. ТЕНДЕНЦИИ РАЗВИТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ...........................183


Управление проектами в переходной экономике...................................................................................................183

Будущее управления проектами.................................................................................................................................185

ГЛОССАРИЙ.....................................................................................................................197

Литература.......................................................................................................................219

3
Введение

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

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

Последние методические разработки в области УП имеют в основном зоологический


характер исследований (попытка получения информации по тем или иным параметрам
вводимых категорий подвыборок проектов), а обретение знаний эвристическим методом
(получение принципиально новых знаний) – явление для современного УП скорее
экзотическое. В этой связи особенно важным является максимальное привлечение
накопленного опыта как на масштабах географических (изучение и привлечение опыта
разных стран), так и аккумулирование исторического опыта на разных хронологических
масштабах.
5
ГЛАВА 1. История проектной деятельности

ГЛАВА 1. История проектной деятельности

Некоторые исторические вехи проектной деятельности человечества

30-25 тысяч лет до Р.Х. — переход от стихийной деятельности человека к осознанному


планированию, направленному на повышение выживаемости групп и общин, на рост качества
жизни.
15 тысяч лет до Р.Х. – экспансия азиатско-монголоидных рас в Америку.
8 тысяч лет до Р.Х. — проекты американских индейцев строительства пуэбло – небоскребов.
Чичен Ица и др. – строительство мегаполисов Центральной и Южной Америки.
7 тысяч лет до Р.Х. — поселение Тель-Хассуна, Тель-Сотто (террит. совр. Ирака).
Музыкальные ударные инструменты, медицинские инструменты трепанации черепа,
ирригационные проекты (Чатал-Хююк, террит. совр. Турции) и др.
5 тысяч лет до Р.Х. – проекты земледельческого освоения дельты Нила.
4 тысячи лет до Р.Х. – проект производства хлопковых тканей (террит. совр. Перу). Проекты
ярусных террас, висячие сады (Телль-Халафский период, Месопотамия).
3 тысячи лет до Р.Х. – Пирамиды. Пирамида Хеопса. Количество членов команды проекта
достигает 100 тысяч человек и более.
2 тысячи лет до Р.Х. — Стоун Хендж, Великобритания.
3-й век лет до Р.Х. – проекты римской экспансии.
1-й век – проекты христианской экспансии.
17-й век - проект строительства Петербурга – одно из лучших произведений проектного
процесса.
1957 г. – проект начала освоения космоса.
Проект «Глобальное состояние планеты Земля» (стартовал в 2003г.)
3000 г. (гипотетически) – сфера Дайсона. Площадь сферы Дайсона, обращенная к Солнцу в
10^9 раз больше, чем площадь Земли. В сфере могут жить 8 х 10^ 12 человек.

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

Опыт проектной деятельности в России обширен. Частично он отражен в исторически


зафиксированных источниках. Наиболее достоверные сведения, касающиеся проектной
деятельности, даны в фундаментальном труде начала ХVIII-го века Дмитрия Ростовского
«Четьи-Минеи» [Дм.Ростовский], затем в конце ХVIII – начале ХIХ веков в трудах Николая
Михайловича Карамзина [Н.М.Карамзин], в середине ХIХ века в трудах Сергея Михайловича
Соловьева [С.М.Соловьев] и Василия Осиповича Ключевского [В.О.Ключевский]. Развитие
методов управления проектами в это время в нашей стране шло своим направлением с
поглощением мирового опыта развития УП.
В годы Советской власти проектная деятельность приобретает бурный характер,
свойственный для государственно-плановой экономики.
Начало Управления проектами в СССР связанно с периодом Новой экономической политики
и индустриализацией 30-х годов. Рост однотипного, серийного производства прежде всего в
сфере жилищного строительства дал толчок для развития теории и практики поточной
организации работ по реализации строительных проектов. Опираясь на опыт массового
жилищного и растущего промышленного строительства, в стране развивается теория
строительного потока, которая явилась фундаментом современной научной организации и

6
ГЛАВА 1. История проектной деятельности

управления труда. Планирование и контроль выполнения проектов в этот период базируется


на детерминированных линейных моделях Гантта и циклограммах с использованием
графоаналитических методов их расчета и оптимизации.
В 60-х годах развитие современных методов управления проектами началось в СССР с
применением сетевых методов (метод критического пути, метод PERT), развития методов
сетевого моделирования и календарного планирования, разработкой программных средств
для расчета сетевых графиков, развития стохастических и альтернативных моделей,
учитывающих вероятностную природу различных элементов проекта.
К началу 70-х методы управления проектами, основанные на сетевых методах, получили в
стране свое развитие и широкое внедрение в различных отраслях народного хозяйства.
В 70-е годы получил развитие системный подход и программные средства для управления
проектами:
 Развитие и внедрение автоматизированных систем сетевого планирования и
управления.
 Первые программные комплексы для управления проектами, содержащие:
 временной и стоимостной анализ и оптимизацию сроков и стоимости работ
проектов
 эвристические алгоритмы распределения ресурсов, выполняющие логический
анализ сложных ситуаций и обладающие способностью самообучения с
удобным пользовательским интерфейсом.
 Первые комплексы программ для многопроектного управления программой
деятельности организации с учетом ее целей и ресурсных возможностей.
 Создание автоматизированных систем управления организациями и предприятиями
(АСУП) в различных отраслях народного хозяйства.
В 80-е годы разработаны интегрированные системы управления:
 Создание интегрированных автоматизированных систем управления (ИАСУ)
становится основой технической политики в области автоматизации производства и
управления и др.
 Основой интегрированных систем управления явились:
 вертикальная интеграция всех уровней управления системы от АСУ
технологических процессов до государственной системы управления
 горизонтальная интеграция функций управления жизненным циклом создания
продукта и всех связанных с ним видов деятельности
 интеграция обеспечивающей части ИАСУ, включающая информационную,
техническую и организационную интеграцию системы.
 ИАСУ создавались с начала 80-х г.г. во многих крупных промышленных и
строительных организациях, объединениях, главках и министерствах. Накопленные
достижения и опыт в создании ИАСУ в значительной мере могут быть использованы
при разработке систем управления проектами.
В 90-е годы получило развитие и внедрение профессионального управления проектами:
 Создание Советской Ассоциации управления проектами СОВНЕТ.
 Изучение возможности использования УП как методов и средств общего управления.
 Развитие современных методов и средств УП, отвечающих условиям России.
 Создание рынка профессиональных услуг и программных продуктов по управлению
проектами.
 Разработка и ввод в действие национальной программы подготовки и сертификации
менеджеров проекта на основе международных требований и стандартов.
 Начало подготовки специалистов по управлению проектами в вузах.

7
ГЛАВА 1. История проектной деятельности

 Начало применения УП в нетрадиционных сферах: социальные и экономические


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

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


«Управление проектами» на Западе

1930-е – разработка специальных методов координации инжиниринга крупных проектов в


США: авиационные в US Air Corporation и нефтегазовые в фирме Exxon.
1939 – разработка американского ученого Гулика по матричной организации управления
сложными проектами.
1953-1954 – применение разработки Гулика в полном объеме в Офисе совместных проектов
воздушных сил США и в Офисе специальных проектов по вооружению, далее в 1955-м – в
Офисе специальных проектов морского флота США (определение требуемых результатов;
тщательное предварительное планирование во избежание будущих изменений плана;
назначение главного контрактора, ответственного за разработку и выполнение проекта.
1956 – компания «Дюпон де Немур» (Du Pont de Nemours Co.) образовала группу для
разработки методов и средств управления проектами.
1957 – к работам группы «Дюпон» присоединились исследовательский центр UNIVAC и
фирма Remington Rand. К концу 57-го ими был разработан метод критического пути (СРМ) с
программной реализацией на ЭВМ UNIVAC. СРМ был с успехом опробован на разработке
плана строительства завода химического волокна в г. Луисвилле, штат Кентукки.
1957-1958 – разработана и опробована система сетевого планирования PERT для программы
«Поларис» (US Navy), которая включала в себя 250 фирм-контракторов и более 9000 фирм-
субконтракторов.
С 1958 г. методы и техника сетевого планирования используются для планирования работ,
оценки риска, контроля стоимости и управления ресурсами в ряде крупных гражданских и
военных проектов в США.
1959 – комитет Андерсона (NASA) сформулировал системный подход к управлению проектом
по стадиям его жизненного цикла – особое внимание уделено предпроектному анализу.
1960-е – расширение сферы применения сетевых методов, разрабатываются методы и
средства оптимизации стоимости для CPM и PERT(PERT/COST), распределения и
планирования ресурсов (RPSM, RAMPS и др.). IBM разрабатывает пакет программ на базе
PERT/COST как систему для управления проектами – PMS, разрабатываются первые системы
контроля на основе сетевой техники – PSC. Развивается организационная интеграция
(матричные формы).
1966 – разработана целостная система материально-технического обеспечения и система
GERT, использующая новую генерацию сетевых моделей.
1970-е – техника сетевого анализа и компьютерные приложения вводятся в качестве
обязательных инженерных предметов в учебных заведениях США. Ряд судов рассматривает
претензии участников проектов только при представлении соответствующих расчетов на
ЭВМ (метод СРМ).
В связи с ростом оппозиции защитников окружающей среды (АЭС, транспортные сети,
нефтегазовые проекты и др.) начинается разработка «внешнего окружения» проекта.
В 70-е годы активно развиваются такие области, как руководитель и команда проекта, методы
управления конфликтами, организационные структуры управления проектами.
1969 – создание Института управления проекта в США (PMI) как бесприбыльной
международной профессиональной организации. Девиз PMI – «…развитие профессионализма
в управлении проектами».

8
ГЛАВА 1. История проектной деятельности

К 1970 году созданы национальные и международные организации в Европе (Международная


Ассоциация управления проектами INTERNET, с 1995 г. - IPMA), в Австралии
(Австралийский институт управления проектами AIPM), в Азии (Японская ассоциация
развития инжиниринга ENAA).
1980-е – воедино сводятся проблемы управления и обеспечения проектов (финансы и другие
ресурсы, Петер Левене), внедряются методы управления конфигурацией (изменениями),
развивается управление качеством, возрастает значение партнерства и эффективной работы
проектной команды. В отдельную дисциплину в УП выделяется управление рисками.
Развитие компьютерной техники и ИТ позволили шире использовать методы УП в
разнообразных сферах.
1987 – опубликован Свод знаний по УП Института управления проектами США (PMBOK).

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


Основоположники практических западных методов УП:

• Фредерик Тейлор, начало ХХ века – разработал принципы рационального управления


исполнителями проекта, реализовал «конвейерный», «механический» подход в УП.
• Генри Форд – ошибочно причисляют к основоположникам западных методов УП:
«авторитарное управление проектом/производством самодостаточно и не требует
привлечение УП».
• Анри Файоль, начало ХХ века – заложил основы единой теории управления.
• Генри Гантт, начало ХХ века – разработал структурный подход к управлению
содержанием, временем и людскими ресурсами, сторонник «личностного» подхода в УП.
• Гаррингтон Эмерсон, начало ХХ века – создал теорию эффективной хозяйственной
деятельности, рациональное управление производством.

Восточные практические методы УП:

• Конфуцианская философия (достижение гармонии, семейные ценности).


• Метод Ту-ан-ши.
• Влияние Эдварда Деминга и Джозефа Джурана на качество УП в восточных методах.
• Каору Исикава – развил подход причинно-следственных связей в УП.

Основоположники практических российских методов УП


• Михаил Михайлович Сперанский, 1825 – первые фундаментальные работы по
систематизации методов управления.
Петр Аркадьевич Столыпин, 1900-е – развитие практических методов управления.
• Юлий Сергеевич Витте, 1900-е – методы управления проектами в финансово-
экономическом бизнесе.
• Алексей Капитонович Гастев, 1920-е – разработка НОТ (научной организации труда и
управления); воплощал «личностный» подход в УП, создал ЦИТ (Центральный институт
труда) РФ.

9
ГЛАВА 2. Опыт и знания

ГЛАВА 2. Опыт и знания

ОБЪЕКТЫ УПРАВЛЕНИЯ

Под объектами управления в контексте дисциплины УП понимают: проект, программу


проектов, портфель проектов.

Проект

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

В настоящее время существует большое разнообразие определений проекта. Чтобы не вводить


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

Проект – это мероприятие, направленное на получение нового (уникального) продукта


или услуги, выполняемое в рамках ограниченных ресурсов.
Здесь ресурсы понимаются в широком смысле: время, финансы, материально-технические,
людские, технологические и т.д.
Проектная деятельность существенно отличается от производственной. Целью проектной
деятельности является создание уникального продукта или услуги, целью производственной
деятельности – создание типового продукта или услуги.
Пример 1. Группа людей начинает строительство завода с целью выпуска автомобилей
новых марок. Начинается строительство корпусов, подвод коммуникаций, монтаж
оборудования, организуются поставки материалов и комплектующих, набираются
инженерно-технический состав завода, бригады сборщиков и т.д. Идет подготовка к
промышленной эксплуатации линий сборки и всего комплекса. Завод выводится на 100%
мощности и сдается госкомиссии, после чего начинается процесс серийного производства
автомобилей. В описанной деятельности все, что происходило до подписания акта сдачи-
приемки госкомиссии, можно охарактеризовать проектной деятельностью, после –
производственной.
Проектной деятельности свойственен подход, аналогичный деятельности в искусстве, –
уникальный, творческий. Производственной деятельности свойственны черты дублирования,
повторяющейся «регулярной» деятельности.
Пример 2. Художник пишет картину. На выходе данного процесса – уникальный,
единственный, неповторимый новый продукт. Для проектной деятельности свойственен
именно такой процесс. Если же мы с данной картины начнем делать репродукции, запустим
процесс копирования, то это уже производственный процесс. Причем, подходя более
аккуратно в разграничении типов деятельности, во втором процессе в самом его начале
можно выделить небольшой этап: организация копирования и вывод процесса копирования
на 100% плановой мощности. Этот этап тоже можно отнести к проектной деятельности,
а последующее – собственно к производственному процессу.
В реальной жизни проектная и производственная деятельности пересекаются и
перекрываются: между ними не всегда возможно провести четкую границу (Таблица 2-1).

10
ГЛАВА 2. Опыт и знания

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

Таблица 2-1. Основные различия проектной и производственной деятельности

Производственная
Характеристика Проектная деятельность
деятельность
Фиксированное календарное начало и
Хронологическая Непрерывная
завершение деятельности
Регламентационный
Неотлаженный Отлаженный
тип
Стабильный выпуск
Цель Получение конечного нового продукта
серийного продукта
Вид продукта Уникальный Типовой

Классификация проектов

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


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

Классификация по сферам деятельности (тип проекта)

Технический (строительство здания или сооружения, внедрение новой производственной


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

11
ГЛАВА 2. Опыт и знания

Классификация по размерности (класс проекта)

Класс проекта фиксирует состав и структуру проекта в его предметной области.


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

Классификация по объемам финансирования проекта (масштаб проекта)

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


зависимости от отрасли, масштабов деятельности компании-исполнителя и страны, в которой
реализуется проект, уровни финансирования для проектов одного и того же типа будут
существенно отличаться.
Так, в американской практике существуют прецеденты, когда к малым проектам относят
проекты с объемом капиталовложений до $10-15 млн. и трудозатратами до 40-50 тыс.
человеко-часов. (Примеры: опытно-промышленные установки, небольшие промышленные
предприятия, модернизация действующих производств).
В российской практике к малым проектам можно отнести проекты с объемом финансирования
до $200-300 тыс. А проекты с объемом финансирования свыше $10-15 млн. уже относят, как
правило, к крупным.

Классификация по назначению проекта (назначение проекта)

1. Инвестиционный: главная цель – создание или обновление основных фондов организаций,


требующих вложения инвестиций.
2. Инновационный: главная цель – разработка и применение новых технологий,
организационных новаций, ноу-хау и других нововведений, обеспечивающих развитие
организаций.
3. Научн- исследовательский.
4. Учебно-образовательный.
5. Смешанный.

Классификация по длительности проекта (длительность проекта)

1. Краткосрочный - до 1 года.
2. Среднесрочный - от 1 года до 3 лет.
3. Долгосрочный - свыше 3 лет.

12
ГЛАВА 2. Опыт и знания

Классификация по уровню сложности (сложность проекта)

Эту метрику классификаций иногда называют комплексность проекта.

1. Простой.
2. Сложный.
3. Очень сложный.

Классификация по географическому признаку

1. Проект реализуется в пределах какого-либо города.


2. Региональный проект.
3. Международный проект.

Классификация по принадлежности предприятию

1. Внешний.
2. Внутренний.

Классификация по уровню организации (внутри компании)

1. Локальный – на уровне структурного подразделения, филиала, отделения.


2. Корпоративный – на уровне компании в целом.

Программа

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


общей целью и условиями их выполнения.

Программа, также как и проект, является объектом управления. Однако в отличие от


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

13
ГЛАВА 2. Опыт и знания

временем. Такие программы могут быть международными, государственными,


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

Портфель проектов

Портфель проектов – полный набор проектов и программ предприятия или подразделения


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

14
ГЛАВА 2. Опыт и знания

Цели и стратегия проекта

Цели проекта – желаемый результат деятельности, достигаемый в итоге успешного


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

Критерии успехов и неудач проекта

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


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

15
ГЛАВА 2. Опыт и знания

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


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

Жизненный цикл проекта

Управление проектом обычно рассматривают с двух сторон: предметная сторона и


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

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


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

16
ГЛАВА 2. Опыт и знания

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

6
реализации предметной части проекта

0
Инициализация Создание Разработка Реализация Завершение
1 фаза концепции 3 фаза 4 фаза 5 фаза
2 фаза
Время

Рис. 2-1. Распределение трудозатрат по предметной составляющей проекта

17
ГЛАВА 2. Опыт и знания

Рис.

П
У
по
ов
рс
су
ре
т
ра
зат
ь
ен
ов
Ур

Фаза Концептуальная Разработк Реализаци Завершени


инициации фаза а я е

2-2. Распределение трудозатрат по управлению проектом

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

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

18
ГЛАВА 2. Опыт и знания

Таблица 2-2. Пример соотношения деления жизненного цикла проекта на фазы


в разных сферах деятельности

Общее Госбюджетные Нефтегазо-


Строительные
деление организации ИТ-проекты добывающий
проекты
(PMI) РФ бизнес
Инициация
Инициация Инициация Инициация
(оценка)
Начальная
фаза Подготовка Предконтрактная
тендера фаза (пресейл)
(концепция) Концепция Выбор
Проведение
Контрактование
тендера
Разработка
Фаза
Разработка проектной Разработка Определение
разработки
документации
Фаза
Исполнение Строительство Реализация Выполнение
реализации
Фаза
Завершение Завершение Завершение Эксплуатация
завершения

Жизненный цикл организации


Промышленное
Политика Определение Концепция производство Решение
Планирование потребностей проекта Реализация продукта владельца

Жизненный цикл
продукта/оборудования

Решение
Возможности Приобретение Производство владельца

Жизненный цикл проекта

Концепция Разработка Реализация Завершение Четыре базовые фазы


Цели, задачи Планирование Подготовка Ввод в
работы проекта обеспечение Исполнение эксплуатацию Промежуточные

Рис. 2-3. Жизненный цикл проекта в контексте жизненного цикла организации и


жизненного цикла продукта/оборудования (версия PMI)

19
ГЛАВА 2. Опыт и знания

Окружение проекта

Окружение проекта – среда проекта, порождающая совокупность внутренних и внешних


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

Разработка и оценка проекта, его начало и реализация осуществляются в соответствующем


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

20
ГЛАВА 2. Опыт и знания

Структуры проекта

Структуры проекта – иерархические декомпозиции проекта на составные части (элементы,


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

21
ГЛАВА 2. Опыт и знания

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


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

Структурная модель проекта по фазам жизненного цикла


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

22
ГЛАВА 2. Опыт и знания

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


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

23
ГЛАВА 2. Опыт и знания

СУБЪЕКТЫ И ИНСТРУМЕНТАРИЙ УПРАВЛЕНИЯ

Участники проекта

Участники проекта – юридические и физические лица, которые непосредственно вовлечены


в проект или чьи интересы могут быть затронуты при осуществлении проекта.
Четко определить полный состав участников проекта часто бывает достаточно сложной
задачей. Если состав и содержание работ и функций по управлению проектом от случая к
случаю остается относительно постоянным, то состав участников проекта, их роли, функции,
полномочия и обязанности могут меняться в каждом конкретном случае.
Состав участников проекта, их роли, функции, полномочия, обязанности и ответственности
зависят:
 от типа, вида, масштаба и сложности проекта
 от того, на какой фазе жизненного цикла находится проект в данный момент времени.
Как правило, основными (ключевыми) участниками проекта являются:
Заказчик – главная сторона, заинтересованная в осуществлении проекта и достижении его
целей. Будущий владелец результатов проекта. Заказчик определяет основные требования к
проекту, обеспечивает финансирование проекта за счет своих или привлекаемых средств,
заключает контракты с основными исполнителями проекта и несет ответственность по этим
контрактам, управляет процессом взаимодействия между всеми участниками проекта или
делегирует основному исполнителю эту функцию, несет ответственность за проект в целом
перед обществом и законом и т.п.
Клиент – индивидуум или организация, которая будет использовать продукты проекта. Это
могут быть также группы клиентов.
Собственник проекта – юридическое или физическое лицо, наследующее права
собственности на продукт проекта. Обычно это заказчик.
Спонсор – индивидуум или группа в исполняющей организации, которая обеспечивает
финансовые, материальные, человеческие и другие ресурсы для осуществления проекта.
Управляющий (главный менеджер) проекта – физическое лицо, которому делегируются
полномочия по руководству всеми работами по осуществлению проекта: планированию,
контролю и координации работ всех участников проекта. Он является индивидуально
ответственным за осуществление проекта.
Команда проекта – специфическая организационная структура, совокупность физических и
юридических лиц и их групп, объединенных целевым образом для осуществления проекта.
Создается на период осуществления проекта. Главная задача команды проекта –
осуществление функций координации действий и согласование интересов всех участников
проекта для достижения целей проекта.
Команда управления проектом – специфическая организационная структура, возглавляемая
управляющим (главным менеджером) проекта и создаваемая на период осуществления
проекта. Главная задача команды управления проектом – осуществление функций управления
проектом для эффективного достижения целей проекта.

24
ГЛАВА 2. Опыт и знания

Возможными участниками проекта могут быть:


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

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

25
ГЛАВА 2. Опыт и знания

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


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

Команда проекта

Термин «команда» используется для обозначения отношений партнерства и сотрудничества


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

26
ГЛАВА 2. Опыт и знания

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


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

Команда управления проектом – члены команды проекта, которые непосредственно


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

Команды проекта могут существовать на разных уровнях организации: Совет директоров,


группы менеджеров, занимающихся планированием или реорганизацией, проектные группы.
В рамках настоящего курса мы предлагаем использовать следующее определение понятия
«команда».
В практике можно выделить три основных модели формирования команды проекта:
1) Привлечение руководителей или специалистов к работе над проектом по
совместительству с основной работой:
Эта модель выбирается для ограниченных по времени и ресурсам проектов. Руководство
предприятия назначает руководителя проекта из числа штатных сотрудников. При этом
руководитель проекта продолжает выполнять обязанности по основной должности и по
совместительству руководит проектной командой. Ему предоставляются права по доступу к
необходимой информации и по планированию и координации использования ресурсов,
требующихся для реализации проекта.
Проблемы при использовании такой модели могут заключаться в том, что менеджер проекта
лишь в малой степени может влиять на сотрудников из других подразделений из-за
приоритета их подчинения линейным руководителям подразделений. Повышенная нагрузка
из-за работы над проектом и по основной должности может приводить к небрежностям по
проектным заданиям.
2) «Предприятие в предприятии» (классическая модель):
Эта модель выбирается при комплексных и объемных задачах и необходимости тесной
интеграции проекта с основной деятельностью предприятия. Работа в команде проекта имеет
однозначный приоритет перед отношениями подчинения руководителям традиционных
подразделений. Проект курируется непосредственно руководством, а руководитель и
отдельные сотрудники проекта полностью или частично освобождаются от своей обычной
деятельности.
3) Смешанные формы:
Чаще всего такая модель используется на средних предприятиях, исполняющих проекты. При
этом, как правило, для руководства проектом подбирается опытный руководитель проекта
(возможно – извне) и, в зависимости от проекта, привлекаются квалифицированные
специалисты из функциональных подразделений по совместительству с основной работой
(под отдельные задачи могут быть привлечены также специалисты извне на время
выполнения конкретной задачи). Вся ответственность при этом возлагается на руководителя
проекта, который обычно имеет поддержку от руководства предприятия.
Еще один вариант – назначение координатором проекта одного из высших руководителей
компании. При этом для оперативной работы по проекту ему обычно выделяется молодой и
перспективный сотрудник, который в дальнейшем может возглавить направление, связанное
с проектом.
Место и роль команд в проекте определяется целями входящих в них лиц и представителей
участников проекта, степенью участия команды в процессах проекта и ее ответственностью.
Состав и функции команды управления проекта зависят от масштабов, сложности и других

27
ГЛАВА 2. Опыт и знания

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


профессиональный уровень всех возложенных на нее обязанностей. Культура команды
менеджмента проекта различного типа в общем случае включает в себя национальную,
корпоративную, организационную и профессиональную культуры. По степени
вовлеченности в проект в команде можно выделить три группы участников:
 основная группа – группа специалистов, непосредственно работающих над
осуществлением проекта в тесном контакте друг с другом и знающих каждого члена
группы;
 вторичная группа – более обширная, чем основная, объединяет специалистов и
организации, оказывающие содействие членам основной группы, но не участвующие
напрямую в осуществлении проекта и достижении его целей;
 вспомогательная (третичная) группа – люди, оказывающие влияние на членов
основной и вторичной групп и на ход работ по проекту, но не вступающие с ними в
прямое сотрудничество.
Основные этапы жизненного цикла команды проекта
Наши отечественные специалисты выделяют пять этапов в жизненном цикле команды
проекта.
1. Формирование
На этом этапе члены команды знакомятся друг с другом. Менеджер проекта занимается
формированием благоприятных взаимоотношений и эффективного взаимодействия в
команде, сплочением участников на основе главной цели проекта, начинается выработка
общих норм и согласование ценностей. Кроме этого, менеджер выстраивает эффективные
отношения с окружением и внешними участниками проекта.
2. Этап срабатываемости участников
В процессе совместной работы над проектом проявляются различия в подходах и методах,
используемых участниками, возникают трудности и конфликтные ситуации в работе
команды. Менеджер проекта уделяет особое внимание формированию конструктивных
позиций у участников проекта при решении возникающих проблем и оптимальному
распределению ролей в команде.
3. Этап нормального функционирования
К этому этапу у участников уже формируется чувство команды, все они, как правило,
понимают, что от них требуется для достижения общей цели и выполняют определенную для
них в рамках проекта часть работы. Этот этап является самым продолжительным и самым
продуктивным для проекта.
4. Этап реорганизации
На этом этапе менеджер, как правило, производит изменения в количественном и
качественном составе команды. Это связано с различными причинами, в том числе и с
такими, как изменения в объемах и видах работ, необходимость замены некоторых
работников из-за их непригодности, потребность в привлечении новых специалистов или
временных экспертов.
5. Этап расформирования команды
По завершении проекта команда расформировывается. Два типичных сценария развития
событий на этом этапе таковы.
В первом случае, когда команда достигает успеха в реализации проекта, все ее участники
получают удовлетворение от совместной работы и готовы к дальнейшему сотрудничеству.
При открытии нового проекта менеджер, как правило, и приглашает в команду этих же
людей.
Во втором случае, когда проект неуспешен, команда расформировывается и чаще всего далее
уже не собирается в таком составе.
Опыт реализации различных проектов показывает, что оптимальный период работы
проектной команды 1,5-2 года. Затем ее эффективность падает. Для решения данной

28
ГЛАВА 2. Опыт и знания

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


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

Управляющий проектом

Управляющий (менеджер) проекта – главная фигура в процессе управления проектом.


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

29
ГЛАВА 2. Опыт и знания

интуицией. Наличие теоретических знаний без опыта еще не гарантирует качественного


управления проектом. Опыт в сочетании с теоретическими знаниями, навыками и
врожденными умственными способностями формируют интуитивные оценки, которые часто,
как и в искусстве, оказываются решающими при выборе того или иного пути движения
вперед.
Как показывают исследования специалистов в области УП, менеджеры тратят около 75%
своего рабочего времени на общение, уточнение тех или иных деталей проекта, разъяснения,
нахождение взаимопонимания между членами команды проекта, встречи, совещания,
переписку и т.д. При этом основным инструментом менеджера является риторика – искусство
адекватного донесения своих мыслей до адресата. Недооценивание этого ресурса часто
является источником значительных рисков и конфликтов в проектной деятельности, в
которых повинен менеджер, руководитель проекта.
Будем использовать термины «менеджер» и «управляющий» как синонимы, обозначающие
принадлежность к профессии. Очевидно, что менеджер (управляющий) может занимать
разные должности в команде проекта, управляя каким-либо звеном в проекте. Если менеджер
управляет проектом в целом, руководит им, то в этом случае будем называть менеджера
руководителем проекта.
Руководитель проекта должен осознавать, с кем, как и при помощи какого словарного запаса
разговаривать. Здесь он может и должен использовать свой ресурс психоаналитика.

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

Модель организации деятельности предприятия или учреждения в значительной степени


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

 функциональная;
 матричная;
 проектная.

Функциональная структура

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


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

30
ГЛАВА 2. Опыт и знания

Координация проекта
Руководитель организации

Функциональный Функциональный Функциональный Функциональный


менеджер менеджер менеджер менеджер
(инженерные (финансы) (маркетинг) (производство)
разработки)

Служащий Служащий Служащий Служащий

Служащий Служащий Служащий Служащий

Служащий Служащий Служащий Служащий

Рис. 2-4. Функциональная организационная структура.

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

Проектная структура

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

31
ГЛАВА 2. Опыт и знания

Руководитель организации

Менеджер проекта Менеджер проекта Менеджер проекта


Финансы

Маркетинг

Служащий Служащий Служащий

Стратегическое
планирование Служащий Служащий Служащий

Служащий Служащий Служащий


Техническая
поддержка

Координация проекта

Рис. 2-5. Проектная структура.

Проектная структура ориентирована на предприятия, у которых профилирующий вид


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

Матричная структура

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


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

32
ГЛАВА 2. Опыт и знания

В зависимости от преобладания функциональной или проектной составляющей деятельности


предприятия матричные структуры делятся на:

 упрощенную;
 сбалансированную;
 усиленную.

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


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

Руководитель организации

Функциональный Функциональный Функциональный Функциональный


менеджер менеджер менеджер менеджер
(инженерные (финансы) (маркетинг) (производство)
разработки)

Служащий Служащий Служащий Служащий

Служащий Служащий Служащий Служащий

Служащий Служащий Служащий Служащий

Координация проекта

Рис. 2-6. Упрощенная матричная структура.

33
ГЛАВА 2. Опыт и знания

Чтобы минимизировать эти отрицательные свойства матричной структуры, используются


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

Упрощенная матричная структура

В таком варианте организации (рис. 2-6) сохраняются все особенности функциональной


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

Сбалансированная матричная структура

Руководитель организации

Функциональный Функциональный Функциональный Функциональный


менеджер менеджер менеджер менеджер
(инженерные (финансы) (маркетинг) (производство)
разработки)

Служащий Служащий Служащий Служащий

Менеджер проекта Служащий Служащий Служащий

Служащий Служащий Служащий Служащий

Координация проекта

Рис. 2-7. Сбалансированная матричная структура.

При таком подходе (рис.2-7) из числа служащих одного из функциональных подразделений


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

34
ГЛАВА 2. Опыт и знания

Усиленная матричная структура

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


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

Руководитель организации

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


отдела менеджер менеджер менеджер
менеджеров проектов (финансы) (маркетинг) (производство)

Менеджер проекта Служащий Служащий Служащий

Менеджер проекта Служащий Служащий Служащий

Служащий Служащий Служащий


Менеджер проекта

Координация проекта

Рис. 2-8. Усиленная матричная структура.

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


существенно различается (см. таблицу 2-3).
В целом все структуры имеют свои преимущества и недостатки (таблица 2-4), поэтому на
практике каждая из упомянутых структур в чистом виде используется нечасто. Чаще
используется некоторая их комбинация, что позволяет сгладить недостатки, характерные для
каждой из составляющих. Например, для выполнения критического проекта в
функциональной компании вполне возможно создание отдельной команды. Эта команда
может нести в себе все черты проектно-ориентированного подхода, включая
откомандирование на условиях полной занятости специалистов из функциональных
подразделений, предоставление менеджеру проекта всей полноты власти, включая
финансовые полномочия в рамках бюджета проекта. Для такого проекта могут быть
установлены свои собственные управленческие процедуры и процедуры отчетности,
отличные от принятых в компании в целом. Кроме того, в некоторых случаях для оказания
одному или нескольким проектам ряда сервисных услуг может быть сформировано отдельное
подразделение – служба поддержки проекта. В англоязычной литературе для его обозначения
используется термин Project Support Office. Это подразделение предоставляет такие услуги,
как планирование сроков и ресурсов, контроль хода выполнения, распространение/сбор
любой другой проектной информации и пр.

35
ГЛАВА 2. Опыт и знания

Таблица 2-3. Загруженность персонала в проектной деятельности в разных


организационных структурах

Тип орг. Функциональная Матричная Проектно-


структуры ориентированн
/Параметр ая
сравнения
Упрощенная Сбалансирован- Усиленная
ная

Полномочия Малы или Ограничены От От средних до От широких до


менеджера отсутствуют ограниченных до широких почти полных
проекта средних
Процент Практически нет 0 – 25% 15 – 60% 50 – 95% 85 – 100%
персонала,
полностью
занятого на
проектах
Занятость Частичная Частичная Полная Полная Полная
менеджера
Наименование Координатор Координатор Менеджер Менеджер Менеджер
позиции проекта/лидер проекта/лидер проекта проекта / проекта /
менеджера проекта проекта менеджер менеджер
проекта программы программы
Занятость вспом. Частичная Частичная Частичная Полная Полная
админ.,
персонала

Таблица 2-4. Преимущества и недостатки разных организационных структур

Основные показатели Функциональная Матричная Проектная


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

36
ГЛАВА 2. Опыт и знания

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

Другие организационные структуры

37
ГЛАВА 2. Опыт и знания

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


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

Процессно-ориентированная организационная структура строится с ориентацией на


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

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


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

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


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

Организационная структура проекта

38
ГЛАВА 2. Опыт и знания

Как уже отмечалось, важной составляющей в управлении проектов является формирование


команды проекта. Состав команды определяется целью, задачами проекта, наличием
доступных людских ресурсов и типом организационной структуры родительского
предприятия.
Организационная структура проекта – наиболее соответствующая проекту временная
организационная структура, включающая всех его участников и создаваемая для успешного
достижения целей проекта.
Декомпозиция организационной структуры (Organisational Breakdown Structure – OBS) –
структурная декомпозиция организации проекта, предназначенная для соотнесения пакетов
работ с организационными единицами. Примеры организационных структур проектов
приведены на рис.2-9, 2-10.
Разработка организационной структуры проекта включает:
 идентификацию всех организационных единиц; 
 определение ролей участников проекта и их взаимодействия, определение
ответственности и полномочий;
 распределение ответственности и полномочий между организационными единицами
структуры;
 разработку инструкций, регламентирующих взаимодействия в структуре и рабочие
процедуры.
Организационная структура проекта является динамической структурой, которая
претерпевает изменения в процессе осуществления проекта. Эти изменения зависят от фаз
жизненного цикла проекта, типов, используемых в проекте контрактов и других условий
выполнения проекта.

На рис.2-10 показан пример организационной структуры ИТ-проекта. В этом проекте


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

39
ГЛАВА 2. Опыт и знания

Куратор комплексного
проекта

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

Региональные Изучение Поисковое Оценка Оформление


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

Рабочая группа Рабочая группа Рабочая группа Рабочая группа Рабочая группа

Смежные Смежные Смежные Смежные Смежные


подразделения подразделения подразделения подразделения подразделения

- Управление - Управление - Подрядные - Отдел геологии - Отдел


кадров кадров строительные и учета запасов лицензирования и
- Управление МТС - Управление МТС организации - Отдел недропользова-
- Управление - Управление моделирования ния
технологического технологического
транспорта транспорта
- Отдел
моделирования

Рис. 2-9. Организационная структура проекта «Нефте-газо разведка». Показана в виде


блок-схемы.

40
ГЛАВА 3. Процессы управления

Куратор Руководитель проекта


проекта
Бизнес ветвь (предметная
Ветвь управления
Организационн часть)

ая структура Эксперт ГМП (Главный менеджер


проекта)
проекта,
OBS
ГИП (Главный Администратор
инженер проекта) проекта
(Проектный
Координатор
офис) проекта
Инженер Инженер Инженер
направления направления 2 направления 3 Менеджер 1
1
Менеджер 2

Бригадир Бригадир Бригадир


2-1 2-2 2-3 Менеджер 3
Команда проекта
(КП) КУП Менеджер 4

Менеджер по
Команда Звено 2- Звено 2- Звено 2- продажам
управления 2-1 2-2 2-3 Экономист
проекта (КУП)
Инженер службы
Информ.Безопаснос
ти
Исп.-2-2- Исп. 2-2- Исп. 2-2- Менеджер службы
2-1 2-2 2-3 КП качества

Рис. 2-10. Пример организационной структуры проект в области информационных технологий


Руководство и лидерство

Руководство и лидерство – искусство воздействия на других для побуждения их к


достижению определенных целей.

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


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

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


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

42
деловому администрированию, мотивации, системе поощрения и наказания и проч.

Решение проблем

Решение проблем – определение последовательных систематических процедур, с помощью


которых анализируются и решаются проблемные ситуации.

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

Конфликты в команде проекта

По данным одного из опросов, проведенного Американской Ассоциацией менеджеров, были


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

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

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

Причины возникновения конфликтов


Основные причины возникновения конфликтов в управлении проектами можно представить
следующим образом:
1. Конфликт из-за приоритетов в проекте.
Мнения участников проекта о последовательности работ и задач различаются.
2. Конфликт из-за административных процедур.
Расхождения между участниками по поводу того, как должен управляться проект.
3. Конфликт из-за технических решений.
Несогласие по техническим вопросам и технологии производства работ.
4. Конфликт из-за людских ресурсов.
Конфликт из-за набора исполнителей из других подразделений и распределения их по
направлениям работ.
5. Конфликт из-за увеличения стоимости.
Конфликт из-за перерасходов, вызванных авариями и другими непредвиденными
ситуациями, увеличивающими стоимость проекта.
6. Конфликт из-за выполнения календарного плана.
Несогласие из-за времени и последовательности выполнения проектных задач.
7. Конфликт из-за личных взаимоотношений.
Для разрешения конфликта менеджер сначала должен выявить реальные причины конфликта,
а затем использовать наиболее подходящие стратегии и методы для управления конфликтной
ситуацией.

Переговоры, деловые встречи

Переговоры, деловые встречи – мероприятия, предпринятые для поиска решения


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

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


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

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

Информационные технологии в проекте

Информационные технологии в проекте – совокупность процессов сбора, хранения,


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

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

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

На уровне исполнения заданий (пакетов работ) проекта необходима детальная информация,


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

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

Стандарты и нормы

Стандарты и нормы – документы, устанавливающие общие принципы, правила и


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

47
 Международная организация по стандартам (ISO).
Все они в той или иной мере участвуют в создании норм, инструкций и стандартов в области
управления проектами.
Классификация стандартов:
 международные;
 национальные;
 отраслевые;
 фирменные.
При разработке международных и национальных систем требований в качестве базы
используются стандарты семейства ISO 9000.
Следует различать системы требований и стандарты в области управления проектами. В
частности, два базовых международных документа, определяющих компетентность
профессионалов в области проектного менеджмента (ICB IPMA Competence Baseline и A
Guide to the Project Management Body of Knowledge. PMI) являются системами требований.
В то же время, семейство ISO (ISO 10006) и DIN являются стандартами. В области
управления проектами основными нормативными международными документами являются:
 ICB IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee: Caupin G.
Knopfel H., Morris P., Motzel E., Pannenbacker O. Bremen: Eigenverlag, 1999. pp.112.
 A Guide to the Project Management Body of Knowledge. PMI. Director of Standards
Committee: Duncan W.R. pp.176 (Путеводитель в мир управления проектами. Пер. с
англ. Екатеринбург: УГТУ, 1998. с.192.)
 ISO 10006 Quality Management – Guidelines to quality in project management (12/97).
(ISO 10006 Управление качеством – Руководство по качеству при управлении
проектами (12/97).
Помимо международных нормативных документов и стандартов в ряде стран существуют
национальные системы стандартов и требований. Например:
 Ireland L.R., Quality Management for Project & Programs. Drexel Hill, PA: PMI, 1991;
Competence Standart, Level 4/5/6, AIPM Australian Institute for Project
Management, 1996 (Стандарт Требований к Компетенции, Уровни 4/5/6,
Австралийский Институт Управления Проектами, 1996.);
 DIN 69 9001 Управление проектами – Сетевые методы управления – Термины
(1997); DIN 69 9002 Управление проектами – Сетевые методы управления –
Использование (1987);
 DIN 69 901 Управление проектами – Прожект менеджмент – Термины
(1987); DIN 69 902 Управление проектами – Практические методы –
Термины (1987);
 DIN 69 903 Управление проектами – Затраты и результаты, методы управления
финансами – Термины (1987);
 DIN 69 904 Управление проектами – Системы управления проектами –
Элементы и структуры (проект стандарта 1998);
 DIN 69 905 Управление проектами – Завершение проекта – Термины (1997).
При управлении проектами выполнение проектно-ориентированных работ регулируется
соответствующими сфере приложения проекта общими и отраслевыми стандартами и
нормами.
Процесс управления проектами регулируется специальными стандартами и инструкциями,

48
относящимися к управлению проектами.

Правовое обеспечение проекта

Правовое обеспечение проекта – совокупность правовых (юридических) норм,


регулирующих деятельность по осуществлению проекта.

У каждого решения, принимаемого в ходе реализации проекта, должно быть


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

49
ГЛАВА 3. Процессы управления

ГЛАВА 3. Процессы управления

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

Управление проектом – использование знаний, навыков, методов, средств и технологий


при выполнении проекта с целью достижения или превышения ожиданий участников
проекта.

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


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

50
ГЛАВА 3. Процессы управления

Знания по управлению
проектами

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

Общий Знания
менеджмент предметной
области

Рис. 3-1. Связь УП с другими областями знаний

Проектно-ориентированное управление

Проектно-ориентированное управление – управленческий подход, при котором отдельно


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

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


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

В проектно-ориентированной компании менеджер проекта имеет полные полномочия для


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

51
ГЛАВА 3. Процессы управления

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


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

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


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

52
ГЛАВА 3. Процессы управления

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

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


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

53
ГЛАВА 3. Процессы управления

необходимо ответить на несколько ключевых вопросов:


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

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

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


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

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

54
ГЛАВА 3. Процессы управления

 процессы контроля – обеспечение достижения целей проекта путем мониторинга хода


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

Процессы Процессы
инициации планирования

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

Процессы
завершения

Рис. 3-2. Связи между группами процессов внутри одной фазы

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

55
ГЛАВА 3. Процессы управления

Уровень трудозатрат

Процессы организации выполнения

Процессы
планирования
Процессы
завершения
Процессы
инициации
Процессы контроля

Время

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

56
ГЛАВА 3. Процессы управления

К процессам организации выполнения


Процессы планирования

Основные процессы

Определение
Определение Разработка графика
последовательности
Планирование состава работ (расписания)
работ
содержания

Оценка
Составление
продолжительности
бюджета
работ
Определение
содержания
Планирование
ресурсов Оценка затрат Разработка
сводного плана
проекта

Вспомогательные процессы

Планирование Планирование Идентификация Количественная Разработка методов


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

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

Процессы инициации

Инициация проекта – стадия процесса управления проектом, результатом которой


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

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

Инициирование (запуск) проекта часто ассоциируется с начальной фазой проекта, на


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

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

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


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

Решение о запуске проекта может быть принято на организационном совещании.

Процессы планирования

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

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

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


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

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

Процессы организации выполнения работ


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

61
 Управление контрактами – управление взаимодействием с выбранными
поставщиками в рамках заключенных контрактов.

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

Процессы организации выполнения работ

Выполнение сводного
плана проекта

К процессам контро
Вспомогательные процессы

Обеспечение
От процессов

Распространение Формирование и качества


контроля

информации развитие команды


проекта
Подтверждение
содержания
Предварительная Выбор
работа с поставщиков
поставщиками Управление
контрактами

Рис. 3-5 Взаимодействие процессов организации выполнения

Процессы контроля

Эффективность выполнения проекта должна оцениваться регулярно с целью обнаружения


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

62
 контроль реагирования на риски – ответные действия на изменения состава и
значимости факторов риска по всему жизненному циклу проекта;

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

Отчетность по эффективности Всеобщий контроль


выполнения проекта изменений

Вспомогательные процессы

К процессам завершения
Контроль изменений Контроль графика Контроль затрат
содержания работ

Контроль качества Контроль реагирования


на риски

Рис. 3-6. Взаимодействие между процессами контроля.

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

Анализ и регулирование выполнения проекта – это процесс сравнения фактического


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

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

Анализ и регулирование проекта по временным параметрам:


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

Анализ и регулирование проекта по стоимостным показателям:


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

Анализ состояния и обеспечение качества:


 Сравнение фактических результатов проекта со спецификациями и
требованиями;
 Анализ состояния и прогресса качества в проекте на протяжении его
жизненного цикла;
 Техническая оценка качества продукта проекта; 
 Процесс проверки соответствия результатов контроля качества существующим
требованиям;
 Формирование списка отклонений;
 Определение необходимых корректирующих действий по обеспечению
качества в проекте;
 Решение о промежуточной приемке;
 Уточнение списков контроля объектов;
 Корректирующие действия по обеспечению качества в проекте;
 Документирование изменений.

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

Анализ деятельности и развитие команды проекта:


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

Анализ, интеграция и регулирование изменений в проекте:


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

Процессы завершения

Эта группа включает два процесса:

65
 Административное завершение – генерация, сбор и распространение информации,
необходимой для формального завершения фазы или проекта в соответствии с
принятыми в компании административными процедурами.
 Закрытие контрактов – закрытие и окончательный расчет по контрактам, включая
разрешение всех спорных и нерешенных вопросов.
Как уже отмечалось ранее, к сожалению, в отечественной практике в настоящее время
уделяется мало внимания грамотному завершению проекта. Как результат, компании
часто повторяют ошибки, сделанные в прошлых проектах. Можно привести как минимум
четыре причины, по которым по завершении проекта следует проводить тщательный
анализ проекта и документировать результаты:
 Общее подведение итогов. Если проект был достаточно большим и/или
выполнялся на протяжении нескольких лет, то многие участники в конце имеют
весьма туманное представление об окончательных результатах. Были ли
достигнуты первоначальные цели проекта? Каковы были общие фактические
расходы и прибыль? Ответ на эти вопросы обязательно должен быть дан.
 Документирование удачных решений и разработка рекомендаций по их
тиражированию. В ходе выполнения проекта компания получает ценный опыт,
носителем которого становятся менеджер и команда проекта. Налаженный обмен
таким опытом внутри компании является важным фактором ее жизнестойкости и
конкурентоспособности.
 Документирование неудачных решений и разработка рекомендаций по их
предотвращению в дальнейшем. Достаточно часто по завершении проекта
менеджеры стараются как можно меньше вспоминать о имевших место неудачных
решениях. В результате эти неудачные решения могут быть повторены на других
проектах другими менеджерами компании.
 Приобретение опыта персоналом. По ходу выполнения проекта все его участники
получают новый опыт, развивают уже имеющиеся знания и навыки. Знания и опыт
персонала - это один из важнейших активов компании. И информация о вновь
приобретенных умениях каждого из участников проекта, а также отзывы о том, как
каждый из участников себя показал, могут оказаться очень ценными при принятии
кадровых решений и комплектовании команд для будущих проектов.

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

Система – целостное образование, состоящее из множества элементов,


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

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

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


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

67
необходимо ответить на несколько ключевых вопросов:
 Зачем нужно управление проектами в компании?
 Где нужно и можно применять управление проектами?
 Что даст применение управления проектами компании?
 Что нужно сделать для применения управления проектами в компании?

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


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

Управление документооборотом и интеграцией

Поскольку деление УП на области знания (подход PMI) или на разделы (подход IPMA)
выполняется какой-либо группой людей, то это деление носит и определенную долю

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

69
Рис. 3-7. Относительный вклад элементов управления проектами в жизненном цикле ИТ проектов

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

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

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

Сводный план проекта содержит следующую информацию:


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

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


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

72
Управление документооборотом и интеграцией проекта

Разработка сводного плана Выполнение сводного плана Общее управление


проекта проекта изменениями

Входные объекты Входные материалы Входные материалы


Выходные объекты других Сводный план проекта Сводный план проекта
процессов планирования Дополнительные материалы Отчеты по эффективности выполнения
Статистические и архивные Организационная политика проекта
данные Запросы на внесение изменений
Корректирующие воздействия
Организационная политика Инструменты и методы
Инструменты и методы
Ограничения Система контроля изменений
Навыки общего менеджмента
Допущения, принятые как Управление конфигурацией
Знания и навыки, необходимые для
истинные
создания продукта Контроль эффективности выполнения
Инструменты и методы проекта
Система авторизации (утверждения)
Методология планирования проекта заданий на выполнение работ Дополнительное планирование
Опыт, знания и навыки ключевых Совещания по анализу текущего Информационная система управления
участников проекта состояния проекта проектом
Информационная система Информационная система управления Выходные материалы
управления проектом проектом Обновления сводного плана проекта
Выходные материалы Организационные процедуры Корректирующие воздействия
1. Сводный план проекта Выходные материалы Извлеченные уроки
2. Дополнительные материалы 1. Результаты работ
2. Запросы на внесение изменений

Рис. 3-8. Управление документооборотом и интеграцией проекта

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


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

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

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


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

Управление содержанием проекта

Управление содержанием (предметной областью) проекта определяет, какие виды


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

В контексте проекта под термином «содержание» может подразумеваться:


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

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


предметной области.

74
Управление содержанием проекта

Инициализация Планирование Определение содержания

содержания
Входные материалы Входные материалы Входные материалы
Описание продукта Описание продукта Свод содержания проекта
Стратегия компании Основные положения проекта Ограничения
Критерии выбора проекта Ограничения Допущения
Статистические и архивные Допущения Результаты других процессов
данные Инструменты и методы планирования
Инструменты и методы Анализ продукта Статистическая и архивная
Методика выбора проекта Анализ прибылей/затрат информация
Заключение экспертов Идентификация альтернатив Инструменты и методы
Выходные материалы Заключение экспертов Шаблоны иерархических структур
Основные положения проекта Выходные материалы декомпозиции проекта
Назначение руководителя проекта Свод содержания проекта Методы декомпозиции
Ограничения Вспомогательные материалы Выходные материалы
Допущения Регламент внесения изменений в Иерархическая структура
содержание проекта декомпозиции проекта (СДР)

Подтверждение содержания Контроль изменений содержания


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

Рис. 3-9. Управление содержанием проекта.

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

Входные материалы для процесса инициализации:


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

Инструменты и методы для процесса инициализации:


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

Выходные материалы процесса инициализации:


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

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

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

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


 Анализ продукта. Подразумевает получение точного представления о продукте,
который предполагается получить. Используются такие технологии, как системное
проектирование, функциональный анализ и пр.
 Анализ прибылей/затрат. Финансовый анализ проекта с точки зрения скорости
возврата инвестиций, прибыльности и пр.
 Идентификация альтернатив. Термин, обобщающий различные управленческие
методы, позволяющие сформировать альтернативный подход к выполнению
проекта. Например, «мозговой штурм».
 Заключения экспертов. См. предыдущий раздел.

Выходные материалы процесса планирования содержания:


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

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

77
Входные материалы для процесса определения содержания:
 Свод содержания проекта. См. предыдущий раздел.
 Ограничения. См. предыдущий раздел.
 Допущения. См. предыдущий раздел.
 Выходные материалы других процессов планирования.
 Статистическая и архивная информация.

Инструменты и методы для определения содержания:


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

Выходные материалы процесса определения содержания: СДР.

78
Подготовка/утверждение
Техио коммерческого предложения

фаза
Подготовка/заключение контракта

Предконтрактная
Проектирование системы/
Подготовка спецификаций
Фаза
разработки

Заказ оборудования

области ИТ
система

Инсталляция/конфигурирование
оборудования и ПО
Информационная

Фаза
реализации

Тестирование и опытная
эксплуатация

Техническая поддержка и upgrade

Рис. 3-10. Пример блочной декомпозиции по жизненному циклу проекта из


Закрытие проекта
Эксплуатация

79
Рис. 3-11. Пример СДР в формате MS Project

Чаще всего используется два вида СДР:


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

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

80
Код Название Номер Длитель- Начало, Окончание, Трудозатраты, Стоимость, Чел. Приоритет
задачи задачи предшествующей ность, дата дата чел-часы руб. ресурсы задачи
задачи дни
1.1 Формирован - 3 10.05.2005 12.05.2005 18 22000 БИМ, РП 2
ие идеи
проекта
1.2 Проведение 1.1 1 13.05.2005 13.05.2005 10 10000 БИМ, 1
совещания Гейткипер,
SPA, РП
1.3 Протокол 1.2 - 13.05.2005 13.05.2005 - - РП 1
совещания
2.1 Подготовка 1.2; 1.3 2 16.05.2005 17.05.2005 12 14000 БИМ, РП 1
Запроса на
инициацию
проекта

Таблица 3-1. Пример представления СДР

81
В таблице 3-1 приведен пример СДР в табличном представлении. В 1-м столбце указывается код
задачи, в соответствии с принятыми на предприятии правилами и настройкой инструментов ПО,
используемых в УП (например, MS Project). Этот код показывает место задачи в иерархической
структуре СДР: к какой фазе, этапу, блоку, группе относится задача. Код задачи может
использоваться как параметр при различных группировках, фильтрации и сортировках задач по
степени вложенности, принадлежности, соподчиненности и логических взаимосвязей.
Название задачи обычно содержит краткую формулировку, которая при необходимости может
быть пояснена в специальных примечаниях. В MS Project это решается несколькими
технологическими приемами, например, через систему заметок в описании свойств задач или
через связанный с задачей документ. Документ может быть в формате Word, Excel, MS Project и
др.
Следующий столбец один из самых информативных и тяжелых для заполнения: номер
предшествующей задачи. Опыт составления СДР показывает, что именно в этом столбце
менеджеры чаще всего допускают ошибки. Информация этого столбца показывает всю логику
взаимосвязей задач в проекте, она обеспечивает эффективность компоновки параллельно и
последовательно выполняющихся задач. От правильности определения предшествующей задачи
(задач), зависят основные параметры проекта, такие как общая длительность проекта, стоимость,
трудозатраты, ресурсы. Неправильное указание предшествующей задачи, как правило, влечет за
собой большие конфликты между параметрами проекта и значительно затрудняет эффективное
использование инструмента MS Project. Именно в этом столбце лучше всего проявляется,
профессионализм менеджера, составляющего СДР, его опыт и навыки. В практике ведения
реальных проектов не следует недооценивать значимость этого столбца, кажущегося на первый
взгляд простым в заполнении.
Оценку продолжительности работ, как правило, дают ответственные исполнители по этим
работам, затем продолжительность работ согласуется с ключевыми участниками проекта, а
руководитель (менеджер) проекта заносит в СДР согласованные данные. Иногда в СДР вводится
дополнительный столбец «Резерв времени» или «Возможные отклонения по времени».
Величины возможных отклонений и их вероятности определяются для важных работ,
обстоятельства выполнения по времени у которых имеют значимые неопределенности и
оцениваются ответственным исполнителем по данной работе, либо экспертом, либо
руководителем проекта. Например, данная работа займет 2 недели. Возможные отклонения – 2-3
дня в ту или иную сторону с вероятностью в 15%. В подобной ситуации обычно используются
вероятностные методы оценки продолжительности работ, а именно метод PERT (Program
Evaluation and Review Technique). По этому методу продолжительность рассчитывается по
формуле:
ПPERT=(ПОПТ+4*ПНВ+ППЕСС)/6
где:
ПОПТ - оптимистическая оценка продолжительности;
ППЕСС - пессимистическая оценка продолжительности;
ПНВ - наиболее вероятная оценка продолжительности.
Если вероятность величин отклонений не удается точно определить, можно использовать
интегральные экспертные оценки эксперта (экспертов). В этом случае эксперт дает оценку
продолжительности работы (ППЕСС ) при наихудшем стечении обстоятельств, максимальных
задержках и п.т. Оптимистическую оценку продолжительности (ПОПТ) эксперт оценивает как
продолжительность работы при оптимальном, благоприятном стечении обстоятельств, с
минимальными задержками. Здесь метод PERT обычно используется в виде формулы:
ПPERT=(ПОПТ+ 5*ППЕСС)/6,
Опыт выполнения ИТ проектов подтверждает, что наиболее вероятное время выполнения работы
близко именно к данной оценке П PERT с приданием весового коэффициента 5 наихудшему
варианту и коэффициента 1 – оптимистическому варианту.

82
Таким образом, даже в случае значительных неопределенностей руководитель проекта должен
придерживаться качественного и аргументированного составления СДР, используя экспертные
оценки опытных профессионалов, современные инструменты и методы.
Трудозатраты задачи обычно считаются в человеко-часах, но иногда в более крупных единицах:
человеко-днях, -месяцах, а иногда и в человеко-годах. Этот параметр зависит от того, сколько
человек необходимо для выполнения данной задачи на протяжении определенного в столбце
«Продолжительность» времени и с каким процентом загрузки будет работать каждый из них.
Например, в задаче 2.1 участвует БИМ с загрузкой 25% на протяжении 2 дней и руководитель
проекта (РП) с загрузкой 50% в тот же период времени. Итого получается:
БИМ потратит 2 дня х 0.25 = 4 часа, трудозатраты РП: 2 дня х 0.5 = 8 часов (при условии, что
рабочий день равен 8 рабочим часам). Всего трудозатраты на задачу 2.1 составят 12 человеко-
часов.
Столбец «Стоимость» в базовой версии СДР считается как себестоимость реализации задачи.
Если в реализации задачи участвовали только людские ресурсы, то «Стоимость» считается как
произведение себестоимости ресурса на трудозатраты. Себестоимость ресурса состоит из двух
основных частей: заработной платы и себестоимости инфраструктуры, обеспечивающей работу
данного ресурса. Обычно на предприятии экономисты рассчитывают среднее значение
себестоимости ресурсов по их группам: например, для секретарей-машинисток, инженеров-
программистов, офис-менеджеров и т.д. Предположим, что себестоимость ресурса БИМов в
среднем составляет 1500руб/час, а РП – 1000руб/час. Тогда себестоимость задачи 2.1 будет
составлять: 4 час х 1500 + 8 час х 1000 = 14000 руб. Если для реализации задач необходима
закупка оборудования, ПО или привлечение подряда, то в этом случае указывается стоимость
договора поставки или договора на подрядные работы. Конкретные схемы определения
«Стоимости» обычно указываются в соответствующих Регламентах и могут реализовываться в
автоматическом режиме при использовании инструментария УП (например, MS Project).
«Человеческие ресурсы» заполняются обычно таким образом, что первым указывается
ответственный исполнитель, затем рядовые исполнители, принимающие участие в выполнении
задачи.
Важным параметром является «Приоритет» задачи. Этот параметр может регулировать
распределение и выделение ресурсов под задачу, что является весьма значимым в условиях
нехватки, ограниченности выделяемых ресурсов. Для верхнего руководящего звена этот
параметр может быть инструментом реализации стратегии организации. Для них отдельные
проекты представляются как рядовые задачи и, присваивая им соответствующий приоритет, топ-
менеджеры тем самым обеспечивают доступ и распределение ресурсов. Этот подход позволяет
значительно ускорять реализацию важных приоритетных проектов в сравнении с фоновыми
проектами и проектами более низкого приоритета.
В целом СДР составляется в несколько проходов, несколькими итерациями, поскольку данные в
ней должны быть взаимосогласованны: объем доступных ресурсов, продолжительность работ,
оптимизация логических связей и т.д. определяются по мере уточнения обстоятельств
выполнения проекта и детального учета требований к нему.
Типичный пример СДР для ИТ проекта, в формате MS Project представлен на рис.3-11.

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

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

Инструменты и методы подтверждения содержания:


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

Выходные материалы процесса подтверждения содержания:


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

Контроль изменений содержания


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

Входные материалы для процесса контроля изменений содержания:


 СДР.
 Отчетность по эффективности выполнения проекта и текущему его состоянию.
 Запросы на внесение изменений.
 План управления содержанием. См. предыдущий раздел.

Инструменты и методы для контроля изменения содержания:


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

Выходные материалы контроля изменения содержания:


 Изменения содержания.
 Корректирующие воздействия.
 Извлеченные уроки.

84
Управление границами и изменениями

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


контролем исполнения.

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


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

Пример 1. Конфликт из-за нечетко определенных границ проекта.


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

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


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

85
Управление границами и изменениями

Управление внешними грани- Уточнение характеристик Внутреннее управление


цами и общими изменениями продукта границами
Входные материалы Входные материалы Входные материалы
1. Техническое задание 1. Техническое задание 1. Перечень работ
2. Положения договора или 2. Положения договора или 2. Ограничения
контракта контракта 3. Предположения
4. Фиксация функций членов
3. Сводный план проекта 3. СДР команды проекта
4. Отчетность по эффективности 4. Ограничения 5. Статистическая и архивная
выполнения проекта 5. Допущения информация
5. Запросы на внесение изменений Инструменты и методы
1. Оценка с использованием Инструменты и методы
Инструменты и методы аналога 4. Декомпозиция
1. Система контроля изменений 2. Моделирование 5. Анализ пула ресурсов
2. Управление конфигурацией 3. Заключение экспертов
6. Шаблоны
3. Оценка эффективности
Выходные материалы
4. Дополнительное планирование 1. Перечень дополнительных Выходные материалы
5. Информационная система работ
1. Уточненный регламент
управления проектами 2. Вспомогательные распределения людских
Выходные материалы материалы или доп. ресурсов
1. Обновления сводного плана соглашения
2. Матрица ответственности (С
2. Корректирующие воздействия 3. Обновления СДР Блок II)

Отслеживание и контроль границ и


изменений
Входные материалы
1. Базовый календарный план
2. Базовый ресурсный план
3. Текущий календарный план
4. Текущий ресурсный план
5. Отчеты выполнения проекта
6. Запросы на внесение изменений
7. Регламент внесения изменений

Инструменты и методы
1. Система контроля изменений
2. Оценки эффективности
3. Дополнительное планирование

Выходные материалы
1. Обновления графика
2. Корректирующие воздействия
3. Извлеченные уроки

Рис.3-12. Управление границами и изменениями проекта

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

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


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

Произвести Получить
Зарегистрировать Согласовать
оценку утверждение
запрос на изменение с
последствий Исполнителя на
изменение Заказчиком
изменения изменение
Решенный
Запрос на
изменение
Утвержденный запрос
на изменение
Периодический
анализ открытых
Контроль
запросов на
Рабочего плана
изменение

Рис. 3-13. Пример алгоритма работы с запросами на изменения

Управление внешними границами и общими изменениями


Управление изменениями включает в себя:

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

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


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

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


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

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


изменениями:
 Сводный план проекта. Содержит базовый план, относительно которого в
дальнейшем отсчитываются все изменения.
 Отчетность по эффективности выполнения проекта. Эти отчеты показывают
наличие/отсутствие отклонений от плана в текущем состоянии проекта и
позволяют проанализировать тенденции его дальнейшего продвижения и принять
превентивные меры, если будут обнаружены потенциальные проблемы.
 Запросы на внесение изменений. Могут быть представлены как в устной, так и в
письменной форме, инициированы как извне, так и изнутри проекта, а также могут
быть обязательными к исполнению или только рекомендательными (Рис.3-13).

88
Отчетность по Общее управление
эффективности изменениями;
выполнения контроль в
проекта изменениях УП

Процессы координации изменений

Контроль коррекций целей проекта


Контроль изменений содержания
Контроль изменений сроков
Контроль изменений затрат по ресурсам
Контроль стоимости
Контроль качества
Контроль изменения факторов риска
Управление изменениями в контрактах,
поставках и подрядах

Рис. 3-14. Координация изменений по всему проекту

Инструменты и методы для процесса общего управления изменениями (рис. 3-14):


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

89
 Управление конфигурацией. Часто управление конфигурацией является
подмножеством общей системы контроля изменений. К сфере управления
конфигурацией относятся:
 идентификация и документирование функциональных и/или физических
свойств разрабатываемого продукта;
 контроль всех изменений, вносимых в данный перечень;
 контроль соответствия продукта ранее сформулированным требованиям.
Иными словами управление конфигурацией – это определение необходимости изменения
архитектуры продукта проекта, внесение и отслеживание этих изменений.
 Оценка эффективности. Техника оценки эффективности выполнения проекта
(например, метод выполненной стоимости) помогает определить, в какой момент
требуются корректирующие воздействия, чтобы выправить отклонения от
первоначального плана. Обзор и анализ динамики изменений в проекте. Текущая
оценка изменений в проекте и достигнутых в связи с этим результатов. Отчет об
исполнении изменений в проекте и отклонениях от плана управления изменениями.
Предложения по корректировке плана изменений.
 Дополнительное планирование. Проекты чрезвычайно редко выполняются в
полном соответствии с первоначальным планом. Поэтому вносимые изменения
могут потребовать пересмотра оценки общих затрат, изменения
последовательности работ, дополнительного анализа альтернативных способов
реагирования на риски и прочих доработок плана проекта.
 Информационная система управления проектами (см. рис.3-49).

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


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

 Приобретенный опыт. Проведение постпроектного анализа, оценка изменений и


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

Управление проектом по временным параметрам

Задача управления временными параметрами формулируется как обеспечение


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

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

Определение состава работ


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

Входные материалы для процесса определения состава работ:


 Структурная декомпозиция работ.
 Свод содержания проекта.
 Статистическая и архивная информация.
 Ограничения.
 Допущения

Методы и инструменты для определения состава работ:


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

91
Управление по временным параметрам

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


последовательности работ работ
Входные материалы Входные материалы Входные материалы
СДР Перечень работ Перечень работ
Свод содержания Описание продукта Ограничения
Обязательные логические связи Предположения
Статистические и архивные данные Необязательные логические связи Потребности в ресурсах
Ограничения Внешние логические связи Характеристики ресурсов
Допущения Ограничения Статистическая и архивная
Допущения информация
Инструменты и методы
Инструменты и методы Инструменты и методы
Декомпозиция Диаграмма предшествования Заключение экспертов
Шаблоны Стрелочная диаграмма Оценка с использованием аналога
Выходные материалы Условные диаграммы Моделирование
Шаблоны сетевых моделей Выходные материалы
Перечень работ
Выходные материалы Оценки продолжительности работ
Вспомогательные материалы Сетевая модель проекта Базис оценок
Обновления СДР Обновления перечня работ Обновления перечня работ

Разработка графика Контроль выполнения графика


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

Рис. 3-15. Управление проектом по временным параметрам

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

Определение последовательности работ


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

Ветвь 1

Ветвь 2

Ветвь 3
Стартовое
Завершающее
ключевое
Ветвь 4 ключевое
событие
событие

Ветвь 5

Рис. 3-16. Представление планирования проекта по времени в виде параллельно идущих


блоков работ по схеме «гамак»

Входные материалы для процесса определения последовательности работ:


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

93
Инструменты и методы для процесса определения последовательности работ:
 Диаграмма предшествования. Представляет собой метод построения сетевой
модели проекта, в котором узлы обозначают отдельные работы, а стрелки между
ними – логические связи (рис. 3-17).
 Стрелочная диаграмма. Метод построения сетевой модели проекта, в котором
работы показываются стрелками, соединяющими события (рис. 3-18). В данном
методе используются только связи типа финиш-старт. Существует несколько типов
логических связей, отражаемых в сетевой модели проекта. Все они охватывают по
две работы, одну из которых будем называть работой-предшественником, а другую
– работой-последователем (рис. 3-19).
 Диаграммы, построенные с помощью условных методов. Функциональные аналоги
описанных выше диаграмм, но, например, допускающие введение циклов.
 Шаблоны сетевых моделей. Для описания многих проектов могут быть
использованы шаблонные сетевые модели с минимальными модификациями.
Шаблон может описывать весь проект или только какую-либо его компоненту. Это
особенно полезно в проектах, содержащих несколько близких по своей природе
компонент.

A B C

Начало Конец

D E F

Рис. 3-17. Пример диаграммы предшествования.

94
Начало B

A C

Конец

D
F
E

Рис. 3-18. Пример стрелочной диаграммы

Финиш-Старт. Наиболее часто используемый тип связи.


Последователь не может начаться раньше завершения
предшественника.
Финиш-Финиш. Последователь не может завершиться раньше
завершения предшественника.
Старт-Старт. Последователь не может начаться раньше начала
предшественника.
Старт-Финиш. Последователь не может завершиться до начала
предшественника.

Рис. 3-19. Логические связи между двумя работами

Детально расписанная диаграмма «гамак» представляет собой сетевую диаграмму -


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

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

Критический путь
Начало работ

Завершение работ
Свободный резерв

Рис. 3-20. Фрагмент сетевой диаграммы

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


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

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

Выходные материалы процесса определения последовательности работ:


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

Рис. 3-21. Фрагмент диаграммы Гантта

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

На данном этапе производится оценка продолжительности каждой из работ описанными


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

Инструменты и методы для оценки продолжительности работ:


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

Выходные материалы процесса оценки продолжительности работ:


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

Разработка графика (расписания) проекта


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

Входные материалы для процесса разработки графика:


 Сетевая модель проекта.
 Оценки продолжительностей работ.
 Потребности в ресурсах.
 Описание пула ресурсов. Информация о том, какие ресурсы, с какими
навыками/свойствами доступны, в какое время и в каком количестве.
 Календари. Содержат информацию о продолжительности рабочего дня, недели,
количестве рабочих смен, а также о нерабочих периодах (государственные

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

Инструменты и методы для разработки графика проекта:


 Математические методы. Диаграмма Гантта и др. методы.
 Программное обеспечение, реализующее данные методы.

Выходные материалы для процесса разработки графика проекта:


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

Контроль выполнения графика


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

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


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

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


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

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

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


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

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

Управление стоимостью проекта включает процессы, целью которых является завершение


проекта в рамках запланированного и утвержденного бюджета. К таким процессам
относят:
Планирование ресурсов – определение того, какие ресурсы (люди, материалы,
оборудование) и в каком количестве будут использованы в проекте.
Оценка затрат – приблизительная оценка затрат на ресурсы, требуемые для выполнения
проекта.
Составление бюджета – расчет затрат по каждой из работ проекта, исходя из требуемых
для нее ресурсов.
Контроль затрат – контроль изменений в бюджете проекта.
Обзор процессов данной группы приведен на рис. 3-22.
Управление стоимостью отличается от управления финансами. Управление стоимостью
включает оптимизацию затрат по всем составляющим проекта исходя из требований
получения максимума возврата инвестиций в проект (ROI – Return on Investment):
коэффициента, характеризующего, сколько копеек прибыли мы получим по завершении
проекта на каждый вложенный в него рубль). Управление финансами имеет предметом
реализацию стоимостных, финансовых оценок по составляющим проекта, полученным в
результате процессов управления стоимостью. Управление стоимостью – это область
аналитической экономики, управление финансами – финансово-бухгалтерского учета.

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

Планирование ресурсов Оценка затрат

Входные материалы Входные материалы


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

Составление бюджета Контроль затрат


Входные материалы Входные материалы
Оценки затрат Базовый план затрат
СДР Отчетность по эффективности выполнения
График (расписание) проекта проекта
Инструменты и методы Запросы на внесение изменений
Методы и инструменты оценки затрат План управления затратами
Выходные материалы
Инструменты и методы
Базовый план затрат
Система контроля изменений затрат
Оценки эффективности
Дополнительное планирование
Программные средства
Выходные материалы
Уточненные оценки затрат
Обновления бюджета
Корректирующие воздействия
Оценка затрат по завершении проекта
Извлеченные уроки

Рис. 3-22. Управление стоимостью проекта

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

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

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

Составление бюджета проекта


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

103
Здесь же в качестве примера рассмотрим построение диаграммы движения денежных
средств. Этот инструмент относится к области анализа финансовой эффективности
проекта.
Диаграмма движения денежных средств представляет собой график, на котором для
каждого отчетного периода нарастающим итогом указывается сумма расходов на проект и
поступлений от него. Расходы мы будем откладывать вниз, а поступления вверх.
Предположим, имеется проект по разработке заказного программного обеспечения,
рассчитанный на 6 месяцев. Запланированные размеры расходов/поступлений приведены
в таблице 3-2.

Таблица 3-2.
Период Янв. 05 Фев. 05 Март 05 Апр. 05 Май 05 Июнь 05
Расход 2 3 5 5 3 2
Приход 0 0 3 3 10 15

Цифры указаны в тысячах долларов. Тогда график движения денежных средств можно
представить в виде, изображенном на рис. 3-23. Из этого графика видно, что на начальном
этапе проекта исполнитель вынужден вкладывать в разработку собственные средства и
поступление платежей от заказчика начинается только после сдачи некоторых
промежуточных этапов, а прибыль появляется только после окончательного расчета. Для
простоты на данном графике не указаны затраты/поступления, связанные с эксплуатацией
и технической поддержкой разработанного продукта.
Одним из наиболее важных показателей при финансовом анализе проекта является точка
безубыточности. По определению это объем продаж, при котором выручка от реализации
продукции совпадает с издержками производства. На диаграмме движения денежных
средств эта точка является пересечением суммарного графика с осью абсцисс. В
стоимостном выражении точка безубыточности определяется по формуле:
Tmin = Cпост/(1-Cперем/V), где:
Cпост – постоянные издержки, не зависящие от объема производства (амортизация и
аренда здания, заработная плата управленческого персонала и пр.).
Cперем - переменные издержки, зависящие от объема производства (сырье, материалы,
заработная плата производственного персонала, торговые издержки и пр.).
V – объем продаж в стоимостном выражении.
В натуральном выражении количество единиц проданных товаров в точке безубыточности
равно:
Qmin = Тmin / Цена единицы продукции.

ЯНВ. ФЕВ. МАРТ АПР. МАЙ


ИЮНЬ

10

10

Рис. 3-23. Пример диаграммы движения денежных средств

104
Экономическая реализуемость необходима для определения продолжительности проекта,
которая соответствует минимальной стоимости. Вполне возможно, что анализ
экономической реализуемости (исполнения бюджета) будет проводиться при
определенных ограничениях на ресурсы. Довольно часто уровень используемых ресурсов
или длительность ограничены сверху. Хотя процедуры проверки ресурсной,
экономической и финансовой реализуемости аналогичны, различные ограничения по-
разному определяют область, в которой проводятся исследования различных
длительностей и стоимостей выполнения проекта.
Если в проекте будут использоваться только собственные трудовые ресурсы, то можно
составить расписание их использования, чтобы определить, можно ли таким путем
обеспечить выполнение проекта. Аналогично можно составить расписание затрат, чтобы
убедиться, что намеченные закупки могут быть осуществлены и что материалы будут
поставлены в нужные сроки.
При определении продолжительности выполнения, соответствующей минимальной
стоимости, следует провести окончательную проверку финансовой реализуемости. Для
этого менеджер проводит анализ денежных потоков для определения проекта при
установленных общих затратах и выбранной длительности выполнения проекта. Выходом
анализа денежных потоков является планирование по отчетным периодам (квартальные,
месячные, полумесячные) всех финансовых операций и их конечный эффект.
Если план-график реализации проекта проходит через эти виды оценок, то проект,
которому он соответствует, обеспечен всеми требуемыми ресурсами и выполнение его по
этому плану более экономично, чем по любому другому (рис. 3-24).

Составление бюджета

Выполнение бюджета

Сравнение фактических затрат


Принятие мер Пересмотр
по выполнению бюджета
бюджета Определение отклонений

Бюджет реален

Рис. 3-24. Схема анализа реализуемости плана-графика и бюджета проекта

105
Рис. 3-25. Представление бюджета проекта в MS Project

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


 Бюджет проекта. Таблица (рис. 3-25) или график распределения затрат по
проекту на протяжении всего его жизненного цикла. Этот график мы будем
называть базовым и по отношению к нему отсчитывать отклонения фактических
затрат. Для больших проектов бывает целесообразно пересматривать базовый план
затрат в соответствии с фактическим ходом дел.

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

Входные материалы для процесса контроля затрат:


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

106
и, в частности, на отчетности с отслеживанием движения денежных средств (cash
flow, рис.3-23). Является подмножеством общей системы управления изменениями
в проекте.
 Анализ эффективности выполнения проекта. Эффективность выполнения проекта
оценивается путем постоянного контроля нескольких показателей эффективности.
 Дополнительное планирование.
 Программные средства.

Методика выполненной стоимости


Рассмотрим пример использования методики выполненной стоимости (Earned Value). Это
методика предлагает около 25 параметров эффективности выполнения проекта.
Рассмотрим наиболее важные из них:
Плановая стоимость плановых работ/Budget Cost of Work Scheduled (ПСПР/BCWS). Как
и все рассматриваемые ниже параметры, рассчитывается для отдельных работ, узлов WBS
и всего проекта в целом. Представляет собой сумму затрат по вовлеченным ресурсам,
рассчитанную исходя из плановой продолжительности работы и плановых потребностей в
ресурсах, плюс плановые прямые затраты, не связанные с ресурсами.
Плановая стоимость выполненных работ/Budget Cost of Work Performed (ПСВР/BCWP).
Представляет собой денежное выражение процента выполнения и рассчитывается как
произведение процента выполнения работы и ПСПР (BCWS).
Фактическая стоимость выполненных работ/Actual Cost of Work Performed
(ФСВР/ACWP). Представляет собой сумму затрат по вовлеченным ресурсам,
рассчитанную исходя из фактической продолжительности работы и фактических
потребностей в ресурсах, плюс фактические прямые затраты, не связанные с ресурсами.
Затраты
ФСВР (АCWP)
ОДЗ
(ETC)

ОЗ=ПСВР-ФСВР
(CV=BCWP-ACWP)
ПСПР (BCWS)

ОГ=ПСВР-ПСПР
(SV=BCWP-BCWS)

ПСВР (BCWP) Время

Текущая дата
Дата завершения проекта

Рис. 3-26. Методика выполненной стоимости

107
Начало работ по проекту
Оценка до завершения/Estimate to Complete (ОДЗ/ETC). Оценка затрат, необходимых для
выполнения незавершенной части отдельной работы, узла WBS или всего проекта в
целом.
Оценка по завершении/Estimate at Complete (ОПЗ/EAC). Прогноз общих затрат по проекту,
исходя из анализа эффективности выполненной части. Методы расчета см. выше в
предыдущем разделе.
Отклонение по затратам/Cost Variance (ОЗ/CV). Разность ПСВР-ФСВР (BCWP-ACWP).
Отклонение от графика/Schedule Variance (ОГ/SV). Разность ПСВР-ПСПР (BCWP-
BCWS).
Индекс эффективности расходов/Cost Performance Index (ИЭР/CPI). Отношение
ПСВР/ФСВР (BCWP/ACWP).
Индекс эффективности графика/Schedule Performance Index (ИЭГ/SPI). Отношение
ПСВР/ПСПР (BCWP/BCWS).
Как правило, при расчете всех приведенных выше параметров предполагают, что как
ресурсные, так и прямые затраты по каждой из работ равномерно распределены по ее
продолжительности и пропорциональны проценту выполнения. Последние версии
программных средств, как правило, могут учитывать как ситуацию 100% предоплаты, так
и ситуацию оплаты по завершении работ. Соотношение перечисленных параметров
показано на рис. 3-26.
Пусть имеется проект строительства десятиэтажного дома. Для простоты примем, что
затраты на строительство каждого этажа одинаковы, а затраты на работы нулевого цикла
равномерно распределены между затратами на каждый этаж. Будем также считать, что
затраты распределены во времени линейно, пропорционально проценту выполнения
работ. Плановый срок строительства – 20 дней, плановые затраты $100.000, по $10.000 на
каждый этаж.
Прошло 10 дней и выяснилось, что фактические затраты составили 65.000$. Таким
образом, на текущий момент (10-й день строительства):
ФСВР=$65.000, ПСПР=$50.000 и ОЗ= -$15.000
Можно ли на основе этой информации сделать окончательный вывод об эффективности
выполнения проекта? Нет, т.к. не известно, какой объем работ был выполнен, т.е. сколько
было построено этажей. Предположим, что было построено 4 этажа, т.е. процент
выполнения составляет 40%. Значит,
ПСВР=0.4х$100.000=$40.000 и ОГ=$40.000-$50.000= -$10.000
Т.е. в данном случае имеется перерасход бюджета на $15.000 с одной стороны и
отставание по объемам работ с другой. Ситуация требует срочного принятия мер и
проведения расследования причин перерасхода.
Предположим теперь, что построено было 6 этажей, т.е. процент выполнения составляет
60%. Тогда,
ПСВР=0.6х$100.000=$60.000 и ОГ=$60.000-$50.000=$10.000
В этом случае перерасход бюджета частично компенсируется опережением по
выполненному объему работ. Это может быть оправдано, если по каким-то причинам
время стало наиболее значимым фактором и строительная компания готова мириться с
дополнительными затратами (в данном случае $5.000). На рис. 3-26 двум рассмотренным
случаям соответствуют две кривые ПСВР: пунктирная – первому варианту, точечная –
второму варианту.

Анализ эффективности проекта с точки зрения инвестиций, как правило, включает в себя
оценку коэффициента возврата инвестиций ROI (Return on Investment), чистого
дисконтного дохода (иногда его называют чистый приведенный доход), ЧДД (NPV, Net
Present Value), внутреннего индекса доходности, ИД (IRR, Internal Rate of Return).

108
NPV вычисляется по формуле: Т
NPV =  (Rt – 3t)х(1/(1+E)t )
t=o
где Rt— результаты, достигаемые на t-м шаге расчета,
3t— затраты, осуществляемые на том же шаге,
Т — продолжительность расчетного периода. Он равен номеру шага расчета, на
котором производится закрытие проекта. Шаг может быть месячный, квартальный или
годовой.
Е — постоянная норма дисконтирования, равная приемлемой норме дохода на
капитал и не может быть ниже коэффициента инфляции.
Если NPV инвестиционного проекта положителен, проект является эффективным (при
данной норме дисконта) и может рассматриваться вопрос о его принятии. Чем больше
NPV, тем эффективнее проект. Если инвестиционный проект начнет осуществляться при
отрицательном NPV, проект будет неэффективен.
На практике часто пользуются модифицированной формулой для определения NPV. Для
этого из состава 3t, исключают капитальные вложения и через 3 t+ обозначают затраты на
t-м шаге при условии, что в них не входят капиталовложения. Тогда:
T
NPV =  (Rt – 3t+)х(1/(1+E)t ) - К
t=o
где К — сумма дисконтированных капиталовложений.
Модифицированный показатель NPV выражает разницу между суммой приведенных
эффектов и приведенной к тому же моменту времени величиной капитальных вложений
(К).
IRR представляет собой отношение суммы приведенных эффектов (результат – затраты) к
величине капиталовложений:
1 Т
IRR =   (Rt – 3t+)х (1/(1+E)t )
К t=o
Индекс доходности тесно связан с NPV: если NPV положителен, то IRR >1 и наоборот.
Если IRR >1, проект эффективен, если IRR <1 — неэффективен.

Коэффициент возврата инвестиций (в процентах) вычисляется по формуле:


ROI = (прибыль / затраты) х 100
Или
ROI = [NPV/ Общий план финансирования/(1+Е)] х 100.
Коэффициент возврата инвестиций ROI показывает сколько центов прибыли будет
получено в результате реализации проекта на каждый, вложенный в проект доллар
инвестиций.

Выходные материалы процесса контроля затрат:


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

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

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


посредством общего управления качеством проекта. Под качеством продукта мы будем
понимать совокупность характеристик объекта (продуктов проекта), относящихся к его
способности удовлетворять установленные и предполагаемые потребности (определение
Международной Организации по Стандартам ИСО). Основные стандарты в области
качества устанавливаются стандартами ИСО серий 9000 и 10000. Цель процессов
управления качеством – не только и не столько контроль качества, но обеспечение
качества.
Управление качеством включает в себя три процесса:
Планирование качества – выбор стандартов качества, которым должен удовлетворять
проект.
Обеспечение качества – регулярная оценка эффективности выполнения проекта и
выделение параметров эффективности, характеризующих качество проекта.
Контроль качества – контроль результатов проекта на предмет их соответствия
выбранным стандартам качества, а также идентификация путей повышения
эффективности выполнения проекта (рис. 3-27).

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

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

Планирование качества Обеспечение качества Контроль качества

Входные материалы Входные материалы Входные материалы


Политика предприятия в области План управления качеством Результаты работ
качества План управления качеством
Оценки качества, полученные в ходе
Свод содержания проекта контрольных мероприятий Операционные определения
Описание продукта Контрольные листки
Инструменты и методы
Стандарты и правила Инструменты и методы Инструменты и методы
Выходные материалы других планирования качества Инспекция
процессов Аудит качества Контрольные диаграммы
Инструменты и методы
Выходные материалы Диаграммы Парето
Анализ выгод/затрат
Мероприятия по Выборочный контроль
Сравнительный анализ проектов совершенствованию качества Методы построения прочих
Методы построения диаграмм диаграмм
Анализ чувствительности Анализ тенденций
Выходные материалы Выходные материалы
План управления качеством Мероприятия по
Операционные определения совершенствованию качества
Контрольные листки Решения об утверждении
Выходные материалы Доработки
других процессов Заполненные контрольные
листки
Корректировка процессов

Рис. 3-27. Управление качеством проекта

Инструменты и методы для управления качеством:


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

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

стоимость

оптимальное время
и стоимость

min
накладные
расходы

качество

прямые
расходы

Рис. 3-28. Оптимизация качества, продолжительности и стоимости проекта

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

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

113
 Выборочный контроль. Данные методики предусматривают проведение инспекций
не всех объектов, а только тех, которые попали в выборку. Зачастую это позволяет
снизить затраты на проведение процесса контроля качества.
 Методы построения диаграмм.
 Анализ тенденций. Используется математический аппарат, позволяющий строить
прогнозы о дальнейшем развитии проекта на основе анализа его выполненной
части, а также выполненных ранее проектов-аналогов.
Выходные материалы процесса контроля качества:
 Мероприятия по совершенствованию качества.
 Решения об утверждении. Продукты, подвергнутые инспекции, могут быть
приняты или признаны непригодными (в этом случае потребуется доработка).
 Доработки. Это действия, направленные на то, чтобы довести продукт,
признанный не удовлетворяющим всем требованиям, до достаточного уровня
качества. Доработки, особенно неожиданные, являются одной из основных причин
перерасхода бюджета проекта и срыва сроков. Поэтому одной из основных задач
управления качеством является снижение количества доработок.
 Заполненные контрольные листки. Будучи заполнены и проанализированы,
контрольные листки становятся частью архива проекта и могут быть использованы
в дальнейшем в работах по сходным проектам.
 Корректировки бизнес-процессов. При необходимости по результатам контроля
качества могут быть внесены изменения в некоторые бизнес-процессы. Эти
изменения осуществляются в соответствии с принятой в проекте системой
управления изменениями.
В целом упорядоченное управление качеством проекта осуществляется через систему
управления качеством предприятия.

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

Управление рисками включает процессы, направленные на идентификацию рисков, их


анализ и реагирование. Целью является извлечение максимально большей выгоды из
событий, положительно влияющих на проект, и минимизация последствий событий,
влияющих на проект отрицательно. Риски могут быть связаны как с положительными
последствиями, так и с отрицательными. Однако все риски можно привести к
отрицательным, если положительные последствия рисков отнести к запланированным
возможностям. Поэтому далее будем рассматривать риски с отрицательными
последствиями.
Что такое риски проекта? Это потери, которые можно понести либо в результате,
либо в процессе какой-либо деятельности.
Часто на практике «интуитивно» под риском понимают следующее:
• Вероятность отклонения хода проекта от рассчитанного и понесенные в результате
этого отклонения убытки.
• Дисперсию (меру рассеяния) полученных в результате множественного прогноза
оценочных показателей рассматриваемого проекта (прибыль, рентабельность
капитала и т.п.).
• Опасность того, что цели проекта не будут достигнуты в полном объеме, а
полученные результаты могут оказаться хуже запланированных (при этом, как
правило, имеют в виду конкретные показатели – такие как прибыль или срок
окупаемости и т.п.).

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

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

116
 Риск связан с какой-либо деятельностью и принятием управленческих решений.

117
 Риск в количественном измерении является величиной размерной, т.е.
количественно риск может измеряться в деньгах, тоннах и т.д.

118
 Риск – величина вероятностная.

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

120
Выделяются следующие основные процессы:

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

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

Идентификация рисков Количественная оценка рисков

Входные материалы Входные материалы


Чувствительность к рискам ключевых участников
Описание продукта
Источники риска
Выходные материалы других процессов Рисковые события
планирования
Оценки затрат
Статистическая и архивная информация Оценки продолжительности работ
Инструменты и методы Инструменты и методы
Контрольные листы Ожидаемый финансовый эффект
Диаграммы Моделирование
Деревья решений
Интервью
Заключения экспертов
Выходные материалы Программные средства
Источники риска Выходные материалы
Рисковые события Перечень значимых угроз и перспективных
возможностей
Симптомы рисков
Перечень малоперспективных возможностей и
Входные материалы для других процессов игнорируемых рисков

Разработка методов реагирования Контроль реагирования

Входные материалы Входные материалы


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

124
Рис. 3-29. Управление рисками проекта
Количественная оценка рисков – оценка рисков с точки зрения размеров потенциальных
потерь для проекта.
Разработка методов реагирования – определение последовательностей действий,
позволяющих использовать позитивные возможности и противостоять угрозам.
Контроль реагирования – реагирование на изменения в факторах риска на протяжении
жизненного цикла проекта.
Обзор процессов управления рисками приведен на рис. 3-29.
В разных предметных областях существуют различные нюансы в трактовке приведенных
здесь терминов. Например:
 Процессы идентификации рисков и их количественной оценки часто рассматриваются
как один процесс, называемый анализом или оценкой рисков.
 Процессы разработки методов реагирования и контроля реагирования также часто
рассматриваются как один процесс под названием «управление рисками».

ВЕРОЯТНОСТЬ
СЛУЧАЙНОЕ
СОБЫТИЕ РИСК ПОЯВЛЕНИЯ
СЛУЧАЙНЫХ СОБЫТИЙ

РАЗМЕР УЩЕРБА
РЕШЕНИЯ НАБЛЮДАЕ-
МЫЕ
ПАРАМЕТРЫ
ПРОЦЕССА

Рис. 3-30. Факторы окружения проекта

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

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

Таблица 3-3.
Интегральное Мероприятия по
Рисковое Вероятность Степень влияния Результаты
№ события
влияние на минимизации отрицат
событие на процесс проекта результаты проекта последствий План | Факт

Концептуальна
Предусмотреть в
я ошибка в
проекте создание
1 разработке 0.2 0.95 0.19 модели (пилота)
нового
нового элемента
элемента
Неприятие Провести
коллективом производственные
2
новых 0.7 0.1 0.07 собрания,
технологий семинары

Неподготовленн Предусмотреть
соответствующие
3 ость рынка 0.3 0.5 0.15 затраты на маркетинг и
сбыта фьючерские сделки

Принять на работу
Проблемы
юриста, спец. в
4 поставок западных
комплектующих
0.6 0.4 0.24 таможенном
законодательстве

Увеличить долю
Задержка
авансовых
5 финансирова- 0.1 0.9 0.09 платежей и фин.
ния
резервов

Причем в некоторых работах риск может отсутствовать, а в некоторых может быть


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

126
Р И С К И

внешние внутренние

непредсказуемые
(непредвиденные)
технологические нетехнологические

предсказуемые
(прогнозируемые)

юридические

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

персонала

Рис. 3-31. Классификация рисков

Входные материалы для процесса идентификации рисков:


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

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

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


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

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

ФАЗЫ ПРОВЕДЕНИЯ ПРОЕКТА


Начальная фаза Фаза разработки Фаза реализации Фаза завершения

Общий проектный
риск

РИСК
фин. потери
И Возможные
Сумма возможных
финансовых
потерь

Рис. 3-33. Общая оценка рисков, выраженная в денежном эквиваленте, и возможные


финансовые потери в зависимости от фазы жизненного цикла проекта

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


 Чувствительность к рискам ключевых участников. Различные организации и
различные лица обладают разной чувствительностью к рискам. Например:
 Крупная, высокоприбыльная компания может себе позволить потратить
$500.000 на подготовку детального предложения по контракту ценой в 1
миллиард долларов, принимая во внимание риск того, что контракт так и не
будет подписан. Для мелкой компании потеря такой суммы может означать
банкротство.
 Одна компания может интерпретировать вероятность в 15% перерасхода
бюджета как высокий уровень риска, а другая – как приемлемый.
 Источники рисков. См. предыдущий раздел.
 Рисковые события. См. предыдущий раздел.
 Оценки затрат.
 Оценки продолжительности работ.

129
Инструменты и методы для количественного анализа риска:
 Ожидаемый финансовый эффект. Данный параметр рассчитывается как
произведение двух величин:
 оценки вероятности данного рискового события;
 ожидаемых в результате этого события потерь или выгод в денежном
выражении.
 Моделирование. Эффективность проекта анализируется с помощью
математических моделей. Используются различные варианты метода Монте-Карло.
 Деревья решений. Представляют собой диаграммы, отражающие различные
варианты принимаемых решений и возможные рисковые события, связанные с
каждым из решений.
 Заключения экспертов.
Выходные материалы процесса количественной оценки рисков:
 Перечень значимых угроз и перспективных возможностей. Основным результатом
процесса количественной оценки рисков является перечень перспективных
возможностей и угроз, требующих внимания.
 Перечень малоперспективных возможностей и игнорируемых угроз. Также в
результате процесса количественной оценки рисков выявляются источники рисков
и рисковые события, а также лица, принимающие решения по выбору методов
реагирования.
После отождествления рисковых событий (вторая колонка таблицы 3-3), оценивается
вероятность того, что данное событие в принципе наступит (третья колонка) и степень
влияния на процесс проекта, который затрагивает данное рисковое событие (четвертая
колонка). Например, в проекте создания нового типа автомобиля, в двигателе
присутствует разработка инжектора принципиально новой конструкции. Эксперты дают
оценку вероятности нештатной работы (неудачи) нового инжектора в 20% (0.2). Но если
это случится (инжектор не будет работать штатно), то с высокой вероятностью (95%)
двигатель будет неработоспособен. Обще же влияние на проект в целом равно
произведению вероятности события на степень его влияния на процесс проекта:
0.20 х 0.95 = 0.19 (пятая колонка Таблицы 3-3)
При анализе рисковых событий все качественные оценки стараются переводить в
количественные. И более того, все количественные оценки затем приводят в единую
шкалу, например в финансовую. Все величины оценок рисков можно перевести в
финансовый эквивалент. Например, в данном случае, если реализуется рисковое событие,
связанное с ошибкой в разработке инжектора и отказе в работе двигателя, при бюджете
проекта в $100 000 величина финансового эффекта будет: 100 000 х 0.19 = $19 000.
На рисунке 3-34 приведен пример количественной оценки рисковых событий методом
ожидаемого финансового эффекта (Expected Monetary Value – EV).

Ранжирование рисков.
Список рисков может быть очень большим, и если реагировать на все риски, то никаких
средств и ресурсов на это не хватит. Естественно, в этом случае выбирают только
наиболее значимые и важные, для чего проводится ранжирование рисков по их основным
количественным показателям, например, таким как интегральное влияние на результат
проекта, финансовый эффект от рискового события.
Для корректного ранжирования рисков по степени интегрального влияния на результат
проекта, все величины этого параметра (пятая колонка таблицы 3-3) суммируются и
нормируются (приравниваются) на 100%. Затем каждая из величин по отдельному риску
пересчитывается в предположении (нормировке), что их сумма равна 100%.
После этого можно приступить к собственно процедурам ранжирования. Одним из
распространенных методов ранжирования рисков (и проблем в целом) является метод

130
Парето. Метод Парето заключается в том, что ранжирование идет от самого значимого
риска или причины риска (проблемы) до минимального. Строится диаграмма (рис. 3-35),
на которой все риски откладываются в порядке их интегрального влияния на результат
проекта. Эта диаграмма (ее называют диаграммой Парето) может строиться в
дифференциальном виде (нижняя ступенчатая диаграмма), в которой количественная
оценка риска отмечается отдельно по каждому риску (причине), и интегральном
(кумулятивном) виде, когда каждая последующая величина риска суммируется с
предыдущей (верхняя кривая). Слева на оси ординат отмечена ненормированная степень
влияния (доля риска в общем составе рисков), справа – нормированная на 100%.

131
Рис. 3-34. Метод оценки ожидаемого финансового эффекта
(Expected Monetary Value - EV)
Иллюстрация соотношения источников риска, рисковых событий и принимаемых решений

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

Источник 1 Событие 1 Решение 1 EV=$3000

Событие 1 Решение 2 EV=$4000

ытие 1
Событие 2 Решение 3 EV=$2000

Источник 2 Событие 3 Решение 4 EV=$15000

Решение 5 EV=$18000

Решение 6 EV=$12000

Событие 4 Решение 7 EV=$2500

Решение 1 EV=$4000

проблем проектов. Метод Парето очень удобен в ранжировании и анализе рисков:


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

132
Рис. 3-35. Диаграмма Парето

Еще одним распространенным и удобным методом ранжирования и анализа рисков


является метод Ишикава. Суть метода заключена в том, что вы берете в относительном
масштабе (например, на листе бумаги формата А4) и откладываете в виде стрелки
анализируемую проблему. При этом длина стрелки соответствует общему эффекту этой
проблемы (величины влияния на результат проекта). Затем в том же масштабе
откладываете по сторонам от центральной стрелы стрелки (обычно под углом 45º ),
соответствующие декомпозированным подпроблемам, составляющим основную
проблему. Причем величина стрелки подпроблемы в данном относительном масштабе
соответствует величине в пятой колонке таблицы 3-3. Далее каждую подпроблему можно
декомпозировать на следующий уровень субпроблем. В результате получится диаграмма,
похожая на скелет рыбы (иногда ее так и называют диаграмма «скелет рыбы»), или
диаграмма Ишикава. Диаграмма Ишикава очень удобна при ранжировании проблем – на
ней сразу видны в относительном масштабе основные проблемы и из чего они состоят.

133
Рис. 3-36. Диаграмма Ишикава («скелет рыбы»)

Разработка методов реагирования


В анализе рисков важным элементом является осознанное ограничение реагирования на
риски. Эти ограничения можно эффективно применять, только тогда, когда уже проведено
ранжирование и становится ясно, какие риски большие, какие маленькие. Например, во
многих организациях считается, что необходимо рассматривать в дальнейшем анализе
риски, величина влияния которых на конечный результат проекта превышает 1%
(например, 1% от бюджета проекта – предел реагирования). Причем анализ и
ранжирование рисков может проходить в две итерации. Первая итерация заканчивается
предложением по мероприятиям, минимизирующим отрицательные последствия
рискового события (шестая колонка таблицы 3-3) и оценкой влияния этого риска после
применения планового мероприятия (седьмая колонка таблицы 3-3 = «План»). После этого
проводится повторное ранжирование, но уже по данным седьмой колонки Таблицы 3-3,
столбец «План». И затем возможно вычленение дополнительных значимых рисков,
определение мероприятий по минимизации отрицательных последствий этих рисков.
Разработанные мероприятия по минимизации отрицательных последствий рисковых
событий заносятся в СДР и с ними работают, как и с другими работами (задачами)
проекта. Естественно, для осуществления этих мероприятий необходимы ресурсы. Это
обстоятельство четко диктует условия по времени и глубине проработки рисков и их
анализу: как правило, это должно проводиться в фазе инициации, а СДР должна
корректироваться на предмет введения в нее работ и задач минимизации рисков еще до
утверждения приказа на открытие проекта. Важным элементом управления рисками

134
является анализ результатов выполненного проекта (при составлении Сводного отчета по
проекту). Во время этих аналитических работ заполняется последний столбец таблицы
рисков (столбец «Факт», таблица 3-3), в который заносятся фактические данные в
выполненном проекте по оценке проведенного мероприятия, минимизирующего рисковое
событие. Таблица рисков может входить как составная часть в Устав проекта или как
отдельный самостоятельный документ в приложении к приказу на открытие проекта.

До этого мы говорили в основном о рисках по предметной части проекта. Риски


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

К+1
23

К
1
К+112
К-1

К+121

К
К+122
2

К+1
23

Рис. 3-37. Дерево принятия решений. Альтернатива

Если из текущего состояния можно перейти только в два, причем если р – вероятность
перехода в одно, а 1-р – вероятность перехода в другое, то такое состояние называется
простой лотереей. Простейший вариант дерева решений – лотерея, когда в зависимости
от решения р принимает только два значения: 0 или 1 (рис. 3-38).

135
К1
p(d(x))

К-1

1-p(d(x)) К2
d(x)

Рис. 3-38. Дерево принятия решений. Простая лотерея

Чем сложнее поставленная задача, тем сложнее процесс выстраивания дерева. Дерево
решений имеет несколько вариантов решений, выведенных в конце, из которых
менеджер проекта должен выбрать наиболее подходящее с точки зрения рисков и
эффективности проекта (прибыли) оптимальное решение. Технологически построение
подобной диаграммы состоит из трех этапов:
 строится последовательная цепочка слева направо, включая все
результирующие пункты и все точки выбора (принятия решений).
 затем описываются все альтернативны и лотереи.
 и, наконец, добавляются все вероятностные значения в лотереи.
Пример определения рисков управления методом построения дерева решений показан на
рис. 3-39 . Из рисунка видно, что максимальный риск находится на пути решений BD, и он
равен 42%, минимальный риск при выборе решения AD, и он равен 8%.
Таким образом, метод, базирующийся на использовании дерева решений, позволяет
моделировать динамику развития процесса и проанализировать последствия возможных
решений. Необходимо подчеркнуть возможности использования метода дерева решений в
процессе реализации проекта. Изменившиеся обстоятельства внешней среды проекта
могут вынудить менеджера, принимающего решение, отклониться от избранной
оптимальной траектории. Наличие построенной «пошаговой» схемы в виде дерева
решений позволит менеджеру рассчитать риск такого развития событий и минимизировать
в конечном счете убытки.

136
Итоговая вероятность
АС = (0,40) х (0,80) = 0,32
Действие С 80%

Вероятность риска А
40% АD = (0,40) х (0,20) = 0,08

Действие D 20%

Действие С 30%
BC = (0,60) х (0,30) = 0,18

Вероятность риска В
60%

BD = (0,60) х (0,70) = 0,42


Действие D 70%

Рис. 3-39. Пример определения рисков выбора решения методом построения

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


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

Методы реагирования на риски могут быть следующие:


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

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

ПРЕДОТВРАЩЕНИЕ

СОКРАЩЕНИЕ
МЕТОДЫ
РЕАГИРОВАНИЯ НА
РИСКИ
ПРЕДПОЛОЖЕНИЕ

ПЕРЕДАЧА

ЗНАНИЕ И ИЗУЧЕНИЕ

Рис. 3-40. Классификация методов реагирования на риски

Естественно, за это надо платить: обычно генподрядчик требует значительного


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

138
На Западе страхование проекта или его отдельных задач – явление весьма
распространенное. Этот метод минимизации рисков постепенно приживается и в России.
В целом риски можно разделить на страхуемые и нестрахуемые.

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

Форс-мажорные (нестрахуемые) риски:


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

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


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

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


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

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

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

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

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

Управление человеческими ресурсами включает в себя процессы, направленные на


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

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


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

141
 Набор персонала. Включает набор людских ресурсов, требуемых для выполнения
проекта, как извне, так и из различных подразделений компании.
 Формирование и развитие команды проекта. Включает развитие индивидуальных и
групповых навыков, важных для роста эффективности выполнения проекта (рис. 3-41).

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

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

Организационное Набор персонала Формирование


планирование и развитие команды
Входные материалы Входные материалы Входные материалы
Интерфейсы проекта План подбора персонала Персонал, занятый в проекте
Требования к набираемому Описание подбираемого пула Сводный план проекта
персоналу ресурсов План подбора персонала
Ограничения Отчетность по эффективности
Практика найма Внешние отзывы
Инструменты и методы
Инструменты и методы Инструменты и методы
Шаблоны Переговоры
Правила работы с персоналом Деятельность по построению
Предварительное назначение команды
Организационные теории
Временное привлечение людских Навыки общего менеджмента
Анализ ключевых участников ресурсов извне Система мотивации персонала
Выходные материалы
Выходные материалы Совместное размещение
Распределение ролей и
Назначение персонала на проект Обучение
ответственностей
План подбора персонала База данных по персоналу проекта Выходные материалы
Организационная структура Рост эффективности работы
каждого сотрудника
Вспомогательные материалы
Входные материалы для
проведения аттестации

Рис. 3-41. Управление человеческими ресурсами в проекте

142
Входные материалы для процесса организационного планирования:
 Интерфейсы проекта. Обычно попадают в одну из следующих категорий:
 Организационные интерфейсы – формальные и неформальные
взаимодействия между различными организационными единицами
(различными участниками проекта, различными подразделениями и пр.).
Они могут быть как очень сложными (многолетний проект со множеством
субподрядчиков), так и простыми.
 Технические интерфейсы – взаимодействия между представителями разных
технических дисциплин.
 Межличностные интерфейсы – взаимодействия индивидуумов, занятых в
проекте.
 Требования к нанимаемому персоналу. Необходимо определить требуемые
профессиональные навыки для различных групп людей, участвующих в проекте.
Эти требования являются частью общих потребностей в ресурсах, определяемых в
ходе процесса планирования ресурсов.
 Ограничения. Факторы, ограничивающие возможности команды управления
проектом.

Инструменты и методы для процесса организационного планирования:


 Шаблоны. Хотя каждый проект и уникален, но часто материалы одного проекта
вполне можно использовать и в работах по другому аналогичному проекту.
Использование определений ролей и ответственностей, а также отношений
подчиненности проекта-аналога может существенно ускорить процесс
организационного планирования.
 Правила работы с персоналом. Многие организации имеют развитый набор
процедур и правил по работе с персоналом, в частности, описание многих
стандартных ролей и ответственностей.
 Организационные теории. Существует множество теорий, посвященных методам
построения оргструктуры предприятия и проекта. Желательно, чтобы в команде
управления проектом был эксперт, знакомый с теоретическими подходами,
применимыми к данному проекту и предметной области.
 Анализ потребностей ключевых участников. Выбор той или иной
организационной модели в значительной степени зависит от требований,
предъявляемых к этой модели ключевыми участниками проекта.
 Распределение ролей и ответственностей. Это распределение может меняться во
времени.
Распределение ролей и ответственностей в проекте тесно связано с процессом
определения содержания. Для иллюстрации этой связи часто используется матрица
ответственности (Responsibility Assignment Matrix - RAM). Для больших проектов матрица
ответственности может разрабатываться на нескольких уровнях. Например, матрица
верхнего уровня может определять ответственность соответствующей группы или
подразделения за каждый узел СДР. В то же время матрица нижнего уровня может
определять ответственность отдельных лиц за отдельные работы. Пример матрицы
ответственности приведен на рис. 3-42.

Выходные материалы процесса организационного планирования


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

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

Исполнители/Работа Отдел А Отдел Б


Исполнитель Исполнитель Исполнитель Исполнитель
А1 А2 Б1 Б2

Блок работ 1 Работы 1.1 К О П И


Работа 1.2 У С К,П О
Работа 1.3 С К,П О -
Работа 1.4 У,П К О И

Блок работ 2 Работа 2.1 У,П К О И


Работа 2.2 С,П - К О

Условные обозначения:
О – ответственный исполнитель;
И – исполнитель,
У – утверждает,
С – согласует,
К – контролирует,
П – принимает работу (возможны другие обозначения).

Рис. 3-42. Схематическое представление матрицы ответственности

144
Набор персонала
Процесс набора персонала включает поиск людей с требуемыми навыками и их
назначение в проект. Достаточно часто случается, что по той или иной причине «лучшие»
из имеющихся ресурсов могут оказаться недоступными, и команде управления проекта
потребуется проводить дополнительную проверку соответствия имеющихся ресурсов
требованиям, предъявляемым проектом.
Входные материалы для процесса набора персонала:
 План подбора персонала.
 Описание подбираемого пула ресурсов. Если команда управления проектом имеет
возможность непосредственно влиять на подбор персонала, то следует принимать
во внимание следующие аспекты:
 Предыдущий опыт. Имело ли данное лицо или группа сходный опыт в
прошлом? Был ли этот опыт успешным?
 Личные интересы. Заинтересовано ли данное лицо или группа в работе на
данном проекте?
 Персональные характеристики. Может ли данное лицо эффективно работать
в команде или является ли данная группа уже сработавшейся командой?
 Доступность. Будут ли данное лицо или группа доступны в те периоды
времени, когда потребуется их участие в проекте?
 В конкретных проектах могут приниматься во внимание и другие
соображения.
 Практика найма. Одна или несколько организаций – участников проекта могут
иметь свои собственные процедуры приема на работу и назначения на проекты. В
этом случае такие процедуры должны рассматриваться как ограничения для
процесса найма персонала.

Инструменты и методы для процесса найма персонала


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

145
Начало

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

Определение Определение
необходимых кадров возможных ресурсов

Назначение
ресурсов

Разработка
графиков

Рис.3-43. Назначение людских ресурсов в проекте

Выходные материалы процесса найма персонала


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

Формирование и развитие команды


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

Входные материалы для процесса формирования и развития команды


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

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

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

Выходные материалы процесса формирования и развития команды


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

При планировании людских ресурсов особое значение имеет планирование загруженности


ресурсов. При некорректном распределении нагрузки на персонал часто возникает так
называемый конфликт ресурсов – ситуация, свойственная перегруженности ресурса (на
рис. 3-44 показано над уровнем 100% нагрузки).

147
Рис. 3-44. Конфликт ресурсов

Опытный управляющий уже на этапе планирования стремится не допускать конфликта


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

148
Управление взаимодействием в проекте

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


обеспечение сотрудничества между участниками проекта (юридическими лицами) и
членами их команд. Все участники проекта должны владеть неким общим набором
понятий, составляющих «язык» проекта, с помощью которого и будет осуществляться
взаимодействие. Обычно взаимодействие делится на внешнее (между участниками
проекта) и внутреннее (между членами команды проекта и сотрудниками предприятия).
Задачи управления внешним взаимодействием – установить единый порядок, методику и
технику отработки запросов независимо от их источника путем охвата всех каналов и
точек контакта с организациями на этапе работы по запросам с целью:
 повышения эффективности бизнес-процессов, сосредоточенных в службе
взаимодействия с клиентами;
 оперативного реагирования на запрос клиента через согласованный набор
процедур и методик;
 создания условий для подготовки точной, полной и последовательной информации
по запросу клиента путем оптимальной маршрутизации запросов в бизнес-
направления предприятия.
Задачи управления внутренним взаимодействием – обеспечение эффективного
внутреннего делопроизводства и сотрудничества внутри команды проекта и предприятия
в целом.
Как показали аналитические исследования в области УП, менеджеры проектов до 75%
своего рабочего времени тратят на управление взаимодействием: согласование понимания
тех или иных аспектов проекта между членами команд, участниками; выявление точек
возникновения конфликтов, упреждение конфликтов и их разрешение. Время тратится
на индивидуальные обсуждения, переговоры, кулуарные, неформальные разговоры,
совещания, семинары, конференции, телефонные общения, составление писем, факсов,
протоколов и пр. При этом базовым ресурсом менеджера являются его персональное
владение языком и риторикой. Опытный менеджер особое внимание уделяет владению
риторикой – искусству адекватного донесения своих мыслей адресату взаимодействия.
Если кто-то из членов команды или внешних участников плохо вас понимает, то это
прежде всего ваши проблемы, это прямой сигнал к тому, что вы неверно используете
ресурсы языка и приемы общения, вы не провели предварительный анализ языковой
среды адресата общения, не уточнили его практический, активный словарный запас.
Опытный менеджер всегда стремится говорить на языке, понятном его собеседнику.
Очень важна обратная связь в процессах взаимодействия: менеджер должен проводить
анализ результатов процессов взаимодействия – насколько адекватно доведена и
воспринята информация участниками проекта и членами их команд.

Управление взаимодействием связано со всеми другими областями УП и прежде всего с


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

149
Формальное завершение – генерация, сбор и распространение информации, связанной с
формальным завершением отдельной фазы или всего проекта в целом.

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


менеджменте, в значительной степени совпадает с управлением взаимодействием
применительно к проектам. Но при этом существуют некоторые различия. Можно сказать,
что существует некоторый свод знаний по этой проблеме, независимый от конкретного
проекта. Он включает в себя:
 Модели отправитель-получатель – петли обратных связей, коммуникационные
барьеры и пр.
 Выбор среды – когда письменное общение следует предпочесть устному и
наоборот. Или когда следует выбрать формальный отчет, а когда неформальное
письмо.
 Стиль письма – выбор действительного или страдательного залога, структура
предложений, выбор слов и т.д.
 Техника презентаций – «язык тела и жестов», подготовка наглядных
иллюстрирующих материалов и пр.
 Техника проведения совещаний – подготовка повестки, разрешение конфликтов и
т.д.
Обзор процессов управления взаимодействием приведен на рис. 3-45.

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

150
Управление взаимодействием

Планирование взаимодействия Организация взаимодействия

Входные материалы Входные материалы


Требования к организации взаимодействия Сводный план проекта
Ограничения План управления взаимодействием
Допущения Реестр проектов
Инструменты и методы Инструменты и методы
Анализ участников (юридических лиц) Навыки взаимодействия
Выходные материалы Система взаимодействия с внешними
организациями (CRM)
План управления взаимодействием
Единая информационная система
Выходные материалы
Рабочая документация по управлению
проектом

Отчетность по эффективности Формальное завершение


выполнения проекта

Входные материалы Входные материалы


Сводный план проекта Документация по оценке эффективности
Результаты работ выполнения проекта
Прочая рабочая документация проекта Документация по продуктам проекта
Инструменты и методы Прочая рабочая документация проекта
Обзоры эффективности выполнения проекта Инструменты и методы
Анализ отклонений Инструменты и методы отчетности по
Анализ тенденций эффективности выполнения проекта
Анализ выполненной стоимости Выходные материалы
Выходные материалы Архивы проекта
Отчетность по эффективности выполнения Формальное утверждение
проекта Извлеченные уроки
Запросы на внесение изменений

Рис. 3-45. Управление взаимодействием

151
Таблица 3-4. Основные источники анализа психологических проблем управления
проектов

Основные Функциональная Матричная Проектная


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

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

Инструменты и методы для планирования взаимодействия:


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

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

153
Воронка
обращений

Центр
обработки
запросов

Претензия по счетам
Претензия по Заказ новых
Информационный запрос
качеству услуг услуг
Изменение услуг
Инженерно-
технические
службы
Центр компетенции Центр компетенции Служба по
по качеству Служба продаж по качеству расчетам с
услуг обслуживания клиентами
Службы операти-
вно-технического
управления

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

Клиент
Клиент

Рис. 3-46. Пример схемы обслуживания запросов от внешнего участника

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

Выходные материалы:
 Рабочая документация по управлению проектом.

Отчетность по эффективности выполнения проекта

Входные материалы для процесса отчетности по эффективности выполнения


проекта:
 Сводный план проекта.

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

Инструменты и методы для подготовки отчетности по эффективности выполнения


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

Выходные материалы процесса отчетности по эффективности выполнения проекта:


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

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

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

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


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

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

Управление поставками включает в себя процессы, направленные на получение товаров и


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

156
157
158
159
Управление поставками

Планирование поставок Планирование работы Сбор технико-коммерческих


с поставщиками предложений
Входные материалы Входные материалы Входные материалы
Свод содержания проекта План управления закупками Стандартизованная документация по
Описание продукта Описание фрагментов продукта поставкам
Людские ресурсы Выходные материалы других Перечень потенциальных
процессов планирования поставщиков
Состояние рынка
Инструменты и методы Инструменты и методы
Выходные материалы других
процессов планирования Стандартные формы Конференции поставщиков
Ограничения Заключения экспертов Публикации в средствах массовой
Выходные материалы информации
Допущения
Стандартизованная документация Выходные материалы
Инструменты и методы
Анализ произвести-или-купить по поставкам Технико-коммерческие предложения
Заключения экспертов Критерии оценки
Выбор типа контрактов
Выходные материалы
План управления закупками
Описания фрагментов продукта

Выбор поставщиков Управление контрактами Закрытие контрактов


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

Рис. 3-47. Управление поставками и контрактами

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

161
 Контракт с возмещением фактических затрат – по этому типу контракта
покупатель возмещает поставщику фактически понесенные затраты по
выполнению оговоренного объема работ, включая как прямые, так и
косвенные затраты.
 Контракт с оплатой единицы продукции – по этому типу контракта
покупатель платит определенную цену за единицу предоставляемого
продукта (например, 500 рублей в час за работу консультанта или 10 рублей
за кубометр вынутого грунта).
Выходные материалы процесса планирования закупок:
 План управления закупками. Является частью Сводного плана проекта и
определяет:
 Какие типы контрактов будут использоваться?
 Будут ли использоваться оценки независимых экспертов (например, в
качестве критерия выбора поставщиков)? Если да, то кто будет играть роль
экспертов?
 Если в компании имеется отдельное подразделение, ответственное за закупки
и контракты, то каким будет разделение обязанностей и полномочий между
этим подразделением и командой управления проектом?
 Существуют ли в компании стандартизованные документы и формы, которые
потребуется использовать в процессе управления поставками?
 Как управление поставками будет взаимодействовать с другими
составляющими проекта, такими, как разработка графика и отчетность по
эффективности выполнения проекта?
 Описание фрагмента (фрагментов) продукта. Включает в себя описание
поставляемого продукта (изделия) или услуги. Должно содержать всю
информацию, необходимую поставщику для выполнения своих обязательств.

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


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

162
 Качество продукта или услуги, а также наличие сертификата на систему
качества у данного поставщика.
 Надежность, деловая репутация и финансовая устойчивость данного
поставщика.

Сбор технико-коммерческих предложений


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

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

163
 Умножение каждого рейтинга на соответствующий весовой коэффициент.
 Расчет интегральных оценочных показателей.
 Система обязательных требований. Эта система предъявляет обязательные
требования по одному или нескольким критериям оценки и устанавливает
минимально допустимые значения для этих критериев.
 Независимые оценки. Часто организация-покупатель готовит свои собственные
оценки цены и сравнивает их с оценками, полученными от потенциальных
поставщиков. Существенные расхождения могут, например, означать различие в
толкованиях описания поставляемого продукта или услуги между покупателем и
поставщиком.
Выходные материалы процесса выбора поставщиков:
 Контракты. Контракт – это соглашение, по которому продавец обязуется
поставить определенный набор продуктов или услуг, а покупатель обязуется
оплатить этот набор по той или иной схеме.

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

164
 Отчетность по эффективности выполнения. Такая отчетность предоставляет
руководству информацию о том, насколько успешно данный поставщик
справляется со своими обязательствами.
 Система организации платежей. Как правило, все платежи по проекту проходят
через бухгалтерию и финансовые службы компании, выполняющей проект.
Выходные материалы процесса управления контрактами:
 Оперативная переписка. Условия контрактов часто требуют документирования
многих аспектов взаимодействия покупателя и продавца. Например, это могут
быть уведомления об отставании от графика, акты приемки поставленных
продуктов и услуг или протоколы об изменениях в контрактах.
 Изменения в контрактах. Изменения в контрактах должны обрабатываться
процессами планирования и управления поставками. При этом соответствующие
изменения вносятся в Сводный план проекта и другие документы.
 Запросы на исполнение платежей. Такая формулировка предполагает, что в
проекте используется внешняя система организации платежей. Если проект имеет
свою собственную систему, то здесь следует сказать просто «платежи».

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

165
Управление информацией

Наибольшего успеха в ведении бизнеса достигают те компании, где особое внимание


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

В управлении информацией выделяются следующие основные процессы:


Планирование информационного обеспечения проекта — определяет стратегию
информационного обеспечения и информационной безопасности проекта.
Распространение информации – фиксирует механизмы распределения информации в
соответствии с документами планирования информационного обеспечения и
объективными текущими потребностями реализации проекта.
Отчетность по информационному обеспечению проекта – обеспечивает системный
контроль над установленными регламентами и реализацией информационного
обеспечения. Является одним из механизмов системы информационной безопасности
предприятия.
Составление реестра информационных БД – консолидация опыта информационного
обеспечения. Является базой для повышения производительности труда в реализации
будущих проектов, повышения качества работы процессов информационного обеспечения
(рис. 3-48).

166
Планирование информационного обеспечения проекта

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

167
168
Управление информацией

Планирование информационного Распространение информации


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

Отчетность по информационному Составление реестра информационных


обеспечению проекта БД

Входные материалы Входные материалы


Сводный план проекта Документация по оценке эффективности
Результаты работ выполнения проекта
Прочая рабочая документация проекта Документация по продуктам проекта
Инструменты и методы План управления информацией.
1. Обзоры эффективности выполнения проекта Документы системы информационной
Анализ отклонений безопасности.
Анализ тенденций Прочая рабочая документация проекта
Анализ выполненной стоимости
Методы и инструменты распространения Инструменты и методы
информации Инструменты и методы отчетности по
Выходные материалы эффективности выполнения проекта
Отчетность по эффективности выполнения Инструменты и технологии архивизации.
проекта Выходные материалы
Запросы на внесение изменений Архивы проекта
Формальное утверждение
Извлеченные уроки

Рис. 3-48. Управление информацией в проекте

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

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


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

170
Система управления
предприятием

Система
информационной
безопасности

Система Система
Система Система
АСУП (ERP) электронного финансово-экономического
управления проектами кадрового учета
документооборота учета

Методико-
Стратегические технологические АСУТП-1 АСУТП-2
Базовое ПО АРМы Система архивизации
Регламенты УП Регламенты УП MRP-II MRP-II
CVP и др.

Инженерно-
производственная
Инструменты подсистема
MS Project, АРМы
и др.

Система учета ресурсов


MRP-I

Рис. 3-49. Пример единой информационной системы

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

Входные материалы для процесса распространения информации


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

Отчетность по информационному обеспечению проекта


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

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

Составление реестра информационных БД


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

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

Под безопасностью проекта понимается состояние всех его элементов, определяющее их


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

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

174
Рис. 3-50. Управление безопасностью в проекте

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

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


Оценка объемов потребности в
безопасности
Входные материалы
Входные материалы
1. Список участников проекта и их 1. Критерии оценки безопасности систем,
характеристики процессов и ресурсов, вовлекаемых в
2. Описание продукта проект
3. СДР 2. СДР
4. Выходные материалы других процессов 3. Источники угроз
планирования 4. Рисковые события
5. Статистическая и архивная информация 5. Оценки затрат
Инструменты и методы 6. Оценки продолжительности работ
1. Своды законов, нормативной документации, Инструменты и методы
регулирующие данный вид бизнеса 1. Ожидаемый финансовый эффект
2. Справочники юриспруденции, экономики, 2. Моделирование
финансового и бухгалтерского учета, другие 3. Деревья решений
документы окружения проекта 4. Заключения экспертов
3. Регламент политики безопасности предприятия 5. Программные средства
4. Анализ и экспертные оценки Выходные материалы
Выходные материалы 1. Перечень значимых угроз
1. Перечень источников угроз и опасностей. 1. Ресурсный план по обеспечению
2. Перечень слабых сторон проекта безопасности
3. Симптомы угроз 2. План резервов.
4. План управления безопасностью 3. Статья бюджета по затратам на
5. Входные материалы для других процессов безопасность проекта.

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


безопасности проекта мероприятий безопасности

Входные материалы
1. План управления рисками
Входные материалы 2. Фактически произошедшие события и
1. План управления рисками мероприятия по безопасности
2. Перечень значимых угроз проекту 3. Идентификация дополнительных угроз
3. Ресурсный план по обеспечению безопасности Инструменты и методы
1. Правовой мониторинг
Инструменты и методы 2. Динамическая отчетность.
1. Регламенты безопасности предприятия 3. Внеплановые реагирования
2. Применение санкций и стимулов 4. Разработка дополнительных методов
3. Альтернативные стратегии реагирования
4. Страхование Выходные материалы
5. Динамическая отчетность 1. Корректирующие воздействия
2. Обновления плана управления рисками
Выходные материалы 3. Отчеты по безопасности
1. Текущие результаты мероприятий 4. Профили защиты и реестр средств и
безопасности. мероприятий по обеспечению
2. Входные материалы для других процессов. безопасности проектов.
3. План на случай нештатных ситуаций.
4. Резервы. 175
Планирование управления безопасностью

Планирование управления безопасностью и требования к безопасности конкретных


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

Таблица 3-5. Пример применения правовых процедур на разных фазах проекта

Фаза проекта Характерные процедуры правового обеспечения


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

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

Оценка объемов потребности в безопасности


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

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

Критерии
оценки

Методология
оценки

Система
оценки

Входные Окончательные Утверждение План мероприятий


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

Рис. 3-51. Схема оценки объемов потребности в безопасности проекта

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

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

предпринимают
чтобы уменьшить
КОНТРМЕРЫ
которые
направлены на

УЯЗВИМОСТЬ
могут знать И

ведущие к
которые приводят к РИСК и
ПОТЕРИ
которые для Субъекты и
ИСТОЧНИКИ повышают объекты
УГРОЗ
проекта
порождают

УГРОЗЫ для

могут нанести ущерб

Рис. 3-52. Элементы безопасности проекта и их взаимосвязи

178
Разработка и проведение мероприятий по безопасности проекта

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


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

Контроль осуществления мероприятий безопасности

Отслеживание текущих изменений внешней и внутренней среды проекта. Мониторинг


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

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

Управление конфликтами в проекте – процесс, в котором с помощью использования


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

180
Объект

Субъект 1
Субъект 2

Рис. 3-53. Столкновение интересов разных субъектов – источник конфликтов

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


представить следующим образом:
1. Конфликт из-за приоритетов в проекте.
Мнения участников проекта о последовательности работ и задач различаются.
2. Конфликт из-за административных процедур.
Расхождения между участниками по поводу того, как должен управляться проект.
3. Конфликт из-за технических решений.
Несогласие по техническим вопросам и технологии производства работ.
4. Конфликт из-за людских ресурсов.
Конфликт из-за набора исполнителей из других подразделений и распределения их по
направлениям работ.
5. Конфликт из-за увеличения стоимости.
Конфликт из-за перерасходов, вызванных авариями и другими непредвиденными
ситуациями, увеличивающими стоимость проекта.
6. Конфликт из-за выполнения календарного плана.
Несогласие из-за времени и последовательности выполнения проектных задач.
7. Конфликт из-за личных взаимоотношений.

Для разрешения конфликта менеджер сначала должен выявить реальные причины


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

181
как продукт проекта будут потребляться конечными пользователями. С этой точки зрения
руководитель проекта должен особое внимание уделять анализу состояния конечного
пользователя результата проекта. На рис. 3-54 приведен типичный пример,
иллюстрирующий процесс внедрения новой системы. Данный проект имеет целью
повышение производительности труда конечных пользователей, у которых до внедрения
новой системы на единичную работу трудозатраты составляли около 2 чел-дней (см.
данные по ординате рис.3-54). После внедрения системы производительность должна
составлять 0.1 чел-день (т.е. около 50 минут на указанную единичную работу, при 8-
часовом рабочем дне). Руководство не снимает с сотрудников текущие работы и
обязанности и параллельно обязывает их осваивать новую систему. В результате на пути
реализации проекта возникает значительный барьер. Основной составляющей этого
барьера является непринятие новых систем и технологий конечными пользователями.

При внедрении новых технологий или систем необходимо


упреждение преодоления барьеров
ную
аты

еди
нич

раб
Тру
доз

оту
атр

на

5 чел-дн.

2 чел-дн.

0.1 чел-дн.
t1 tк Этапы
Начало ввода новой Завершение ввода
системы новой системы

Рис. 3-54. Поведение производительности труда пользователя продукта проекта


внедрения новых систем, технологий или методик

Западные аналитики ИТ-проектов приводят данные, показывающие, что из пяти ИТ-


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

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

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

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

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


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

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

Контроль общих изменений и отчетности.


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

184
Рис. 3-55. Управление контролем исполнения проекта

Контроль изменений содержания Контроль выполнения графика


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

Контроль затрат Контроль качества


Входные материалы
Входные материалы
Базовый план затрат
Отчетность по эффективности выполнения План управления качеством
проекта Оценки эффективности контроля качества
Запросы на внесение изменений Инструменты и методы
План управления затратами
Инструменты и методы планирования
Инструменты и методы качества
Система контроля изменений затрат
Аудит качества
Оценки эффективности
Дополнительное планирование Выходные материалы
Программные средства Мероприятия по совершенствованию
Выходные материалы качества
Уточненные оценки затрат
Обновления бюджета
Корректирующие воздействия
Оценка затрат по завершении проекта
Извлеченные уроки

Контроль реагирования на риски Контроль общих изменений отчетности


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

185
Отчетность о текущем исполнении проекта развивает дисциплину и систематичность в
ходе выполнения проекта. Отчеты должны предоставляться на регулярной основе.
Например, раз в месяц в случае долгосрочных проектов и раз в неделю в случае
среднесрочных проектов. Организуя систему динамической отчетности, следует должным
образом анализировать оптимальное время предоставления отчетов и последовательность
их отработки.
Например, нецелесообразно ставить точку предоставления еженедельных отчетов на утро
понедельника, так как за выходные ответственные исполнители часть деталей о
прошедших событиях могут упустить и вероятность искажения информации в отчете при
этом возрастает. Более рационально поставить точку динамической отчетности на конец
рабочей недели, например на 16 часов пятницы. Обычно в крупных проектах отчеты по
функциональным направлениям составляют менеджеры по направлениям и
предоставляют их ведущему менеджеру проекта или руководителю проекта. Руководитель
проекта в течении часа проводит анализ отчетов, ранжирует возникшие за отчетную
неделю проблемы и формулирует задания соответствующим членам команды
(ответственным исполнителям или их руководителям) на выработку мероприятий,
корректирующих отклонения от плана. Ответственные исполнители или их руководители
к 10 часам понедельника должны представить предложения по данным мероприятиям. В
11 часов руководитель проекта после анализа предложений и моделирования последствий
их реализации либо утверждает их, либо корректирует, либо предлагает иные
мероприятия и направляет эти решения на реализацию ответственным исполнителям.
Подобная жесткая схема отчетности значительно повышает эффективность динамической
отчетности.
Кроме того, для повышения эффективности работы менеджеров, используются шаблоны
отчетов, в которых приоритетным является информация о возникших проблемах,
отставанию от графиков выполнения работ, отклонениям по затратам и т.д.
 Ретроспективная отчетность. По запросу вышестоящего руководства или внешних
организаций в делопроизводстве контроля управлением проекта должен быть
предусмотрен вариант подготовки и предоставления сводной информации о проекте
с момента его открытия по текущую дату, т.е. вся историческая информация по
осуществленной части жизненного цикла проекта. Иногда этот ретроспективный
отчет называют статус-репорт (status-report).
 Листы изменений. Качественное делопроизводство проекта предусматривает
сопровождение любой документации на продукт проекта Листом изменений,
который фиксирует на основании чего, кем, когда и что было изменено. В крупных
проектах общие изменения больших масштабов имеют особенное значение, поэтому
в процессах УП фиксации этих изменений и их отслеживанию уделяется тщательное
внимание. Для этого используется Матрица координации изменений (таблица 3-6),
представляющая собой Лист изменений по проекту в целом. Матрица координации
изменений является одним их действенных управленческих инструментов,
обеспечивающих практическую прозрачность ведения проекта. В рамках этой цели
Матрица координации изменений помогает четко сформулировать шаги процесса
контроля общих изменений, идентифицировать действия, которые должны быть
предприняты, назначать лиц, ответственных за выполнение этих действий, и
координировать их усилия.
 Контрольные встречи. Встречи для обсуждения хода проекта, выполненных работ и
имеющихся проблем.
 Разработка дополнительных методов реагирования.

186
Руководитель проекта

МАТРИЦА КООРДИНАЦИИ ИЗМЕНЕНИЙ


Код проекта: Название проекта:
Дата Прочие стороны, Принятие Дата
Источник Предмет Ответствен-
инициации затрагиваемые решения, отработки
изменения изменения ный
изменения изменением основание изменения

Главный инженер проекта Инженер службы качества Экономист

Таблица 3-6. Пример матрицы координации изменений

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

187
ГЛАВА 4. Система сертификации IPMA

В Международных Требованиях по Компетентности специалистов по Управлению


Проектами (ICB International Competence Baseline), разработанных Международной
ассоциацией управления проектами (IPMAInternational Project Management Association)
представлены требования к знаниям, навыкам и личным качествам управляющих
проектами и членов команды проекта. ICB включает основные термины и понятия,
задачи, обобщают передовой опыт, навыки, функции, процессы управления, методы,
технологии и инструментарий, которые обычно используются в Управлении Проектами, а
также специальные знания о нововведениях и их применении в управлении отдельными
проектами. ICB – не учебник и не сборник рецептов, ICB открывает путь к знаниям,
опыту и индивидуальному мастерству в сфере управления проектами. ICB – это основа
всех сертификационных программ национальных ассоциаций и их сертификационных
центров, ратифицируемых Международной Ассоциацией Управления Проектами (IPMA).

Международная Ассоциация Управления Проектами (IPMA) – зарегистрирована в


Швейцарии как некоммерческая профессиональная организация, основной функцией
которой является содействие развитию и широкому применению на практике методов и
средств Управления Проектами в разных странах мира. Ассоциация IPMA создана в 1965
году под своим прежним названием INTERNET как форум для обмена опытом между
управляющими международными проектами. Со времени проведения первого
Международного конгресса в Вене в 1967 году IPMA стабильно развивается как
организация и содействует развитию управления проектами как самостоятельной
профессиональной дисциплины.

В 1985 году Институт Управления Проектами (PMI) в Северной Америке разработал


«Body of Knowledge (BOK)» – Свод Знаний по Управлению Проектами. Этот документ
и его последующие версии вплоть до последней «Guide to the Project Management Body
of Knowledge» [31] являются основой для оценки знаний профессионалов по управлению
проектами (PMP Project Management Professional). В 1987 году IPMA провела опрос
своих членов относительно необходимости введения сертификации в рамках IPMA.
Большинство ответов были положительными. Вслед за этим ведущие профессиональные
ассоциации управления проектами в течение последних десяти лет разработали
Требования к оценке компетентности в области управления проектами. В 1991 году
Ассоциация управляющих проектами Великобритании (АРМ) издала первую версию
своего Свода Знаний по Управлению Проектами. В первой половине девяностых годов в
других европейских странах были осуществлены подобные программы, иногда связанные
с созданием соответствующих тренинг-курсов. С 1993 года рабочей группе IPMA по
сертификации (CCTCertification Core Team) была поручена работа по координации и
унификации национальных сертификационных программ. Было выработано первое
соглашение об установлении международных требований, предъявляемых к разработке
национальных документов по сертификации.
Национальные ассоциации несут ответственность за сертификационные программы в
своих странах. IPMA осуществляет ратификацию этих программ, на основе анализа их
соответствия установленным правилам, стандартам и рекомендациям. К 1996 году в
Швейцарии, Франции и Германии уже использовались и были готовы к аккредитации
документы по сертификации для одного или нескольких уровней сертификационной
программы. В качестве главного инструмента для оценки кандидатов асессорами и
самооценки была определена система оценок, названная в ICB таксономия. Таксономия
(или система оценок) отображает требования к знаниям, навыкам и личным качествам, а

188
также требования к специалистам по управлению проектами разных уровней
сертификации. IPMA отслеживает существенные отклонения в национальных программах
сертификации.
В 1997 году Дирекция IPMA по ратификации сертификационной программы (CVM
Board – Certification Validation Management Board) начала работу по развитию и
координации квалификационных и сертификационных программ национальных
ассоциаций на международном уровне. Главное различие было сделано между
содержанием сертификационной программы (ICB) и ее организацией и
сертификационными процедурами. В 1998 году IPMA утвердила систему
ратификации четырех уровневой сертификационной программы (4LC – Fore Level
Certification), которая получила всемирную известность. К февралю 1999 года 17
стран подписали соглашение с IPMA и 10 стран применяют международную
программу сертификации.
ICB содержит следующие разделы:
A. Введение (Introduction)
B. Знания и опыт (Knowledge and Experience)
C. Личные качества кандидата (Personal Attitude)
D. Система оценок (Taxonomy)
E. Стандарты и руководства, ссылки (Standards and Guidelines, References)
F. Литература (Literature)
Настоящая версия ICB представлена на трех языках: английском, немецком и
французском. ICB создан на основе Национальных Требований к Компетентности
следующих национальных ассоциаций по управлению проектами:
 АРМ (Великобритания) – the UK Body of Knowledge;

 VZPM (Швейцария) the Swiss Assessment Structure; 
 GPM (Германия) the German projektmanagement
Kanon;
 AFITEP (Франция) – the French Assessment Criteria.
Элементы этих национальных требований к компетентности были перенесены в ICB
полностью или в частично измененном виде. При этом во всех случаях была обеспечена
смысловая согласованность. Для сохранения связи с первоисточниками в тексте ICB
имеются соответствующие ссылки. ICB используется в качестве основы всех
нормативных документов сертификационных программ, ратифицируемых IPMA, а также в
качестве теоретических и практических рекомендаций в области управления проектами
(например, литература по управлению проектами, исследования, образование, подготовка
и переподготовка кадров, отчеты по управлению проектом). ICB отражает общепринятые
в рамках IPMA принципы для оценки компетентности в области управления проектами.
Тем самым ICB оказывает непосредственное влияние на развитие национальных
требований к компетентности, которые в свою очередь влияют на развитие ICB. Каждая
национальная ассоциация разрабатывает и утверждает собственную детальную
документацию для сертификационной программы и прежде всего Национальные
требования к компетентности (NCBNational Competence Baseline). Эта документация
ратифицируется IPMA для проведения сертификации. При этом национальным
ассоциациям предоставляется определенная свобода для учета особенностей
национальной культуры и достижений в области компетентности по управлению
проектами. С другой стороны, унификация, проводимая IPMA, учитывает требования
компаний и организаций, работающих на мировом рынке.
ICB содержит 42 элемента, определяющих знания и опыт в управлении проектами (28

189
основных и 14 дополнительных элементов), а так же 8 аспектов, касающихся личных
качеств кандидата и 10 аспектов, определяющих общее впечатление о сертифицируемом.
IPMA требует, чтобы в NCB были включены все 28 основных элементов и по крайней
мере 6 дополнительных элементов, выбранных на усмотрение национальной ассоциации.
Кроме того, в NCB также должны быть представлены разделы, отражающие аспекты,
касающиеся личных качеств и определяющие общее впечатление о кандидате. В то же
время, примерно 8 дополнительных элементов знаний и навыков (примерно 20% от 42
элементов) могут быть устранены или заменены на новые элементы, учитывающие
национальные особенности и достижения в области управления проектами. В тоже время,
некоторые специфические вопросы, отраженные в NCB национальных ассоциаций, не
были включены в число элементов управления проектами, представленных в ICB. Такие
элементы выделены в ICB курсивом (italics). Эти элементы могут послужить отправными
точками для дальнейшего развития и расширения ICB.

Российские Национальные требования к компетенции (НТК) разработаны группой


сертифицированных специалистов Российской Ассоциацией Управления Проектами
СОВНЕТ на основе и в соответствии с Международными Требованиями к Компетенции
специалистов по управлению проектами (International Competence Baseline of the
International Project Management Association ICB, IPMA) и одобрены Сертификационной
комиссией Ассоциации СОВНЕТ.
В процессе разработки НТК вышло за рамки предусмотренного содержания и объема и,
по существу, переросло в Основы Профессиональных Знаний и Требования к
Компетентности Специалистов по Управлению Проектами. Это послужило причиной
того, что фактическое содержание данной работы вынесено на титульный лист книги.
Такое расширение НТК Сертификационной Комиссией СОВНЕТ признано
целесообразным, т.к. позволяет всем интересующимся получить более полную
информацию об Управлениb Проектами.

Ассоциация Управления Проектами СОВНЕТ основана в 1990г., как профессиональная


некоммерческая организация, действующая на основе hоссийского законодательства.
Ассоциация СОВНЕТ объединяет специалистов, фирмы, компании и предприятия,
которые осуществляют разработку, выполнение и управление проектами в различных
сферах деятельности: строительстве, промышленности, информационных технологиях,
телекоммуникациях, консалтинговых услугах и др. С 1991г., Ассоциация СОВНЕТ
является национальной, российской организацией в составе Международной Ассоциации
Управления Проектами – IPMA (Цюрих, Швейцария); Российская ассоциация управления
проектами ставит своей главной целью развитие профессионального Управления
Проектами в России и содействие его широкому применению на практике.
Лицам, успешно прошедшим сертификацию, вручается сертификат международного
образца на русском и английском языках за подписью международных асессоров. На
сертификатах располагаются логотипы IPMA и Ассоциации СОВНЕТ. Данные
сертификаты признаются во всех странах – членах IPMA и других странах мира.
Информация о специалистах, прошедших сертификацию, заносится в международный и
национальный реестры специалистов – профессионалов по управлению проектами и
публикуется на сайтах IPMA – www.ipma.ch и СОВНЕТ – www.sovnet.ru.
В основу структуры НТК Российской Ассоциации Управления Проектами положено
представление об управлении проектами как о некоторой кибернетической системе. При
этом элементы международных требований к компетентности были перенесены из ICB в
НТК полностью или в частично измененном виде. При этом во всех случаях была
обеспечена смысловая согласованность. Для сохранения связи с ICB в тексте НТК
приводится таблица соответствия разделов знаний ICB и НТК.

190
НТК содержит все разделы 1СВ, ряд дополнительных разделов, а также имеет
некоторые особенности в изложении материала. Отметим основные различия в этих
документах.
В состав элементов знаний НТК вошли 28 основных (Core Elements) и 13
дополнительных (Additional Elements) элементов ICB. В состав элементов знаний НТК
из ICB не вошел элемент знаний по бизнеспроцессам (Business Processes). Помимо этого
в состав элементов знаний НТК добавлено 4 дополнительных элемента
национального уровня, не представленных в ICB. Такими элементами стали:
Управление проектами за рубежом; Управление проектами в России; Управление
проектами в переходной экономике; Будущее управления проектами. Все эти сорок пять
элементов, в соответствии с разработанной системной моделью управления проектами
[138], сгруппированы в 43 элемента знаний НТК.
В отличие от ICB каждый элемент знаний в НТК снабжен основной и дополнительной
литературой на русском и других языках, преимущественно английском. Также в НТК в
отличие от ICB представлен «Этический кодекс управляющего проектом» и Глоссарий
профессиональной терминологии по управлению проектами. В разделе НТК
«Литература» приводится полный список существующих стандартов и руководств по
УП, словарей, сборников трудов основных международных форумов по управлению
проектами в России и за рубежом, а также список отобранной основной и
дополнительной русской и англоязычной литературы. Все приведенные литературные
источники имеют сквозную нумерацию, и в тексте НТК на них указываются ссылки в
квадратных скобках.
Оценка квалификации и компетентности специалистов по Управлению Проектами
осуществляется путем оценки знаний, опыта, личных качеств претендента, а также
общего впечатления, производимого кандидатом в процессе общения с ним.
Разработанная IPMA система сертификации включает четыре уровня (таблица 4-1).
Основные требования к каждому уровню сертификации определяются исходя из
обязанностей, ответственности и требований практики, предъявляемых к специалистам
соответствующего уровня.

Уровень А. Сертифицированный директор программ или проектов – СДП


(Certificated Project Director CPD) должен:
 Быть способным управлять всеми проектами компании или проектами ее
отделения или всеми проектами программы;
 Иметь минимум 5-летний опыт управления комплексными проектами и
программами, из которых кандидат не менее 3 лет был ответственен за
руководство, координацию и управление портфелем проектов;
 Осуществлять руководство координацией и контролем всех проектов на уровне
компании или ее отделения;
 Иметь портфель конкретных стратегических предложений по общему управлению;

 Принимать участие в подготовке персонала, задействованного в управлении


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

191
Таблица 4-1. Квалификационные уровни в области УП по версии Международной
Ассоциации управления проектами IPMA

Уровни
№ Требования к специалистам сертификации
A B B1 C D
1 Способность управлять:
программой Х
сложными проектами Х Х Х
простыми проектами Х
основными функциями в сложных проектах Х
отдельными функциями в проекте на основе своих знаний Х
2 Опыт работы:
управляющим проектом (5 лет) Х Х Х
координатором комплекса проектов (5 лет) Х
в международных проектах (3 года ) Х
в команде проекта (3 года ) Х
3 Высшее образование Х Х Х Х Х
Свободно владеть одним из иностранных языков
4 Х Х
(английским, французским, немецким)
Уровень В имеет два варианта сертификации:

В1 – Сертифицированный управляющий проектами СУП (Certificated Project Manager


CPM) должен:
 Быть способным самостоятельно управлять сложными проектами с
использованием современных методов и средств управления проектами;
 Иметь минимум 5-летний опыт управления проектами, из которых не менее 3 лет в
качестве ответственного за руководство и управление сложными проектами;
 Нести ответственность за осуществление сложного проекта связанного с: 
 множеством взаимосвязанных подсистем и элементов, а также связей с
окружением проекта;
 несколькими компаниями и/или организационными единицами,
вовлеченными в проект; различными функциональными сферами и
дисциплинами, задействованными в проекте; различными фазами
жизненного цикла проекта, имеющими значительную продолжительность;
 применения различных методов, средств и инструментария по
Управлению Проектами;
 Руководить большой группой персонала, участвующего в управлении проектом; 
 Нести ответственность за все параметры проекта и все функциональные области
управления проектом.
В2 – Сертифицированный управляющий международными проектами – СУМП
(Certificated International Project Manager CIPM) должен:
 Быть способным самостоятельно управлять сложными проектами, включая
международные проекты с использованием современных методов и средств
управления проектами;
 Иметь минимум 5-летний опыт управления проектами, из которых не менее 3 лет в
качестве ответственного за руководство и управление сложными проектами;
 Иметь минимум 3-летний опыт работы в международных проектах;
 Владеть одним из трех иностранных языков: английским, немецким или

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

Уровень С
Сертифицированный Профессионал по Управлению Проектами СПУП (Registered
Project Management Professional RPMP) должен:
 Быть способным самостоятельно управлять несложными проектами
использованием современных методов и средств управления проектами,
помогать управляющему сложными проектами во всех функциональных областях
Управления проектами;
 Иметь минимум 3-летний опыт управления проектами в качестве руководителя в
функциональных областях несложного проекта;
 Нести ответственность за осуществление несложного проекта и за все его
параметры;
 Управлять небольшими группами персонала по управлению проектом;
 Применять методы, средства и инструментарий по управлению проектами; 
 Быть способным работать в качестве руководителя группы специалистов,
входящей в команду сложного проекта, и нести ответственность за
соответствующие параметры проекта.

Уровень D
Сертифицированный специалист по управлению проектами ССУП (Project
Management Professional PMP) должен:
 Обладать знаниями во всех областях Управления Проектами (и быть
способным применять их в некоторых областях как специалист);
 Обладать широким спектром знаний в Управлении Проектами и быть
способным применять эти знания на практике;
 Быть способным выступать в качестве члена команды проекта в любой
функциональной области по управлению проектами.

Уровни сертификации не учитывают должностной, образовательной, социальной или


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

193
многих отечественных, зарубежных и международных компаний и организаций.
Уровень D соответствует требованиям национальных ассоциаций к подготовке кадров с
высшим образованием по специальности (или специализации) Управление Проектами.
Основное различие между уровнями B и C системы сертификации IPMA состоит в том,
что управляющий проектами уровня В должен быть способен управлять сложными
проектами, в то время как управляющий проектами или член команды проекта уровня С
должен быть способен управлять несложными проектами. Данное разграничение
отражает потребности экономики в управляющих проектами уровней B и C. Большое
число малых и средних проектов требуют профессионалов. Для управления большими и
сложными проектами требуют больше знаний и опыта, а также специфические
профессиональные качества, таким требованиям отвечают профессионалы уровня В.
Сложные проекты имеют следующие отличительные особенности:
 Наличие множества взаимосвязанных подсистем и элементов в структурах
проектов и их взаимосвязи с окружающей средой проекта;
 Наличие нескольких компаний и/или структурных подразделений вовлеченных в
проект; 
 Наличие различных функциональных сфер и дисциплин, задействованных в
осуществлении проекта;
 Управление сложным проектом осуществляется на протяжении нескольких фаз
жизненного цикла с минимальной продолжительностью всего проекта;
 При управлении сложными проектами используется значительное число известных
методов и средств Управления Проектом (более 60-80%).

Перечень элементов ICB


28 основных элементов (Core Elements)
1. Проекты и управление проектами
2. Применение управления проектом
3. Проектно ориентированное управление
4. Системный подход и интеграция
5. Окружение и участники проекта
6. Фазы и жизненный цикл проекта
7. Разработка и оценка проекта
8. Цели и стратегии проекта
9. Критерии успехов и неудач проекта
10. Запуск проекта
11. Закрытие проекта
12. Организационные структуры проекта
13. Содержание, предметная область
14. Календарное планирование
15. Ресурсы
16. Стоимость и финансирование проекта
17. Конфигурация и изменения
18. Риски в проекте
19. Оценка выполнения
20. Контроль за проектом
21. Информация, документация, отчетность
22. Организация проекта
23. Команда проекта
24. Руководство и лидерство
25. Взаимодействие
26. Конфликты и кризисы
27. Поставки и контракты

194
28. Качество в проекте

14 дополнительных элементов (Additional Elements )


1. Информатика в проекте
2. Стандарты и нормы
3. Решение проблем
4. Переговоры, деловые встречи
5. Постоянная (родительская) организация
6. Бизнес-процессы
7. Управление персоналом
8. Организационное обучение
9. Управление изменениями
10. Маркетинг
11. Управление системами
12. Безопасность, здоровье, экология
13. Правовые аспекты
14. Финансы и бухучет
Структура НТК Российской Ассоциации Управления проектами СОВНЕТ состоит из 43
элементов НТК, включающих 28 основных элементов ICB и 15 дополнительных
элементов, охватывающих содержание 13 дополнительных элементов ICB и 4 новых
элементов. Все элементы НТК сгруппированы в 4 раздела:
Раздел 1: Объекты управления
Раздел 2: Субъекты и инструментарий управления проектами
Раздел 3: Процессы управления проектами
Раздел 4: История и тенденции развития управления проектами.

Структура НТК СОВНЕТ и соответствие ее элементов, элементам ICB приводится в


Таблице 4-2.

Таблица 4-2. Структура НТК СОВНЕТ и соответствие ее элементам ICB

Разделы НТК Соответствующие разделы ICB

Объекты управления
(1) Projects and Project Management
1 Проект (Project)
(Проекты и управление проектами)
(3) Management by Project
2 Программа (Program)
(Проектноориентированное управление)
Цели и стратегии проекта (8) Project Objectives and Strategies
3
(Project Objectives and Strategies) (Цели и стратегии проекта)
Критерии успехов и неудач проекта (9) Project Success and Failure Criteria
4
(Project Success and Failure Criteria) (Критерии успехов и неудач проекта)
(12) Project Structures (Структуры
5 Структуры проекта (Project Structures)
проекта)
Фазы и жизненный цикл проекта (Project (6) Project Phases and Life Cycle
6
Phases and Life Cycle) (Фазы и жизненный цикл проекта)
(38) Marketing, Product Management
(Маркетинг)
7 Окружение проекта (Project Environment) (5) Project Context (Окружение и
участники проекта)
участники проекта)

195
Субъекты и инструментарий управления проектами

Участники проекта (Project (5) Project Context


Stakeholders) (Окружение и участники
8
проекта)

Постоянная или родительская (33) Permanent Organization


организация (Permanent or Parents (Постоянная (родительская)
9
Organization) организация)

Команда проекта (Project Team) (23) Teamwork (Команда проекта)


10
Управляющий проектом (Project (23) Teamwork (Команда проекта)
11
Manager)
Организационные структуры (12) Project Structures
проекта (Project Organization) (Организационные структуры
12 проекта)
(22) Project Organisation
(Организация проекта)
Руководство и лидерство (24) Leadership
13
(Leadership) (Руководство и лидерство)
14 Решение проблем (Problem Solving) (31) Problem Solving (Решение проблем)
Переговоры, деловые встречи (32) Negotiations, Meetings
15
(Negotiations, Meetings) (Переговоры, деловые встречи)
Информационные технологии в (29) Informatics in Project
16 проекте (Information Technologies (Информатика в проекте)
in Project)
Стандарты и нормы (30) Standards and Regulations
17
(Standards and Regulations) Стандарты и нормы)
Правовое обеспечение проекта (Legal (41) Legal Aspects
18
Aspects) (Правовые аспекты)

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


Управление проектом (Project (1) Projects and Project Management
19
Management) (Проекты и управление проектами)

Проектно-ориентированное управление (3) Management by Projects


20
(Management by Projects) (Проектно-ориентированное управление)
Управление системами (System (39) System Managemant
21
Managemant) (Управление системами)
Применение управления проектами (2) Project Management Implementation
22
(Project Management Implementation) (Применение управление проектами)
23 Инициация (Project Start Up) (10) Project Start Up (Запуск проекта)
Планирование проекта (Project (7) Project Development and Appraisal
24
Development) (Разработка и оценка проекта)
(19) Project Performance (Оценка
25 Выполнение проекта (Project Performance)
выполнения)
26 Контроль проекта (Project Controlling)
(20) Project Controlling (Контроль

196
проекта)
(11) Project Close Out (Закрытие
27 Закрытие проекта (Project Close Out)
проекта)
(13) Content, Scope
(Cодержание, предметная область) (17)
Управление предметной областью проекта
28 Configurations and Changes
(Project Scope Management)
(Конфигурация и изменения)

(14) Time Schedules


Управление проектом по временным
29 (Календарное планирование) (15)
параметрам (Project Time Management)
Resources (Ресурсы)
(16) Project Cost and Finance
Управление стоимостью и финансами (Стоимость и финансирование проекта)
30
проекта (Project Cost Management) (42) Finance and Accounting Финансы и
бухучет)
(28) Project Quality (Качество в проекте)
Управление качеством в проекте (Project
31 (30) Standards and Regulations
Quality Management)
(Стандарты и нормы)
Управление риском в проекте (Project
32 (18) Project Risks (Риски в проекте)
Risk Management)
(23) Teamwork (Команда проекта)
(35) Personal development
(Управление персоналом) (36)
Управление персоналом в проекте
33 Organizational Learning
(Project Human Resource Management)
(Организационное обучение) (26)
Conflicts and Crises (Конфликты и
кризисы)
(25) Communications (Коммуникации)
Управление коммуникациями в
(21) Information, Documentation,
34 проекте (Project Communications
Reporting (Информация, документация,
Management)
отчетность)
Управление поставками и контрактами в (27) Procurement, Contracts (Поставки и
35
проекте (Project Contracts Management) контракты)
(37) Management of Change
Управление изменениями в проекте (Управление изменениями) (17)
36
(Project Change Management) Configurations and Changes
(Конфигурация и изменения)
(40) Safety, Health and Environment
37
(Безопасность, здоровье, экология)
(26) Conflicts and Crises (Конфликты и
38
кризисы)
(4) System Approach and Integration
39
(Системный подход и интеграция)

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

40. Управление проектами за рубежом (Project Management in the World)


41. Управление проектами в России (Project Management in Russia)
42. Управления проектами в переходной экономике (Project Management in Transition
Economy)
43. Будущее управления проектами (Project Management in Future)

197
ГЛАВА 5. Тенденции развития управления проектами

Управление проектами в переходной экономике

Сформировавшееся преимущественно в 70-90 годы прошлого века современное


представление о профессиональном управлении проектами основано на вкладе и опыте
технически развитых стран с относительно стабильными социально-экономическими
условиями. Поэтому перед Россией, сравнительно недавно присоединившейся к «миру
УП», стоит проблема выбора: По какому пути должно идти национальное развитие и
применение УП?. Такая постановка проблемы поднимает ряд вопросов:
1. В чем сущность переходной экономики в России?
2. В чем существенные отличия планово-распределительной, переходной и рыночной
экономики с точки зрения современного УП?
3. Каково влияние этих различий на УП и его компоненты?
4. Возможно ли формирование общего понимания УП и его унификация?
5. Какие сферы и области УП допускают унификацию и какие требуют учета
естественно-исторических, социальных, экономических, национальных, культурных и
других особенностей?
6. Что нужно делать для развития и широкого применения УП в переходной период?

Общая характеристика социально-экономических изменений:


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

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


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

Структура и характеристика проектов и проектной среды:


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

198
 изменение инвестиционной политики, структуры и источников инвестиций;
 изменение инвестиционного климата, приведшее к резкому снижению
инвестиционной активности.

В России осуществляется структурная перестройка, которая резко меняет приоритеты, и


направление инвестиций, состав, назначение и сферы реализации программ и проектов.

С точки зрения влияния изменений в проектной сфере на компоненты УП можно


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

Происходящие в России политические и социально-экономические изменения неизбежно


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

Эти изменения в свою очередь привели к существенному отличию УП в переходной


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

199
область», «Конфигурация», «Коммуникации, информация»), достигают своего
экстремума в переходный период, а часть функций, менее чувствительных к этим
факторам («Качество», «Время», «Стоимость», «Персонал») - возрастают более
монотонно по мере приближения к развитой рыночной экономике.
3. Научные основы УП, структура и ядро «дерева знаний» (PM BOK) по УП, включая
состав и содержание функций УП, для всех типов экономик имеет всеобщий характер,
несмотря на существенные отличия в самих экономиках.
4. Имеющиеся различия в УП для разных типов социально-экономических сред не носят
принципиального характера и не затрагивают фундаментальных основ УП Эти
различия могут быть учтены и разрешены в рамках локальных дополнений к ядру PM
BOK, а также в руководствах, методиках и рекомендациях по применения УП.
5. При переходе к рыночной экономике резко возрастает вероятность изменений в
проекте и его окружении и связанные с ними риски. Это обстоятельство требует
включения в УП специальной интегрирующей функции «Управление изменениями».

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


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

Перспективные направления дальнейшего развития УП должны формироваться на


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

200
Развитие УП должно осуществляться путем его глобализации, унификации, локализации.

Глобализация УП – формирование общего для всех стран понимания и признания УП как:


 специальной сферы профессиональной деятельности, имеющей глобальное
распространение и охватывающей все области возможных приложений УП;
 комплексной прикладной научной дисциплины, имеющей свою теорию,
методологию, сферы и практику приложения:
 профессии менеджера проекта, требующей профессиональных специальных
знаний, навыков, умения и компетентности для успешного управления проектами.
В рамках глобализации УП будут решаться следующие проблемы и вопросы:
 формирование и обеспечение всемирного понимания и признания УП как
профессиональной специальной сферы деятельности, научной дисциплины и
самостоятельной профессии;
 формирование общих основ, включая:
 разработку всеобщего языка УП, включающего термины и их определения,
понятия и их толкования и т.д.;
 разработку общей теории и методологии УП;
 разработку международного ядра «свода знаний» (Project Management
International Body of Knowledge – PM IBOK), инвариантного по отношению к
сферам приложений и практике применения УП;
 организация, поддержание и координация глобального международного
сотрудничества организаций и специалистов по УП.

Унификация УП – формирование и разработка общих для всех стран унифицированных


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

Локализация УП – формирование и разработка различных компонентов, элементов и


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

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

Международная организация по стандартам ISO (International Organization for


Standardization) организована в 1947 году как организация институтов национальных
стандартов, в настоящее время объединяет 153 государства, включая Россию.
Официально Россию в ISO представляет Федеральное агентство по техническому
регулированию и метрологии РФ (Ленинский проспект, дом 9, Москва, В-49, ГСП-1,
119991, Россия; www.gost.ru)

202
Глоссарий

Административное завершение (Administrative Closure) Подготовка, сбор и распределение информации для формального
завершения проекта.

Администрирование контракта (Contract Administration) Регулирование взаимоотношений с Продавцом.

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

Анализ вариантов / «что, если?» / (What-if Analysis) Процесс оценки возможных альтернативных стратегий.

Анализ воздействия (Impact Analysis) – Оценка преимуществ продолжения принятого направления действий.

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

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

Анализ контрактных предложений (Bid Analysis) Анализ предложений и тендеров.

Анализ критического пути (Critical Path Analysis) Процедура для расчета критического пути и резервов времени в сетевом графике.

Анализ методом МонтеКарло (Monte Carlo Analysis) Метод оценки риска календарного плана, при котором осуществляется
многократная имитация выполнения проекта с целью определения функции распределения вероятности получения возможных
результатов.

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

Анализ расписания (Schedule Analysis) см. Сетевой анализ, Сетевое планирование.

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

Анализ сетевого графика (Network Analysis) Метод, используемый для расчета критического пути проекта, ранних и поздних
сроков выполнения работ и резервов времени. См. Анализ критического пути, Сетевой анализ и Сетевое планирование.

Анализ сметной стоимости выполненных работ (Earned Value Analysis) – См. Определение сметной стоимости выполненных
работ.

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

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

Архив проекта (Project File) Архив, содержащий все плановые и другие важные документы проекта.

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

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

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

Базисная дата начала (Baseline Start Date) см. Плановая дата начала.

Базисная дата окончания (Baseline Finish Date) см. Плановая дата окончания.

203
Базисные затраты (Baseline Cost) Количество денежных средств, предполагавшихся для выполнения работы по разработанному
базисному календарному плану.

Базисные сроки (Baseline Dates) Первоначально планировавшиеся сроки начала и окончан