Принцип матрешки или как проектному офису стать полезным
- Владельцы бизнеса
- Руководители проектного офиса
- Руководители проектов
- Проектные офисы
- Стейкхолдеры
- Команда проекта
Периодически приходится сталкиваться с попытками руководителей проектных офисов оценить удовлетворенность своим подразделением со стороны тех, с кем оно взаимодействует.
Когда я был руководителем корпоративного проектного офиса в банке я сам проходил процедуру такой оценки, правда не по своей воле.
Наиболее полезным итогом данного мероприятия были не сами оценки, а комментарии, отвечающие на вопрос «почему» были поставлены определенные баллы.
Тут всплывали и личные обиды, и уязвленные амбиции некоторых руководителей, но периодически попадались и дельные отзывы о кривых забюрократизированных процессах и формальном отношении некоторых сотрудников (реже).
Но одновременно с желанием получить «объективную» оценку своей работы этим попыткам почти всегда сопутствует страх того, что контрагенты проектного офиса, с которых он что-то постоянно требует, то отчет, то презентацию, то заполнение как их либо проектных документов, не воспринимают проектный офис, как подразделение приносящее ценность и, следовательно, могут отразить в опросе ровно то, что думают о его пользе «без купюр». И это скорее обрушит его авторитет в глазах руководства организации.
При этом проектный офис «выбивается из сил, чтобы быть полезным для руководства» – отчетность, комитеты, решение любых поставленных задач, бессонные ночи, и подспудно чувствует несправедливость вероятной негативной оценки.
Один из моих бывших руководителей – Старший вице-президент Банка, бравший меня на работу, на одной из первых встреч после трудоустройства заявил: «Если на тебя не будут жаловаться, я тебя уволю». Видимо, подразумевая, что деятельность проектного офиса не может быть комфортна для тех, чьи действия он хотел бы изменить, а полномочия ограничить.
Так как же стать проектному офису полезным подразделением для тех, с кем оно взаимодействует?
Возьмем, к примеру руководителей проектов, линейных руководителей или топ-менеджеров. С руководителей проектов он требует соблюдение правил и предоставление отчетности, линейных руководителей выводит из тени и заставляет решать их косяки на проектах или оправдываться за отклонения перед большими боссами, топ-руководителей может ограничить в свободе действий, а то и лишить возможности принимать единоличные решения о судьбе проектов или выделяемых на их усмотрение ресурсов.
Но ведь нельзя в атмосфере постоянной вражды со всеми ключевыми стейкхолдерами преуспеть (и многие проектные офисы как раз налетают на эти грабли и тогда заканчивают свой земной путь не более чем за пару лет).
На мой взгляд, существует наиболее рабочий подход, который позволяет поднять ценность проектного офиса в глазах ключевых стейхколдеров.
Я для себя называю его «Принцип матрешки».
Принцип состоит в том, что польза от проектного офиса напрямую связана с построением правильной иерархией ожиданий и целей стейкхолдеров, на удовлетворении которых стоит сфокусировать свои усилия.
Я предлагаю начать с оценки ожиданий самого влиятельного стейкхолдера (например, акционера), а далее прояснить для каждого ключевого стейкхолдера рангом пониже (например, ИТ-директора).
Ожидание и цели более высокого стейхолдера при этом выступают в качестве ограничений в переговорах о том, чем проектный офис может быть полезен менее статусному руководителю.
То есть, в идеале – сначала идем к акционеру, потом к ГД, потом к ЗГД, потом к линейным менеджерам и руководителям проектов.
Например, задача от акционера: хочу заранее знать, если возникнет риск нарушить сроки или выйти за утвержденный бюджет нескольких стратегических проектов.
Теперь этот тезис будет ограничением для ИТ-директора (в этом как раз проявляется «Принцип матрешки»), который хочет, чтобы объем поручаемых ему проектов был реалистичным, и он мог обосновать необходимые ресурсы.
Но для того, чтобы корректно сформулировать свои ожидания ИТ-директор должен обладать знанием целей и ограничений акционера и ГД. Корректно донести их – задача руководителя проектного офиса.
Далее идем к руководителю руководителей ИТ-проектов и узнаем о его ожиданиях от проектного офиса, но уже в контексте целей более влиятельных стейкхолдеров.
И ему проектный офис может быть полезен, только не в вакууме, а в обозначенных ограничениях.
Проектному офису не стоит да и невозможно быть безоговорочно полезным или приятным всем участникам проектной деятельности. Для многих изменение правил запуска и реализации проектов и выделения ресурсов на них встанут поперек горла. Но, если:
1) есть внятные стейкхолдеры – владельцы ресурсов (акционер, ГД, ЗГД)
2) вы как руководитель проектного офиса работаете с ними в нужном порядке
3) вы смогли выстроить правильную последовательность целей-ограничений
то и быть полезным станет намного проще.