Скачать книгу руководство к своду знаний по управлению проектами (руководство pmbok). шестое издание. agile: практическое руководство бесплатно

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

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

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

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

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

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

Project Management Plan Components and Project Documents

Please note the following changes to the project management plan components and project documents:

  • The components of the project management plan that are inputs to a process, or that are updated as outputs from a process, are not listed individually in the inputs or outputs. Rather, the project management plan is the input and project management plan updates is the output.
  • Beneath the input/output table, a list of potential project management plan components is identified. However, the components of the project management plan that will be inputs or updated depends on the needs of the project.
  • Project documents are listed as an input and project documents updates is listed as an output, as appropriate. Beneath the input/output table there is a list of potential project  documents that may be inputs, or may be updated as an output. The needs of the project will determine the actual project documents that should be inputs or updated as an output.

This is what we know about the upcoming changes yet. There may be additional changes; as a result from the actual exposure draft review for instance.

We will update this article accordingly.

first published @ projectmanagement.plus

Немного о моем опыте

PMO Competence Manager в SoftServe, в прошлом — Senior Project Manager. Вел несколько крупных аккаунтов, вырастил из нескольких небольших проектов третий по величине аккаунт на SoftServe. На данный момент ответственный за направление People Excellence. Занимаюсь разработкой моделей компетенций для проектных менеджеров. Оптимизирую процессы оценки знаний и performance руководителей проектов всех уровней, отбора внешних кандидатов. Координирую менторские и on-boarding программы для PM-ов. Совместно с SoftServe University разрабатываем тренинги для проектных менеджеров.

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

Примерно через год после сдачи PMP, на одном проекте с крупным британским концерном, столкнулся с процессами, которые отличались от тех, что в PMBoK. Оказывается, у них на корпоративном уровне внедрен PRINCE2. Чтобы лучше понимать процессы на стороне клиента, прочитал Managing Successful Projects with PRINCE2 2017 Edition. Уже после окончания проекта достаточно хорошо разобрался в этом подходе и без труда сдал экзамен.

На другом проекте мы перешли от Fixed-Price модели к SLA поддержке. Решил построить процесс согласно best practices и изучил ITIL Service Operation. Через некоторое время для более полного понимания картины прочитал остальные 4 книги и решил сдать экзамен, больше чтобы проверить свои знания и понимание.

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

Преимущества сертификации

Сертификация подтверждает ваши достижения
в профессиональном сообществе.

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

Наличие PMP существенно повышает востребованность
на рынке труда, в том числе международном. В США и странах Евросоюза наличие сертификации является одним из существенных критериев при выборе кандидата.

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

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

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

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

Чаще всего это функциональная структура, наиболее распространённая в России.

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

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

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

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

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

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

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

На данный момент в мире насчитывается более 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). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Обзор PMBoK

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

Руководство PMBoK знакомит с ключевыми понятиями и терминами в области управления проектами, определяет 10 областей знаний проектного управления, жизненный цикл проекта, группы процессов и процессы (в том числе входы, выходы и активности в рамках конкретного процесса), определяются внешние и внутренние организационные факторы, окружающие проект или оказывающие влияние на его успех, методы и методики, применяемые в рамках отдельных областей знаний по управлению проектами. Является основным стандартом по управлению проектами в США и некоторых других странах (в России, Украине и Белоруссии данный стандарт носит рекомендательный характер).

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

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

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

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

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

Скачать PMBoK нельзя и данный стандарт распространяется только на платной основе.

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

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

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

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

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

Уведомление

Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

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

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

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

Акцент на управлении знаниями

В области знаний «Управление интеграцией» добавлен новый процесс «Управление знаниями проекта»

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

В описании процесса заслуживает внимания два метода «Управление знаниями» и «Управление информацией».

К методам управления информацией авторы относят в том числе поиск информации в Интернете и использование информационной системы управления проектами.

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

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

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

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

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

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

Processes; Process Groups and Knowledge Areas

The Process Groups remain the same in the Sixth Edition, although two Knowledge Areas have new names:

Project Time Management is now Project Schedule Management, emphasizing the importance of scheduling in project management. This aligns with PMI’s Practice Standard for Scheduling.And Project Human Resource Management is now Project Resource Management. We discuss both team resources and physical resources in the processes of this Knowledge Area.

There are three new processes in the Sixth Edition:

  • Manage Project Knowledge is part of the Executing Process Group and Project Integration Management knowledge area.
  • Implement Risk Responses is part of the Executing Process Group and Project Risk Management knowledge area.
  • Control Resources is part of the Monitoring and Controlling Process Group and Project Resource Management knowledge area.

Estimate Activity Resources is still part of the Planning Process Group, but it is associated with Project Resource Management processes instead of Project Schedule Management processes.

Since we do not know about deleting processes now, the overall number of processes seems to increase to 50!

In addition, some processes have different names. For example, to align with research showing that project management is more about facilitating and managing than controlling, we have shifted several processes from a Control function to a Monitor function. In other cases, we have aligned the process name with the intent of the process. The chart below identifies the overall name changes.

Perform Quality Assurance

Manage Quality

Plan Human Resource Management

Plan Resource Management

Control Communications

Monitor Communications

Control Risks

Monitor Risks

Plan Stakeholder Management

Plan Stakeholder Engagement

