Pmbok 7 на русском – Новый PMBOK будет основан на принципах, а не на процессах / Хабр

Содержание

Новый PMBOK будет основан на принципах, а не на процессах / Хабр

Последние версии PMBoK (Project Management Body of Knowledge) не сильно отличались друг от друга. В этот раз нас, похоже, ждут серьёзные изменения. Новый, седьмой, PMBok будет principle-based, то есть построен на принципах, а не на процессах. Разбираемся, что это значит.

Что такое стандарты, основанные на процессах?


Все предыдущие версии Руководства PMBOK были основаны на процессах с их входами и выходами, инструментами и методами. В последней, шестой версии процессов было 49, в предпоследней — 47.

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

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

Что такое стандарты, основанные на принципах?


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

Под принципом обычно понимается:

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

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

Примером методологии, основанной на принципах, является PRINCE2. NUPP Guide — это набор из 6 принципов управления проектами.

Некоторые стандарты PMI также основаны на принципах. Например, недавно выпущенное Benefits Realization Management: A Practice Guide перечисляет такие принципы, как:

  • Чистые выгоды оправдывают использование вложенных ресурсов
  • Управление выгодами планируется и управляется всесторонне.

The Standard for Risk Management включают в себя:
  • Стремитесь к совершенству в практике управления рисками
  • Согласуйте управление рисками с организационной стратегией и практикой управления.

На каких принципах будет основан PMBoK 7?


Это открытый вопрос. Сейчас над этим работает core team из 12 авторов. Подготовленный драфт будет направлен review team из 70 человек.

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

Краткая справка


  • PMBoK (Project Management Body of Knowledge) — свод знаний по управлению проектами, выпускаемый PMI (Project Management Institute)
  • Первая версия PMBoK была выпущена PMI в 1996 году
  • Текущая, шестая, версия была выпущена в сентябре 2017 года и переведена на 11 языков
  • По состоянию на 30 июня 2019 года в обращении 6 467 214 копий PMBoK

Источники


→ PMBOK Guide 7th edition: Interesting Changes
→ Baking Principles

habr.com

PMBoK | Блог 4brain

Прежде чем перейти к предмету статьи, мы хотели бы сказать, что вы не должны рассматривать ее в качестве всеобъемлющего пособия по управлению проектами. Мы лишь хотим простым языком познакомить вас со сводом соответствующих знаний, который и называется PMBoK (Project Management Body of Knowledge).

Из нашей статьи вы узнаете, что вообще представляет собой PMBoK, в чем состоит основная концепция этого Стандарта, каковы основные процессы управления проектами. Также мы расскажем, зачем нужен сертификат PMP (Project Management Professional) и как получить его.

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

Что такое PMBoK?

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

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

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

Концепция PMBoK

В PMBoK выделяются 44 главных процесса, происходящих при управлении проектами. Эти процессы разделены на пять основных групп:

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

Каждый из этих процессов относится к одной из девяти (в некоторых случаях – десяти) областей знаний, определяемых PMBoK:

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

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

  • Входы
  • Выходы
  • Инструменты и методы

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

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

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

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

Установление связей заменяется в PMBoK специальной областью знаний «Управление интеграцией проекта». Благодаря интеграции устанавливаются и поддерживаются в актуальном состоянии необходимые связи. Чтобы у вас сформировалось целостное понимание вышесказанного, предлагаем посмотреть 10-минутное видео от специалиста по проект-менеджменту Михаила Софонова.

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

Основные элементы PMBoK

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

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

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

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

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

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

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

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

Согласно PMBoK, классификация участников проекта такова:

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

Заметим, что PMBoK говорит как об ответственности участников проекта, так и об их ожиданиях. Управление ожиданиями входит в число прямых обязанностей проект-менеджера.

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

Главные проектные документы

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

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

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

И, естественно, мы не могли не сказать еще об одном аспекте управления проектами, которому PMBoK уделяет огромнейшее внимание – это инструменты и методы работы. Но повторимся: чтобы понять, что именно подходит для конкретного проекта более всего, необходимо тщательно изучить сам Стандарт.

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

Ниже мы приведем лишь перечень основных инструментов и методов PMBoK (о некоторых из них мы рассказывали на нашем сайте, поэтому переходите по ссылкам и разбирайтесь).

Методы PMBoK:

  • Управление освоенным объемом (EVM-метод)
  • Выравнивание ресурсов
  • Оценка «снизу вверх»
  • Быстрый подход
  • Древо решений
  • Анализ допущений
  • Метод набегающей волны
  • Анализ сети
  • Мозговой штурм
  • Оценка и анализ программ (PERT-метод)
  • Метод Монте-Карло
  • Метод Дельфи
  • Анализ отклонений
  • Метод «операции в узлах» (PDM-метод)
  • SWOT-анализ
  • Метод критической цепи
  • Метод критического пути (CPM-метод)
  • Декомпозиция
  • Анализ ожидаемого денежного значения (EMV-метод)
  • Анализ чувствительности
  • Метод освоенного объема
  • Анализ характера и последствий отказов (FMEA-метод)

