7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Публикация № 1184273

Методология - Управление проектом

В новой версии PMBoK традиционные рекомендации по управлению проектами перевернуты с ног на голову. В этой статье расскажу свою точку зрения, в чем, на мой взгляд, основные изменения, и как это может сказаться на проектах внедрения…   

Лирическое отступление

Подробнее про то, какие изменения ждут 7-ую версию PMBoK и как они повлияют на проектное управление, мы поговорим на бесплатном вебинаре 30 января, с 12:00 по московскому времени. Присоединяйтесь к дискуссии!

 

История вопроса

Как известно, законодателем “моды” в мировом проектном управлении давно является американский институт PMI (Project Management Institute), издающий широко известный томик PMBoK, содержащий исчерпывающие рекомендации, как надо реализовывать проекты. В частности, методологи 1С под лозунгом “к чему изобретать велосипед?” в своей “Технологии корпоративного внедрения” отталкиваются именно от процессов из PMBoK. 
 Предлагаемый ими подход давно уже рассматривается как стандарт для крупных проектов. Ну, а если вы работаете не так - значит, просто вы просто несерьезные, и “не дотягиваете” до планки… И правда ведь - в PMBoK явно указано, какие процессы должен включать в себя проект (от Разработки Устава до Закрытия проекта), в План управления проектом рекомендуется включать аж 18 компонентов (План управления содержанием, план управления требованиями, план управления конфигурацией, жизненный цикл проекта и т. п.). Правда, там, конечно, явно написано, что адаптируйте предлагаемые технологии под свою ситуацию, и берите то, что нужно. Скажем, Устав пригодится практически для любого проекта (другой вопрос, что он может быть предельно кратким - буквально несколько абзацев). А поддерживать сетевую диаграмму расписания в MS Project для внедрения, на котором работают один программист и один аналитик, может быть нецелесообразным. Но в любом случае, предполагалось изучать все 49 (в 6-ой версии) процессов управления проектами и понимать их взаимодействия (скажем, прежде чем создать описание содержания проекта, рекомендуется выявить заинтересованные стороны, составить планы управления требованиями и содержанием, провести сбор требований и т. п.) . Схема процессов при этом выглядит примерно следующим образом:

 

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

Честно скажу, идея, что для качественного управления проектами необходимо прочитать (а на самом деле, не прочитать, а осознать и освоить) талмуд в несколько сотен страниц, на многих действовала угнетающе. Но все привыкли к этой идее, и сообщество приучало своих членов к тому, что это неизбежно. В частности, в шаблонах документов уже упомянутой выше 1С:Технологии корпоративного внедрения, явно написано - мол, прежде чем использовать, скажем, план управления проектом или реестр рисков из технологии, изучите PMBoK. 
На практике такая установка нередко приводит к крену в сторону “умения производить впечатление” вместо “умения делать дело на самом деле”. То есть упоминание красивых слов и использование красивых шаблонов часто создает иллюзию профессионализма независимо от его наличия.  Не скажу, что это прямо повсеместная ситуация, но вполне знаю компании и внедренцев, успех которых был основан во многом именно на впечатлении солидности. Скажем, сам по себе факт, что РП пишет Устав, а тем более рисует расписание в MS Project, магически вызывает у заказчиков уверенность в его экспертизе (наблюдала этот эффект неоднократно). При этом то, насколько планам следуют дальше в процессе проекта, часто остается за кадром. (Наблюдала ситуации, в частности, когда расписание проекта рисовали в Project исключительно для галочки, и в работе не использовали вовсе - что, конечно, сводит на нет весь смысл таких планов).

 

Что изменилось в 7-ой версии

