Вопросы адаптации решений по управлению проектами под 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.

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

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

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

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

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

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-системы, это только экспертная оценка.

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

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