Encerramento no PMI: aceite, transição, documentação final e lições aprendidas acionáveis

O que é “encerrar” no PMI (e por que não é só parar de trabalhar)

No PMI/PMBOK, encerramento é o conjunto de atividades para finalizar formalmente o projeto (ou uma fase), confirmando que as entregas foram concluídas e aceitas, que a transição para operação/sustentação foi realizada, que contratos e pendências foram resolvidos e que o conhecimento gerado foi registrado de forma reutilizável. Encerrar bem reduz disputas (“faltou isso”), evita que o time fique preso em correções intermináveis e aumenta a chance de benefícios se materializarem após a entrega.

Um encerramento completo costuma responder a quatro perguntas objetivas:

• Entrega: tudo o que foi combinado foi entregue e verificado?
• Aceite: existe evidência formal de aceitação (ou registro de exceções)?
• Transição: operação/sustentação consegue manter e evoluir o que foi entregue?
• Aprendizado: o que deve ser repetido/evitado e quem fará o quê a partir disso?

Pré-requisitos mínimos para iniciar o encerramento

Antes de marcar a reunião de aceite e “dar baixa” no projeto, valide se você tem, no mínimo:

• Lista final de entregas e seus critérios de aceite (mesmo que simples).
• Registro de pendências (bugs, ajustes, itens de documentação, treinamentos) com responsável e prazo.
• Plano de handover (o que será transferido, para quem, quando e como).
• Mapa de contratos/fornecedores envolvidos e o que falta para encerrar cada um.
• Local definido para arquivamento dos artefatos (com estrutura e permissões).

Passo a passo prático do encerramento formal

1) Validação final das entregas (verificação “última milha”)

Objetivo: confirmar que cada entrega atende aos critérios acordados e que evidências estão disponíveis.

• Revise item a item: entrega, versão, data, responsável, evidência (link/arquivo), resultado do teste/validação.
• Garanta que o que será apresentado para aceite está “congelado” (ex.: versão final do documento, release final do sistema).
• Se houver itens não conformes, registre como pendência com decisão explícita: corrigir antes do aceite, aceitar com ressalva, ou mover para backlog operacional.

Exemplo prático (projeto de implantação de ferramenta): a entrega “Dashboard de indicadores” só pode ser considerada validada se os dados batem com a fonte oficial e se usuários-chave conseguem reproduzir o relatório seguindo um passo a passo.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

2) Checklist de pendências e decisão de “o que fica para depois”

Objetivo: evitar que o projeto seja encerrado com itens críticos escondidos e, ao mesmo tempo, impedir que melhorias opcionais travem o aceite.

Use um checklist simples de pendências:

• Críticas (bloqueiam aceite): impedem uso, geram risco legal/segurança, quebram requisito essencial.
• Importantes (aceite com plano): não impedem uso, mas precisam de prazo e responsável definidos.
• Oportunidades (backlog): melhorias desejáveis sem compromisso de prazo no encerramento.

Regra prática: se uma pendência não tem responsável e data, ela não é plano; é risco. No encerramento, tudo o que ficar “para depois” deve virar item formal em operação/sustentação (com dono).

3) Termo de aceite (aceite formal e rastreável)

Objetivo: registrar formalmente que o cliente/patrocinador aceitou as entregas e sob quais condições.

O termo de aceite pode ser um documento curto (1–2 páginas) ou um e-mail padronizado, desde que contenha:

• Identificação do projeto e das entregas aceitas (com versão/data).
• Critérios de aceite atendidos (ou referência ao documento de critérios).
• Ressalvas e pendências aceitas (se houver), com responsáveis e prazos.
• Data de início da garantia/suporte (quando aplicável) e condições.
• Assinatura/validação do responsável pelo aceite (nome, cargo, data).

Boa prática: inclua links diretos para as evidências (repositório, release notes, atas de validação) para reduzir disputas futuras.

4) Handover (transição para operação/sustentação)

Objetivo: garantir que quem vai operar tenha condições reais de manter o resultado do projeto.

Handover não é só “passar um arquivo”; é transferência de responsabilidade. Um handover mínimo costuma incluir:

• O que foi entregue: componentes, integrações, acessos, ambientes, contatos.
• Como operar: rotinas, SLAs, monitoramento, backups, procedimentos de incidentes.
• Como suportar: base de conhecimento, troubleshooting, limites do suporte, escalonamento.
• Como evoluir: backlog remanescente, restrições técnicas, decisões arquiteturais relevantes.
• Treinamento: público-alvo, conteúdo, presença/registro, materiais.

Exemplo prático (projeto de processo): ao entregar um novo fluxo de atendimento, o handover deve incluir o procedimento oficial, exemplos preenchidos, critérios de qualidade, e como auditar se o fluxo está sendo seguido.

5) Atualização e consolidação da documentação final

Objetivo: deixar o “pacote final” consistente, encontrável e pronto para auditoria, suporte e reutilização.

Checklist de documentação final (adapte ao seu contexto):

• Documentos de entrega: manuais, especificações finais, desenhos, scripts, configurações, release notes.
• Registros de validação: evidências de testes, homologação, checklists assinados.
• Decisões e mudanças: principais decisões, justificativas, aprovações, impactos.
• Operação: runbook, procedimentos, contatos, SLAs, matriz de suporte.
• Treinamento: materiais, gravações (se permitido), lista de presença, avaliação.
• Conformidade: licenças, termos, evidências exigidas por auditoria/regulatório.

Regra prática: documentação final deve ser “suficiente para alguém novo entender e operar”, não “perfeita”. O que não for útil para operar, auditar ou evoluir tende a virar ruído.

6) Encerramento de contratos e fornecedores

Objetivo: finalizar obrigações contratuais, evitar cobranças indevidas e registrar desempenho do fornecedor.

• Confirme entregas do fornecedor e aceite (interno e/ou do cliente, conforme contrato).
• Valide notas fiscais, medições, marcos e pagamentos pendentes.
• Registre aditivos, variações e justificativas (se existirem).
• Formalize encerramento: termo de recebimento, aceite de serviço, encerramento de chamado/ordem de compra.
• Faça avaliação objetiva do fornecedor: qualidade, prazo, comunicação, flexibilidade, conformidade.

Se houver garantia/assistência pós-entrega prevista em contrato, registre claramente: período, canais, tempos de resposta e o que está fora de escopo.

7) Consolidação de lições aprendidas com plano de ação (acionáveis)

Objetivo: transformar aprendizado em melhoria real, não em uma lista genérica.

Para serem acionáveis, lições aprendidas precisam de três elementos: contexto (quando aconteceu), causa (por que aconteceu) e ação (o que muda daqui para frente).

Formato prático (use como tabela):

Boa prática: limite a 5–10 lições principais e exija dono e data para cada ação. Se não há dono, não é ação; é desejo.

Modelo enxuto de Relatório de Encerramento (copiar e preencher)

Use este modelo como documento único (1–3 páginas) com links para anexos. Ele serve para registrar o “estado final” do projeto.

RELATÓRIO DE ENCERRAMENTO DO PROJETO (ENXUTO)

1) Identificação
- Projeto:
- Sponsor/Cliente:
- Gerente do Projeto:
- Período (início/fim):
- Versão do relatório / Data:

2) Objetivo e entregas finais
- Objetivo do projeto (1-2 frases):
- Entregas aceitas (lista com versão/data e link):
  1.
  2.

3) Aceite
- Data do aceite:
- Responsável pelo aceite:
- Evidência do aceite (link/arquivo):
- Ressalvas/pendências aceitas (se houver):
  - Pendência | Dono | Prazo | Onde será tratada (operação/backlog)

4) Transição (handover)
- Área receptora (operação/sustentação):
- Itens transferidos (acessos, ambientes, documentação, runbook):
- Treinamentos realizados (datas/público/material):
- Suporte/garantia: período, canal, SLA, limites:

5) Contratos e fornecedores (se aplicável)
- Contratos encerrados (sim/não) e evidências:
- Pagamentos pendentes (sim/não):
- Avaliação de desempenho do fornecedor (pontos objetivos):

6) Métricas de sucesso
- Critérios de aceite atendidos: (sim/não + observações)
- Satisfação do cliente/usuário: método, nota, comentários:
- Benefícios (quando aplicável): indicador, baseline, meta, status atual:

7) Lições aprendidas acionáveis
- Top lições e ações (link para tabela completa):
  1) Lição -> Ação -> Dono -> Prazo
  2) ...

8) Arquivamento e localização dos artefatos
- Repositório oficial (link):
- Estrutura de pastas usada:
- Permissões e responsáveis pelo repositório:

9) Aprovações
- GP:
- Sponsor/Cliente:
- Operação/Sustentação:

Como arquivar artefatos para reutilização futura (sem virar “cemitério de arquivos”)

Estrutura recomendada de pastas (simples e escalável)

Escolha um repositório oficial (ex.: drive corporativo, SharePoint, Git, ferramenta interna) e padronize uma estrutura. Exemplo:

/Projeto_Nome_YYYY
  /01_Gestao
    - Relatorio_Encerramento.pdf
    - Termo_Aceite.pdf
    - Registro_Pendencias.xlsx
    - Cronologia_Decisoes.md
  /02_Entregas
    /Produto_ou_Servico
  /03_Validacao
    - Evidencias_Testes
    - Checklists_Assinados
  /04_Transicao_Operacao
    - Runbook.pdf
    - Matriz_Suporte.xlsx
    - Treinamentos
  /05_Contratos
    - Contrato.pdf
    - Aditivos.pdf
    - Aceites_Fornecedor.pdf
  /06_Licoes_Aprendidas
    - Licoes_Aprendidas_Acoes.xlsx
  /99_Administrativo (opcional)

Regras práticas de arquivamento

• Um “arquivo mestre”: o Relatório de Encerramento deve apontar para todos os links importantes.
• Nomenclatura consistente: Tipo_Documento_Versao_Data (ex.: Termo_Aceite_v1_2026-01-30.pdf).
• Controle de acesso: operação precisa de acesso contínuo ao runbook e às evidências essenciais.
• Reutilização: separe modelos e checklists que podem virar template corporativo (ex.: pasta “Modelos”).
• Retenção: defina prazo de retenção conforme política interna (especialmente para contratos e evidências).

Como medir sucesso no encerramento (além de “entregou”)

1) Critérios de aceite (objetivo e verificável)

Meça sucesso confirmando o percentual de critérios atendidos e registrando exceções. Exemplos de métricas:

• % de entregas aceitas na primeira submissão.
• Número de ressalvas no termo de aceite (e severidade).
• Tempo entre entrega final e aceite (dias).

2) Satisfação do cliente/usuário (percepção estruturada)

Use um método simples e repetível, como pesquisa rápida pós-entrega (3–5 perguntas). Exemplos:

• Nota de 0 a 10 para “atendeu à necessidade”.
• Nota de 0 a 10 para “facilidade de adoção/uso”.
• Campo aberto: “o que mais ajudou” e “o que mais atrapalhou”.

Registre a amostra (quantas pessoas responderam) e o público (cliente, usuários finais, operação).

3) Realização de benefícios (quando aplicável)

Nem todo projeto mede benefício imediatamente no encerramento, mas você pode deixar o mecanismo pronto. Para benefícios, registre:

• Indicador: o que será medido (ex.: tempo de atendimento, custo por transação, taxa de erro).
• Baseline: valor antes do projeto.
• Meta: valor esperado e prazo.
• Responsável pelo acompanhamento: geralmente a área de negócio/operação.
• Cadência: quando medir (30/60/90 dias, trimestral).

Exemplo: se o projeto automatizou um processo, o encerramento pode registrar que a operação medirá “tempo médio de ciclo” por 90 dias e reportará ao sponsor, com data da primeira medição.

Checklists rápidos (para usar no dia a dia)

Checklist de encerramento em 15 itens

• Entregas finais revisadas e “congeladas” (versão final).
• Evidências de validação anexadas/links disponíveis.
• Pendências classificadas (críticas/importantes/oportunidades).
• Decisão formal sobre pendências pós-aceite (dono e prazo).
• Termo de aceite pronto e revisado.
• Aceite coletado e arquivado.
• Handover realizado com área receptora.
• Acessos transferidos (contas, permissões, chaves, credenciais conforme política).
• Runbook/procedimentos entregues.
• Matriz de suporte e escalonamento definida.
• Treinamentos realizados e registrados.
• Documentação final consolidada e versionada.
• Contratos encerrados e pagamentos reconciliados.
• Lições aprendidas registradas com ações, donos e prazos.
• Relatório de encerramento publicado com links e local de arquivo.