Типичная ошибка при построении матрицы ответственности это

Иллюстрация: Оля Ежак для Skillbox Media

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

Матрица RACI, или матрица ответственности, — инструмент для управления отношениями в команде; это таблица, с помощью которой распределяют ответственность, полномочия и роли.

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

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

В статье рассказываем главное о матрице ответственности RACI.

• Что такое матрица RACI и какие у неё бывают модификации
• Как построить матрицу RACI — разбираем на примере IT-проекта
• Какие типичные ошибки возникают при построении RACI

---

Матрица RACI представляет собой таблицу: по вертикали выписывают задачи проекта, по горизонтали — исполнителей.

На пересечении задач и исполнителей ставят буквы, которые обозначают роли в проекте и степень ответственности. Из этих букв состоит аббревиатура RACI:

• R (responsible) — исполнитель задачи или подзадачи проекта. Тот, кто самостоятельно выполняет все работы в рамках задачи.

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

• A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам. Часто A-участники назначают задачи и подзадачи R-участникам.

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

• C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции. Он не выполняет задачу, но даёт советы и рекомендации, которые помогают выполнить её эффективнее.
• I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников, поэтому им важно следить, что происходит.

Некоторым проектам не хватает классического списка ролей. Тогда к RACI можно добавить дополнительные буквы и, соответственно, роли. Вот примеры:

• RACI-VS. Новые роли V (verifier) и S (signatory) — верификатор и подписывающий. Они проверяют, соответствует ли результат установленному стандарту, и согласовывают его. V- или S-участников может быть один или два.
• RACIQ. Новая роль Q (quality) проверяет качество результата.
• RASCI. Новая роль S (support) помогает основному исполнителю выполнять работу.

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

Разберём процесс построения матрицы RACI пошагово, на примере разработки приложения для телефонов.

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

• написать техническое задание для разработки приложения;
• создать дизайн приложения;
• разработать приложение;
• протестировать приложение;
• опубликовать приложение в сторах.

По горизонтали выписываем исполнителей проекта — должности либо фамилии сотрудников:

• менеджер проекта;
• дизайнер;
• разработчик;
• тестировщик;
• заказчик.

Получается таблица. На следующем этапе заполним ячейки на пересечении задач и исполнителей.

О том, по какому принципу распределяют роли команды, писали выше. Определим их для участников нашего проекта:

R-участники. Это исполнители задач.

• Писать техническое задание для приложения будет заказчик.
• Заниматься дизайном — дизайнер.
• Разрабатывать и тестировать приложение — разработчик и тестировщик.
• Размещать приложение в магазинах — заказчик.

A-участники. Это ответственные за каждую задачу проекта.

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

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

C-участники. Это консультанты.

В нашем примере дизайнер может проконсультировать заказчика, когда тот будет составлять техническое задание. Например, подсказать, как правильно составить ТЗ на дизайн приложения. На этом же этапе свой совет может дать и разработчик.

I-участники. Это исполнители, которых нужно информировать о ходе работ.

В нашем случае тестировщика нужно проинформировать о том, что разработчик закончил свои задачи, а заказчика — о том, что приложение готово и протестировано.

Мало просто построить матрицу ответственности — важно грамотно ей пользоваться.

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

Вот типичные ошибки, которые возникают при построении матрицы ответственности:

• Один участник команды — R-исполнитель сразу в нескольких задачах. В этом случае нужно проанализировать, насколько эти задачи масштабные. При необходимости — назначить на некоторые из них дополнительных людей.
• У участника проекта нет R- или A-роли. В этом случае нужно решить, действительно ли этот участник необходим проекту. Возможно, стоит пересмотреть состав команды.
• У задачи много ответственных. Могут возникнуть проблемы при согласовании результата: сколько ответственных, столько и мнений. В идеале на каждую задачу нужно назначать только одну A-роль.
• Несколько букв в одной клетке. Как правило, когда один человек отвечает за всё, это ни к чему хорошему не приводит.

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

• Много консультантов или участников, которых нужно информировать о промежуточных результатах. Это приводит к лишней коммуникации и отвлекает от основных работ. Назначать C- и I-участников лучше в случае крайней необходимости.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Менеджер проектов
Узнать больше

Еще статьи

Показать еще

комментарии

Иллюстрация: Оля Ежак для Skillbox Media

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

Матрица RACI, или матрица ответственности, — инструмент для управления отношениями в команде; это таблица, с помощью которой распределяют ответственность, полномочия и роли.

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

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

В статье рассказываем главное о матрице ответственности RACI.

• Что такое матрица RACI и какие у неё бывают модификации
• Как построить матрицу RACI — разбираем на примере IT-проекта
• Какие типичные ошибки возникают при построении RACI

---

Матрица RACI представляет собой таблицу: по вертикали выписывают задачи проекта, по горизонтали — исполнителей.

На пересечении задач и исполнителей ставят буквы, которые обозначают роли в проекте и степень ответственности. Из этих букв состоит аббревиатура RACI:

• R (responsible) — исполнитель задачи или подзадачи проекта. Тот, кто самостоятельно выполняет все работы в рамках задачи.

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

• A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам. Часто A-участники назначают задачи и подзадачи R-участникам.

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

• C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции. Он не выполняет задачу, но даёт советы и рекомендации, которые помогают выполнить её эффективнее.
• I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников, поэтому им важно следить, что происходит.

Некоторым проектам не хватает классического списка ролей. Тогда к RACI можно добавить дополнительные буквы и, соответственно, роли. Вот примеры:

• RACI-VS. Новые роли V (verifier) и S (signatory) — верификатор и подписывающий. Они проверяют, соответствует ли результат установленному стандарту, и согласовывают его. V- или S-участников может быть один или два.
• RACIQ. Новая роль Q (quality) проверяет качество результата.
• RASCI. Новая роль S (support) помогает основному исполнителю выполнять работу.

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

Разберём процесс построения матрицы RACI пошагово, на примере разработки приложения для телефонов.

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

• написать техническое задание для разработки приложения;
• создать дизайн приложения;
• разработать приложение;
• протестировать приложение;
• опубликовать приложение в сторах.

По горизонтали выписываем исполнителей проекта — должности либо фамилии сотрудников:

• менеджер проекта;
• дизайнер;
• разработчик;
• тестировщик;
• заказчик.

Получается таблица. На следующем этапе заполним ячейки на пересечении задач и исполнителей.

О том, по какому принципу распределяют роли команды, писали выше. Определим их для участников нашего проекта:

R-участники. Это исполнители задач.

• Писать техническое задание для приложения будет заказчик.
• Заниматься дизайном — дизайнер.
• Разрабатывать и тестировать приложение — разработчик и тестировщик.
• Размещать приложение в магазинах — заказчик.

A-участники. Это ответственные за каждую задачу проекта.

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

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

C-участники. Это консультанты.

В нашем примере дизайнер может проконсультировать заказчика, когда тот будет составлять техническое задание. Например, подсказать, как правильно составить ТЗ на дизайн приложения. На этом же этапе свой совет может дать и разработчик.

I-участники. Это исполнители, которых нужно информировать о ходе работ.

В нашем случае тестировщика нужно проинформировать о том, что разработчик закончил свои задачи, а заказчика — о том, что приложение готово и протестировано.

Мало просто построить матрицу ответственности — важно грамотно ей пользоваться.

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

Вот типичные ошибки, которые возникают при построении матрицы ответственности:

• Один участник команды — R-исполнитель сразу в нескольких задачах. В этом случае нужно проанализировать, насколько эти задачи масштабные. При необходимости — назначить на некоторые из них дополнительных людей.
• У участника проекта нет R- или A-роли. В этом случае нужно решить, действительно ли этот участник необходим проекту. Возможно, стоит пересмотреть состав команды.
• У задачи много ответственных. Могут возникнуть проблемы при согласовании результата: сколько ответственных, столько и мнений. В идеале на каждую задачу нужно назначать только одну A-роль.
• Несколько букв в одной клетке. Как правило, когда один человек отвечает за всё, это ни к чему хорошему не приводит.

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

• Много консультантов или участников, которых нужно информировать о промежуточных результатах. Это приводит к лишней коммуникации и отвлекает от основных работ. Назначать C- и I-участников лучше в случае крайней необходимости.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Менеджер проектов
Узнать больше

Обновлено: 11.04.2023

Матрица ответственности позволяет распределить ответственность за результаты проекта.

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

•1 шаг: Перечислите основные результаты проекта/важные решения в строках матрицы.

•2 шаг: Перечислите участников/группы участников проекта в столбцах матрицы.

•3 шаг: Закодируйте матрицу ответственности: О, У, К, И.

Придерживайтесь правил разработки матрицы ответственности:

•Не назначайте более одного ответственного за данный конкретный результат, для того чтобы избежать эффекта коллективной безответственности.

•Следите за тем, чтобы не осталось такого результата, за который никто не несет персональной ответственности.

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

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

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

Задание. Разработайте матрицу ответственности

Фазы (ключевые результаты, пакеты работ и т.д.)

Менеджер проекта (ФИО)

Должность, ФИО участника проекта

Должность, ФИО участника проекта

Должность, ФИО участника проекта

Должность, ФИО участника проекта

Сетевой план-график. Календарный план-график

1. Разработка сетевого плана-графика проекта:

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

Выстраиваем цепочки операций:

2. Разработка календарного плана-графика проекта:

Календарный план-график представляет собой расписания работ. Он дает наглядное представление о последовательности выполнения операций с привязкой ко времени.

Пример календарного плана-графика:

Операция	Наименование	t	Временная шкала
1.1.	///	///
1.2.	///	///	///	///
1.3.	///	///	///
2.1.	///
2.2.	///	///

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

3. Оптимизация расписанияпроекта:

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

Важным (конечным) этапом оптимизации расписания является окончательное согласование планов и их утверждение Спонсором / Заказчиком. Также следует согласовать допустимые отклонения.

Результат: план работ составлен, оптимизирован и утвержден Спонсором / Заказчиком.

Задание: разработайте сетевой и календарный планы-графики
Основы фандрайзинга

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

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

•Какой ресурс для Вашего проекта является основополагающим?

•Без чего не может быть осуществлен проект?

•Является ли отсутствие денег и материально–технической базы непреодолимым препятствием в обеспечении жизнедеятельности Вашего проекта?

Теперь необходимо определить: •Какие ресурсы мы хотим получить?

•Сколько?

•Зачем?

•На что будут потрачены те деньги, которые, как мы рассчитываем, нам дадут люди?

Классический цикл фандрайзинга выглядит следующим образом:

•оценка потребностей (составление бюджета, бизнес–плана);

•выбор потенциальных источников (инвесторов);

•проведение конкретных мероприятий по привлечению конкретных ресурсов;

Аннотация: Определение ролей проекта. Матрица ответственности проекта. Построение матрицы ответственности. Закрепление функций и полномочий в проекте. Реестры навыков.

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

Определение ролей проекта

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

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

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

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

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

Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.

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

Ключевые роли со стороны исполнителя — руководитель проекта ( менеджер проекта) со стороны исполнителя и бизнес- менеджер .

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

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

В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].

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

