В настоящей статье проводится сравнительный анализ PMI PMBOK® и OGC PRINCE2®, рассматриваются их идеология, процессные модели, география использования и другие аспекты, связанные с их применением. Везде далее, если не оговорено особо, речь пойдет о PMBOK® 5th Edition и PRINCE2® в версии 2009 года.

Введение

Как известно, в настоящее время в США и Великобритании применяется целый ряд подходов к управлению проектами. Среди них – универсальные и фундаментальные, как например, PMI PMBOK® 5th Edition, OGC PRINCE2® (2009) и APM APMBOK®, и гибкие (или облегченные), как например, Agile-методы (в частности, SCRUM), и узкоспециализированные, как например, NASA Project Management and Systems Engineering Competency Framework.

Тем не менее, традиционно принятыми в США и Великобритании подходами можно считать соответственно именно PMI PMBOK® и OGC PRINCE2® в силу их весьма широкого применения в этих странах. Стоит отметить, что упомянутые документы PMI и OGC уже давно используются во всем мире и по праву считаются стандартами международного уровня по управлению проектами.

В настоящей статье проводится сравнительный анализ PMI PMBOK® и OGC PRINCE2®, рассматриваются их идеология, процессные модели, география использования и другие аспекты, связанные с их применением. Везде далее, если не оговорено особо, речь пойдет о PMBOK® 5th Edition и PRINCE2® в версии 2009 года.

Правообладатели и разработчики

PMBOK® создан и принадлежит американскому Институту по управлению проектами (PMI), который был основан в 1969 году и представляет собой крупнейшую в мире некоммерческую ассоциацию профессиональных руководителей проектов. Эта организация разрабатывает стандарты по управлению проектами, проводит конференции и семинары, организует обучение, осуществляет профессиональную сертификацию.

Правообладателем PRINCE2® является Министерство государственной торговли Великобритании (OGC), образованное в 2000г. в результате слияния ряда Правительственных организаций, включая Центральное вычислительное и телекоммуникационное агентство (CCTA), которое и создало данную методологию, а также — Консультативную группу по гражданской недвижимости и Агентство по закупкам. OGC разрабатывает и совершенствует стандарты для управления закупками, проектами и государственным имуществом, контролирует и сравнивает результаты работы подразделений правительства с требованиями стандартов и данными по лучшим практикам и т.д. PRINCE2® – торговая марка OGC.

История возникновения и развития

Подход PMI появился в середине XX века как побочный продукт американских оборонных проектов, таких, как например, «Манхэттен» (середина 1940-х), «Поларис» (конец 1950-х) и других. В 1996г. была опубликована первая редакция PMBOK®, и затем с интервалом один раз в четыре года выходили последующие версии этого документа, соответственно, вторая редакция – в 2000г., третья – в 2004г., четвертая – в 2008г. и пятая – в 2012г.

В 1975г. британская компания Simpact Systems Ltd. разработала Метод управления компьютерными проектами PROMPTII, который явился прототипом PRINCE2®. В 1989г. на основе PROMPTII Центральное вычислительное и телекоммуникационное агентство (CCTA) разработало первую редакцию методологии PRINCE, обязательную к использованию во всех правительственных проектах по созданию информационных систем. В 1996г. при участии Консорциума специалистов из 150 общественных и частных организаций была создана версия PRINCE2®, универсальная и применимая к любым проектам, представляющая собой вторую редакцию данной методологии. В 2002г. появилась ее третья редакция, в 2005г. – четвертая и в 2009г. – пятая.

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

География применения

Как известно, PMBOK® применяется на всех континентах в более чем 185 странах мира. Он пользуется наибольшей популярностью в США, Канаде, Мексике, Азиатских странах, включая КНР и Индию, и практикуется в той или иной степени в каждой стране, имеющей членство в ВТО. По статистике, 70% членов PMI находятся в Северной Америке.

Методология PRINCE2® также находит применение на всех континентах в более чем 150 государствах [2]. Наибольшей популярностью она пользуется в Великобритании, многих странах Европы, ЮАР, Австралии, Новой Зеландии, США (в ИТ-проектах нефтяных компаний). Стоит отметить, что в противовес ситуации с PMBOK®, 70% пользователей PRINCE2® находятся за пределами Великобритании. За последние четыре-пять лет резко возрос спрос на использование PRINCE2® в Индии и Китае, причем в КНР за последние годы прирост количества практикующих PRINCE2® составляет 100% в год [4].

