PMBOK 4й редакции. Революция или Эволюция?

 

Вопросы адаптации решений по управлению проектами под PMBOK 4

До выхода 4й редакции PMBOK остаются считанные месяцы. Однако практически нет обзоров PMBOK 4 ни в России, ни за рубежом. Если поработать Google, то вы довольно быстро увидите, что сейчас вы читаете самым полный сравнительный обзор PMBOK 3 и PMBOK 4 вышедший в мире. Неслучайно такой обзор пишет представитель Microsoft EPM PAC, т.к. мы увидим далее PMBOK 4 является важным достижением по большему соответствию методик PMI и Microsoft. Благодаря сотрудничеству PMI и Microsoft EPM PAC возможны такие обзоры как этот.

Анализ PMBOK 4 усложняет то обстоятельство, что в мире нет еще ни одного сертифицированного специалиста по PMBOK 4 и нет ни одного тренера, который бы подготовил хотя бы одного PMP по PMBOK 4. В таких условиях тяжело найти эксперта, который может убедительно доказать свой профессионализм в PMBOK 4. Тем не менее они есть. Это авторы PMBOK 4 и PMBOK 3. Мы приведем их мнение. Также мы приведем оценки центральных экспертов PMI специализирующихся на итеративных методиках в связи с новой философией PMBOK 4. Корпорация Microsoft очень ценит мнение эксперта PMI Бонни Беафоре публикуя ее статьи на Microsoft.com и публикуя ее книги в Microsoft Press, мы приведем и ее мнение. К сожалению процедура неразглашения принятая в EPM PAC лимитирует использование информации Microsoft, однако мы приведем необходимые указания на совместимость методологий Microsoft Solution Framework и PMBOK 4.

Свое мнение я оформил как вопросы, вы можете на них дать ответ по своему усмотрению. В составлении данной статьи мне очень помог руководитель центрального отделения PMI по Украине Влад Березин (PMP), его комментарии по ряду вопросов приведены в обзоре.

Сравнивая PMBOK 3 и PMBOK 4 неизбежно встают вопросы, которые уже горячо дискутируются:

1) Можно ли считать, что в PMBOK 4 это принципиально другой уровень, если в PMBOK 4 пошли на удаление целых разделов и сделали такие большие исправления?

Авторы PMBOK 4 считают, что это не "перегруппировка" информации и не более детальное раскрытие  PMBOK 3, а принципиальные новые изменения. С интервью руководится  разработки PMBOK 4 вы сможете ознакомится ниже. Также соавтор и редактор PMBOK 3 считает, что изменения весьма существенные на концептуальном уровне. С другой стороны Влад Березин отмечает, что при переходе с PMBOK 2 на PMBOK 3 также были сделано множество изменений, но в целом концепцию стандарта это не изменило.

2)  Не привели ли столь большие переделки в PMBOK 4 к тому, что старые учебные курсы и методические наработки требуют полной переделки?

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

3) Стал ли PMBOK 4 вслед  за мировой тенденцией на программно-методические решения ориентированным на IT-технологии?

В PMBOK 4 вводит в практику системы искусственного интеллекта. Многие профессионалы во внедрении IT-систем увидят, что хорошо им знакомые принципы итеративности и ведения аналитики на прототипах делают PMBOK 4 "совместимым" с большинством современных методик управления проектами в области высоких технологий.

С другой стороны Влад Березин отмечает, что PMBOK 3 хотя и не раскрывает методических аспектов применения данных технологий, но и не запрещает их. 

4) Вполне логично, что при проекте внедрения самого проектного управления нужно следовать PMBOK.  Следует ли из того что в PMBOK 4  изъяли абстрактный документ похожий на "концепцию" и внедрили прототип, то обстоятельство что сейчас внедрение проектного управления по PMBOK 3 часто ведется ошибочно или неэффективно? 

На эти вопросы каждому нужно ответить самостоятельно внимательно изучив, что же так сильно поменяли в PMBOK 4.

Конечно новые требования это новая работа, но через это надо пройти. Нам пришлось потратить изрядные ресурсы на адаптацию под PMBOK 4, но как мы увидим далее компания работающая по PMBOK 4 получает существенные преимущества и может уйти от множества рисков в управлении проектами. В том числе в проекте внедрения самого проектного управления.

Вам следует принять решение о том насколько можно использовать старые учебные и методические  материалы в свете выхода PMBOK 4 самостоятельно.

Интервью с руководителем разработки PMBOK 4й редакции

Думаю лучше начать обзор PMBOK 4 с мнения авторов в оригинале.

Cynthia Stackpole, является руководителем проекта по разработке PMBOK 4й редакции.

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

Больший акцент на управление программами и портфельные методы (Introduction)

Приступим к анализу новой версии PMBOK.

Вводная часть среди прочего содержит довольно четкий акцент на управление программами проектов и портфелями проектов. Причем управление программами как видно по схеме ниже становится важной методологической частью.

Новый PMBOK во вводной части описывает только самые общие принципы управления программами проектов и портфелями проектов. Дело в том, что PMI готовит отдельные методические рекомендации по портфельному и программному управлению. Уже действует отдельная сертификация на программное и портфельное управление (PgMP, Program Management Professional).