Состав команды управления должен быть достаточным, чтобы осуществлять [11]:

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

  В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для IT-проектов: функциональный архитектор , функциональный консультант, разработчик, администратор ИС, тестировщик , менеджер по качеству, системный аналитик . В проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается в небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей , как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик , менеджер разработки и разработчик, менеджер по качеству и тестировщик . Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика.

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

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

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

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

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

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

  Для отражения иерархии подотчетности на проекте и указания обязанностей каждой из групп, входящих в проектную команду, в документ описания содержания проекта рекомендуется включить матрицу ответственности , наиболее распространенный вариант которой известен как RACI-матрица. Использование данного инструмента особенно актуально в ситуации, когда проектная команда состоит из представителей различных юридических лиц (например, типичная команда на проекте внедрения КИС включает в себя сотрудников заказчика, генерального подрядчика и субподрядчиков). Матрица ответственности решает задачу демонстрации межорганизационного или межгруппового взаимодействия и, как следствие, позволяет избежать недоразумений, которые время от времени возникают в проектах между подразделениями и организациями из-за неясности, к кому следует обращаться по тем или иным вопросам и кто должен принимать по ним решение, а кто — непосредственно реализовать принятую резолюцию.

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

  Построение матрицы ответственности

  По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР ), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.

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

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

  На коды, используемые в матрице ответственности , каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.

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

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

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

  

  Еще один пост для начинающих РМов про нужный и полезный инструмент – RACI матрицу.

  Что такое матрица распределения ответственности или RACI матрица?

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

  Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.

  Расшифровка RACI:

  1. R (Responsible) – тот, кто будет делать работу. Например, модуль Х будет писать разработчик Вася. Для каждой задачи должен быть как минимум один “R”, можно больше.
  2. A (Accountable) – тот, кто примет итоговую работу и будет нести за нее ответственность. Принимать у Васи модуль Х и отвечать перед руководителем проекта головой за то, что он заработает, будет его тимлид Петя. “А” для каждой задачи должен быть только один, отсутствовать “А”, также как и “R”, в задаче не может. В исключительных случаях (обычно для совсем маленьких команд) “А” и “R” будут одним и тем же человеком, тогда достаточно указать просто “А”. Но вообще это нехорошая практика.
  3. C (Consulted) – тот, кто будет в обязательном порядке консультировать остальных при выполнении задачи. Чтобы модуль Х работал как надо, и Васе и Пете надо будет согласовать свои идеи по реализации с Инной, главной за информационную безопасность в компании, и Еленой, архитектором проекта. “C” в задаче может быть, а может и не быть.
  4. I (Informed) – тот, кто должен быть в курсе принимаемых решений или хода выполнения задачи, но влиять на них никак не будет. Руководитель поддержки Иван, которого пользователи уже запинали в ожидании модуля Х, будет грустно читать статусы и рассылки о ходе разработки модуля, смотреть таски в JIRA и тяжело вздыхать. По аналогии с “C”, “I” в задаче может быть, а может и не быть.

  Пример матрицы распределения ответственности

  Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):

  

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

  А вот более “корпоративный” пример:

  

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

  Как и где используется матрица распределения ответственности?

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

  Итак, где может быть полезна матрица распределения ответственности?

  1. Конечно, в первую очередь при управлении проектом. Самый правильный момент создания RACI матрицы – на этапе планирования проекта. Поможет избежать кучи проблем и недопониманий в дальнейшем.
  2. При разработке нового или формализации существующего бизнес-процесса. При создании RACI матрицы для существующего процесса как правило выясняется много нового и интересного.
  3. При создании нового продукта, когда процессов как таковых еще нет. Если договориться на берегу, кто тут за продажи, а кто за производство – есть вероятность даже не поругаться и как минимум продукт запустить.
  4. В любой другой ситуации, когда надо жестко разграничить, кто и за что отвечает и в чем участвует (а иногда – и в чем не участвует, см.вариации RACI ниже).

  Разработка матрицы распределения ответственности

  Построить RACI матрицу несложно, все, что нужно, это:

  1. Определить и выписать по вертикали задачи/промежуточные результаты проекта, шаги бизнес-процесса или другой набор действий, для которого вы хотите обозначить ответстенных.
  2. Определить и выписать по горизонтали все роли или конкретных людей.
  3. Проставить “А” для каждой задачи. Этот пункт, кстати, здорово прочищает мозги, так как сказать, “кто будет делать – легко”, а вот “за кем будет последнее слово” – уже сложнее.
  4. Проставить “R” для каждой задачи.
  5. Посмотреть на остальные роли/людей, прикинуть, нужно ли будет с ними консультироваться или хотя бы держать в курсе происходящего, и проставить соответствующие буквы.

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

  Поздравляю, ваша матрица распределения ответственности готова!

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

  Другие виды матрицы распределения ответственности

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

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

  Вот такие варианты можно встретить чаще всего:

  • RASCI – к обычной RACI добавляется S (Support), то есть тот, кто будет помогать ответственному (R) выполнять задачу.
  • RACIQ – к обычной RACI добавляется Q (Quality), то есть тот, кто будет проверять результат на предмет соответствия заявленному качеству.
  • RACI-VS – к обычной RACI добавляется V (Verifier) и S (Signatory), которые, соответственно, будут принимать продукт с точки зрения критериев приемки и согласовывать передачу его в эксплуатацию.
  • RACIO (или CAIRO, просто буквы в другом порядке) – к обычной RACI добавляется O (Out of the loop), или тот, кого в задаче видеть вообще не хотят (чтобы сразу его выпилить, ну, например, не хотим мы, чтобы архитектор Елена мешалась под ногами у разработчика Васи). В жизни такого не видела, но очень хотела бы.
  • И так далее.

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

  Основные ошибки при построении матрицы распределения ответственности

  Вариантов “как из RACI матрицы сделать бессмысленную бумажку” много, но вот самые частые и поэтому самые любимые:

  1. Указываем везде спонсора (ну или хотя бы заказчика или любого топ-менеджера на выбор) в качестве “А”. В итоге большим дядям не до вас, ничего толком не принято, ответственных нет.
  2. Пихаем по несколько букв в одну клетку матрицы. Нет, такие редкие исключения, конечно, бывают, но если у вас вся матрица пестрит A/R и C/I – значит, вы сами не разобрались то ли с инструментом, то ли с ответственностью.
  3. Всех информируем изо всех сил. Или со всеми консультируемся. И в итоге получаем массу лишней коммуникации и генерацию белого шума в проекте или процессе.
  4. Использование имен вместо ролей. Мало того, что придется переделывать при любом изменении в команде, так еще и потом для истории этот документ будет бессмысленным.

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

  Используете RACI матрицу у себя? Расскажите!

  Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.

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

  А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!

  

  

  Информация полезна? Поддержи развитие проекта!

  На кофе и новые материалы для читателей блога

  

  

  Еще статьи

  комментарии

  ‘ data-post_id=»5783″ data-user_id=»0″ data-is_need_logged=»0″ data-lang=»en» data-decom_comment_single_translate=» комментарий» data-decom_comment_twice_translate=» комментария» data-decom_comment_plural_translate=» комментариев» data-multiple_vote=»1″ data-text_lang_comment_deleted=’Комментарий удален’ data-text_lang_edited=»Отредактировано в» data-text_lang_delete=»Удалить» data-text_lang_not_zero=»Поле не NULL» data-text_lang_required=»Это обязательное поле.» data-text_lang_checked=»Отметьте один из пунктов» data-text_lang_completed=»Операция завершена» data-text_lang_items_deleted=»Объекты были удалены» data-text_lang_close=»Закрыть» data-text_lang_loading=»Загрузка. «>

  Добавить комментарий

  2 комментария

  Как раз в связи с пуском большой программы проектов в компании пытаемся наладить работу с RACI матрицей руководителей проектов и использование ее в практике управления проектами, и вот тут возникло небольшое непонимание:

  1. На уровне руководства решено было представить верхнеуровнево матрицу распределения ответственности по отделам- Эксплуатация, Производство, Внедрение, а вот роль РП отдельно выделили. На вопрос, почему бы тогда не отразить и роли других участников, поступил ответ: тогда матрица получиться очень масштабной и плохо читаемой. Цель была укрупненно представить какое подразделение за что отвечает. Мне кажется, что эта практика не очень полезная, даже в укрупненном масштабе, т.к. дьявол всегда в деталях, и как правило много “политических” вопросов возникает, когда начинаешь решать конкретные задачи, хотя на верхнем уровне вроде бы как и все отлично выглядит.

  2. “если у вас вся матрица пестрит A/R” – как раз по роли РП такая ситуация очень частая, если говорить о задачах, связанных с управлением проектом. Возможно, здесь нужно рассмотреть конкретные ситуации, что бы понять, где такая практика допустима, где показывает, что “вы сами не разобрались то ли с инструментом, то ли с ответственностью”.

  Светлана, отвечу по пунктам:
  1. Я категорически против такой коллективной безответственности, толку от этой матрицы примерно ноль. Попробуйте предложить тогда уж указать в матрице руководителей этих департаментов, а с них уже конкретное делегирование стрясти. В письменной форме, конечно же, тогда хоть будет на кого пальцем показать при необходимости=)) Вот сколько таких матриц видела – ни одна не работала, и спасибо еще, если не вредила.
  2. A/R – вариант нормы, если для вас это работает, более того – чем меньше проект, тем чаще это норма. Другой вопрос – что в это A вкладывается. Действительно ли РМ у вас “A” за, например, финансовый план проекта, как РМ сделает – так и будет? Или все-таки спонсор и заказчик в итоге его утвердят и перед менеджментом отвечать будут, если что? Ну и так далее.

  

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

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

  

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

  

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

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

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

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

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

  

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

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

  

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

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

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

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

  

  Что такое матрица RACI

  Каждая буква этой аббревиатуры означает конкретную роль сотрудника:

  • R – ответственный;
  • A – подотчетный;
  • C – консультант;
  • I – уведомляемый.

  Ответственный исполнитель несет основную ответственность за решение порученной задачи. Степень определяет подотчетный сотрудник.

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

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

  Информируемый сотрудник принимает решение о завершении работы. Также отчитывается перед заказчиком.
  Также существуют два расширенных варианта матрицы — RACI-VS и RASCI. В первом случае к аббревиатуре добавлены две функции персонала:

  • V – проверяющий;
  • S – контролирующий завершение задачи.

  Цели использования RACI

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

  Матрица позволяет выявить и решить следующие проблемы:

  • избыток проверяющих;
  • временные потери;
  • низкая вовлеченность сотрудников;
  • низкая производительность;
  • плохая командная работа коллектива.

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

  Правила построения

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

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

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

  

  Анализ матрицы

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

  Достоинства и недостатки

  • открытая коммуникация;
  • снижение временных потерь;
  • простота использования.
  • схематичность;
  • упрощенность;
  • не учитывает нестандартные ситуации.

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

  Читайте также:

  • Наследство вирджиния вулф краткое содержание
  • Очень люблю детей поэтому работаю в школе
  • Юрий казаков краткое содержание
  • Смешные рассказы о школе смерть шпиона гадюкина
  • Красная жизель балет краткое содержание

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

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