Однако, буквально несколько дней назад институт PMI выпустил черновик 7-ой версии PMBoK, которая, во-первых, гораздо меньше по объему. А во вторых, в ней  вместо процессов говорится про принципы.
Многие теоретики от проектного управления в шоке. Картина мира сломалась ))). Столько было разговоров про противопоставление PMBoK и Agile. Тот же Иван Селиховкин еще год назад прямо говорил о противоположных подходах “PMI или Agile?” противопоставляя гибкие подходы и следование процессам.  И вот теперь сам Свод знаний по управлению проектами стал гибким. На самом деле, это логичный шаг, учитывая реальную картину в ИТ-сфере. На самом деле, существенная часть проектов не может быть реализована по предиктивному подходу (когда мы с самого начала можем четко сформулировать цель, бюджет и сроки, составить план и выполнить его с минимальными отклонениями), а многие проекты осуществляются в гибких (или гибридных) условиях. И если раньше PMBoK фактически говорил только о первом типе проектов (тех самых предиктивных), то теперь пытается охватить все, в том числе и небольшие. И говорит о том, что следует не фиксироваться на следовании тем или иным процессам, а сфокусироваться на соблюдении принципов.

Вот так выглядит новая схема (фото с сайта pmi.org):

 


Как  же так - PMBoK и без процессов?
Честно скажу, PMBoK я в своей практике вполне себе использовала. Особенно при работе с крупными проектами. Но нюанс в том, что в первую очередь фокусируюсь-то я вовсе не на процессах и их описании. А на инструментах и техниках, которые рекомендуются для тех или иных процессов (к примеру - иерархическая структура работ, матрица ответственности и т. д.). И то же самое, когда я читаю курсы по проектному управлению - да, рассказываю про процессы, входы и выходы - особенно для тех, кто собирается сертификаты получать (например, 1С:Руководитель проектов требует знания PMBoK). Но важнее всего нам инструменты и техники. Самое интересное вовсе не в том, чтобы запомнить, что, скажем, управление рисками включает в себя процессы идентификации рисков, качественного анализа рисков и т. п. А то, какие есть лучшие практики по работе с рисками - как составлять реестр, как делать матрицы, как рисовать дерево решений и т. п. А инструменты и техники в любом случае из PMBoK никуда не деваются (разве что их из основной части перенесут в онлайн базу знаний).

 

На чем предлагает сфокусироваться 7-ой PMBoK?

Как я уже писала выше, новый путеводитель будет основан не на группах процессов (инициация, планирование, исполнение, мониторинг и контроль, завершение), а на принципах (а путеводитель - не на областях знаний (управление содержанием, расписанием, ресурсами и т. п.), а на областях деятельности). Какие же это принципы и области, и как они связаны с процессами из прошлых версий? 

 

 

