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.
Resumo em áudio (~1 min) do post, gerado por IA (voz pt-BR).

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.

Posts Similares

3 Comentários

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *