Почему закрываются проектные офисы

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

Сразу отмечу, что:

  1. Я не рассматриваю какие-то форс-мажоры, такие как: закрытие бизнеса, кризис, поглощение и т. д.; 
  2. Рассматриваю проектные офисы, связанные с технологическим развитием компаний, с ИТ.

Почему проектные офисы закрываются? Что с ними не так? Попробуем ответить на эти вопросы. 

Основные причины закрытия проектных офисов

Все просто. Существует только две основные причины, почему они закрываются:

  1. Проектный офис выполнил свою задачу. Неважно какого уровня, корпоративный или внутри подразделения, открывался под вполне конкретную бизнес-задачу, например, под программу модернизации ИТ, под цифровую трансформацию. Установленные цели достигнуты, надобность в проектном офисе отпадает, его закрывают. Все логично.
  2. Проектный офис не выполнил свою задачу, не смог доказать свою выгоду. Если бы он приносил пользу для бизнеса, компании, то его бы не закрыли. Это как, взять и закрыть отдел продаж, который продает, и это приносит живые деньги. 

Затраты или выгода: что приносит проектный офис

В большинстве случаев так описывают преимущества от проектного офиса или его задачи:

  • эффективное и качественное управление проектами;
  • развитие проектной методологии;
  • сокращение сроков реализации проектов;
  • управление ресурсами проектов;
  • приоритизация проектов;
  • обучение сотрудников проектной деятельности.

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

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

Как оценить выгоду от проектного офиса

1. Помогает достигать стратегические цели

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

2. Зарабатывает и/или экономит деньги

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

Приведу примеры, как это может выглядеть на практике:

  • При централизованном управлении проектами в компании, проектное управление помогает сократить бюджеты проектов в несколько раз, особенно если проект большой инфраструктурный, прежде всего через централизованную работу с рисками. Каждому отдельному подразделению не нужно закладывать в бюджет своих работ риски, которые они видят. Ведь точно такие же риски может видеть и другое подразделение, и по имеющейся практике в крупных компаниях, заложить под них бюджет. Соответственно, проектный офис может выделить общие риски, оцифровать их, показав сколько бы денег заложило каждое подразделение на этот риск, а сколько в итоге заложено. Экономию показать руководству.
  • Проектный офис, выполняя свои функции, должен постоянно стремиться к поиску пути ускорения реализации проектов и сокращения времени представления результатов заказчику. Это может быть достигнуто разными путями, но все найденные возможности сокращения должны оцифровываться. Например, широко используемая при реализации ИТ-проектов практика внедрения MVP-продукта, а затем уже всей остальной функциональности. Вполне реально оцифровать выгоду от MVP в количестве сэкономленных человеко-часов ИТ-команд в связи с отсутствием необходимости переделки функционала. На больших проектах, в которых участвуют десятки команд и подразделений, такая экономия может выражаться в тысячах человеко-часах. Уже на этапе MVP можно заработать для компании деньги — такой факт непременно оцифровываем и показываем руководству. А можно показать нежизнеспособность предполагаемого результата проекта — в этом случае ищем другой вариант, а экономию оцифровываем и показываем руководству.

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

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

Вывод

Если проектный офис не приносит оцифрованную выгоду компании, то рано или поздно такой проектный офис будет закрыт!

Читайте также:

Расскажите коллегам:
Комментарии
Генеральный директор, Москва
Михаил Трофименко пишет:
Евгений Равич пишет:
Не вижу связи между идеями ТРИЗ и обсуждаемыми проблемами управления проектами на предприятии.

Так Вы и не смотрите, потму и не видите. ТРИЗ применяется для решения изобретательских задач, а инструменты Бережливого потребления для решения управленческих задач. Построение алгоритмов использует схожую идею универсальности. Кибернетика, штука сильная.

Евгений Равич пишет:
Дадите хотя бы оглавление?

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

Давайте, что можете и хотите. Предполагаемый тираж распространения - 1 экз., читатель Вам известен. Так будет проще обсуждвть задачи, инструменты, ТРИЗ, PM и кибернетику в одном флаконе. Такое сочетание встречается не каждый день, мягко говоря.

