Найти в Дзене
PMEvangelist

Почему проектные роли в бизнесе важнее, чем роли в PMO

Во многих организациях PMO становится ловушкой: туда складывают всё, что связано с проектами — задачи, отчётность, шаблоны, контроль, иногда даже исполнение. Формально это выглядит логично: «пусть за проекты отвечает тот, кто в этом разбирается». Но на деле такая логика приводит к тому, что бизнес отстраняется. Проекты превращаются в «не нашу» повестку. Когда проекты живут только в PMO: — Бизнес воспринимает их как чужую инициативу. Даже если проект затрагивает работу конкретного департамента, он не чувствует, что это его задача. Люди ждут, когда им принесут готовое решение.
— PMO оказывается между двумя огнями: оно должно обеспечить результат, но рычагов влияния нет. Все ключевые решения — на стороне бизнеса, который не вовлечён.
— Проекты буксуют. Не потому что PMO плохо работает, а потому что в процесс не встроены те, кто реально должен менять поведение, процессы, подходы. Пример: проект по внедрению системы управления знаниями. Вёл его PMO. Документы, план-график, поставщик, интег
Оглавление

Что происходит, когда все проекты «живут» только в PMO

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

Когда проекты живут только в PMO:

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

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

Реальность такова: PMO не управляет бизнесом. Оно может организовать, поддержать, обеспечить методологию. Но если бизнес не считает проект своим — он не взлетит. В лучшем случае — его дотащат на «автопилоте». В худшем — закопают в тишине.

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

Чем отличаются формальные роли от реального влияния

В проектном управлении часто всё красиво на бумаге: расписаны роли, ответственности, полномочия. Есть спонсор, заказчик, руководитель проекта, куратор, владелец продукта. Только вот в жизни это может никак не работать. Потому что реальное влияние — не в таблице RACI, а в том, кто принимает решения, распределяет ресурсы и готов действовать.

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

И наоборот: бывают проекты, где у PMO почти нет формальной власти. Но в команде есть сильный бизнес-заказчик или продуктовый лидер, который понимает, зачем это нужно, кому, и что должно измениться. Такой проект движется быстрее, гибче и устойчивее. Потому что решения принимаются на месте. Потому что есть человек, у которого есть не только должность, но и вовлечённость.

Парадокс: чем жёстче расписаны формальные роли, тем чаще организация скрывает за этим отсутствие реального вовлечения. Люди прячутся за регламентами: «Я не отвечаю за внедрение, я по срокам», «Мы же передали, а дальше — зона бизнеса». В итоге каждый делает «свою часть», но никто не двигает вперёд.

Вывод простой: проект держится не на ролях, а на людях, которые готовы брать на себя решения и ответственность. Формальные конструкции могут помочь, но не заменят живого участия. И пока у проекта нет настоящего «хозяина» на стороне бизнеса — он остаётся внешним, хрупким и зависимым от обстоятельств.

Проект — это не только структура. Это — воля. И если в ней участвует только PMO, а не бизнес, — значит, структуры много, а движения мало.

Почему бизнесовые роли — это ключевые «узлы» изменений

Ни один проект не даёт эффекта, пока не начинает что-то менять в повседневной работе. А повседневность — это не PMO. Это операционные подразделения, продуктовые команды, frontline-менеджеры. Именно они живут в реалии, которую проект должен изменить. А значит, только они могут:

— понять, в чём именно проблема,
— оценить последствия изменений,
— внедрить новое в практику,
— адаптировать под контекст,
— и главное —
обеспечить устойчивость после проекта.

Проект, в котором нет бизнесовой роли, — это техническое упражнение. Сделать по ТЗ, отчитаться, сдать. Но ценность появляется только тогда, когда бизнес говорит: “это нам нужно, мы в этом участвуем, мы это внедрим и доведём до результата”.

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

Пример: проект по переходу на новую систему расчёта мотивации в продажах. Формально инициатор — HR, оператор — PMO. Но только тогда, когда коммерческий директор лично подключился, провёл сессии с руководителями направлений, утвердил модель и поучаствовал в пилоте — началось реальное внедрение. Потому что только он мог «прошить» это изменение в культуру, процессы, KPI.

И наоборот: в другой компании PMO вело проект по оптимизации логистики. Департамент логистики держался в стороне: «мы посмотрим, что вы там наработаете». Всё было красиво: карта процессов, система маршрутизации, новая модель. Только работать она не начала. Потому что решения — не приняты, персонал — не обучен, ответственность — не осознана.

Настоящие «узлы» изменений — в бизнесе. Там, где живут процессы, поведение, деньги, люди. И без включения этих точек никакой проект не станет результатом. PMO может быть катализатором, но только бизнес может быть носителем изменений.

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

Какие проектные роли реально нужны в бизнесе

Чтобы проект заработал не на бумаге, а в жизни, в бизнесе должны появиться конкретные роли — не «для отчёта», а для действия. Эти роли могут называться по-разному, но их суть в том, чтобы удерживать смысл, принимать решения, включать людей и обеспечивать внедрение. Вот ключевые из них:

1. Владелец эффекта (или результата)
Это человек, который отвечает не за реализацию проекта, а за то, чтобы
после проекта что-то реально изменилось. Например, повысился уровень обслуживания, снизились затраты, ускорилось согласование. Он не руководит проектом в классическом смысле, но он «держатель ценности» — и в этом его сила. Именно он потом будет жить с результатом.

2. Бизнес-заказчик, который действительно вовлечён
Не тот, кто «подписал устав и исчез», а тот, кто регулярно в курсе, вовлечён в развилки, готов защищать проект, когда возникают споры и конфликты. Он не обязан знать всю детализацию, но должен быть моральным и политическим покровителем. Он задаёт рамку и держит курс.

3. Внутренний агент изменений (change agent)
Это не внешний консультант и не project manager. Это человек в подразделении, который умеет переводить изменения на язык повседневной работы: убедить коллег, отстоять адаптацию, собрать обратную связь, донести до руководства, что реально работает. Без него все инструкции останутся на бумаге.

4. Тихий лидер — тот, кто «тащит»
В каждой команде есть такие люди: неформальные авторитеты, которые могут увлечь, упростить, собрать. Они редко значатся в уставах, но без них проект не двигается. Именно они превращают решение в действие.

Мини-кейсы:

— В компании по дистрибуции владелец эффекта по проекту цифровизации стал директор по логистике. Он сам просил замеры, смотрел дашборды, настраивал работу команды. В результате — автоматизация не просто внедрилась, а сократила срок отгрузки на 27%.
— В банке по проекту клиентской поддержки оказался старший оператор. Он провёл более 20 мини-обучений для коллег, собрал вопросы, перезапустил скрипты. Без него внедрение бы забуксовало.
— В телеком-компании бизнес-заказчик по проекту обучения не просто согласовал контент, а лично вел демо-сессии, давал обратную связь и продвигал успехи команды наверх. Это укрепило доверие и ускорило масштабирование.

Все эти роли — не про статус. Они про влияние и включённость. И именно они делают проекты реальностью. Не PMO, не отчёты, не диаграммы. А люди, которые живут внутри бизнеса — и понимают, зачем всё это.

Что делать PMO, чтобы стать партнёром, а не владельцем

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

Вот что для этого реально работает:

1. Перестать быть «единственным источником проектной истины»
Нужно признать: проекты живут в бизнесе. PMO — не центр принятия решений. Его функция —
сервисная: помочь структуре понять, как сформулировать инициативу, приоритизировать, организовать, реализовать и не забыть про эффект. В таком подходе PMO становится не «шефом проектов», а советом и поддержкой.

2. Предлагать мышление, а не процедуру
Вместо того чтобы навязывать регламенты, PMO может задавать рамку:
Зачем этот проект? Какой эффект? Кто должен быть вовлечён? Если команда не знает, как начать — помочь стартовать. Если запуталась — предложить формат. Если буксует — фасилитировать обсуждение. Это не контроль — это навигация.

3. Упростить, а не усложнить
Чем проще PMO делает жизнь команд — тем охотнее бизнес с ним работает. Пример: вместо многостраничного шаблона устава — холст на одну страницу. Вместо дашборда с 20 метриками — 3 фокуса. Вместо «заполните всё» — «давайте проговорим вместе». Это показывает: PMO — не про бюрократию, а про пользу.

4. Настраивать ритм, а не заменять движение
PMO может быть тем, кто задаёт темп: регулярные синки, квартальные обзоры, точки переоценки приоритетов. Но не в формате «мы собираем всех», а как
модератор: помогает не терять нить, видеть взаимосвязи, вовремя разворачивать проект. Это особенно важно при управлении портфелем.

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

Пример: в одной продуктовой компании PMO полностью ушло от роли «центра ведения». Вместо этого оно стало работать как «внутренний акселератор»: команда, которая помогает сформулировать гипотезу, найти владельца, структурировать действия, измерить результат. У них нет отчётности в классическом смысле — но доверие к PMO выше, чем когда-либо. Потому что бизнес чувствует: они на нашей стороне.

Такое PMO становится не бюрократическим узлом, а органом чувств и координации. Тонким, гибким, встраивающимся в среду. И именно так строится зрелая, живая проектная система — где проекты рождаются в бизнесе, а PMO помогает им состояться.

Как понять, что бизнес включился

Главный маркер зрелой проектной среды — это не количество проектов в Jira и не заполняемость шаблонов. Это уровень вовлечения бизнеса. Не по названию в уставе, а по действиям. И есть вполне конкретные признаки, по которым можно увидеть: проект больше не «в PMO», а в бизнесе.

Вот эти признаки:

1. Инициатива идёт оттуда, а не к ним
Если сотрудники бизнес-подразделений сами приходят с идеями: «Мы хотим сделать проект», «Нам нужно улучшить вот этот процесс», «Есть предложение — можно попробовать», — это значит, что проектное мышление начало укореняться. Люди чувствуют: можно и нужно что-то менять.

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

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

4. Бизнес защищает проект перед другими функциями
В кросс-функциональной среде всегда есть конфликты интересов. И если руководитель подразделения лично вступается за инициативу, помогает с приоритетами, договаривается с соседями — это значит, что проект стал «своим».

5. PMO задаёт ритм, но не тянет за собой
Если раньше PMO звонило каждую неделю: «вы не забыли про план?», а теперь бизнес сам инициирует синки, просит помощи в фасилитации, делится рисками — это знак:
ответственность сместилась туда, где и должна быть.

6. Проект продолжается после «завершения»
Самый точный индикатор. Если после официального закрытия команда продолжает донастраивать, улучшать, масштабировать, делиться — значит, это был не проект «ради отчёта». Это стало частью изменений.

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