Проектный офис: функции, задачи и когда его создавать

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

Иногда действительно нужен. Гораздо чаще нужна функция, а не отдел, и начинать стоит не с найма, а с трёх правил, которые ничего не стоят.

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

Что такое проектный офис простыми словами

Проектный офис (в англоязычной практике PMO, project management office) — это подразделение или роль, которое отвечает не за отдельный проект, а за то, как в компании устроено управление проектами вообще.

Разница с руководителем проекта принципиальная. Руководитель проекта отвечает за один проект: сроки, объём, результат. Проектный офис — за то, чтобы все проекты компании велись по единым правилам, были видны в одном месте и не мешали друг другу.

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

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

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

Функции проектного офиса: что он делает

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

Единый учёт проектов. Список всех проектов компании в одном месте: что идёт, на какой стадии, кто ведёт, когда ожидается результат. Звучит скромно, но именно этого чаще всего и не хватает — во многих компаниях полного списка проектов не существует нигде.

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

Отчётность и статус. Регулярная сводка по всем проектам для руководства: где идём по плану, где отстаём, где нужны решения.

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

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

Контроль качества управления. Проверка, что по проектам реально ведётся то, о чём договорились: план обновляется, риски пересматриваются, решения фиксируются.

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

Набор функций зависит от того, сколько у компании проектов и кто их ведёт:

Сколько проектов одновременно	Что действительно нужно	Кто это делает
1–2	ничего сверх управления самим проектом	руководитель проекта
3–5	единый список, регулярный статус, приоритизация при конфликте ресурсов	один человек, для которого это часть работы
6–10	плюс правила старта, шаблоны, портфельная встреча раз в две недели	выделенная роль, до половины ставки
больше 10	плюс методология, обучение, контроль качества управления	отдельная должность или небольшая группа

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

Кто за что отвечает: офис, руководитель проекта, заказчик

Путаница в этих трёх ролях — причина большинства конфликтов вокруг проектных офисов. Разложим по предмету ответственности.

Роль	За что отвечает	Чего с неё спрашивать нельзя
Заказчик проекта	зачем проект нужен, каким должен быть результат, приёмка	ход работ и сроки: он не управляет исполнением
Руководитель проекта	сроки, объём, качество конкретного проекта	приоритет своего проекта относительно чужих — это не его уровень
Проектный офис	картина по всем проектам, правила, портфель	результат отдельного проекта: он не ведёт проекты вместо руководителей

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

Обратная ошибка — превращать проектный офис в резерв руководителей проектов. Как только его сотрудники начинают вести проекты, времени на надпроектную работу не остаётся, и функция исчезает: снова никто не видит картину целиком.

Важно: роли можно совмещать в одном человеке, пока компания небольшая, — но нельзя смешивать спрос. Даже если руководитель проекта и «офис» — один человек, вопросы к нему звучат в двух разных режимах: как идёт этот проект и что вообще происходит со всеми.

Три роли: советник, контролёр, управляющий

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

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

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

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

Выбирать нужно осознанно, а не по умолчанию. Самая частая беда — офис, которому вменили ответственность контролёра, но не дали права даже требовать статус: он рассылает напоминания, его игнорируют, и через полгода функция тихо умирает.

Частая ошибка: назначить проектный офис ответственным за сроки проектов, не дав ему полномочий. Отвечать за то, чем не управляешь, нельзя — получится должность для приёма претензий.

Когда проектный офис не нужен

Раздел, которого нет в статьях компаний, продающих софт для управления проектами. Между тем ответ «пока не нужен» — правильный для большинства компаний среднего размера.

Не нужен, если:

• Проектов один-два. Ими управляет руководитель проекта, надстройка не требуется.
• Проекты редкие. Два-три в год — функцию несёт тот, кто их ведёт, вместе с собственником.
• Проблема не в координации, а в исполнении. Если проекты стоят, потому что люди заняты текучкой, офис ничего не изменит: он не добавит рабочих часов.
• Нет ни одного описанного проекта. Начинать надо с того, чтобы хотя бы один проект прошёл цикл целиком, а не с органа, который будет управлять несуществующей системой.
• Единственная цель — «чтобы кто-то следил». Слежение без полномочий превращается в сбор отчётов, который отнимает время у тех, кто делает работу.

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

Признаки, что проектный офис уже нужен

Обратная сторона: моменты, когда откладывать уже дорого.

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

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

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

Ещё один сигнал — повторяющийся разговор «а что там с проектом Х», который начинается не по плану, а когда о проекте случайно вспомнили. Регулярность вопроса заменяет управление ровно до тех пор, пока проектов немного; дальше о части из них просто перестают вспоминать.

Что считать проектом, а что текущей работой

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

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

Пограничные случаи, которые чаще всего спорны:

• Крупный заказ клиента. Для компаний, работающих под заказ, каждый контракт — проект, и портфель состоит из них. Для остальных это текущая работа, даже если заказ большой.
• Внедрение системы. Проект. Но поддержка после запуска — уже процесс, и она должна перейти к владельцу, иначе проект не закроется никогда.
• Разработка регламентов. Проект, если есть срок и объём. Если «пишем по мере возможности» — это не проект и не процесс, а благое намерение.
• Улучшения в существующем процессе. Обычно не проект, пока не требует нескольких подразделений и отдельных ресурсов.

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

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

Что говорят российские стандарты

Полезно знать, что тема управления совокупностью проектов нормирована, и при желании на это можно опереться.

Управление отдельным проектом описывает ГОСТ Р 54869-2011: инициация, планирование, организация исполнения, контроль исполнения, завершение. Про устройство одного проекта во времени — отдельная статья про жизненный цикл проекта.