Практикующие организации

Предприятий, использующих в своих проектах подход на основе PMI PMBOK®, в мире найдется великое множество. Такие организации действуют во всех странах, имеющих членство во Всемирной Торговой Организации (ВТО). В силу относительно меньшего географического охвата, методология PRINCE2® распространена в мире не настолько широко, как PMBOK®. Поэтому приведем список организаций, практикующих подход OGC, в качестве примера.

Среди государственных и общественно-политических можно отметить Британское Правительство, Полицейские Силы Великобритании, Евросоюз, Всемирный банк, Программа развития ООН (UNDP) и другие организации.

К торговым предприятиям, практикующим в своей деятельности PRINCE2®, относятся Siemens, Bank of New York, ВАТ, крупнейшие банки и телекоммуникационные операторы Великобритании, Philips, Microsoft, Unilever, Tesco, Philip Morris UK, GlaxoSmithKline, Tesco, Shell, Nokia, Novartis, HSBC, Cornhill, Sun, Hitachi, Fidelity, и другие.

В России и странах бывшего СССР методология PRINCE2® используется в международных британских фирмах, как например, British American Tobacco и British Telecom, а также в крупнейших международных американских корпорациях, как например, IBM и Hewlett Packard. Причем, как известно, две последних применяют и PMBOK® и PRINCE2® одновременно.

Сравнение подходов PMBOK® и PRINCE2® [1,2]

Таблица 1.

П/п Критерий сравнения PMBOK® PRINCE2®
1 Идеология Свод знаний, навыков и передовых практик по управлению проектами.Ключевые принципы:Это – руководство (причем не пошаговое) и не методология [1].Ориентированность на выполнение требований заказчика.Приводятся процессы, инструменты и методы.

Носит описательный и рекомендательный характер.

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

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

Имеет предписывающий (директивный) характер.

2 Определение проекта Ограниченная временем деятельность по созданию уникального продукта, услуги или результата. При этом слово «продукт» — в единственном числе, хотя и допускается использование нескольких компонентов одного сложного продукта;термин «управленческие продукты» не используется. Временная организация, образованная для создания одного или нескольких специальных продуктов на основании утвержденного экономического обоснования. При этом помимо специальных продуктов используются управленческие продукты:Business Case, Project Brief, Project Initiation Documentation, Benefits Review Plan, Highlight report, End-Stage report и другие.
3 Основные проектные ограничения (параметры) Сроки, Затраты, Содержание, Качество, Риски, Ресурсы, Удовлетворенность заказчика Затраты, Сроки, Качество, Содержание, Риски, Выгоды от реализации
4 Персональная ответственность за проект Project Manager (Руководитель проекта) Executive (Ответственный руководитель проекта/Председатель Совета проекта или Спонсор в терминах PMBOK).
5 Требования к Председателю Проектного Комитета (Совета проекта) и его членам Даны на уровне общих положений Изложены в отдельном руководстве [3].
6 Команда управления проектом Исчерпывающий список в документе PMI не приводится, поскольку ее состав зависит от целей и содержания проекта. Включает в себя членов команды, которые непосредственно вовлечены в деятельность по управлению проектом и могут отвечать за определенные объемы работ (представители поставщиков и подрядчиков, руководители подпроектов, администраторы). Состав этой команды достаточно четко определен и состоит из1) Совета проекта (Executive, Senior User, Senior Supplier),2) Руководителя проекта,3) Менеджеров команд специалистов,4) Администратора проекта,

5) Внутреннего контроля проекта.

