что такое pmi pmbok
Качаем навык управления проектами или еще раз про PMI PMBOK
Структура статьи
Друзья, всем привет. Сегодня я расскажу про управление проектами, про методологию или свод правил по управлению проектами PMI PMBOK (Project Management Institute Project Management Body Of Knowledge). Выпустил эту методологию и регулярно ее обновляет авторитетный институт по управлению проектами, расположенный в Пенсильвании, США. Несмотря на то, что в мире есть и другие методологии, например британский стандарт PRINCE2 или японский P2M, в России наиболее популярна именно эта, на ее основе приняты ГОСТы по проектному менеджменту.
В целом я попробую лаконично, но возможности интересно рассказать о тех знаниях и опыте в области управления проектами, которые получил на данный момент. Также я являюсь сертифицированным экспертом по управлению проектами – PME.
Методика управления проектами универсальна, правила одни и те же. Сами же проекты всегда разные, они имеют начало и конец в отличие от операционной деятельности, которая, как бы происходит постоянно, рутинно. Мы с вами являемся участниками множества проектов и на работе и дома. Проектом может быть исследование рынка, разработка программного обеспечения, строительство нового здания. Проектом может быть и переезд на новое место жительства или создание семьи.
PMI PMBOK – методология использующая современный процессный подход, согласно которого все работы по управлению проектом осуществляются в виде отдельных взаимосвязанных между собой процессов. Каждый процесс начинается с исходного состояния и завершается неким результатом или ценностью, которая затем используется в других процессах или является конечным продуктом. Всего методология содержит 49 процессов из 10 областей зданий. Процессы можно сгруппировать не только по областям знаний, но и по фазам жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и контроль, завершение. Таким PMBOK есть сеть взаимосвязанных процессов по управлению проектами, выполнение которых приведет вас к успеху (статистика показывает, что вероятность успеха выше там, где используется осознанное профессиональное управление проектом). Свод правил как раз и описывает каким образом нужно производить каждый их этих процессов через определенные порядок, методики и инструменты.
Проект считается успешным, если не превышены запланированные для него бюджет и график, а также заказчик и конечные пользователи остались довольны его результатами.
Если вы профессиональный руководитель проектов или его помощник, то пройти курсы по управлению проектами и получить сертификат просто обязаны. Если вы являетесь регулярным участником различных проектов у себя в компании, то можно и самостоятельно изучить принципы проектного управления через открытые источники.
Я решил привести информацию в структурированной форме, с учетом существования 10 областей знаний. Надеюсь, мои заключения будут интересны и полезны как тем людям которые только слышали про PMBOK, так и профессионалам. По каждой из областей знаний я опишу следующее:
Методология, фреймворк или стандарт проектного управления
В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.
Краткие вводные:
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.
PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.
Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.
PRINCE2
PMBoK (6 издание, 2017г.)
ISO 21500:20112
Определение проекта
Временная организация, которая создается с целью предоставления одного или нескольких бизнес-продуктов в соответствии с утвержденным экономическим обоснованием проекта.
Временное предприятие, направленное на создание уникального продукта, услуги или результата.
Уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей.
Процессы
7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.
49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.
Предметные темы / группы (курсивом отмечены различающиеся темы)
7 тем:
1. Экономическое обоснование,
3. Управление качеством,
5. Анализ и управление рисками,
6. Управление изменениями содержания,
7. Принятие решений.
10 областей знаний:
1. Управление интеграцией проекта,
2. Управление содержанием,
3. Управление сроками,
4. Управление стоимостью,
5. Управление качеством,
6. Управление человеческими ресурсами,
7. Управление коммуникациями,
8. Управления рисками,
10. Управление заинтересованными сторонами.
10 предметных групп:
2. Заинтересованные стороны,
Жизненный цикл проекта
Структура стадий проекта:
1. Стадия инициации,
2. Последующие стадии (создание продуктов, соответствующих требованием),
3. Финальная стадия (приемка результатов, подведение итогов проекта).
Минимальное количество стадий в проекте – 2 (инициация и финальная).
Все проекты могут иметь следующую структуру жизненного цикла:
2. организация и подготовка;
3. выполнение работ проекта;
4. завершение проекта.
В стандарте отсутствуют четкие требования/пояснения по стадиям проекта, стандарт определяет, что проект должен подразделяться на фазы, состав и содержание которых должно определяться потребностями управления и контроля.
Принципы
7 принципов (универсальны и не требуют обоснования):
1. Постоянная оценка целесообразности,
2. Учет предыдущего опыта,
3. Определенные роли и обязанности,
4. Управление по стадиям,
5. Управление по исключениям,
6. Фокус на продукте,
7. Адаптация к внешним условиям.
Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.
Ожидается, что новое седьмое издание будет ориентировано на принципы.
ISO 21500 по аналогии с PMBoK основан на процессной составляющей.
Ответственность за результат проекта
Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.
Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.
Руководитель проекта = единый ответственный за результат.
Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.
Инструменты управления
В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.
Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.
Стандарт не описывает конкретных инструментов для реализации процессов управления.
Возможность гибкого применения
Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).
Так как PMBoK является не методологией или стандартом, а фреймворком, его создатели рекомендуют использовать PMBoK для создания собственной методологии управления проектами в компании. При этом созданная методология должна учитывать особенности каждого отдельного проекта и позволять руководителю проектов изменять процессы управления в определенных пределах.
Описанные в стандарте процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель проекта должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.
Возможность использования в программе проектов
Возможность использования в портфеле проектов
Сертификат PMI(PMBOK) или IPMA для управленцев ИТ проектов. Нужен ли?
Что такое PMI&IPMI&PMBOK?
PMI (Project Management Institute) – институт по управлению проектами, разработавший систему комплексного подхода к проектированию и организации процессов для успешной реализации проектов. Он предлагает универсальную схему построения работ при начальном планировании, предлагая, возможно даже, исчерпывающую схему этапности, учит правильно строить организационную структуру проекта и контролировать ход его выполнения.
PMBOK (Project Management Body of Knowledge) — Свод знаний по управлению проектами представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. PMI использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Является Американским национальным стандартом.
IPMA — Международная Ассоциация Управления Проектами (Щвейцария) (англ. International Project Managment Organization, IPMA) — ассоциация, созданная в 1965 году и призванная объединить специалистов в области управления проектами (Project Management), а так же внедрившая собственную четерыхступенчатую систему сертификации.
В России представлена Ассоциацией Управления проектами (СОВНЕТ). Основана в 1990 году и представляет собой добровольный некомерческий союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области Управления проектами; обоснование, подготовку, выполнение и управление проектами в различных сферах деятельности.
Как Вы считаете изучение по PMBOK и сертификация PMI может пригодится человеку, который занимается Web-проектами? Насколько мне известно, подход к управлению проектами по 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. Завершение проекта
Закрытие проекта — этап, когда разрабатываемый продукт готов и его нужно сдать в эксплуатацию. К закрытию проекта есть чек-лист, касающийся самого проекта, документации и команды проекта.