Termo de abertura e controle integrado de mudanças.

Um projeto que começa sem termo de abertura não tem autorização para existir — tem apenas pressa. E projeto com pressa e sem critério de sucesso só termina por esgotamento.

Já vi essa combinação de perto no nosso ERP. Uma versão de melhorias no faturamento começou com uma conversa: o cliente queria “agilizar a emissão de nota”. Três pessoas gostaram da ideia, o time pegou o tema e trabalhou por semanas. Na demonstração, veio a pergunta que não tinha resposta: qual número define que o problema foi resolvido? Tempo de emissão menor? Menos notas rejeitadas? Quantas? Ninguém tinha escrito. A entrega ficou aprovada “em parte”, os pedidos de ajuste entraram semana após semana, e o tema nunca fechou — porque não existia o acordo inicial que definisse o fim. O problema não era competência técnica da equipe. Era a ausência de um documento de meia página assinado antes do primeiro commit.

Este é o sétimo artigo da série PMBOK sem Burocracia. O índice central está em PMBOK sem Burocracia: série com 40 artigos sobre gestão de projetos.

TL;DR

• O termo de abertura autoriza o projeto em uma página: objetivo, critério de sucesso mensurável, orçamento e a autoridade escrita do gerente do projeto.
• Sem critério de fim mensurável, o encerramento do projeto vira opinião — e opinião não fecha projeto, só promove disputa.
• O controle integrado de mudanças transforma pedido em decisão: análise de impacto em escopo, prazo, custo e qualidade primeiro, resposta depois.
• Mudou um vértice do triângulo, renegocie os outros; conceder mudança em silêncio e sem registro é assinar um cheque em branco.

~ 10 min de leitura · 1794 palavras

🎧 Ouvir resumo (41) — voz gerada por IA, narração dos pontos principais do post.

O problema real: projeto que nunca fecha porque nunca definiu o fim

Volto ao caso do ERP. A versão de faturamento tinha patrocinador informal, prazo implícito e escopo mutável. Cada reunião adicionava algo: um campo a mais na nota, um relatório extra, um filtro novo na interface da tela. Cada item, isolado, parecia pequeno. O conjunto virou três releases e nenhum encerramento.

O sintoma que mais dói em projeto assim não é o atraso — é a indefinição. Quando alguém perguntava “quando isso termina?”, a resposta honesta era “quando o cliente parar de pedir”. Nenhum gerente consegue defender prazo contra um critério inexistente. A discussão de aceite descia para o detalhe: a cor do botão, o texto do e-mail, o caso de borda. O projeto perdeu o nível de objetivo e afundou no nível de pixel.

A segunda perda foi de autoridade. Sem termo de abertura, o gerente do projeto coordena por favor: pede gente ao comercial, pede hora ao time de infraestrutura, pede prioridade ao suporte. O trabalho acontece por boa vontade dos demais gestores, e a boa vontade é o recurso mais volátil que existe — acaba na primeira semana cheia.

O termo de abertura é exatamente o oposto disso: é o documento em que a organização, por meio do patrocinador, autoriza o projeto a existir, dá um objetivo, define quanto vale e entrega a alguém — o gerente do projeto — a autoridade para gastar os recursos em nome desse objetivo. No PMBOK da 6ª edição, o processo “desenvolver o termo de abertura do projeto” é o primeiro da integração e o primeiro da série de 49: o projeto começa por um contrato de resultado. Não é burocracia de formulário. É a diferença entre “estou ajudando” e “estou responsável”.

O que entra na meia página

Um termo de abertura útil para software cabe em uma página e não precisa de formatação. Os campos que eu cobro, por ordem de valor:

