Как минимизировать организационное сопротивление при внедрении проектного управления: подход «блэк бокс»

Мой первый опыт внедрения проектного управления в компании был провальным.

Я руководил проектным офисом — подразделением компании, отвечающим за разработку методологии проектного управления, формирование портфеля проектов, сбор отчетности по проектам и т. п. Я пытался заставить руководителей и кураторов проектов, не подчинявшихся мне напрямую, работать по новым правилам, например — проводить планерки по-новому, а они мне говорили: «Вася, ты будешь нам рассказывать, как планерки проводить? Мы и так отлично справляемся».

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

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

Проектный офис часто «лезет не в свое дело»

Часто я вижу, как представители проектного офиса лезут в проекты с «добрыми советами»: пытаются обучить, заставить правильно проводить планерки, управлять рисками и т. д.
Когда на неё нет запроса, эта работа проектного офиса воспринимается как то, что он лезет, куда не просят, и говорит: «Вы неправильно живете» — проект неправильно оформили, не по процедуре, и т. д. Это как минимум раздражает, даже если правда.

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

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

Надо четко очертить границы проекта и не лезть в них

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

  1. Компания инвестирует в проект определенные ресурсы. В обмен ожидает получить результат должного качества в согласованные сроки и бюджеты.
  1. Для этого надо согласовать требования к результату, согласовать сроки и бюджеты. Это удобнее всего сделать с помощью паспорта проекта, реестра результатов с требованиями, графика контрольных точек (не принимайте за универсальный рецепт). Требования к этому оформлению вот такие (и я могу их обосновать).
  1. Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.
  1. Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.

Чего я этим добиваюсь?

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

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

В-третьих, этих требований достаточно, чтобы контролировать ход проекта «снаружи» через отчетность по контрольным точкам.

Учить разумному, доброму, вечному можно только при наличии запроса

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

Например, не выполняется в срок контрольная точка из плана:
«2022-09-13 — Сдан в ОПЭ модуль „Бюджетирование“»
Мы можем 13 сентября сходить в бухгалтерию, и посмотреть своими глазами, сдан модуль в эксплуатацию или нет. И вот уже у нас есть неоспоримый факт: не соблюдена контрольная точка, и разговор проектного офиса становится гораздо конкретнее, и от него так не отмахнешься.
— Не выполнили контрольную точку? Вы должны инициировать процедуру переноса сроков, эскалации и т. д.
— Систематически не выполняются контрольные точки? Вот вам рейтинг руководителей или КПЭ, вы в нем в красной зоне. И вот уже руководителю проектов сложно сказать «я таких проектов сделал сотни, не надо меня учить». Глядишь, он и сам приходит на вебинар по управлению сроками, рисками и т. д.

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

К сожалению, я неоднократно сталкивался с тем, что проектный офис наступает на те же грабли, что и я когда-то: начинает с того, что пытается учить руководителей проектов, «сеять разумное, доброе, вечное» среди них, хочет «принести пользу руководителям, а не только заставить их заполнять бумажки»... и каждый раз это заканчивается абсолютно одинаково. Разумное, доброе, вечное не всходит, польза оказывается не востребована, очередная попытка внедрения проектного управления буксует.

Поделиться
Отправить
Запинить
Популярное