Почему без гибридных методов управления проектами не обойтись?

В последний год все чаще слышишь от коллег и клиентов, что Agile (включая Scrum) в чистом виде не взлетел в их организации или на проекте. Конечно же можно списывать все на непонимание, незнание или неумение тех, кто применяет эти подходы, но на самом деле проблема несколько глубже.

Agile методы не универсальны. Существует обширный класс задач, такие как реализация социальных, культурных, консалтинговых, бизнес-ИТ проектов или даже ремонта в собственной квартире, для которых буквальное применение упомянутых методов — зло.

И как бы мне не был симпатичен Agile/Scrum, анализируя опыт последний консалтинговых проектов (проектирование и внедрение процессов управления, внедрение ИТ-решений, диагностика организации), я в очередной раз убедился, что не могу управлять проектом, смотря вперед на длину одного спринта (2-4 недели) и не видя всей длительности проекта.

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

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

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

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

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

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

При этом часто классическое управление проектами (а-ля Prince2, PMBoK) дает сбой в том числе из-за сверхуверенности заказчиков или руководителей проекта, которые убеждены, что составленный в начале планы проектов и требования к результатам — закон, а отчетность, эскалации и управление изменениями позволят сохранить контроль над ситуацией. К сожалению, и этот подход для сложных проектов не срабатывает.

Для упомянутых выше типов проектов подойдет гибридное управление проектами. Американский Институт Управления Проектами с 2015 года говорит о его появлении как о тренде, правда не уточняя, что именно имеет в виду. В 2019 году даже в России гибридные методу управления — один из наиболее актуальных трендов.

Для меня гибридное управление проектами — не что иное как прокачка методов классического управления проектами (а-ля PMBoK и Prince2) с помощью идей и практик Agile, различных управленческих инструментов.

При этом это системная, целостная и осознанная, а вовсе не произвольная их комбинация.

Вам может потребоваться гибридное управление проектами, если:

• необходимо временной и незрелой командой создать сложный продукт в амбициозный срок с заданным бюджетом, и при этом не жертвуя качеством.
• логические взаимосвязи между элементами продукта и хронологические — между блоками работ критически важны, и от них невозможно избавиться. То есть их необходимо учитывать при планировании и реализации проекта.
• продукт такого проекта невозможно технологически поставить в готовом или в пригодном к использованию виде за короткий срок — итерацию или спринт т.е. в течение 2-х-4-х недель (а попытка это сделать ведет к удлинению сроков производства, снижению ценности для клиента, увеличению бюджета). То же касается и последующих итераций создания продукта. Даже для создания «минимально ценной для клиента версии продукта» (MVP) требуется больше времени чем 1-2 итерации.
• требования определены частично, меняются и уточняются по ходу,
• команда проекта проясняет способ решения и требования к продукту проекта непосредственно в процессе реализации проекта методом проб и ошибок, так как заранее есть только смутная идея того, что и как будет делаться. В итоге для получения результата может потребоваться несколько итераций, а сроки будут отличаться от заранее ожидаемых.

Некоторое количество гибридных методов управления проектами уже представлено на рынке, хотя они пока еще не слишком известны (например, DSDM, Prince2 Agile, P3.Express), тем не менее большинство из них пока выглядит как довольно незрелые попытки решения указанных выше проблем.

Я отношу метод к гибридным, если он соответствует большинству критериев указанных ниже:

• Ориентируется на конечную ценность (материальную или нематериальную), а не только на создание продукта

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

• Учитывает проектные ограничения (сроки, стоимость)

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

• Вписывает проект в организационный контекст, а не фокусируются на работе одной команды

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

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

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

• Уточняет способ реализации проекта, необходимые работы и конкретные требования к продукту по ходу выполнения

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

Помогает управлять хронологическими взаимосвязями блоков работ

Беда многих Agile методов для решения наших задач — отказ от учета взаимосвязей между блоками работ. Мол команда сама разберется, что и в каком порядке делать. Все усилия направляются на то, чтобы организационно и технологически взаимосвязи убрать, сосредоточив все компетенции в одной выделенной команде. И действительно при создании ИТ-продуктов это иногда возможно. Но, во-первых, не всегда такую команду можно выделить, а во-вторых, часть взаимосвязей — не дефект организации, а особенность конкретного продукта и его производственного процесса. Такова ситуация, например, в проектах запусков новых товаров народного потребления на рынок. Есть, конечно, Less и SAFe, но они заточены исключительно на ИТ-проекты.

• Помогает управлять минимум на трех временных горизонтах: долгосрочный (от 3 до 12 месяцев), среднесрочный (до 3-х месяцев), краткосрочный (до недели).

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

• Поддерживает итерационный, а где возможно, и инкрементальный подход к созданию продукта

Итерационно-инкрементальная работа позволяет достичь трех основных плюсов:

1) постепенное и более осознанное уточнение требований с заказчиком

2) получение пригодного результата как можно раньше и, как следствие, получение эффекта от использования продукта

3) повышение уверенности заказчика в успехе проекта

• Делегирует большой объем полномочий команде, но не настаивают на самоорганизации

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

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

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

• Гибко адаптирует проект к вновь поступающим вводным и изменениям

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

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

Есть ли такие методы?

Ниже список методов и фреймворков управления проектами, которые я считаю гибридными:

• DSDM
• Prince2 Agile
• Spiral model
• P3.Express
• Last Planner System
• Water-Scrum-Fall
• Adaptive Project Framework

Но на мой взгляд, все они содержат ряд недостатков, которые я планирую преодолеть в методе, который разрабатываю сам под названием Парацельс ПиЭМ. C ним вы можете ознакомиться в ближайшее время. Ждите анонсов.