PMI PMBOK 2004 – «Новый завет» библии менеджера проектов

31.05.2008 16:38:24

Мнения и комментарии ведущих российских специалистов по управлению проектами об основных новшествах стандарта PMI PMBOK Guide 2004

Уважаемые коллеги, мы, как и все российское сообщество по управлению проектами, с нетерпением ждем выхода переработанной новой версии стандарта PMI - PMBOK Guide 2004.

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

Используя этот стандарт, большинство руководителей проектов в России смогли повысить свою профессиональную компетенцию и использовать в своих компаниях и проектах передовые управленческие технологии. Принятие PMBOK как базового источника компетенции по УП позволило повысить культуру управления на многих российских предприятиях, которые в данный момент являются лидерами в своих бизнес-областях.

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

Итак, по официальной информации PMI, в PMBOK 2004 внесены следующие основные изменения по сравнению с версией 2000:

1. Внесены уточнения в различии между жизненным циклом проекта и жизненным циклом продукта;
2. Количество процессов управления проектом увеличено с 39 до 44;
3. Если в предыдущем издании структура знаний УП описывается в основном по «областям знаний», то в новом издании усилен фокус на процессах и группах процессах;
4. Глава 3, «Процессы управления проектами», перенесена и переименована в новую Секцию 2 «Стандарт управления проектами для отдельного проекта». Эта глава также существенно доработана, с целью показать, что процессы, «входы» и «выходы», рассмотренные в этой части, должны являться базисом Стандарта управления проектом для отдельного проекта. Составлена карта процессов, показывающая их интеграцию. Добавлены 6 процессов и 14 переименовано;
5. Описаны необходимые требования для выделения пяти групп процессов (и процессов, их составляющих) для отдельного проекта;
6. Усилено значение процессов Инициации и Завершения проекта;
7. В группу процессов Контролинга добавлено описание нового процесса «Мониторинг» и сделан акцент на новое содержание группы «Процессы мониторинга и Контроля»;
8. В Главе 4 «Интеграция в Управлении Проектами» пересмотрено и расширено описание значения интеграционных процессов в проекте (Project Management Integration)». Показана важность интеграции для управления проектом и его успешного завершения. Расширено и детализировано описание связей между процессами управления, включая процессы Инициации и Завершения;
9. Описание навыков Общего Менеджмента объединено в одной секции в Главе 1;
10. Команда проекта должна быть компетентна во многих областях знаний, поэтому добавлена секция, определяющая экспертные области, которые команда проекта должна понимать и использовать;
11. Расширена секция, посвященная связанным видам деятельности. Дополнена информация по Управлению Портфелем проектов. Описаны различные варианты использования Проектного Офиса в организации;
12. Добавлена информация в главу по управлению предметной областью (содержанием) проекта, с целью улучшения определения Устава проекта, Плана управления предметной областью и роли Системы управления конфигурацией. Процесс инициации управления предметной областью был удален, но разработка документа, утверждающего содержание (предметную область) проекта была рассмотрена в Части 4 (Интеграция в УП) и более подробно рассмотрена в Главе 5 Управление Предметной областью проекта;
13. Более широко рассмотрены способы применения и важность Work Breakdown Structure (WBS) в Главе 5 - Управление Предметной областью проекта, добавлены описания методов и средств разработки WBS;
14. В Главу 6 добавлена секция «Управление по временным параметрам», включая информацию об оценках затрат по проекту, выравниванию загрузки ресурсов и отчетах о ходе работ проекта, чтобы показать, как эти процессы влияют на календарный план проекта. Для наглядности добавлены рисунки;
15. В Главе 7 Управление Стоимостью Проекта добавлена информация, касающаяся процессов контроля стоимости, включая подсекции по средствам и техникам, действиям и управлению в кризисных ситуациях. Процесс планирования ресурсов был удален, но процесс планирования человеческих ресурсов был описаны в Главе 9 Управление человеческими ресурсами;
16. Перенесена и расширена секция, касающаяся метода Освоенного объема (Earned Value) в Главе 7 Управление стоимостью в проекте. Секции Метод освоенного объема и Планирование ресурсов также перенесены;
17. В Главу 8 Управление качеством в проекте были внесены незначительные изменения (добавлены несколько новых секций) - чтобы лучше осветить эту тему;
18. Глава10 Управление коммуникациями в проекте теперь включает в себя информацию по обратной связи и совещаниям по обзору состояния проекта, для демонстрации важности этих процессов в проектных коммуникациях;
19. В Главу 11 Управление рисками в проекте добавлены подсекции, содержащие информацию о категориях рисков, предположениях, вероятности, влиянии, а также список возможных мер реагирования. Добавлена новая диаграмма Структурной Декомпозиции рисков (Risk Breakdown Structure);
20. Последняя секция в Главе 11 Управление рисками содержит повторение описания процессов управления рисками, чтобы показать, что выполнение этих процессов должно повторяться на протяжении всего жизненного цикла проекта;
21. Глава 12 Управление Поставками в проекте включает некоторые изменения, которые касаются в основном команды проекта как покупателя материала, продуктов, товаров и сервисов для проекта, либо как покупателя\продавца проекта по контракту;
22. Был существенно переработан глоссарий и введена некоторая категоризация терминов для избежания различного толкования;
23. Добавлены следующие процессы:
    • разработка устава проекта;
    • разработка документа, определяющего предметную область (содержание) проекта;
    • контроль и мониторинг работ по проекту;
    • закрытие проекта;
    • создание WBS;
    • определение количества необходимых для операции ресурсов;
    • управление командой проекта;
