Как создать проектный офис с нуля: практическое руководство

Прежде чем начинать: диагностика и поиск спонсора

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

Диагностика перед запуском PMO должна дать ответы на три вопроса:

• Сколько проектов реально идёт в компании прямо сейчас? Часто выясняется, что руководство не видит и половины из них.
• В чём причины типичных срывов? Нехватка ресурсов, неясные приоритеты, отсутствие единой точки контроля — диагноз определяет, с какой функции начинать.
• Кто из топ-менеджеров реально заинтересован в результате? Не тот, кто формально «отвечает за цифровизацию», а тот, чьи собственные KPI зависят от предсказуемости проектов.

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

Комплиментарные активы: почему одного PMO недостаточно

Согласитесь, что иногда только совокупность элементов способна выполнить задачу и дать нужный результат. Например, вам нужно доехать из точки А в точку Б за определённое время. Даже для такой простой задачи потребуется несколько связанных элементов. Если у вас есть автомобиль, но нет топлива, машина будет бесполезной. Если в вашей машине полный бак, но впереди густой лес, то задача снова не решается. Если есть автомобиль с бензином и хорошая дорога, но вы не знаете правил дорожного движения — риск не доехать снова велик. Только при наличии всех элементов: автомобиль + бензин + дорога + знание ПДД — вы сможете достичь своей цели. Это пример комплиментарных активов — элементов, дополняющих друг друга и взаимно увеличивающих общую эффективность.

Та же ситуация ожидает нас при внедрении системы управления проектами:

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

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

Выбор типа и уровня проектного офиса

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

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

Также разграничьте уровень PMO в организационной структуре:

• Уровень организации (центральный ПО). Работает с портфелем всей компании — то, о чём говорит это руководство.
• Уровень подразделения (функциональный ПО). Ограничен одним департаментом или бизнес-единицей — часто оптимальная точка входа для пилота.
• Уровень программы/проекта. Временная структура вокруг одной крупной инициативы — минимальный формат, но с наименьшим стратегическим охватом.

Первые шаги проектного офиса

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

Наиболее популярные функции PMO:

• Разработка и развитие методологии управления проектами.
• Контроль выполнения процессов управления.
• Формирование сводной отчётности по портфелю проектов.
• Контроль достижения проектных целей.
• Обеспечение (организация) принятия решений.
• Обучение проектного персонала.
• Подготовка данных для мотивации проектных команд.
• Настройка и поддержка ИСУП.

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

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

1. Отражать ключевые результаты проектов;
2. Показывать наличие существующих отклонений;
3. Идентифицировать наличие рисков;
4. Сигнализировать о необходимости принятия управленческих решений.

Если присмотреться, то речь идёт о диаграмме контрольных точек. Такой отчёт легко воспринимается и рекомендуется для использования руководством (PMBOK), кроме того, начать его использовать можно как для отдельного проекта, так и для наиболее важной группы проектов.

Как организовать регулярную отчётность по проектам

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

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

Формализация: пример внутреннего приказа

Ключевыми условиями для такой отчётности являются несколько формально зафиксированных соглашений, а именно:

1. Все контрольные точки для отчётности должны быть утверждены;
2. Совещание для предоставления такого отчёта должно быть регулярным;
3. У проектного офиса должны быть права для требования таких данных;
4. У менеджеров проектов должна быть ответственность за предоставление таких данных.

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

«Для повышения контроля за выполнением проектов (далее следуют цели создания такой отчётности) ... приказываю:

1. Утвердить ответственность за получение следующих результатов по проекту/проектам: [таблица с проектами, контрольными точками и ответственными]

2. Еженедельно по вторникам в 10:00 организовывать совещание для предоставления статуса исполнения проектов в составе .... Ответственный за организацию — Иванов М.Ю. (руководитель проектного офиса). Типовой повесткой совещания утвердить ...

3. Определить полномочия Иванова М.Ю. (руководитель проектного офиса) запрашивать информацию для подготовки отчёта и эскалировать нарушения предоставления требуемых данных первому лицу.

4. Вменить в обязанность приёмщиков результатов регулярно (по понедельникам) предоставлять Иванову М.Ю. данные о статусе приёмки контрольных результатов п.1 по установленной форме.»

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

