Encerrar o Projeto ou Fase — PMBOK 8: Guia Completo (2026)

Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.

Encerrar o Projeto ou Fase: O Processo que Fecha o Ciclo e Transforma Resultados em Legado (PMBOK 8)

Anteriormente: Encerrar o Projeto ou Fase (PMBOK 6)

Cadastre-se para navegar sem anúncios e participar do Project Together →

Imagine este cenário: o projeto entregou todas as funcionalidades, o cliente assinou o aceite, a equipe comemorou. E pronto — todos foram para o próximo projeto. Ninguém consolidou as lições aprendidas. Os contratos com fornecedores ficaram abertos. A documentação técnica ficou incompleta. O produto entregue não foi formalmente transferido para a equipe de operações. Seis meses depois, a equipe de suporte não sabe como o sistema funciona, o financeiro descobre faturas pendentes de fornecedores e ninguém consegue responder se o projeto atingiu os objetivos que justificaram sua existência. O projeto “terminou” — mas nunca foi encerrado.

No PMBOK 8, o processo Encerrar o Projeto ou Fase é o Processo 9 do Domínio de Governança (código 2.1.6.9) — o último processo da governança e, simbolicamente, o encerramento do ciclo que começou com a iniciação. Ele garante que o projeto seja concluído de forma ordenada, com todas as pontas amarradas, conhecimento preservado e resultados formalmente transferidos.

Neste guia completo você vai encontrar:

• O que é o processo e onde ele se encaixa no PMBOK 8
• Por que usá-lo — e o que acontece quando o encerramento é negligenciado
• ITTO completo — Entradas, Ferramentas/Técnicas e Saídas em tabela detalhada
• Passo a passo prático para aplicar o processo do zero
• Quando aplicar — cenários e gatilhos
• Exemplos práticos — Projeto Horizonte e Projeto ProjectAdm
• Atalhos, templates e dicas
• 5 erros comuns — e como evitá-los
• Tailoring para contextos Preditivo, Ágil e Híbrido
• Interações com outros processos e domínios
• Checklist de aplicação rápida com 7 itens para usar hoje

1. O que é o Processo Encerrar o Projeto ou Fase

Encerrar o Projeto ou Fase é o processo de finalizar todas as atividades do projeto, fase ou contrato. Ele confirma que o trabalho foi concluído conforme o plano, as entregas foram aceitas, os contratos foram encerrados, os recursos foram liberados, as lições aprendidas foram consolidadas e os resultados foram formalmente transferidos para o cliente ou para a organização operacional.

No PMBOK 8, este é o Processo 9 do Domínio de Governança (código 2.1.6.9) — o último processo do domínio. Sua posição é intencional: o encerramento é o complemento da iniciação. O projeto começou com uma autorização formal (Processo 1) e termina com um encerramento formal (Processo 9). O ciclo completo — de abertura a encerramento — garante a integridade da governança.

O processo produz as seguintes saídas:

• Atualizações de documentos do projeto — todos os documentos são finalizados e arquivados
• Transição do Produto — transferência formal do produto, serviço ou resultado para o cliente ou para a equipe de operações
• Relatório Final — documento que consolida o desempenho do projeto, entregas concluídas, lições aprendidas e avaliação de sucesso
• Atualizações dos Ativos de Processos Organizacionais (APO) — lições aprendidas, templates atualizados, processos melhorados incorporados aos ativos da organização

Diferença entre encerrar um projeto e encerrar uma fase

Aspecto	Encerrar Projeto	Encerrar Fase
Escopo	Todas as entregas, contratos e recursos do projeto	Entregas e recursos da fase específica
Contratos	Todos os contratos são encerrados formalmente	Contratos específicos da fase (se aplicável)
Equipe	Liberação completa — todos retornam às suas áreas	Liberação parcial — parte da equipe segue para a próxima fase
Lições aprendidas	Consolidação final de todas as lições do projeto	Lições da fase, usadas como entrada para a próxima
Relatório Final	Relatório completo do projeto	Relatório da fase (pode ser simplificado)
Gate review	Encerramento formal com aceitação do patrocinador	Gate review para decidir se avança para a próxima fase

2. Por que Usar o Processo Encerrar o Projeto ou Fase

Benefícios diretos

• Conclusão formal: O projeto tem um ponto final claro e documentado. Recursos são liberados, contratos são fechados, responsabilidades são transferidas. Não há “zona cinzenta” entre projeto e operação.
• Preservação do conhecimento: Lições aprendidas consolidadas e arquivadas beneficiam projetos futuros. Sem encerramento, o conhecimento vai embora com a equipe.
• Encerramento financeiro: Todas as faturas são pagas, contratos são encerrados, reservas não utilizadas são devolvidas. O financeiro tem uma visão clara e final dos custos do projeto.
• Avaliação de sucesso: O Relatório Final permite avaliar se o projeto atingiu os objetivos que justificaram sua existência — ROI, benefícios, satisfação do cliente, lições para o futuro.
• Transferência ordenada: O produto ou serviço é formalmente transferido para o cliente ou para a equipe de operações, com documentação, treinamento e suporte definidos.
• Reconhecimento da equipe: O encerramento formal é a oportunidade de reconhecer o trabalho da equipe, celebrar conquistas e encerrar o ciclo de forma positiva.

O que acontece quando o processo é ignorado

• Projetos “zumbi”: O projeto não está mais ativo mas nunca foi oficialmente encerrado. Recursos ficam alocados no papel, custos continuam sendo contabilizados, e ninguém sabe se o projeto terminou ou está “pausado”.
• Contratos abertos: Fornecedores com contratos não encerrados continuam gerando obrigações (e às vezes custos) para a organização.
• Conhecimento perdido: A equipe se dispersa para outros projetos e o conhecimento acumulado vai embora. Projetos futuros repetem os mesmos erros.
• Transferência improvisada: O produto é “jogado” para a equipe de operações sem documentação, treinamento ou plano de suporte. A equipe de operações sofre por meses tentando entender o que recebeu.
• Sem avaliação de sucesso: Ninguém sabe se o projeto gerou o valor que prometeu. O Business Case que justificou o investimento nunca é verificado contra os resultados reais.

3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)

Entradas	Ferramentas e Técnicas	Saídas
Termo de abertura do projeto Plano de gerenciamento do projeto Documentos do projeto (registro de lições aprendidas, registro de mudanças, registro de riscos, relatórios de desempenho) Entregas aceitas Documentos de negócio (Business Case, Plano de Benefícios) Acordos (contratos) Documentação de aquisições Ativos de processos organizacionais (APO)	Opinião especializada Análise de dados (análise de variação, análise de tendência, análise de documentos) Reuniões	Atualizações de documentos do projeto Transição do Produto Relatório Final Atualizações dos APO

Detalhamento das Entradas

Termo de abertura do projeto: Referência original dos objetivos, premissas e critérios de sucesso definidos na iniciação. O encerramento verifica se os objetivos foram atingidos — comparando os resultados reais com o que foi prometido no Termo de Abertura.

Plano de gerenciamento do projeto: Contém as linhas de base e os planos auxiliares que serão verificados no encerramento. O escopo planejado é comparado com o escopo entregue. O cronograma planejado é comparado com as datas reais. O orçamento planejado é comparado com o custo final.

Documentos do projeto: O registro de lições aprendidas é consolidado. O registro de mudanças documenta a evolução do escopo ao longo do projeto. O registro de riscos mostra quais riscos se materializaram e quais respostas foram eficazes. Os relatórios de desempenho fornecem os dados de EVM e KPIs finais.

Entregas aceitas: Produtos, serviços ou resultados que foram validados pelo cliente ou pelo processo de aceitação formal. Apenas entregas aceitas podem ser transferidas no encerramento.

Documentos de negócio: O Business Case é revisado para verificar se os benefícios projetados se concretizaram (ou estão no caminho de se concretizar). O Plano de Benefícios indica como e quando os benefícios serão medidos após o encerramento.

Acordos e documentação de aquisições: Contratos com fornecedores que devem ser formalmente encerrados. A documentação de aquisições inclui entregas do fornecedor, certificados de aceitação, garantias e condições pós-contrato.

Detalhamento das Ferramentas e Técnicas

Opinião especializada: Consulta a especialistas em encerramento de contratos (área jurídica), avaliação de desempenho (PMO), transferência de produtos (equipe de operações) e consolidação financeira (controladoria).

Análise de dados: Análise de variação final (desempenho real vs. planejado em escopo, cronograma e custos), análise de tendência (evolução dos KPIs ao longo do projeto) e análise de documentos (verificação de completude da documentação do projeto).

Reuniões: Reunião de encerramento com a equipe (retrospectiva final), reunião de aceitação com o cliente/patrocinador, reunião de transferência com a equipe de operações e reunião financeira de encerramento com a controladoria.

Detalhamento das Saídas

Atualizações de documentos do projeto: Todos os documentos do projeto são finalizados, versionados como “versão final” e arquivados no repositório da organização. Nenhum documento fica em “rascunho” ou “em revisão” após o encerramento.

Transição do Produto: Transferência formal do produto, serviço ou resultado para o cliente ou para a equipe de operações. Inclui: documentação técnica, manuais de operação, treinamento da equipe receptora, definição de SLAs de suporte, contatos de escalonamento e período de acompanhamento pós-transferência (hypercare).

Relatório Final: Documento que consolida toda a história do projeto:

• Resumo executivo (o que o projeto fez e por quê)
• Escopo entregue vs. planejado
• Cronograma real vs. planejado
• Custo final vs. orçamento
• Qualidade das entregas (defeitos, retrabalho, satisfação do cliente)
• Riscos materializados e respostas executadas
• Mudanças aprovadas e seu impacto acumulado
• Lições aprendidas consolidadas (top 10)
• Avaliação de sucesso (objetivos atingidos?)
• Recomendações para projetos futuros

Atualizações dos APO: Incorporação das lições aprendidas, templates melhorados e processos revisados aos ativos da organização. Esta é a forma como o projeto devolve valor permanente à organização — mesmo após seu encerramento.

4. Como Aplicar o Processo Passo a Passo

Passo 1 — Confirme que todas as entregas foram aceitas

Antes de iniciar o encerramento formal, verifique:

• Todas as entregas previstas no escopo foram produzidas
• Todas as entregas passaram pelo processo de validação e foram aceitas formalmente pelo cliente ou patrocinador
• Entregas parciais ou condicionais estão documentadas (o que foi aceito, o que está pendente)
• Reparos de defeitos pendentes foram concluídos ou têm plano de resolução definido

Dica prática: Se existem entregas rejeitadas ou pendentes, o encerramento não pode ser concluído até que sejam resolvidas — ou até que o patrocinador aceite formalmente o encerramento com itens pendentes documentados.

Passo 2 — Encerre todos os contratos com fornecedores

Para cada contrato ativo:

• Verifique se o fornecedor cumpriu todas as obrigações contratuais
• Obtenha certificados de aceitação das entregas do fornecedor
• Resolva disputas pendentes (pagamentos, qualidade, escopo)
• Emita o termo de encerramento do contrato
• Processe pagamentos finais e retenções
• Documente a avaliação de desempenho do fornecedor (para referência futura)

Passo 3 — Consolide as lições aprendidas

Conduza uma sessão final de lições aprendidas com toda a equipe:

• Revise o registro de lições capturadas ao longo do projeto
• Conduza uma retrospectiva final: o que funcionou, o que não funcionou, o que mudar
• Priorize as lições por impacto (quais são as mais valiosas para projetos futuros?)
• Documente as top 10 lições aprendidas no Relatório Final
• Incorpore lições aos APO (templates atualizados, checklists expandidos, processos revisados)

Dica prática: Use storytelling. Peça a cada membro da equipe para contar uma história — o momento mais desafiador, a melhor decisão, o maior aprendizado. Histórias são mais memoráveis e mais úteis que listas genéricas de “lições aprendidas”.

Passo 4 — Elabore o Relatório Final

Consolide toda a informação do projeto em um único documento:

• Compare entregas planejadas vs. entregues
• Compare cronograma planejado vs. real (SPI final)
• Compare orçamento vs. custo real (CPI final, EAC vs. BAC)
• Documente os riscos que se materializaram e como foram tratados
• Documente as mudanças aprovadas e seu impacto acumulado
• Avalie o alcance dos objetivos do Termo de Abertura (critérios de sucesso)
• Inclua recomendações para projetos futuros
• Inclua avaliação de satisfação do cliente/patrocinador

Passo 5 — Transfira o produto para operações

Formalize a transição do produto:

• Entregue a documentação técnica completa (manuais, diagramas, configurações)
• Conduza treinamento para a equipe de operações/suporte
• Defina o SLA de suporte pós-projeto (quem atende, em quanto tempo, para quais problemas)
• Defina o período de hypercare (acompanhamento intensivo pós-transferência — tipicamente 2-4 semanas)
• Transfira credenciais, acessos e responsabilidades
• Obtenha aceite formal da equipe receptora

Passo 6 — Libere recursos e encerre financeiramente

• Libere os membros da equipe formalmente (comunicação aos gerentes funcionais)
• Devolva equipamentos, licenças e infraestrutura alocados ao projeto
• Encerre contas e centros de custo do projeto
• Processe pagamentos finais e devolva reservas de contingência não utilizadas
• Obtenha aprovação financeira final da controladoria

Passo 7 — Obtenha o aceite formal de encerramento

Submeta o Relatório Final e a documentação de encerramento ao patrocinador para aprovação formal:

• O patrocinador confirma que os objetivos foram atingidos (ou documenta as exceções)
• O patrocinador assina (física ou digitalmente) o termo de encerramento do projeto
• O encerramento é comunicado a todos os stakeholders
• Os documentos são arquivados no repositório organizacional

Dica prática: Organize uma reunião de encerramento com toda a equipe — não apenas para formalidades, mas para celebrar o trabalho realizado. Reconhecimento é a forma mais eficaz de motivar equipes para projetos futuros.

5. Quando Aplicar o Processo

Cenários obrigatórios

• Conclusão de todas as entregas: Quando todas as entregas foram produzidas e aceitas, o projeto deve ser formalmente encerrado.
• Final de uma fase em projetos multi-fases: Cada fase tem seu próprio encerramento, com gate review para decidir se avança para a próxima.
• Cancelamento do projeto: Mesmo projetos cancelados devem ser formalmente encerrados — com documentação das razões, lições aprendidas, encerramento de contratos e liberação de recursos.

Cenários recomendados

• Mudança radical de escopo ou direcionamento: Quando o projeto muda tão fundamentalmente que o escopo original não é mais válido, pode ser mais adequado encerrar o projeto atual e iniciar um novo — com novo Termo de Abertura.
• Saída do gerente de projeto: Quando o GP deixa o projeto antes do encerramento, um mini-encerramento (transferência de conhecimento + documentação do estado atual) é recomendado.

Gatilhos que indicam que o encerramento é necessário

• Todas as entregas foram aceitas pelo cliente
• O patrocinador declara que os objetivos foram atingidos
• O projeto foi cancelado por decisão da organização
• Recursos estão alocados a um projeto que não está mais ativo
• Contratos com fornecedores continuam abertos sem necessidade
• A equipe de operações já está usando o produto mas não recebeu transferência formal

6. Exemplos Práticos por Setor

Exemplo 1 — Implantação do PMO: Projeto Horizonte

Contexto: O Projeto Horizonte chegou ao mês 6 — prazo final para a implantação do PMO na Horizonte Transportes. Ana Silveira precisava encerrar formalmente o projeto, transferir a operação do PMO para Diego Carvalho (que assumiria como coordenador do PMO) e apresentar os resultados a Roberto Campos (CEO).

Como o processo foi aplicado:

1. Verificação de entregas: Ana conduziu uma revisão completa das entregas contra o escopo aprovado (incluindo as 4 mudanças aprovadas ao longo do projeto):
   • 12 templates de gestão de projetos criados e aprovados
   • Plataforma ProjectAdm configurada com 50 usuários ativos (73% de adoção — meta era 70%)
   • Integração ERP TOTVS ↔ ProjectAdm funcionando em produção
   • 30 colaboradores treinados em gestão de projetos (3 turmas concluídas)
   • Framework metodológico do PMO documentado e aprovado
   • Dashboard executivo para comitê diretivo (mudança CR-003, aprovada)

   Resultado: 100% das entregas aceitas por Roberto Campos.

2. Encerramento de contratos: Três contratos encerrados formalmente: (1) Carolina Mendes — consultoria concluída, 310 horas de 320 horas contratadas (T&M com cap), avaliação de desempenho: excelente; (2) Fornecedor de treinamento — 3 turmas entregues, contrato de preço fixo encerrado sem pendências; (3) Licença ProjectAdm — contrato contínuo (SaaS mensal) transferido para o departamento de TI da Horizonte.
3. Consolidação de lições aprendidas: Ana conduziu uma retrospectiva final de 2 horas com toda a equipe. Top 5 lições consolidadas:
   • “Resistência cultural é o maior risco de projetos de PMO — invista mais tempo em change management do que em tecnologia”
   • “Treinamento hands-on com casos reais da empresa gera 3x mais adoção que treinamento genérico”
   • “Verificar documentação de API de sistemas legados na fase de planejamento, não na execução”
   • “Comunicação do CEO para gerentes de operações sobre a importância do PMO é mais eficaz que qualquer treinamento”
   • “Templates devem ter guia de estilo padronizado desde o início — corrigir inconsistências retroativamente custa 5x mais”
4. Relatório Final: Ana elaborou um Relatório Final de 8 páginas:
   • Escopo: 100% entregue (6 entregas principais + 4 mudanças aprovadas)
   • Cronograma: concluído no prazo (6 meses, sem extensão)
   • Custo: R$ 312.400 de R$ 320.000 orçados (97,6% — R$ 7.600 devolvidos da contingência)
   • Qualidade: 73% de adoção da plataforma (meta: 70%), 0 templates com inconsistência (após correção)
   • Satisfação: Roberto Campos avaliou o projeto como 9/10. Marcos Tanaka: 8/10
5. Transição do produto: Diego Carvalho recebeu formalmente a operação do PMO com: documentação completa do framework, acesso administrativo ao ProjectAdm, cronograma de auditorias de qualidade dos templates, lista de contatos de suporte (Carolina Mendes disponível para consultoria pontual por 3 meses) e plano de evolução do PMO (fase 2: gestão de manutenção de frota). Período de hypercare: 4 semanas com Ana disponível para dúvidas.
6. Celebração: Roberto Campos organizou um almoço para toda a equipe do projeto, reconhecendo publicamente o trabalho de Ana e da equipe. Ana recebeu uma carta de recomendação formal do CEO.

Resultado: O Projeto Horizonte foi encerrado formalmente, com documentação completa, conhecimento preservado e transição ordenada. Seis meses após o encerramento, o PMO da Horizonte estava gerenciando 4 projetos simultaneamente — usando os templates e processos criados durante o Projeto Horizonte. As lições aprendidas foram consultadas na iniciação de cada um dos 4 projetos.

Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm

Contexto: A Release 1 (MVP) do Projeto ProjectAdm foi concluída. Eduardo Montes precisava encerrar a fase de desenvolvimento do MVP, transferir o produto para a equipe de operações/suporte e preparar a documentação para a Release 2.

Como o processo foi aplicado:

1. Verificação de entregas: Eduardo revisou todas as funcionalidades contra o product backlog da Release 1: 87 user stories planejadas, 85 entregues (2 adiadas para Release 2 por decisão de priorização), 5 bugs críticos resolvidos pós-pentest, documentação de API completa. Os 2 clientes-piloto assinaram o aceite formal do MVP.
2. Encerramento de contratos: (1) Agência de design UX/UI — contrato de preço fixo com incentivo encerrado. Entrega antecipada em 2 dias — bônus de R$ 5.000 pago. Avaliação: excelente (portfólio forte, boa comunicação, cumpriu prazos). (2) Pentest — contrato encerrado após reteste confirmar correção das 3 vulnerabilidades identificadas.
3. Consolidação de lições aprendidas: Eduardo consolidou as lições das 8 retrospectivas de sprint em um documento de 5 páginas. Destaque: “Code review obrigatório (branch protection) reduziu bugs em 70% entre Sprint 5 e Sprint 8” e “Briefing de design entregue 1 semana antes do sprint elimina atrasos da agência externa”.
4. Relatório Final (Release 1):
   • Escopo: 85 de 87 user stories (97,7%)
   • Cronograma: 8 sprints conforme planejado (24 semanas)
   • Custo: R$ 497.000 de R$ 480.000 (estouro de 3,5%, dentro da contingência de R$ 24.000)
   • Qualidade: 5 bugs críticos encontrados no pentest (todos resolvidos), taxa de defeitos caiu 70% da Sprint 5 para Sprint 8
   • Velocidade final: 44 story points/sprint (estável)
5. Transição para operações: A equipe de suporte (2 pessoas) recebeu: documentação técnica (87 entradas na wiki), runbook operacional (procedimentos de deploy, monitoramento, backup, incident response), acesso aos ambientes de staging e produção, treinamento de 3 dias na plataforma e canal de escalonamento para o time de desenvolvimento. Período de hypercare: 3 semanas com 1 desenvolvedor dedicado ao suporte.
6. Atualização dos APO: Eduardo incorporou à base de conhecimento da empresa: template de briefing de design (baseado na lição da agência), checklist de segurança pré-release (baseado no pentest), e processo de code review obrigatório (implementado como padrão para todos os projetos futuros).

Resultado: A transição ordenada permitiu que a equipe de suporte assumisse o MVP com confiança. Nos primeiros 30 dias de operação, apenas 2 incidentes foram reportados (ambos resolvidos em menos de 4 horas usando o runbook). Eduardo e a equipe puderam focar 100% na Release 2 sem ser interrompidos por problemas operacionais do MVP — porque a transferência foi feita corretamente.

7. Atalhos, Templates e Dicas

Templates recomendados

• Template de Relatório Final: Documento com seções pré-definidas: resumo executivo, escopo (planejado vs. entregue), cronograma (planejado vs. real), custo (orçamento vs. real), qualidade, riscos, mudanças, lições aprendidas, avaliação de sucesso, recomendações.
• Checklist de Encerramento: Lista de verificação com todos os itens que devem ser concluídos antes do encerramento formal.
• Template de Termo de Encerramento: Documento de 1 página com: nome do projeto, data de encerramento, entregas aceitas, pendências (se houver), aprovação do patrocinador.
• Template de Plano de Transição: Documento com: escopo da transição, documentação entregue, treinamento realizado, SLA de suporte, período de hypercare, contatos de escalonamento.

Ferramentas digitais

• ProjectAdm / MS Project: Para verificação de escopo concluído e geração de relatórios finais
• Confluence / SharePoint: Para documentação técnica e arquivamento do projeto
• DocuSign / Adobe Sign: Para assinatura digital do Termo de Encerramento
• Power BI: Para dashboard final do projeto com métricas consolidadas

Dicas avançadas

• Planeje o encerramento desde o planejamento: Não espere a última semana para pensar no encerramento. Defina no plano de gerenciamento: o que será entregue na transição, quem será treinado, quando os contratos serão encerrados, como as lições serão consolidadas. O encerramento bem planejado leva 1-2 semanas. O encerramento improvisado pode levar meses.
• Encerre contratos antes de encerrar o projeto: Fornecedores com contratos abertos após o encerramento formal do projeto são um problema administrativo e financeiro. Encerre todos os contratos durante o encerramento, não depois.
• Conduza a retrospectiva final com toda a equipe: Não apenas com os líderes. As melhores lições frequentemente vêm de quem executou o trabalho, não de quem o gerenciou.
• Verifique o Business Case no encerramento: O projeto atingiu os benefícios projetados? Se for cedo para medir (benefícios de longo prazo), defina quem medirá e quando. O Business Case sem verificação é uma promessa não cumprida.
• Celebre — sempre: Mesmo projetos difíceis merecem reconhecimento. A forma como o projeto termina influencia a motivação da equipe para projetos futuros. Uma celebração simples (almoço, reconhecimento público, e-mail do patrocinador) tem impacto desproporcional na moral da equipe.

8. Erros Comuns e Como Evitá-los

Erro 1 — Não encerrar formalmente o projeto

Por que acontece: O projeto “termina” quando a última entrega é feita. A equipe se dispersa para outros projetos. O gerente de projeto assume um novo projeto. Ninguém faz o encerramento formal — contratos ficam abertos, lições não são capturadas, recursos não são liberados.

Como evitar: Trate o encerramento como uma fase obrigatória do projeto — com atividades, responsáveis e prazo. Inclua o encerramento no cronograma do projeto (1-2 semanas). O patrocinador não deve aceitar o projeto como “concluído” sem o Relatório Final e o Termo de Encerramento assinados.

Erro 2 — Lições aprendidas genéricas ou inexistentes

Por que acontece: A sessão de lições aprendidas acontece na última hora do último dia, com metade da equipe já em outro projeto. As lições são genéricas (“a comunicação precisa melhorar”) e nunca serão consultadas por ninguém.

Como evitar: Se você capturou lições ao longo do projeto (Processo 6), o encerramento é apenas a consolidação. Se não capturou, reserve pelo menos 2 horas para uma retrospectiva final séria, com toda a equipe. Exija especificidade. Conecte cada lição a uma ação de melhoria.

Erro 3 — Transferência improvisada para operações

Por que acontece: A equipe de operações recebe o produto sem documentação, sem treinamento e sem plano de suporte. O resultado: a equipe de suporte não sabe operar o produto e escala tudo para os desenvolvedores, que deveriam estar focados no próximo projeto.

Como evitar: Planeje a transição antecipadamente. Inclua na transição: documentação técnica, runbook operacional, treinamento hands-on, SLA de suporte, período de hypercare e contatos de escalonamento. O aceite formal da equipe receptora confirma que ela tem tudo que precisa para operar.

Erro 4 — Não verificar os benefícios do Business Case

Por que acontece: O Business Case que justificou o projeto prometia ROI de 200% em 12 meses. Mas ninguém verifica se o ROI se concretizou. O projeto é considerado “sucesso” porque entregou no prazo — mas ninguém sabe se gerou valor.

Como evitar: No encerramento, revise o Business Case e o Plano de Benefícios. Se os benefícios já podem ser medidos, meça. Se são de longo prazo, defina: quem medirá, quando, com quais métricas e para quem reportará. A verificação de benefícios é o teste definitivo de sucesso do projeto.

Erro 5 — Não celebrar e reconhecer a equipe

Por que acontece: O gerente de projeto está focado no próximo projeto e não investe tempo em reconhecimento. A equipe sente que o trabalho foi “descartável” — entregou, pronto, próximo. Motivação para o próximo projeto: baixa.

Como evitar: Reserve 1 hora para uma celebração de encerramento. Reconheça publicamente as contribuições individuais. Peça ao patrocinador para enviar um e-mail de agradecimento. Celebrações simples geram retorno desproporcional em engajamento e motivação.

9. Tailoring: Preditivo, Ágil e Híbrido

Ambiente Preditivo (Waterfall)

• Encerramento: Formal e completo. Todas as entregas verificadas, contratos encerrados, lições consolidadas, Relatório Final elaborado e aprovado pelo patrocinador.
• Transição: Plano de transição formal com documentação completa, treinamento e período de hypercare.
• Relatório Final: Documento completo (5-10 páginas) com análise de desempenho detalhada (EVM, variações, lições).
• Gate review final: Apresentação ao comitê de governança com recomendação de encerramento.

Ambiente Ágil

• Encerramento: Mais leve mas ainda necessário. A última sprint inclui atividades de encerramento (documentação, transferência, retrospectiva final).
• Transição: Pode ser mais orgânica — em projetos ágeis contínuos, a equipe de desenvolvimento frequentemente também opera o produto. A transição é mais relevante quando a equipe muda.
• Relatório Final: Métricas consolidadas (velocidade média, throughput, defeitos) + retrospectiva final + product demo final. Menos formal, mais visual.
• Encerramento incremental: Em produtos ágeis de longa duração, o “encerramento” pode acontecer por release — cada release tem seu mini-encerramento.

Ambiente Híbrido

• Encerramento: Formal para a release/fase (preditivo) + retrospectiva ágil para encerrar o ciclo de desenvolvimento.
• Transição: Plano formal de transição + wiki/documentação técnica ágil.
• Relatório Final: Combinação de métricas EVM (preditivo) e métricas ágeis (velocidade, burndown).

Resumo comparativo do Tailoring

Aspecto	Preditivo	Ágil	Híbrido
Relatório Final	Formal e detalhado (5-10 pgs)	Métricas + retrospectiva + demo	Mix (EVM + ágil)
Transição	Plano formal + hypercare	Orgânica ou por release	Plano formal + wiki técnica
Lições aprendidas	Sessão formal de encerramento	Retrospectiva final + consolidação	Ambos
Contratos	Encerramento formal completo	Pode ser contínuo (SaaS/retainer)	Encerramento por release + contínuos
Aprovação	Gate review + assinatura do patrocinador	Product demo + aceite do PO	Gate review + PO

10. Interações com Outros Processos e Domínios

Processos que alimentam o encerramento

• Gerenciar Execução (Processo 4, Governança): Produz as entregas que serão verificadas no encerramento.
• Gerenciar o Conhecimento (Processo 6, Governança): Fornece o registro de lições aprendidas para consolidação final.
• Monitorar e Controlar o Desempenho (Processo 7, Governança): Fornece dados de desempenho final para o Relatório.
• Avaliar e Implementar Mudanças (Processo 8, Governança): Fornece o registro de mudanças para análise de impacto acumulado.
• Validar o Escopo (Escopo): Fornece entregas formalmente aceitas pelo cliente.

Processos que dependem do encerramento

Processo que recebe a saída	Domínio	O que recebe
Iniciar Projeto ou Fase (Processo 1) — para a próxima fase	Governança	Lições aprendidas, templates melhorados, avaliação de fornecedores
Processos organizacionais (pré-projeto)	Organizacional	APO atualizados (lições, templates, processos) para projetos futuros

Interações com os Domínios do PMBOK 8

Governança: O encerramento completa o ciclo de governança iniciado no Processo 1. Sem encerramento formal, a governança fica incompleta — o projeto não tem ponto final documentado.

Escopo: O encerramento verifica se todo o escopo foi entregue e aceito. Variações de escopo são documentadas no Relatório Final.

Cronograma: O cronograma real é consolidado e comparado com a linha de base. SPI final documentado.

Finanças: O custo final é consolidado, comparado com o orçamento, e o encerramento financeiro é formalizado. CPI final documentado.

Riscos: Riscos materializados e respostas executadas são documentados como lições para projetos futuros.

Recursos: Recursos humanos são formalmente liberados. Equipamentos e infraestrutura são devolvidos.

Partes Interessadas: O encerramento é comunicado a todos os stakeholders. A satisfação dos stakeholders-chave é avaliada e documentada.

11. Checklist de Aplicação Rápida

Use estes 7 itens como referência rápida para o encerramento do projeto:

1. Todas as entregas foram verificadas e formalmente aceitas pelo cliente ou patrocinador?
2. Todos os contratos com fornecedores foram formalmente encerrados (entregas aceitas, pagamentos processados, termos assinados)?
3. As lições aprendidas foram consolidadas e incorporadas aos ativos de processos organizacionais?
4. O Relatório Final foi elaborado com análise de desempenho (escopo, cronograma, custos, qualidade) e avaliação de sucesso?
5. A transição do produto para operações foi formalizada (documentação, treinamento, SLA, hypercare)?
6. Os recursos foram liberados (equipe, equipamentos, licenças, contas de custo)?
7. O patrocinador assinou o Termo de Encerramento e o encerramento foi comunicado a todos os stakeholders?

Regra prática: Se menos de 5 destes itens foram concluídos, o projeto não está encerrado — está abandonado. Projetos abandonados geram custos residuais, conhecimento perdido e transferências caóticas. Investir 1-2 semanas em encerramento formal economiza meses de problemas posteriores.

12. Faça agora com IA: o Processo 40 do PMBOK 8 Together

O PMBOK 8 Together é o curso gratuito que executa este processo no seu projeto: você responde no seu quadro, roda o processo e ele escreve o documento — preenchido, no modelo pronto. É o Processo 40 de 40.

O que este processo lê do seu quadro

• as respostas do 5W2H (o Termo de Abertura)
• a árvore do escopo (EAP ou Product Backlog)
• a situação de conclusão dos cartões

O que ele entrega

• Relatório Final do Projeto
• Transição do Produto

Como rodar

1. Responda no seu quadro do projeto (ProjectAdm).
2. Rode o processo 40 — ele devolve o prompt pronto, com os seus dados, na área de transferência.
3. Cole na sua IA. Ela propõe; você decide.
4. Cole a resposta na Caixa de entrada do quadro e rode o processo de novo — agora ele escreve o documento.

Baixar o pacote do curso — gratuito e sem instalar nada. Primeira vez? Veja a instalação padrão (5 minutos). As 40 aulas, com certificado, você recebe inscrevendo-se na página do curso.

Para se aprofundar em cada saída

• Relatório Final do Projeto
• Transição do Produto

Conclusão

O processo Encerrar o Projeto ou Fase é o que transforma um projeto concluído em um legado organizacional. Sem ele, o projeto simplesmente “para” — sem documentação final, sem transferência ordenada, sem lições preservadas e sem verificação de valor.

Os três pontos essenciais para levar para a prática:

• O encerramento é uma fase do projeto, não um afterthought. Inclua-o no cronograma, aloque recursos e trate-o com a mesma seriedade que a execução. Projetos que “terminam” sem encerramento formal geram custos residuais, contratos pendentes e transferências caóticas.
• A transição para operações é tão importante quanto a entrega. Entregar o produto não é o mesmo que transferir o produto. Documentação, treinamento, SLA de suporte e período de hypercare garantem que a equipe receptora pode operar o que foi entregue — sem depender da equipe do projeto.
• Verifique os benefícios — não apenas as entregas. O projeto foi iniciado para gerar valor (Business Case). O encerramento é o momento de verificar se o valor foi gerado — ou de definir quando e como será medido. Um projeto que entregou no prazo e no orçamento, mas não gerou os benefícios prometidos, não é um sucesso.

Próximo passo concreto: Abra o seu projeto atual (ou o último projeto concluído). Ele foi formalmente encerrado? Existe um Relatório Final? Os contratos foram fechados? As lições foram documentadas? A transição para operações foi formalizada? Se a resposta for “não” para qualquer uma dessas perguntas, você tem uma pendência que deveria ser resolvida — mesmo que o projeto já tenha “terminado” há meses.

Veja todos os artigos do PMBOK 8 no Indice Completo

---

Read this article in English

CTA Final

Gostou do artigo?

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

Cadastre-se para navegar sem anúncios e participar do Project Together →

Disclaimer:
Este artigo tem caráter informativo e educacional, com o objetivo de apresentar uma análise independente sobre o Guia PMBOK®. O conteúdo aqui publicado não reproduz nem substitui o material original do PMI e respeita integralmente seus direitos autorais. As marcas PMI e PMBOK® Guide são registradas pelo Project Management Institute. Para acesso ao conteúdo completo e oficial, adquira o guia pela Amazon ou baixe de forma gratuita em https://www.pmi.org/standards/pmbok se você é membro do PMI.

Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.