Так получилось, что я лично был участником двух закрытий проектных офисов в компаниях и знаю много подробностей еще о трех других таких случаях.
Сразу отмечу, что:
- Я не рассматриваю какие-то форс-мажоры, такие как: закрытие бизнеса, кризис, поглощение и т. д.;
- Рассматриваю проектные офисы, связанные с технологическим развитием компаний, с ИТ.
Почему проектные офисы закрываются? Что с ними не так? Попробуем ответить на эти вопросы.
Основные причины закрытия проектных офисов
Все просто. Существует только две основные причины, почему они закрываются:
- Проектный офис выполнил свою задачу. Неважно какого уровня, корпоративный или внутри подразделения, открывался под вполне конкретную бизнес-задачу, например, под программу модернизации ИТ, под цифровую трансформацию. Установленные цели достигнуты, надобность в проектном офисе отпадает, его закрывают. Все логично.
- Проектный офис не выполнил свою задачу, не смог доказать свою выгоду. Если бы он приносил пользу для бизнеса, компании, то его бы не закрыли. Это как, взять и закрыть отдел продаж, который продает, и это приносит живые деньги.
Затраты или выгода: что приносит проектный офис
В большинстве случаев так описывают преимущества от проектного офиса или его задачи:
- эффективное и качественное управление проектами;
- развитие проектной методологии;
- сокращение сроков реализации проектов;
- управление ресурсами проектов;
- приоритизация проектов;
- обучение сотрудников проектной деятельности.
Все, что указано выше важно. Главное, чтобы «проекты выполнялись четко и прозрачно» можно услышать от генерального директора компании. От проектного офиса в начале его функционирования требуют мониторинга и контроля эффективной реализации проектов, но постепенно он превращается в излишнюю бюрократию, проекты начинают плыть, сроки срываются, бюджеты растут. В итоге, по прошествии трех-пяти лет офис закрывают. Причем это не является проблемой для компаний, потому что они продолжают прекрасно функционировать и дальше.
Проектный офис превратился в проблему для владельцев бизнеса и управленцев, он оказался бесполезным, не оправдал надежды. Иногда даже говорят, что стал слишком затратным, потому что многие компании рассматривают проектный офис, как центр затрат на проектную деятельность. Все затраты оцифровывают и переводят в деньги. Это очень любят делать финансовые директора. Но никто не оценивает профит, который должен приносить проектный офис. А ведь именно причиняемая выгода и должна говорить об успехе его функционирования. Все другие метрики рано или поздно приводят к закрытию проектного офиса, как ненужного подразделения.
Как оценить выгоду от проектного офиса
1. Помогает достигать стратегические цели
Проектному офису нужно управлять портфелем проектов, который тесно связан со стратегией компании. Каждый из этих проектов должен быть оценен с точки зрения его влияния на цели компании. Те, которые не влияют на стратегические цели компании, не должны запускаться. В данном случе проектный офис служит неким фильтром и инструментом для формирования правильного портфеля. Это очень болезненный, стрессовый и конфликтный путь развития проектного офиса. Мало кто решается по нему идти. Как следствие, этот отказ в том числе влияет на решение в будущем о закрытии проектного офис, как подразделения, которое не приносит выгоду подразделения, и без которого можно и обойтись.
2. Зарабатывает и/или экономит деньги
Проектный офис должен зарабатывать для компании или экономить деньги при реализации выбранных по первому пункту проектов. Эти деньги необходимо показывать отдельной строкой в бюджетах и отчетах. Сроки проектов не должны превышаться, а даже завершаться раньше сроков.
Приведу примеры, как это может выглядеть на практике:
- При централизованном управлении проектами в компании, проектное управление помогает сократить бюджеты проектов в несколько раз, особенно если проект большой инфраструктурный, прежде всего через централизованную работу с рисками. Каждому отдельному подразделению не нужно закладывать в бюджет своих работ риски, которые они видят. Ведь точно такие же риски может видеть и другое подразделение, и по имеющейся практике в крупных компаниях, заложить под них бюджет. Соответственно, проектный офис может выделить общие риски, оцифровать их, показав сколько бы денег заложило каждое подразделение на этот риск, а сколько в итоге заложено. Экономию показать руководству.
- Проектный офис, выполняя свои функции, должен постоянно стремиться к поиску пути ускорения реализации проектов и сокращения времени представления результатов заказчику. Это может быть достигнуто разными путями, но все найденные возможности сокращения должны оцифровываться. Например, широко используемая при реализации ИТ-проектов практика внедрения MVP-продукта, а затем уже всей остальной функциональности. Вполне реально оцифровать выгоду от MVP в количестве сэкономленных человеко-часов ИТ-команд в связи с отсутствием необходимости переделки функционала. На больших проектах, в которых участвуют десятки команд и подразделений, такая экономия может выражаться в тысячах человеко-часах. Уже на этапе MVP можно заработать для компании деньги — такой факт непременно оцифровываем и показываем руководству. А можно показать нежизнеспособность предполагаемого результата проекта — в этом случае ищем другой вариант, а экономию оцифровываем и показываем руководству.
Существует большое количество возможностей, при использовании которых проектный офис может найти способы экономии и заработка денег при реализации проектов, отвечающих стратегии компании. Главное – находить, реализовывать, оцифровывать эти возможности и показывать руководству цифры.
В моей практике был пример, когда очень важный для всей компании проект удалось спасти от закрытия. Сократили сроки реализации, урезали при этом предметную область. Но как оказалось такое урезание практически не повлияло на цели проекта, достижение которых в результате руководство приняло. Экономия была под семь десятков миллионов рублей.
Вывод
Если проектный офис не приносит оцифрованную выгоду компании, то рано или поздно такой проектный офис будет закрыт!
Читайте также:
Спасибо, интересно. Не самая простая тема для обсуждения.
Можно ли уточнить детали следующего:
В соответствии с Вашим опытом, как часто такая ситуация возникает?
В силу каких причин?
И почему PMO не может справиться с нарастающей собственной неэффективностью, хотя все инструменты для решения этой проблемы должны быть в наличии?
«Проекты начинают плыть, сроки срываются, бюджеты растут», такая ситуация следствие методологии управления проектом. Эффективная реализация проекта, гарантия существования проектного офиса. Сегодня практика показывает, что большинство проектных начинаний проваливаются вследствие того, что традиционные рациональные и линейные методы оказываются неэффективными для управления сложными проектами и их жизненными циклами Основной их недостаток – негибкость в условиях сложности и неопределенности среды. В проектной работе все шире применяются методики адаптивного управления, управление неопределенностью, при этом устанавливая рациональный баланс между контролем и взаимодействием в условиях динамичных сред.
Из Жана-Батиста Мольера:
- Мы можем излагать свои мысли не иначе, как прозой или стихами.
- Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой.
Мы можем вести дела либо в операционном стиле, либо в проектном. Третьего не дано. Я когда-то думал, что есть еще и третий стиль - конвейерный. Нет, конвейер - это тоже операционный стиль.
"Проектный офис" придумали как инструмент реализации проектного стиля ведения дел. Только, пожалуйста, не нужно придираться к словам: "стиль ведения дел", "метод управления", "подход к управлению" - слова сути не меняют.
Так вот. Проектный менеджмент штука непростая сама по себе (как теория) и тем более непростая при его реализации (как практика). Можно работать в проектном стиле правильно (там, PMBoK, Р2М), а можно по колхозному.
Чем отличается "правильный" подход от "колхозного"?
В "правильном" подходе чётко расписаны и не менее чётко реализуются регламенты.
В "колхозном" подходе на регламенты поплёвывают.
Проектное управление без проектного офиса возможно, знаю. Но это как раз симптом колхозного отношения к проектному управлению. А само проектное управление при этом никуда не девается, просто озимые засеваются весной, а урожай убирается в декабре с первыми морозами.
А так, да. Автор прав на 146%.
Вероятно, что проблема проектных офисов в том, что они могут быть оторваны от "производства", как впрочем могут быть оторваны от реальности тактических менеджеров с исполнителями стратегические менеджеры.
Соглашусь с Александром, что должны быть четкие регламенты и стандарты! А с другой стороны эти же самые регламенты могут приводить к бюрократии с её формальной отчетностью локальными показателями эффективности.
Проекты - это всегда о новом, то есть о том чтобы иногда выходить за рамки регламентов, создавая при этом новые регламенты.
Для меня примером такой гибкости являются старые стандарты Тойоты, позволяющие укладывать в строгие организационно-технические стандарты непредсказуемость и переменчивость социального спроса на продукцию.
На своем опыте могу сказать, что проектный офис во многих компаниях является этакой "пульсирующей" структурой со сроком жизни 2-3 года. Жизненный цикл выглядит так: у нас проблемы с реализацией проектов, нам нужен РМО - о, у нас появился РМО, ситуация постепенно улучшается - у нас всё стало хорошо, зачем нам РМО, он очень дорогой - распустили РМО, а всё работает, мы эффективные манагеры, ура! - у нас проблемы с реализацией проектов, нам нужен РМО.
Вот такой вот круговорот РМО в природе, да...
Такая ситуация не всегда относится к "неэффективности РМО". Есть разные типы проектных офисов. Если РМО не является частью основного бизнеса компании, а управляет "поддерживающими" проектами (типа ИТ-развития производственного предприятия), то обычно у него нет достаточных полномочий для решения возникающих проблем. Он функционирует по принципу "мы не играем, мы только счет ведем". И здесь велик соблазн свалить все неудачи на РМО, хотя по факту это неудачи руководства компании, которое не отреагировало своевременно на сигналы и эскалации. В этом случае, чтобы не остаться крайним, РМО вынужденно повышает уровень бюрократии, прикрываясь бумажками. Ну и получается то, о чем написано в статье: процесс мониторинга вроде бы идет, ресурсы на это тратятся, толку - чуть.
Евгений, к сожалению довольно частая ситуация в моем опыте. И как мне кажется, причина именно в том, что в начале требуют контроля и мониторинга. Проектный офис начиная эту работу, постепенно "влезает" в другие подразделения, придумывает регламентный процедуры, которые помогают именно ему выполнять лучше свою функцию, но мешают другим подразделениям и именно тогда проектный офис начинает восприниматься как бюрократическая единица.
Возможно. Если Вы правы, то такая проблема может возникнуть в любом подразделении. Но зоны ответственности и детали полномочий обычно определяются в момент создания подразделения. Если их недостаточно, то это видно на ранних этапах.
Есть ли в происходящем человеческий фактор?
Если мы о проектах, то какие новые регламентные процедуры, инициируемые PMO, начнают, как Вы выразились, мешать другим подразделениям? Где организационно находятся исполнители?
Такого рода процедуры обычно требуют согласования между подразделениями и выходят за рамки внутренних регламентов PMO. Но сами проекты никто не отменяет, и они должны выполняться.
Есть пример на эту тему?
Практика проектных офисов должна постепенно уйти в прошлое для промышленных предприятий по двум основным причинам.
1. Очень слаба профессиональная подготовка участников таких групп. А реализация проектов требует особых компетенций.
2. Внутренние подразделения предприятий не имеют свободы выбора информации, свободы подключения узких специалистов, свободы от внутрикорпоративных связей. Всë всегда упирается в бюрократию, в финансового директора, в службу экономической безопасности, в противодействие со стороны отдельных лиц, чьи интересы могут пострадать.
Такую практику надо менять.