Программный продукт как основной инструмент управления

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

Отчёты — наиболее часто используемые функции программных продуктов. Как основа мониторинга и контроля, они делают систему действительно применимой и полезной для всех участников. С одной стороны, отчёт — рабочая область для руководителя проекта, с другой — возможность для топ-менеджмента оценивать управление в целом. Как координировать создание отчётов на основании данных ИСУП, понимать их назначение и предоставлять нужную информацию в выгодном свете — целая наука.

Инструментов анализа данных — великое множество. Они всегда востребованы, и их всегда не хватает. При внедрении любого программного продукта особым вопросом является настройка требуемых отчётов.

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

1. Гибкие и настраиваемые отчёты

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

2. Формы сбора данных по расписанию и контроль дисциплины

Система должна уметь сама собирать, сохранять и обрабатывать необходимую информацию. А ещё сообщать руководителю проекта или проектному офису о нарушениях или просрочках в этом процессе.

3. Интеграция с другими системами

ИСУП должна быть способна выгружать данные в другие системы. Как минимум — представлять отчёт в Excel-формате или на основе функций Excel. Объединение показателей для глубокого анализа и принятия обоснованных решений — неизбежный шаг к успешному управлению.

4. Дашборды для руководства

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

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

Как снизить сопротивление коллектива на старте

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

Практические меры снижения сопротивления на старте:

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

Как измерить, что проектный офис заработал

Регулярный анализ метрик позволяет объективно оценивать ценность PMO для бизнеса и обосновывать его дальнейшее развитие перед руководством.

Что развивать после того, как первый отчёт заработал

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

1. Расширение охвата. Добавляйте новые проекты и подразделения в контур регулярной отчётности только после того, как текущий контур работает устойчиво минимум 2–3 отчётных цикла.
2. Углубление отчётности. От диаграммы контрольных точек — к включению рисков, бюджета, загрузки ресурсов. Каждый новый слой отчётности вводится отдельно, с тем же циклом «прототип → показ руководству → формализация».
3. Формализация методологии. Когда отчётность работает регулярно, самое время описать процессы инициации, планирования и закрытия проектов — не наоборот. Методология, написанная раньше практики, обычно расходится с реальностью.
4. Развитие компетенций команды. Обучение руководителей проектов работе со стандартами и системой — по мере того, как контур контроля растёт, а не заранее «на всякий случай».
5. Переход к следующему типу PMO. От поддерживающей модели — к контролирующей, если охват и качество данных это оправдывают, и есть явный мандат от спонсора.

Вопросы и ответы

С какого числа проектов стоит начинать регулярную отчётность?

Начинать можно даже с одного стратегически значимого проекта — диаграмма контрольных точек по одному проекту уже показывает принцип работы и создаёт первый прецедент доверия. Оптимально для пилота — 3–7 проектов: достаточно, чтобы продемонстрировать ценность агрегированной картины, но не настолько много, чтобы усложнить организацию первого цикла отчётности.

Что делать, если топ-менеджер не хочет тратить время на определение контрольных точек?

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

Нужна ли специализированная ИСУП с первого дня, или можно начать в Excel?

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

Как понять, что пора менять тип PMO с поддерживающего на контролирующий?

Три признака готовности: (1) отчётность по контрольным точкам работает стабильно более двух кварталов без сбоев; (2) руководители проектов сами обращаются в PMO с вопросами и за шаблонами, а не только предоставляют требуемые данные; (3) спонсор явно выражает готовность делегировать PMO больше полномочий — например, право требовать соответствия стандартам, а не только предоставления отчётности.

Как обосновать перед руководством дальнейшие инвестиции в развитие PMO?

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

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

Три принципа, определяющие успех запуска PMO с нуля:

• Идите туда, где уже есть спрос. Найдите боль первого лица, а не навязывайте абстрактную ценность проектного управления.
• Комплиментарные активы работают только вместе. Методология, персонал и инструмент должны развиваться согласованно — отставание любого из них обесценивает усилия в остальных.
• Доверие — это ресурс, который нужно заработать, прежде чем расходовать. Начните с минимально достаточного контура отчётности и расширяйте его только после того, как текущий уровень работает устойчиво.

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