Сертификат PgMP уже имеет около 100 специалистов в мире. При выборе модели сертификации PMI вам нужно определится, кто вы менеджер проекта или же портфельный менеджер?

Новые организационные требования (Organization)

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

PMBOK 4 - Новая философия итеративного управления проектами (Project Life Cycle)

То что PMBOK 4 стал не просто улучшением видно по большим изменения во вводной концептуальной части. До этого PMBOK вероятно оставался чуть ли не единственной из серьезных методик, которая имела раскрытое описание только для последовательного управление этапами проектов, что известного как методика водопада (waterfall).

Водопад следует принципу, что нельзя начать новую фазу незакончив предыдущую. Такое есть и в новом PMBOK

Но есть и еще новое - перекрытие фаз проекта. На рисунке реалистичный пример перекрытия фаз по проектированию и строительству для ускорения возведения нового завода.

Все это означает, что в PMBOK 4 теперь внедрены современные итеративные методики управления проектами.

Методика водопада формально объявлена в 1970 году после публикаций Винстона Ройса (Winston Royce).

Современные методики управления проектами такие как Microsoft Solution Framework, Rational Unified Processes и  Agile итеративные, т.е. подразумевают многократный возврат назад для улучшения результатов проекта. Аннотации к книгам с описанием методик, а также аннотацию к книге Бонни Биафоре с описанием практических приемов PMI, многие из которых соответствуют не PMBOK 3, а именно PMBOK 4 вы можете прочесть в этом обзоре.

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

Критика известных экспертов PMI концепции "водопада" в PMBOK 3

Более категоричен соавтор и соредактор PMBOK 3й версии Майк Гриффитс (PMP). Соавтор и редактор PMBOK 3 считает, что итеративность это принципиальное изменение в PMBOK 4. Вы можете ознакомится с его мнением в данной статье:PMBOK 4: This Time It's Iterative!

Майк не только соавтор PMBOK 3, но и один из основоположников популярной методики Agile, где итеративность концептуальный момент. Неудивительно поэтому, что Майк считает, что PMBOK 4 должен был в итеративности пойти еще дальше еще больше приближаясь к Agile.

Вопрос об итеративности неслучайно является таким концептуальным, т.к. меняет философию ведения проектов. Мишель Слигер (PMP) в своей статье по сравнению PMBOK 3 с Agile указывает, что в философии PMBOK 3 "священная корова" это сам план (plan driven), а в итеративных методиках "священная корова" это максимальное удовлетворение заказчика в рамках фиксированного бюджета и сроков (value driven). Мишель эту методологическую разницу демонстрирует следующей схемой известного треугольника "сроки-деньги-объем работ". На схеме Waterfall показывает подход "водопада" из PMBOK 3, а Agile демонстрирует итеративную парадигму управления проектами.

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

Итеративные методики управления проектами господствуют во всех видах проектов, где Заказчик готов мобильно менять требования к системе, чтобы повысить свой уровень удовлетворения, а также удержать проект в сроках и бюджете. Например, внедрение большинства информационных систем итеративно. Microsoft требует от партнеров итеративным способом внедрять системы управления проектами на базе Microsoft Project применяя специальную модификацию методики Microsoft Solution Framework.

Microsoft Solution Framework хорошо совместим с Agile, даже на сайте Microsoft есть готовые шаблоны и рекомендации. Неудивительно, что проблемы по интеграции с методиками PMBOK 3 стали схожими. Отличие MSF от Agile в основном касается более высокого уровня документированности процессов в MSF.

PMBOK 4 разрешил проблемы "совместимости" методических разработок PMI и Microsoft

Поскольку в PMBOK 3 не была явно и подробно описана поддержка  итеративности и разработки прототипа, то очень многие практики использующие итеративные методы довольно осторожно применяли PMBOK 3 отдавая ведущую роль итеративным методикам таким как Agile или Microsoft Solution Framework. Эти ограничения на использование PMBOK применяли и мы, т.к. будучи партнером Microsoft мы не могли пойти по пути игнорирования адаптированного Microsoft Solution Framework с готовыми методическими наработками.  

Хотя есть много предложений экспертов как преобразовать концепцию PMBOK 3 в интеративные методики (см. даже предложения Слигер - "paradigm shift"), на практике "сшивание парадигм" гладко и просто не происходило.

Очень многие  наши коллеги по внедрению Microsoft Project пошли по пути отказа от методических разработок Microsoft и создания собственных методических разработок, чтобы в точности соответствовать PMBOK 3. На уровне этапов работ, в коммерческом предложении на внедрение MS Project Заказчик не видел 4 этапа MSF по внедрению MS Project, хотя вроде бы это должно быть обязательно по сертификационной системе Microsoft в управлении проектами. Очень многие кто сейчас заглянут в свой план внедрения системы управления проектами убедятся, что в интеграции методологий PMBOK 3 и MSF все совсем не так гладко как бы хотелось.