7 Роли и ответственности Определяются руководителем проекта в каждом отдельно взятом проекте по необходимости Для всех проектов определены и описаны 8 основных ролей: Executive, Senior User, Senior Supplier, Project Assurance (Business, User and Supplier), Change Authority, Project Manager, Team Manager(s), Project Support.
8 План проекта Объединенный детализированный документ, включающий в себя составляющие его отдельные планы по областям знаний, относящиеся к двум категориям: Планы управления и Базовые планы. Как общий, так и отдельные планы доступны для любой заинтересованной стороны проекта. Высокоуровневый документ;определяет, как и когда будут достигнуты цели проекта;показывает основные продукты, задачи и необходимые ресурсы;используется Советом проекта в качестве Базового; на основании Плана Проекта составляются детальные Планы этапов (Stage Plans) и Планы команд (Team Plans), по которым работают Руководитель проекта и Руководители команд, а также — план для исключительной ситуации (Exception Plan).
9 Прохождение границ этапов Рекомендовано корректное прохождение Kill points (Stage gates); эскалация Проектному комитету в случае проблем Регламентировано на уровне отдельного основного процесса Managing a Stage Boundary
10 Управление изменениями/отклонениями Рекомендовано использование процедуры Общего управления изменениями PMI;Эскалация на рассмотрение Комитета по управлению изменениями в случае существенных изменений Регламентировано использование допустимых отклонений (tolerances);Configuration Management – управление изменениями продуктов;Все изменения в проекте трактуются как инциденты.
11 Issue Management
  • Issue – потенциальная проблема, с которой надо работать, с тем, чтобы она не превратилась в настоящую серьезную проблему;
  • подход к управлению потенциальными проблемами не приводится;
  • рекомендовано ведение Issue Log.

 

Issue – уже произошедший инцидент, который случился незапланированным образом и требует вмешательства вышестоящего руководства. Это может быть1) запрос на изменение,2) отклонение от заданных характеристик в одном из продуктов,3) прочие проблемы или затруднения, которые требуют от менеджера проекта решения или эскалации. Регламентировано ведение Issue Register (для инцидентов, которые требуют формального разрешения), Issue Report (для детального анализа и документирования формальных инцидентов), Daily Log (для инцидентов, с которыми можно работать неформально).

Архитектура PMBOK® 5th Edition и PRINCE2® (2009)

В PMBOK® представлены 10 областей знаний (Интеграция, Содержание, Сроки, Стоимость, Качество, Персонал, Заинтересованные стороны, Коммуникации, Риски, Закупки) и 5 процессных групп (Инициации, Планирования, Исполнения, Мониторинга и контроля, Завершения), для которых подробно описаны 47 процессов управления проектами. Для сравнения отметим, что в предыдущей версии PMBOK® было 9 областей знаний и 42 процесса.

В случае PRINCE2® работает «магическая» цифра 7: в соответствующем документе фигурируют 7 принципов, 7 тем, 7 процессов. Принципами являются Continued business justification, Learn from experience, Defined roles and responsibilities, Manage by stages, Manage by exception, Focus on products, Tailor to suit the project environment. В этой методологии описаны следующие темы: Business Case, Organization, Quality, Plans, Risk, Change и Progress. Данный стандарт регламентирует использование 26 управленческих продуктов, 8 ролей и ответственностей, 2 методов (Планирование на основе продуктов и Техника ревизии качества). В нем также приведены Рекомендации по адаптации на случай проекта в программе, отношений заказчик/исполнитель, нескольких владельцев проекта, использования с другими моделями жизненного цикла и стандартами, изменениями масштабов проекта. Интересно отметить, что в версии PRINCE2® от 2005 года было описано 8 основных и 45 подпроцессов, 36 управленческих продуктов, 10 ролей.

Темы и Области знаний

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

Хотя можно отметить, что тема Risk PRINCE2® заметно коррелирует с аналогичной областью знаний PMBOK®, тема Organization ограниченно соответствует области знаний HR Management, тогда как раздел Управление закупками совершенно отсутствует в PRINCE2®.

Сопоставление процессных моделей

В PMBOK® описаны 47 процессов управления проектами. Из них — 2 инициации, 24 планирования, 8 исполнения, 11 мониторинга и контроля, 2 завершения. Каждый из 47 процессов PMBOK® выполняется в проекте один или несколько раз, причем процессы инициации открывают проект (его фазу), процессы завершения — закрывают, а основной ход проекта (или отдельной фазы) предполагает возможность выполнения со взаимным перекрытием друг друга во времени (overlapping) процессов планирования, исполнения, мониторинга и контроля. Названия процессов PMBOK® приведены в соответствующих разделах Таблицы 2.

Методология PRINCE2® регламентирует использование в каждом проекте 7 основных процессов: Starting up a Project (SU), Directing a Project (DP), Initiating a Project (IP), Controlling a Stage (CS), Managing Product Delivery (MP), Managing a Stage Boundary (SB), Closing a Project (CP) и 40 подпроцессов (или деятельностей), являющихся частью соответствующих основных. Соответственно, этих деятельностей в SU – 6, в DP – 5, в IP   – 8, в CS — 8, в MP – 3, в SB – 5, и в CP – 5.