Необходимо подчеркнуть слово «координируется» в данном определении, которое неспроста было упомянуто в раскрытии смысла понятия «организация». Успешное функционирование организации основывается на четкой, уверенной и успешной координации работы со стороны руководства организации, а именно, генеральных директоров и людей, исполняющих их обязанности, администраторов, менеджеров, директоров различных отделов или структурных подразделений организации и др. Таким образом, ответственность за принятие верных или неверных решений, несут именно руководители. В дополнение, можно также акцентировать внимание читателя на том, что часто руководители несут ответственность не только за личные решения и действия, но также и за деятельность своих подчиненных. Недаром Премьер-министр Великобритании Уинстон Черчилль говорил: «Ответственность – это та цена, которую мы платим за власть». [1]

Для наиболее благоприятного распределения ответственности между отделами или работниками организации в настоящее время используют RACI-матрицу. Рассмотрим расшифровку данной аббревиатуры. (рис. 1.)

Рисунок 1. Расшифровка аббревиатуры «RACI» [2. С. 345]

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

Существуют подвиды RACI-матрицы или, иными словами, «модификации»:

1. RACI-VS.
2. RACIQ.
3. RASCI. [3. С. 138]

Рассмотрим каждую модификацию более подробно. (рис.2.)

Рисунок 2. Модификации RACI-матрицы [4. С.145]

Разработку матрицы ответственности проекта необходимо доверять профессионалу, так как неверное толкование составляющих может привести к ложному распределению обязанностей между работниками. После тщательно распределенной информации по ячейкам в матрице, проект-менеджер проводит анализ полученных данных. Информация, указанная по вертикали, позволяет менеджеру проекта оценить уровень нагрузки каждого работника, при наличии у одного участника проекта больше трех зон ответственности, менеджер проводит перераспределение ответственных лиц за те или иные этапы реализации проекта. Например, отсутствие A и R в ячейках у сотрудника указывает на возможное наличие невостребованности в определенной должности или сотруднике. Большое количество в ячейках матрицы значения «A» указывает на наличие ответственности сотрудника за всех. При возникновении данной ситуации следует разделить зону ответственности работника с иными участниками проекта. Большое количество значения «R» в ячейках означает, что работник будет отвечать за множество задач, что может привести к снижению скорости достижения поставленных целей, качества реализуемой работы и др. В данной ситуации менеджеру проекта необходимо перенести значение «R» иным, менее загруженным работникам. [2. С. 37]

Также существует горизонтальный анализ матриц ответственности проекта. Горизонтальный анализ позволяет специалисту проанализировать уровень качества функционирования организации на каждом отдельном этапе. Если при анализе выявлено большое количество ячеек, заполненных показателем «R», значит, в анализируемом заполнении присутствует ошибка, заключающаяся в дублировании одной функции у двух участников проекта, что означает, что один работник выполняет бесполезную деятельность. Отсутствие значения «I» подразумевает, что осуществление одной функции возложено на нескольких участников проекта, что так же является бесполезным. Наличие большого значения «С» означает, что окончательная реализация того или иного действия ожидает одобрения и подтверждения со стороны большого количества иных участников-руководителей проекта, обязанность которых заключается в предоставлении обратной связи в виде корректировок, поправок, замечаний и др.