Наблюдаемое по факту уклонение от использования MSF во внедрении MS Project доказывает, что разговоры о полной совместимости PMBOK 3 и MSF не более чем разговоры. Причем отметим, "жертвами" нестыковок стандартов чаще всего становятся конкретные методические наработки Microsoft как обобщение практики сотен крупных внедрений MS Project, репозитарий регламентов Microsoft, репозитарий шаблонов, планы работ скопированные с успешных внедрений  и т.д. и т.п.  Иногда методика из абстрактного спора "о понятиях" превращается в конкретные и существенные убытки.

C выходом PMBOK 4 ограничения на итеративность отпадают и теперь выбирать "MSF или PMBOK?" не требуется. PMI  "де-юре" в PMBOK 4 легализует итеративные подходы и многие процессы, как мы увидим далее, адаптированы именно под итеративное управление проектами. Поэтому партнеры Microsoft могут смело использовать наработки MSF и без лукавства утверждать, что это стандартный подход PMI, причем не опция, а столько же важный как и Волна.

PMBOK 4 заявив в недвусмысленной форме поддержку итеративных методов и создания прототипа, уже начинает привлекать новой философией множество новых сторонников в ряды PMI. В комментариях к статье Гриффитса сторонники итеративного Agile говорят о PMBOK 4 как о "глотке свежего воздуха" в управлении проектами.

Как сторонник  Microsoft Solution Framework (в адаптированной версии для внедрения Microsoft EPM) готов поддержать оценки PMBOK 4 как новой философии управления проектами. Как минимум теперь PMBOK 4 содержит описания обоих подходов. Следует отметить, что Microsoft как один из центральных партнеров и спонсоров PMI приложил достаточно серьезные усилия и со своей стороны для "повышенной совместимости" итеративного MSF и нового PMBOK 4.

Преемственность "старых" и итеративных методов управления проектами в PMBOK 4

От себя также могу добавить, что противопоставление постепенного уточнения и метода Волны с итеративными методиками неверно. Это методики для разных случаев в управлении проектами. Возможны и комбинированные варианты управления проектами. Например, подпроект проектирования может с фиксированным сроком и бюджетом вестись итеративно, а подпроект строительства может выполняться по методике "водопада". Такой комбинированный вариант поддерживается в Turbo Project.

Кроме этого итеративные методики могут сами использовать метод "Волны". Поскольку фиксация срока и бюджета хорошо совместима с принципом итеративного ведения, то детализация больших проектов "Волной" сверху-вниз обычно хорошо работает, а на уровне подпроектов уже господствует итеративность и мобильность. Наличие готовых нормативов срокам и бюджетам фазам в Rational Unified Processes позволяет этой итеративной методике делать эффективные планы Волной (мы использовали этот принцип в системе нормирования Turbo Project).

Поэтому рассматривать PMBOK 4 как отрицание старого опыта неверно. Наоборот, "старые" методики усилены новыми итеративными. 

Изменения в основных принципах управлениях проектами (Project Integration Management)

Исключение общего (предварительного) описания  состава работ

Российская традиция внедрения проектного управления это сначала составление бумажной "Концепции управления проектами".

В PMBOK 3 такого понятия нет, но есть документ "предварительное описание содержания"  (Preliminary Project Scope Statement), который обладал следующими основными характеристиками:

- описание результатов проекта без детальной конкретики и только на верхнем уровне
- описание только общих требований к процессам 

Если считать, что проектное управление внедряется тоже по PMBOK, то большинство "Концепций" с общими декларациями попадали под признаки Preliminary Project Scope Statement.

В принципе другого варианта в PMBOK 3 и не предусмотрено, предварительное описание содержание было единственным общим документом. Также довольно общие документы были на "планировании содержания" (Scope Planning).  

В PMBOK 4 удалены и Preliminary Project Scope Statement и Scope Planning. В принципе общих документов кроме Устава ничего и не осталось, все остальное очень конкретные регламенты для которых PMBOK 4 дает четкое описание содержания.

В связи с этим встает вопрос. Не является ли практика составления абстрактных "Концепций" методической ошибкой в свете требований PMBOK 4?

Не означает ли, что консультанты должны с абстрактных "Концепций" перейти к процедурам и документам описанным в принципиально новом разделе PMBOK 4 по сбору требований (Collect Requirements)?

Как минимум в PMBOK 4 довольно сложно обосновать наличие абстрактных "Концепции" в проекте внедрения проектного управления и найти в результатах процессов PMBOK 4 что-то похожее.

Влад Березин в своих комментариях отмечает, что PMBOK 4 не внес нового в практику опытных экспертов. Опытные эксперты и до выхода PMBOK 4 предпочитали детализировать концепции до реальных проектных документов (progressive elaboration). Поэтому появление точных требований к детализации только закрепляет "де-юре", что уже "де-факто" стало практикой у профессионалов. 

Консультанты PM Consulting Services не стали менять традиционное название "Концепция", но были исключены все абстрактные положения и по содержанию документ стал эквивалентен тому что описано в Collect Requirements.

Смещение акцентов в Уставе Проекта от инициализации в сторону создания авторитета менеджеру проекта 

