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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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