В июле 2021 членам Института управления проектами стала доступна новая 7-ая редакция Руководства к своду знаний по управлению проектами (PMBOK Guide). Выпуски на других языках, в том числе на русском, ожидаются в августе 2021.
Новое издание предлагает взглянуть на управление проектом с другой точки зрения. Проект — не просто производство результатов. Проект — это система поставки ценности для заинтересованных сторон. Каждый проект уникален, поэтому описать такую систему в виде набора шагов (процессов) не получится. Более универсальным представляется определение общих принципов, которыми участники проекта должны руководствоваться при работе над проектом. А сам проект можно представить как совокупность связанных между собой тематических областей (доменов).
Для соблюдения баланса между стабильностью и изменчивостью авторы выделили переменную часть в отдельную платформу PMIstandard+. В PMIstandards+ будут размещаться новые практики, полезные кейсы и другая быстро меняющаяся информация.
Как и в шестом издании, новое издание содержит две основные части — стандарт ANSI и руководство PMBOK Guide. Однако структура каждой части значительно изменилась.
Изменения в стандарте ANSI
В шестом издании стандарт описывал управленческий цикл как общую структуру для всех действий. Структура задавала логичную последовательность:
- Инициация — по сути целеполагание;
- Планирование — ответ на вопрос, как добраться до цели;
- Исполнение — путь к цели;
- Мониторинг и контроль — наблюдение за тем, как проходит путь к цели;
- Закрытие — подведение итогов, насколько удалось достигнуть цель.
Несмотря на простоту цикла, на практике его постоянно путают с фазами проекта при каскадной организации: старт проекта, организация и подготовка, исполнение, завершение. Неужели фазой «организация и подготовка» не нужно управлять? Если нужно, значит управленческий цикл отрабатывает в полной мере для этой фазы. Однако разбор этой ошибки — тема другой статьи.
Системный подход к поставке ценности
В новом стандарте описывается система поставки ценности. Напомню, что система — это совокупность элементов, взаимодействующих между собой для достижения какой-либо цели. Другими словами, для описания системы нужно определить цель, элементы и взаимосвязи между элементами. Причем, зачастую именно взаимосвязи между элементами являются определяющими в достижении цели.
Цель проектов по новому стандарту не в производстве результатов, а в поставке ценности. Это не одно и то же. Новая цель означает, что проектная команда должна смотреть дальше во времени, думать о пользе создаваемых продуктов. А раз меняется цель проектов, то меняется и система управления.
Новая система управления содержит те же объекты управления: портфели, программы проектов и проекты. Однако процессная модель уходит в прошлое. Нам предлагается 12 базовых принципов, которые направляют поведение участников проектной команды.
12 принципов
- Будьте прилежным, уважительным и заботливым управляющим
- Создавайте среду сотрудничества проектной команды
- Вовлекайте заинтересованные стороны
- Фокусируйтесь на ценности
- Используйте системное мышление
- Поощряйте лидерство на всех уровнях
- Адаптируйте систему управления проектом к конкретной ситуации
- Встраивайте качество в процесс и конечные продукты
- Учитывайте сложность проекта на протяжении всего проекта
- Учитывайте угрозы и возможности
- Встраивайте адаптируемость и устойчивость в систему управления проектом
- Управляйте изменениями в организации
Если у вас остался вопрос после прочтения американского национального стандарта (!), а как же управлять проектом, то я вас прекрасно понимаю. Принципы хороши тем, что они более стабильны и универсальны, нежели процессы. Однако от принципов трудно перейти к конкретным действиям. Аналогичная проблема есть и в agile. Есть манифест с общими ценностями, но, чтобы перейти к действиям, нужно разобраться хотя бы с одной конкретной практикой (например, Scrum), которая построена в согласии с манифестом.
Изменения в PMBOK Guide
Ранее система управления была разложена аккуратно по полочкам. Нужно было определить жизненный цикл проекта. На каждом этапе жизненного цикла выполнялись три слоя активности: слой управления, слой создания продукта и слой обеспечения. Слой управления – это проход управленческого цикла по десяти областям знаний проекта.
В новой редакции компоненты системы управления никуда не делись, но смешались в чуть менее логичное множество – в домены проекта. Доменов теперь восемь.
- Заинтересованные стороны. Была область знаний, а стал домен. Ничего, по сути, не изменилось.
- Команда. Раньше PMBOK Guide не различал людей и асфальтоукладчики. Теперь авторы увидели различие и выделили команду в отдельный домен. Это выделение напрашивалось давно уже. Так что здесь явное улучшение.
- Неопределенность. Была область «управление рисками», а стал домен неопределенность. Яйца в профиль.
- Поставка результатов. Были две области знаний «Содержание» и «Качество», зачем-то разделенные. Отчасти логика была, т.к. тема качества развивается в отдельных стандартах. Но с точки зрения практики отделение было нелогичным. Сейчас все стало на свои места – есть один домен, в котором нужно думать о продуктах и их качестве.
- Жизненный цикл. Раньше эта тема отделялась от областей в красивую логику. Теперь это стало одним из доменов. Мне кажется, это менее удобным. Возможно, просто нужно привыкнуть. Радует, что тема жизненного цикла проработана глубже. Хотя ребята сами запутались и инкрементный подход проиллюстрировали неверно.
- Планирование. Раньше был управленческий цикл из 5 шагов. Конечно, инициация и завершения были довольно куцыми, но вместе с ними последовательность была целостной, законченной. Теперь остались только три самых наполненных действиями шага – планирование, выполнение и мониторинг.
- Выполнение. Был шаг управленческого цикла, теперь отдельный домен
- Измерение прогресса. Был шаг управленческого цикла «мониторинг и контроль», теперь отдельный домен. Справедливости ради, стало больше четкости, т.к. речь идет только про метрики слежения за прогрессом.
Полноценная интеграция Agile
В седьмом издании Agile стал частным случаем более общей системы поставки ценности. Интеграция прошла довольно гладко, на мой взгляд:
- Итеративно-инкрементальная разработка и поставка — это вариант жизненного цикла
- Самоуправляемые команды — опция при построении команды проекта
- Стили лидерства — на выбор руководителя проекта: можешь помогать команде самоорганизовываться, а можешь управлять директивно
- Практики — на выбор команды, можно использовать Scrum, Kanban или любой другой подход
Конечно, после PMBOK Guide невозможно начать делать проект с помощью Scrum. Верно также, что и после прочтения Scrum Guide (17 страниц описания на русском языке) команда вряд ли сразу сможет делать поставку продукта спринтами. Нужна конкретика.
Платформа PMIstandards+
Платформа PMIstandards+ задумана как хранилище полезных дополнений к основным стандартам.
Сейчас здесь можно найти 4 руководства (шестое издание PMBOK Guide с приложением по Agile, руководство по иерархическим структурам и руководство по бизнес-анализу). К ним можно скачать шаблоны, небольшие поясняющие видео, аудио и текстовые материалы по различным отдельным темам.
Я честно пытался понять, в чем отличие платформы от ресурса projectmanagement.com, но пока сути различий не понял. Опять яйца в профиль?
Современная тенденция плодить продукты-близнецы начинает уже раздражать. Какую проблему пытались решить ребята в PMI? Типа сайт ProjectManagement.com не диджитал, и нам страшно упустить тренд?
Заключение
Из-за стремления авторов к универсальности система управления стала более абстрактной, что затруднит ее применение на практике. Логика 6-й редакции хоть и была похожа на частный случай, все же была понятной: на каждом этапе жизненного цикла вы проходите управленческий набор шагов, акцентируя внимание на 10 областях знаний проекта. Довольно просто и логично.
Теперь в списке из 8 доменов перемешались и жизненный цикл проекта, и управленческий цикл и при этом сохранились некоторые из прежних областей (заинтересованные стороны и риски/неопределенность). Логика в этом тоже есть, ведь работа с заинтересованными сторонами, командой и рисками идет в своем ритме, не сильно связанном с процессами планирования, выполнения и контроля всех работ проекта. Пока это трудно уложить в голове. Только время покажет, насколько это будет логично, как для меня, так и других практиков.
Если обратиться к описаниям различных agile-практик, все-таки традиционно участники проекта четко отделяются от процесса. Мне кажется, это логично именно с системной точки зрения. Люди — это элементы системы. Артефакты (требования, результаты) — тоже элементы системы. А процессы описывают взаимодействия элементов. Это совершенно разные характеристики системы. И в том же Scrum они четко отделены друг от друга. Я бы тоже их не смешивал в общую кучу.