И последний фактор – количество значения «A» в ячейке строки. Если данного значения много, это может означать, что в организации происходит нечеткое разделение границ ответственности за проекты, что может привести к отрицательным последствиям при их непосредственной сдаче. [5. С. 38]

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

Рассмотрим сущность разработки матрицы ответственности на примере внедрения государственного проекта «Пушкинская карта», участниками и по совместительству создателями которого являются Минкультуры, Министерство финансового развития и «Почта Банк».

Назначение проекта: данный проект направлен на повышение культурного и социального воспитания молодежи в возрасте от 14 до 23 лет.

При рассмотрении классификации проектов, можно сделать вывод, что данный проект является национальным, социальным, учебно-образовательным, долгосрочным, сложным и крупным проектом. Запуск данного проекта: 30 июня 2021 года. Правила по осуществлению реализации данного проекта прописаны в Постановлении Правительства РФ от 8 сентября 2021 года № 1521 «О социальной поддержке молодежи в возрасте от 14 до 22 лет для повышения доступности организации культуры».

В данном нормативно-правовом акте прописаны участники проекта:

– Министерство культуры (далее будет использоваться сокращение МК);

– Министерство цифрового развития (МЦР);

– федеральное казённое учреждение (ФКУ);

– организация культуры (ОК);

– оператор (ОР);

– экспертные советы (ЭС);

– граждане (Г);

– билетный оператор (БО). [6.]

Рассмотрим возможное построение RACI-матрицы на примере данного проекта. (табл. 1).

Таблица 1

Пример построения RACI-матрицы на уровне основных участников на примере национального проекта «Пушкинская карта»

Задачи	МК	МЦР	ФКУ	ОК	ОР	ЭС	БО
– координация реализации программы; – обеспечение отбора и включения организаций культуры и мероприятий в реестр.	IA	–	R	–	–	C	–
– разработка и поддержание функционирования мобильного приложения, сайта; – ведение реестра проданных билетов гражданам.	I	RA	–	–	–	C	C
– размещение заявок для включения в реестры; – предоставление информации по использованию терминальных устройств; – реализация билетов; – размещение информации о билетах.	I	–	A	R	–	C	C
– предоставление гражданам информации об остатке средств на индивидуальных картах; – подписание соглашений с организациями, вступающими в программу.	I	–	–	A	R	C	R
– популяризация проекта.	AI	C	–	–	–	R	–

Составлено автором на основе ранее полученного теоретического материала

Представленная RACI-матрица применительно к проекту «Пушкинская карта» является лишь одним из многих вариантов распределения ответственности между основными участниками данного проекта, разработанный автором статьи на основе Постановления Правительства РФ от 08.09.2021 г. № 1521. При анализе данной матрице можно сделать вывод, что обязанности распределены равнозначно, однако, можно заметить, что операторы и билетные операторы дублируют выполнение определенных функций, что, в соответствии с правилами горизонтального анализа, является не наилучшим показателем. Однако, так как масштаб данного проекта находится в фазе «крупный», в связи с тем, что проект является национальным, можно утверждать, что дублирование функций по предоставлению гражданам информации об остатках средств на индивидуальных счетах, а также подписания соглашений с организациями, вступающими в программу, является рациональным. Дублирование данных обязанностей двух участников проекта позволяет ускорить процесс информирования граждан, а также повышение уровня включение новых организаций в проект.

Подводя итог, можно сделать определенные выводы.

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