
Como fazer reunião de kickoff: preparação, pauta e roteiro
| 04/11/26Veja como preparar e conduzir uma reunião de kickoff de projeto: documentos prévios, participantes, pauta, perguntas de alinhamento e registro dos próximos passos.
Aprenda a montar e validar uma matriz RACI, com exemplo preenchido, modelo para planilha e checklist para corrigir tarefas sem dono e aprovações confusas.
Para fazer uma matriz RACI, liste as entregas nas linhas, coloque as pessoas ou papéis nas colunas e indique quem executa (R), quem responde pela entrega e aprova (A), quem é consultado (C) e quem recebe atualizações (I). Confira se cada linha tem pelo menos um R e exatamente um A e, antes de usar a matriz, discuta as atribuições com os envolvidos.
Também chamada de matriz de responsabilidades, ela registra as expectativas sobre cada entrega. Isso ajuda a tratar tarefas que ninguém assume, aprovações ambíguas e atribuições sem autoridade para decidir. Nas células sem participação, use —; o acúmulo A/R exige autoridade para executar e aprovar, além de registro explícito.
Em resumo:


RACI vem de Responsible, Accountable, Consulted e Informed. Em português, os quatro papéis são Responsável, Aprovador, Consultado e Informado:
Para distinguir R de A, faça duas perguntas: quem realiza o trabalho? Esse é o R. Quem responde pelo resultado e tem autoridade para considerá-lo concluído? Esse é o A. Já a diferença entre C e I está na participação: o consultado contribui para a entrega; o informado precisa acompanhar o que aconteceu.

Decida se a matriz cobre um projeto inteiro, uma fase ou uma iniciativa específica. Depois, liste as tarefas ou entregas desse recorte. Se o projeto já tiver uma EAP (estrutura analítica do projeto), as entregas dela servem como ponto de partida para as linhas. Na sequência, identifique os participantes, atribua os papéis e revise a matriz com os envolvidos.
Prefira resultados verificáveis a rótulos vagos. “Termos de uso revisados e aprovados” permite discutir execução e aprovação. “Jurídico” identifica uma área, mas não diz o que ela entrega.
Se houver dúvida sobre o A, confira se falta definir autoridade ou se a linha reúne resultados distintos. Separe entregas com aprovações diferentes. Agrupe linhas apenas se formarem um resultado coerente e mantiverem claras as responsabilidades.
Use pessoas, cargos ou áreas que participam das entregas; o mapeamento de stakeholders ajuda a lembrar quem precisa ser consultado ou informado. Ao nomear uma área, identifique quem a representa e quem assumirá a responsabilidade final nas linhas em que ela aparece como A. O nome da área não substitui essa identificação.
Uma tabela compartilhada em planilha é suficiente para registrar as atribuições. Mantenha os nomes ou cargos consistentes entre a matriz e os demais registros do projeto.
Preencha uma linha por vez: primeiro a execução, depois a responsabilidade final e, por último, consulta e comunicação.
A possibilidade de vários executores e a regra de um único A aparecem neste exemplo de atribuição de papéis em uma matriz RACI. Com dois R, registre quem faz cada parte; marcar a mesma letra em duas colunas não explica essa divisão.
A mesma pessoa pode acumular execução e aprovação, desde que tenha autoridade para isso e o acúmulo esteja explícito como A/R. É uma possibilidade, não um padrão a aplicar a todas as entregas.
Apresente a proposta em reunião e percorra as linhas com os envolvidos, em vez de apenas enviar a planilha. Confirme se os executores entenderam o trabalho, se o A aceita responder pela entrega e tem autoridade para aprová-la e se C e I sabem qual participação se espera deles.
Se alguém disser que não sabia que era responsável por uma entrega, reveja a atribuição. No cenário hipotético a seguir, por exemplo, confirme com o representante de TI a execução do desenvolvimento antes de tratar a linha como acordada.
Registre as decisões na própria matriz e compartilhe a versão corrigida. Pendências de autoridade ou de execução precisam de resolução explícita, não apenas de uma letra preenchida.

Este exemplo é hipotético e didático: um projeto de lançamento de portal de autoatendimento para clientes. A distribuição das letras ilustra as regras, sem representar um caso real ou um padrão obrigatório.
Cada coluna corresponde a uma pessoa identificada para representar a área. Na aplicação ao seu projeto, registre o nome ou cargo dessa pessoa, especialmente nos papéis A e R.
| Entrega | Gerente do projeto | Produto | TI | Atendimento | Jurídico | Patrocinador |
|---|---|---|---|---|---|---|
| Escopo e requisitos aprovados | R | R | C | C | I | A |
| Termos de uso e política de privacidade revisados | I | C | I | I | A/R | I |
| Portal desenvolvido e integrado | C | A | R | C | I | I |
| Roteiro de atendimento e material de ajuda prontos | A | C | C | R | I | I |
| Teste de aceitação com usuários concluído | A | R | C | R | — | I |
| Decisão de liberar o portal registrada | R | C | C | C | C | A |
Legenda: R = executa; A = responde pela entrega e aprova; C = é consultado; I = é informado; — = não participa; A/R = executa e aprova, com autoridade para acumular os papéis.
Todas as linhas têm ao menos um R e exatamente um A. Nas duas linhas com múltiplos executores, a divisão didática é esta:
No desenvolvimento, TI executa e Produto aprova. Na linha dos termos de uso, a premissa do cenário é que o representante do Jurídico tenha autoridade para executar e aprovar o próprio texto. Na liberação do portal, quatro áreas são consultadas, mas a aprovação final cabe ao patrocinador; o gerente organiza e registra a decisão.
Copie a tabela para uma planilha ou tabela compartilhada. Substitua os campos entre colchetes, acrescente entregas e ajuste as colunas aos participantes do projeto. As células vazias são espaços para preenchimento, não atribuições concluídas.
| Entrega verificável | [Pessoa ou cargo 1] | [Pessoa ou cargo 2] | [Pessoa ou cargo 3] | [Pessoa ou cargo 4] | [Pessoa ou cargo 5] | Observações |
|---|---|---|---|---|---|---|
| [Entrega 1] | ||||||
| [Entrega 2] | ||||||
| [Entrega 3] | ||||||
| [Entrega 4] | ||||||
| [Entrega 5] |
Legenda para manter junto do modelo: R = executa; A = responde pela entrega e dá a aprovação final; C = contribui por consulta; I = recebe atualizações; — = não participa; A/R = acumula execução e aprovação, com autoridade e justificativa registradas.

