Впихнуть невпихуемое или 8 причин, почему ваши регламенты по управлению проектами не работают

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

Сегодня поговорим о типовых ошибках при составлении регламентов, которые приводят к тому, что:

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

Регламент не отвечает на вопросы, начинающиеся с «как» – для этого существуют инструкции, чек-листы, материалы обучения или методики.

Ниже разбираем типовые ошибки, которые превращают ваши регламенты в бесполезную макулатуру.

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

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

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

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

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

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

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

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

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

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

Чтобы сформировать единые ожидания, в какой момент потребуется тот или иной инструмент, я рекомендую делить проект согласно технологическому жизненному циклу продукта (делению проекта на этапы его создания). Например, для девелоперского проекта это будут: разработка концепции, разработка проектно-сметной документации, строительство и т.д. А для ИТ-проекта жизненный цикл будет состоять из обследования, разработки, архитектуры, разработки первой версии mvp, последующих релизов.

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

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

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

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

Для разделения на обязательные и необязательные артефакты формируйте условия: например, реестр стейкхолдеров является обязательным артефактом, если в нем указано более трех заинтересованных лиц, или реестр рисков будет обязательным, если он делается для проекта стоимостью от 10 млн рублей.

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

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

А как у вас с регламентами в компании? Какие трудности возникают?

Подписывайтесь на мой телеграм канал t.me/UzhiEzh, чтобы получать ещё больше полезного контента о самых эффективных методах, инструментах и практиках в управлении проектами.