Control Stakeholder Engagement

Monitor Stakeholder Engagement

The function of the Close Procurement process has now been captured within Control Procurements and Close Project or Phase. Research shows that few project managers have the authority to formally and legally close a contract. Project managers are responsible to determine that work is complete, records indexed and archived, and responsibilities transferred appropriately. Thus, they have now included work associated with Close Procurements within the aforementioned processes.

Project Management Plan Components and Project Documents

Please note the following changes to the project management plan components and project documents:

  • The components of the project management plan that are inputs to a process, or that are updated as outputs from a process, are not listed individually in the inputs or outputs. Rather, the project management plan is the input and project management plan updates is the output.
  • Beneath the input/output table, a list of potential project management plan components is identified. However, the components of the project management plan that will be inputs or updated depends on the needs of the project.
  • Project documents are listed as an input and project documents updates is listed as an output, as appropriate. Beneath the input/output table there is a list of potential project  documents that may be inputs, or may be updated as an output. The needs of the project will determine the actual project documents that should be inputs or updated as an output.

This is what we know about the upcoming changes yet. There may be additional changes; as a result from the actual exposure draft review for instance.

We will update this article accordingly.

first published @ projectmanagement.plus

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.

Успех проекта

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

Но динамика изменения требований в современных проектах столь высока, что к своему финалу, проект вылезает за все мыслимые и немыслимые ограничения. Поэтому управление изменяющимися требованиями, фиксация их в документах проекта и пересогласование базовых планов становится всё более востребованным навыком руководителя проекта. Это нашло отражение в PMBOK 5 в предложении “Успех проекта следует отнести к реализации последних базовых планов, утверждённых уполномоченными заинтересованными сторонами”. По-моему, лучше и не скажешь. Если умудрился согласовать с заказчиком увеличение сроков и бюджета проекта за два дня до окончания проекта, то проект успешен, не взирая на 2-кратное превышение сроков и 3-кратное увеличение бюджета.

How is PMBOK® Updated?

Following is the six-step followed by PMI to update PMBOK.

  1. PMI charters a volunteer committee to develop or update a standard.
  2. The volunteer committee drafts and/or refines an existing standard.
  3. A group of subject matter experts review initial drafts of the standard and provide feedback to the committee.
  4. The committee revises the draft standard and prepares a document for public review and comment. The committee considers input from the public and may revise the standard in response. -> We see the PMBOK exposure draft at the end of this step.
  5. The final standard is presented the PMI Standards Consensus Committee which consists of volunteers from the profession for final validation.
  6. The new standard is submitted for approved by the PMI Director, Standards & Publications before it is released

PMBOK Seventh Edition exposure draft has been published for public review and comment on 15 January 2020 and review/comment was available until 14 February 2020. Based on the reviews and comments, PMI will be working on the development of PMBOK 7th Edition. The planned release date for PMBOK Seventh Edition is Q4 2020.

EditionsEdit

The PMBOK has gone through 6 editions — starting with the first release in 1996.

6th EditionEdit

The 6th edition was released September 6, 2017.  This wiki does not yet reflect all the changes for the 6th version. As of March 26,2018, the exams for PMP and CAPM certifications changed to reflect this new version. PMI recommends «PMBOK Guide – Sixth Edition (2017).» as the format for citations.

The 6th edition builds on prior versions and is released with the Agile Practice Guide. The PMBOK has 3 parts. Part one has a similar structure to the 5th edition. It begins with some introductory information about project management and then has chapters organized around the knowledge areas. Part two, «The Standard for Project Management» discusses the same project processes, but is organized by process groups. Part two includes more examples and specifies which project documents may need updates. Part three has the appendices, including the glossary and more details about the changes for the edition.

In this edition the names of two knowledge areas changed. Time Management became Schedule Management. Human Resources Management became Resource Management. Three processes were added. One was removed. A few others were renamed. «Every Knowledge Area now features four new sections:

  • Key Concepts
  • Trends and Emerging Practices
  • Tailoring Considerations
  • Considerations for Agile/Adaptive Environments»

There are three new processes in the 6th edition: Manage Project Knowledge, Implement Risk Responses, and Control Resources. Estimate activity resources remains in the planning process group, but moves from the time management (now schedule management) knowledge area to resource management. Other changes are the use of the project management plan (rather than its component parts as inputs and outputs), more emphasis on adaptive methodologies (e.g., Agile), and an additional chapter on the PMI Talent Triangle.

5th EditionEdit

The fifth edition has a copyright of 2013. This edition added a knowledge area, some processes, changed the names of other processes, and made other changes.

The chapters in the 5th edition PMBOK are

  1. Introduction
  2. Organizational influences and project life cycle
  3. Project management processes
  4. Project integration management
  5. Project scope management
  6. Project time management
  7. Project cost management
  8. Project quality management
  9. Project human resource management
  10. Project communication management
  11. Project risk management
  12. Project procurement management
  13. Project stakeholder management

1st through 4th EditionsEdit

The «3rd edition was released in 2004, with some major changes as compared to previous edition. 4th edition was released in 2008. The latest, 5th edition is released in 2013.»

The 4th edition was released in 2008.

The 3rd edition was released in 2004.

The 2nd edition was released in 2000.

The 1st edition was released in 1996.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector