Matriz RACI em Projetos de Engenharia: como definir responsabilidades e evitar falhas de comunicação

Entenda como usar a matriz RACI em projetos de engenharia para definir responsáveis, aprovadores, consultados e informados, reduzindo conflitos e falhas de comunicação.

Confira!

Em projetos de engenharia, muitas falhas não acontecem por falta de capacidade técnica, mas por falta de clareza sobre responsabilidades. Quem executa? Quem aprova? Quem precisa ser consultado antes da decisão? Quem deve apenas ser informado? Quando essas respostas não estão claras, surgem atrasos, retrabalho, decisões contraditórias, conflitos entre fornecedores e dificuldades no aceite técnico.

A matriz RACI é uma ferramenta simples e muito útil para organizar responsabilidades em projetos, contratos, obras, serviços de consultoria, comissionamento, due diligence, procurement, compatibilização de projetos e Owner’s Engineering.

Em engenharia, a matriz RACI ajuda a transformar papéis difusos em uma estrutura objetiva de governança. Ela define quem é responsável por executar uma atividade, quem responde pela decisão, quem precisa ser consultado e quem deve ser informado.

Quando bem aplicada, a matriz RACI reduz ambiguidades, melhora a comunicação, apoia a tomada de decisão e ajuda o contratante a controlar interfaces críticas.

O que é matriz RACI?

A matriz RACI é uma ferramenta de atribuição de responsabilidades. O termo RACI vem de quatro papéis:

Letra	Termo	Função
R	Responsible	Quem executa a atividade ou entrega o resultado
A	Accountable	Quem responde pela decisão, aprovação ou resultado final
C	Consulted	Quem deve ser consultado antes da decisão ou execução
I	Informed	Quem deve ser informado sobre andamento, decisão ou resultado

Em português, é comum interpretar esses papéis como Responsável, Aprovador, Consultado e Informado. O ponto mais importante é diferenciar quem executa de quem aprova. Em muitos projetos de engenharia, essa distinção evita conflitos relevantes.

Por que usar matriz RACI em projetos de engenharia?

Projetos de engenharia envolvem múltiplas partes: contratante, projetistas, consultores, integradores, fornecedores, operação, manutenção, compras, jurídico, fiscalização, comissionamento e, em alguns casos, Owner’s Engineering. Sem uma estrutura clara, as responsabilidades podem se sobrepor ou ficar descobertas.

Sem matriz RACI	Com matriz RACI
Responsabilidades ambíguas	Papéis definidos por atividade
Decisões sem dono claro	Responsável pela aprovação identificado
Consultas feitas tarde demais	Partes consultadas definidas previamente
Comunicação excessiva ou insuficiente	Informados definidos de forma objetiva
Conflitos entre áreas e fornecedores	Interfaces mais bem controladas
Atrasos por indefinição	Fluxo de decisão mais claro

Na prática, a matriz RACI funciona como um mapa de responsabilidades. Ela não substitui contrato, escopo, cronograma ou matriz de riscos, mas complementa esses instrumentos.

RACI é um mecanismo de governança, não apenas uma planilha

Uma matriz RACI madura não começa pela pergunta “qual letra colocar para cada pessoa?”. Ela começa pela governança: quais decisões existem, quem possui autoridade para tomá-las, quais entregas precisam de responsável, que conhecimento deve entrar antes da decisão e quais partes precisam receber informação para cumprir suas próprias obrigações.

O PMBOK® Guide — Eighth Edition, disponível no acervo técnico da A3A, trata a governança como a estrutura que organiza sistemas, processos, papéis, responsabilidades e modelos de decisão do projeto. Nesse contexto, a publicação apresenta a RACI como um exemplo de mecanismo de governança. Isso é relevante porque desloca a ferramenta do campo de “planilha de tarefas” para o campo de accountability, autoridade e coordenação.

Em um projeto de engenharia, uma mesma entrega pode atravessar vários níveis. O projetista produz, um coordenador verifica, o Owner’s Engineer analisa, operação valida um requisito e o proprietário toma a decisão de aceitar ou não determinado resultado. Se a RACI tratar tudo isso como uma única atividade genérica, ela esconderá justamente as fronteiras que deveria esclarecer.

Por isso, a matriz deve ser coerente com contrato, estrutura organizacional, matriz de autoridade, gestão de interfaces, plano de comunicação e fluxos de mudança. Quando esses instrumentos apontam para responsáveis diferentes, existe uma inconsistência de governança que precisa ser resolvida — não apenas uma célula a ser corrigida.

O que a ABNT NBR ISO 21502 acrescenta à lógica de responsabilidades

A ABNT NBR ISO 21502:2021, consultada no Knowledge Base da A3A, não prescreve uma matriz RACI obrigatória, mas estabelece a base que justifica seu uso. A norma orienta que a organização temporária do projeto defina papéis, responsabilidades e autoridades, possua linhas de reporte claras e seja comunicada a todos os envolvidos.

A norma também exige que as responsabilidades sejam suficientemente claras para que cada pessoa compreenda não apenas o seu papel, mas também os papéis das pessoas com quem trabalha. Em engenharia multidisciplinar, essa orientação é especialmente importante: projetista, fornecedor, fiscalização, operação e proprietário precisam conhecer as fronteiras entre produzir, verificar, recomendar, autorizar e aceitar.

Outro ponto central é o limite de autoridade. A ISO 21502 diferencia responsabilidades de patrocinador, gerente de projeto, líderes de pacotes de trabalho, equipe e estruturas de apoio como PMO. Ela também prevê escalonamento quando riscos, questões ou mudanças ultrapassam a autoridade delegada. Logo, marcar alguém como A sem verificar se essa função pode efetivamente tomar a decisão contradiz a própria lógica de governança.

A rastreabilidade também importa. Uma responsabilidade indicada na RACI deve ser compatível com o contrato, o plano de gestão, os procedimentos de aprovação e os documentos de delegação de autoridade. Uma “verdade na matriz” e outra “verdade no contrato” cria exposição justamente em momentos de maior criticidade: mudança de escopo, pleito, aprovação de projeto, energização, comissionamento e aceite.

Papel, função, pessoa e organização não são a mesma coisa

Uma RACI deve trabalhar preferencialmente com papéis ou funções, e não apenas com nomes de pessoas. Pessoas podem ser substituídas; a responsabilidade institucional precisa permanecer. Colunas como “Gerente do Projeto”, “Coordenação Elétrica”, “Owner’s Engineer”, “Operação”, “Fornecedor do Sistema” e “Fiscalização” tendem a ser mais robustas que nomes individuais.

Também é importante manter consistência de nível. Misturar em uma mesma matriz uma empresa, uma pessoa, uma disciplina e um departamento sem critério pode produzir ambiguidade. Em projetos maiores, pode haver uma camada contratual por organização e outra camada operacional por função. O objetivo não é produzir a matriz mais detalhada possível, mas o nível de detalhe necessário para eliminar dúvidas sobre responsabilidade e decisão.

Diferença entre Responsible e Accountable

A maior dificuldade no uso da matriz RACI costuma estar na diferença entre Responsible e Accountable.

O Responsible é quem executa a atividade. Pode haver mais de uma pessoa ou equipe responsável pela execução, embora seja recomendável evitar excesso de responsáveis para não diluir o trabalho.

O Accountable é quem responde pela aprovação ou pelo resultado final. Em geral, deve existir apenas um accountable por atividade. Quando há muitos aprovadores finais, a decisão fica lenta, conflituosa ou sem dono.

Papel	Pergunta que responde	Exemplo em engenharia
Responsible	Quem faz?	Projetista elabora o desenho técnico
Accountable	Quem aprova ou responde pelo resultado?	Coordenador técnico aprova a entrega
Consulted	Quem precisa opinar antes?	Operação valida requisito de manutenção
Informed	Quem precisa saber depois?	Gestão do contrato recebe atualização

Exemplo de matriz RACI em projetos de engenharia

A matriz RACI normalmente cruza atividades com papéis, equipes ou partes interessadas. O exemplo abaixo mostra uma aplicação simplificada em um projeto técnico.

