7-ой PMBOK® Guide: Есть ли там что-то действительно полезное?..

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

О чем вообще речь?

Как известно, в августе 2021 года вышла 7-ая версия руководства к Своду знаний по управлению проектами, изрядно переработанная.

Тех, кому интересно поговорить про новое издание поподробнее, приглашаю на открытый вебинар 8 сентября в 19:00 мск. Чтобы не растекаться мыслью по древу я решила не обсуждать все 278 страниц, а взять конкретную актуальную тему: “Как быть, когда с Заказчиком невозможно договориться: Что на эту тему советует новый 7-ой PMBOK Guide?”. Присоединяйтесь к вебинару!

В чем суть изменений?

Составители принципиально переделали логику, ушли от описания 49 процессов (для многих проектов слишком громоздких и избыточных) к 8 доменам исполнения (актуальных для проектов любого масштаба).
Руководство ориентировано на работу по Agile не в меньшей степени, чем на “классические” подходы, а то и в большей (что логично, учитывая, что число Agile проектов неуклонно возрастает).
Размер книги существенно сократили (примерно в три раза), многое вынесли на онлайн-платформу.
Руководство стало еще менее предписывающим, и более рекомендующим (в любом случае, каждый проект - уникален, и универсальных советов не бывает).

Основные ценные и полезные рекомендации остались без изменений, просто структурированы по-другому (Устав, работа с заинтересованными сторонами, управление рисками, развитие команды и т. п.). На самом деле, группы процессов тоже остались - переходящие друг в друга инициация, планирование, исполнение, мониторинг и контроль и завершение. Просто теперь вся структура не построена вокруг групп процессов, а просто они приводятся как одна из удобных и полезных моделей.

Более подробно о том, чем новое издание радикально отличается от предыдущего я уже немного писала в своей предыдущей статье:  Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт? 

Но это были общие тезисы. А здесь - немного конкретики, что лично мне показалось наиболее полезным в новом издании, и что я порекомендую взять с собой в работу РП любого уровня.  Сразу оговорюсь, не надо думать, что авторы Руководства (чего-то меня так утомили противники англицизмов в комментах к предыдущей статье, что я уже избегаю аббревиатуры PMBOK, заменяя ее какими-то русскими словами, ну да ладно) мало предлагают “свежих гениальных идей”. В первую очередь они рассказывают существующие и проверенные временем концепции, методы и модели. И это прекрасно. Потому что “новые и уникальные методики” при ближайшем рассмотрении обычно оказываются куда менее действенными, чем выглядят на первый взгляд, и сопряжены с гораздо большим числом побочных эффектов, чем хочется. Ну, а волшебные пилюли существуют только в нашем воображении. 

Итак, несколько новых моделей и методов, которые показались мне полезными.

Модель ситуационного лидерства Кена Бланшара

(Строго говоря, она называется Модель II, потому что есть еще Модель I - так как двое соавторов: Пол Херси и Кен Бланшар не поделили права на концепцию и зарегистрировали две разных названия).

Очень часто, когда речь идет про лидерство, люди ударяются в одну из двух крайностей. Вариант первый: говорят о том, что директивное руководство неизбежно, без него люди таких дров наломают… Дальше следуют описания историй, наглядно подтверждающих, что только так и может быть. Например, как только техлид доверил команде самой принимать решение по архитектуре, выбрали неработающее решение. Как только исполнительный директор ушел от микроменеджмента и перестал заниматься пошаговым руководством - разработчики вообще практически перестали работать, и так далее (почти уверена, что у вас тоже есть в коллекции такие истории…)
Другая крайность - когда заявляют: мол, Agile призывает делать все команды самоуправляемыми. Давайте уволим всех менеджеров и дадим команде самой решать, как она будет работать… Как нетрудно догадаться, получается примерно как с щенками, которых учат плавать бросая в воду: некоторые выплывают, некоторые нет…

Где же истина? Истина, как обычно, во вникании в данную конкретную ситуацию.  Для одних ситуаций подойдет один метод, для других - другой. И не надо видеть мир в черно-белых цветах: либо у нас директивное управление, либо самоуправление.

