Зачем бизнесу проектный офис (PMO) на самом деле?

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

Тут возникает вопрос о способности формулировать управленческие запросы на уровне руководства. Но ещё более важный вопрос — к тому, кто запускает проектный офис: хочет ли он быть Head of PMO или им казаться?

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

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

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

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

Как звучат вопросы формалистов:

• Нужно внедрить единую методологию управления проектами.
  Формальный этот запрос по причине, что фокусируется он вокруг регламентов и стандартов, а не на том, что должно улучшиться.

• Нам нужна единые реестры (проектов, продуктов, НМА и т.п.).
  Запрашиваются артефакты, но не объясняется, какие риски, задержки или неопределённости они должны убрать.

• Нам нужно создать проектный офис.
  Запрос на форму решения, но не определена сама проблема, которую PMO решает.

• Мой любимый запрос: на еженедельный статус-отчёт по проектам для руководства.
  Есть требование к формату отчётности, но нет сформулированного управленческого решения и проблемы.

• Надо внедрить систему управления портфелем проектов.
  Тут обычно дополняется названием ИТ-системы, но не говорят по каким принципам она будет работать. И по классике автоматизируется существующих хаос из незрелых процессов.

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

Сам по себе формальный запрос не обязательно плох. Он просто неполный. За ним почти всегда скрывается реальная проблема, которую вам нужно будет решать. А вот получится её решить, прикрываясь формальным запросом, или нет — вопрос другой.

Как звучат запросы здорового человека:

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

• Поздно узнаем об отклонениях по срокам или бюджету, обычно времени на корректировки уже не остается.
  Тут появляются отчеты по статусам, риски и правила эскалации.

• Одни и те же сотрудники обещаны в разные проекты, из-за чего не все получают ресурсы вовремя.
  При таких ситуациях возникают ресурсные карты и управление ресурсами.

• Вопросы неделями проходят согласования. Время теряется не на исполнителях, а на ожидании решений.
  Матрицы RACI, SLA и регламенты по процессам.

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

Для перевода формального запроса в управленческий задаются три уточняющих вопроса:

1. Какие решения сейчас вызывают больше всего проблем?
   Если формат не позволяет использовать слово «проблема», можно обойтись «отнимает больше всего времени или ресурсов».

2. Какие потери это создает? Тут должно прозвучать что-то про потери денег или имиджа, один словом ресурсы.

3. Как вы поймете, что ситуация изменилась в сторону улучшений? Тут должно прозвучать что-то про метрики, что можно мониторить на дистанции.

Таким образом формальный запрос:

Нам нужен еженедельный отчет по проектам

Превращается в управленческий:

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

Итого

Проектный офис нужен не потому, что в компании много проектов. Он нужен в момент, когда руководители перестают понимать:

• во что компания уже вложила ресурсы;

• какие инициативы действительно поддерживают стратегию;

• что надо остановить, перенести или не запускать;

• где находятся реальные блокеры и межфункциональные зависимости;

• кто имеет право принять решение при конфликте приоритетов;

• какие проекты создают ценность, а какие только потребляют ресурсы.

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