Atividade	Contratante	Consultoria Técnica	Projetista	Fornecedor	Operação
Definir requisitos técnicos	A	R	C	I	C
Elaborar projeto básico	A	R	C	I	C
Avaliar proposta técnica	A	R	C	C	I
Executar instalação	I	C	C	R	I
Acompanhar testes	A	R	C	R	C
Validar aceite técnico	A	R	C	C	C
Receber documentação final	A	R	C	R	I

Esse modelo deve ser adaptado ao contrato, ao porte do projeto e ao nível de criticidade da entrega. Em projetos maiores, a matriz pode ser detalhada por disciplina, pacote de trabalho, etapa ou entregável.

Quando criar uma matriz RACI?

A matriz RACI deve ser criada antes que as atividades críticas comecem. O melhor momento costuma ser durante o planejamento, estruturação do escopo, elaboração do projeto básico, contratação ou mobilização do projeto.

Ela é especialmente útil quando há:

• múltiplos fornecedores ou disciplinas;
• interfaces entre projeto, obra, operação e manutenção;
• contratante com várias áreas envolvidas;
• processo de aprovação técnica complexo;
• serviços de engenharia consultiva ou Owner’s Engineering;
• comissionamento e aceite técnico;
• due diligence técnica ou auditoria;
• risco de conflito entre escopo, contrato e operação.

Como montar uma matriz RACI passo a passo

Uma matriz RACI eficiente depende de clareza de escopo e de bom entendimento das partes envolvidas.

1. Liste as atividades ou entregáveis

Comece pelas atividades relevantes do projeto. Em engenharia, pode ser mais útil trabalhar por entregáveis: projeto básico, matriz de requisitos, proposta técnica, revisão de projeto, relatório de due diligence, plano de testes, comissionamento, documentação final e aceite técnico.

2. Liste os papéis envolvidos

Inclua áreas, equipes ou funções, não necessariamente nomes individuais. Exemplos: contratante, consultoria técnica, projetista, integrador, fornecedor, operação, manutenção, compras, jurídico, fiscalização e Owner’s Engineering.

3. Atribua R, A, C e I

Para cada atividade, defina quem executa, quem aprova, quem deve ser consultado e quem deve ser informado. Evite excesso de responsáveis e procure manter apenas um accountable por linha.

4. Revise conflitos e lacunas

Verifique se há atividades sem responsável, sem aprovador, com muitos aprovadores ou com partes críticas ausentes. Esses pontos indicam risco de governança.

5. Valide com os stakeholders

A matriz RACI só funciona se as partes envolvidas reconhecem os papéis definidos. Ela deve ser validada com as áreas impactadas antes da execução. A análise de stakeholders ajuda a identificar quem precisa participar dessa validação e sobre quais decisões possui influência, impacto ou legitimidade.

6. Atualize quando o projeto mudar

Projetos mudam. Se escopo, fornecedores, fases ou responsabilidades forem alterados, a matriz RACI também deve ser revisada.

Regras práticas para uma boa matriz RACI

Regra	Por que importa
Ter ao menos um Responsible por atividade	Evita atividade sem executor
Ter apenas um Accountable por atividade	Evita decisão sem dono claro
Evitar excesso de Consulted	Reduz lentidão no fluxo de decisão
Definir Informed com critério	Evita comunicação excessiva ou insuficiente
Revisar atividades sem R ou A	Indica lacuna de responsabilidade
Revisar atividades com muitos R	Pode indicar responsabilidade diluída
Alinhar a matriz ao contrato	Evita conflito entre governança e obrigação contratual
Atualizar após mudanças de escopo	Mantém a matriz útil durante o projeto

Matriz RACI em Engenharia Consultiva

Na engenharia consultiva, a matriz RACI é útil porque organiza a relação entre contratante, consultoria, projetistas, fornecedores e operação.

Ela ajuda a definir quem analisa, quem recomenda, quem aprova, quem executa e quem precisa ser informado. Isso é importante porque a consultoria técnica normalmente apoia a decisão, mas nem sempre é a autoridade final de aprovação.