Евгений Равич пишет:
Как уже обсуждалось по другому поводу, все такие беседы предшествуют формальному принятию решения о начале работ.

А Вы разве не участвовали в подобных технически непростых проектах? Всегда есть недоработки проектов, недоработки концепции, недоработки подрядчиков и исполнителей.

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

Евгений Равич пишет:
Простой критерий для проверки: что влияет на состав работ?

Порядок выполнения работ неизменен.

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

Евгений Равич пишет:
Почему PMO (при его наличии) не мог бы создать такую базу? Цели понятны, ожидаемые результаты - тоже. Бюджет, сроки и ресурсы уточняются со спонсором проекта.

Если выступит на принципах работы ПР, когда ищет решение, но не принимает его, тогда почему нет. Например, РМО выступает Аоставщиком решений для службы главного инженера предприятия.

Зачем бы PMO это делать, если это не происходит в формате проекта?

Рутинную работу по сбору информации, подготовке ТЭО осуществляет РМО, но утверждает после защиты главный инженер. Защита осуществляется при проверке специалистами отдела главного инженера. Если защита проходит гладко, повод задуматься о профпригодности менеджеров отдела.

Когда-то в ходе похожей по сюжету беседы я уже задавал самые базовые вопросы: кто инициирует проект, кто его спонсор, и какие у проекта цели? Для проекта по созданию базы ответы Вам известны?

Всё остальное из перечисленного Вами - какой-то порядок проведения работ. Один из возможных.

 

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

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

Евгений Равич пишет:
Зачем бы PMO это делать, если это не происходит в формате проекта?

ПР всегда действует на упреждение. Иногда может сам выступать инициатором улучшений, например в области энергосбережения.

Евгений Равич пишет:
Когда-то в ходе похожей по сюжету беседы я уже задавал самые базовые вопросы: кто инициирует проект, кто его спонсор, и какие у проекта цели? Для проекта по созданию базы ответы Вам известны?

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

Аналитик, Нижний Новгород
Евгений Равич пишет:
Давайте, что можете и хотите.

trofimenkoml  и дальше собака мейл. Скидывайте тестовое письмо, пришлю некоторые материалы которые можно.

Генеральный директор, Москва
Михаил Трофименко пишет:

Тогда возникает вопрос, а как организован полный контроль, если ПО может привлекаться только частично? Должно быть стандартное решение. И почему есть такая градация участия?

Моё мнение, что УК, как безответственная прокладка между Собственником и его активами, должны исчезнуть уступив место советам директоров или любому другому органу непосредственного управления без отчуждения права решать.

Вот. Давайте посмотрим что такое проект. Разве любой проект не является закупкой в принципе? Даже если мы говорим о некоммерческом проекте, это всегда затраты ресурсов.

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

Мурад Чапаров пишет:
Т.о. упрощенно схема следущая: инициатор предлагает проект, ЦПГ и служба развития (техпроекты и функциональные) его рассматривает и формирует модель с финрезом и прочими эффектами, затверждает на  инвест-комитете, защищает на СД. Управляет проектом ЦПГ, реализует развитие или ФЦ, контролит и постинвест-мониторинг ИК.

А ЦПГ, это цилиндро-поршневая группа? Класс. Но пыль в глаза можно пустить и так. Я конечно понимаю, что Вы владеете, но Если я Вам скажу на другом языке поймёте? Например: инициатором выступает внутренний  или заказчик, ТЗК включает в простой состав проектов, привлекает ПР, ПР готовит ТЭО, ИК проводит аттестацию на основании которой ТЗК включает в приоритетный список проектов с финансовым обеспечением, затем ПР под контролем ТЗК выполняет подбор исполнителей, ИК назначает РП для управления проектом, ПР осуществляет надзор и на заключительном этапе отчёт об аудите эффективности. На самом деле сложней, но и так всё понятно.

 

 

