Прожектёрству — бой! (Не)сбыточные мечты руководителя проектного офиса

Путь в тысячу лье

Чтобы нивелировать эту фундаментальную проблему существует несколько методологических решений: от гейтовой модели управления (она же управление по контрольным точкам) в классических водопадных системах до синхронизации релизных эшелонов (release trains) через активаторы (enablers) в Scaled Agile Framework. Идея очень простая — во всех проектах определяют обязательные ключевые события. Они должны быть привязаны к конкретным артефактам проектной деятельности (акты выполненных работ, подписанные регламенты, распоряжения и т. п.), которые предъявляются как основание для приемки этого рубежа. Эти контрольные точки (КТ), результат совместного труда нескольких независимых команд, и вынуждают их эффективно сотрудничать на каждом таком стыке. Кроме того, довольно часто КТ и их артефакты являются активаторами для работы по другим проектам.

Управление по контрольным точкам: на каждом уровне менеджмента определяются свои КТ

SAFe 6.0: синхронизация релизных эшелонов через активаторы

Удар об реальность

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

Опираясь на лучшие практики из миров классического и гибкого менеджмента проектов, мы объединили управление по сквозным контрольным точкам и активаторы:

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

Для другого контрольная точка является активатором, при этом мы видим, что в обоих проектах есть сдвиг относительно согласованной КТ

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

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

Контрольные точки разного уровня (изначально их три: критическая КТ-0, ключевая КТ-1, оперативная КТ-2) могут быть распределены не только по иерархии руководящего состава, но и вовсе не нести иерархический смысл, например, можно ввести КТ-4 для финансовых служб, КТ-5 для службы информационной безопасности и т. д. Эти рубежи определяются на уровне конкретного объекта управления (портфеля, программы или проекта) и спускаются вниз по иерархии всем участникам процесса.

Верхи не могут, низы не хотят

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

Дорожки классической и гибкой методологий на этом этапе расходятся и предлагают следующее:

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

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

Ответственный исполнитель регулярно вносит количество потраченных трудовыми ресурсами (неавтоматизированными сотрудниками) часов на работу, разнося их по этапам

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

Для гибкой модели — в случае управления по Scrum приблизительно прогнозировать срок достижения помогают диаграмма сгорания количества тикетов-эпиков, до которых был декомпозирован этап плана, либо кумулятивная диаграмма потока если используется Канбан-метод:

Смысл у диаграмм примерно одинаковый — оценить текущую скорость уменьшения количества работ в бэклоге и попытаться аппроксимировать ее на оставшийся объем. Не стоит забывать, что последние 20% работ займут еще 80% времени, так что при прогнозировании лучше руководствоваться соответствующей степенной шкалой.

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

Эпилог

Мы не одни ищем пути простого, но эффективного управления портфелями проектов. Когнитивная нагрузка от лучших практик PMBoK сгубила немало бравых ребят. Видимо поэтому каждые пару лет появляются все новые и новые слова в лексиконе сертифицированных PMP (сейчас, например, модно приговаривать p3express). Но надо не забывать, что хоть в пятидесятый раз попытайся продать под разными названиями нам цикл Деминга-Шухарта (который скоро будет праздновать столетний юбилей, йу-ху аджайл-коучи), без прямого, как палка, и надежного, как молоток, инструмента, который находится в руках у всех участников проектной деятельности, они так и останутся только в воображении несчастного PM.

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

Изображение от Freepik.