Большие изменения коснулись Устава проекта. Устав проекта это документ формально авторизующий запуск проекта.

В PMBOK 3 за Уставом скрывалась процедура инициализации, в PMBOK 4 это изменено. Во вводной части PMBOK 4 можно прочитать то, что уже давно известно тем кто сдал экзамены на аналитика по внедрению Microsoft EPM: инициализация это дело портфельного менеджера. PMBOK не будет являться рекомендациями по портфельному и программному управлению. Соответственно в PMBOK 4 весьма последовательно очистили Устав Проекта от функций инициализации.

Исключены все функциональные и организационные требования из Устава Проекта. Из Устава исключено требование к описанию возврата инвестиций (ROI), т.к. все что происходит до Устава в том числе ROI-анализ это дело портфельного менеджера (см. п. 2.3.3 в PMBOK 4). В PMBOK 4 довольно четко прописаны границы проекты и действия которые за его границами в PMBOK 4 не входят.

Устав в PMBOK 4 это формальное подверждение уже принятого решения, а не процесс выработки такого решения.

Поскольку предварительное содержание аннулировано, то в Устав включены общие требования к проекту и продукту, но в очень кратком виде (high-level).

Состав Устава по PMBOK 4 выглядит так (курсивом отмечены изменения относительно PMBOK3, об исключенных пунктах рассказано выше):

• Цель проекта
• Измеряемые критерии успешности проекта
• Краткое изложение общих требований
• Краткое изложение описания сути проекта
• Краткое изложение характеристик продукта проекта
• Ключевые вехи по срокам проекта
• Ориентировочный бюджет
• Требования к системе утверждения результатов проекта и кто решает, что проект успешно завершен
• Менеджер проекта, его полномочия и ответственность
• Поименный перечень лиц с указанием их ответственности за проект

Следует отметить, что известный эксперт PMI Бонни Биафоре в своих книгах (см. обзор Microsoft Press) формулирует Устав также как в PMBOK 4 видя главную функцию в том, чтобы  наделить менеджера проекта властью и продемонстрировать заинтересованным лицам, что у менеджера проекта сильная поддержка спонсора (куратора). Бонии Биафоре отмечает, что для проекта весьма важно чтобы  менеджеры выступающие в роли спонсора (куратора) самостоятельно написали часть Устава Проекта. Это демонстрация уровня поддержки менеджеру проекта. PMBOK 4 облегчил данную задачу позволяя спонсору довольно просто изложить суть проекта.

В пункте 2.3.2 PMBOK 4 роль спонсора (куратора) в составлении Устава теперь обозначена. Во введении PMBOK 3 было указано что ведущий в разработке Устава это команда по управлению проектами (project management team), в PMBOK 4 эта ссылка убрана. Также по PMBOK 4 составление перечня основных результатов для Устава (Statement of Work, SOW) это теперь эксклюзивная привилегия спонсора. В SOW как в PMBOK 3 входит: декларация потребности организации, общие требования к продукту проекта и соответствие стратегическим целям организации.

Возможно именно идея большего вовлечения спонсора в написание Устава также нашла отражение в том, что из разработки Устава убраны инструменты для отбора проектов и даже методология проектного менеджмента. Действительно спонсор делает окончательный выбор методом собственной экспертной оценки. Поэтому только этот метод и оставлен в PMBOK 4 в разработке Устава.

Комментируя процессы по составлению Устава проекта в PMBOK 4 Влад Березин сожалеет, что авторы PMBOK 4 пошли по пути разделения функций портфельного менеджера (сертификация PgPM) и менеджера проекта (сертификация PMP). По мнению Влада практика многих организаций это инициализация проекта в рамках самого проекта, теперь PMBOK 4 не поддерживает такой способ инициализации.  

Процедура составления Устава проекта полностью переработана и практически не имеет ничего общего с PMBOK 3

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

Business Case теперь вынесен за пределы составления составления Устава. В него входит: запросы рынка, потребности бизнеса, запросы клиентов, технологические преимущества от проекта, соответствие законодательству и социальным потребностям.

Важность самого контракта смещена с 1го до 3го приоритета. 

Влияние на Устав факторов предприятия (Enterprise Environment Factors) резко сокращено до стандартов, организационной структуры и рыночных условий.

Резко сокращено влияние  организационных активов (Organization Process Assets) на Устав до стандартов, шаблона Устава и информации об предыдущих аналогичных проектах.

В числе экспертов участвующих в Уставе в PMBOK 4 впервые продекларирован Офис Управления Проектами и узкие эксперты по тематике проекта. Напомним, что по PMBOK 4 вся процедура устава состоит из экспертной оценки, остальные процедуры удалены.

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

Можно ли теперь использовать методические наработки по составлению  Устава сделанные для PMBOK 3? На мой взгляд нет и наши консультанты разработали новый шаблон Устава и переработали регламент ведения работ на данном этапе. 

Возможно вы согласитесь и  с другой точкой зрения, что эти изменения в PMBOK 4 несущественны и можно использовать старые наработки. 