Кен Бланшар как раз предложил удобную модель для определения, какой стиль управления подходит для команды в зависимости от ее уровня. И оценивать команду предлагает по двум критериям: компетентность и приверженность - оба эти параметра постепенно изменяются по мере роста и развития команды…

Что из этого следует в реальности? Пока у новичков брызжет энтузиазм и они уверены в своей способности покорить Эверест (R1: не компетентны, но мотивированы), безопаснее их вовремя останавливать, чем давать проявлять инициативу. При этом их необязательно вдохновлять, они сами себя прекрасно вдохновляют. Лучше для всех директивно руководить (S1 - директивный стиль). А на следующем шаги они уже разочаровались после первых неудач (R2: недостаточно компетентны и демотивированы - см. кривую Данинга-Крюгера, она примерно про это же). Тогда нужно сменить директивный стиль поведения на наставнический, “продавая” свои (по-прежнему все еще директивные) решения и поддерживая сотрудников (S2 - наставнический стиль). Иначе разочарованные сотрудники просто уйдут. По мере того, как компетентность растет, лидеру всё важнее уметь ситуацию “отпускать” - (R3: сотрудники компетентны, но не достаточно мотивированы) здесь уместен менее директивный стиль руководства - поддерживающий. Ну а когда у команды высокая компетентность совмещается с высокой вовлеченностью (R4), здесь уже можно реализовать мечту хорошего руководителя - отпустить ситуацию. Команда сама разберется (стиль руководства делегирующий - S4). Примерно так и работает идеальная Agile-команда. Главное - понимать стадии развития команды и сотрудников, способствовать росту и постепенно давать всё большую инициативу, а не замереть навечно на директивном уровне со словами, что “эти без меня никогда ни в чем не разберутся, вечно приходится их контролировать”.

 
Понятно, что модель Бланшара всё упрощает (любая модель всё упрощает - они для этого и создаются). Но в моей практике она достаточно удобна, чтобы хотя бы в общих чертах понять, что происходит, и как лучше действовать на данном этапе.

Модель изменений Коттера
 

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

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

Один сотрудник франчайзи как-то делился, что наблюдал два крупных проекта по внедрению в организации MS Project. Оба проекта были серьезно организованными, были потрачены крупные деньги, проведено серьезное обучение… И оба проекта получили один и тот же результат: менеджеры, с которых требовали отмечать работы в Project’е, отмечали там что попало, а работали при помощи более привычных инструментов. Так что завершилось это всё крупным скандалом с увольнением ответственных лиц и  полной неудовлетворенностью результатом…

Как же повысить шансы на успех проектов преобразований? Работающую схему сформулировал Джон Коттер. Для того, чтобы изменения были внедрены, нужно последовательно пройти  8 шагов: 

• Создать ощущение срочности. По другому можно обозначить как очевидность необходимости. Чтобы ключевым заинтересованным сторонам было понятно, что это изменение необходимо, и без него никуда. Что важно - важно, чтобы диалог получился честным и открытым - например, про сложности изменения тоже стоит поговорить.

• Сформировать группу поддержки. Чтобы была команда, понимающая, в чем преимущество этого изменения. Без этого саботаж неизбежен.

• Сформулировать видение изменений. Картинка красивого светлого будущего, понимание к чему мы идем. Очень многие аналитики жалуются, что руководство продвигает внедрение новой ИС не озвучивая, а зачастую и не очень понимая само, а в чем смысл преобразования. “Морально устарело… Это используют конкуренты… Это необходимо”... - и ничего более конкретного. 

• Информировать все заинтересованные стороны. На этом этапе нужно как можно более частое подробное обсуждение, что и зачем мы делаем. Типичное заблуждение, когда топ-менеджмент считает: “они обязаны перейти на новый формат работы, потому что иначе мы их уволим - какая здесь еще нужна мотивация???”... К сожалению, такой подход не работает.

• Устранить преграды. В описанных выше история с Project’ом, проблемы и сопротивление всплывали на поверхность уже в конце проекта. Чем раньше мы понимаем сложности и ограничения, и чем оперативнее предпринимаем шаги для их разрешения, тем больше шансов, что всё получится. 

