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

Руководство PMI PMBoK® – это стандарт для управления проектами. Данный стандарт описывает процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.

PMI PMBOK был разработан и поддерживается Институтом управления проектами (PMI®, Project Management Institute) — это ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, объединяющая более 200 000 членов в 125 странах. Получить степень PMP можно здесь.

Разберем свод правил по этой книге с помощью методологии Ивана Селиховкина.

Содержание:

1. Структура PMBOK
2. Принципы проектного управления
3. Области знаний

10 областей знаний:

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

Области знаний разбиты на группы и состоят из 47 процессов управления проектом, объединенных  в 5 групп:

• Инициация
• Планирование
• Исполнение
• Мониторинг и Контроль
• Закрытие

Процесс — это задача, к примеру, создать расписание.

Пример: область знаний «управление сроками» на этапах «ПЛАНИРОВАНИЕ» и «МОНИТОРИНГ»:

Исключение: процессы из областей знания «интеграция» и «управление HR»:

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

ЧАСТЬ 2.

ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ

Фундаментальные принципы PMI:

1. Принцип яйца
2. Принцип удава
3. Принцип командности и проактивности

Разберем каждый принцип подробнее.

1. Принцип яйца

 «Скорлупа яйца» — Устав проекта, который пишется в начале проекта

«Внутреннее содержимое яйца»:

1. содержимое проекта (что собираемся сделать, требования и функционал)  > сроки, стоимость
2. коммуникации, риски, закупки, качество, HR

2. Принцип удава

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

Начало проекта — «инициация» > Середина проекта — «цикл Деминга»  > Конец проекта — «закрытие»

Если представить этапы в виде удава, то получается следующая картинка (этого в книге нет, это разработал И.Селиховкин):

3. Принцип командности и проактивности

1. Следует вовлекать команду в процесс планирования
2. Проактивность!

ЧАСТЬ 3. ОБЛАСТИ ЗНАНИЙ

Области знаний:

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

1. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА

payback period — (период оккупаемости)

ROI-return of investment — (возврат инвестиций)

internal rate of return — (внутренняя ставка возврата)

discounted cash flow — (дисконтированный денежный поток)

net present value — (чистый дисконтированный доход)

4.1. Разработка устава проекта 

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

Должен быть неизменным

Пример: Temp1 — ProjectCharter_2015

4.2. Разработка плана управления проектом

Как будем измерять выполнение планов, как закрывать проект.

4.3. Мониторинг и контроль работ проекта

Проверка хода проекта относительно всех планов: нужно сверить «план» и «факт» (укладываем в сроки?, укладываемся в бюджет? и т.п.)

4.4. Интегрированный контроль изменений

4.5. Руководство и управление работами проекта

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

4.6. Закрытие фазы или проекта

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

Для закрытия: 

• выдать результат (требуемый по scope baseline)
• проверить и сделать «что нужно» для закрытия (например, высвободить команду подписать акт приемки работ, получить отзыв от клиента и т.п.)
• зафиксировать полезную информацию по проекту («выученный урок» — что было успешно/неуспешно, какие самые большие риски и т.п.)

2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

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

5.1. Планирование управлением содержанием

Связать все планы воедино

5.2. Сбор требований

Сбор требований происходит посредством опроса заинтересонных лиц — интервью, анкеты и т.п. 

Пример матрицы требований RequirementMatrix_2015

5.3. Определение содержания

Делаем концепцию (техническое задание): детальное описание продукта и проекта

Определяем: что делаем и чего НЕ делаем в ходе проекта

Пример концепции: ProjectScope_2015

5.4. Создание иерархической структуры работ

Разделяй и властвуй!

Перед тем как представить иерархическую структуру работ желательно представить иерархическую структуру продукта

Иерархическая структура продукта (PBS — Product Breakdown Structure):

Иерархическая структура работ (WBS — Work Breakdown Structure):

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

От сложного – к простому.

5.5. Контроль содержания

Если понимаем, что не учли какой-то элемент, то вносим изменения в планы

5.6. Подтверждение содержания

3. УПРАВЛЕНИЕ ВРЕМЕНЕМ (СРОКАМИ) ПРОЕКТА

Вот как это выглядит на «Карте процессов»:

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

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

