Матрица отвественности

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

Традиционные подходы и рекомендации

В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI». В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ.

Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).

Пример матрицы RACI из Руководства PMBOK

В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР – с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций.

Российскую практику проектирования часто отличает расширение вариантов ответственности вплоть до включения в МО также и полномочий. Это вносит разбалансировку в матрицу. Иллюстрацию такого подхода вы можете увидеть ниже.

Пример матрицы ответственности инвестиционного проекта на территории России

Подзадачи и ответственность

Предыдущий пример наглядно демонстрирует ситуацию размытия фокусов на ответственности. Как избежать подобной ситуации? Вспомним, коллеги, подраздел, посвященный задачам управления. В нем мы разобрали важную категорию управления – «ответственность». Тогда мы установили, что ответственность ресурса предполагает его право принять и обязанность выполнить задачу, не ссылаясь ни на какие препятствия. Позвольте напомнить пример красноярского охотника, который взялся за задачу доставить к сроку шкурки белок, битых в глаз, но под условием, что число их будет не более 45 вместо 100. Об этом говорит сайт https://intellect.icu . Таково было его правило: браться только за то, что он способен сделать реально.

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

Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления:

• разработка ТЗ;
• развертывание прототипа системы;
• опытная эксплуатация и т.п.

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

Схема декомпозиции проектной задачи по внедрению продукта Y

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

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

Вариант упрощенной матрицы ответственности

Ответственность и полномочия: как избежать ошибок?

Считаю, что особенно начинающим PM нужно научиться заполнять упрощенную матрицу и обеспечить ее работоспособность и контроль, а затем переходить к более сложным конфигурациям, избегая при этом типовых ошибок, которые иногда случаются. Независимо от числа вариантов ответственности (букв, применяемых в таблице для ее заполнения), следует руководствоваться определенными правилами заполнения. Построение МО проекта требует соблюдения важных правил:

1. Работать над МО всей командой, стараясь заполнить ее в единственную сессию.
2. Сначала заполнять все ячейки с ответственностью, исключить ситуацию, когда остаются строки без символа «О».
3. Придерживаться методики RACI, избегая расширения состава полномочий из разряда «Исполнитель», «Согласование», которые, по сути, не несут в содержании ответственности.
4. Исключить ситуацию пустых столбцов в МО.
5. Составить несколько вариантов МО, начиная с верхнего уровня и соблюдая принцип лаконичности.

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

1. Допустить ситуацию, когда в одной ячейке проставлено два символа.
2. Перегрузить МО символами, тем самым девальвируя ее работопригодность.
3. После утверждения МО «положить ее под сукно» и забыть, тем самым исключив смысл применения МО в качестве инструмента прямого контроля промежуточных результатов и спроса с ответственных ресурсов по задачам проекта.

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

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

Прежде всего, за все происходящее в проекте отвечает один человек - руководитель проекта. Но, поскольку задач в проекте много, а руководитель - один, ему приходится делегировать ответственность за отдельные задачи и группы задач другим членам команды. 

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

Степеней ответственности может быть много. Например, РМВОК определяет 4 вида ответственности:

1. Ответственный (О)- полностью отвечает за выполнение задачи и вправе принимать решения по способу ее реализации

2. Исполнитель (И) - исполняет задачу, но в обшем случае, не несет ответственности за способ ее решения.

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

4. Наблюдатель (Н) - то же самое что и консультант, но ответственности не несет.

Матрица ответственности выглядит таким образом:

Обратите внимание, что для каждой задачи роль "Ответственный" существует обязательно и в единственном экземпляре, в соответствии с поговоркой "Если за что-то отвечает более одного человека - виноватых не найти". Остальных ролей может не быть (за исключением "Исполнителя", конечно), или они могут дублироваться.

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

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