• Обеспечить краткосрочные победы. Это важный пункт при внедрении чего угодно нового. Взрослым, также как детям или животным (всем рекомендую книгу - Не рычите на собаку! Книга о дрессировке людей, животных и самого себя! Карен Прайор) нужен быстрый успех. Пускай маленький, но успех. А дальше - серия успехов. С трудностями будем бороться не в самом начале пути, а когда мотивация уже будет укреплена. 

• Поставить цели для дальнейших улучшений. После первых успехов неминуемо будут попытки отката назад. Не надо праздновать победу после тех самых маленьких успехов - изменения - это всегда длительный процесс. Скажем, Agile-трансформация в организации проходит не быстрее, чем за 2-3 года - нужно быть к этому готовым.

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

На самом деле, в PMBOK описывается еще много моделей, которые полезны для использования на практике.
Мне, в частности, кажется полезной модель командной продуктивности, которая в отличие от известной Лестницы Такмана объясняет, как можно поддерживать продуктивность команды на высоком уровне. 
И модель изменений Вирджинии Сатир, из которой становится понятно, что на надо бояться хаоса в ходе организационных изменений, так как это неизбежный этап для перехода... Про все модели рассказать здесь я явно не успею, про что-то попробуем поговорить на анонсированном в начале статьи вебинаре - в частности, как раз модель изменений позволяет более четко управлять ожиданиями бизнес-заказчика в трансформационном проекте - стоит их заранее подготовить, что этап хаоса неизбежен ))).  

  
У тех, кто прочитал эту статью может возникнуть резонный вопрос - а в чем ценность книги, если она представляет собой в большей степени структурированную компиляцию, чем какой-то уникальный материал? А именно в качестве этой компиляции. Да, в современном мире есть гигантское количество теорий, статей, книг, посвященных управлению проектами и смежным темам. Можно пытаться прочитать их все, и надеяться, что от этого станешь умнее… А можно посмотреть краткую выжимку рекомендаций от профессионалов в проектном управлении, и иметь готовый набор инструментов на все случае жизни. Впрочем, в Руководстве есть, конечно, и уникальная информация - просто будучи связана ограничениями по нераспространению уникального содержания без разрешения, я не стала рассказывать про них в этой статье… 

Если вам интересно узнать про PMBOK® 7 подробнее, и, главное, разобраться, какая в нём может быть польза для практической работы, то у меня для вас хорошая новость

Напоминаю, что осенью стартует целых три курса, построенных на основе 7 PMBOK®:

• Для начинающих РП - Базовый курс (первая часть Комплексного курса 3в1)
• Для РП с серьезными намерениями - Продвинутый курс по PMBOK® (2-ой модуль) (первая часть курса Подготовка к PMP в трёх частях)
• Для тех, кто хорошо знает старые версии PMBOK® - (в частности, для выпускников, уже закончивших Продвинутый курс по PMBOK® 6) - Cпецкурс, посвященный отличиям в 7-ом PMBOK®.

Сразу предупреждаю, приходить на курс имеет смысл только тем, кто хорошо освоил и умеет применять 5-ое или 6-ое издание на практике - так как иначе картинка проектного управления получится лоскутной. Всё-таки, что бы мы не говорили, большая часть инструментов и методов перекочевала в 7-ое издание из 6-ого в неизменном виде (повторюсь, каких-то радикальных изменений - с завтрашнего дня у нас революция и мы управляем проектами по новому), поэтому более привычные инструменты и техники знать тоже надо. Поэтому тех, кто пока не проходил Продвинутый курс - приглашаю более внимательно посмотреть на предложения выше.
Кстати, актуальное расписание моих курсов по управлению ИТ-проектами всегда (ну, почти всегда) доступно из левого меню сайта Инфостарта, раздел "Курсы".
Ну, и еще раз приглашаю всех на открытый вебинар 8 сентября в 19:00 мск. “Как быть, когда с Заказчиком невозможно договориться: Что на эту тему советует новый 7-ой PMBOK Guide?”  
Приносите свои кейсы, обсудим.