Como este tema funciona na sua empresa
Escopo é vago em contrato. Disputa frequente: cliente pensa que algo está incluído, fornecedor acha que é adicional. Sem processo formal de mudança. Relacionamento torna-se frustrado. Solução: definir escopo em poucas páginas, bem claro. "Suporte inclui: tickets, análise, implementação. Não inclui: consultoria arquitetônica".
Escopo mais claro (lista de serviços). Disputa ainda ocorre em casos borderline. Processo de mudança existe informalmente. Desafio: não é rápido. Solução: formalizar: Cliente solicita (email), fornecedor estima (2 dias úteis), cliente aprova, aditivo é assinado.
Escopo definido por exemplo: "in-scope: X, Y, Z; out-of-scope: A, B, C". Processo formal de mudança com aprovação, impacto financeiro, timeline. Matriz de responsabilidades clara. Raramente há disputa porque limite está claro desde início.
Disputa de escopo é conflito entre cliente e fornecedor sobre o que está incluído (in-scope) vs. o que é adicional (out-of-scope) em contrato. Causa: definição vaga de escopo no contrato original. Resultado: cliente quer pagar o mesmo, fornecedor quer cobrar mais. Processo claro de mudança de escopo (change request, aprovação, formalização) resolve 80% das disputas. Sem processo, escalação é comum[1].
Definição clara de escopo: in-scope vs. out-of-scope com exemplos
Contrato deve especificar o que está incluído por exemplo, não descrição genérica. Ruim: "Suporte a infraestrutura". Bom: "Suporte a infraestrutura inclui: gerenciamento de servidores, backup diário, monitoramento 24/7, recuperação de desastre. Não inclui: desenvolvimento de código, consultoria arquitetônica, suporte a aplicação do cliente". Quanto mais claro, menos disputa depois. Formato recomendado: tabela com "Atividade", "In-Scope", "Out-of-Scope".
Scope creep: como acontece silenciosamente
Creep não acontece de repente. Começa com pequenos pedidos informais: "pode dar uma olhada nisse problema?" Fornecedor faz, cliente fica feliz, pede mais. Após 1 ano, projeto está 30% maior sem pagamento adicional. Fornecedor fica apertado (está fazendo 30% a mais pela mesma taxa), qualidade sofre. Como evitar: qualquer mudança precisa de change request formal. Cliente preenche formulário (descrição, urgência, impacto). Fornecedor estima (custo, prazo). Cliente aprova ou rejeita. Se aprova, aditivo é assinado. Sem esse processo, creep é garantido.
Escopo simples em 1 página: lista de 8-10 atividades em-scope, 5 atividades out-of-scope. Exemplo: "Em-scope: responder tickets helpdesk, troubleshooting básico. Out-of-scope: desenvolvimento de código, consultoria". Mudança de escopo: email de requisição, fornecedor responde com estimativa em 5 dias, cliente aprova ou nega por email. Documentação: email é suficiente (não formal).
Escopo detalhado em 3-5 páginas com tabela de in/out-scope. Exemplos concretos: "Em-scope: backup diário (automático, retenção 30 dias). Out-of-scope: restore a pedido (cobrado extra)". Mudança de escopo: formulário formal (cliente preenche). Fornecedor analisa (2-5 dias), responde com: impacto (mais recurso?), custo (quanto?), timeline (quando?). Cliente aprova (autoriza na forma de aditivo ou PO), mudança é implementada. Registro: histórico de mudanças mantido.
Escopo muito detalhado (10+ páginas) organizando por domínio (suporte, infra, projetos). Tabela por serviço: o que está incluído em SLA, o que é adicional com pricing. Mudança de escopo: formulário web (Jira Service Management, ServiceNow), workflow de aprovação (gestor autoriza, financial aprova). Fornecedor analisa (5 dias úteis), responde com impacto. CAB (Change Advisory Board) aprova ou nega. Se aprova, implementa. Histórico central de todas mudanças. Relatório trimestral: quanto escopo mudou, qual custo adicional.
Processo de Change Request: estrutura que funciona
Estrutura: (1) Solicitação: cliente descreve mudança, benefício, urgência. (2) Análise: fornecedor estima em 5 dias úteis (impacto, custo, timeline). (3) Aprovação: cliente aprova ou rejeita. Se aprova, autoriza (assinatura, PO, aditivo). (4) Implementação: mudança é incorporada ao contrato e cronograma. (5) Rastreamento: histórico de todas mudanças mantido. Isso não é burocracia — é proteção. Sem processo, disputa é garantida. Com processo, ambas as partes sabem o que esperar.
Critério de classificação: deixe explícito o limite
Critério ajuda a decidir in/out sem disputar. Exemplo: "Se a atividade toma >4h/mês de seu tempo e é recorrente, deve ser escopo. Se é um-off ou ad hoc (<4h/mês), é out-of-scope e cobrado T&M". Esse tipo de critério reduz ambiguidade. Outro exemplo: "Mudanças que afetam apenas usuário (1-2 pessoas) são out-of-scope. Mudanças que afetam múltiplos usuários (3+) são in-scope". Deixar explícito economiza discussão depois.
Sinais de que disputa de escopo é iminente
Se você se reconhece em três ou mais cenários abaixo, defina escopo claro urgentemente.
- Escopo em contrato é vago ou uma frase genérica
- Você e fornecedor frequentemente discordam sobre o que está incluído
- Cliente pede algo, fornecedor diz "é adicional, custa extra"
- Não há processo formal de mudança de escopo
- Mudanças são pedidas informalmente (Whatsapp, calls) sem documentação
- Fornecedor começou a fazer "menos" do que antes
- Relacionamento está ficando tenso (comunicação defensiva)
Caminhos para resolver disputa de escopo
Você renegocia escopo com fornecedor.
- Perfil necessário: gestor de fornecedor com autoridade para negociar
- Tempo estimado: 1-3 semanas de conversa com fornecedor
- Faz sentido quando: relacionamento é bom, ambas as partes querem resolver
- Risco principal: renegociação pode não chegar a acordo
Mediador/consultor ajuda a resolver disputa.
- Tipo de fornecedor: Consultor de vendor management, advogado corporativo
- Vantagem: imparcialidade, expertise em resolução de conflito
- Faz sentido quando: disputa é crônica ou ambas as partes não conseguem conversar
- Resultado típico: escopo redefinido, processo de mudança formalizado, acordo documentado