1. Objetivo do projeto em uma frase sem jargão interno: o que muda para o negócio quando acabar.
2. Critério de sucesso mensurável: número, prazo ou taxa. “Emissão de nota em até 10 segundos em 95% das operações” é critério; “faturamento mais ágil” é desejo.
3. Escopo de alto nível com as exclusões escritas: o que o projeto NÃO vai fazer. Exclusão explícita previne metade das discussões de escopo que virariam mudança depois.
4. Orçamento e prazo autorizados, ainda que estimados.
5. Patrocinador com nome — a pessoa que decide quando o projeto precisa de verba ou de escolha.
6. Gerente do projeto com nome e autoridade escrita: o que ele aprova sozinho e o que escala.
7. Stakeholders principais, com uma linha do interesse de cada um.
8. Riscos de alto nível registrados, para o patrocinador assinar ciente dos limites.
9. Marcos principais, no máximo cinco.

Meia hora de conversa com o patrocinador preenche esses nove campos. A rejeição comum — “não temos tempo para documentar” — cai por terra diante de meia hora. O custo real do termo de abertura é uma conversa difícil sobre o critério de sucesso, que aconteceria de qualquer forma, só que depois, quando o custo de corrigir já fosse multiplicado.

No nosso caso de modernização — migrar um ERP escrito em .NET Framework e Web Forms para .NET 10 com Angular — o termo de abertura coube em meia página e tinha um critério que matou dez discussões futuras: comportamento idêntico ao sistema atual, validado pelos mesmos relatórios e pelos mesmos arquivos que o sistema antigo produz. Com esse critério no papel, quem pedisse uma funcionalidade nova durante a migração sabia que estava pedindo duas coisas: uma migração e um projeto novo. E que o projeto novo entraria no controle de mudanças.

O controle integrado de mudanças: a regra que mantém o contrato vivo

O termo de abertura, sozinho, não sobrevive. Toda base de compromisso envelhece quando a realidade muda e a decisão continua a antiga. Para isso existe o segundo processo desta dupla: o controle integrado de mudanças, do PMBOK da 6ª edição — e é “integrado” por um motivo direto. Nenhuma mudança afeta apenas um vértice do triângulo escopo-prazo-custo. Um campo novo na nota fiscal aumenta escopo, o que aumenta prazo ou custo, o que pode afetar qualidade por falta de tempo de teste. Avaliar o pedido isolado da sua consequência é metade da análise; a outra metade é decidir consciente: o que a mudança cobra de qual vértice.

O processo, no essencial, tem cinco passos que cabem em uma regra de uma página:

1. Todo pedido de alteração entra por uma porta única — no nosso caso, um registro com descrição, origem e data. Pedido verbal em corredor não é pedido; é conversa até virar registro.
2. Análise de impacto em escopo, prazo, custo e qualidade, feita por quem vai executar — não pelo pedinte. O impacto é escrito em número: dias, horas, risco.
3. Decisão com autor: aprovar, rejeitar ou adiar. Para a maioria das empresas, isso não exige comitê permanente — exige o nome de quem decide por faixa de valor. Mudança pequena com risco baixo, o gerente decide; acima da faixa, o patrocinador decide.
4. Registro da decisão e do motivo. O que não fica escrito será discutido de novo depois, e o projeto perde a memória.
5. Baseline atualizada e comunicada: escopo, prazo e custo oficiais mudam junto, ou a organização passa a gerenciar dois projetos paralelos — o que está no papel e o que está acontecendo.

A regra vale tanto para pedido do cliente quanto para pedido interno. No nosso ERP, a origem mais comum de escopo silencioso nunca foi o cliente: foi a própria equipe, adicionando robustez aqui, refatorando ali, com a melhor das intenções e sem porta de decisão. O controle integrado de mudanças protege o projeto do pedido ruim externo e, com o mesmo rigor, do pedido generoso interno.

Na prática no ERP: uma mudança de dois dias que poderia custar duas semanas

Exemplo real recente no Posseidom. Um cliente da distribuição pediu um campo adicional na nota fiscal de remessa — uma linha a mais no XML, aparentemente. Em sistema fiscal, “aparentemente” é a palavra mais cara do vocabulário.

Com a regra de mudança ativa, o pedido entrou como registro. A análise impactou: ajuste no layout do XML e no cadastro (1 dia), teste em homologação com validação de rejeição pela SEFAZ (1 dia), e um ponto nada pequeno — o campo novo mudava a ordem de processamento de uma rotina de faturamento usada por todos os clientes da mesma release. Impacto total: 2 dias diretos mais risco de regressão.

A decisão voltou ao patrocinador do projeto com três opções escritas: aprovar e estender a release em 2 dias; adiar para a release seguinte, que já mexia na mesma rotina; ou recusar com motivo. Ficou adiar — a rotina já estava sendo alterada por outra mudança aprovada, e concentrar as duas numa só release de teste reduziu o risco total. O cliente recebeu a resposta com o motivo registrado, não com um “depois a gente vê”.

Sem a regra, o trajeto clássico era outro: o desenvolvedor atendia o colega que pediu, o campo entrava sem teste fiscal completo, a nota era rejeitada em produção num sábado, e o custo do conserto — que inclui horário de suporte, retrabalho e desgaste — passava de uma semana. A mesma mudança custou 2 dias decididos ou 7 dias consertada. O documento que permite essa conta é a regra de uma página, e a regra só existe porque o termo de abertura definiu quem tem autoridade para decidir.

Erros frequentes que mantenho o termo de abertura de pé para evitar

• Termo de abertura de 40 páginas. Documento que ninguém lê autoriza menos que uma meia página assinada. Se o documento passa de duas páginas, o projeto está escondendo indecisão atrás de quantidade.
• Critério de sucesso sem unidade. “Melhorar o faturamento”, “deixar o sistema mais rápido”, “aumentar satisfação”. Sem número, o fim do projeto vira gosto — e gosto não encerra nada.
• Mudança aprovada verbalmente. A reunião decide, o e-mail não registra, a baseline continua antiga. Três meses depois, ninguém lembra o que foi acordado, e os dois lados se lembram de versões diferentes — com o projeto pagando a diferença.
• Conceder mudança sem renegociar os outros vértices. Aprovar escopo e manter prazo é a forma mais comum de destruir qualidade: alguém vai pagar os dois dias extra, e o pagamento costuma ser no tempo de teste.
• Gerente sem autoridade escrita. O termo de abertura que não nomeia o gerente do projeto e o que ele aprova sozinho produz um coordenador informal, que negocia cada decisão em tempo real com quem aparecer primeiro.
• Baseline congelada depois da aprovação. Decisão tomada, registro salvo, baseline nunca atualizada. Em poucos ciclos, o plano oficial é ficção — e plano de ficção não gerencia nada.

Reflexão final e próxima ação

O par termo de abertura + controle integrado de mudanças é o único conjunto do PMBOK que eu instalaria no primeiro dia de qualquer projeto, antes de qualquer ferramenta. O termo de abertura compra duas coisas que dinheiro depois não compra: um critério de fim que evita a discussão infinita de aceite, e autoridade que evita gerente implorando recurso. O controle de mudanças mantém esse contrato honesto quando a realidade muda — e ela sempre muda.

É o que eu exijo agora de qualquer projeto que assumir, inclusive nos internos: meia página com os nove campos e uma regra de mudança de uma página com cinco passos. Sem os dois, eu não começo — porque já comecei sem eles e sei o preço da indefinição.

A próxima ação, para quem lê: escolha o projeto mais ativo hoje e escreva o critério de sucesso em um número que caiba em uma linha. Se a frase não existir ou não puder ser verificada, essa é a lacuna que vai custar caro primeiro — e 30 minutos de conversa com o patrocinador hoje custam menos que a discussão de aceite em seis semanas.

Leitura relacionada

• PMBOK sem Burocracia: série com 40 artigos sobre gestão de projetos — o índice central, com a agenda completa da série.
• Integração: como coordenar um projeto inteiro — a área que reúne as dez do PMBOK, da qual termo de abertura e controle de mudanças fazem parte.
• Escopo, prazo e custo mudaram um? Renegocie os outros — o triângulo por trás de toda análise de impacto de mudança.

A série continua no próximo artigo com o escopo: o perigo dos projetos que nunca param de crescer — e como travar o crescimento antes que ele decida o prazo por você.