24. Для всех процессов были пересмотрены «входы», средства и техники, «выходы», с целью усиления интеграции между процессами и построения более четких «карт» процессов.

Более подробную информацию обо всех изменениях и новшествах в PMBOK 2004 вы можете найти на страницах web-сайта http://www.pmi.org/.

Мнения ведущих специалистов по Управлению Проектами в России по представленному драфту 2004 версии стандарта

Алексей Полковников

PMP, Вице-президент Московского отделения PMI,
Вице-президент Российской ассоциации
управления проектами СОВНЕТ

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

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

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

Процессы управления проектом

PMBOK увеличился в объеме (примерно на 50 страниц). В основном это произошло за счет развития раздела, описывающего последовательность управленческих процессов (Глава 3 выросла с 9 до 27 страниц). По существу, появилось достаточно хорошо структурированное руководство по последовательности управленческих процедур с описанием входов и выходов, которое имеет самостоятельную ценность для читателя. В предыдущей версии PMBOK процессы делились на основные и вспомогательные, причем только основные процессы были взаимосвязаны, а вспомогательные были представлены несвязанным подмножеством. Спорным являлось выделение организационного планирования и планирования коммуникаций из основных процедур разработки плана проекта, а также разрыв в процедурах планирования рисков и др. Приходилось объяснять это общим характером документа, предусматривающим высокую степень гибкости при описании процедур управления конкретным проектом. В новой версии схемы, отображающие последовательность процессов, значительно переработаны - все процессы объединены в единую последовательность, добавлены основные результаты. Процесс инициации проекта теперь, кроме разработки устава проекта, включает и процедуру разработки предварительного определения проекта (scope statement).

Результаты процессов управления (outputs, deliverables)

Имеет смысл также обратить внимание на изменения в описании результатов процессов управления. В большинстве процессов есть изменения в описании входов и выходов. В общем, есть тенденция к уменьшению описываемых результатов. Например, если раньше в результате инициации проекта на выходе, кроме выпуска устава проекта, описывались также такие результаты как назначение менеджера проекта, описание предположений и ограничений, то в новой версии остался только устав. Похожая ситуация и с другими процессами. Например, в процессах планирования управления рисками вместо значительного количества результатов предлагается единый интегрирующий документ - «регистр рисков». Обращает на себя внимание также изменение названия документа «План проекта» на «План управления проектом». В принципе оба этих термина используются на практике. Иногда под планом управления проектом понимается более узкий документ, входящий в план проекта. В России более распространен термин План проекта.

Области знаний управления проектами

Количество и названия областей знаний не изменились, однако внутри произведены некоторые (можно сказать значительные) изменения. Наибольшие изменения претерпел раздел знаний, связанных с управлением интеграцией проекта. Видимо, по идее авторов, процедуры данного раздела должны стать «хребтом» сквозного процесса управления проектом, а процедуры других разделов выстраиваться вокруг интеграционных процессов. Для достижения этой цели все процедуры, связанные с разработкой ключевых документов и сбором ключевых показателей по проекту перенесены в раздел «Управление интеграцией», включая процедуры разработки устава, определения и плана управления проектом, процедуры управления, мониторинга и контроля, управления изменениями и закрытия проекта.

Менее значительные изменения управленческих процессов есть почти во всех остальных разделах знаний. Я бы обратил Ваше внимание на новые процессы «Управление заинтересованными сторонами» (Manage Stakeholders) и «Оценка потребности задачи в ресурсах» (Activity Resource Estimating). Еще одним приятным новшеством являются схемы взаимосвязи процессов внутри областей знаний, что позволяет получать более целостную картину по каждой области. Считаю, что с выходом новой версии PMBOK 2004 будет сделан серьезный шаг как в развитии стандарта, так и в улучшении его восприятия. Естественно, что любое значительное изменение связано с появлением спорных моментов и шероховатостей (на которых я не стал акцентировать внимание). Но для их устранения еще есть время.

