Стандарт pmi pmbok рекомендует расставлять приоритеты компонентам портфеля как это лучше сделать

Добавил пользователь Дмитрий К.
Обновлено: 05.10.2024

Содержание статьи

Из всех изданий руководства от предыдущих значительно отличалась версия 2008 года, в которой были внесены новые структурированные модели (методики PMBoK):

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

В пятом издании описывается уже 10 областей знаний (в предыдущей версии было 9), поскольку одна из областей знаний была разделена на две самостоятельные. На эту пока самую актуальную версию и следует ориентироваться при рассмотрении свода знаний по проектному управлению.

Уточнение, которое поможет лучше понять PMBoK

PMBoK – это общее руководство, в котором:

Подходы к организации управления проектами

Управление проектами на основе стандарта PMI PMBoK даёт возможность выбрать наиболее подходящий проектный формат, в зависимости от сложности, срочности, важности, технологий, числа участников, привычности (рутинности) характеристик проекта. Поскольку под отдельный проект компании создаются в исключительных случаях для очень крупных и сложных проектов, основная проектная деятельность ведётся организацией с уже сложившейся структурой. Чаще всего это функциональная структура, наиболее распространённая в России.

В функциональной структуре принципиально то, что персонал объединён по специализации в отделы: плановый, капитального строительства, финансовый, маркетинга и т.д.. Исполнители подчиняются одному руководителю (начальнику отдела). Такие структуры эффективны и экономически целесообразны при решении рутинных привычных задач, которые выполняются в рамках одного подразделения. Если запускается проект, который требует привлечения исполнителей из разных подразделений (отделов) и их взаимодействие не имеет аналогов в предыдущей деятельности организации, начинают возникать трудности:

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

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

В слабой матричной структуре руководитель проекта (здесь он называется экспедитор) передаёт задачи через руководителя функционального подразделения. Эффективно такое управление, если у экспедитора есть достаточное влияние (в том числе – неформальное). В этой же структуре участвует и координатор проекта, ставящий задачи руководителям функциональных подразделений. Однако тут высок риск возникновения двойного подчинения и спровоцированных этим конфликтов.
В сильной матрице члены команды проекта, сохраняя свой статус и место в функциональной структуре, временно откомандировываются в команду проекта. Такие структуры устойчивы и эффективны при стабильной налаженной работе.

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

Области знаний PMBoK

В последнем издании PMBoK описывается 10 областей знаний из арсенала профессионального Project Manager, касающихся управления проектом в следующих частях:

1. Интеграция. Здесь это означает консолидацию, объединение, направленное на эффективное управление ожиданиями всех заинтересованных сторон. В разделе описываются:

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

2. Содержание. Здесь имеются в виду те процессы, которые позволяют производить выборки, отфильтровывание и группировку исключительно тех работ, которые будут необходимы Руководителю проекта. Для того чтобы определить, что войдёт, а что будет исключено, представлена схема Сбора требований, схема Определения содержания, а также схема построения Иерархической структуры работ.

3. Сроки. В этой части – речь о процессах, которые обеспечивают своевременное завершение проекта в указанные сроки. Для этого нужно определить операции и их последовательность, оценить ресурсы, длительность каждой операции, разработать расписание.

4. Стоимость. Сюда входят процессы, которые позволяют завершить проект в рамках первоначально утверждённого бюджета. Для этого необходимо произвести Оценку стоимости и Определение бюджета. Схема процессов включает в себя также Управление стоимостью.

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

6. Человеческие ресурсы. Процессы управления командой проекта предполагают распределение ролей и ответственности даже с учётом изменения в составе команды по ходу проекта. Имеет значение и момент привлечения специалиста – стадия проекта.

7. Коммуникации. Эффективность коммуникации зависит от того, насколько грамотно будут объединены интересы заинтересованных сторон с разнообразными культурными и организационными особенностями. Здесь должен быть консолидирован накопленный опыт, сопоставлены различные взгляды. Поэтому Схема управления коммуникациями предполагает Определение заинтересованных сторон и Управление их ожиданиями, Планирование, Распространение информации, Отчёты об исполнении.

8. Риски. Возможные риски идентифицируются, планируются, анализируются, в результате чего вырабатываются методы реагирования. Также необходим контроль и мониторинг рисками в ходе проекта. Это приводит к увеличению вероятности благоприятного исхода.

9. Поставки. Процессы в этой области сводятся к приобретению необходимых услуг, продуктов, документов, результатов у внешних организаций. При этом организация, осуществляющая проект, может выступать и в роли покупателя, и в роли продавца составляющих перечня. С помощью подпроцессов происходит управление контрактами с возможными изменениями по ходу проекта. Схема включает Планирование, Проведение и Закрытие закупок, Управление закупочной деятельностью.

10. Заинтересованные стороны. В этой части проясняется коммуникация между заинтересованными лицами и командой проекта. Выстраивается работа, направленная на удовлетворение потребностей заинтересованных лиц, в том числе – связанная с изменениями в проекте.

В этой статье мы рассмотрим основные мифы, связанные со Сводом знаний по Управлению Проектами PMI PMBOK. Этих мифов и ошибочных представлений гораздо больше, но мы рассмотрим 4 основных:

PMBOK — это стандарт
PMBOK состоит из лучших практик
PMBOK — это методология
PMBOK не связан с реальным управлением проектами