6.2. Определение операций

Декомпозиция технического задания в ДЕЙСТВИЯ!

Берем иерархическую структуру работ и переводим ее в «глаголы» — как добьем результата обозначенного в ИСР.

6.3. Определение последовательности операций

Перестраиваем ИСР в Сетевую диаграмму (PDM — Precedence Diagramming Method, Метод «операции в узлах» (метод предшествования).

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

6.4. Оценка ресурсов операций

Ресурсы делятся на:

• Возобновляемые – люди и оборудование
• Невозобновляемые – материалы

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

6.5. Оценка длительности операций

• Аналоговая оценка

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

Пример такой оценки: мы уже исполняли подобные работы и по опыту знаем, что на исполнение требуется 5 дней. Или не исполняли подобного, но погуглили или опросили экспертов.

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

опытный человек чешет затылок и сообщает: — ну, я это не раз делал, понадобится столько-то деньков.

Такой оценки имеет существенную особенность – оценки получаются заниженными, то есть оптимистичными.

• Оценка по трем точкам

Это оценка такого типа:

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

В результате нужно усреднить способом «оценка PERT» (PERT – Program Evaluation and Review Technique): 

Ожидаемая оценка = (Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6

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

Пример: Оценка по трем точкам.

6.6. Разработка расписания

Используйте программное обеспечение — диаграммы Ганта и т.п.

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

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

Операции могут иметь резервы, вызванные наличием параллельных цепочек:

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

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

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

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

6.7. Контроль расписания

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

4. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

Вот как это выглядит на «Карте процессов»:

7.1. Планирование управлением стоимостью

Как будем держать под контролем наш план

7.2. Оценка стоимости

Считаем себестоимость на основе временных зарат.

Стоимость проекта = стоимость всех работ проекта

Стоимость работы = стоимость израсходованных ресурсов.

Стоимость проекта = Сумма стоимостей израсходованных ресурсов.

7.3. Определение бюджета

Бюджет проекта – это распределение стоимости проекта по времени.

Базовый план стоимости (cost baseline)= себестоимость работ + резервы работ + резервы пакетов работ

Бюджет проекта (project budget) = Базовый план стоимости + управленческие резервы

Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»

«План по стоимости» — это бюджет проекта.

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

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

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

7.4. Контроль стоимости

Собираем все вместе  и контролируем календарный план проекта (MS Project):

Пример: The Practice Standard for Earned Value Management

Далее разберем:

• управление качеством,
• управление HR,
• управление коммуникациями,
• управление рисками,
• управление закупками,
• управление заинтересованными сторонами.

7. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ

• Определение заинтересованных сторон проекта.

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

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

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

• Распространение информации

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

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

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

• Подготовка отчетов об исполнении

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

Тур по книгам по управлению проектами:

1. Описать основные принципы работы в IT-сфере успешно удалось Тому Демарко и Тиму Листеру. Пожалуй, начать книжное путешествие стоит с их книги «Человеческий фактор: успешные проекты и команды».  Из книги узнаете: «как?», «зачем?» и «почему?»
2. Если в вашей работе много рисков, то возьмите на заметку  «Вальсируя с Медведями».
3. Руководителю стоит иметь в библиотеке книги Патрика Ленсиони «Пять искушений руководителя» и «Три признака унылой работы: История со смыслом для менеджеров (и их подчиненных)». Первая рассказывает о руководстве, вторая о том, как зажечь огонь в глазах команды и мотивировать на подвиги.

А вот сервис, где представлена деловая литература: http://filegiver.com/c/delovaya-literatura

Часть 3 подготовлена по материалам Селиховкина, PMlead.ru, http://projectbureau.ru/book/bp_work/ и книги PMBOK

Свод знаний по управлению проектами (англ. Project Management Body of Knowledge, PMBoK) представляет собой сумму профессиональных знаний по управлению проектами.

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

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

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

Группа процессов инициирования

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

• Разработка устава проекта

• Определение заинтересованных сторон проекта

Группа процессов планирования

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

• Разработка плана управления проектом

• Планирование содержания

• Определение содержания

• Создание иерархической структуры работ (ИСР)

• Определение состава операций

• Определение взаимосвязей операций

• Оценка ресурсов

• Оценка длительности операций

• Разработка расписания

• Стоимостная оценка

• Разработка бюджета расходов

• Планирование качества

• Планирование человеческих ресурсов

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

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

• Идентификация рисков

• Качественный анализ рисков

• Количественный анализ рисков

• Планирование реагирования на риски

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

• Планирование контрактов

Группа процессов исполнения

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

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

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

• Набор команды проекта

• Развитие команды проекта

• Распространение информации

• Запрос информации у продавцов

• Выбор продавцов

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

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

• Мониторинг и управление работами проекта

• Общее управление изменениями

• Подтверждение содержания

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

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

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

• Процесс контроля качества

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

• Отчетность по исполнению

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

• Наблюдение и управление рисками

• Администрирование контрактов

Группа завершающих процессов

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

• Закрытие проекта

• Закрытие контрактов

Большинство специалистов не знают, что PMBoK ® Guide целиком не является стандартом, несмотря на то, что PMI (Project Management Institute) ставят штамп стандарта ANSI на обложку. Стандартом является только «Стандарт управления проектами» (Project Management Standard for Managing a Project), брошюра размером всего в 40 страниц. Само же, привычное нам, руководство PMBoK гораздо обширнее – более шести сотен страниц (в русском издании 587).

Путём несложных подсчётов станет понятно, что стандарт, утверждённый ANSI составляет менее 10% от всего PMBoK, 93% которого написаны сотрудниками PMI, приглашёнными авторами и даже волонтёрами и никак не является стандартом. «Глава 3 – это стандарт по управлению проектами» сказано во введении четвёртого издания PMBoK. В пятом же издании, он приведён в Приложении №1. Оно так и называется: «Стандарт управления проектом». (стр. 417 русского издания PMBoK 5th Edition, 2013 год).

Рассмотрим основные бытующие мифы:

1.       PMBoK это «Международный стандарт».

Эта фраза, написанная на обложке Руководства PMBоK, также вводит читателя в заблуждение.

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

Какая международная организация по стандартизации объявила Руководство PMBoK стандартом – неизвестно. Первый миф был создан для продвижения PMI.

2.       PMBoK содержит лучшие практики.

Другой распространённый миф был создан маркетинговыми подразделениями PMI и их партнёрами для того, чтобы активнее продвигать сертификацию и обучение по PMBoK – единственный источник дохода для большинства из них. Он состоит в том, что PMBоK продвигает лучшие практики в управлении проектами.

Поиск по ключевым словам «лучшие практики» (best practices) и «PMBоK» выдают несколько результатов, но в основном они связаны с лучшими практиками из отраслей, не из руководства, которые могут быть использованы в управлении проектами. Нигде фраза «лучшие практики» не относится к самому Руководству. Наоборот, во введении на странице 2 прямым текстом сказано, что PMBoK включает в себя «хорошие практики», а не лучшие.

Получается, что PMBoK предлагает хорошие, но всё же не лучшие практики.

Зачем был создан этот миф? Затем, что если всё лучшее уже собрано в PMBoK, зачем искать что-то новое. Второй миф – для продвижения PMI и их партнёров

3.       PMBoK – это методология.

Третий миф также происходит из маркетинга, но его корни лежат в непонимании подлинной сути Руководства PMBoK, причём даже теми, кто читает по нему курсы.

Достаточно часто приходится видеть рекламу курсов или онлайн дискуссии, упоминающие методологию PMI, PMP или PMBoK® Guide. Так вот, ничего из этого не существует. PMBoK – это фреймворк, PMP – сертификат, а PMI не занимается созданием методологий.

Важно чётко понимать: Руководство PMBоK – общее, именно поэтому оно так популярно и подходит для «большинства проектов в большинстве случаев» (Руководство PMBоK, 5th edition, 2013). А методология или методика должна быть создана и адаптирована к нуждам конкретной организации и проектного окружения. Таким образом, PMBоK– это фреймворк, заготовка для методологии, а отнюдь не методология.

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

4.       PMBoK не применим к практике.

Как и предыдущий миф, этот миф происходит из непонимания Руководства PMBoK.

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

Также часто можно слышать: «Вы что, действительно хотите, чтобы мы реализовывали все 47 процессов? Для этого же нужна целая армия!». Мы обычно улыбаемся и отвечаем: «Да, вы должны их использовать, причём повторять на каждом этапе». Можете представить выражение лица. Это заблуждение, независимо от размеров необходимо реализовывать упомянутые группы процессов, в этом и заключается искусство управления проектами.

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

Институт управления проектами (PMI) выпустил 6 сентября 2017 года шестое издание Руководства к Своду знаний по управлению проектом (PMBоK Guide). Помимо традиционных стилистических и технических исправлений, новое издание PMBоK включает в себя идеи из PRINCE2, теории систем, и теорию гибких подходов к проектному управлению Agile.

Шестое издание PMBоK  разделено на 3 части:

• Само Руководство PMBоK.

• Стандарт управления проектом — раньше располагался в Приложениях. Часть содержания, которое раньше входило в состав Руководства, теперь отражено только в тексте. За счет этого информация меньше дублируется.

• Приложения, глоссарий, указатели.

Новую структуру можно только приветствовать — пользоваться изданием стало удобнее.

На этот раз PMI написали однозначно – «…настоящее Руководство не является методологией». И для пущего понимания описали подробно, как использовать Руководство.

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

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

Итак, Project Management Body of Knowledge, PMBoK, является сборником методологических норм, призванных стандартизировать управление проектами организации. Применение этих методик передвигает процесс управления проектом из «зоны искусства» в «зону ремесла», со всеми вытекающими последствиями. Сам человек, руководитель проекта, перестает быть уникальным, делается унифицированным (в известных пределах), и, соответственно, заменяемым. Работает ли это? Необходимо ли? Наверное, если проектный офис компании ведет полсотни проектов одновременно – это необходимо, если же проект уникален, и за ним стоит конкретная личность – вопрос спорный.

ГОСТ Р 54869—2011 Проектный менеджмент. Требования к управлению проектом.pdf

ГОСТ Р 54870—2011 Проектный менеджмент. Требования к управлению портфелем проектов.pdf

ГОСТ Р 54871- 2011 Управление-программой-проектов.pdf

Свод знаний по управлению проектами (PMBoK).pdf

Руководство PMBOK®-4 (полная) https://yadi.sk/i/O6vpqaEQ3Y7LEm

Руководство PMBOK®-5 (полная) https://yadi.sk/i/VVTDTjXC3Y7LLR

A Guide to the Project Management Body of Knowledge (далее PMBoK) — руководство к своду знаний по управлению проектами представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта.

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

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

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

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

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

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

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

Институт управления проектами PMI (Project Management Institute) использует данный стандарт в качестве основного справочного материала по управлению проектами для своих программ профессионального развития и сертификации.

История Project Management Body of Knowledge

Первое издание PMBoK, было выпущено Институтом управления проектами (PMI — Project Management Institute) еще в 1986 году. Это была революционная методология, которую изначально ориентировали на помощь членам института в рамках подготовки к экзамену PMP (Project Management Professional), а так же данная методология по управлению проектами должна была оказать влияние на подход к управлению проектами в будущем.

Методология получила название «A guide to the Project Management Body of Knowledge» или PMBoK. Уже в 1991 году методологию PMBoK признают национальным стандартом ANSI (American National Standards Institute). Первую редакцию такого стандарта по управлению проектами опубликовали в 1994 году. Через два года была выпущена вторая редакция PMBoK, это произошло из-за быстрого роста членов PMI.

В скором будущем появилась третья редакция и называлась она — PMBoK Guide 2000. В 2004 году PMI выпускает своё очередное творение — PMBoK Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI.

31 декабря в 2008 году вышла в свет новая версия методологии — PMBoK Fourth Edition, которая, как и свой предшественник претерпела значительные изменения и стала по сути таким же революционным изданием. В этой версии были изменены сами методики PMI. В стандарт включили дополнительные методики: ведения аналитических работ, прототипирование, итеративность и применение систем искусственного интеллекта с целью построения прогноза реализации и завершения проекта в части сроков и бюджета.

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

Дополнительная область знания — Управление заинтересованными лицами (разделили область знаний Communication Management на две: Communication Management и Stakeholders Management). Дополнительные процессы следующие — Plan Scope Management, Plan Schedule Management, Plan Cost Management, Plan Stakeholder Management, а также Control Stakeholder Engagement. Обновление программ сертификации произойдет с 1 июля 2013 года. Дата выпуска PMBoK Guide 6th Edition еще не известна, но PMI уже определились с годом — 2016 год.

Описание методологии PMBoK

Области знаний PMBoK

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

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

Управление интеграцией проекта (Project Integration Management)

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

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

Управление содержанием проекта (Project Scope Management)

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

Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ — ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

Управление качеством проекта (Project Quality Management)

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

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

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

Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.

Управление коммуникациями проекта (Project Communications Management)

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

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

Схема  процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Управление ожиданиями заинтересованных сторон проекта (начиная с пятой версии — PMBoK Fifth Edition, данные процессы вынесли в отдельную область знаний — Управление аинтересованными сторонами проекта Project Stakeholder Management), Отчеты об исполнении.

Управление рисками проекта (Project Risk Management)

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

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

Управление поставками проекта (Project Procurement Management)

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

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

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

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Группы процессов PMBoK

Все процессы в руководстве PMBoK разделяются на следующие группы:

Группа процессов инициации

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

• Разработка Устава проекта (Develop Project Charter)
• Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования

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

• Разработка плана управления проектом (Develop Project Management Plan)
• План управления содержанием (Plan Scope Management)
• Сбор требований (Collect Requirements)
• Определение содержания (Define Scope)
• Создание иерархической структуры работ — ИСР (Create Work Breakdown Structure — WBS)
• Разработка плана управления расписанием (Develop Schedule Management Plan)
• Определение операций (Define Activities)
• Определение последовательности операций (Sequence Activities)
• Оценка ресурсов операций (Estimate Activity Resources)
• Оценка длительности операций (Estimate Activity Durations)
• Разработка расписания (Develop Schedule)
• Разработка плана управления стоимостью (Develop Cost Management Plan)
• Оценка стоимости (Estimate Costs)
• Определение бюджета (Determine Budget)
• Планирование качества (Plan Quality)
• Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)
• Планирование коммуникаций (Plan Communications)
• Планирование управления рисками (Plan Risk Management)
• Идентификация рисков (Identify Risks)
• Качественный анализ рисков (Perform Qualitative Risk Analysis)
• Количественный анализ рисков (Perform Quantitative Risk Analysis)
• Планирование реагирования на риски (Plan Risk Responses)
• Планирование закупок (Plan Procurements)
• Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

Группа процессов исполнения

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

• Руководство и управление исполнением проекта (Direct and Manage Project Execution)
• Ообеспечение качества (Perform Quality Assurance)
• Набор команды проекта (Acquire Project Team)
• Развитие команды проекта (Develop Project Team)
• Управление командой проекта (Manage Project Team)
• Управление коммуникациями (Manage Communications)
• Осуществление закупок (Conduct Procurements)
• Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

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

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

• Мониторинг и управление работами проекта (Monitor and Control Project Work)
• Общее управление изменениямиОбщий контроль изменений (Perform Integrated Change Control)
• Подтверждение содержания (Validate Scope)
• Контроль содержанияУправление содержанием (Control Scope)
• Контроль расписанияУправление расписанием (Control Schedule)
• Контроль стоимостиУправление стоимостью (Control Costs)
• Процесс контроля качества (Perform Quality Control)
• Мониторинг и контроль коммуникаций (Monitor and Control Communications)
• Мониторинг и контроль рисков (Monitor and Control Risks)
• Контроль закупокконтрактов (Control Procurement)
• Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

Группа завершающих процессов

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

• Закрытие проекта или фазы (Close Project or Phase)
• Закрытие контрактов (Close Procurement)

Жизненный цикл по PMBoK

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

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

Инструменты и методы PMBoK

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

Данные инструменты и техники существуют сами по себе и уже давно применяются в различных направления деятельности человека. В процессах PMBoK существуют входы, выходы и методы. Именно при реализации методов определенных процессов и подразумевается применение руководителем проекта (Project Manager) тех или иных инструментов и техник. Ниже приведен список основных методов, инструментов и техник применимых к определенным процессам:

Методы

• Анализ дерева решений (Decision Tree Analysis).
• Анализ допущений (Assumptions Analysis).
• Анализ ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
• Анализ отклонений (Variance Analysis).
• Анализ сети (Schedule Network Analysis или Network Analysis).
• Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
• Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
• Aнализ чувствительности (Sensitivity Analysis).
• Быстрый проход (Fast Tracking).
• Выравнивание ресурсов (Resource Leveling).
• Декомпозиция (Decomposition).
• Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
• Метод Дельфи (дельфийский метод) (Delphi Technique).
• Метод критического пути (Critical Path Methodology, CPM).
• Метод критической цепи (Critical Chain Method).
• Метод Монте-Карло (Monte Carlo Analysis).
• Метод освоенного объема (Earned Value Technique, EVT).
• Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
• Мозговой штурм (Brainstorming).
• Оценка «снизу вверх» (Bottom-up Estimating).
• Планирование методом набегающей волны (Rolling Wave Planning).
• Управление освоенным объемом (Earned Value Management, EVM).

Инструменты

• Диаграмма Ганта (Gantt Chart).
• Диаграмма Парето (Pareto Chart).
• Иерархическая структура рисков (Risk Breakdown Structure, RBS).
• Информационная система управления проектами (Project Management Information System, PMIS).
• Матрица вероятности и воздействия (Probability and Impact Matrix).
• Матрица ответственности (Responsibility Assignment Matrix, RAM).
• Расписание контрольных событий (Milestone Schedule).
• Сетевая модель (Schedule Model).
• Система санкционирования выполнения работ (Work Authorization System).
• Система управления изменениями (Change Control System).
• Система управления конфигурацией (Configuration Management System).

Экзамены, сертификация и обучение

На данный момент в мире насчитывается более 470,000 менеджеров и специалистов по управлению проектами, имеющих сертификацию PMP – Project Management Professional. Степень по управлению проектами PMP, может получить каждый специалист из любой отрасли. PMP позволяет войти в ряды самого большого и престижного сообщества специалистов по управлению проектами.

Для получения степени PMP,  необходимо соответствовать определенным требованиям к образованию и опыту работы. Также необходимо пройти экзамен в виде теста на компьютере в специализированных аккредитованных центрах по всему миру (Registered Education Provider). Данный тест разработан для объективной оценки компетенций претендента в части управления проектами.

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

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

При себе иметь подтверждающие документы:

1. Сведетельство о высшем образовании.
2. Форма подтверждения опыта
3. Перечень обучающих программ, пройденых кандидатом (35 PDU)

Посредством теста на степень PMP оцениваются применение знаний и навыков, использование инструментов и методов применяемых на практике при управлении проектами. Еще в 1997 году были разработаны требования к экзамену. Претенденту необходимо выбрать один правильный ответ из 4 вариантов по каждому из 200 вопросов. Сам тест состоит из 175 вопросов, остальные 25 вопросов определяются, как претестовые и в зачет не идут. Все вопросы в тесте разрабатываются комиссией, состоящей из специалистов со степенью PMP. Вопросы входящие в тест, ежегодно проверяются на соответствие экзаменационным требованиям. Для успешного прохождения теста, претенденту, за 4 часа, необходимо положительно ответить на 106 вопросов из 175. Получается, что проходной балл по экзамену составляет 61%.

Подготовка к экзамену PMP

Из множества учебников и материалов для подготовки к экзамену на степень PMP основным конечно же является сам свод знаний по управлению проектами — PMBoK Guide. Данный стандарт на двух языках (английский и русский) и множество дополнительных материалов (книг и учебников) по управлению проектами можно приобрести в специализированных on-line магазинах PMI.

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

Содержание экзамена PMP

Далее в процентном соотношении представлена разбивка вопросов экзамена по группам процессов:

• Инициация проекта (Project Initiating) – 13 % вопросов
• Планирование проекта (Project Planning) – 24 % вопросов
• Исполнение проекта (Project Executing) — 30 % вопросов
• Контроль проекта (Project Control) – 25 % вопросов
• Завершение проекта (Project Closing) – 8 % вопросов

В свое время, PMI провело исследование по описанию ролей (The Role Delineation Study), которое в последствии легло в основу Кодекса Профессиональной Этики (PMP Examination Specification). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Просмотры: 32 933

Иллюстрация: May Gauthier / Unsplash / Pngegg / Annie для Skillbox Media

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

Больше 10 лет опыта в разработке крупных проектов и запуске цифровых продуктов для развития бизнеса (МТС, Х5, «Эльдорадо», «Авилон», «Русал»). Автор и преподаватель курса Skillbox «Управление проектами».

PMBoK (Project Management Body of Knowledge) — свод знаний по управлению проектами, в котором содержатся методики, подходы, инструменты и техники, необходимые для эффективного выполнения проекта.

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

PMBoK выпускает PMI — Институт управления проектами, одна из ведущих мировых организаций в области проектного управления. Кроме разработки единых стандартов управления проектами, PMI сертифицирует проектных менеджеров.

В статье для Skillbox Media разберёмся:

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

---

Как мы сказали выше, в PMBoK описаны различные методики, подходы, инструменты и техники управления проектами.

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

Первый PMBoK вышел в 1996 году. С того времени его регулярно обновляют и дополняют, поскольку появляется новый управленческий опыт, новые проблемы и их решения. Актуальное издание на январь 2023 года — PMBoK 7. Его выпустили в 2021 году.

С помощью PMBoK решают две основные задачи:

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

Стандарт от PMI — самый распространённый, но не единственный в области управления проектами. Есть и другие стандарты — например, PRINCE2, IPMA ICB, P2M, «ПМ Стандарт».

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

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

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

PMBoK включает в себя:

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

Основное содержание PMBoK поделено на десять областей знаний — фокусов внимания менеджеров проектов. Вот они:

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

Согласно PMBoK, жизненный цикл любого проекта состоит из пяти этапов. Вот они:

• инициация;
• планирование;
• исполнение;
• мониторинг и контроль;
• завершение.

На каждом этапе возникают свои процессы, которые PMBoK подробно описывает.

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

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

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

Мониторинг и контроль. Процессы этой группы идут параллельно с процессами планирования и исполнения. Они предполагают непрерывную проверку соблюдения планов проекта — сроков, качества, стоимости.

Завершение. Эти процессы формализуют передачу результатов проекта и закрывают его. На этом этапе составляют финальные отчёты, передают результат заказчику, формируют окончательную документацию и распускают команду.

PMBoK наиболее эффективен в проектах двух видов:

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

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

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

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

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

• Проекты запуска новых продуктов — стартапы, где неизвестно, какой результат проекта будет в итоге успешным. Команда стартапа на протяжении всего проекта ищет оптимальный результат, постоянно меняет цели и пути их достижения.
• Проекты НИОКР. В таких проектах тоже нет чётких целей и задач. В рамках исследований учёные ищут новые свойства, материалы, новые технологии. Работу таких проектов нельзя описать на этапе подготовки.

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

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

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

• PMBoK — свод профессиональных знаний о различных методиках, подходах, инструментах и техниках, необходимых для эффективного выполнения проекта.
• PMBoK рассматривает любой проект как набор процессов, разделённых на пять групп: инициация, планирование, исполнение, мониторинг и контроль, завершение. Эти же группы процессов соответствуют жизненному циклу проекта.
• Лучше всего методики PMBoK подходят типовым и мегапроектам с чётко обозначенными целями и задачами.
• PMBoK не будет эффективен в проектах, где нужно определять результат в процессе или искать оптимальный путь к достижению результата. Как правило, таковы проекты стартапов и НИОКР.

• Купить и скачать PMBoK, а также узнать о его актуальных обновлениях можно на официальном сайте PMI. Версия для скачивания в формате PDF доступна на нескольких языках, включая русский.
• Проект — временное предприятие для создания уникального результата. В отдельном материале мы привели примеры проектов и разобрали, чем они отличаются от процессов.
• В проектном управлении много разных фреймворков и методик. Подробнее о них можно почитать в статьях Skillbox Media: в них разбирали Waterfall, Scrum, Agile, Kanban, метод критического пути.
• Чтобы управлять проектами, нужно уметь презентовать идеи, работать с бюджетом, мотивировать команду, планировать и распределять задачи. Всему этому можно научиться на курсе Skillbox «Профессия Менеджер проектов».

Научитесь: Профессия Менеджер проектов
Узнать больше