Por exemplo, em uma análise de proposta técnica, a consultoria pode ser responsável por avaliar tecnicamente, enquanto o contratante é accountable pela decisão de contratação. Compras e jurídico podem ser consultados, e operação pode ser informada ou consultada dependendo do impacto.

Esse uso se conecta diretamente ao papel da Engenharia Consultiva no apoio a decisões técnicas do contratante.

Matriz RACI em Owner’s Engineering

No Owner’s Engineering, a matriz RACI é especialmente importante porque o Owner’s Engineer atua em nome do proprietário, mas não substitui todas as responsabilidades do contratante.

A matriz ajuda a definir limites de atuação entre proprietário, Owner’s Engineer, EPCista, projetistas, fiscalização, operação e fornecedores.

Atividade	Proprietário	Owner’s Engineer	EPCista	Operação
Definir requisitos do proprietário	A	R	C	C
Revisar projeto executivo	A	R	R	C
Acompanhar avanço técnico	I	R	R	I
Validar testes e comissionamento	A	R	R	C
Recomendar aceite técnico	A	R	C	C

Essa clareza reduz conflito de autoridade e melhora a governança técnica do projeto.

Matriz RACI em Due Diligence Técnica

Em uma due diligence técnica, a matriz RACI ajuda a organizar a coleta de documentos, entrevistas, vistorias, análise de evidências, validação de achados, matriz de riscos e plano de ação.

Sem clareza de papéis, a due diligence pode atrasar porque documentos não são enviados, áreas não respondem, fornecedores não disponibilizam informações ou decisões ficam pendentes.

Esse uso se conecta ao artigo Relatório de Due Diligence Técnica: evidências, matriz de riscos e plano de ação, porque a qualidade do relatório depende da qualidade das informações levantadas e da definição dos responsáveis por fornecê-las.

Matriz RACI na análise de proposta técnica

Na análise de proposta técnica de engenharia, a matriz RACI ajuda a definir quem compara escopo, quem avalia preço, quem verifica riscos, quem consulta operação, quem interage com fornecedor e quem aprova a recomendação final.

Etapa	Engenharia	Compras	Jurídico	Operação	Consultoria Técnica
Definir critérios técnicos	A	C	I	C	R
Solicitar esclarecimentos	C	A/R	I	C	R
Equalizar propostas	A	C	I	C	R
Avaliar riscos contratuais	C	R	A	I	C
Emitir recomendação técnica	A	I	I	C	R

Essa organização evita que a decisão de contratação fique fragmentada entre áreas sem responsável final definido.

Matriz RACI no projeto básico

O projeto básico depende de definições claras de escopo, requisitos, premissas, interfaces, critérios de aceite e responsabilidades. A matriz RACI ajuda a definir quem fornece informações, quem consolida requisitos, quem valida premissas e quem aprova o documento final.

Ela também pode ser usada junto com o checklist de projeto básico, especialmente antes de licitar ou contratar uma obra ou serviço técnico.

Matriz RACI no comissionamento e aceite técnico

No comissionamento e no aceite técnico, a matriz RACI é importante porque testes, pendências, evidências e documentação final envolvem muitas partes.

Atividade	Contratante	Comissionamento	Fornecedor	Operação
Definir critérios de aceite	A	R	C	C
Executar testes	I	C	R	C
Registrar evidências	I	R	R	I
Classificar pendências	A	R	C	C
Validar aceite técnico	A	R	C	C
Receber treinamento	A	C	R	R

Essa matriz evita que pendências críticas fiquem sem dono e que o aceite seja assinado sem validação adequada.

Matriz RACI em compatibilização de projetos BIM

Em projetos multidisciplinares e BIM, a matriz RACI ajuda a definir responsabilidades entre coordenação, modeladores, projetistas, contratante, compatibilização e operação.

Ela pode apoiar decisões sobre quem atualiza o modelo, quem valida interferências, quem aprova mudanças, quem responde por disciplina e quem deve ser informado em cada ciclo de revisão.

Esse uso complementa o artigo sobre Compatibilização de Projetos em BIM.

Matriz RACI x matriz de riscos

A matriz RACI e a matriz de riscos são ferramentas diferentes, mas complementares.

Ferramenta	Finalidade	Pergunta principal
Matriz RACI	Definir papéis e responsabilidades	Quem faz, aprova, consulta e informa?
Matriz de riscos	Classificar riscos e prioridades	O que pode afetar o projeto e como responder?

Em projetos de engenharia, a matriz de riscos pode indicar um risco crítico, enquanto a matriz RACI define quem será responsável por tratar esse risco, quem aprova a resposta, quem deve ser consultado e quem precisa ser informado.

Erros comuns ao usar matriz RACI

Erro	Consequência
Ter vários Accountable na mesma atividade	Decisão lenta ou sem dono claro
Não definir Responsible	Atividade sem executor
Colocar todo mundo como Consulted	Processo pesado e lento
Informar pessoas demais	Ruído de comunicação
Não validar a matriz com as partes	Baixa adesão durante o projeto
Não atualizar após mudança de escopo	Matriz fica desatualizada
Confundir RACI com organograma	Foco sai das atividades e vira hierarquia
Não conectar a matriz ao contrato	Risco de conflito entre prática e obrigação contratual

RACI não substitui contrato, organograma, EAP ou plano de comunicação

Uma das causas de matrizes excessivamente grandes é tentar fazer a RACI responder perguntas que pertencem a outros instrumentos. O contrato define obrigações, direitos e responsabilidades formais; o organograma mostra relações hierárquicas; a EAP/WBS decompõe o escopo; a análise de stakeholders identifica influência, impacto e necessidade de envolvimento; o plano de comunicação define informação, canal e frequência; a matriz de interfaces controla fronteiras e dependências.

A RACI conecta parte desses elementos ao trabalho cotidiano. Ela ajuda a responder quem executa, quem responde pelo resultado, quem deve contribuir antes de uma decisão e quem precisa ser informado. Se houver conflito entre a matriz e uma obrigação contratual, o problema não é resolvido “seguindo a RACI”: a inconsistência precisa ser analisada e a fonte formal de autoridade preservada.

RACI e análise de stakeholders: C e I não devem ser escolhidos ao acaso

Os papéis Consulted e Informed dependem diretamente da compreensão das partes interessadas. O PMBOK 8 descreve a análise de stakeholders a partir de dimensões como posição, papel, interesse, expectativas, atitude, conhecimento e influência. O artigo sobre análise de stakeholders aprofunda essa lógica para projetos de engenharia.

Uma área pode ter baixa autoridade formal e ainda possuir conhecimento crítico que exige consulta. Operação pode não executar o projeto, mas ser fortemente impactada pela solução e precisar participar da definição de requisitos e do aceite. Um órgão regulador pode não aparecer na equipe, mas suas decisões podem condicionar marcos. Por isso, C e I não devem ser distribuídos apenas pela hierarquia ou pela lista de participantes das reuniões.

O mapeamento de stakeholders ajuda a não esquecer atores relevantes, enquanto a matriz de stakeholders auxilia a priorizar o nível de atenção. A RACI utiliza essas informações para uma pergunta mais operacional: em qual atividade ou decisão essa parte realmente precisa atuar?

RACI e plano de comunicação: responsabilidade não é fluxo de informação

Marcar uma função como I não significa colocá-la em cópia em todos os e-mails. Marcar uma função como C também não significa convidá-la para todas as reuniões. A RACI identifica a necessidade de participação; o plano de comunicação em projetos deve definir conteúdo, canal, momento, frequência, formato e mecanismo de feedback.

A ABNT NBR ISO 21502 orienta que a comunicação seja planejada conforme as necessidades das partes e que as interações sejam eficazes. Uma equipe pode ter uma RACI tecnicamente correta e ainda falhar porque consultas ocorrem tarde, decisões não são registradas ou pessoas informadas recebem volume excessivo sem contexto. A matriz é uma entrada para o sistema de comunicação, não seu substituto.

RACI e gestão de interfaces: responsabilidade dos dois lados da fronteira

Interfaces técnicas e contratuais são pontos em que a clareza de responsabilidade produz impacto direto. Uma interface existe porque dois ou mais elementos dependem um do outro: podem trocar energia, sinal, informação, espaço, requisitos, documentos, dados ou condições operacionais.

Imagine uma integração entre um sistema de segurança e a rede corporativa. O integrador pode ser R pela configuração de sua aplicação; TI pode ser R pela configuração da rede sob sua administração; o proprietário pode ser A por uma decisão de arquitetura; cibersegurança pode ser C e operação pode ser C ou I. Se a linha disser apenas “integração”, múltiplos R parecem conflito. Se forem separados os parâmetros, entregas e decisões, a responsabilidade fica compreensível.

Por isso, RACI e Interface Management precisam conversar. A matriz de interfaces mostra onde existem dependências; a RACI ajuda a organizar quem age, quem decide, quem fornece informação e quem deve participar do fechamento da interface.

RACI em riscos, questões e mudanças

A ISO 21502 trata riscos e questões com atribuição clara de responsabilidade e prevê escalonamento quando uma decisão ultrapassa a autoridade da equipe. Essa lógica é diretamente aplicável à RACI. Um gerente de projeto pode ser R por coordenar a análise de uma questão, enquanto o patrocinador é A por uma decisão que ultrapassa o limite delegado. Especialistas entram como C e áreas impactadas podem ser I ou C.

Na gestão de riscos em projetos, definir um risk owner sem esclarecer sua autoridade e suas interfaces também pode gerar responsabilidade nominal. O registro de riscos precisa identificar quem conduz a resposta, quem autoriza recursos ou mudanças e quando o assunto deve ser escalado.

No controle de mudanças, a separação é ainda mais evidente: quem solicita não é necessariamente quem analisa; quem analisa não é necessariamente quem autoriza; quem implementa não é necessariamente quem verifica. Uma RACI específica para change control pode impedir alterações executadas sem análise de impacto ou aprovação válida.

RACI em requisitos, verificação, validação e aceite

Projetos de engenharia frequentemente tratam elaboração, revisão, verificação, validação e aceite como se fossem o mesmo ato. Não são. A gestão de requisitos precisa identificar quem fornece necessidades, quem consolida requisitos, quem verifica sua implementação e quem valida se a solução atende ao uso pretendido.

Em aceite técnico, um fornecedor pode ser R por executar testes e entregar evidências. Uma consultoria pode ser R por analisar resultados e recomendar aceite. O proprietário, porém, pode continuar A pela decisão formal. Colocar a consultoria como A apenas porque ela realizou a análise pode transferir, no papel, uma autoridade que não foi delegada contratualmente.

RACI em contratos e Owner’s Engineering

A matriz RACI não transfere obrigação contratual. Se o contrato atribui ao contratado a responsabilidade pelo projeto executivo, uma planilha interna não pode descaracterizar essa obrigação. Da mesma forma, o fato de um Owner’s Engineer revisar documentos, acompanhar testes ou recomendar decisões não significa que ele passou a ser responsável pela execução técnica do contratado.

Em Owner’s Engineering, a RACI é particularmente valiosa para separar recomendação técnica de decisão do proprietário. O Owner’s Engineer pode conduzir Design Reviews, análises, diligências, fiscalização, verificação de evidências e recomendações. Decisões relacionadas a orçamento, apetite de risco, alterações contratuais e aceite formal podem permanecer com o proprietário.

Como o modelo de contratação altera a matriz RACI

A PMI Construction Extension disponível no KB mostra como projetos de engenharia e construção reúnem proprietário, projetista, construtor, especialistas, órgãos reguladores e outras partes, e como as responsabilidades mudam conforme a estratégia de entrega. Embora seja uma referência histórica, essa observação permanece útil para compreender por que uma RACI não deve ser copiada de um contrato para outro.

No design-bid-build, projeto e construção tendem a estar separados: projetista responde pela documentação de projeto, contratado executa e o proprietário administra aprovações e mudanças conforme os contratos. No design-build, uma única organização concentra projeto e construção, reduzindo algumas interfaces externas, mas mantendo a necessidade de separar produção, verificação e aceitação.