Таким образом, модели процессов PMBOK® и PRINCE2® сопоставимы по глубине проработки. Тем не менее, рассмотрим более подробно работу процессной модели PRINCE2® (см. рис.1), поскольку взаимодействия в ней представляются несколько более сложными по сравнению с PMBOK®.

В PRINCE2® жизненный цикл проекта состоит из управленческих стадий, разделяемых «воротами», по достижении которых Совет проекта (СП) принимает решение, продолжать ли данный проект.

Своего рода импульсом к запуску проекта является создание уполномоченным органом (Корпоративным руководством или руководством программы проектов) Мандата проекта, являющегося неким аналогом Устава по PMBOK®. При появлении оформленного Мандата запускается однократный предпроектный процесс «Начало проекта» (SU — Starting Up a Project), устанавливающий проектные цели и подход, в ходе которого формируется команда проекта и план следующей стадии (инициации). При этом должны быть получены ответы на ряд вопросов: «Следует ли делать проект? Будет ли он жизнеспособным? Достижимы ли цели?», чтобы СП мог принять решение о целесообразности выделения ресурсов для реализации последующих стадий проекта. При положительном решении СП запускается процесс «Инициация проекта» (IP — Initiating a Project), в ходе которого проводится его детальное обоснование (указываются причины запуска) и составляется план проекта (продукты, работы, бюджет, риски, выгоды, ресурсы, качество) в форме документации по инициации проекта (PID) с экономическим обоснованием (Business Case). Отметим, что для простых проектов процессы SP и IP могут быть объединены в один.

Одновременно с обоснованием и инициацией начинается процесс «Руководство проектом» (DP — Directing a Project), который далее выполняется на протяжении всего жизненного цикла проекта и регламентирует одобрение работ и ресурсов СП, авторизацию его начала и завершения (в т.ч. принудительного), тем самым обеспечивая ответственность СП за его успех. В основе этого процесса лежит принцип управления по исключениям, описанный выше (см. табл.1).

Процесс «Контроль стадии» (CS — Controlling a Stage) фокусирован на повседневном управлении проектом проектным менеджером. Этот процесс предусматривает авторизацию пакетов работ (WP – Work Packages) для создания или изменения продуктов, их регулярный мониторинг и закрытие, управление проблемами и изменениями, отчеты о ходе проекта и прогнозы для СП, корректирующие действия для удержания проекта в пределах допусков и эскалирование на СП в случае их превышения.

image-1

Рис. 1.  Модель процессов управления проектом в PRINCE2® ( УГС – управление границами стадии, КС – контроль стадии).

Для управляемого перехода от одной стадии к другой служит процесс «Управление границами стадии» (SB — Managing a Stage Boundary). Он включает процедуры отчетности о результатах текущей управленческой стадии и оценку их влияния на план проекта, риски и экономическое обоснование, разработку и одобрения плана следующего этапа, а также извлеченные уроки. Процесс SB применяется и при возникновении исключительной ситуации и включает ее анализ и создание при необходимости плана по исключению (Exception Plan).

Нижний уровень непосредственно создания и приемки продуктов проекта (Delivering) описывается процессом «Управление созданием продукта» (MP — Managing Product Delivery). В ходе этого процесса менеджеры или члены проектных групп информируют РМ о прогрессе работ посредством отчетов о прохождении контрольных точек (Checkpoint Reports). В процессе MP используется техника PRINCE2® оценки качества продуктов (Quality Review) с определенными структурой, процедурой и ролями.

Отметим, что процессы CS, MP и SB повторяются на каждой стадии реализации проекта.

Методология PRINCE2® придает особо важное значение этапу завершения проекта, управляемого процессом «Закрытие проекта» (CP — Closing a Project). Этот процесс описывает подготовку и проведение формального закрытия проекта: принятие финального продукта, отчет о закрытии с подтверждением достижения целей и ожиданий, определенных в PID и запросах на изменения, а также оценку выполнения проекта по отношению к утвержденным контрольным версиям (Baselines) и полученного опыта, и уроков (Lessons Learned), либо принудительное закрытие проекта в случае потери актуальности его экономического обоснования. Он также включает планирование послепроектной оценки выгод, фиксацию открытых вопросов и рисков и выработку рекомендаций по их закрытию.

Сопоставление видов деятельностей в PMBOK® и PRINCE2®

Таблица 2.

