Матрица ответственности для бизнес процессов

Иллюстрация: Оля Ежак для 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 для менеджеров

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

From Wikipedia, the free encyclopedia

A responsibility assignment matrix^[1] (RAM), also known as RACI matrix^[2] () or linear responsibility chart^[3] (LRC), describes the participation by various roles in completing tasks or deliverables for a project or business process. RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed.^[4] It is used for clarifying and defining roles and responsibilities in cross-functional or departmental projects and processes.^[5] There are a number of alternatives to the RACI model.

Key responsibility roles in RACI model[edit]

Role distinction[edit]

There is a distinction between a role and individually identified people: a role is a descriptor of an associated set of tasks; may be performed by many people; and one person can perform many roles. For example, an organization may have ten people who can perform the role of project manager, although traditionally each project only has one project manager at any one time; and a person who is able to perform the role of project manager may also be able to perform the role of business analyst and tester.

R = Responsible (also recommender)

Those who do the work to complete the task.^[6] There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required (see also RASCI below for separately identifying those who participate in a supporting role)

A = Accountable (also approver or final approving authority)

The one ultimately answerable for the correct and thorough completion of the deliverable or task, the one who ensures the prerequisites of the task are met and who delegates the work to those responsible.^[6] In other words, an accountable must sign off (approve) work that responsible provides. There must be only one accountable specified for each task or deliverable.^[7]

C = Consulted (sometimes consultant or counsel)

Those whose opinions are sought, typically subject-matter experts; and with whom there is two-way communication.^[6]

I = Informed (also informee)

Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.^[6]

