Преимущества hybrid model

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

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

В этой статье мы поговорим о том, как использование гибридного подхода позволяет решить некоторые проблемы, и отметим его преимущества:

  1. Возможность быстро реагировать на изменения. Популярность Agile подходов во много обусловлена возможностью быстро вносить корректировки в scope и приоритеты проекта. Используя гибридную модель, вы можете сохранить гибкость и адаптивность к изменениям, добавить к этому более детальную оценку сроков и стоимости, проработку рисков и анализ заинтересованных сторон.
  2. Выбор подходящих инструментов для проектных команд. Большинство офисов управления проектами ранее строились на унифицированных процессах. Однако одним командам требуется гибкость и вариативность, другим нужно с минимальными затратами обеспечить получение конкретного итогового продукта. Гибридный подход предоставляет проектным командам возможность выбирать инструменты для достижения результата.
  3. Возможность принимать более точные и взвешенные решения. Управлять портфелем проектов сложно. Постоянно существует риск, что более приоритетные проекты останутся без ресурсов, экспертной поддержки, решения не будут приняты вовремя. Чтобы максимально эффективного перераспределить ресурсы на уровне портфеля проектов, важно собрать в одном месте всю информацию по проектам и их сравнительные характеристики. Прозрачность информации по проектам позволяет избегать конфликтов, когда одни и те же ресурсы одновременно выделяются на два разных проекта. Гибридная модель с поддерживающими ИТ-инструментами объединяет все проекты в один портфель, чтобы вы могли принимать своевременные решения в условиях постоянных изменений.
  4. Разумное следование процедурам. Стандартизированные процессы более экономны для компании, чем постоянно меняющиеся экшен-планы по проектам. Офис управления проектами отвечает за анализ хода реализации проектов. Там, где это возможно, необходимо создавать стандартизованные процедуры, которыми смогут пользоваться различные проектные команды.
  5. Возможность перемещения ресурсов между командами. Сотрудники проектных команд, которые знают специфику использования различных инструментов, становятся более универсальными ресурсами. Их можно перемещать между проектами, когда в команде не хватает людей из-за болезни, увольнения или необходимо нарастить результативность.
  6. Высокопродуктивные команды. Когда у команды есть общая картина портфеля проектов, совместные цели, единая система отчетности и автономность в выборе инструментов, производительность и отдача от сотрудников качественно возрастают. Это на порядок повышает мотивацию команды и желание добиться намеченного результата.

В зависимости от цели мы можем комбинировать разные походы к управлению проектами: PRINCE2, PMBOK, Scrum, Kanban и другие.

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

  
Поделитесь с друзьями

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