Управление совокупностью проектов — предмет соседнего стандарта, ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (утверждён приказом Росстандарта от 22.12.2011 № 1583-ст, введён в действие с 1 сентября 2012 года). Сам факт существования отдельного стандарта — хороший аргумент в разговоре о том, что портфель проектов требует управления, а не только каждый проект по отдельности.

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

Один человек: как выглядит минимальная версия

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

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

Что он делает еженедельно:

1. Обновляет список проектов — стадия, ответственный, ближайшая контрольная точка.
2. Собирает статус — коротко, по каждому проекту, желательно письменно.
3. Готовит сводку для собственника — одна страница: что идёт по плану, что отстаёт, какие решения нужны.
4. Ведёт список решений и изменений по проектам, чтобы через месяц было понятно, почему сдвинулись сроки.

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

Совет: не давайте этой роли название «проектный офис» на старте. Название предполагает структуру и вызывает у команды ожидание бюрократии. Достаточно сказать, что такой-то ведёт общий список проектов и собирает статус.

Почему проектные офисы не приживаются

Причин обычно три, и все они управленческие, а не методологические.

Офис стал сборщиком отчётности. Самая распространённая история. Функция сводится к тому, что раз в неделю всех просят заполнить форму. Руководители проектов тратят время, взамен не получают ничего, и заполняют формально. Через полгода отчёты есть, картины нет.

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

У офиса нет выхода на решения. Отклонения фиксируются, а решать некому: собственник занят, комитета нет, полномочий у офиса нет. Функция превращается в архив плохих новостей.

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

Кому подчиняется проектный офис

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

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

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

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

В практике Business Commandos на проектах по постановке управления проектами именно вопрос подчинения оказывается развилкой: пока функция висит сбоку и ни к кому не привязана, её решения носят рекомендательный характер, а проекты продолжают идти как шли.

Что офис делает с завершёнными проектами

Функция, которую пропускают почти все, а она даёт наибольшую отдачу со временем.

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

Минимум, который стоит фиксировать по завершении:

• План против факта по срокам и трудозатратам — в одну строку, без анализа.
• Что оказалось не учтено на старте — обычно один-два пункта, и они повторяются от проекта к проекту.
• Что сработало и стоит повторить — тоже коротко.

Через пять-шесть проектов накапливается то, ради чего всё делалось: реалистичные коэффициенты. Компания начинает понимать, что внедрение подобного масштаба занимает не два месяца, как хочется, а четыре, и планирует уже по факту, а не по надежде.

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

Портфель: как проекты приоритизируются между собой

Ключевая работа, ради которой всё и затевается: решать, какие проекты идут сейчас, а какие ждут.

Порядок, который работает в средних компаниях.

Один список. Все проекты в одном месте, включая те, что «делаются потихоньку». Обычно на этом шаге и обнаруживается, что активных проектов не пять, а двенадцать.

Оценка по двум признакам. Что даёт компании и чего стоит — деньгами и временем ключевых людей. Точность здесь не нужна, нужна сопоставимость.

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

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

Пересмотр раз в квартал. Чаще — суета, реже — оторванность от реальности.

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

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

Как выбирается главное на уровне отдельных задач — в статье про приоритизацию задач; здесь та же логика, только на уровень выше.

Как запустить функцию за месяц

Без структуры, найма и покупки систем.

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

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

Неделя 3. Правила. Договориться о минимуме: как выглядит статус, когда он подаётся, кто принимает решение о старте нового проекта. Полстраницы текста.

Неделя 4. Ритм. Назначить регулярную встречу по портфелю — раз в две недели, тридцать минут, по сводке. На ней принимаются решения, а не пересказываются статусы.

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

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

Как измерить работу самой функции

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

Доля проектов, завершённых в срок или с согласованным переносом. Второе не менее важно, чем первое: перенос, о котором решили заранее, — это управление, а срыв по факту — его отсутствие.

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

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

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

Что мерить не стоит: количество проведённых встреч, заполненных форм и подготовленных шаблонов. Это затраты, а не результат, и стоит начать их считать — функция быстро оптимизируется в сторону производства бумаги.

Проектный офис и подрядчики

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

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

Минимум с вашей стороны: один человек, который принимает результат по этапам, ведёт журнал решений и следит, чтобы изменения объёма проходили через явное согласование. Это не недоверие к подрядчику, а нормальная организация работы: у него в проекте свои границы, у вас свои.

Частые ошибки

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

Как понять, что функция работает

Четыре проверки, все считаются по фактам.

1. Число активных проектов известно и не растёт бесконтрольно.
2. Есть завершённые. Соотношение закрытых и запущенных за квартал — самый честный показатель.
3. Собственник узнаёт о проблеме не последним. Отклонения приходят к нему из сводки, а не от расстроенного клиента.
4. Конфликты за ресурсы разрешаются решением, а не громкостью. Есть место и момент, где это происходит.

Если через квартал ни один показатель не сдвинулся, дело не в форме офиса: скорее всего, у функции нет полномочий или проекты стоят по причинам, к координации не относящимся.

С чего начать

Три шага на ближайший месяц.

1. Составьте полный список проектов компании — включая те, что делаются негласно.
2. Пройдите его с собственником и остановите то, что не идёт и не нужно.
3. Назначьте человека, который раз в две недели собирает статус и готовит сводку на одну страницу.

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

Выводы

Проектный офис — это функция, а не обязательно отдел. Она отвечает не за отдельный проект, а за то, как в компании устроено управление проектами: единый список, единые правила, отчётность и приоритизация портфеля.

Большинству компаний среднего размера отдел не нужен — нужен один человек с двумя-четырьмя часами в неделю, доступом к первому лицу и правом спрашивать статус. Создавать структуру раньше, чем координация стала отдельной работой, вредно: получается отчётность без управления.

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