Escopo, prazo e custo: mudou um, você precisa conversar novamente sobre os outros
Leitura: ~6 minutos
TL;DR
- Cliente contratou o projeto A; escopo cresceu para A+B+C+D.
- Mesmo assim, entrega é cobrada na data e no orçamento do A.
- Mudança de escopo arrasta cronograma, custo, recursos, riscos e qualidade.
- Aceitar a mudança é fácil; aceitar as consequências exige renegociar.
- Renegocie na hora da mudança — não na data da entrega.
O cliente contratou o projeto A. Durante o desenvolvimento, o escopo cresceu para A + B + C + D. No fim, a entrega continua sendo cobrada na data e no orçamento negociados para o A.
Leia também: É só uma alteração: a mudança que destrói o planejamento — o post anterior deste cluster, sobre o instante em que o pedido “é só uma alteração” desmonta o cronograma.
Esse é o erro de projeto mais frequente que eu vejo em décadas de software: aceitar uma mudança e fingir que ela não tem consequências.
O hook desta pauta é simples: se o projeto de seis meses virou um projeto de nove meses em funcionalidades, ele não pode continuar sendo tratado como projeto de seis meses no calendário.
O triângulo não negocia sozinho
Escopo, prazo e custo formam um triângulo interdependente. Um vértice não muda sem esticar os outros dois — você escolhe conscientemente, ou o projeto escolhe por você (em atraso, em estouro, em qualidade reprovada).
O contrato é fechado na data da assinatura, com escopo estimado, equipe e orçamento estimados. Nada disso sobrevive intocável a seis meses de execução. O problema não é a mudança — é o silêncio sobre a mudança.
Baseline: sem ele, tudo vira briga de opinião
Antes de debater impactos, você precisa de um baseline: aquilo que estava acordado quando o projeto começou. Sem baseline, toda discussão de “isso era escopo original?” vira memória seletiva — o cliente lembra uma versão, a equipe lembra outra.
Com baseline, a conversa é factual: “o acordado era X; o que entrou depois foi Y; X tinha prazo T, X+Y não cabe em T”. Sem baseline (ou sem versionar mudanças sobre ele), a renegociação desanda em briga.
Impactos que a mudança puxa
Uma alteração de escopo não é um item a mais na lista — ela carrega impactos em cascata:
- Cronograma — funcionalidades novas ocupam sprint que já estava comprometida.
- Orçamento — horas extras, horas re-alocadas de outro projeto, custo de retrabalho.
- Recursos — a mesma equipe não se multiplica; alguém prioriza algo a menos.
- Riscos — dependências novas, integrações não testadas, prazos de terceiros.
- Qualidade — o buraco silencioso: escopo cresce, prazo e equipe não, e quem paga é a qualidade do que já estava no plano. Testes encurtados, código “provisório” que vira permanente, acúmulo de dívida técnica.
Aceitar uma mudança e aceitar suas consequências
Aqui está a armadilha de comunicação mais comum. O cliente pede B, C e D. A diz “tudo bem” — e aí vem a parte que ninguém disse em voz alta: em troca de quê?
As três moedas da renegociação
As três moedas disponíveis:
- Prazo — entrega esticada proporcionalmente ao escopo novo.
- Custo — horas novas contratadas para absorver o escopo novo.
- Escopo devolvido — entra B, sai C: troca explícita, projeto continua do mesmo tamanho.
Se nenhuma moeda é cobrada, a moeda paga é a qualidade — a mais barata de aceitar e a mais cara de conviver depois.
Quando renegociar prazo ou custo
Renegociação não é derrota. Quando o escopo desvia do baseline o suficiente para mudar qualquer uma das três moedas, a conversa precisa acontecer na hora em que a mudança é proposta, não na data da entrega.
Sinais de que é hora de renegociar
- O desvio acumulado de estimativas (por sprint) excede 10% da capacidade da equipe por dois sprints seguidos.
- Funcionalidades novas entram em cima do cronograma fechado, sem mover datas.
- O cliente começa a cobrar “só mais essa funcionalidade” sem perceber que já são três.
Integração entre os seis vértices (PMI)
O PMI trata escopo, cronograma, custos, recursos, riscos e qualidade como áreas integradas de gerenciamento de projeto. Uma mudança de escopo precisa passar por controle de mudanças que avalie os seis vértices — não é formalidade: é o que impede o silêncio de deslocar o custo para o vértice que o cliente não está olhando.
Mudou um vértice? Você conversa de novo sobre os outros. Nem mais, nem menos.
Conclusão
O cliente não é o vilão — ele não enxerga os impactos em cascata, e cabe a você mostrar. A equipe não é a vilã — ela aceita o trabalho novo porque quer entregar. O vilão é o silêncio.
Contratou A, cresceu para A+B+C+D, entrega na data e no orçamento do A: essa conta fecha só em um lugar, e é na qualidade. Renegociar em cima da mudança é mais barato do que renegociar em cima do fracasso.








3 Comentários