Один удачно завершённый проект ничего не говорит о зрелости компании в управлении проектами — это могло быть удачей, героизмом одного человека или счастливым стечением обстоятельств. OPM3 (Organizational Project Management Maturity Model) оценивает не отдельный проект, а системную способность организации повторяемо и предсказуемо доводить проекты до результата.
Реальный, официально задокументированный пример системного повышения зрелости управления проектами — австралийское федеральное агентство Centrelink (создано в 1997 году для доставки социальных выплат населению). После критического аудита Australian National Audit Office (ANAO), выявившего проблемы в управлении стратегическими проектами, агентство в мае 2005 года создало специальный Совет по координации проектов (Project Coordination Board), а в июле 2006 года утвердило план из шести конкретных пунктов повышения зрелости, официально согласованный с рекомендациями ANAO. Цель, которую агентство поставило перед собой явно и публично, — достичь рейтинга зрелости управления проектами уровня 4 и добиться признания управления проектами полноценной профессиональной карьерной траекторией для сотрудников, а не побочной обязанностью. Основой для стандартизации процессов Centrelink выбрало международно признанные стандарты — PMBOK и PRINCE2 — с последующим неоднократным пересмотром практики. Этот кейс, наряду с Washington Savannah River Company (США), фигурирует в собственном исследовании PMI «Analysis of Organizational Project Management Maturity Model Cases» как реальный пример применения именно логики OPM3: последовательное движение от разрозненной практики к измеримой, повторяемой системе управления проектами.
Модель разработана Институтом управления проектами (PMI) — той же организацией, что стоит за глобальным стандартом PMBOK — и остаётся одним из наиболее признанных в мире инструментов диагностики организационной зрелости проектного управления.
Один успешный проект — это может быть везение. Десять успешных проектов подряд — это уже система.
Происхождение и исследовательская база
OPM3 разработан и опубликован Институтом управления проектами (Project Management Institute, PMI) как стандарт для оценки и улучшения организационной зрелости управления проектами, портфелями и программами. Впервые опубликован в 2003 году, регулярно обновляется вместе с другими стандартами PMI. PMI официально учредил проект разработки OPM3 в 1998 году, а собственно исследовательскую фазу в январе 1999-го возглавил Джон Шлихтер (John Schlichter), пригласивший добровольцев из разных стран. За без малого шесть лет работы над стандартом было задействовано более 800 практикующих специалистов по управлению проектами из 35 стран мира — беспрецедентный по охвату для отрасли объём коллективной экспертизы. Прежде чем приступить к созданию собственной модели, команда PMI изучила 27 уже существующих на тот момент моделей зрелости управления проектами по пяти критериям (область охвата, полнота покрытия PMBOK, методология самооценки, структура — ступенчатая или непрерывная, наличие плана внедрения) и пришла к выводу, что ни одна из них не удовлетворяет требованиям, не охватывает все выявленные лучшие практики и не учитывает организационные ограничения, из-за которых практики можно внедрять только постепенно — именно это решение и стало отправной точкой для разработки полностью оригинальной модели.
Ключевые идеи и принципы
Принцип: четыре последовательные стадии процесса.
Стандартизация (Standardize — процессы управления проектами задокументированы и последовательны), измерение (Measure — собираются данные об эффективности процессов), контроль (Control — на основе данных процессы контролируются и корректируются), непрерывное улучшение (Continuously Improve — процессы систематически совершенствуются на основе накопленных данных). Принципиально важная деталь, которую часто упускают при поверхностном пересказе модели: разработчики OPM3 сознательно отказались от единой сквозной шкалы «уровней зрелости» в духе Capability Maturity Model, где организация получает один общий балл от 1 до 5. Вместо этого зрелость в OPM3 оценивается одновременно по четырём независимым измерениям: прогрессия по трём доменам (проект → программа → портфель), прогрессия по четырём стадиям SMCI внутри каждого домена, последовательность накопления конкретных Capabilities внутри каждой лучшей практики, и, наконец, привязка каждой Capability к одной из пяти групп процессов PMBOK (Initiating, Planning, Executing, Controlling, Closing — аббревиатура IPECC). Такая многомерность делает диагностику заметно более гранулярной, чем один общий балл: организация вполне может иметь высокую зрелость в стандартизации на уровне отдельных проектов и почти нулевую — в контроле на уровне портфеля, и OPM3 покажет эту неравномерность явно, а не усреднит её в один непрозрачный показатель.
Принцип: три домена управления.
Модель применяется одновременно к трём уровням: управление отдельными проектами, управление программами (группами связанных проектов), управление портфелем (совокупностью проектов и программ в соответствии со стратегией компании) — зрелость на одном уровне не гарантирует зрелость на других. Насколько детально устроена сама модель, хорошо видно на конкретном примере из официального стандарта. Лучшая практика с идентификатором 5240 «Establish Internal Project Management Communities» («Формирование внутренних сообществ практиков управления проектами») раскладывается на четыре последовательные Capabilities возрастающей зрелости: «содействовать формированию сообщества» (Facilitate Project Management Activities), «развивать осведомлённость о деятельности сообщества» (Develop Awareness), «обеспечивать спонсорскую поддержку сообщества» (Sponsor) и, на высшей ступени, «координировать сообщество как часть общей программы поддержки управления проектами» (Coordinate Project Management Activities). Существование каждой отдельной Capability подтверждается не экспертным мнением, а наблюдаемым Outcome — так, для Capability «Develop Awareness» стандарт требует зафиксировать конкретный Outcome «организация использует локальные инициативы сообщества» с измеримым индикатором (KPI) «сообщество реально решает локальные вопросы» — то есть оценка спускается с абстрактного домена до проверяемого факта на уровне конкретного рабочего сообщества внутри компании.
Принцип: зрелость — это про повторяемость, не про один успех.
Ключевой вопрос OPM3 — не «был ли этот проект успешным», а «сможет ли компания повторить этот успех системно, независимо от того, кто именно ведёт следующий проект». Операционно эта повторяемость достигается через пятишаговый цикл OPM3, который стандарт называет «OPM3 Cycle»: (1) подготовка к оценке — изучение содержания стандарта и трёх его справочников; (2) собственно оценка, которая сама делится на два этапа — сначала высокоуровневый опрос из 151 вопроса «да/нет» (например, «использует ли организация единый набор документированных процессов для управления проектами?»), дающий общую картину по трём доменам и четырём стадиям SMCI, а затем детальная («Comprehensive») оценка — подтверждение каждой конкретной Capability через наблюдаемые Outcomes; (3) планирование улучшений — приоритизация недостающих Capabilities по критериям достижимости, стратегической приоритетности, выгоды и стоимости; (4) внедрение улучшений как полноценных проектов организационных изменений; (5) повторение цикла — возврат к оценке для верификации достигнутого прогресса и выявления следующих зон роста. Именно повтор шагов 2–5 на регулярной основе и превращает разовый успех в подтверждённую, воспроизводимую зрелость, а не разовую диагностику, положенную на полку.
Ограничения, слепые зоны и критика
Модель разработана для компаний, ведущих множество проектов одновременно — для стартапа с одной-двумя параллельными инициативами полноценное применение всех трёх доменов (проект/программа/портфель) избыточно. Формальная зрелость процессов не гарантирует, что сами проекты выбраны правильно — OPM3 оценивает, насколько хорошо компания выполняет проекты, а не насколько удачно она их выбирает (это ближе к стратегическому управлению портфелем). Сами разработчики стандарта проявляют примечательную методологическую честность: в предисловии к первому изданию 2003 года прямо признаётся, что «OPM3 находится в своей первой публичной итерации» и что «результаты этой работы предлагаются с определённой мерой смирения, наряду с гордостью» — необычно откровенная формулировка для отраслевого стандарта. Причина в самой природе процесса разработки: команда изначально стремилась построить строгую «причинно-следственную» (causal) инженерную модель, но собственное исследование PMI обнаружило, что ни одна существующая модель зрелости — и, как следствие, сама OPM3 в её итоговом виде — не может полностью игнорировать организационные ограничения, из-за которых лучшие практики достижимы только постепенно, а не одним теоретически «идеальным» скачком. Это ограничение стоит держать в уме при любом внедрении: OPM3 описывает, к чему стремиться и в каком порядке, но не отменяет того, что реальные организационные изменения происходят рывками, откатами и компромиссами, а не по чистой линейной логике модели.
Типовые ошибки
Ошибка 1: путают успех одного проекта с организационной зрелостью.
Один проект прошёл отлично благодаря сильному менеджеру проекта — компания считает себя зрелой в управлении проектами, хотя без этого конкретного человека результат может быть совсем другим.
Как избежать
проверять, задокументирован ли процесс так, чтобы его мог повторить кто-то другой, не полагаться только на факт одного успеха.
Ошибка 2: внедряют сложные процессы раньше, чем компания к ним готова.
Пытаются сразу перейти к продвинутым практикам управления портфелем, хотя базовая стандартизация проектных процессов ещё не закреплена.
Как избежать
последовательно проходить стадии — сначала стандартизация, затем измерение, контроль и только потом непрерывное улучшение.
Ошибка 3: измеряют процесс, но не используют данные для решений.
Собираются метрики по проектам, но они никак не влияют на реальные управленческие решения — измерение существует формально.
Как избежать
явно связывать собранные данные с конкретными решениями о корректировке процесса.
Ошибка 4: оценивают зрелость только на уровне отдельных проектов, игнорируя программы и портфель.
Диагностика зрелости проводится только для отдельных проектов, хотя OPM3 явно требует оценки на трёх уровнях одновременно (проекты, программы, портфель) — сильная зрелость на проектном уровне не гарантирует, что компания правильно выбирает и приоритизирует сами проекты на уровне портфеля.
Как избежать
явно проводить оценку зрелости отдельно на всех трёх доменах модели, а не только на самом заметном — уровне отдельных проектов.
Ошибка 5: копируют целевой уровень зрелости другой компании без учёта собственного контекста.
Компания механически ставит целью «достичь уровня 4, как у известной организации из кейса», не оценив, действительно ли такой уровень зрелости оправдан масштабом и сложностью собственного проектного портфеля — избыточная зрелость для простого портфеля тратит ресурсы без реальной пользы.
Как избежать
определять целевой уровень зрелости исходя из реального масштаба и сложности собственного портфеля проектов, а не по аналогии с чужим примером.
План внедрения
Неделя 1: диагностика стандартизации.
Оценить, задокументированы ли основные процессы ведения проектов, или каждый проект ведётся по-своему.
Неделя 2: базовые метрики.
Определить 2-3 простые метрики для отслеживания проектов (сроки, бюджет, объём).
Неделя 3: точки контроля.
Ввести регулярные точки сверки хода проекта с планом.
Неделя 4: закрепление цикла улучшения.
Зафиксировать, как выводы из завершённых проектов будут использоваться для улучшения процесса следующих. Далее: пересматривать раз в полгода.
Как реализовать этот план с помощью фрейма OPM3 в OrgDevTools
Фрейм «OPM3» построен как горизонтальный ряд из четырёх последовательных карточек — ровно четыре стадии процесса зрелости методики: «Стандартизация» (процессы задокументированы), «Измерение» (собираются данные об эффективности), «Контроль» (процессы контролируются по этим данным), «Непрерывное улучшение» (систематическое совершенствование на основе накопленных данных).
Каждая карточка — свободный список конкретных практик, реально внедрённых на соответствующей стадии. Ключевая логика вердикта — строгая последовательность: фрейм явно проверяет, не пропущена ли более ранняя стадия при наличии записей в более поздней (например, заполнен «Контроль», но пуста «Стандартизация») — именно это прямо иллюстрирует Ошибку 2 из блока Типовых ошибок (внедрение продвинутых практик раньше готовности). Вердикт называет текущую реально достигнутую стадию и следующий шаг, а при достижении «Непрерывного улучшения» — высшего уровня — даёт финальный положительный вердикт.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме
PMI — «Organizational Project Management Maturity Model (OPM3)» (официальный стандарт, регулярно обновляемый институтом). PMI — «A Guide to the Project Management Body of Knowledge (PMBOK Guide)» — смежный, более широко известный стандарт управления отдельными проектами, на который во многом опирается OPM3.