Улучшение процедур Закрытия. Закрытия по фазам и закрытие контрактов на закупки

В PMBOK 4 изменена идеология процедуры закрытия. Из закрытия проекта целиком теперь процедура работает постоянно закрывая и отдельные фазы. Следует отметить что это следование реальным тенденциям на рынке. В других обзорах MicrosoftProject.ru отмечено смещение рынка в сторону больших программ и мультипроектов, которые состоят из множества подпроектов,  в таких условиях процедура закрытия фазы это часто закрытие подпроекта.

Влад Березин отмечает, что опытные эксперты могли путем трактовки общих положений PMBOK 3 использовать такие же процедуры закрытия как в PMBOK 4, разница заключалась только в том, что "де-юре" стандарт не прописывал подробности таких процессов. 

В PMBOK 4 процедура закрытия сделана более естественной. Из самой процедуры убрано понятие административного закрытия и закрытия контракта. Также из закрытия контракта убрано непременное использование "методологии" и информационных систем. Конечно решение о закрытия принимаю не методологи и не IT-системы, это только экспертная оценка.

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

Сам процесс закрытия контрактов закупки довольно хорошо прописан. Мы на этом остановимся далее. 

Новое в управлении содержанием проекта (Scope Management)

PMBOK 4 впервые описал процесс ведения аналитических работ

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

Что мы имели в PMBOK 3 как начало по управлению содержанием? Scope Planning - планирование содержания. Подразумевалось, что нужно описывать процессы по подготовке содержания проекта.

Если непредвзято вчитаться в PMBOK 3, то возникает много вопросов без ответов.

Кто должен придумать проектные решения для проекта?

Как должен придумать проектные решения?

Как проверить качество проектных решений до их реализации?

Все это были вопросы без ответов. Вместо этого были рекомендации описывать процессы планирования содержания. 

В PMBOK 4 удалили полностью Scope Planning. В связи с этим и вопросами выше, следует ли считать, что методические наработки сделанные в строгом соответствии с  PMBOK 3 содержат серьезные недостатки по ведению аналитических работ?

Это довольно серьезный вопрос. По мнению Влада Березина все зависело от самого консультанта. Опытные консультанты раскрывали полностью состав проектных документов и их практика и зафиксирована в PMBOK 4. В тоже время консультанты могли ограничится  и только общими положениями, PMBOK 3 это не запрещал.

Так это или нет нужно ответить каждому самостоятельно изучив новый процесс сбора требований к проекту (Collect Requirements) заменивший Scope Planning.

Теперь в обязанностях консультанта по управлению проектами детально выявить требования через большое количество специальных мероприятий. Это не может не радовать, т.к. ссылаясь на требования PMBOK 4 заказчики теперь смогут от консультантов получить более качественные регламентные документы. По-сути PMBOK 4 теперь может выполнить роль как СНИП у строителей, когда нужно вытащить из дизайнера и архитектора не только красивые общие штрихи решения, но и важные детали. Аналогично требуя исполнения указаний PMBOK 4 можно от консультанта теперь получить намного больше конкретики.

PMBOK 4 вводит довольно серьезный набор мероприятий по выявлению требований к проекту.

• Интервью
• Группы экспертов-стейкхолдеров по компетенции (Focus Group)
• Тематические сессии (Facilitated Workshop). Формат сессии: "эксперт и пользователь".
• Креативные техники принятия решений и разрешения конфликтов интересов стейкхолдеров, в том числе техники принятия решения меньшинством за большинство.
• Опросники
• Наблюдение за выполнением процесса в реальности, а не только по бумагам
• Прототипы

Явление Прототипа. Итерационные методы внутри процессов PMBOK 4

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

Прототипы встречались в PMBOK 3 в некоторых комментариях, но как реальный инструмент (Tools & Techniques) не значились ни в одном из процессов PMBOK 3. Как аналитический инструмент в PMBOK 3 нигде прототип не рассматривался даже на уровне замечания.

Появление прототипа в Collect Requirement очень принципиальный важный момент для проектов по внедрению самого проектного управления. Согласно PMBOK 4 прототип информационной системы управления проектами должен быть применен как аналитический инструмент сразу после Устава проекта и до всякой регламентации и разработки концептуальных документов.

В связи с этим встает снова важный вопрос. Не является ли текущая практика написания "Концепций" без проверки их на моделях-прототипах серьезной методической ошибкой?

Отметим, что многие ведущие поставщики решений и до PMBOK 4 не работали без прототипов, например эксперты Primavera без прототипирования не выполняет регламентацию. Мы поступаем ровно также. 

PMBOK 4. Состав регламентной документации перестал быть абстракцией

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

 

Описание требований стейкхолдеров (Stakeholder Requirements Documentation)

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

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

Опять же сразу встает вопрос. Большинство методически разработок для PMBOK 3 не имеют такого четкого перечня постановочных документов. Еще до выхода PMBOK 4 в стандартах Microsoft Consulting Services  обязательное четкое моделирование всех бизнес-процессов стало обязательным.

