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