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