Что такое pmbok простыми словами

Что такое PMBoK. Объясняем простыми словами

Project Management Body of Knowledge (PMBoK) — свод знаний, максимально полное изложение информации по управлению проектами.

По сути, это своеобразная энциклопедия управления, в которой содержатся описание методов и рекомендации к работе. PMBoK разработан американским Институтом управления проектами (PMI).

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

Кроме того, PMBOK предлагает управленцам десять областей знания — по сути, фокусов внимания руководителя. Среди них — управление содержанием (что должно получиться в итоге и как вносить изменения в ходе проекта), управление временем (разработка и контроль календарного плана), управление рисками (идентификация и методы реагирования), управление персоналом (создание и работа в команде) и другие важные точки.

Этот свод знаний популярен из-за своей универсальности: он подходит для большинства проектов, вне зависимости от сферы бизнеса. Однако все же PMBOK — это не готовая методология, а скорее фреймворк для методологии, который можно (и нужно) адаптировать, подгонять по себя и только тогда уже использовать.

Пример употребления на «Секрете»

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

(Президент компании «Технониколь» Сергей Колесников — о том, как достичь стандартизации и централизации.)

Ошибки в употреблении

PMBOK часто называют стандартом, однако это не так. Существует утверждённый Американским институтом стандартов (ANSI) «Стандарт управления проектами» (Project Management Standard for Managing a Project), который, по сути, является выдержкой из свода знаний PMBOK. Он написан в 1994 году и считается признанным ориентиром в проектном менеджменте.

Источник

PMBoK

Прежде чем перейти к предмету статьи, мы хотели бы сказать, что вы не должны рассматривать ее в качестве всеобъемлющего пособия по управлению проектами. Мы лишь хотим простым языком познакомить вас со сводом соответствующих знаний, который и называется 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 (пятое издание) присутствуют также методы гибкой системы управления проектами Agile. Каждый из них подробно изучается и осваивается при исследовании PMBoK. Множество материалов на эту тему вы можете найти на сайте Московского отделения Института проект-менеджмента (PMI) и официальном сайте PMI (на английском языке).

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

Сертификат PMP

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

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

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

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

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

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

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

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

Источник

Процессы PMBoK 5 за 10 минут

Oct 5, 2017 · 10 min read

Подробнее об управлении проектами в моем блоге: https://salakhmir.ru/

В начале сентября 2017 года вышла шестая редакция PMBoK (Project Management Body of Knowledge). PMBoK — свод знаний по проектному менеджменту, выпускающийся организацией PMI (Project Management Institute).

Это офигенно здоровый талмуд справок по ведению проектов, регуляр н о при том обновляющийся. Первая публикация свода вышла в 1996 году, за 20 лет — шесть редакций. В довесок к выпуску свода знаний, организация проводит сертификации проектных менеджеров. Увы, по некоторым причинам, я её пройти пока не могу. Ещё одна фентифлюшка PMI — участие в “клубе”, нафиг в жизни не нужна. Кроме легального доступа к PMBoK 6, она ничего не даст. Потому я и не могу рассказать, что там, в шестой редакции. Только что читать краткие ревью, чего там появилось нового.

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

Что такое проект

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

Этапы выполнения проекта

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

1. Инициация

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

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

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

Составление устава проекта. Здесь решаются вопросы с документами: руководство по ведению проекта, примерный тайм-план и техническое задание. Основной вопрос устава проекта — что решает продукт, создаваемый в процессе проекта, что должны получить на выходе (например, “на выходе нужен дом на 250 квартир”).

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

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

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

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

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

Разработка плана работы с рисками — что ты будешь делать в случае, если риск наступит?

Предупреждение рисков — что можно сделать, чтобы риск не наступил? Здесь же нам нужно оценить триггеры, по которым мы сможем оценить, что риск наступил и с ним нужно что-то делать. Это как когда у вас дома выбивает пробки, вы ищете потребитель, “кладущий” электросеть.

Характеристиками рисков являются “последствия” и “вероятность наступления”, где 1 — минимальное значение, 5 — максимальное.