No EPC, a contratada assume ampla integração de engenharia, procurement e construção. A RACI precisa respeitar essa alocação para não recriar microgerenciamento pelo proprietário, mas deve continuar identificando requisitos, marcos, mudanças, interfaces externas e aceites que permanecem sob autoridade do owner. Em EPCM ou múltiplos pacotes, a quantidade de interfaces aumenta porque a organização gerenciadora coordena atividades que são executadas por outras contratadas.

Portanto, uma RACI tecnicamente boa para EPC pode ser inadequada para EPCM, Design-Build ou uma contratação fragmentada. O contrato e a estratégia de entrega são entradas obrigatórias para a matriz.

A RACI muda ao longo do ciclo de vida do projeto

A organização e as responsabilidades não permanecem estáticas. Na concepção, patrocinador e proprietário concentram decisões de investimento, enquanto especialistas produzem estudos. No planejamento e projeto básico, entram requisitos, interfaces e estratégia de contratação. No projeto executivo, projetistas e vendors assumem forte responsabilidade de produção, enquanto coordenação e Design Review ganham peso.

Durante procurement e fabricação, engenharia, suprimentos, jurídico e fornecedores compartilham diferentes responsabilidades. Na implantação, contratadas de campo, fiscalização, planejamento, segurança e operação ganham protagonismo. No comissionamento e handover, a distribuição muda novamente para testes, evidências, treinamento, documentação, validação operacional e aceite.

Isso justifica matrizes específicas por fase ou uma matriz controlada por revisões. A mesma coluna “Contratante” pode ter papel de A em concepção, C em determinados detalhes de projeto e novamente A no aceite final. A governança deve acompanhar a evolução do empreendimento.

Como controlar a RACI como documento vivo

Uma matriz que orienta decisões precisa ser controlada como informação de projeto. Deve possuir responsável pela manutenção, versão, data, escopo de aplicação, fonte de autoridade e gatilhos de revisão. Mudanças de fase, fornecedor, estrutura organizacional, contrato, escopo ou delegação de autoridade são eventos que justificam revisão.

Em ambientes com GED ou CDE, a equipe deve consultar uma fonte única. Versões locais paralelas são especialmente perigosas porque uma atualização de responsabilidade pode ser conhecida por uma área e ignorada por outra. O registro de stakeholders também deve acompanhar mudanças relevantes de funções, influência e participação.

Indicadores que mostram se a RACI está funcionando

O sucesso da RACI não se mede pela quantidade de células preenchidas, mas pela redução de ambiguidade. Alguns sinais de baixa maturidade são decisões vencidas por falta de autoridade clara, atividades iniciadas sem responsável, questões escaladas repetidamente por disputa de papel, mudanças implementadas sem aprovação, interfaces reabertas e reuniões cuja pauta recorrente é descobrir “quem deveria resolver”.

Também vale observar a distribuição vertical da matriz. Uma função com A em quase todas as linhas pode virar gargalo decisório; uma disciplina marcada como C em tudo pode paralisar o fluxo; vários R sem delimitação podem indicar que o objeto da linha está amplo demais. A leitura vertical complementa a leitura atividade por atividade e permite detectar problemas de desenho organizacional.

Como o PMBOK 8 apoia o uso da matriz RACI

O PMBOK 8ª edição é uma referência importante para o uso da matriz RACI porque reforça governança, foco em valor, stakeholders, recursos, áreas de foco do projeto, tailoring e procurement.

Elemento do PMBOK 8	Aplicação na matriz RACI
Governance Performance Domain	Define como decisões, responsabilidades e supervisão são organizadas
Stakeholders Performance Domain	Ajuda a identificar partes envolvidas, influência e necessidade de comunicação
Resources Performance Domain	Relaciona recursos, equipes e responsabilidades de execução
Scope Performance Domain	Conecta responsabilidades a entregáveis e requisitos
Focus Areas	Permite aplicar RACI em iniciação, planejamento, execução, monitoramento e encerramento
Procurement Appendix	Apoia definição de papéis em contratação, fornecedores, seleção e gestão contratual
Tailoring	Adapta a matriz ao porte, complexidade e criticidade do projeto

Checklist prático para revisar uma matriz RACI