Принципы управления проектами в новом PMBoK:
Сразу предупреждаю - в новом Своде знаний по управлению проектами мало вещей из серии “что-то принципиально новое, уникальное и гениальное”. Все-таки задача PMBoK - обобщить лучшие практики, и скорее всего со многими упомянутыми в нем вещами вы уже так или иначе сталкивались…
Итак, какие же 12 принципов предлагает поставить во главу угла новый стандарт? Начнем с ключевых первых четырех: 
1. Stewardship (ответственное планирование и управление) - здесь фокус внимания на том, что РП должен быть проактивным, а не действовать для галочки, и понимать, каким будет результат его действий.  По сути, здесь говорится про то же планирование и исполнение, про которые говорилось в прошлых версиях стандарта. Только с фокусами внимания на то самое “stewardship” - только не надо переводить это слово с английского как “прислуживание”, авторы имеют в виду под “being a steward” - интегрировать, заботиться, быть лояльным, соблюдать требования
Какое следствие из такого подхода для проектов внедрения? Здесь, мне кажется важный момент - быть честным с заказчиком (как внутренним, так и внешним), и искренне быть заинтересованным не в выполнении буквы контракта, а в получении им требуемого результата. На практике такое получается чаще всего, когда между заказчиками и исполнителями достаточно сильные неформальные отношения.  Ну и когда обе стороны заинтересованы в долговременном сотрудничестве, а не просто в получении денег в ближайшее время (не важно, идет ли здесь речь о работах по контракту или зарплате для ИТ-шника в штате).
2. Команда  - это всё то же управление человеческими ресурсами из прошлых версий, только с несколько большим уважением к членам команды проекта - ведь человеческий фактор значит для успеха гораздо больше, чем технологии. И, кстати, все большее значение приобретает мотивация вместо принуждения (до сих пор мне встречаются руководители, которые говорят "это входит в должностные обязанности сотрудников, зачем их мотивировать?" - но, увы, такой подход чаще всего не очень работает). 
3. То же относится и к следующему принципу - Заинтересованные стороны, при работе с которыми настоятельно рекомендуется учитывать готовность к изменениям конкретных людей, и на первый план выходит не внимание к деталям контракта, а умение договариваться (привет Agile манифесту!).
4. Ценность - это, по сути, все то же управление содержанием. Только с более гибким подходом - фокусом на целях, а не на результатах. Я неоднократно сталкивалась с ситуациями, когда клиенты обращались в нашу компанию-внедренца с запросом “Внедрите нам такое-то прикладное решение”. А при попытке слегка “копнуть, и выяснить, что же им актуально на самом деле - выяснялось, что главная цель, допустим, прозрачность управленческого учета, или повышение качества работы с повторными клиентами - таким образом совершенно не может быть решена. И в хорошем варианте внедренцы помогают заказчикам разобраться, что им нужно на самом деле. А в плохом - внедрение происходит, а цели никоим образом не достигаются. Вот как раз концентрация на ценности позволяет повысить шансы “хорошего” исхода событий.

На сегодня, кажется, всё. Продолжение следует. 
А всех заинтересовавшихся темой - приглашаю на бесплатный вебинар
Подробнее про то, какие изменения ждут 7-ую версию PMBoK и как они повлияют на проектное управление, мы поговорим на вебинаре 30 января, с 12:00 по московскому времени. Присоединяйтесь к дискуссии!

 

Продолжение статьи. Часть 2-ая.

 

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Valerych 24.01.20 18:50 Сейчас в теме
Супер обзор!
Особенно фрагменты про гибкие технологии/процессы, PMBoK/Agile
2. MariaTemchina 1246 26.01.20 13:41 Сейчас в теме
(1) Спасибо на добром слове! Приходите на вебинар - поговорим подробнее!
3. Alxesp 1 08.02.20 14:58 Сейчас в теме
OFF: Так и знал, что про руководство проектами женский пол напишет.
Все логично: в программировании разобраться неспособен - значит нужно руководить.
4. user856012 13 08.02.20 15:46 Сейчас в теме
(3)
Все логично: в программировании разобраться неспособен - значит нужно руководить.
Вы, видимо, не знаете классической поговорки: "Кто может - делает. Кто не может - учит, как делать. Кто не может учить - управляет".
jobkostya1c8; +1 Ответить
6. MariaTemchina 1246 09.02.20 18:25 Сейчас в теме
(4) Это вполне логично с точки зрения широко известного принципа Питера: "Каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности".
5. MariaTemchina 1246 09.02.20 18:23 Сейчас в теме
(3) ... Как правило, когда нечего сказать по существу - начинают придираться к собеседнику по формальным признаком - пола, возраста, национальности, цвета глаз и так далее...
7. advard 15 05.03.20 14:09 Сейчас в теме
Обзор хороший, кратко изложена суть. Но на мой взгляд не стоит тратить время на изучение того что не соответствует нашему менталитету, я имею ввиду Российскому. Нужно применять и создавать своё. Мы например используем технологический и календарный план и этого поверти вполне хватает для проектов любого масштаба.
8. Anastas181 07.04.20 14:59 Сейчас в теме
Подскажите, есть ли 7-е издание PMBoK на русском?
Alex_warrior; +1 Ответить
Оставьте свое сообщение

См. также

Стратегия выживания в корпоративных войнах Промо

Управление проектом Бесплатно (free)

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    10421    GSoft    16