O cliente pede uma alteração no meio do projeto. A equipe aceita na conversa, ninguém registra nada, e três semanas depois ninguém lembra o que foi combinado, nem se o prazo mudou por causa disso. Quando a entrega atrasa, começa a caça a quem autorizou o quê.
É exatamente para evitar essa confusão que existe o change request modelo: um jeito simples de registrar cada pedido de mudança para que ele tenha dono, critério de aprovação e impacto claro, sem virar burocracia que trava a operação.
A boa notícia é que você não precisa de um PMO nem de software caro. Precisa de um modelo de change request enxuto e a disciplina de usá-lo. Veja o modelo pronto abaixo e como aplicá-lo em 4 passos.
O que é um change request (e o que não é)
Change request é o registro formal de um pedido de mudança em um projeto ou entrega: o que muda, por que muda, quem aprova e como saber se deu certo.
O que ele não é: um recado no WhatsApp, uma nota solta em ata ou um “combinado” verbal. Se a mudança não está registrada em um lugar único, ela não existe de forma confiável, existe até alguém esquecer.
O modelo de change request pronto para usar
Um change request modelo funcional cabe em uma tabela simples — no Notion, no Trello, numa planilha, onde o time já trabalha. Estes são os campos mínimos:
| Campo | O que preencher |
|---|---|
| Título | Nome curto da mudança |
| O que muda | Descrição objetiva do ajuste |
| Por quê | Motivo e quem pediu |
| Impacto | Efeito no prazo, custo e escopo |
| Dono | Quem aprova (uma pessoa, não um comitê) |
| Responsável | Quem executa a mudança |
| Critério de aceite | Como saber que a mudança deu certo |
| Status | Pendente / Aprovado / Em execução / Validado |
Esse é o modelo inteiro. Se você conseguir preencher esses 8 campos para cada pedido de mudança, já resolveu 90% do problema, porque a maioria das mudanças se perde justamente por não ter dono, impacto ou critério claro.
Os 4 passos para aplicar o modelo
1. Registre antes de fazer. Toda mudança que chega — por e-mail, reunião ou WhatsApp — vira uma linha no modelo antes de qualquer execução. Ana, gerente de operações, criou a regra na equipe dela: “pedido que não está no quadro não é feito”. Em duas semanas, os pedidos improvisados sumiram.
Como identificar que você precisa disso: se alguém no time já perguntou “quem autorizou essa mudança?”, o registro está faltando.
2. Avalie o impacto antes de aprovar. Antes de dizer sim, responda: isso muda o prazo? O custo? Some com outra entrega? João, diretor de uma PME, aprovava toda alteração “rapidinho” — até perceber que a soma das mudanças pequenas tinha estourado o cronograma em três semanas sem ninguém notar.
O que fazer: nenhuma mudança é aprovada sem o campo “impacto” preenchido, nem que seja em uma frase.
3. Defina um dono, não um comitê. Cada change request precisa de uma pessoa com autoridade para aprovar ou recusar. Quando a decisão depende de “levar para a reunião”, ela trava por semanas. Em PME, o dono costuma ser quem lidera a área impactada, não precisa de mais que isso. Se a dúvida é quem tem autoridade para decidir, vale entender antes o papel do sponsor no sucesso do projeto.
4. Priorize com critério, não por quem gritou mais alto. Quando vários pedidos chegam juntos, o que entra primeiro é o de maior valor e urgência, não o de quem pediu por último. Esse é o mesmo princípio de como priorizar projetos quando tudo é urgente.
Quando simplificar e quando apertar o controle
Em operações com poucas mudanças e time pequeno, o modelo de change request acima já basta: registro, dono e critério de aceite. Não invente mais camadas.
Aperte o controle só quando o volume de mudanças crescer, quando cada alteração mexer em várias áreas, ou quando o impacto for crítico para o cliente. Aí vale uma rotina fixa de revisão dos pedidos, mas mantendo o registro simples. Referências como o PMI tratam controle de mudanças em projetos complexos, mas para a maioria das PMEs o excesso de processo trava mais do que protege.
O sinal de que você exagerou: se aprovar uma mudança pequena leva mais tempo do que executá-la, o controle virou o problema.
Um change request modelo bem aplicado não é papelada, é o que evita que mudanças se percam no corre-corre e virem retrabalho, atraso ou cliente insatisfeito. Ele conecta o que foi pedido ao que foi entregue, com dono e impacto visíveis.
Na Projetiq, estruturar esse tipo de controle de mudanças faz parte do diagnóstico operacional. Em 3 semanas, mapeamos onde sua operação perde tempo com mudanças mal geridas e montamos um fluxo que cabe no seu time.
👉 Quero começar pelo diagnóstico — gratuito e sem compromisso.
