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

Акцент на адаптации

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

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

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

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

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

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

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

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

Необходимо соответствовать первой или второй категории. Первая категория — высшее образование (не ниже бакалавра), 4500 часов (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.

Дополнительно можно выделить труд Риты Мулкахи (Rita Mulcahy) — PMP Exam Prep (Rita’s Course in a Book for Passing the PMP Exam), целью которого является подготовить читателя к экзамену PMP (Project Management Professional). Даннвая книга не переписывает PMBoK, как это случается зачастую с остальными материалами по подготовке к экзамену, а даёт понимание того, как будет проходить сертификация, какие будут вопросы т.е. является прикладной (Рисунок 5).

Рисунок 5. PMP Exam Prep (Rita’s Course in a Book for Passing the PMP Exam)

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

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

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

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

Терминология и гармонизация

Авторы с гордостью утверждают, что вся терминология приведена в соответствие с PMI Lexicon of Project Management Terms. При этом за приоритет взята именно терминология из PMI Lexicon. Если ещё и перевод PMBOK 5 на русский язык начнётся с создания правильной терминологии, то есть надежда получить грамотно переведённый свод знаний.

Также PMBOK 5 приведён в соответствие со стандартом ISO 21500:2012 “Guidance on project management” и обеспечено согласование названий, процессов, входов, выходов, инструментов и методов с другими стандартами PMI (типа, “The Standart for Portfolio Management” и др.).

Наконец-то перестали ставить народ в ступор своим “положительным риском”. Ведь что такое риск? Это возможность опасности или неудачи! Термин происходит от греческого risikon, т.е. “утёс” или “скала”. В времена величия и могущества Древней Греции “рисковать” означало “лавировать на судне между скалами”, т.е. потенциальную опасность неудачи.

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

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

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

Начинать внедрение КСУП оптимальнее не с разработки методологии управления проектами, как это часто бывает, а с практических шагов:

• создание Проектного офиса и выделение ответственных за внедрение
• определение общих принципов и шаблонов методологии
• формирование реестра проектов и выбор контрольных точек для контроля на уровне менеджмента
• формирование отчетности по проектной деятельности для руководства
• проведение еженедельных/ежемесячных совещаний на уровне руководства по внедрению КСУП

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

Новые процессы

Здесь нет каких-либо сюрпризов, т.к. с 2000 года в каждом новом издании PMBoK появлялись новые процессы. Если в PMBoK 3d Edition было 39 процессов, то в четвертом издании их стало 42, в пятом 47, ну а в шестом мы видим уже 49 процессов (страшно представить сколько процессов будет к десятому изданию).

В PMBoK 6th Edition добавлено 3 новых процесса и удален один старый «Закрытие закупок» (англ.Close Procurements). Это изменение сделало новый PMBoK более целостным и заполнило пробелы в областях, которые не были должным образом раскрыты в ранних выпусках

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

Вот те новые три процесса, которые появились в PMBoK 6th Edition:

Manage Project Knowledge — Управление знаниями проекта

Область зананий: Управление интеграцией

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

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

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

Implement Risk Responses — Реализация ответных мер

Область зананий: Управление рисками

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

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

Кроме того, PMI добавил новую меру реагирования на риск — «Эскалация» (англ., Escalation). Эту меру предлагается использовать для рисков, выходящих за рамки проекта, чтобы передать риск соответствующему внешнему для проекта человеку или организации.

Control Resources — Контроль ресурсов

Область зананий: Управление ресурсами

Группа процессов: Мониторинг и контроль

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

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

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

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

PMBOK – это методология

Первый миф был создан для продвижения PMI, второй – для продвижения PMI и их партнёров. Третий миф также происходит из маркетинга, но его корни лежат в непонимании подлинной сути Руководства PMBOK, причём даже теми, кто читает по нему курсы. К сожалению, даже такие люди иногда становятся Зарегистрированными Провайдерами Обучения PMI.

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

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

Таким образом, PMBOK– это фреймворк, заготовка для методологии, а отнюдь не методология.

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

О бизнес-школе в цифрах

1989	26000+	323
Год основания ИМИСП — первой бизнес-школы в Санкт-Петербурге	Количество выпускников образовательных программ бизнес-школы ИМИСП	Посадочных места в 9 аудиториях исторического здания бизнес-школы.

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

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

Управление проектами на основе международного стандарта PMI PMBOK v.6

Подробности материала

Код курса
УП-312

Форма обучения
Очная

Объем часов
36

Даты обучения

30.11 — 04.12.20

Стоимость
27000 руб.

ПРОГРАММА КУРСА

Каждый модуль состоит из повествовательного блока и практики. По завершении курса участники будут знать подходы и методы как классического (на основе стандарта PMI PMBoK v.6) так и современного (Agile) проектного управления, будут уметь самостоятельно управлять небольшими проектами.

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

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

1.1. Основы проектного управления, стандарты – PMI PMBoK, PRINCE2, ГОСТ.

• Проекты и программы.
• Классификации проектов.
• Этапы проекта – инициирование (бизнес кейс, анализ реализуемости, подготовка устава проекта), планирование, исполнение, закрытие.

1.2. Процессы проектного управления – от бизнес кейса до закрытия проекта.

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

1.3. Эволюционные подходы к управлению проектами.

• Структура проектов в ГОСТ-34 – анализ, ТЗ, эскизный и технический проекты, подготовка рабочей документации.
• Построение прототипов как способ уточнения требований.
• Практические правила анализа проектов.

1.4. Инструменты управления проектами.

• От стандартных форм и шаблонов документов (MS Office) к системам управления инвестиционными программами (HP PPM).
• Структуры работ, сетевые графики, диаграммы Ганта, гистограммы ресурсов, инженерия стоимости в MS Project.
• Что подсказывает практика автоматизации проектного управления.

1.5. Проектный офис.

• Зрелость и возможности проектного офиса.
• Проектный офис как центр инновационных компетенций компании.

2. Современные подходы проектного управления. 

2.1. Современные подходы – Agile.

• Скрам, бэклог, спринты, стэндапы, канбан.
• Преимущества и риски Agile-подхода.
• Использование Agile за пределами проектного управления.
• Почему Agile работает не у всех.
• Современные программные проекты – постоянные изменения, постоянное внедрение в эксплуатацию (DevOps).
• А/В-тестирование.
• Инфраструктура как ПО.
• Технологии и культура как критические факторы успеха.

2.2. Успехи и провалы проектов как результат заинтересованности.

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

Другие изменения

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

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

• Добавлен процесс «Контроль ресурсов»;
• Удален процесс «Закрытие закупок»;
• Процесс «Оценка ресурсов операций» перенесен в область знаний «Управление ресурсами проекта».

Какие существуют группы процессов PMBOK?

Существуют 5 групп процессов PMBOK:

1. Группа процессов «Подготовка»: процессы, необходимые для запуска нового проекта или новой фазы проекта. 
2. Группа процессов «Планирование»: процессы, связанные с определением и планированием объема проекта, а также планированием способов его реализации. 
3. Группа процессов «Выполнение»: процессы, непосредственно связанные с осуществлением мероприятий и выполнением задач проекта. 
4. Группа процессов «Контроль»: процессы, связанные с отслеживанием, мониторингом, отчетностью и контролированием хода работы над проектом. 
5. Группа процессов «Завершение»: процессы, необходимые для окончательного завершения и сдачи проекта или фазы проекта. 

Подготовка

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

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

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

Обычно в уставе проекта также указываются:

• Необходимые ресурсы;
• Ключевые участники проекта; 
• Временные рамки с ключевыми вехами;
• Детальная смета;
• Известные риски, проблемы и зависимости. 

Планирование

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

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

PMP – это «живой» документ, который обновляется и уточняется на протяжении всего проекта по мере внесения изменений. 

Выполнение

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

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

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

Контроль

Группа процессов «Контроль» – вторая по величине группа, в нее включены 12 процессов. Эти процессы действуют на протяжении всего проекта и нужны для обеспечения надзора. Они также помогают определять и устранять потенциальные проблемы. 

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

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

Завершение

Группа процессов «Завершение» состоит всего из одного главного процесса: завершение проекта или одной его фазы

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

Входы

.1 Факторы внешней среды предприятия

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

.2 Активы организационного процесса

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

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

.3 Описание содержания проекта

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

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

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

Внимание к проблемам бизнеса

В шестом издании Руководства больше внимания уделяется бизнес-вопросам реализации проектов

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

Бизнес-кейс. Документ «Бизнес-кейс» упоминался и в пятой редакции Руководства, но в новой редакции подробнее описано его назначение и содержание. Разработчики преследовали цель согласовать PMBOK и другое руководство PMI по бизнес-анализу (Business analysis for Practitioners: A Practice Guide).

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

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

PMBOK не применим к практике

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

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

Правда ли это? И почему такие утверждения?

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

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

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

Why is PMBOK® changing?

Until now, PMBOK was mainly focusing on waterfall project management techniques. However, with the fast pace of technology, competition is harsher than it was never before. Product life cycles are shorter and requirements of the product or project can change over time depending on the progress of the project.

With conventional project management approaches, it is not possible to welcome rapidly changing requirements to the projects. That is why agile project management methods and approaches emerged in the 2000s. These agile frameworks started to be adapted by many organizations in project management, especially in the IT and software industry.

PMP is the most reputable project management certification around the world with nearly one million PMP certified professionals. PMBOK is the backbone of the PMP certification exam content.  Since the project management dynamics, popular frameworks, and trends are changing, PMBOK must be relevant to the changing dynamics of the project management profession as well. That is the main reason why PMBOK is changing every three to five years.

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

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

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

Активы процессов — разделены на 2 группы:

1. процессы, политики, процедуры,
2. репозиторий знаний организации.

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

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

Типы организационных структур. В 5-м издании описывалось 5 типов организационных структур. В 6-м издании к ним добавили еще пять:

1. Органичная или простая
2. Мультидивизиональная
3. Виртуальная
4. Гибридная
5. Офис управления портфелем/программой/проектом

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

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

Complete Application

Once you’ve determined you meet the eligibility criteria, it’s time to apply. Collect the following information and then use our online certification system to guide you through the process.

• Contact information — email, address, phone number
• Education attained — school attended, level of education attained, degree date
• Domain experience — details of the projects, programs, portfolios you’ve worked on including qualifying hours, dates of employment, role, organization details, reference, and experience summary
• Domain education — names of courses completed, institutions attended, dates, qualifying hours

Once you open an application, it will remain active for 90 days after which time it will close.

Tip: To complete the application quickly, gather all of the information and documentation you need before opening it. Otherwise, it will likely take you multiple sessions to complete.

Коммуникации проекта

Давно назревало упорядочивание информации и знаний генерируемых во время реализации проекта. Одним из самых революционных изменений в PMBOK 5 является применение модели DIKW (Data, Information, Knowledge, Wisdom) — информационной иерархии, где каждый уровень добавляет определённые свойства к предыдущему уровню:

• В основании находятся данные.
• Информациядобавляет контекст.
• Знаниедобавляет ответ на вопрос «как?» (механизм использования).
• Мудростьдобавляет ответ на вопрос «когда?» (условия использования).

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

1. Данные об исполнении работ. “Сырые” наблюдения и измерения, выявленные в ходе выполнения проектных работ.
2. Информация об исполнении работ. Данные об исполнении работ анализируется и интегрируются на основании взаимосвязей между различными областями/этапами проекта.
3. Отчёты об исполнении работ. Физическое или электронное представление информации об исполнении работ, предназначенное для принятия решений, освещения вопросов и проблем, выработки действий или осознания ситуации.

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

Ну, а процессы, которые путали многих размытостью своих границ и непонятной последовательностью: “Распространение информации” и “Подготовка отчётов об исполнении”, переименованы, соответственно, в “Управление коммуникациями” и “Контроль коммуникаций” с логичными входами и выходами.