Инструменты PMBoK:

  • Система управления конфигурацией
  • Система управления изменениями
  • Сетевая модель
  • Матрица вероятности и воздействия
  • Диаграмма Парето
  • Расписание контрольных событий
  • Система санкционирования выполненных работ
  • Расписание контрольных событий
  • Диаграмма Ганта
  • Матрица ответственности
  • Информационная система управления проектами
  • Иерархическая структура рисков

В дополнение к этим методам в последней версии PMBoK (пятое издание) присутствуют также методы гибкой системы управления проектами Agile. Каждый из них подробно изучается и осваивается при исследовании PMBoK. Множество материалов на эту тему вы можете найти на сайте Московского отделения Института проект-менеджмента (PMI) и официальном сайте PMI (на английском языке).

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

Сертификат PMP

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

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

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

Как сдать экзамен:

  • Зайти на сайт PMI (ссылка была выше)
  • Зарегистрироваться
  • Оплатить членский взнос (не так давно он составлял 140 USD, но лучше уточнить на сайте)
  • Заполнить профиль и указать E-Mail
  • Получив доступ к материалам сайта, скачать и изучить последнее издание PMBoK (вообще, вы можете уже сейчас скачать его отсюда)
  • Ознакомиться с документами на английском языке (экзамен тоже будет проходить на английском)
  • Подать запрос на тестирование (вашу кандидатуру должны одобрить)
  • Подождать 5 дней, пока PMI одобрит заявку
  • Получить письмо на указанный E-Mail (после одобрения вашей кандидатуры)
  • Оплатить экзамен
  • Забронировать дату экзамена

Есть несколько важных дополнений:

  • На сдачу экзамена дается 1 год
  • На сдачу экзамена дается 3 попытки (в течение этого же года)
  • Стоимость экзамена составляет 405 USD (без оплаты членского взноса стоимость составит 555 USD)
  • Вторая и третья попытки оплачиваются отдельно (примерно 275 USD каждая)
  • Лучше всего оплатить членский взнос, чтобы получить доступ к архиву материалов (без его оплаты такого доступа нет)

Что же касается требований к кандидату, то они таковы:

  • Стаж работы в сфере управления проектами 3 года, т.е. 4 500 часов (при наличии высшего образования)
  • Стаж работы в сфере управления проектами 5 лет, т.е. 7 500 часов (при отсутствии высшего образования)
  • Прохождение базового курса по управлению проектами у сертифицированного провайдера (чтобы его гарантированно засчитали в PMI)

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

Экзамен будет проходить на компьютере. Он включает в себя 200 вопросов. На выполнение всех заданий отводится 4 часа. После успешной сдачи экзамена выдается сертификат PMP. Он действителен в течение трех лет, однако для подтверждения своего статуса и его окончательного утверждения нужно будет за указанный срок набрать 60 баллов PDU (Professional Development Units). Но об этом читайте на сайте PMI.

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

Желаем вам удачи и успешных проектов!

4brain.ru

4 мифа о PMBOK®

10 Ноя 2015

В этой статье мы рассмотрим основные мифы, связанные со Сводом знаний по Управлению Проектами PMI PMBOK. Этих мифов и ошибочных представлений гораздо больше, но мы рассмотрим 4 основных:

  1. PMBOK — это стандарт
  2. PMBOK состоит из лучших практик
  3. PMBOK — это методология
  4. PMBOK не связан с реальным управлением проектами

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

PMBOK – cтандарт по управлению проектами

PMBOK – это фреймворк. Многие называют его стандартом, но это не совсем верно. К сожалению, причина такого заблуждение – штамп Американского Национального Института Стандартизации (ANSI) и слова «Международный стандарт» (Global Standard) на обложке.

Штамп ANSI

Большинство людей не знают, что PMBOK® Guide целиком не является стандартом, несмотря на то, что PMI (Project Management Institute) ставят штамп стандарта ANSI на обложку. Стандартом является только «Стандарт управления проектами» (‘Project Management Standard for Managing a Project’), размером всего в 40 страниц. Само же руководство PMBOK гораздо обширнее – 616 страниц (в русском издании 587 – прим. пер.). Путём несложных подсчётов станет понятно, что стандарт, утверждённый ANSI составляет менее 7% от всего PMBOK, 93% которого написаны сотрудниками PMI, приглашёнными авторами и даже волонтёрами и не является стандартом. «Глава 3 – это стандарт по управлению проектами» сказано во введении четвёртого издания PMBOK. В пятом же издании, он приведён в Приложении 1. Оно так и называется: «Стандарт управления проектом». (стр. 417 русского издания PMBOK 5th Edition, 2013 год – прим. пер.)

