21 сен 2020

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
31 Мая 2024
Что такое PMBok и как его применять
В этой статье подробнее расскажем о международном стандарте по управлению проектами PMBoK: что это такое, для каких проектов лучше всего подходит, из чего состоит, преимущества и недостатки стандарта.
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

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

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

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена