Более подробно о всех изменениях вы сможете прочитать в представленном драфте 2004 версии PMBoK 2004 по адресу: https://secure.pmi.org/exposuredraft/.

Мнения ведущих специалистов по Управлению Проектами в России по представленному драфту 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).

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

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