После внедрения трех проектных офисов, смысловая нагрузка одного из принципов управления от PMI - синергия, для меня, обрела еще более прикладной формат. Далее пойдет моя трактовка, с ориентиром на практики и стандарты от PMI: PMO: Практическое руководство и стандарты управления проектом\программой\портфелем.
Отталкиваясь от принципа, внедрение проектного офиса следует рассматривать одновременно как проект с ограниченными ресурсами и сроками, как создание управленческой функции и как разработку продукта для пользователей.Начинается этот набор подходов с проблем бизнеса, запускается через минимально жизнеспособный продукт и развивается по мере появления результатов и обратной связи.
Три направления внедрения проектного офиса
1.Проект - работа с ограничениями, ресурсами и сроками. Такой подход помогает показать результат в определенный период. Типичный срок этапа - около трех месяцев, хотя в зависимости от масштаба он может составлять один месяц или квартал.
2.Управленческая функция - проектный офис должен иметь возможность влиять на процессы: устанавливать фильтры, контрольные точки, ворота и условия принятия решений. Без такой возможности он рискует превратиться в центр отчетности, который собирает и подсвечивает данные, но не влияет на управление.
3.Продукт - деятельность нужно выстраивать вокруг пользователей и их потребностей. Наличие большого количества шаблонов, артефактов и сервисов само по себе не означает, что они полезны: они могут не решать актуальные проблемы. Продуктовый подход предполагает проверку востребованности: сервис запускают, оценивают отклик пользователей и затем решают, масштабировать его или отказаться от него. Если отклика нет, это признак того, что выбранная проблема и решение может быть неактуально.
Принципы: не идеальная модель, а работающая
Важный вопрос при создании проектного офиса - не только то, что считается правильным, но и то, какой набор действий будет достаточным и реально работающим. На что обратить внимание:
Попытка с самого начала внедрить все возможные стандарты и процессы требует значительных ресурсов. Обычно на ранних этапах необходимого объема нет в доступе.
PMI также рекомендует не стремиться сразу внедрить всё в идеальном виде. PMO: Practice Guide.
Практичнее опираться на принципы и правила, которые помогают проектному офису решать конкретные управленческие задачи.
-
Прозрачность и ее цель. Практический результат, а не как создание реестров ради самих реестров.Пример показательной метрики - сокращение количества "красных" проектов. Она позволяет оценивать, помогает ли проектный офис улучшать положение проектов, а не только собирать информацию о них.
Бывает ли, что полнота артефактов у проектов и есть сама цель? - да, если это прямо влияет на стоимость каждого проекта, иначе, про полноту артефактов лучше подумать еще раз.
MVP проектного офиса и состав базового набора
Для запуска PMI предлагает использовать MVP - минимально жизнеспособный продукт проектного офиса. Из моей практики, около трех месяцев обычно достаточно, чтобы выпустить базовый набор и затем перейти к более сложным процессам, этапам и артефактам.
Возможные элементы MVP:
Реестр проектов
Проектная логика и требования
Реестр рисков и требований
Дополнительные проектные и управленческие элементы, например RACI
Контур проверки гипотез и развитие продуктовой активности, которая выводит на каталог услуг
Мандат проектного офиса - документ, в котором закрепляются его положение, полномочия и границы ответственности; и т.п. MVP собирается под контекст.
Смысл MVP - сначала выпустить базовый набор, который закрывает основные потребности, проверить его практическую пользу и только затем усложнять модель.
Универсальные правила внедрения PMO
Практические правила внедрения проектного офиса можно свести к следующим пунктам:
Начинать с проблем бизнеса, а не с теории. Сначала определить, где теряются ценность и управляемость: в приоритетах, сроках, бюджетах, ресурсах, решениях или прозрачности.
Формализовать положения PMO. Должно быть ясно, за что проектный офис отвечает и где заканчиваются его полномочия.
Создать минимально жизнеспособную модель. Не внедрять сразу весь идеальный пакет, а начать с базовых процессов, устраняющих наиболее значимые проблемы.
Сегментировать проекты. Для инициатив разных типов следует устанавливать разные уровни управления.
Согласовать единый язык управления. В частности, определить, что означают понятия: проект, программа, риск, веха, статус, решение, эскалация и закрытие.
Назначить сильного владельца изменений. Без политической и управленческой поддержки проектный офис быстро теряет влияние.
Поддерживать команды, а не только проверять их. Стандарты принимаются лучше, когда помогают людям выполнять работу.
Измерять результат на уровне бизнеса. Оценивать не только соблюдение процессов, но и эффект для управления и исполнения.
Регулярно пересматривать модель PMO. По мере роста зрелости компании роль проектного офиса должна меняться.
Развивать культуру ответственности и открытости. Без нее даже хорошо спроектированный PMO может остаться декоративной структурой.
Итог
Рабочий проектный офис сочетает проектную дисциплину, полномочия управленческой функции и ориентацию на потребности пользователей. Его целесообразно запускать через MVP примерно за три месяца, оценивать по бизнес-результатам - в частности, по сокращению числа красных проектов и адаптировать по мере роста зрелости компании.
Статья составлена по моему первому ролику на тему PMO. По проектным офисам у меня накопилось значительное количество материалов и кейсов, если будет отклик, то могу двигаться по всем этапам, переведенным стандартам или конкретным темам. При том, что конструктивная критика подхода - тоже приветствуется.
Пишите как у вас запускался проектный офис? С чего начинали? Делитесь в комментариях.