П/п Вид деятельности PMBOK® PRINCE2®
1 Предпроектная рекомендованы экономическое обоснование и анализ осуществимости, на основании которыхпринимается решение о запуске проекта;экономическое обоснование учитывается только при его инициации. описана на уровне двух основных процессов (SU и DP);соответствие первоначальному экономическому обоснованию поддерживается на протяжении всего проекта. В результате выполнения SU создается Project Brief, включающий в себя краткое изложение содержания проекта.
2 Инициация Неглубокая: процессы Develop Project Charter и Identify Stakeholders. Глубокая на уровне следующих деятельностей процесса IP:Prepare Risk Management Strategy, Prepare Configuration Management Strategy, Prepare Quality Management Strategy, Prepare Communication Management Strategy, Set Up Project Controls, Create the Project Plan, Refine the Business Case, Assemble the Project Initiation Documentation (PID).PID включает в себя общий высокоуровневый план проекта.
3 Планирование Реализовано в процессах детального и общего планирования:Plan Scope Management, Collect Requirements, Define Scope, Create WBS, Plan Schedule Management, Define Activities, Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, Develop Schedule, Plan Cost Management, Estimate Costs, Determine Budget, Plan Quality Management, Plan HR Management, Plan Communications Management, Plan Risk Management, Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Plan Procurement Management, Plan Stakeholder Management,Develop Project Management Plan. Детальное планирование реализовано на уровне следующих деятельностей:Plan the next stage,Update the Project Plan,Update the Business Case,Authorize a Work Package,

Accept a Work Package,

Produce an Exception Plan.

 

4 Планирование содержания продукта и проекта В соответствии с Генеральной целью проекта и требованиями стейкхолдеров составляется Матрица отслеживания требований, на основе которой создается документОписание содержания проекта. Затем на основании этого документа составляется Иерархическая структура работ проекта (ИСР – WBS). ИСР – это жесткая вертикальная иерархия, на самом верху которой изображается Генеральная цель, которая декомпозируется на подцели, каждая из которых расщепляется на соответствующие задачи, задачи – на подзадачи и т.д., пока на самом нижнем уровне не будут получены Пакеты работ. Пакет работ представляет собой совокупность элементарных проектных работ, требующую для своего исполнения не более 80 рабочих часов. В соответствии с Project Brief в высокоуровневом Плане проекта приводитсяoбщее описание продуктов проекта (PPD). На всех уровнях детальных планов, включая Stage Plans, Team Plans, Exception Plans составляютсяИерархическая структура продуктов (PBS),детальные описания продуктов (PDs), Диаграмма последовательности создания продуктов (PFD), а также -Пакеты Работ. Пакет работ – это  объем информации об одном или нескольких продуктах, составляемый руководителем проекта для передачи ответственности за его выполнение менеджеру команды или члену команды. Продукт разбивается на несколько составляющих его продуктов, если для его создания необходимо выполнить более одного пакета работ.

 

5 Исполнение Реализовано через следующие процессы:Direct and Manage Project Work, Perform Quality Assurance, Acquire Project Team, Develop Project Team, Manage Project Team, Manage Communications, Conduct Procurements, Manage Stakeholder Engagement. Реализовано на уровне следующих повторяющихся деятельностей процессов MP, CS и SB:Execute a Work Package,Receive completed Work Packages,Report highlights,Escalate issues and risks,

Take corrective action,

Report stage end.

6 Мониторинг и контроль реализованы посредством следующих процессов:Monitor and Control Project Work, Perform Integrated Change Control, Validate Scope, Control Scope, Control Schedule, Control Costs, Control Quality, Control Communications, Control Risks, Control Procurements, Control Stakeholder Engagement. реализованы посредством процессов DP, CS, MP и SB и их деятельностей:Authorize initiation, Authorize the Project, Authorize a Stage or Exception Plan, Give ad hoc direction, Review Work Package status, Review the stage status, Deliver a Work Package, Capture and examine issues and risks,Report stage end, Authorize project closure. Проводятся Quality Reviews и Benefits Reviews.
7 Завершение реализовано в процессах Close Procurements и Close Project or Phase. реализовано на уровне деятельности Report stage end и процесса СP; проводятся Benefits Reviews.
8 Постпроектная В жизненный цикл проекта не входит. В течение года после окончания проекта проводится проверка реализации выгод (PIR — Post Implementation Review). Эта проверка в PRINCE2® детально не регламентирована.

Продуктно-ориентированное планирование в PRINCE2®