Однако многие методические наработки для PMBOK 3 декларируют только принципы, но не содержат таких конкретных пошаговых описаний. Следует ли тогда считать, что наработки сделанные по PMBOK 3 не гарантируют заказчику уровень детализации решения зафиксированный в PMBOK 4?

План управления требованиями (Requirements Management Plan)

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

Scope Planning обязательно требовал предварительного описания содержания, как уже отмечалось это удалено в PMBOK 4.

Scope Planning полностью отдавал отслеживание  содержания в конфигурационный менеджмент.

Requirements Management Plan требует разработать специальную процедуру по планированию, отслеживанию и отчетностью в требованиях к проекту. В PMBOK 4 подчеркивается связь с управлениями изменениями, но отмечается, что это теперь отдельная процедура. 

Матрица трансформации требований (Requirements Traceability Matrix)

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

Прочитав все эти новые процедуры и документы вы должны задать себе вопрос. Устарело ли все что сделано для PMBOK 3 в управлении содержанием, а тем более требованиями?

Мы для себя ответили, что устарело и переделали и шаблоны документов и процессов. 

Новые навыки в управлении персоналом (Human Resource Management)

Очевидно PMBOK 4 будет весьма коварен в новой сертификации PMP. Многие разделы внешне схоже выглядят с PMBOK 3. Однако при внимательном чтении видны многочисленные мелкие правки, за которые конечно будут "цепляться" вопросы в новом экзамене. Но даже для тех для кого PMBOK 4 это справочник знаний об управлении проектами довольно легко не заметить сильные принципиальные расхождения с PMBOK 3.

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

Новые навыки персонала (Interpersonal skills, Soft Skills) в PMBOK 3 уже были продекларированы во вводной части. В PMBOK 4 они поставлены во главу угла. Добавлен новый навык по генерации решений  (Effective Decision Making). Довольно легко проглядеть ссылку на Приложение X, где все эти навыки и расписаны.

Как легко догадаться, пропустив эти "мелочи" даже с хорошим знанием PMBOK 3 новый экзамен PMP не сдать.

Коммуникация нового уровня: выявление стейкхолдеров и искусственный интеллект (Project Communications Management)

Методики обнаружения влиятельных лиц (Identify Stakeholders)

В PMBOK 3 существовало предположение, что все заинтересованные лица проекта явятся сами и искать их не нужно.

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

Microsoft приводит в своей статистике, что 80% причин провала внедрения проектного управления это сопротивление персонала.

В связи с этим сразу вопрос. Является ли отсутствие таких работ по идентификации заинтересованных лиц серьезным методическим недостатком PMBOK 3 в управлении коммуникацией и управлении рисками?

Влад Березин отмечает, что хотя в PMBOK 3 не были прописаны четкие процессы по идентификации стекхолдеров и учету их при управлении рисками, но в PMBOK 3 практически в каждом разделе была общая ссылка на необходимость внимание на заинтересованных лиц ("Stakeholders Management is critical for success"). Опытные эксперты несмотря на отсутствие детальных указаний в PMBOK 3 самостоятельно разрабатывали и использовали методики по идентификации заинтересованных лиц и использования этих данных для управления рисками. Поэтому PMBOK 4 не вносит нового в практику экспертов высокого уровня, но фиксирует "де-юре" такую практику на уровне стандарта.

Слова Влада подтверждает известный эксперт PMI Бонни Биафоре, в своей книге она сразу же приводит методики идентификации стейкхолдеров так как это сделано в PMBOK 4.

По PMBOK 4  Действие по идентификации стейкхолдеров носит стратегический характер для проекта и должно производится на самых первых шагах, практически одновременно с созданием Устава проекта. 

 

Новый Регистр стейкхолдеров довольно эффективное средство для их выявления и выработки стратегии для работы с ними.

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

Диаграмма ниже позволяет выбрать оптимальную стратегию в зависимости от возможностей (Power) и интереса (Interest) стейкхолдера.

Отчетность об исполнении и прогнозы на базе Искусственного Интеллекта (Report Performance)

В PMBOK 3 были вводные слова о том, что неплохо бы иметь отчетность об исполнении проекта с прогнозированием развития проекта.

В PMBOK 4 это наполнилось более чем конкретикой. PMI взял на вооружение методику прогнозирования на базе Искусственного Интеллекта известную как Временные Ряды (Time Series Method). Причем данная методика прогнозирования считается теперь базовой и стоит на первом месте в списке инструментов.

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

Следует отметить, что выбор Time Series показывает что над PMBOK 4 работали действительно профессионалы высочайшего уровня в IT-технологиях.

Microsoft стал поддерживать методику прогнозирования Time Series только в 2005 году, но даже моя личная практика показывает высокую перспективность этого решения.

В данный момент мы с компанией Систематика выполняем правительственный контракт, в котором применяется технология прогнозирования Time Series.

Хотя мы сертифицированы Microsoft на внедрение такого инструментария прогнозирования изначально на запрос клиента отреагировал довольно скептически.

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

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

