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