A tabela reúne situações para conferir durante a revisão. As causas são hipóteses: confirme o que está acontecendo com as pessoas envolvidas antes de alterar as atribuições.
| Sintoma | Causa a verificar | Correção |
|---|---|---|
| Entrega sem R | A execução não foi atribuída ou a entrega está vaga. | Esclareça o resultado, defina o executor com os envolvidos e registre a atribuição. |
| Dois A na mesma linha | A linha reúne validações distintas ou a responsabilidade final não foi definida. | Separe entregas ou validações distintas, cada uma com um A. Para uma única entrega, defina o responsável final. Atribua C, I ou — ao outro participante conforme sua participação. |
| A sem autoridade | A pessoa indicada depende de outra para dar a aprovação final. | Identifique quem tem autoridade ou ajuste explicitamente a autoridade da pessoa indicada. |
| Muitos C | Os participantes foram incluídos sem definir a contribuição esperada. | Confira a contribuição de cada C e o momento da consulta. Use I apenas para quem precisa de atualizações e — para quem não participa. |
| I em todas as células restantes | A comunicação foi atribuída sem avaliar sua necessidade. | Mantenha I apenas em quem precisa acompanhar o andamento ou a conclusão. |
Para tratar uma atividade sem dono, esclareça a entrega, defina quem responde por ela, atribua a execução e confirme a decisão com os envolvidos. No exemplo hipotético, se o roteiro de atendimento estivesse sem R, o gerente do projeto, como A, discutiria com Atendimento quem escreveria o material. A decisão ficaria registrada na matriz.
A revisão e atualização da matriz RACI ao longo do projeto mantém o registro alinhado às atribuições atuais. Combine revisões nos marcos e retome as linhas afetadas por mudanças.
Confira a matriz após alterações de escopo, entrada de uma área ou fornecedor, troca de pessoas e renegociação de prazos que modifique quem executa ou aprova. Registre a nova data, confirme os papéis alterados com os envolvidos e compartilhe a versão atualizada. Se o relatório de status do projeto registrar um novo responsável ou aprovador para uma entrega, atualize a linha correspondente na matriz.
O foco da matriz é a responsabilidade por entregas, não os níveis de autonomia para delegar decisões. Para combinar a autonomia de quem recebe uma tarefa, veja como delegar tarefas na empresa.
R executa o trabalho. A responde pela entrega e dá a aprovação final. São papéis distintos; a mesma pessoa pode acumulá-los se tiver autoridade para isso e a matriz registrar o acúmulo como A/R.
Não para a mesma entrega: a regra é exatamente um A por linha. Se houver aprovações distintas, confira se representam entregas ou validações que precisam de linhas próprias. Não transforme uma aprovação necessária em consulta apenas para ajustar a tabela.
Sim. Cada tarefa precisa de pelo menos um executor identificado. É possível atribuir mais de um R, desde que esteja claro qual parte do trabalho cabe a cada pessoa.
Descreva o resultado esperado, identifique quem responde pela entrega, defina quem executa e registre os papéis. Confirme a atribuição com os envolvidos antes de usar a matriz como referência.
Defina os consultados pela contribuição necessária à entrega, sem adotar uma quantidade fixa como regra do modelo. Para cada C, esclareça o que será consultado e em que momento. Quem precisa apenas acompanhar recebe I; quem não participa recebe —.
Combine revisões nos marcos do projeto e revise as linhas afetadas por mudanças de escopo, pessoas, áreas, fornecedores ou prazos que alterem as atribuições.
Sim. A aplicação não se limita à tecnologia e abrange projetos de portes variados. Ajuste o número de linhas e colunas ao projeto, preservando pelo menos um R e exatamente um A por entrega.
O exemplo mostra como distribuir os papéis; o modelo permite registrar as escolhas do projeto. A revisão conecta os dois: execução identificada, um responsável final com autoridade, consultas necessárias e comunicação definida. As atribuições discutidas com os envolvidos e atualizadas nas mudanças formam a referência para acompanhar quem executa, quem aprova e quem participa de cada entrega.


Veja como preparar e conduzir uma reunião de kickoff de projeto: documentos prévios, participantes, pauta, perguntas de alinhamento e registro dos próximos passos.

Veja como preencher um plano de comunicação de projeto com audiência, informação, canal, frequência, responsável e gatilhos de escalonamento — e como revisá-lo.

Aprenda a montar e validar uma matriz RACI, com exemplo preenchido, modelo para planilha e checklist para corrigir tarefas sem dono e aprovações confusas.