Very often the role that is accountable for a task or deliverable may also be responsible for completing it (indicated on the matrix by the task or deliverable having a role accountable for it, but no role responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task.

Assigning people to facilities[edit]

The matrix is typically created with a vertical axis (left-hand column) of tasks (from a work breakdown structure) or deliverables (from a product breakdown structure), and a horizontal axis (top row) of roles (from an organizational chart).

Example of a responsibility assignment (or RACI) matrix

Code	Name	Project sponsor	Business analyst	Project manager	Technical architect	Applications development
Stage A	Manage sales
Stage B	Assess job
Stage C	Initiate project
— C04	Security governance (draft)	C	C	A	I	I
— C10	Functional requirements	A	R	I	C	I
— C11	Business acceptance criteria	A	R	I	C	I
Stage D	Design solution

Another example from the maintenance and reliability community

Maintenance crew KPI RACI chart

Tasks	Maintenance supervisors	Maintenance analyst	Maintenance planner	Maintenance technician	Maintenance support	Rel specialist	CMMS project engineer
Inputting failure data	A	C	I	R		C	C
Work order completion	R	C	C	C	A	I	I
Work order closeout	C	R	C		I	I	A
QA of failure data input	C	R	I	C	I	C	A
Analyze failure reports	C	C	I	C	A	R	I
Maintenance strategy adjustments	C	I	I	C	A	R	R
Implementing new strategies	R	I	R	C	A	I	I

Alternatives[edit]

There are a number of alternatives to the RACI participation types:

RACI ROLES SHORTEN:
Roles are the following

Responsible

Does the work to complete the task  

Accountable

Delegates work and is the last one to review the task or deliverable before it’s deemed complete

Consulted

Provides input based on either how it will impact their future project work or their domain of expertise on the deliverable itself

Informed

Needs to be kept in the loop on project progress, rather than roped into details of every deliverable

PARIS[edit]

This is an early version^[8] of a responsibility assignment matrix, with the roles defined as:

Participant

Accountable

Review required

Input required

Sign-off required

PACSI[edit]

This is a version very useful to organizations where the output of activities under the accountability of a single person/function can be reviewed and vetoed by multiple stakeholders, due to the collaborative nature of the culture.

Perform

The person/function carrying out the activity.

Accountable

The person/function ultimately answerable for the correct and thorough completion of the deliverable or task, and often the one who delegates the work to the performer.

Control

The person/function reviewing the result of the activity. They have a right of veto; their advice is binding.

Suggest

The person/function consulted to give advice based upon recognized expertise. The advice is non-binding.

Informed

The person/function who must be informed of the result of the activity.

RASIC or RASCI[edit]

This is an expanded version^[9] of the standard RACI, less frequently known as RASCI,^[10] breaking the responsible participation into:

Responsible

Those responsible for the task, who ensure that it is done as per the approver

Support

Resources allocated to responsible. Unlike consulted, who may provide input to the task, support helps complete the task.

RASI[edit]

This is an alternative version^[11] of the standard RACI, foregoing the consulted participation and replacing it with:

Support

Resources which play a supporting role in implementation.

RACI + F[edit]

This is an expanded version of the standard RACI, with an additional participation type: Facilitate. This variation was introduced by Christophe Le Coent in 2012.^[12] Coent argued that the facilitator or coach role is important in agile software development environments and should therefore be explicitly included in the RAM.^[12] The use of RAM in Agile environments is considered contentious because some practitioners believe that everyone working in an agile team should be jointly responsible and accountable.^[13]

Facilitates

Facilitate activities during a Scrum project.

RACIQ[edit]

This is an expanded version of the standard RACI, with an additional participation type:

Quality review

Those who check whether the product meets the quality requirements.

RACI-VS[edit]

This is an expanded version^[4] of the standard RACI, with two additional participation types:

Verifier

Those who check whether the product meets the acceptance criteria set forth in the product description.

Signatory

Those who approve the verify decision and authorize the product hand-off. It seems to make sense that the signatory should be the party being accountable for its success.

CAIRO[edit]

This is an expanded version^[14] of the standard RACI, also known as RACIO^[15] with one additional participation type.

Out of the loop (or omitted)

Designating individuals or groups who are specifically not part of the task. Specifying that a resource does not participate can be as beneficial to a task’s completion as specifying those who do participate.

DACI[edit]

Another version that has been used to centralize decision making, and clarify who can re-open discussions.^[16]

Driver

A single driver of overall project like the person steering a car.

Approver

One or more approvers who make most project decisions, and are responsible if it fails.

Contributors

Are the worker-bees who are responsible for deliverables; and with whom there is two-way communication.

Informed

Those who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.

RAPID[edit]

Another tool used to clarify decision roles and thereby improve decision making, is RAPID, which was created by and is a registered trademark of Bain & Company.

Recommend

The recommend role typically involves 80 percent of the work in a decision. The recommender gathers relevant input and proposes a course of action—sometimes alternative courses, complete with pros and cons so that the decision maker’s choices are as clear, simple and timely as possible.

Agree

The agree role represents a formal approval of a recommendation. The ‘A’ and the ‘R’ should work together to come to a mutually satisfactory proposal to bring forward to the decider. But not all decisions will need an agree role, as this is typically reserved for those situations where some form of regulatory or compliance sign-off is required.

Perform

The perform role defines who is accountable for executing or implementing the decision once it is made. Best-practice companies typically define P’s and gather input from them early in the process.

Input

The input role provides relevant information and facts so that the recommender and decider can assess all the relevant facts to make the right decision. However, the ‘I’ role is strictly advisory. Recommenders should consider all input, but they don’t have to reflect every point of view in the final recommendation.

Decide

The decide role is for the single person who ultimately is accountable for making the final decision, committing the group to action and ensuring the decision gets implemented.

RATSI[edit]

Another tool used in organization design or roles analysis.

Responsibility

Identify who is in charge of making sure the work is done.

Authority

Identify who has final decision power on the work.

Task

Identify who actually does the work.

Support

Identify who is involved to provide support to the work.

Informed

Identify who is informed that the work has been done (or will be started)

DRASCI[edit]

A variant of RASCI developed by three Whitehall theorists (Kane, Jackson, Gilbert). This scheme is adapted for use in matrix management environments, and differs only from RASCI in having an additional role of Driver and a narrower definition of Support:

Driver

An individual or party that assists those who are responsible for delivering a task by both producing supporting collateral and setting timescales for delivery in line with the overarching aim of the individual or party who is accountable for the overall accomplishment of the objective. The distinction between driver and support lies in that the former reinforces and clarifies the parameters of the task on behalf of those who are accountable, while the latter refers to those who help those who are responsible in reaching a given goal.

PDQA[edit]

A version developed at U Tokyo and MIT for model-based project management. The PDQA set of roles corresponds to demand for capabilities of teams. Roles include those for work on scope, handling of dependencies as coordination, and exception handling through error detection and decisions across a project organization. PDQA is used in agent-based modeling to simulate the supply of these capabilities by teams in projects.^[17]

Primary

Provides skill-based effort within capacity to complete scope and also manages dependencies through coordination.

Decision

Handles any decision, including scope acceptable and exception handling decisions leading to rework. (Does not generation nominal scope).

Quality

Reviews scope as it progresses to detect poor quality and escalates to decision-maker as so. (Does not general nominal scope).

Assist

Provides skill-based effort with the capacity to complete scope, in assistance to the primary. (Does not manage dependencies through coordination).

DCI[edit]

A minimal set of decision-making categories used in organisation design or roles analysis.

Decision maker

Individuals who make the decision and is accountable for its impact on the business.

Consulted

Individuals accountable for providing guidance based on functional expertise and experience, highlighting issues and raising alternatives to support the Decision Maker.

Informed

Impacted stakeholders are notified after the decision has been made and who will need to support the execution of the decision.

RASCEIO[edit]

To be used when working on governance, risk, compliance (GRC) and outsourcing matters:

Responsible

Accountable

Support

Consult

Execute

Third parties contracted to execute activities in accordance with a service level agreement

Inform

Overview

Key GRC roles, such as risk owner, policy owner — where accountability is devolved, but a role is needed to oversee whether accountabilities all fit together

Variations[edit]

There are also a number of variations to the meaning of RACI participation types:

RACI (alternative scheme)[edit]

There is an alternative coding, less widely published but used by some practitioners and process mapping software, which modifies the application of the R and A codes of the original scheme. The overall methodology remains the same but this alternative avoids potential confusion of the terms accountable and responsible, which may be understood by management professionals but not always so clearly differentiated by others:

Responsible

Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.

Assists

Those who assist in the completion of the task

Consulted

Those whose opinions are sought; and with whom there is two-way communication.

Informed

Those who are kept up-to-date on progress; and with whom there is one-way communication.

ARCI (decisions)[edit]

This alternative is focused only on documenting who has the authority to make which decisions. This can work across all sized workgroups.

Accountable

Authorized to approve an answer to the decision.

Responsible

Responsible to recommend an answer to the decision.

Consulted

Those whose opinions are sought, and with whom there is two-way communication.

Informed

Those who are informed after the decision is made, and with whom there is one-way communication.

References[edit]

External links[edit]

• Comprehensive Series on RACI
• Assignment

Рано или поздно вы встретитесь с проектом, у которого много стейкхолдеров и много участников команды проекта. Большая команда помимо наличия большого трудового ресурса обременяет PM-а простым вопросом: «А как мне всё это контролировать? Я не могу постоянно быть на связи с командой и принимать важные решения в моменте». Чтобы Менеджеры Проектов в таких ситуациях не сходили с ума, были придуманы два универсальных инструмента распределить ролей и ответственности — матрица RACI и матрица DACI.

Матрица RACI, что это такое и для чего используется

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

RACI расшифровывается:

R — responsible — Кто является исполнителем задачи. Он должен сделать поставленную задачу. Чаще всего это линейный участник проекта.

A — accountable — Кто ответственный за выполнение задачи. Он несёт ответственность за выполнение поставленной задачи. К проекту рекомендуется обычно назначать только одно ответственное лицо. Этот человек служит контактным лицом для всех заинтересованных сторон на протяжении всего проекта. Чаще всего это PM.

С — consulted — Кто консультирует исполнителя задачи. Он предоставляет консультацию исполнителю, если они сталкиваются с проблемами. Чаще всего эксперты по вопросу внутри компании или лиды команды.

I — informed — Кого информируют о выполнении задачи. Их необходимо постоянно информировать о прогрессе реализации задачи. Это могут быть ключевые стейкхолдеры.

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

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

Как работать с RACI?

Инструмент нужно заполнять после того, как понятны основные задачи, не обязательно их прописывать детализировано, можно взять блоки из вашей иерархической структуры (WBS). Далее на установочной встрече команды проекта (Kickoff meeting) можно в общем пространстве составить матрицу RACI, прикрепляю ссылочку на удобный шаблон в Miro:

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

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

Матрица DACI, что это такое и для чего используется

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

DACI расшифровывается:

D – driver — Кто ответственен за привлечение заинтересованных сторон, сбор и изучение информации и получение решения в согласованный срок. Чаще всего это PM.

A – аpprover — Кто согласовывает и утверждает решение. Это может быть спонсор проекта или ключевой стейхолдер.

C – сontributors — Кто участвует в принятии решения, консультирует. Зачастую это члены команды или консультанты.

I — informed — Кого информируют о принятии решения. Чаще команда проекта и стейкхолдеры.

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

Как работать с DACI?

Составление DACI не сильно отличается от составление RACI, поэтому подход к заполнению, который был описан выше подходит и тут, но важно после заполнения согласовать со спонсором проекта или другими ключевыми стейкхолдерами, которые указаны в разделе A – аpprover.

Заключение

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

Еще статьи

Показать еще

комментарии

В управлении проектом важно четко определить, кто за что отвечает. Для этого применяется инструмент «матрица ответственности».

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

Матрица ответственности процесса «А4 Планирование и осуществление проектных работ»

Отчет

По вопросам обучения работе в Business Studio обращайтесь по тел.: +7 (8552) 322-243. E-mail: info@p3s.ru

Другие примеры

Business Studio. Пример матрицы ответственности должностного лица

Business Studio. Пример положения о подразделении «Отдел снабжения»

Business Studio. Пример должностной инструкции «Заместитель директора»

Business Studio. Пример регламента процесса «Предпроектное обследование»

Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул. Настолки состоялись.

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

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:

Простите. Не могу промолчать. Не надо так.

Общая суть

Есть в проектном менеджменте такой инструмент — RACI матрица PMBOK Guide (9.1.2.1 Organization Charts and Position Descriptions, Matrix-based charts)

RACI — это аббревиатура:

R — Responsible
A — Accountable
C — Consulted
I — Informed

И вокруг этой матрицы есть путаница. Responsible и Accountable можно перевести на русский язык одинаково — ответственный, иногда это можно использовать как синонимы, но не в RACI matrix. В матрице ответственности между Responsible и Accountable семантическая пропасть, вот вам мостик через неё. 

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

Responsible  — тот, кто будет выполнять этап, прям физически, к примеру, Вася делает кликабельный прототип приложения. Он Responsible за этап проекта «прототипирование».

Accountable — тот кто апрувит результат и отвечает за него. В некоторых вариациях звучит как Authorize. В зависимости от команды, это может быть менеджер Васи, может быть старший дизайнер Васи, а если в команде 2,5 человека, то это может быть и сам Вася. Но такая практика сгодится только для супер-маленьких команд, не надо к ней прилипать. 

Informed и Consulted тоже кажутся близки по смыслу. Основное отличие в том, что у C двусторонняя коммуникация в проекте, а у I — односторонняя. C может влиять на проект, а I — нет. 

Я нашла в сети еще объяснения RACI матрицы, на бытовых примерах из жизни:

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

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

Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.

1. В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
2. Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта. 
3. Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
4. В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
5. Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней. 
6. Лучше устанавливать A и R на минимальный соответствующий уровень.
7. Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
8. Сведите к минимум позиции I и С.
9. Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
10. RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.

Проверка матрицы

Проверяют матрицу по двум направлениям: по вертикали и по горизонтали. Вот чек-лист, как проверить свою RACI матрицу на вшивость.

Вертикальная (по ролям)

Т.е. оценивается насколько сбалансированы роли в проекте

Слишком много R

 

Проверочный вопрос: «Вывезет человек на этой роли так много задач?»

Нет пустых мест

Проверочный вопрос: «Человеку в этой роли действительно необходимо участвовать во всех этапах проекта?»

Слишком много A

Проверочный вопрос: «Можно ли снизить количество процессов, в которых человек в этой роли принимает решение и отчитывается за них?»

Нет R или A

Проверочный вопрос: «Это нужная роль? Можно ли перераспределить часть ответственности на другие роли или передать часть ответственности с других ролей на эту?»

Двойные позиции A/R, или A/I

A/R, A/C, R/C — возможная картина для очень маленькой компании, но лучше избегать.
A/I, R/I, C/I- свидетельствует о непонимании RACI матрицы как инструмента.

Общая картина

Проверочный вопрос: «Соответствует ли количество ответственности на проверяемой роли уровню подготовки человека / его вовлеченности в проект?

Горизонтальная (по этапам)

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

Нет R 

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

Слишком много R

Работа может замедлиться. Проверочный вопрос: «Можно ли разбить этап на более конкретные задачи, чтобы снизить количество исполнителей в этапе?»

Нет A

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

Больше, чем одна A

Первое правило RACI матрицы — только одна А для каждого этапа проекта.

Все ячейки заполнены на каждом этапе

Проверочный вопрос: «Действительно ли нужны все участники проекта на каждом этапе? Есть при преимущества от их участия?»

Нет C/I

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

Слишком много C

Замедляет проект. Проверочные вопросы: «Действительно нужно консультироваться со всеми C? Затраты часов на эти консультации окупаются? Можно просто проинформировать эти роли?»

Слишком много I

Проверочные вопросы: «Приносит ли это информирование пользу проекту? Или просто создает лишние созвоны и совещания? Можно информировать людей на этих ролях только в исключительных обстоятельствах? Можно ли отказаться от информирования людей на этих ролях?»

Много двойных позиций

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

Непоняточки

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

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

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

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

Ошибки из примера

А теперь, с чек-листом, я проведу проверку шуточной матрицы из интернетов, из-за которой я начала писать:

Горизонтальная проверка (по этапам)

− Подготовить машину.

Нет R (исполнителя), того, кто будет это делать: пойдет выгонять машину из гаража, проверять масло и т.д.

+ Купить еду.

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

± Взять игрушки.

Если речь идет о детских игрушках (в такой маленькой команде, как семья), скорее всего сыну пришлось бы взять на себя и A и R. Вряд ли папа смог бы его проконсультировать о том, какие игрушки сын любит. И вряд ли семья вызвала бы маму на ковёр, если бы сын поехал без игрушек.

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

+ Взять одежду.

Все окей: мама скомандовала всем взять теплые кофты, все взяли теплые кофты. Все в порядке.

− Взять алкоголь

Та же ошибка, что и с подготовкой машины, нет R. Непонятно, кто побежит в магазин за пивом. Да и польза этапа для всего проекта сомнительная. Убираем этот этап.

+ Замариновать шашлык

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

+ Взять рассаду

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

− Взять инструмент

Опять нет R, кто этим будет заниматься — непонятно.

− Оценить погоду

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

Итого, 4 или 5 из 9 этапов требуют корректировки.

Вертикальная проверка (по ролям)

Папа

Участвует абсолютно в каждом этапе проекта. При горизонтальной проверке, на этапе «Подготовить машину» нет R. Папа — единственный компетентный член семьи, так что ему придется совмещать A и R. Вероятно, эта роль перегружена, и надо перераспределить часть задач на других членов команды.

Мама

В целом роль выглядит сбалансированной, но т.к. в ходе горизонтальной проверки, мы нашли этапы, на которых нет R (исполнителей), Мама может стать R на этапе «Оценить погоду». Если мама маленькая и хрупкая (некомпетентная), то она не сможет стать R на этапе «Взять инструмент», но обычно мама знает, где что лежит, так что может выступить C (консультантом).

Сын

В целом роль выглядит сбалансированной. Если сын большой и сильный мальчик, то на этапе «Взять инструмент», может стать R (исполнителем).

Бабушка

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

Кот

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

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

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

Меня вдохновила вот эта штука: Как объяснить бабушке, что такое Agile за 15 минут с картинками

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

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

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

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

• Ответственное лицо (Responsible). Это человек, на которого непосредственно возложена работа. У каждой задачи должно быть только одно ответственное лицо, чтобы все знали, к кому обращаться за информацией или с вопросами. Если в задаче несколько ответственных, теряется чёткость и возникает путаница. Вместо этого лучше приглашать дополнительных участников, имеющих другие роли по RACI, в которых может быть больше одного человека.

• Подотчётное лицо (Accountable). Подотчётное лицо отвечает за ход выполнения задач в целом, хотя при этом может не принимать непосредственного участия в работе. Есть два способа определения подотчётного лица. Иногда это менеджер проекта (или даже ответственное лицо, хотя в таком случае оно будет выполнять две разные роли в процессе выполнения задачи). В подобных случаях подотчётное лицо отвечает за выполнение всей работы. В других случаях это топ-менеджер или руководитель, отвечающий за утверждение работы, прежде чем она будет считаться выполненной. Как и в случае с ролью ответственного лица, роль подотчётного лица должен выполнять только один человек.

• Консультирующее лицо (Consulted). Этот человек или люди проверяют и визируют работу перед её сдачей. У каждой задачи, вехе проекта или ожидаемому результату может быть несколько таких специалистов.

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

Попробовать Asana для управления проектами

Когда следует создавать матрицу RACI?

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

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

Пример матрицы RACI

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

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

• Копирайтер

• Дизайнер

• Администратор веб-сайта

• Веб-разработчик

Вам нужно создать матрицу RACI по пяти задачам и ожидаемым результатам:

• Обновить кнопки, призывающие к действию, на главной странице

• Обновить историю клиента на главной странице

• Обновить дизайн веб-сайта

• Увеличить скорость загрузки главной страницы

• Обновить дизайн главной страницы

Вот как будет при этом выглядеть матрица RACI:

Обновить кнопки, призывающие к действию, на главной странице

• Ответственное лицо: копирайтер

• Подотчётное лицо: веб-разработчик

• Консультирующее лицо: администратор веб-сайта

• Информируемое лицо: дизайнер

Обновить историю клиента на главной странице

• Ответственное лицо: копирайтер

• Подотчётное лицо: веб-разработчик

• Консультирующее лицо: администратор веб-сайта

• Информируемое лицо: дизайнер

Обновить видео на главной странице

• Ответственное лицо: дизайнер

• Подотчётное лицо: веб-разработчик

• Консультирующее лицо: администратор веб-сайта

• Информируемое лицо: копирайтер

Увеличить скорость загрузки главной страницы

• Ответственное лицо: веб-разработчик

• Подотчётное лицо: веб-разработчик

• Консультирующее лицо: администратор веб-сайта

• Информируемые лица: копирайтер и дизайнер

Обновить дизайн главной страницы

• Ответственное лицо: дизайнер

• Подотчётное лицо: веб-разработчик

• Консультирующее лицо: администратор веб-сайта

• Информируемое лицо: копирайтер

Преимущества и недостатки матриц RACI

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

Преимущества матриц RACI

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

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

Подводные камни матриц RACI (и как их избегать)

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

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

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

Выведите матрицы RACI на новый уровень с помощью управления проектами

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

Читать о трёх способах визуализации плана проекта: хронология, календарь и доска

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

Контроль того, кто, что и когда делает

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