Технологии определения корреляций заложенные в Time Series делают его очень надежным, практически это единственная технология построения трендов корректность которой математически доказана. Собственно PMI неслучайно выбрал не какие-то абстрактные тренды, а именно тренды Time Series

Мы включим тренды для прогнозирования на базе Time Series по PMBOK 4 в новую версию Turbo Project.

Управление рисками. PMI сравнил PERT и Монте Карло (Risk Management)

В раздел по управлению рисками было внесено много изменений.

PMI исправил проблему с главным риском идущим от сопротивления персонала и сделал связь с Регистром стейкхолдеров

На идентификации рисков стали обязательными методы SWOT и экспертная оценка

В отслеживание рисков добавили новое мероприятие для обзора текущего статуса проекта (status meeting)

В PMBOK 4 эксперты PMI наконец включили PERT-метод и .... по сути объявил вне закона. Точнее PMI официально на уровне PMBOK правильно разъяснил, почему PERT вреден. Верно указаны две основные причины. Первая это низкая точность PERT, а вторая, что сам PERT не столько средство борьбы с рисками, сколько сам по себе риск, т.к. его оценки слишком оптимистичны.

Цитата из PMBOK 4 об PERT с указанием на эти проблемы:

"While such non-interactive models do not take merge bias into account (as Monte Carlo does), they do provide alternative (and more optimistic) approaches for  relative risk of a project."

Как видим PMI остается сторонником только метода Монте Карло. Пользователям MS Project, где есть только PERT не стоит огорчаться, используя Turbo Project вы можете получить систему прогнозирования на базе Монте Карло, которая дает и точность и не страдает избыточным "оптимизмом"

Управление закупками без "весовой" модели (Project Procurement Management)

В управлении закупками число процессов сократилось с 6 до 4:

• Планирование закупок (Plan procurements)
• Проведение закупок (Conduct procurements)
• Администрирование закупок (Administer procurements)
• Закрытие закупок (Close procurements)

Убран процесс по запросу информации у продавцов, но добавлены разные методы по поиску продавцов включая использование Интернет.

Однако самое главное изменение это исключение из обязательного применения методики закупки на весовых показателях (Weighting System).

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

Вроде бы логично, хотя даже участники тендерных комитетов часто себе задавали примерно такой вопрос без ответа: "Почему мы по этому критерию ставим оценку с весом 4, а не скажем с весом 5?"

Мне приходилось наблюдать как персонал обученный на курсах по PMBOK 3 выбирая через такую методику поставщиков теряет большие деньги и подписывается на большие риски. Причем сам персонал понимал, что тут "что-то не так", но доверие к PMBOK 3 брало вверх.

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

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

Опять зададим вопрос о "непогрешимости" PMBOK 3 и разработок на его базе.

Следует ли считать, что в PMBOK 3 была заложена ошибочная концепция управления закупками и это было исправлено в PMBOK 4?

В PMBOK 4 (п. 12.2.3.1)  указан следующий процесс для стратегических закупок.

1) Отобрать лучших поставщиков (selected sellers)

2) Решение о покупке принять топ-менеджменту (senior management)

Для такой стратегической покупки как система управления проектами это тоже верная методика. Первые лица компании должны найти время послушать презентации поставщиков и принять решение.

В связи с полным изменением процессов закрытия в PMBOK 4 появился отдельный процесс по закрытию закупок.

Как и в PMBOK 3 обязательно использование систем документооборота (Records Management System) для работы с контрактами.

Последствия PMBOK 4 для тех кто собирается сдавать на PMP

Думаю многих волнует именно такой вопрос. Ответ кроется в том, что вы хотите.

По моему мнению  и мнению Влада Березина для подготовки к новой сертификации PMP потребуется переделка существующих учебных курсов.

Существенные отличия в порядке составления Устава, ведения аналитических работ, работы с заинтересованными лицами и т.п. делают проблематичным применение старых учебных курсов к новой сертификации PMP. Разделы типа управления персоналом внешне схожи с PMBOK 3, а в реальности сильно переработаны и отличаются во множестве мелочей, за которые по традициям PMI и будут цепляется на экзамене.

Стал ли PMBOK 4 более естественным и меньше страдать "PMIизмами" в терминологии Риты также решать Вам, на мой взгляд PMBOK 4 более хорошо ложится в традиции управления проектами существующими на реальной практике. Обратите внимание, как велико удовлетворение от создания итеративности в PMBOK 4 у менеджеров, которые используют такие методики в своей практике постоянно.

Кроме этого, как вы могли заметить из комментариев Влада Березина в PMBOK 4 явно описаны многие лучшие практики и не требуется догадываться как они должны выглядеть.

Если вы хотите получить, не только сертификат, но и реальные знания, то вероятно лучше ждать новой версии экзамена PMP.

Вероятно его будет и легче сдать опытному менеджеру, т.к. "PMIизмов" станет существенно меньше и можно обращаться больше к собственному опыту.   

С другой стороны курсов по PMBOK 4 еще долго не будет. Поэтому другая стратегия сдачи PMP это сдавать сейчас и максимально быстро пока не отменен экзамен по PMBOK 3, т.к. преподавали сертифицированы по устаревшей версии PMBOK 3 и быстро переучится на новый PMBOK 4 несмогут.