Международный стандарт

Эта фраза, написанная на обложке Руководства PMBOK, также вводит читателя в заблуждение. Какая международная организация по стандартизации объявила Руководство стандартом – неизвестно.

Из этого следует вывод, что весь PMBOK стандартом как таковым не является – ни в Америке, ни во всём мире. И слишком сильно полагаться на него не стоит.

PMBOK содержит лучшие практики

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

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

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

Зачем был создан этот миф? Затем, что если всё лучшее уже собрано в PMBOK, зачем искать что-то новое.

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Смотрите также:

Оригинал: http://blog.sukad.com/20151028/what-are-the-four-myths-about-the-pmbok-guide/


www.pmservices.ru

Свод знаний по управлению проектами (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

upr-proektom.ru

Кого отправлять учиться PMBok / Habr

Некоторое время назад я менял работу, и занимался активным поиском работы менеджера — руководителя проектов в области IT. И я обратил внимание, на довольно частое требование знание методологии PMI, PMBok.

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

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

Сначала изучил краткий курс «Практический PMBoK за 5 дней» (ссылку не привожу — боюсь, сочтут рекламой, но данный курс бесплатен, и его легко найти в интернете), потом скачал книжки на русском и английском языках.

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

Есть ученый — теоретик, ученый практик, а есть инженер на заводе, фирме и т.п. Курс PMBok это для ученых теоретиков. Изучать его инженеру на заводе совершенно бессмысленно.

В бытность свою студентом, меня потрясла формулировка одной теоремы, в то время я заучил ее как стихотворение! «Гомоморфный образ группы изоморфен фактор группе по ядру гомоморфизма» — класс! написал и на душе приятно. Спросите своих знакомых программистов — понятно ли им тут что-либо? А ведь это одна из основных теорем в алгебре, на которой основано многое из программирования. Сейчас спустя много лет, я нет-нет да нахожу в нашей жизни, в своей работе примеры того, о чем говорит данная теорема, но студентом я ее просто выучил как красивый набор слов. Я даже мог ее доказать, но никакого понимания того, как она может применяться в жизни у меня не было тогда.

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

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

Я считаю, что теоретический курс PMBok можно преподавать только опытным менеджерам проектов (с опытом работы больше 10 лет), которые затем будут адаптировать его под ту область в которой они работали и которые в последствии смогут проводить курсы типа: «Основы PMI в разработке web проектов», «Основы PMI для строительства» и т.д.

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

habr.com

Управление проектами по PmBok | Академия маркетинга

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

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


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

Содержание:

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

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

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

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

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

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

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

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

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

 

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Некоторая работа исполнялась 10 раз. Статистика длительностей:

  • 2 раза за 4 дня – оптимистичная
  • 7 раз за 5 дней – наиболее вероятная
  • 1 раз за 9 дней – пессимистичная

Посчитаем разные средние значения:

Средняя (арифм) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней

Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней

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

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

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

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

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

Резерв (Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта:

Резерв = Поздний старт — Ранний старт

Свободный резерв (Free Float) – время, на которое операция может быть задержана, не влияя на раннее начало любой последующей операции

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

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

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

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

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. Руководителю стоит иметь в библиотеке книги Патрика Ленсиони «Пять искушений руководителя» и «Три признака унылой работы: История со смыслом для менеджеров (и их подчиненных)». Первая рассказывает о руководстве, вторая о том, как зажечь огонь в глазах команды и мотивировать на подвиги.

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

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

 

blog.alevi.ru

Обзор шестого издания PMBOK

27 Сен 2017

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

Структура из трех частей

В шестом издании PMBOK содержимое разбито на 3 части:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Признание гибких подходов

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

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

Для адаптивных проектов предлагается два варианта выделения фаз проекта:

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

Фазы с непрерывным наложением друг на друга. Здесь прослеживаются идеи КАНБАН, хотя явного упоминания нет.

Кроме включения гибких методов непосредственно в содержание Руководства, PMI дарит дополнительно книгу «Agile practice guide». Книга создана при совместном участии PMI и Agile Alliance. В ближайшее время мы опубликуем обзор книги «Agile practice guide» в нашем блоге.

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

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

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

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

Заключение

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

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

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

Если вы хотите изучить новое издание PMBOK в компании единомышленников, получить ответы на возникающие вопросы, опробовать инструменты управления на практике, а также получить возможность бесплатно пройти международную проектную сертификацию – записывайтесь на курс «Управление проектами на базе PMI PMBOK и ISO 21500. Подготовка к Международной проектной сертификации».

 

 

Автор: Сергей Шарпак
Директор управления консультационных услуг
PMI PMP

 

 

 

 

Смотрите также:

 


www.pmservices.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о