Заказать звонок
Москва, Пресненская набережная, 12
Корзина 0
Войти
PMJournal.ru - управление проектами
Портал для профессионалов в управлении проектами
Услуги
Книги
Онлайн-курсы
Кейсы
Статьи
Новости
Обзоры
Тренинги
Работа
Персоны
Мероприятия
Ещё
    PMJournal.ru - управление проектами
    Услуги
    Книги
    Онлайн-курсы
    Кейсы
    Статьи
    Новости
    Обзоры
    Тренинги
    Работа
    Персоны
    Мероприятия
    Ещё
      0
      PMJournal.ru - управление проектами
      0
      • Услуги
      • Книги
      • Онлайн-курсы
      • Кейсы
      • Статьи
      • Новости
      • Обзоры
      • Тренинги
      • Работа
      • Персоны
      • Мероприятия
      • Личный кабинет
      • Корзина0
      Будьте на связи
      Москва, Пресненская набережная, 12
      info@pmjournal.ru
      • Facebook
      • Вконтакте
      • Twitter
      • Instagram
      • Telegram

      Управление Проектным офисом по бизнес-целям

      • Главная
      • Блог
      • Обзоры
      • Управление Проектным офисом по бизнес-целям
      // Обзоры
      Автор: PM Angel

      Обзор выступления Марка Прайс Перри с конференции PMO 2017 от практика по внедрению проектных офисов


      Марк Прайс Перри - бывший руководитель дивизиона IBM, основатель консалтинговой компании BOT International, которая внедряет проектные офисы, управляемые по бизнес-целям уже 18 лет. Марк рассказал свое видение модели успешного проектного офиса.

      9 из 10 опрошенных Марком руководителей проектных офисов, руководителей проектов, высших руководителей не знают цель своего проектного офиса. По его мнению, из-за этого некоторые проектные офисы (далее – ПрОф) закрываются.

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


      1 – создается новый проектный офис.

      2 – PPTT (People, Process, Tools, Training – подбор персонала, процессы, инструменты и тренинги). Проблема этого этапа в том, что цели проектного офиса еще не определены и не согласованы, а практики проектного офиса уже внедряются. Многих руководителей проектных офисов (далее – РПО) увольняют на этом этапе.

      3 – QWBS (Quick Wins Buying Support) – проектный офис внедряет стратегию «быстрых побед».

      4 – OPMM (Organizational Project Management Maturity) – в проектном офисе повышают «уровень зрелости». И на этом этапе РПО тоже могут уволить.

      5 — NGVD (Next Generation Value Driven) – в проектном офисе внедряют управление «следующего поколения». Начинается поиск и «продажа» ценности проектного офиса. И здесь РПО тоже могут уволить.

      6 – SPMO (Strategic Project Management Office) – стратегический проектный офис. На этом этапе проектный офис может переместиться вверх по иерархии из-за веры в то, что чем он выше, тем он более стратегический.

      7 – BD (Business Driven) – проектный офис, управляемый по бизнес-целям. У ПрОф определены цели и компетенции для достижения этих целей. Как говорит Марк, на этом этапе «повозка больше не должна ехать впереди лошади».

      Хотя возможно не проходить «долину смерти» с 1 по 6 пункты, а сразу работать над переходом к седьмому пункту.

      Как определить бизнес-цели проектного офиса. Кейс

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

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

      Действие 1. У гендиректора появляется идея создания проектного офиса 

      Гендиректор предложил команде топ-менеджеров создать проектный офис. При этом у каждого топ-менеджера своя задача для ПрОф, для:

      • вице-президента по продажам — увеличить выручку от продажи консалтинга;
      • вице-президента по консалтингу — помощь в управлении объемом работ (SOW);
      • технического директора — создать единую картину по всем проектам компании;
      • гендиректора – создать инструмент реализации стратегии.

      Они просмотрели множество резюме кандидатов на РПО, проинтервьюировали пять кандидатов, из которых двое показались подходящими – опытный РПО и опытный менеджер компании разработки программного обеспечения. Вот их особенности:

      Кандидат 1. Опытный РПО Кандидат 2. Опытный менеджер разработки программного обеспечения
      • Опыт управления проектными офисами
      • Создал три ПрОф за последние 10 лет
      • Разрабатывал методологию проектного управления
      • Внедрял Microsoft Enterprise Project Management
      •  Организовывал программы тренингов по управлению проектами
      •   Сертифицированный PMP
      • Опыт управления подразделением разработки ПО
      • Управлял продажами, маркетингом, бизнес-развитием, консалтингом
      • Знает отрасль и рынок, на котором работает компания
      • Понимает проектное управление
      • Нет сертификата PMP
      • Никогда не управлял проектным офисом

      Действие 2. Компания выбирает кандидата 1

      На второй неделе внедрения новый РПО начинает с модели PPTT (подбор персонала, процессы, инструменты и тренинги).

      Итого за полгода ему удалось:

      • укомплектовать ПрОф новыми сотрудниками
      • согласовать методологию проектного управления
      • внедрить MS Project Server
      • спланировать и начать проводить тренинги по проектному управлению
      • регулярно предоставлять ежемесячные отчеты

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

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

      Но в ответ он слышал: «Вы еще не готовы к проектному офису». Это кажется смешным, но Марк действительно слышал такой ответ.

      Действие 3. Компания нанимает второго кандидата

      Новый РПО начинает с того, что общается с людьми – задает вопросы и слушает ответы. Он реализует два шага для изменения проектного офиса:

      Шаг 1. Определение целей проектного офиса. Причем цели должна определять сама команда топ-менеджеров, роль РПО только в том, чтобы помочь им это сделать. Марк предлагает структурировать эти цели и записать их в формальном документе – «мандат проектного офиса».

      Шаг 2. Разработка бизнес-плана по достижению целей.

      Марк предлагает следующую структуру мандата проектного офиса:

      • Топ-3 проблем
      • Видение
      • Миссия
      • Цели и целевые показатели
      • Ценность для бизнеса. С помощь чего команда топ-менеджеров поймет и оценит достижение целей? И это не должны быть метрики вроде «зрелость проектного офиса», которые имеют ценность только для самого проектного офиса.

      Как же добиться того, чтобы все топ-менеджеры со своими целями и ожиданиями смогли создать один документ для проектного офиса?

      Марк предлагает воспользоваться техникой «Nemawashi», которую используют в компании Toyota.

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

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


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

      И в завершении драмы, напомним. Перед созданием или изменением проектного офиса спросите топ-менеджмент, зачем им проектный офис и какие три проблемы они хотят решить с помощью него и какое значение они имеют для бизнеса?

      Только не подменяйте цели проектного офиса такими:

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

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

      Цели проектного управления и что важно для заинтересованных сторон

      Ниже представлен сводный отчет для топ-менеджмента двух одинаковых проектов, которые, к примеру, реализуются в разных городах – Лондоне и Манчестере. Посмотрите его и ответьте: в каком проекте руководитель проекта (далее – РП) делает свою работу лучше?

      При этом обратите внимание, что повлияло на ваш ответ.


      Когда Марк задавал этот вопрос своим коллегам, у каждого был свой ответ. Профессиональный руководитель проектов, PMP, ответил, что РП лучше в проекте 1.

      А коллега из числа топ-менеджеров ответил, что первому он не верит, а второй делает свою работу лучше.

      Таким образом, мнения о руководителе проекта по одному и тому же отчету разделились. Марк считает, что это произошло из-за того, что в отчете не хватает бизнес-контекста.

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

      Проект «Онлайн продажи пряжи» Проект «Открытие казино»
      Цели в бизнес-контексте Как можно быстрее запустить онлайн-продажи Избежать многомиллионных штрафов
      Затраты Менее 250 тыс долларов Менее 250 тыс долларов
      Длительность Менее 6 месяцев Менее 6 месяцев
      Выгоды
      • Зарабатывать 20 тыс долларов в день
      • Заработать 20 млн долларов за 3 года
      • Избежать штрафа за открытие казино позже срока – 1 млн долларов за 1 день просрочки
      • Избежать потерю лицензии
      Ожидания заинтересованных сторон
      • Время (нужно запустить как можно быстрее)
      • Содержание и затраты вторичны
      • Время (нельзя опаздывать)
      • Содержание и затраты вторичны
      Подход
      • Агрессивное календарное планирование
      • Отрицательные буферы
      • Сокращение оценки сроков на 25%
      • Осторожное календарное планирование
      • Положительные буферы
      • Добавление 25% к оценке сроков
      Результаты проекта Проект закончился позже, чем планировалось, но онлайн-продажи запустились как можно раньше Проект закончился позже, чем планировалось, но казино открылось вовремя
      Бизнес результаты Выгоды максимизированы Штрафов за просрочку удалось избежать

      В обоих проектах требования к бюджету и длительность были одинаковые – потратить не более 250 тысяч долларов и запустить меньше чем за полгода. Но были существенные различия –в бизнес-целях проектов. В одном: запустить как можно скорее, в другом – успеть к сроку и открыть казино вовремя.

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

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

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

      Марк, конечно, лукавит, так как если не контролировать содержание, время и бюджет и не сообщать лицам принимающим решения об отклонениях, то можно нарваться на неприятности. Если отдать на откуп руководителям проектов решения, которыми с учетом бизнес-контекста можно пожертвовать без согласования с заинтересованными сторонами, то вместо ориентации на бизнес можем получить полностью неуправляемую систему   

      Возможно, вам это известно, и вы даже это делаете. Однако опрос клиентов, который провел Марк, показал, что из 100 опрошенных 90% не используют в отчетах метрики, реально отражающие ход проекта в значимых метриках для заинтересованных сторон.

      Марк показал, как может выглядеть отчет топ-менеджменту, если делать акцент только на метриках: содержание, время, бюджет (пример 1). И как выглядит отчет, если показать в нем метрики, важные заинтересованным сторонам — выгоды, приоритеты заказчика – время, качество, бизнес-эффект, то, насколько могут быть изменены параметры проекта, т.е. сколько заказчики готовы платить (will to pay) и сколько готовы ждать (will to wait) (пример 2).




      По комментарию к отчету становится понятно, что дополнительные 300 тысяч долларов США были потрачены на уменьшение риска, который мог принести убытков в 3 млн долларов США.

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

      Порядок создания проектного офиса, управляемого по бизнес-целям, от Марка Перри

      Шаг 1. Согласовать мандат проектного офиса

      • Определить структуру мандата проектного офиса
      • Определить подход к разработке мандата ПрОф
      • Разработать и согласовать мандат ПрОф

      Марк предлагает выделить на создание мандата ПрОф до шести месяцев, в некоторых случаях можно успеть и за три месяца.

      Шаг 2. Разработать бизнес-план создания проектного офиса

      • Определить структуру бизнес-плана. Возможно, взять используемую в компании
      • Написать стратегию и план в соответствии с целями из мандата проектного офиса
      • Спланировать создание и развитие практик ПрОф

      Марк предлагает выделить на разработку бизнес-плана 1-3 месяца.

      Шаг 3. Реализовать бизнес-план внедрения проектного офиса

      Учитывать:

      • Нужно управлять проектным офисом, как и другими бизнес-подразделениями
      • Действовать в соответствии с бизнес-планом

      Шаг 4. Создать метрики для отслеживания прогресса внедрения проектного офиса (PMO Dashboard)

      Марк Перри считает, что если у вас нет метрик, то неважно сколько вы делаете, этого всегда будет недостаточно.


      Заключение

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

      Цели он предлагает оформлять в виде мандата проектного офиса и ежегодно их пересматривать.

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

      Помните, проектный офис не принадлежит самому себе, он принадлежит бизнесу.



      Подробнее на  http://pmlogic.ru/proektnyiy-ofis-upravlyaemyiy-po-biznes-tselyam/?utm_source=fb&utm_medium=anons&utm_campaign=anonsfb_mark_perry_270418


      Автор: PM Angel
      Понравилось Понравилось Не понравилось Не понравилось

      Поделиться
      Назад к списку
      • Комментарии
      • Facebook
      • Вконтакте
      Загрузка комментариев...
      Категории
      • Кейсы40
      • Бизнес статьи35
      • Новости13
      • Обзоры38
      • Проект "Бизнес-эволюция"0
      • Тренинги4
      • Работа9
      • Персоны64
      • Мероприятия4
      Это интересно
      • Тренажер для подготовки к сертификации РМР
        Тренажер для подготовки к сертификации РМР
      • Внедрение корпоративной системы управления проектами (КСУП)
        Внедрение корпоративной системы управления проектами (КСУП)
      • Agile и Scrum: книги по гибкой методологии
        Agile и Scrum: книги по гибкой методологии
      • Гибкое управление продуктом (видео презентация)
        Гибкое управление продуктом (видео презентация)
      • Отчет об исследовании Agile в России
        Отчет об исследовании Agile в России
      • Об истории сертификации PMI в России в цифрах 2000-2019Q1
        Об истории сертификации PMI в России в цифрах 2000-2019Q1
      • Продление сертификата PMP
        Продление сертификата PMP
      • Менеджер проекта VS Менеджер по продажам
        Менеджер проекта VS Менеджер по продажам
      • Уметь спорить с достоинством
        Уметь спорить с достоинством
      • Redmine – система управления проектами
        Redmine – система управления проектами
      • С чего начать внедрение проектного управления?
        С чего начать внедрение проектного управления?
      • Мода на проекты
        Мода на проекты
      • 43 полезных сервиса для управления проектами и задачами
        43 полезных сервиса для управления проектами и задачами
      • Приемы управления стартапами в XIX веке
        Приемы управления стартапами в XIX веке
      • Цитаты от создателей VISA и MICROSOFT
        Цитаты от создателей VISA и MICROSOFT
      • Организационное управление проектами и модель зрелости
        Организационное управление проектами и модель зрелости
      • Когда у компании слишком много проектов.
        Когда у компании слишком много проектов.
      •  Руководство по запуску Agile команд
        Руководство по запуску Agile команд
      • ПРОРЫВ! Google выяснил 5 условий построения идеальной команды
        ПРОРЫВ! Google выяснил 5 условий построения идеальной команды
      • Обзор зарплат Руководителей проектов по всему миру
        Обзор зарплат Руководителей проектов по всему миру
      Облако тегов
      50 проектов Agile Gartner IPMA jira Kanban M&A MS Project opm3 PDCA PM PMBOK PMBOK7 PMI PMP PRINCE2 Project Manager RUP Scrum waterfall web-разработка ZohoProjects анти КСУП Боль веб-сервис внедрение информационной системы управления проектами внедрение корпоративной системы управления проектами внедрение проектной методололгии жизненный цикл проекта зачем нужно проектное управление информационная система управления проектами ИСУП коммуникации конференция по управлению проектами Корпоративная Система Управления Проектами КСУП Менеджер проекта Менеджмент менеджмент менеджмент проектов веб-сервисы Методология проектного управления Мотивация области управления проектами Обучение управлению проектами Онлайн-обучение онлайн-тренинги по управлению проектами Онлайн-школа освоенный объем погуби проектное управление подборка принимать решения приоритезация провал проекта продакшн Проектный офис проекты процессное управление процессы управления проектами регулярный менеджмент Роман об управлении проектами Руководитель проекта сервисы сертификация по управлению проектами Стандарт управления проектами ГОСТ строительные проекты тайм-менеджмент технология проектного управления типы коммуникаций типы контрактов Тренинги умение договариваться умение спорить Управление бюджетом управление закупками Управление идеями управление инновациями Управление интеграцией Управление качеством Управление коммуникациями Управление персоналом управление поручениями Управление проектами управление проектами Управление проектами в органах государственной власти Управление проектом управление рисками Управление содержанием Управление сроками Управление стейкхолдерами управление хаосом Фейковое проектное управление финансовый анализ ценность проектного управления Цитаты об управлении проектами Цифровая трансформация
      Подпишитесь на нашу рассылку и получайте первыми все самые интересные новости об управлении проектами!
      Онлайн-школа по управлению проектами
      Авторский тренинг «Стань Руководителем проекта, начни зарабатывать больше»
      Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      Услуги по управлению проектами
      Внедрение Корпоративной Системы Управления Проектами (КСУП)
      Книги по управлению проектами
      Книга "Корпоративная система управления проектами"
      Книга "Как сдать экзамен PMP (Project Management Professional)"
      Наши контакты


      Заказать звонок
      info@pmjournal.ru
      Москва, Пресненская набережная, 12
      © 2023 PMJournal.ru - управление проектами. Все права защищены.
      • Вконтакте
      • Facebook
      • Twitter
      • Instagram
      • Telegram
      0