1. Пример частичного управления: закпуки у ПО, контроль бюджета у ПО, ход проекта у ПО и т.п. на моей практике  ПО в УК и контролил сроки, бюджет, помогал с подрядчиками. В общем курировал, мне как CEO это не лишне.

2. С УК не соглашусь. Вопрос какой ее создавать, как выстроить кросс-функциональное взаимодействие, но это отдельная и большая тема обсуждения. Скажу так: УК полезна и важна площадкам, главное, что бы УК занималась своей главной функцией: стратегия, развитие, контроль, консолидация, методология, но не погружалась в операционку.

3. Ок.

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

5. Не комментирую, т.к. не цепляюсь за слова, если что-то непонятно вежливо прошу разъяснить.

Генеральный директор, Москва
Михаил Трофименко пишет:
Евгений Равич пишет:
Каждый должен принимать свои решения, а изменения в планы вносятся по мере необходимости и в соответствии с процедурой.

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

Бывает - и часто. Менеджер проекта об этом знает.

Вопрос, что написано в контракте, на основании которого делается проект, и какова процедура внесения изменений в ранее согласованную проектную документацию.

Евгений Равич пишет:
Зачем бы PMO это делать, если это не происходит в формате проекта?

ПР всегда действует на упреждение. Иногда может сам выступать инициатором улучшений, например в области энергосбережения.

Я говорю о PMO. То есть о подразделении Project Management Office с задачами, перечисленными в статье и мной выше.

Вы - о ПР, и только Вы знаете, что входит в его цели и задачи. Как и о его месте в структуре организации.

Евгений Равич пишет:
Когда-то в ходе похожей по сюжету беседы я уже задавал самые базовые вопросы: кто инициирует проект, кто его спонсор, и какие у проекта цели? Для проекта по созданию базы ответы Вам известны?

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

Давайте сделаем паузу для изучения Ваших материалов.

Что такое проект и его реализация - примерно понятно., если пользоваться общедоступными источниками.  База с перечнем нарушений и замечаний, о которой Вы сказали выше, вполне может быть создана в рамках отдельного проекта под управлением PMO. Но Вы так не считаете. Мне пока нечего добавить.

Аналитик, Нижний Новгород
Евгений Равич пишет:
Бывает - и часто. Менеджер проекта об этом знает.

Евгений, настройтесь на понимание. Надеюсь Вы поняли о чём я говорю.

Евгений Равич пишет:
Вы - о ПР, и только Вы знаете, что входит в его цели и задачи. Как и о его месте в структуре организации.

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

Евгений Равич пишет:
База с перечнем нарушений и замечаний, о которой Вы сказали выше, вполне может быть создана в рамках отдельного проекта под управлением PMO.

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

Генеральный директор, Москва
Михаил Трофименко пишет:
Евгений Равич пишет:
Бывает - и часто. Менеджер проекта об этом знает.

Евгений, настройтесь на понимание. Надеюсь Вы поняли о чём я говорю.

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

Евгений Равич пишет:
Вы - о ПР, и только Вы знаете, что входит в его цели и задачи. Как и о его месте в структуре организации.

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

Подразделение в составе организации, но вне орг. структуры? Пока такое мне не  встречалось.

Евгений Равич пишет:
База с перечнем нарушений и замечаний, о которой Вы сказали выше, вполне может быть создана в рамках отдельного проекта под управлением PMO.

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

Про эту базу сказали Вы. Если она не имеет ценности - Вам виднее.

Аналитик, Нижний Новгород
Евгений Равич пишет:
Тестовое письмо и запрос контакта выслал, почитаю Ваши материалы и продолжим.

Отправил. Некоторые документы попридержал. Но для начала вполне.

1 2 4
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
4
Михаил Лурье
Ну есть версия, что у Александра I были какие-то личные обязательства перед иностранными сторона...
Все дискуссии
HR-новости
Половина россиян трудоустраивали друзей и родственников в свою компанию

Чаще других в хантинге принимали участие специалисты из сфер маркетинга, рекламы и PR, туризма, гостинично-ресторанного и автомобильного бизнеса.