+7 (926) 827 3222
21 сен 2020

Принцип матрешки или как проектному офису стать полезным

Для кого:
  • Владельцы бизнеса
  • Руководители проектного офиса
  • Руководители проектов
Знания и навыки:
  • Проектные офисы
  • Стейкхолдеры
  • Команда проекта

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

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

Наиболее полезным итогом данного мероприятия были не сами оценки, а комментарии, отвечающие на вопрос «почему» были поставлены определенные баллы.

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

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

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

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

Так как же стать проектному офису полезным подразделением для тех, с кем оно взаимодействует?

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

Но ведь нельзя в атмосфере постоянной вражды со всеми ключевыми стейкхолдерами преуспеть (и многие проектные офисы как раз налетают на эти грабли и тогда заканчивают свой земной путь не более чем за пару лет).

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

Я для себя называю его «Принцип матрешки».

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

Я предлагаю начать с оценки ожиданий самого влиятельного стейкхолдера (например, акционера), а далее прояснить для каждого ключевого стейкхолдера рангом пониже (например, ИТ-директора).

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

То есть, в идеале – сначала идем к акционеру, потом к ГД, потом к ЗГД, потом к линейным менеджерам и руководителям проектов.

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

Теперь этот тезис будет ограничением для ИТ-директора (в этом как раз проявляется «Принцип матрешки»), который хочет, чтобы объем поручаемых ему проектов был реалистичным, и он мог обосновать необходимые ресурсы.

Но для того, чтобы корректно сформулировать свои ожидания ИТ-директор должен обладать знанием целей и ограничений акционера и ГД. Корректно донести их – задача руководителя проектного офиса.

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

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

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

1) есть внятные стейкхолдеры – владельцы ресурсов (акционер, ГД, ЗГД)

2) вы как руководитель проектного офиса работаете с ними в нужном порядке

3) вы смогли выстроить правильную последовательность целей-ограничений

то и быть полезным станет намного проще.

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Подписаться на рассылку
Высылаем анонсы статей и полезные материалы

Нажимая на кнопку "Подписаться", вы соглашаетесь с политикой конфиденциальности

Смотрите также:
18 Окт 2024
Что из себя представляет Agile team
Обычно это межфункциональная команда, которая идентифицирует, разрабатывает, тестирует и доставляет пользу за короткий период времени. Какие бывают типы Agile команд и каковы их обязанности, читайте ниже.
18 Окт 2024
Организация команды Agile
Agile-подход заключается в том, что планирование и выполнение проекта происходят поэтапно, с возможностью оперативного внесения корректировок на любом этапе. Этот подход возник, чтобы обеспечить адаптивность, скорость реакции на изменения и лучшее качество конечного продукта. В этой статье рассказываем, как эффективно организовать работу команды Agile.
18 Окт 2024
Что такое матрица трассировки требований
Как и для чего используется матрица трассировки требований – рассказываем в этой статье.
Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена