Termo de encerramento de projeto: o realizado contra o combinado, linha a linha

Encerrar projeto é a tarefa que todo mundo concorda que importa e quase ninguém faz direito. A equipe já foi realocada, o patrocinador já comemorou a entrega, e o documento de fechamento vira uma formalidade de meia hora escrita por quem sobrou. O termo de encerramento feito assim registra que o projeto acabou. Ele não registra o que o projeto ensinou, que é a única coisa que sobrevive dele.

A ferramenta que eu uso tem uma exigência que muda o resultado: comparar cada linha com o termo de abertura, na mesma unidade e na mesma referência, sem arredondar o desvio para menos. É uma frase curta e ela elimina de uma vez a maior parte dos encerramentos decorativos, porque obriga a colocar lado a lado o que foi prometido e o que aconteceu.

Este texto trata do documento de fechamento, não da cerimônia. Se o que você procura é como extrair aprendizado do time, isso é assunto das lições aprendidas, que é um documento vizinho e diferente. Aqui o assunto é a prestação de contas: o que foi combinado, o que foi entregue, qual a distância entre os dois e por quê.

Você vai ver as cinco partes do termo, como montar a tabela de linha de base contra realizado, por que o desvio precisa de causa nomeada, o que fazer com o escopo que entrou por fora, como tratar pendência sem transformar encerramento em adiamento, e o aceite formal que fecha o documento.

Uma nota de procedência: as linhas de exemplo deste artigo foram montadas a partir do formato da ferramenta F17 do Kit Gestão de Projetos da Voitto. São ilustrativas e servem para mostrar o nível de detalhe que cada campo pede — não relatam um projeto real.

O que é o termo de encerramento

O termo de encerramento é o documento que fecha o projeto comparando o realizado com o que o termo de abertura fixou. Ele tem uma estrutura espelhada: para cada compromisso assumido na abertura, uma linha dizendo o que aconteceu.

Essa simetria é o que dá função ao documento. Um encerramento que descreve o que foi feito, sem referência ao que foi combinado, é um relatório de atividades — informativo e inútil para quem vier depois. O valor está na distância entre as duas colunas, porque é dela que sai a calibração das estimativas do projeto seguinte.

Há uma consequência prática disso que vale dizer cedo: se o termo de abertura foi vago, o termo de encerramento será vago, e não há como consertar no fim. Projeto que abriu com "melhorar a experiência do cliente" não tem contra o que comparar. Nesse caso, o encerramento honesto declara a impossibilidade em vez de inventar uma linha de base retroativa.

O documento também tem uma função administrativa que costuma ser a única lembrada: liberar formalmente a equipe, encerrar contratos e registrar o aceite. Essa parte é real e necessária. Ela só não é o motivo pelo qual vale gastar duas horas escrevendo o termo em vez de vinte minutos.

As cinco partes do termo

A segunda e a terceira partes conversam entre si e é comum vê-las confundidas. A tabela de linha de base traz as quatro dimensões clássicas — prazo, orçamento e as duas faces do escopo, o quantitativo e o de conteúdo. O bloco de escopo fora do original é uma lista do que foi acrescentado no caminho, e ele existe porque sem essa lista o desvio de prazo e custo fica sem explicação.

A quarta parte é a que mais gera desconforto e a mais útil. Pendência no encerramento é normal: quase nenhum projeto fecha com tudo resolvido. O que não é normal é pendência sem prazo e sem responsável, e a regra da ferramenta é direta — pendência assim não fecha o projeto, só adia o problema para depois do encerramento, quando já não há equipe para tratá-lo.

A tabela de linha de base contra realizado

Esta é a parte central e a que exige mais disciplina. Cada linha tem quatro colunas: a dimensão, o valor original do termo de abertura, o valor realizado e o desvio com a causa. A instrução da ferramenta cobre as três armadilhas de uma vez — mesma unidade, mesma referência, sem arredondar o desvio para menos.

Repare que a terceira linha traz um desvio negativo e ele está lá do mesmo jeito. Encerramento que só registra o que cresceu conta metade da história: escopo reduzido explica prazo cumprido, e omitir a redução faz o projeto parecer mais eficiente do que foi. É esse tipo de omissão que estraga a estimativa do projeto seguinte.

Sobre a mesma unidade: se a abertura fixou 18 semanas, o encerramento relata semanas. Trocar para "cerca de cinco meses" parece equivalente e não é — a mudança de unidade apaga o desvio de três semanas dentro da margem da palavra "cerca". A mesma coisa vale para orçamento relatado em faixa, e para escopo relatado em percentual quando a abertura falava em quantidade.

E sobre não arredondar para menos: a tentação é real e quase sempre inconsciente. Três semanas viram "pouco mais de duas", R$ 32 mil viram "cerca de 6% acima". O percentual não é errado, mas ele substitui um número que a organização pode somar por um que ela só pode sentir. Guarde o percentual para o comentário; ponha o valor absoluto na coluna.

Desvio precisa de causa nomeada

A quarta coluna da tabela pede o desvio e a causa, e a ferramenta é explícita sobre o padrão de qualidade: todo desvio de prazo e custo tem causa nomeada, não um genérico "atraso da equipe". Essa exigência é o que transforma o encerramento em insumo de aprendizado.

Causa nomeada tem três propriedades. Ela aponta para um evento datável, não para um estado difuso. Ela cita a referência que a documenta — controle de mudanças, registro de problemas, registro de decisões. E ela é específica o bastante para que alguém possa perguntar se o mesmo risco existe no próximo projeto.

• Não é causa: "atraso da equipe", "complexidade maior que a esperada", "problemas de comunicação", "escopo mal dimensionado".
• É causa: "dois analistas realocados em 11/03 para o projeto X", "homologação falhou em 3 de 7 cenários de carga", "janela de infraestrutura confirmada com 9 dias de atraso".
• Teste rápido: se a causa serviria igualmente bem para qualquer outro projeto da empresa, ela não é causa — é categoria.

Quando a causa real é organizacional e desconfortável — prioridade que mudou, recurso que foi remanejado, decisão que demorou —, escrevê-la é justamente o que faz o documento valer. Encerramento que atribui todo desvio à execução treina a organização a achar que o problema é sempre de quem executa, e isso garante que a mesma perda se repita.

O escopo que entrou por fora continua contando

O bloco de escopo fora do original lista tudo que foi acrescentado depois da abertura. A regra da ferramenta tem uma parte contraintuitiva: o que entrou fora do escopo está listado aqui mesmo quando já foi entregue e aceito.

A intuição contrária é compreensível. Se o item foi entregue e o cliente aceitou, por que registrá-lo como fora do escopo? Porque ele consumiu prazo e dinheiro que não estavam previstos, e porque a organização precisa saber quanto do esforço do projeto foi para o combinado e quanto foi para o acrescentado. Sem essa separação, o projeto seguinte será estimado com base num esforço que incluía coisas que ninguém contou.

Há também um efeito de aprendizado sobre o processo. Uma lista longa de escopo acrescentado, com a maioria dos itens sem pedido formal correspondente, diz que o controle de mudanças não estava funcionando. Essa é uma conclusão que só aparece no encerramento, quando se vê o conjunto — durante o projeto, cada item isolado parecia pequeno.

O formato que funciona é simples: uma linha por item, com a data de entrada, quem pediu, se houve pedido formal e o esforço aproximado. Esforço aproximado é melhor que campo vazio; a precisão aqui importa menos que a ordem de grandeza, porque o uso é comparativo.

Pendência sem prazo e sem dono não fecha projeto

Quase nenhum projeto fecha com tudo resolvido, e isso não é problema. O problema é a pendência genérica, sem prazo e sem responsável, que aparece na lista para dar a impressão de que foi considerada. Ela não foi: ela foi adiada para um futuro sem dono, e o efeito prático é que ela reaparece meses depois como um problema novo.

A regra é de completude: toda pendência precisa de descrição, responsável nomeado, prazo e destino. Destino é o campo que falta na maioria dos termos — para onde essa pendência vai depois que o projeto fechar? Para a operação? Para outro projeto? Para um contrato de suporte? Sem destino, a pendência fica órfã na hora exata em que a equipe se dissolve.

Se uma pendência não consegue receber esses quatro campos, ela provavelmente não é pendência: é escopo não entregue. E escopo não entregue pertence à tabela de linha de base contra realizado, com o desvio declarado, não à lista de pendências. Essa distinção evita o encerramento que fecha um projeto que na verdade não terminou.

O aceite formal

O último bloco é o mais curto e o que mais trava encerramentos. Ele pede nome e data de quem aceita, e a regra diz que o aceite formal tem nome e data, não só uma assinatura pendente.

Aceite pendente é o estado mais comum dos termos de encerramento arquivados. O documento fica pronto, circula, e a assinatura nunca vem — porque quem assina sabe que assinar significa concordar com a tabela de desvios. Quando isso acontece, o projeto termina sem encerramento formal, e a memória que sobra é a versão oral de quem conta a história.

A saída não é pressionar pela assinatura: é envolver quem aceita na construção da tabela, antes de o documento ficar pronto. Desvio conhecido e discutido durante o projeto é assinado sem resistência; desvio revelado no documento final vira negociação. Se o registro de decisões e os relatórios de acompanhamento foram mantidos, não há revelação nenhuma no encerramento — só consolidação.

Quando o aceite realmente não vem, registre isso no próprio documento, com data e motivo, e arquive assim. Termo de encerramento com aceite recusado e motivo declarado é informação. Termo de encerramento que nunca foi arquivado porque faltava uma assinatura é perda total.

Quando escrever o termo, e por que o prazo importa

O termo de encerramento tem uma janela curta de qualidade, e ela fecha rápido. Enquanto a equipe está junta e o projeto está fresco, os desvios têm causa conhecida e as referências são encontráveis. Duas semanas depois da dissolução do time, cada causa custa uma conversa, e um mês depois a maior parte delas já não é recuperável.

A recomendação que funciona é agendar o encerramento antes da entrega, não depois. Quando a data de fechamento do documento entra no cronograma junto com a entrega final, ela compete por atenção em igualdade com as outras tarefas. Quando ela é deixada para "assim que der", ela compete com o projeto seguinte, e perde sempre.

Há um argumento adicional para antecipar: boa parte do conteúdo do termo já existe durante o projeto. A tabela de desvios sai dos relatórios de acompanhamento, as causas saem do registro de problemas, o escopo acrescido sai do controle de mudanças. Se esses documentos foram mantidos, o encerramento é consolidação de meia hora. Se não foram, ele é uma investigação de dois dias — e é aí que ele deixa de acontecer.

O padrão que eu recomendo é simples: última semana do projeto, com a equipe ainda alocada, e uma reunião de uma hora para revisar a tabela de desvios com quem participou. Não é sessão de lições aprendidas; é conferência de fatos. A sessão de lições vem depois, e vem melhor por causa dela.

O que fazer com o projeto que foi cancelado

Projeto cancelado também encerra, e o termo dele é o mais útil de todos — e o menos escrito. A lógica organizacional costuma ser a oposta: se o projeto foi cancelado, não haveria o que prestar contas. Há, e é justamente o que impede o próximo cancelamento pela mesma razão.

A estrutura se mantém, com uma diferença na tabela de linha de base: a coluna do realizado registra até onde o projeto chegou, e o desvio passa a ser a distância entre o previsto e o ponto de parada. O campo de causa deixa de explicar atraso e passa a explicar a decisão de cancelar — que é uma decisão e pertence ao registro de decisões com a mesma disciplina.

• Quanto foi consumido: prazo e orçamento gastos até a parada, em valor absoluto. É a informação que a organização mais precisa e menos registra.
• O que foi produzido e é aproveitável: artefatos, contratos, aprendizado técnico, ambientes montados. Cancelamento raramente produz zero.
• O gatilho do cancelamento: mudança de prioridade, inviabilidade técnica comprovada, premissa que caiu. Com data e referência.
• O ponto em que ele poderia ter sido cancelado antes: este é o item que dói e o único que economiza dinheiro no futuro.

O último item é o que transforma um cancelamento em aprendizado. Quase sempre existe um momento anterior em que a informação que motivou o cancelamento já estava disponível, e identificá-lo é o que permite encurtar a próxima decisão parecida. Ele exige honestidade e não exige culpado — a pergunta é em que data a informação existia, não quem deveria tê-la usado.

Encerramento em projetos que viram operação

Uma classe de projeto termina de um jeito que o formulário não prevê: ele não entrega e sai, ele vira rotina. Implantação de sistema, programa de melhoria contínua, estruturação de área — todos terminam com alguém continuando a fazer aquilo indefinidamente, e o encerramento fica ambíguo.

A ambiguidade é resolvida com uma definição explícita no próprio termo: o que exatamente passa a ser operação, quem passa a ser dono, e a partir de que data o projeto deixa de responder por aquilo. Sem essa fronteira, o gerente do projeto continua sendo procurado seis meses depois, e a operação nunca assume de fato.

O bloco de pendências ganha peso especial nesses casos, porque quase tudo que fica em aberto tem como destino a operação. A regra de destino nomeado vale em dobro: "passa para a operação" não é destino, é encaminhamento vago. Destino é a pessoa ou a área com nome, o mecanismo pelo qual ela recebe, e a data.

Vale registrar também o que a operação precisa para sustentar o que foi entregue — documentação, treinamento, acesso, orçamento recorrente. Projeto que entrega uma rotina sem os meios de mantê-la produz uma reversão silenciosa: em três meses a prática antiga volta, e o encerramento do projeto registra sucesso que não durou.

O termo como fonte da estimativa: o que medir ao longo de vários projetos

O retorno do termo de encerramento não acontece no projeto que ele fecha. Ele acontece no terceiro, no quinto, no décimo — quando existe uma série de documentos comparáveis e a organização passa a estimar com dado próprio em vez de com referência de mercado.

Isso exige que alguém mantenha a série, e essa responsabilidade quase nunca é atribuída. Termos de encerramento costumam ficar arquivados na pasta de cada projeto, um por pasta, sem ninguém que os leia em conjunto. Uma planilha única com uma linha por projeto encerrado resolve, e ela cabe em quatro colunas.

A quarta coluna é a que muda decisão de gestão. Quando a mesma causa nomeada aparece como dominante em cinco encerramentos seguidos — realocação de pessoas, demora em decisão de investimento, dependência de um fornecedor único —, o problema deixou de ser de projeto e passou a ser da organização. Nenhum gerente consegue demonstrar isso com um encerramento; qualquer um demonstra com cinco.

Há um cuidado estatístico que vale mencionar sem exagerar: cinco projetos não são amostra para conclusão fina, e não é disso que se trata. A série não serve para calcular a estimativa do próximo projeto com precisão — serve para mostrar viés sistemático. Se os cinco fatores de prazo estão acima de 1, a casa subestima prazo, e essa conclusão é robusta mesmo com poucos casos.

Por isso a insistência em manter a mesma unidade e o mesmo formato entre projetos. Um termo fora do padrão não estraga só a si mesmo: ele tira uma linha da série e enfraquece a única evidência que a organização tem sobre o próprio jeito de estimar.

Quem assina, quem lê e quem nunca vê o termo

O termo de encerramento tem três públicos com interesses diferentes, e escrever pensando num só é o que produz documento inútil para os outros dois. Quem patrocinou quer saber se o que pagou foi entregue. Quem opera quer saber o que passou a ser responsabilidade dele. E quem vai estimar o próximo projeto — que quase nunca é consultado — quer os números.

O terceiro público é o mais mal servido porque ele é invisível no momento da escrita. Ele aparece meses depois, folheando documentos antigos em busca de referência, e encontra encerramentos que falam de aceite e de pendências sem trazer a comparação numérica que ele precisa. É por isso que a tabela de linha de base contra realizado vem antes de tudo: ela é a parte que serve a quem ainda não chegou.

Uma pergunta ajuda a calibrar a escrita: se este documento for lido daqui a dois anos por alguém que nunca ouviu falar do projeto, o que ele consegue reconstruir? A resposta honesta separa o termo que presta contas do termo que registra o fim. O primeiro sobrevive à saída das pessoas; o segundo depende delas para fazer sentido, e elas sempre saem.

Há, por fim, um público que o documento não atende e não deveria tentar atender: a defesa de reputação de quem conduziu o projeto. Termo escrito para proteger quem o escreve é reconhecível de longe — desvios atribuídos a terceiros, causas vagas onde a responsabilidade era interna, escopo acrescido apresentado como conquista. Ele engana por um ciclo e queima a credibilidade do autor no seguinte, quando a série de encerramentos mostra o padrão.

Erros comuns no termo de encerramento

• Escrever depois que a equipe se dissolveu. Sobra quem tem menos contexto, e o documento vira formalidade.
• Trocar a unidade da linha de base. Semanas viram meses, valores viram percentuais, e o desvio desaparece dentro da margem da palavra.
• Registrar só os desvios para mais. Escopo reduzido explica prazo cumprido, e omiti-lo faz o projeto parecer mais eficiente do que foi.
• Causa por categoria. "Atraso da equipe" serve para qualquer projeto e por isso não serve para nenhum.
• Omitir o escopo aceito por fora. Some a explicação de boa parte do desvio de prazo e custo.
• Pendência sem destino. Fica órfã na hora exata em que a equipe se dissolve.
• Confundir pendência com escopo não entregue. Fecha formalmente um projeto que não terminou.
• Arquivar sem aceite e sem registrar a ausência. Transforma em perda total um documento que já estava pronto.

Existe ainda um erro de sequência que atrapalha mais do que parece: escrever o termo de encerramento depois das lições aprendidas. A ordem natural é a inversa. O termo produz os fatos — desvios, causas, escopo acrescido — e as lições saem deles. Quando a sessão de lições vem primeiro, ela trabalha com impressão, e o termo depois vira confirmação do que já foi dito.

O que o termo de encerramento devolve para o próximo projeto

O argumento final para fazer o documento com cuidado não é de governança, é de estimativa. Toda organização estima projeto novo com base na memória dos anteriores, e a memória organizacional tem duas formas possíveis: a tabela de desvios arquivada, ou a lembrança de quem estava lá.

A lembrança tem um viés conhecido e forte. Projetos que deram certo são lembrados como mais suaves do que foram; projetos que deram errado concentram a culpa no evento mais visível. Nenhuma das duas distorções aparece numa tabela que diz 18 semanas contra 21, com a causa datada ao lado.

1. Calibração de prazo: a razão entre previsto e realizado, ao longo de vários encerramentos, dá o fator de correção que nenhuma técnica de estimativa fornece.
2. Calibração de custo: o mesmo, com a vantagem de separar o que foi erro de estimativa do que foi escopo acrescido.
3. Padrão de causas: causas nomeadas repetidas entre projetos apontam a fragilidade estrutural da organização, não do projeto.
4. Taxa de escopo acrescido: quanto do esforço, em média, vai para o que não estava combinado — número que muda a conversa sobre contingência.

Nenhuma dessas quatro leituras é possível com um encerramento por projeto. Todas exigem uma série. É por isso que vale insistir na mesma unidade e no mesmo formato: o valor do documento cresce com o número de documentos comparáveis, e uma tabela fora do padrão estraga a série inteira.