Сравнительный анализ: американский и британский подходы к управлению проектами

Введение

Как известно, в настоящее время в США и Великобритании применяется целый ряд подходов к управлению проектами. Среди них – универсальные и фундаментальные, как например, 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) для создания или изменения продуктов, их регулярный мониторинг и закрытие, управление проблемами и изменениями, отчеты о ходе проекта и прогнозы для СП, корректирующие действия для удержания проекта в пределах допусков и эскалирование на СП в случае их превышения.

Для управляемого перехода от одной стадии к другой служит процесс «Управление границами стадии» (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®

Сначала описывается финальный Продукт проекта (PPD — Project Product Description) для того, чтобы поставщик точно знал, что нужно произвести, пользователь точно знал, что он получит, и чтобы их представления и ожидания совпадали. Этот шаг нужен только для составления плана проекта, а следующие за ним шаги применяются на всех уровнях детального планирования.

Итак, после описания Продукта проекта создается иерархическая структура продуктов (PBS — Product Breakdown Structure). Продукты в PBS подразделяются на управленческие (Management products) и технические (Specialist Products), а также на внешние и внутренние. Наверху такой диаграммы помещается Продукт проекта, далее производится его декомпозиция на основные компоненты, каждый компонент делится на свои составляющие и т.д. Процесс деления на компоненты продолжается, пока не будет достигнут желаемый уровень детализации. Пример PBS приведен на рис. 3.

Рис. 3. Пример иерархической структуры продуктов для проекта конференции. (приведены только технические продукты; управленческие не показаны с целью упрощения схемы)

Условные обозначения:

 — Внешние продукты
 — Внутренние продукты
 — Группы продуктов

Внешние продукты — необходимые для достижения проектной цели, которые уже существуют или будут поставлены от внешних источников.

Внутренние продукты – те, которые создаются по ходу проекта.

Группы продуктов – совокупности однотипных продуктов для удобства планирования.

Для каждого значимого продукта в PBS создается описание продукта (PD — Product Description), одной из ключевых компонент которого является набор критериев качества для подтверждения соответствия продукта требованиям (fit for purpose) и измерений качества, которые будут производиться лицами, ответственными за приемку завершенного продукта. PD помогает определить временные затраты, ресурсы и риски, связанные с производством продукта, а также служит основой (baseline) для управления изменениями продукта. В описании продукта указывается его название и уникальный идентификатор (требующиеся для управления конфигурацией), цель (четкое описание, для чего будет использован продукт), структура продукта (составные части и композиция), происхождение (источник для создания продукта), формат (стандарт и стиль, которому продукт должен соответствовать), критерии и методы оценки качества продукта, а также необходимые квалификации ресурсов, которые будут эту оценку производить.

В заключение, на основе PBS строится диаграмма создания продуктов (PFD — Product Flow Diagram), которая показывает последовательность создания (в соответствии с планом) и зависимости между продуктами. Диаграмма рисуется «справа налево»: Продукт проекта располагается крайним справа. PFD используется менеджером проекта для определения пакетов работ и формирования сетевого календарного плана (или диаграммы Гантта), однако эта деятельность уже выходит за рамки методологии (хотя в PRINCE2® и дается ссылка на нее).

Продвижение PMBOK® и/или PRINCE2® высшему руководству [6,7]

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

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

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

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

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

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

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

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

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

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

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

Сертификация/Аккредитация

В случае PMI экзамены по всему миру проводятся в центрах партнерской компании Prometric. Сертификация начального уровня, CAPM® (Сертифицированный ассистент РП), предполагает сдачу экзамена из 150 вопросов за 3 часа с повторный экзаменом через 5 лет. Профессиональная сертификация, PMP® (Профессионал по управлению проектами), требует успешной сдачи экзамена из 200 вопросов в течение 4 часов с пролонгацией посредством периодического накопления и подтверждения в PMI 60 PDUs (Professional Development Units) за каждые 3 года после сдачи экзамена.

Экзамены по PRINCE2® составляются британской APMG (Аккредитация Проектных Менеджеров Глобальная), всемирной аккредитационной организацией, разрабатывающей и предоставляющей сертификационные программы для профессионалов, уполномоченной OGC.

Сертификация начального уровня, PRINCE2® Foundation, предполагает сдачу экзамена из 75 вопросов за 60 минут с проходным баллом 50% с только одним правильным ответом из нескольких возможных в каждом вопросе. Профессиональная сертификация, PRINCE2® Practitioner, требует успешной сдачи экзамена из 108 вопросов за 2,5 часа с проходным баллом 55% и вопросами по выданному сценарию проекта, для которых возможны несколько правильных ответов. Пролонгация сертификации – через повторный экзамен через 5 лет.

Совместное использование американского и британского подходов

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

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

В случае совместного применения WBS по PMBOK® и PBS согласно PRINCE2® можно получить компоненты продукта проекта, описанные наиболее ясным и исчерпывающим образом.

Преимущества руководителей проектов с двойной сертификацией

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

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

Заключение

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

PMBOK® 5th Edition и PRINCE2® (2009) взаимно дополняют друг друга и могут использоваться совместно даже с большим успехом по сравнению с их независимым друг от друга применением.

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

Список литературы

1. A Guide To The Project Management Body Of Knowledge (PMBOK® Guide) – Fifth Edition, 2013, Project Management Institute, PA, USA.

2. PRINCE2®:2009 Manual — Managing Successful Projects With PRINCE2® — 2009 Edition, 2012, London, The Stationery Office (TSO).

3. Directing Successful Projects With PRINCE2® — 2009 Edition, 2012, London, The Stationery Office.

4. Implementing a VISA Project in a PRINCE2® Project Management Environment by Paul Bradley.

5. The Marriage Proposal of PRINCE2® and PMBOK® by Dr. Anthony Yeong, Jan. 2012 Edition.

6. Positioning PRINCE2® in an Unforgiving Business World by Dayo Sowunmi published as part of.

7.PRINCE2® Business Benefits by Dr. Ian Clarkson, TSO White Paper, January 2010, published on.

Оригинал статьи