Оценка рисков на старте IT-проекта. Вписав риски в таблицу и посчитав “тоталы” последствия/вероятности, мы видим, что нам стоит заняться поиском выхода на лицо, принимающее решение и поиском заменяющего программиста (если уж зачем-то подключаем программиста, который вот-вот уходит в отпуск). “Метеорит” вставил для утрированного примера, когда последствия риска максимальны, но вероятность нулевая.

Проектные задачи

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

В качестве примера иерархической структуры — проект разработки веб-сайта. Проект состоит из трёх этапов, каждый из этапов (фаз выполнения проектов) содержит или не содержит свои подэтапы, а те, в свою очередь, содержат конечные задачи. Проект декомпилируется до уровня задач, где каждая задача занимает от 4 до 40 часов работы конкретного исполнителя (рекомендуется PMBoK). В проектах наподобие разработки сайтов, задача может занимать от получаса до 16 часов — я так считаю.

Определение задач происходит так:

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

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

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

Структура взаимосвязей может составляться на основе верхних уровней иерархической структуры. На примере разработки сайта, взаимосвязи линейны и выглядят так: дизайн => вёрстка => программирование. В случае проекта той же постройки детского сада, количество взаимосвязей стремится к бесконечности, их следует учитывать.

По поводу маршрута хода проекта (ака сетевой трафик) в PMBoK есть несколько инструментов — Float Time и Critical Time. Я их [пока] не использую, а желающие могут почитать об этом в интернете. Пример структуры — диаграмма PERT.

Тайм-план проекта

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

Для того, чтобы составить тайм-план в виде диаграммы Гантта, нужно:

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

Диаграмма Гантта ещё тем хороша, что легко составляется — её можно хоть от руки рисовать. На компьютере её можно создать в Ms Project или Ms Excel. Я воспользовался сервисом draw.io — рекомендую.

Если базовая линия проекта изменилась и планирование посыпалось, PMBoK предлагает нам два инструмента в помощь в борьбе с проблемой: “Crashing the Project” и “Fast Tracking”. Альтернативные пути, подходящие нам и помогающие оставаться в рамках изначального тайм-плана — это уменьшение содержания проекта и уменьшение качества — время здесь равняется бюджету.

Управление командой проекта (Project Leadership)

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

Формирование команды проекта может происходить двумя путями:

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

После набора в команду проекта требующихся специалистов, требуется провести знакомство членов команды проекта (особенно, если часть их привлечена к проекту из вне). Знакомство команды с проектом состоит из четырёх фаз:

В случае крупных проектов может потребоваться процесс “распределение задач”. Например, если наш проект — это веб-разработка, и у нас 10 программистов и 5 верстальщиков. Распределение происходит путём поиска ответов на вопросы:

Под “может” подразумевается квалификация и навыки исполнителя. Под “выполнит” — будет ли он её делать. “Будет ли доступен” — в том случае, если команда собирается сразу, а этап работы этого специалиста произойдёт через месяц. Подразумевается, что члены рабочей группы проекта не сидят на одном месте вокруг одного проекта, что до старта проекта у него были другие задачи (проектные или нет), также могут быть задачи во время хода проекта (во время, когда он не вовлёчен в работу).

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

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

А вот ещё чуток про human resources и выбор исполнителя под проект, чек-лист вопросов по оценке возможностей.

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

3. Выполнение проекта

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

Причины быть “быстрее и дешевле”

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

4. Наблюдение и контроль выполнения проекта

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

Наблюдение за проектом

Главные инструменты тут — расписание проекта (тайм-план с майлстоунами и дедлайнами) и коммуникационный план. И сама коммуникация. Хорошая коммуникация — основа успеха проекта.

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

Участники проекта — и рабочая команда проекта и заказчики.

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

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

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

Как я писал ранее, 80–90% проблем возникают по причине ошибок планирования. Только 10–20% проблем по причине ошибок команды проекта.

В случае проблем обращаемся к процессам Crashing the Project и Fast Tracking. А вот “лайтовый” список, подходящий для небольших проектов:

Если изменились ожидания клиента (при плохом обсуждении планирования с клиентом):

5. Завершение проекта

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

Источник