Лирическое отступление
Подробнее про то, какие изменения ждут 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-ая.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