Гибридные практики (hybrid) – (не)новый подход к управлению проектами
Гибридные практики (hybrid) – (не)новый подход к управлению ...
Выбор неправильной методологии управления проектом может стать одной из причин того, что проект потерпел неудачу. С другой стороны, не существует единой методологии, которая подходит для всех проектов. Более того, даже в одном проекте использование одной методологии на разных этапах его жизненного цикла будет снижать эффективность достижения результата и взаимопонимание между проектной командой и заказчиком. Так возникла идея использовать разные подходы в рамках одного проекта. Такая методология получила название гибридной (hybrid). Гибридная методология подразумевает, что в компании используют наиболее подходящие инструменты на разных этапах жизненного цикла и уровнях управления проектом. Например, этап планирования и сбора требований выполняется с использованием рекомендаций PMBOK, а на этапах проектирования, разработки и внедрения используется Scrum или Kanban. Такой подход позволяет собрать достаточно информации на старте проекта для оценки бюджета и сроков, а затем уже по мере реализации проекта учитывать корректировку требований и вносить уточнения в оценку сроков и стоимости. В итоге прогнозы бюджета и сроков для заказчика будут более точными. Поставка результатов проекта осуществляется поэтапно. Это дает возможность сверяться с ожиданиями заказчика, получать от него обратную связь и более гибко реагировать на изменения рынка. Недавний отчет PMI показывает рост объема ИТ-проектов, выполняемых с использованием гибридных подходов. Ограничение оказывается в том, что команды и отдельно взятые сотрудники часто не готовы менять привычные методы работы. В этой ситуации важна поддержка со стороны топ-менеджмента и HR-специалистов – повести сотрудников за собой и стать лидерами изменений. Читать далее 
Agile: революция или… эволюция?
Agile: революция или… эволюция?
На тренингах по управлению проектами и управлению бизнес-процессами нам часто задают вопросы об agile-практиках и их безальтернативности в современном быстроменяющемся мире. Мы подробно рассказываем о преимуществах и ограничениях agile. И даже идем дальше: показываем, как проекты и процессы дополняют друг друга и почему agile-практики хорошо применимы для оптимизации бизнес-процессов. Давайте попробуем исторически проследить, почему agile-практики близки к процессному управлению и какие концепции предшествовали их появлению. Появление Agile В 2001 году группа разработчиков программного обеспечения (ПО) собралась в г. Юта (США), чтобы предложить новую методологию управления проектами по разработке ПО в противовес классическим «бюрократическим и тяжеловесным» подходам. Прийти к консенсусу по методологии не удалось, зато появился «Agile-манифест», который позиционировался как радикально новый подход к управлению проектами. С легкой руки Кена Швабера (Ken Schwaber) Agile начинают называть революцией в управлении проектами. Идеи, которые легли в основу Agile-манифеста, появились задолго до 2001 года. Обратимся к истории (см. рис. 1). Рис. 1. PM/BPM Timeline Фредерик встретил Генри Корни Agile уходят в 1878 год, когда Фредерик Тейлор (Frederick Taylor) представил теорию «Научного менеджмента». Тейлора ассоциируют со стандартизацией труда на производстве и повышением производительности бизнес-процессов. Однако его вклад в развитие инструментов управления проектами и процессами этим не ограничивается. Дело в том, что в 1887г. Фредерик Тейлор нанял помощником Генри Гантта (Henry Gantt), который в начале 20 века предложил знакомый многим способ визуализации план-графика проекта (см. рис.2). Спустя 100 лет диаграмма Гантта все еще остается популярным инструментом среди руководителей проектов. Рис.2 Диаграмма Гантта Рождение Lean и итеративных практик Труды Тейлора дали толчок дальнейшему изучению бизнес-процессов. Фрэнк и Лилиан Гилбрет (Frank and Lilian Gilbreth) в 1921г. предложили использовать диаграммы процесса (process charts) для его визуализации, анализа и усовершенствования. В основе их рекомендаций по оптимизации лежали: стандартизация процесса, устранение потерь (waste) и упрощение работы сотрудников. В 1930г. Лилиан Гилбрет презентовала способ визуализации потока работ с помощью инструмента, известного сегодня как Kanban-доска: «We had three rows of hooks, one marked “Jobs to be done”, one marked “Jobs being done” and a third marked ”Jobs completed” with tags which were moved from hook to hook to indicate the progress of the task. (Источник: 1930 Speech by Lillian Gilbreth to National Federation of Business and Professional Women’s Clubs in New York)». Рис.3 Kanban-доска Спустя некоторое время, после завершения второй мировой войны, в 1950 году на встрече с японским сообществом ученых и инженеров доктор Эдвардс Деминг (Edwards W. Deming) представил идеи статистического контроля процесса (Statistical Process Control) и цикла PDCA (Plan-Do-Check-Act). Цикл PDCA подразумевает итеративную работу над улучшением бизнес-процесса: начинается все с планирования, затем следует реализация инициатив по улучшению, проверка полученных результатов и решение о дальнейших действиях на следующей итерации. Наиболее популярный agile-фреймворк Scrum предлагает фактически аналогичный подход к организации работы проектной команды (рис 4). Использование agile-практик в проектах по оптимизации бизнес-процессов получается столь органичным именно потому, что agile является эволюцией цикла PDCA. Рис.4 Two-week sprint Киичиро Тойода (Kiichiro Toyoda) познакомился с работами Гилбретов в 1929 году во время поездки в США и Европу. В 50-х годах компания Тойота стала пионером в адаптации идей Гилбретов и Деминга. Производственная система Тойота (Toyota Production System) вобрала в себя идеи стандартизации работы, устранения потерь, непрерывного совершенствования по итеративному принципу, канбан и проч. На волне роста интереса к японским автопроизводителям в 80-х годах в США появился термин Lean Production (бережливое производство). Lean — маркетинговое название принципов производственной системы Тойота. Подход быстро набрал популярность, и вскоре появились адаптации Lean для других отраслей. Концепция Lean software development стала одной из первых agile-методологий по разработке программного обеспечения. В это же время в Японии развивались фабрики разработки ПО (Software factories). По мере ослабления барьеров в торговле и глобализации бизнеса приходилось адаптировать практики параллельной разработки для географически распределенных команд. Идеи устранения потерь (elimination of waste), стандартизации ролей и упрощения процесса добрались до самой прогрессивной на сегодняшний день отрасли спустя 60 лет после возникновения. «Железный» треугольник, инкрементальные и итеративные практики Давайте вернемся к «классическому» управлению проектами и вспомним диаграммы процессов Гилбретов. Именно их компания DuPont адаптировала и положила в основу своего Critical Path Method (CPM). Диаграмма Гантта, критический путь и «железный» треугольник стали популярными инструментами руководителей проектов в 60-х годов прошлого века. Спустя 40 лет идею треугольника стали использовать последователи agile для пояснения отличий классического управления проектами и agile-практик (см. рис. 5).   Рис. 5. Agile-подход В 60-х годах прозвучали первые упоминания об инкрементальных и итеративных практиках управления проектами. Впервые это произошло в проекте Меркурий, который реализовала NASA в 1958-1963 гг. Чуть позже, с 1968 года, началась адаптация итеративных практик под проекты разработки ПО. Через некоторое время итеративные практики включили в фреймворк PROMPT (прообраз современного PRINCE2) и руководство PMBOK (упоминается как спиральный жизненный цикл проекта, spiral project lifecycle). С нашей точки зрения, концепция Agile стала закономерным продолжением эволюции подходов, которые использовались ранее, например, в проектах по разработке ПО и оптимизации бизнес-процессов. История показывает, что бОльшего успеха добиваются те компании, которые комбинируют разные инструменты и методологии в зависимости от специфики проекта и контекста, в котором он реализуется. Судя по всему, в скором будущем agile-практики также будут эволюционировать и в управлении проектами появятся новые «революционные» идеи.   При подготовке статьи использовались материалы: McKenna T, Whitty SJ. (2013) Agile is Not the End-Game of Project Management Methodologies. In: Proceedings of the Annual Project Management Australia Conference Incorporating the PMI Australia National Conference (PMOz), Melbourne, 17‐18 September 2013.   Читать далее