Эти мифы так глубоко укоренились в нашем сознании, что некоторые моменты данной статьи могут пошатнуть представления некоторых практиков управления проектами.

PMBOK – cтандарт по управлению проектами

Штамп ANSI

Международный стандарт

Эта фраза, написанная на обложке Руководства PMBOK, также вводит читателя в заблуждение. Какая международная организация по стандартизации объявила Руководство стандартом – неизвестно.

Из этого следует вывод, что весь PMBOK стандартом как таковым не является – ни в Америке, ни во всём мире. И слишком сильно полагаться на него не стоит.

PMBOK содержит лучшие практики

Другой распространённый миф был создан маркетинговыми подразделениями PMI и их партнёрами для того, чтобы активнее продвигать сертификацию и обучение по PMBOK – единственный источник дохода для большинства из них. Он состоит в том, что PMBOK продвигает лучшие практики в управлении проектами.

Получается, что PMBOK предлагает хорошие, но всё же не лучшие практики.

Зачем был создан этот миф? Затем, что если всё лучшее уже собрано в PMBOK, зачем искать что-то новое.

PMBOK – это методология

Достаточно часто приходится видеть рекламу курсов или онлайн дискуссии, упоминающие методологию PMI, PMP или PMBOK® Guide. Так вот, ничего из этого не существует. PMBOK – это фреймворк, PMP – сертификат, а PMI не занимается созданием методологий.

Руководства PMBOK недостаточно для того, чтобы эффективно управлять проектами – необходимо создать и внедрить методологию. Без методологии, чётко описанного жизненного цикла проекта, невозможно полноценное управление проектами. Не понимающие этого люди зачастую путают, например, группы процессов и фазы проекта.

PMBOK не применим к практике

Как и предыдущий миф, этот миф происходит из непонимания Руководства PMBOK, причём в первую очередь, к сожалению, теми, кто проводит обучение.

Правда ли это? И почему такие утверждения?

Некоторые практикующие руководители считают, что Руководство означает Инструкция. Они думают, что в PMBOK пошагово описана работа над проектам, с шаблонами и схемами. Они не понимают, что это не Корпоративная Система Управления Проектами (КСУП). PMBOK подразумевает, что такая система в компании уже есть, с описанными процессами и жизненными циклами.

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

Заключение

Да, Руководство PMBOK – это не инструкция, да и не планировался как таковая. Он и не может быть ей, так как существует великое множество различных видов проектов и отраслей со своей спецификой, и охватить их всех одним документом нельзя. Вот почему необходимо соотносить PMBOK с корпоративной методологией, системой управления проектами и организационной культурой.

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

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

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

Как известно, законодателем “моды” в мировом проектном управлении давно является американский институт 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 фактически говорил только о первом типе проектов (тех самых предиктивных), то теперь пытается охватить все, в том числе и небольшие. И говорит о том, что следует не фиксироваться на следовании тем или иным процессам, а сфокусироваться на соблюдении принципов.

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

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

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

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

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

Друзья, всем привет. Сегодня я расскажу про управление проектами, про методологию или свод правил по управлению проектами PMI PMBOK (Project Management Institute Project Management Body Of Knowledge). Выпустил эту методологию и регулярно ее обновляет авторитетный институт по управлению проектами, расположенный в Пенсильвании, США. Несмотря на то, что в мире есть и другие методологии, например британский стандарт PRINCE2 или японский P2M, в России наиболее популярна именно эта, на ее основе приняты ГОСТы по проектному менеджменту.

В целом я попробую лаконично, но возможности интересно рассказать о тех знаниях и опыте в области управления проектами, которые получил на данный момент. Также я являюсь сертифицированным экспертом по управлению проектами – PME.

Методика управления проектами универсальна, правила одни и те же. Сами же проекты всегда разные, они имеют начало и конец в отличие от операционной деятельности, которая, как бы происходит постоянно, рутинно. Мы с вами являемся участниками множества проектов и на работе и дома. Проектом может быть исследование рынка, разработка программного обеспечения, строительство нового здания. Проектом может быть и переезд на новое место жительства или создание семьи.

PMI PMBOK – методология использующая современный процессный подход, согласно которого все работы по управлению проектом осуществляются в виде отдельных взаимосвязанных между собой процессов. Каждый процесс начинается с исходного состояния и завершается неким результатом или ценностью, которая затем используется в других процессах или является конечным продуктом. Всего методология содержит 49 процессов из 10 областей зданий. Процессы можно сгруппировать не только по областям знаний, но и по фазам жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и контроль, завершение. Таким PMBOK есть сеть взаимосвязанных процессов по управлению проектами, выполнение которых приведет вас к успеху (статистика показывает, что вероятность успеха выше там, где используется осознанное профессиональное управление проектом). Свод правил как раз и описывает каким образом нужно производить каждый их этих процессов через определенные порядок, методики и инструменты.

Проект считается успешным, если не превышены запланированные для него бюджет и график, а также заказчик и конечные пользователи остались довольны его результатами.

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

Я решил привести информацию в структурированной форме, с учетом существования 10 областей знаний. Надеюсь, мои заключения будут интересны и полезны как тем людям которые только слышали про PMBOK, так и профессионалам. По каждой из областей знаний я опишу следующее:

Читайте также: