В 2021 году вышла новая версия стандарта от PMI – PMBOK 7.
В отличии от предыдущих версий, авторы 7 версии не ограничились небольшими улучшениями. Они серьезно переработали структуру и содержание документа. Стандарт с одной стороны значительно «похудел», а с другой – предлагает дополнительные возможности для проектного сообщества.
Мы попросили подробнее рассказать об основных изменениях стандарта Управляющего партнера ГК «Проектная ПРАКТИКА», Михаила Дубовика.
Что такое PMBOK в целом? В чем замысел его создания? В чем его полезность?
PMBOK – это сборник лучших практик в управлении проектами. При разработке PMBOK проводят опрос в различных организациях, задавая одинаковые вопросы: «Как вы стартуете проект? Можно ли ознакомится с документом, которым вы его оформляете? Из каких шагов состоит проект? Как выглядит план работ? и т.д».
И если в разных организациях эксперты получают похожие ответы, то эти процессы, действия и инструменты определяются как «хорошая практика», которая дает эффект. PMBOK – это сбор хороших практик, которые мы применяем в реальном проектном управлении.
PMBOK – это не методология, как его очень часто называют, а обобщенный обзор практик, и к нему нужно относиться, как к инструменту, который потребуется адаптировать. Авторы стандарта неоднократно упоминают об этом в тексте, но мне кажется, не все его правильно читали. Люди брали PMBOK и машинально выполняли все 49 процессов, которые там имеются. Хорошая практика не должна и не может одинаково применяться ко всем проектам, она должна адаптироваться и применяться индивидуально. Это звучит в каждой редакции стандарта.
Так зачем же тогда его издавать, если всё индивидуально и персонально для каждой компании? Важно, чтобы у нас были общие термины, некая структура и какой-то единый справочный материал, чтобы развивать профессию и развивать профессионалов в данной области. И как раз в этом PMBOK очень преуспел: в задании терминологии и структуры дисциплины, которая называется «проектное управление».
Что такое PMBOK в целом? В чем замысел его создания? В чем его полезность?
PMBOK – это сборник лучших практик в управлении проектами. При разработке PMBOK проводят опрос в различных организациях, задавая одинаковые вопросы: «Как вы стартуете проект? Можно ли ознакомится с документом, которым вы его оформляете? Из каких шагов состоит проект? Как выглядит план работ? и т.д». И если в разных организациях эксперты получают похожие ответы, то эти процессы, действия и инструменты определяются как «хорошая практика», которая дает эффект. PMBOK – это сбор хороших практик, которые мы применяем в реальном проектном управлении.
PMBOK – это не методология, как его очень часто называют, а обобщенный обзор практик и к нему нужно относиться, как к инструменту, который потребуется адаптировать. Авторы стандарта неоднократно упоминают об этом в тексте, но мне кажется, не все его правильно читали. Люди брали PMBOK и машинально выполняли все 49 процессов, которые там имеются. Хорошая практика не должна и не может одинаково применяться ко всем проектам, она должна адаптироваться и применяться индивидуально. Это звучит в каждой редакции стандарта.
Так зачем же тогда его издавать, если всё индивидуально и персонально для каждой компании? Важно, чтобы у нас были общие термины, некая структура и какой-то единый справочный материал, чтобы развивать профессию и развивать профессионалов в данной области. И как раз в этом PMBOK очень преуспел: в задании терминологии и структуры дисциплины, которая называется «проектное управление».
Как выглядели предыдущие версии PMBOK? Какой вклад они внесли в описание и становление проектного управления? В чём их полезность?
Во-первых, PMBOK 6 и предыдущие его версии внесли очень большой вклад в определение терминов, которые теперь часто перетекают в другие стандарты. Есть критики, которые говорят, что термины иногда неоптимальны и могут быть улучшены. В этом есть доля правды. Но иногда лучше неоптимальные, но единые термины, чем прекрасные, но разные. В этом большая заслуга стандартов и PMBOK, в частности.
Второй отличный инструмент, если позволите, «полезность», которую в 1996г. создал PMBOK – это структура групп процессов управления проектом. Процессы инициирования, планирования, организации, контроля и завершения. Они очень сильно упростили понимание, что же мы делаем в проекте. В дальнейшем все эти процессы заимствовали в европейские стандарты и российские ГОСТы. Во многих стандартах, которые появились позже, применяются эти 5 групп процессов.
В дальнейшем модель процессов модернизировалась. Мне кажется, что такая картинка более корректная, но менее понятная. Авторы пытались сделать каждое последующее издание полнее, шире и понятнее, поэтому стандарт неуклонно толстел.
Полезность PMBOK заключалась еще в том, что помимо 5 групп процессов он четко задавал 10 функциональных областей: управление интеграцией, содержанием, расписанием, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками и заинтересованными сторонами. И строго распределял процессы (в предпоследней 6 версии их было 49 штук) по этим функциональным областям. Формула «5х10» много лет являлась как бы кристаллической решеткой PMBOK и задавала структуру дисциплины. Я часто называю эту схему «системный шкаф проектного управления», потому что каждый процесс и каждая функциональная область четко структурировались. Мы с вами пытались выстроить её в некую конкретную последовательность действий и частично это было корректно. Но раз за разом PMBOK транслировал мысль, что это последовательно-параллельно-переплетающиеся процессы, а не шаг за шагом прописанные действия. И следует отметить, что каждый процесс в PMBOK завязан на документы, которые необходимо выпускать, перед запуском проекта и в ходе него.
Довольно много страниц стандарта отводилось на описание инструментов, которые рекомендуют и советуют. Даже велась некая закулисная борьба: когда появлялась какая-то новая методика и она не находила отражение в PMBOK, значит её как бы не признали.
Что изменилось в 7 редакции PMBOK? Какова теперь его структура? Какие изменения наиболее значимы и полезны на Ваш взгляд?
В 2021г. вышла 7 версия стандарта, который значительно похудел (с 762 до 373 стр.). За счёт чего это произошло?
Вместо 5 стандартов управления проектом, ввели набор из 12 принципов проектного управления, которые должны применять к проекту его руководитель и команда. А 10 функциональных областей теперь заменены на 8 доменов исполнения. Плюс ко всему, в новой редакции очень подробно проговаривается раздел адаптации принципов и доменов к практике различных уникальных обширный раздел «Модели, методы, артефакты».
Казалось бы, после вышеперечисленного PMBOK должен был значительно увеличится в объеме, но это не так.
Появилась ИТ платформа PMIstandards+™, в которой содержится большое количество контента. Теперь, когда вы видите в стандарте некий термин, не тратьте время на поиск информации о нём в тексте, а зайдите на цифровую платформу, где хранится огромное количество информации о нём (описание, рекомендованная литература, правила применения и статьи, имеющиеся на эту тему и т.д.). Находящийся там контент является значимой частью 7 версии PMBOK.
Многие вещи звучали и в PMBOK 6, но звучали, как очень важные аспекты проектного менеджмента, а не как принципы. Я бы остановил наше внимание на аспектах: ценность, системное мышление, адаптация и cложность.
С точки зрения ценности, в предыдущих версиях стандарта было предположение, что в рамках проекта создается некий delivery (продукт проекта). В этой версии категорически продвигается мысль, что в процессе проекта мы создаем ценность для организации и эта ценность не в продукте, а в том, что мы начнем его эксплуатировать и получать полезные эффекты после завершения проекта. И этот этап нужно осознано контролировать, выделять, а иногда даже включать в ЖЦП (жизненный цикл проекта).
Принцип адаптации красной нитью проходит в PMBOK 7: «Всё что мы пишем должно подвергаться вашему критическому осмыслению и адаптации под реальный проект» – говорят авторы. Появилось очень много инструментов из области гибких подходов. Найдено место и внятную позицию терминам Agile и гибкий подход. Образовался целый домен – подход к разработке. Однако, стандарт постоянно транслирует мысль: если вы живёте в «водопаде», то вам необходим один подход; если в Agile, то другой, но смысл тот же самый. Если вы производите программный продукт или что-то не слишком материальное, создавайте продукт по Agile, не забывая об адаптации к проекту. Но если вы строите жилое здание, например, то следует идти по «водопадному» циклу – этап за этапом: проектирование, закупки, стройка, сдача. Теперь, надеюсь, закончатся прения на тему: что лучше – Agile или Waterfall? И то и другое – хорошо, все зависит от выбранного вами подхода.
Принцип «Сложность» также очень явно определен в стандарте. Авторы призывают учитывать, что проекты имеют разную сложность, поэтому и система управления, и процессы, и структура должны соответствовать сложности проекта. PMBOK дает системную, но избыточную картину процессов, правил, практик, артефактов, а вы выбираете из неё только то, что вам нужно, занимаетесь бережливым проектным управлением, а не используете всё, что описано в стандарте.
В какие домены объединили 10 функциональных областей? Чем они отличаются от групп процессов? В чём их особенность?
Давайте более детально поговорим о доменах. Все процессы, которые мы привыкли делить на 5 групп и 10 функциональных областей отныне объединены в 8 доменов:
- Заинтересованные стороны,
- Команда,
- Подход к разработке и жизненный цикл,
- Планирование,
- Работа проекта,
- Поставка,
- Измерение,
- Неопределенность.
Определение доменов не сильно отличается от определения группы процессов, но если процесс – это последовательность шагов и действий, то домен – это возможные шаги, без учёта последовательности. Конечно, открывая стандарт хочется увидеть чёткую последовательность действий. С другой стороны, невозможно описать эту последовательность для любого проекта, любого масштаба, в любой отрасли.
Некоторые эксперты усматривают здесь условное распределение действий по порядку. Но авторы указывают на обратное: это перечень операций, которые играют важную роль и могут как применяться, так и не применяться, быть как последовательными, так и параллельными. Нужно думать обо всех доменах, выполнять все операции во взаимосвязанном и разрозненном виде, но не забывать, что на эти домены должны оказывать влияние 12 принципов.
Каждый домен, очень чётко описан. Приводится контрольная таблица, как проверить результат выполнения домена. Каждый домен реализуется во взаимосвязи с другими доменами. Он может содержать операции, которые выполняются раньше, позже и параллельно и дадут результат, который можно проверить.
Какие инструменты проектного управления вошли в раздел «Модели, методы и артефакты»?
К моделям и артефактам относятся проектные документы, методы и технологии, инструменты и правила, которые могут быть полезны для реализации домена (их порядка 200 шт.). Авторы не поленились и сформулировали в каком домене какие методы и артефакты могут применяться. Этот раздел объемный, но не подробный, так как за подробностями авторы отправляют нас на PMIstandards+™.
Ещё больше информации в одноименном вебинаре Михаила Дубовика.