Имеет ли смысл сейчас учится по PMBOK 3?

Для тех кому нужна культура управления управления проектами, а не просто сертификация, это вопрос открытый.

Я и Влад Березин пришли к одному выводу, что для базовых и элементарных знаний по управлению проектами вполне пригодны и довольно старые материалы.

Для расширенных навыков в управлении проектами все зависит от того насколько существенны для вас изменения PMBOK 4 в  подготовке Устава, описания содержания проекта, изменения в методике организации закупок, а также впервые описанные методики  идентификации стейкхолдеров и т.д.

Также важным является, сможете ли вы как Влад применяя свой практический опыт "додумать" положения PMBOK 3 или же хотите сразу получить готовые процедуры из PMBOK 4.

Как партнерам Microsoft эффективно применять PMBOK 4

Партнерам Microsoft следует уже начинать эффективно применять PMBOK 4 даже до официального выхода.

"Повышенная совместимость" PMBOK 4 с передовыми методиками управления IT-проектами позволяет его уже начать применять на практике.

Несекрет, что многие IT-менеджеры не принимали PMBOK 3 так как не могли догадаться как Влад Березин как "додумать" PMBOK 3 для реализации нужных процессов.

Сейчас все это исправлено. Формально зафиксированное итеративное планирование и создание прототипа- это PMBOK 4. Плюс PMBOK 4 имеет очень качественное описание процессов организации аналитических работ, чего стоит только Collect Requirements. В этом плане PMBOK 4 смог не только догнать, но и перегнать многие частные IT-методики.

Потом другой важный плюс для партнеров Microsoft это возможно использовать PMBOK 4 как средства контроля консультантов, которые выступают постановщиками. Компания которая выполняет заказ на бизнес-моделирования может быть достаточно хорошей, однако отдельные консультанты могут искать более легкий путь абстрактных регламентов. Как правило консалтинговые компании заинтересованы в повышении качества работ, поэтому на уровне начальников консультанта вы скорее всего найдете поддержку в использовании PMBOK 4 как стандарта.

Требования PMBOK 4 жесткие и конкретные, поэтому выбрав его как стандарт можно избавить себя и клиента от рисков некачественных регламентов. Кроме этого, PMBOK 4 позволяет (и даже обязывает!) вам прямо во время регламентации испытать на прототипа проектные решения консультанта и доказать что это работает или же это все  нежизненные схемы.

Использовать ли заказчикам PMBOK 4 как стандарт уже сейчас?

Заказчикам решений по управлению проектами стоит PMBOK 4 внедрять уже сейчас. За оставшиеся несколько месяцев уже изменений не предвидится.

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

Заказчик проектного управления как правило не в состоянии "додумать" PMBOK 3 и нуждается в четких процедурных указаниях на уровне стандартов. 

Я бы также обратил внимание на создание прототипа из PMBOK 4, как средство ранней диагностики качества проектных решений консультантов.

Еще раз обращаю внимание, что разработка прототипа по PMBOK 4 начинается сразу после Устава проекта (Project Charter) и даже до всяких "Концепций". Сначала проектные решения должны быть найдены и первично проверены на модели, а потом уже документированы.

Интегрируем MSF для MS Project и PMBOK 4

Мы стали заранее готовится к выходу PMBOK 4, т.к. как уже отмечалось выше сочетать итеративную методику Microsoft Solution Framework можно без натяжек только с PMBOK 4.

Обращаем внимание, что для внедрения MS Project имеется специальная адаптация MSF с готовыми методическими наработками, их хотелось сохранить, но при этом соблюсти стандарты PMI.

Мы уже скорректировали свою методику внедрения проектного управления в следующих моментах:

• Подготовка Устава по требованиям PMBOK 4 с акцентом на демонстрацию поддержки спонсора менеджеру проекта
• Ведение идентификации заинтересованных лиц и применение стратегий управления стекйхолдероами по требованиям PMBOK 4
• Проведение всех видов мероприятий по сбору требований, заявленных в PMBOK 4, включая создание прототипа и фокус-группы.
• Описание отраслевых бизнес-процессов управления проектами согласно требованиям PMBOK 4
• Использование документов PMBOK 4 по трансформации выявленных требований, включая матрицу трансформации.
• Введение прогнозирования на трендах Time Series в коммуникацию о текущем состоянии проекта.
• Применение методики Монте Карло при управлении рисками и разъяснение недостатков PERT на основе требований PMBOK 4
• Приведение  в соответствие с PMBOK 4 наших шаблонов документов по отдельным процессам

PMBOK 4 потребовал практически полной переделки методических наработок PM Consulting Services сделанных в соответствии с PMBOK 3 и MSF. Мы хотели иметь методические достижения PMI и Microsoft в виде интегрированного методического пакета, только PMBOK 4 позволил сделать "сшивание" методик без вольных трактовок PMBOK.

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

Считаете ли вы что должны как можно скорее перейти на передовой стандарт PMI решать Вам. Сравнительная информация для размышлений изложена.