Pergunta	Status	Observação
Todas as atividades críticas estão listadas?	Sim / Não / Parcial	Evitar lacunas de governança
Cada atividade tem pelo menos um Responsible?	Sim / Não / Parcial	Garantir executor definido
Cada atividade tem apenas um Accountable?	Sim / Não / Parcial	Evitar decisão sem dono
Os Consulted são realmente necessários?	Sim / Não / Parcial	Evitar excesso de consulta
Os Informed foram definidos com critério?	Sim / Não / Parcial	Evitar ruído de comunicação
A matriz está alinhada ao contrato?	Sim / Não / Parcial	Evitar conflito com obrigações formais
A matriz foi validada com os stakeholders?	Sim / Não / Parcial	Aumentar adesão
A matriz será atualizada quando houver mudança?	Sim / Não / Parcial	Manter utilidade durante o projeto

Referências técnicas

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gerenciamento de projetos, programas e portfólios — Orientação sobre gerenciamento de projetos. Rio de Janeiro: ABNT, 2021.

[2] PROJECT MANAGEMENT INSTITUTE. The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8. ed. Newtown Square: PMI, 2025. Disponível em: https://www.pmi.org/standards/pmbok.

[3] PROJECT MANAGEMENT INSTITUTE. Construction Extension to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition. Newtown Square: PMI, 2003.

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Disponível em: https://www.iso.org/standard/74947.html.

Perguntas frequentes

O que é matriz RACI?

É uma matriz de responsabilidades que associa atividades ou entregáveis aos papéis Responsible, Accountable, Consulted e Informed, deixando explícito quem executa, quem responde pelo resultado, quem deve ser consultado e quem precisa ser informado.

O que significa RACI?

RACI significa Responsible, Accountable, Consulted e Informed. Em português, correspondem aproximadamente a responsável pela execução, responsável final ou aprovador, consultado e informado.

Qual a diferença entre Responsible e Accountable?

Responsible executa ou coordena a execução da atividade. Accountable responde pelo resultado e pela decisão final. Uma boa matriz evita múltiplos Accountable para a mesma atividade.

Como montar uma matriz RACI?

Liste atividades ou entregáveis, identifique os papéis envolvidos, atribua R, A, C e I, revise lacunas e conflitos, valide com os stakeholders e atualize a matriz sempre que responsabilidades ou interfaces mudarem.

Matriz RACI é útil em projetos de engenharia?

Sim. Ela reduz ambiguidades entre contratante, projetistas, fiscalização, fornecedores, operação e demais partes, principalmente em interfaces, aprovações, revisões, comissionamento e aceite.

Matriz RACI substitui contrato?

Não. A RACI organiza responsabilidades operacionais e de governança, mas não altera obrigações contratuais, competências legais ou responsabilidades profissionais formalmente estabelecidas.

Quem deve aprovar uma matriz RACI?

A validação deve envolver os responsáveis pelas principais entregas e decisões, especialmente quem exerce o papel Accountable e as áreas ou organizações afetadas pelas atribuições.

Quando revisar a matriz RACI?

Sempre que houver mudança relevante de escopo, equipe, contrato, fornecedor, fase do projeto, responsabilidades, interfaces ou processo de aprovação.

Materiais técnicos complementares

Soluções relacionadas

• Gestão de Contratos, Escopo e Entregáveis
• Gestão de Requisitos, Evidências e Critérios de Aceite
• Gestão de Pendências, RFIs e Não Conformidades

Serviços relacionados

• Gerenciamento de Projetos de Engenharia
• Engenharia do Proprietário (Owner’s Engineering)

Conteúdos principais sobre o tema

• Gestão de stakeholders em projetos: identificação, engajamento e comunicação
• Análise de Stakeholders: influência, impacto, legitimidade, urgência e priorização em projetos
• Matriz de Stakeholders: influência, interesse, impacto e priorização em projetos
• Gestão de Interfaces em Projetos de Engenharia

Conteúdos técnicos correlatos

• Plano de Comunicação em Projetos
• Registro de Stakeholders
• Engajamento de Stakeholders
• Gestão de Conflitos em Projetos de Engenharia