Сергей Вратенков

PMP, Вице-президент Московского отделения PMI

Первые впечатления от знакомства с новой версией стандарта PMBOK Guide:

1. Основные и неосновные процессы
   В новой версии стандарта нет деления на основные и неосновные процессы. Это представляется правильным, т.к. условность такого деления не вызывала сомнения. Применение нужных в каждом конкретном проекте процессов передается на усмотрение команды проекта.
2. Названия процессов
   Изменения в названиях процессов производят двойственное впечатление. С одной стороны, некоторые изменения давно напрашивались, например названия процессов выбора поставщиков. С другой стороны некоторые изменения мне просто не нравятся, особенно добавление глагола “Perform” (производить) в названия процессов обеспечения и контроля качества. Третья группа изменений названий не имеет достаточных оснований ни за, ни против. Простой пример. Какое название лучше, “Project Plan Development” (“Разработка Плана Проекта”) или “Develop Project Plan” (“Разработать План Проекта”)? Разработчики стандарта утверждают, что новые глагольные названия более понятны. Возможно это и так, однако понятность любых кратких названий довольно субъективна. Хуже всего то, что новая стилистика не распространенна на все процессы. В прежней версии все процессы назывались единообразно неглагольно, теперь же получилась каша. Часть процессов называется по-прежнему, а другая часть получила новые «более понятные» глагольные названия.
