что такое матрица ответственности проекта
Функции матрицы ответственности в проектном управлении
Когда мы определились с основными ролями в команде проекта, следует перейти к разработке весьма полезного документа, именуемого как матрица ответственности. Нам, уважаемый читатель, важно осознавать, что в ходе разработки матричной таблицы PM фиксирует комплекс не только ответственности членов группы, но и их полномочий. Предлагаю вам разобраться в этой теме подробнее.
Традиционные подходы и рекомендации
В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI». В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ.
Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).
В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР – с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций.
Российскую практику проектирования часто отличает расширение вариантов ответственности вплоть до включения в МО также и полномочий. Это вносит разбалансировку в матрицу. Иллюстрацию такого подхода вы можете увидеть ниже.
Подзадачи и ответственность
Предыдущий пример наглядно демонстрирует ситуацию размытия фокусов на ответственности. Как избежать подобной ситуации? Вспомним, коллеги, подраздел, посвященный задачам управления. В нем мы разобрали важную категорию управления – «ответственность». Тогда мы установили, что ответственность ресурса предполагает его право принять и обязанность выполнить задачу, не ссылаясь ни на какие препятствия. Позвольте напомнить пример красноярского охотника, который взялся за задачу доставить к сроку шкурки белок, битых в глаз, но под условием, что число их будет не более 45 вместо 100. Таково было его правило: браться только за то, что он способен сделать реально.
Ответственным ресурсом уникальной проектной задачи выступает менеджер. В момент планирования проекта его руководитель обязан обеспечить декомпозицию результата на подзадачи, последовательное выполнение которых автоматически приводит к решению ключевой задачи. Такую декомпозицию целесообразно производить коллегиально, привлекая членов команды управления проектом к работе методом мозгового штурма. Результатами его должны явиться иерархическая структура работ, план по вехам.
Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления:
Гораздо действеннее получается, если применять методы управления от задач. Предлагаю вашему вниманию пример такой декомпозиции.
Данный пример показателен. Естественно, что за задачу верхнего уровня отвечает менеджер. И очевидно, что управление проектом устанавливает разделение ответственности по декомпозированным подзадачам между членами команды. Таким образом, закономерно созревает логика составления такой таблицы, как матрица ответственности. Ее построение начинается с формулирования задач.
Лично мне импонирует лаконичный подход к применению матричной модели, потому что обязательность как синоним предмета нашего исследования – это еще и состояние человека: либо она есть, либо ее нет. И самое главное, такое состояние не может быть распределено между несколькими людьми. В целях управления оно может иметь только единственного носителя. В противном случае, ответственность в той или иной степени утрачивается. Наш пример декомпозиции диктует следующую форму матрицы.
Ответственность и полномочия: как избежать ошибок?
Считаю, что особенно начинающим PM нужно научиться заполнять упрощенную матрицу и обеспечить ее работоспособность и контроль, а затем переходить к более сложным конфигурациям, избегая при этом типовых ошибок, которые иногда случаются. Независимо от числа вариантов ответственности (букв, применяемых в таблице для ее заполнения), следует руководствоваться определенными правилами заполнения. Построение МО проекта требует соблюдения важных правил:
Если не учитывать специальных правил, изложенных выше, легко допустить ошибки, которые потом ухудшат возможности контроля, снизят эффективность управления проектом. Чтобы избежать такой ситуации, лучше сразу в ходе работы над МО, контролировать себя на возможность ошибиться. Построение МО может сопровождаться типичными ошибками:
В данной статье, уважаемые коллеги, мы вместе с вами рассмотрели вопрос о понятии, сути и содержании матрицы ответственности как существенном элементе планирования и реализации проекта. Представлены традиционные методология и примеры построения МО. Заявлена авторская позиция о пользе более категоричного подхода к ответственности и ее распределении. Уточнены правила разработки МО и сопутствующие ошибки.
Я убежден, что менеджер проекта, который руководствуется при распределении ответственности правилом «Лучше меньше, да лучше» более успешен. Это происходит также благодаря тому, что построение МО реализуется в режиме однозначности. Поэтому каждому PM я советую начинать с более простых форм, постепенно усложняя практику применения.
Матрица распределения ответственности или RACI матрица – что это и зачем нужно
Еще один пост для начинающих РМов про нужный и полезный инструмент – RACI матрицу.
Что такое матрица распределения ответственности или RACI матрица?
RACI матрица – простой и удобный инструмент для наглядного отображения распределения полномочий и ответственности в рамках проекта или бизнес-процесса. Чаще всего RACI матрица представляет собой табличку, где по вертикали расположены задачи или конкретные результаты, ожидаемые в ходе проекта, а по горизонтали – конкретные люди или роли (роли, конечно, предпочтительнее).
Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.
Расшифровка RACI:
Пример матрицы распределения ответственности
Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):
Непонятно, правда, зачем тут безответственный кот, но ладно, пусть будет. Ну и в матрице – имена, а не роли, что вполне ок для проекта масштаба семьи.
А вот более “корпоративный” пример:
Тут, как вы видите, приведены уже роли, а не люди, плюс используется цветовая кодировка (что лишнее, как по мне).
Как и где используется матрица распределения ответственности?
RACI матрица удобна в первую очередь тем, что ею пользуется весь мир, и на любом международном проекте при разговоре про роли все сразу поймут, что вы имеете ввиду.
Итак, где может быть полезна матрица распределения ответственности?
Разработка матрицы распределения ответственности
Построить RACI матрицу несложно, все, что нужно, это:
Делать все это, конечно, стоит с командой, а не в гордом одиночестве, чтобы потом не удивляться, что ваша идеальная картина мира не совпала с реальностью.
Поздравляю, ваша матрица распределения ответственности готова!
Само составление – примитивнее некуда, а вот согласование – гораздо интереснее. Тут же начинается политика и прочие замечательные вещи, поэтому при разработке RACI матрицы стоит эту перспективу сразу учитывать.
Другие виды матрицы распределения ответственности
В сети можно найти много вариантов на тему, а в книжках – еще больше (многие авторы грешат тем, что приписывают еще какую-нибудь букву и выдают это за обалдеть какой результат многолетней работы или невероятного опыта).
Как всегда, ничего лучше классики не придумано, но если вдруг именно в вашем проекте или в бизнес-процессе еще какой-то разрез ответственности ну совершенно необходим – не теряйтесь и просто добавляйте нужную букву. Ну потому что, как и все остальное в проектном управлении, RACI матрица – это инструмент для вас, а не вы для него.
Вот такие варианты можно встретить чаще всего:
Еще есть куча вариантов с другими буквами и проч., но концепция остается все той же.
Основные ошибки при построении матрицы распределения ответственности
Вариантов “как из RACI матрицы сделать бессмысленную бумажку” много, но вот самые частые и поэтому самые любимые:
Ну вот, наверное и все. Вроде бы простая вещь, но без нее намного хуже, чем с ней, честное слово.
Используете RACI матрицу у себя? Расскажите!
Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.
Если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!
А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!
Планирование человеческих ресурсов проекта
Определение ролей проекта
При распределении ролей и ответственности, необходимых для выполнения проекта, следует учитывать следующие моменты.
Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.
Бизнес- менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта ( руководитель проекта ) отвечает как за успехи, так и за неудачи проекта. В его задачи входит управление сроками, стоимостью, качеством работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя.
Команда управления проектом включает координатора проекта, администратора проекта, менеджера по конфигурации. Для крупных проектов к выполнению каждой из этих ролей могут быть привлечено нескольких человек. На небольших проектах менеджер проекта может совмещать несколько ролей. Масштабные проекты предполагают наличие менеджера по качеству, который ответственен перед бизнес-менеджером исполнителя.
В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].
Приведенный список ключевых ролей команды управления проектом является необходимым для управления работами при внедрении информационной системы. Возможны некоторые модификации состава команды в зависимости от сложности и масштабности проекта, например, при необходимости можно включать в нее заместителя руководителя проекта, руководителей функциональных направлений (финансы, логистика, персонал и т. д.).
Состав команды управления должен быть достаточным, чтобы осуществлять [11]:
На стадии планирования в рамках процесса управления человеческими ресурсами не предусматривается долгосрочное планирование, а составляется план для реализации первого этапа проекта. Основными задачами являются разработка организационной структуры проекта и подбор персонала.
Работа по планированию организационной структуры проводится менеджером проекта со стороны исполнителя совместно с менеджером со стороны заказчика. Путем переговоров достигается соглашение об уровне, на котором должно производиться утверждение выделяемых ресурсов заказчика и обсуждение требований к членам команды исполнителя. Администратор проекта фиксирует результаты переговоров.
Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта.
Матрица ответственности проекта
Построение матрицы ответственности
По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР ), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.
С помощью кодов в ячейках на пересечении соответствующих столбцов с ролями и строк с работами проекта указать степень участия, формальные полномочия и распределение ответственности за выполнение каждой операции. Четкое указание разных уровней формальных полномочий бывает особенно полезно в ситуации, когда множество членов проектной команды желает предъявить особые требования к проекту.
| Обозначение | Расшифровка | Описание |
|---|---|---|
| Исп. (R) | Исполнитель (Responsible) | Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя |
| Утв. (A) | Утверждающий (Accountable) | Отвечает за конечный результат перед вышестоящим руководством. На каждую работу должен быть назначен строго один подотчетный |
| Cогл. (C) | Согласующий (Consulted) | Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер |
| Н. (I) | Наблюдатель (Informed) | Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер |
| Функциональные обязанности | Куратор проекта (Спонсор) | Руководитель проекта | Архитектор системы | Администратор проекта | |||||
|---|---|---|---|---|---|---|---|---|---|
| Планирование | |||||||||
| Разработка и периодическая актуализация плана | + | + | |||||||
| Утверждение плана | + | ||||||||
| Управление командой проекта | |||||||||
| Назначение сотрудника на роль Руководителя проекта | + | ||||||||
| Формирование команды проекта | + | ||||||||
| Определение квалификационных требова ний и состава рабочих групп специалистов по функциональности ИС | + | ||||||||
| Обеспечение выделения необходимых ресурсов для выполнения проекта | + | ||||||||
| Непосредственное руководство Командой проекта | + | ||||||||
| Формирование предложений по стимулированию Команды проекта | + | ||||||||
| Обеспечение стимулирования Команды проекта | + | ||||||||
| Организация выполнения работ | |||||||||
| Организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта | + | ||||||||
| Организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта | + | ||||||||
| Организация, проведение и документирование процедур передачи Заказчику разработанной ИС | + | + | |||||||
| Рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта | + | ||||||||
| Ведение организационно-распорядительной и отчетной документации. Поддержание в актуальном состоянии списка команды проекта | + | ||||||||
| Обеспечение команды проекта необходимыми информационными материалами | + | ||||||||
| Материально-техническое и хозяйственное обеспечение команды проекта | + | ||||||||
| Контроль хода выполнения проекта | |||||||||
| Организация и проведение совещаний по обсуждению хода работ проекта | + | ||||||||
| Подготовка и предоставление Куратору отчетов о ходе работ проекта | + | ||||||||
| Получение и анализ сводной отчетности о ходе реализации проекта | + | ||||||||
| Контроль соответствия результатов проекта Техническому заданию на разработку ИС | + | ||||||||
| Согласование фактических трудозатрат специалистов при исполнении проекта | + | + |
После утверждения матрицы ответственности все дальнейшие изменения в ней должны проходить через процедуру интегрированного управления изменениями при участии авторов первоначальной версии.
Преимущество использования структурированного подхода к изменению матрицы ответственности состоит в том, что руководитель проекта получает актуальный документ, на который он может ссылаться при возникновении тех или иных спорных ситуаций, касающихся распределения полномочий в проекте.
В частности, матрица ответственности может быть использована для распределения основных функциональных обязанностей. Так, в табл. 6.2 в левом столбце перечислены функциональные обязанности, соответствующие проектным работам, список которых составлен на основе используемой методологии и накопленного проектного опыта, а в правую часть таблицы вносится отметка о степени ответственности и участия каждого из члена группы управления проектом в исполнении соответствующей функции.
Развитие матриц ответственности от RACI к РАЗУ
Сегодня вряд ли можно представить любой проект без использования матрицы ответственности, и это естественно. История применения инструмента насчитывает чуть более полувека. Довольно приличный срок, чтобы аналитическая таблица МО прочно утвердилась в качестве управленческого стандарта. Базовым методом считается матрица ответственности по методу RACI. Традиционный подход и рекомендации данного метода были рассмотрены ранее. Однако помимо RACI в современной практике возникли новые разновидности матриц, и они как средства управления значительно ушли вперед. С этих позиций представляет интерес матрица РАЗУ, с которой и приглашаю вас познакомиться в итоге.
Классический способ построения матрицы
МО применяется в различных доктринах управления: функциональной, процессной и проектной. Проектное управление предъявляет к процедурам использования матриц особые требования. Для построения их применяется табличная форма, в ее строках указываются операции, работы, этапы и даже фазы проекта, а в столбцах – роли в проекте, функциональные должности, подразделения и т.п. В матричных ячейках проставляются крестики или условные знаки, обозначающие вид ответственности.
Как было отмечено, для разработки МО традиционно используется методика RAСI: Responsible (отвечает), Accountable (утверждает), Consult before doing (консультирует), Inform after doing (информируется). Модель RACI широко распространена в проектной деятельности. Более того, эта форма рекомендована руководством PMBOK в качестве матричных диаграмм.
Данный подход, на мой взгляд, вполне лаконичен в силу того, что здесь отсутствуют такие условные знаки, как «исполнитель» и «ознакомлен», ответственность которых установить крайне затруднительно. Впрочем, и для «консультирует» также непросто определить ответственность, но все-таки это возможно. Поэтому считаю RACI наиболее уравновешенной среди аналогичных МО. Ниже представлен пример такой матрицы.
Методика RACI предполагает, что перед заполнением МО созданная команда управления проектом разработала иерархическую структуру работ, расписала проектные роли по участникам команды. На отдельном заседании производится разработка таблицы, после чего готовая матрица подвергается перекрестному анализу по следующему составу вопросов:
Типовые матрицы и их разновидности
Модель одноранговой МО, где присутствует только знаки «R» или крестики, фиксирующие ответственность члена команды, имеет ценное преимущество перед остальными типами. Такая матрица – самая рабочая и легкая в применении для контроля результатов. То, что нельзя увидеть глубину участия других членов, на мой взгляд, к недостаткам отнести нельзя, потому что если применить и другие условные знаки, в геометрической прогрессии нарастают вопросы, на которые ответить непросто. Ниже приведен пример такой простой МО.
В некоторых случаях матрица ответственности наглядно представляется в форме изометрической композиции (трехмерного графика). 3D-направление набирает популярность и в проектном управлении. Такой вариант МО предоставляет руководству компании возможность быстро сравнить глубину участия в проекте функциональных подразделений, задействованных в разных видах деятельности компании. Пример матричной трехмерной изометрии дан на следующем рисунке.
МО в модели RACI в определенных случаях рекомендуется разрабатывать по укрупненным блокам проектных мероприятий. Соответственно, и по столбцам в такой таблице представляются не конкретные участники команды, а задействованные организационно-структурные единицы компании. Вместе с тем, ответственность в этом случае возлагается на функциональных руководителей этих единиц в силу того, что ее должны адресно принять конкретные должностные лица. Далее представлен сокращенный пример МО по укрупненным блокам.
Важно помнить! Методика распределения и контроля ответственности в МО предписывает менеджеру соблюдать меру соразмерности матрицы этапу и уровню проектной задачи. На этапе разработки концепции проекта лучше всего применить МО по укрупненным блокам работ, пусть с поливариантной ответственностью, но в упрощенном варианте.
Если проект небольшой, а его задача несколько тяготеет к бизнес-процессу, рекомендую использовать одноранговую упрощенную матрицу. Если пользователями матричной модели являются руководители компании, а задействованных в проекте подразделений достаточно много, то нагляднее будет применить матричную трехмерную изометрию. А если же мы имеем дело с развернутым детализированным планом работ, принятым к распределению ответственности, тут, пожалуй, и классическую RACI будет расписать полезно, но без фанатизма. Кто же любит увлекаться творчеством, однозначно высоко оценит матрицу РАЗУ (разделения административных задач управления). Ниже представлен пример ее фрагмента.
Матрица разделения административных задач управления
Мне весьма импонирует замысловатый инструмент – матрица РАЗУ. Трехранговая, двухтабличная МО, позволяющая оценивать сравнительную трудоемкость всех операций и сравнивать ФОТ с экспертной оценкой результатов, а также многое другое. Просто любо-дорого и для PM, и экономиста-трудовика, курирующего проекты. Здесь привожу пример карты логических аспектов РАЗУ с тремя направления привязки.
Смотрю я на эту карту и вижу одно из изящных решений не только в проектном, но и в операционном, и даже общем менеджменте. Сами посудите: первый раздел идентифицирует тип принятия решения, второй – отграничивает функции управления друг от друга, а третий – форму участия в исполнении. Это так эффектно – соблюсти в сводном символе три объемных элемента самой сущности управления и исполнения.
Матрица РАЗУ – метод сложный, и от него никто не ждет простоты. Тем не менее, понять его не так трудно. Нужно вникнуть в содержание карты и выполнить несколько немудреных правил. Есть разрешенные сочетания знаков-символов, а есть запрещенные. Особенность этих правил в их безусловной обязательности.
Второй формой, включенной в метод РАЗУ, является так называемая таблица парного сравнения. Благодаря этой матрице достигается возможность оцифровки ответственности. Методика позволяет анализировать приведенные в первой таблице символьные значения и обеспечить вывод сравнительной трудоемкости представленных в ней видов.
Символы переименовываются в ряд К1, К2… К8 и попарно выстраивают в столбцах и в строках так, чтобы на пересечении одноименных ячеек всегда были проставлены «1», в другие ячейки сочетаний поставляются либо «2» (значимый), либо «0» (незначимый). Для равноценных символов устанавливается «1». Таким образом, по строкам в итоге получается значимость символа. Работа производится группой экспертов в форме индивидуальной оценки.
Благодаря полученным результатам, аналитик может вычислить:
Матрица РАЗУ, исходя из изложенного, состоит из двух таблиц и целого комплекса аналитической обработки данных и представляет собой системный инструмент оптимизации проектов и операционного управления. Применяя РАЗУ как информационный базис, вы расширяете возможности функционально-стоимостного анализа на основе сравнения оценок внутренней стоимости и эффективности структурных единиц.
Уважаемые коллеги, хочу донести мысль о том, что практика в применении матриц ответственности при управлении проектами – это тот бесценный опыт, который навсегда остается с РМ. Разнообразие инструментов МО в современной управленческой парадигме позволяет искать свои «ключики к замку» каждого ответственного ресурса, которого вы осмысляете под свои задачи. И чем сложнее проект, тем техничнее должны быть процедуры контроля ответственности. При осмотрительном применении матрицы РАЗУ и RACI обязательно принесут вам долгожданный успех.