Гибридные практики (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.   Читать далее 
Lviv PM Day 2018 и два выступления от Дмитрия Лукьянова
Lviv PM Day 2018 и два выступления от Дмитрия Лукьянова
10 ноября 2018 года во Львове состоялась конференция PM Day Lviv 2018. PM Day Lviv завершил серию "PM Day", которая ежегодно проходит в Одессе, Харькове, Львове и Киеве. Управляющий партнер «Бюро проектного менеджмента» Дмитрий Лукьянов порадовал сразу двумя выступлениями. В потоке "Agile и гибкие методологии" он презентовал тему ”«Исторический след» в японской методологии управления проектами: от «Книги пяти колец» до стандарта «Р2М»”. Дмитрий провел аналогии между "Путем воина" и "Путем проектного менеджера" с учетом ценностей Scrum и каждой из "Пяти книг" М. Мусаси: книг "Земли", "Воды", "Огня", "Ветра" и "Пустоты". В потоке "Product Management" обсудили “Откуда берутся Product Owner`ы – ими рождаются или становятся?”. Дмитрий провел интерактивное исследование. В итоге совместной работы с участниками получились профили "Владельца Продукта" и "Руководителя Проекта" по модели PAEI Адизеса. А также родилось общее видение того, как изменяется ролевая модель команды по Белбину с учетом тренда на диджитализацию. Напомним постулат Ицхака Адизеса о том, что не существует "идеального менеджера", у которого все четыре роли - P, A, E и I - представлены на одинаково высоком уровне. Дмитрий предложил разложить профили "Владельца Продукта" и "Руководителя Проекта" и посмотреть, как они взаимно сочетаются. У участников сессии родилась "идеальная пара" - модель PaEi "Владельца Продукта" отлично дополняется моделью pAeI "Руководителя Проекта". Так сам собой решился и один из вопросов дискуссии - насколько хороша идея совмещать эти две роли в одном человеке, а также и вопрос о том, можно ли ожидать успешной трансформации PM'а в PO'а и наоборот. Рекомендации Дмитрия: Давать сотрудникам те роли, к которым они естественно предрасположены. На разных этапах жизненного цикла в организации востребованы разные типы менеджеров. Необходимо учитывать специфику организации и типы ведущихся проектов. Использовать несколько методик в определении ролевых предпочтений, рассматривать команду под разными углами. Хорошо зарекомендовала себя на практике методика М.Белбина. Табл.1 Функции и роли менеджмента, жизненный цикл организации Источник Презентации можно найти здесь: Японская методология и ценности Srum Product Owner Читать далее 
Digital Transformation: чек-лист для успешных преобразований
Digital Transformation: чек-лист для успешных преобразований
Как мы писали ранее, цифровая трансформация (digital transformation) организаций неизбежна. Точки приложения усилий на этом пути разнообразны: BI-аналитика, омниканальное продвижение и коммуникация, управление опытом сотрудников (employee experience management), BPMS-платформы, новые продукты. Процесс цифровой трансформации уникален для каждой организации. Мы выделили шесть составляющих, на которые следует обратить особое внимание при подготовке к реализации цифровых изменений. Используйте этот список в качестве чек-листа перед стартом проекта. [caption id="attachment_2979" align="aligncenter" width="493"] Рис.1. Digital-transformation, чек-лист[/caption] 1. Создайте общее видение Прежде чем приступать к цифровой трансформации, сформулируйте потребность в изменениях. Компания, сотрудники которой считают, что изменения не нужны, вряд ли преуспеет в инновациях и новых подходах к привлечению клиентов Заручитесь поддержкой ключевых заинтересованных сторон на этапе выбора инициатив для трансформации Составьте четкий план реализации инициатив (с детализацией текущего состояния и конечного результата). Это позволит скоординировать усилия сотрудников и минимизировать потенциальные риски 2. Сформируйте совместные команды из представителей бизнеса и ИТ Включите в проектные команды специалистов с глубоким пониманием бизнеса (различных его функций) и умеющих слушать и слышать ИТ визионеров. Проблема в коммуникации между бизнесом и ИТ по-прежнему остается актуальной Обеспечьте среду, в которой ИТ-специалисты обучают представителей бизнеса современным ИТ-технологиям, а представители бизнеса доносят ИТ-специалистам потребности клиентов, их «точки боли», а также действия конкурентов. Включите взаимное обучение в свой фокус внимание Используйте общий язык в виде моделей бизнес-процессов и единую терминологию. Это укрепит взаимопонимание между бизнесом и ИТ. 3. Выберите подходящую технологию через реализацию пилотных проектов Запускайте пилотные проекты и быстро тестируйте новые технологии Обеспечьте оперативное внесение изменений в существующие ИТ-решения. Скорость реализации проектов выходит на первый план Используйте бимодальную ИТ-инфраструктуру (например, ERP-система и BPMS-система). Это позволит интегрировать различные технологии между собой и станет основой для быстрых изменений 4. Регулярно проводите мониторинг новых технологий На регулярной основе осуществляйте мониторинг ключевых инновационных технологий. Задавайте себе вопрос: «Как мы можем применить данную технологию в своем бизнесе?» Выберите доступные и актуальные для вас технологии (см. рис.2), встраивайте их постепенно в бизнес-процессы компании При адаптации новых технологий для вашей компании максимально используйте уже имеющуюся у вас инфраструктуру (hard&software) [caption id="attachment_2969" align="aligncenter" width="600"] Рис.2 Industry 4.0 framework (Источник: 2016 Global Industry 4.0 Survey)[/caption]  5. Измеряйте показатели успеха Измеряйте экономический эффект от реализации проектов. Внедрение новых технологий не должно быть самоцелью Для последующей оценки результатов проекта используйте измеримые индикаторы эффективности. Достижение этих показателей будет стимулировать всю проектную команду двигаться вперед Наметьте измеримые ориентиры на пути цифровой трансформации. Отслеживайте по ним правильность движения на пути к цели. 6. Уделите внимание выбору подходящей ИТ-платформы, которая станет основой для будущих инноваций Найдите ИТ-платформу, которая обеспечит интеграцию между существующими системами, а также позволит дополнить и расширить их новыми функциями Выберите системного интегратора, который поможет осуществить внедрение и интеграцию между системами Убедитесь, что новая ИТ-платформа обеспечит надежность и динамичное развитие в будущем. Читать далее