3. Инициация
   Название процесса инициации изменено с “Initiation” («Инициация») на “Develop Project Charter” («Разработать Устав Проекта»), а в группу процессов инициации добавлен процесс “Develop Project Scope Statement (Preliminary)” («Разработать Содержание Проекта (Предварительное)». Представляется, что это шаг в правильном направлении. Предыдущая версия инициации выглядела упрощенно, материал новой версии гораздо лучше структурирован. Замена основного входящего документа “Product Description” («Описание Продукта») на “Statement of Work” («Состав Работ») приветствуется, так как второй документ шире и наконец-то соответствует процессу планирования поставок. Однако появление двух процессов инициации вместо одного приводит к неясности: где же момент появления проекта? Эта неясность принципиальна для определения стоимости проекта, т.к. все предпроектные расходы аллоцируются на что угодно, кроме самого проекта. Я бы предложил пойти дальше и вынести процедуру выбора проекта в исполнение из первого в новый третий процесс инициации, который станет той самой точкой появления проекта. В этот процесс надо вернуть результат «Менеджер проекта назначен», который совсем исчез из новой версии стандарта.
4. Планирование содержания
   Вместо двух процессов планирования Содержания проекта (Project Scope) стало четыре. Логическая последовательность разработки Содержания теперь следующая: Предварительное Содержание (при инициации) -> План управления Содержанием -> Детальное Содержание -> WBS. Мне импонирует улучшение структурированности материала при таком подходе. Однако выделение создания так любимой всеми WBS в отдельный процесс приводит к тому, что лично мне не совсем непонятно, как может быть создано Детальное Содержание теми методами и средствами, которые указаны в процессе. Конечно, можно говорить о том, что все процессы по сути своей есть процессы логические, или, что мы явно разделяем Содержание проекта и Содержание продукта проекта. Однако сразу после определения WBS приведена фраза о том, что WBS - это просто графическое представление Содержания. Если так, то зачем огород городить? Может тогда логичнее объединить два последних процесса?
5. Команда и участники
   В области управления персоналом и взаимодействием произошли существенные изменения. Старый добрый процесс “Team Development” («Развитие команды»), который содержал гвоздевые темы (власть, конфликты, переговоры, мотивация, …) превратился в набор сухих и деловых процессов управления командой и участниками. Упоминания о теории мотивации Маслоу я не нашел вообще! В целом, новый подход к этим вопросам представляется оправданным, включая как переструктуризацию процессов, так и вынесение теорий управления персоналом за рамки стандарта. Однако остается много вопросов по содержанию этих процессов, обсуждение которых требует много места и времени.
6. Резюме
   Новая версия стандарта пока не производит цельного впечатления. Есть как несомненные улучшения, особенно в структуре и содержании большинства процессов, так и изменения, вызывающие вопросы. Широкое обсуждение стандарта в сообществе менеджеров проектов должно привести к устранению шероховатостей и созданию современной версии стандарта управления проектами.

Александр Кутузов

PMP

В новой версии стандарта (а точнее пока только в его драфте), заметно дальнейшее движение к его рациональности, конкретности и прагматичности, исключению двусмысленности и упрощению. С другой стороны, уделено большее внимание к так называемым“soft skills”; управлению командой проекта, управлению ожиданиями заинтересованных сторон (стейкхолдеров) проекта (добавлен отдельный процесс Manage Stakeholders), которые, на мой взгляд, являются одними из самых важных компетенций и навыков руководителей проектов (и которые так часто ими в проектах игнорируются!).

Порадовало то, что, более тщательно проработана инициация проекта – наконец-то наведен порядок в понятиях Project Charter, Scope Statement, (detailed& preliminary), Project management Plan.

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

Из мелочей, удивление вызвало то, что из оценки длительности работы продолжительности и из количественного анализа рисков исчезло упоминание о методе PERT , но остался почему-то метод составления расписания на дугах (AOA), который уже давно активно не используется. Конечно, более стало разумным упоминание о Earned Value Analysis в управлении стоимостями (а не в управлении коммуникациями, как в PMBOK 2000).

Руководителям проекта сделан подарок в их общении с аудиторами или проектным офисом - в самом начале 3-й главы жирным шрифтов выделено, что в каждом конкретном проекте должны использоваться не все 46 процессов описанных в стандарте, а только те, которые сочтет нужным руководитель проекта вместе со своей командой (ответственность за выбор процессов управления накладывается на того же руководителя проекта). Это, конечно, представляет лазейку менеджерам проекта, поэтому, я считаю, что должны быть определен набор обязательных процессов (и возможно документов) для всех проектов (такие, как например Scope Definition) и вспомогательных, которые выбираются самим руководителем проекта. Хотя, конечно, при корпоративном управлении проектами это может быть определено в методологии управления проектами компании.

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

Алексей Субботин

член Правления СОВНЕТ

PMBOK сделал большой шаг вперед к "процессному" подходу. На сегодняшний день этот подход реализован в стандартах серии 9000, в современных стандартам по ИТ и такое усовершенствование PMBOK несомненно упростит его применение. Особо хочется отметить появление процессных диаграмм - в прошлых версиях их практически не было и приходилось тратить время и восстанавливать их по тексту своими силами.

Радует и внимание уделенное структуризации - разработка WBS вынесена в отдельный процесс, в стандарте наконец появилась Risk Breakdown Structure.

И, конечно, появление понятия портфеля проектов дает надежду на то, что в следующих редакциях появятся и процессы управления портфелем проектов.

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

Андрей Белозеров

СPMP, Вице-президент Московского отделения PMI

Выпуск нового издания PMBoK является важным событием в мире управления проектами. PMBOK 2004 несет в себе много новшеств – усилены отдельные элементы, улучшена структуризация информации, добавлены недостающие звенья. Но при этом нельзя сказать, что она содержит в себе радикально новые технологии проектного менеджмента, в отличие от модели организационной зрелости управления проектами (OPM3), выход которой, на мой взгляд, является существенно более важным и значимым событием в мире управления проектами.

Если PMBOK 2000 была полностью нацелена на управление отдельным проектом и на главное действующее лицо – менеджера проекта, то в новом издании PMBOK сделан существенно больший акцент на управление портфелем. Тем не менее, PMI в своем своде знаний все еще относит такие области знания как управление программой, управление портфелем, проектный офис к «смежным областям» (related endeavors), что позволяет говорить о том, что PMBoK 2004 по прежнему главным образом ориентирована на управление отдельным проектом.

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

Еще одним важным аспектом, который хотелось бы отметить, является критерий включения информации в PMBOK2004. Если ранее в стандарт включалось описание подходов и практик УП, которые являлись общепринятыми (generally accepted), то теперь в PMBoK включаются общепризнанные (generally recognized as good practice) практики.

Т.е. если ранее эти практики были «аксиомами», которые были разработаны в ходе академических исследований и разработок, то сейчас можно сказать о том, что завершился некий среднесрочный цикл использования управления проектами на практике, в рамках которого была получена огромное количество информации об успехах и неудачах использования проектных подходов во всем мире. И PMBOK 2004 строится уже на основе переработанного опыта использования УП в компаниях во всем мире, что существенным образом повышает его значимость как международного стандарта по управлению проектами.

Артем Терпугов

директор направления Московского отделения PMI

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

Претерпело сильное изменение управление интеграцией проекта, что еще раз подтверждает жизненную необходимость этих процессов. В данном разделе следует отметить появление таких жизненно необходимых процессов УП как Direct and Manage Project Execution, Monitoring and Control Project Work.

В новой версии усиленно внимание важности команды проекта и здесь мы уже можем найти требования к компетенции команды проекта, чего ранее не было. Мы можем увидеть новые процессы, акцентирующие свое внимание на команде проекта: управление командой проекта (manage project team) и управление ожиданиями заказчика (manage stakeholders).

В целом новая версия все больше акцентирует свое внимание на следующих вещах:

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