Como este tema funciona na sua empresa
Poucos projetos, com consultores isolados. Desafio: não tem capacidade interna de detalhar escopo. Solução: contratar consultor com experiência em escopo (que detalha com você). Contrato simples com escopo claro, pagamento por marco reduz risco. Documentação mínima: SoW em 2-3 páginas, cronograma visual, critério de aceite.
Múltiplos projetos simultâneos. Desafio: manter controle de escopo, mudanças, custo entre múltiplos projetos. Solução: SoW padronizado, processo formal de change request, pagamento por marco, reunião semanal de alinhamento. Documentação: arquitetura, cronograma detalhado, lista de entregáveis, plano de testes.
Portfolio complexo de projetos. Desafio: padronizar processos, consolidar termos. Solução: PMO centralizado com template de contrato, processo formal de change, integração com ERP de projeto. Documentação: SoW muito detalhado, diagramas de arquitetura, matriz de risco, plano de transição pós-go-live.
Contrato de projeto de TI é acordo que define entrega de trabalho temporal e específico (software customizado, implementação de sistema, infraestrutura), com início, fim, escopo claro e critério de aceite. Diferencia-se de serviço recorrente (que é contínuo) e de suporte (que é reativo). Inclui definição de escopo, cronograma, preço, critério de aceite e processo de mudança[1].
Statement of Work (SoW): o documento que evita disputa de escopo
SoW é documento detalhado que descreve exatamente o que será entregue. Deve conter: funcionalidades (o que vai ter?), tecnologia (qual stack?), arquitetura (como é estruturado?), cronograma com marcos, entregáveis (código, documentação, testes?), critério de aceite (como você valida que está pronto?). SoW deve ser tão detalhado que elimina ambiguidade. Exemplo: "Sistema de vendas com relatório de faturamento" é vago. Melhor: "Sistema web em Python (Django), banco de dados PostgreSQL, interface em React, relatório de faturamento com dados por período, PDF exportável, até 500 usuários simultâneos". Quanto mais detalhe no SoW, menos disputa depois.
Preço fixo vs. Time & Materials vs. híbrido: qual modelo escolher
Preço fixo: você negocia um valor (ex: R$100k) e fornecedor entrega pelo preço. Risco: em escopo mal definido, fornecedor fica apertado e entrega qualidade ruim. Time & Materials (T&M): você paga por horas consumidas (ex: R$200/hora). Risco: custo pode crescer indefinidamente. Híbrido: preço fixo para escopo base + T&M para mudanças. Melhor prática: escopo claro permite preço fixo (ambas partes sabem o que esperar). Mudanças são T&M. Exemplo: "Implementação core do sistema = R$100k fixo. Customizações adicionais = R$200/hora". Isso alinha incentivos.
SoW simples (1-2 páginas): objetivo do projeto, funcionalidades principais, tecnologia, cronograma (datas de início, fim, 1-2 marcos intermediários), entregáveis (lista simples: código, documentação, testes). Contrato básico: escopo, preço fixo, pagamento em 2-3 partes (adiantamento, meio, fim), termo de aceite simples. Reuniões: 1x/semana, via call. Documentação: email de alinhamento, não ata formal.
SoW detalhado (5-10 páginas): objetivo, funcionalidades organizadas por módulo, tecnologia com justificativa, arquitetura em diagrama, cronograma com 4-6 marcos, entregáveis com critério de qualidade, plano de testes. Contrato: SoW anexado, processo de mudança formal (change request form), pagamento por marco, termo de aceite detalhado (quem aprovou, data, ressalvas). Reuniões: 1x/semana, ata formal. Integração com sistema (Jira, Monday, Asana) para rastreamento.
SoW muito detalhado (20+ páginas): funcionalidades por user story, tecnologia com análise de trade-offs, arquitetura em multiple views (funcional, dados, segurança), cronograma com todos os marcos e milestones, entregáveis com SLA de qualidade (coverage de testes 80%+, performance targets, segurança). Contrato: template corporativo, processo de change formalizado com comitê de aprovação, SLA de resposta a mudança (análise em 5 dias), pagamento por marco com holdback (% retido até go-live), termo de aceite com auditoria técnica. Reuniões: Daily standup, weekly steering, monthly executive review. Documentação: central em SharePoint/Confluence.
Critério de aceite: como validar que projeto está pronto
Aceite é formalização de que entrega atende expectativa. Deve ser testável, não subjetivo. Ruim: "sistema deve ser rápido". Bom: "API deve responder em <500ms em 95% das requisições sob carga de 100 usuários simultâneos, validado em teste de carga". Critério de aceite deve ser definido no SoW. Validação: testes de funcionalidade (funciona?), performance (rápido?), segurança (seguro?), documentação (está documentado?). Termo de aceite é documento que formaliza validação. Deve incluir: data, quem aprovou, qual critério foi testado, ressalvas (ex: "aceito com ressalva de que customização X fica para fase 2"). Sem termo assinado, não pagar última parcela.
Garantia em projeto: período pós-entrega de correção
Após entrega de projeto, fornecedor oferece período de garantia (30-90 dias típico). Durante garantia, qualquer bug descoberto é corrigido sem custo. Após garantia, manutenção é contrato separado (pago). Garantia é diferente de manutenção: garantia é "conserta o que não funciona conforme prometido"; manutenção é "ajuda com evolução, novos requisitos, otimização". Contrato deve deixar claro: qual é o período de garantia? O que é coberto? Exemplos de bug vs. requisito novo? Tempo de resposta durante garantia (ex: crítico em 4h)?
Escopo creep: controle de mudanças é essencial
Escopo creep é quando projeto gradualmente expande sem formalização. Cliente pede "um pequeno ajuste aqui", "uma funcionalidade ali", e de repente projeto está 30% maior sem pagamento adicional. Fornecedor fica apertado, qualidade sofre, atraso inevitável. Mitigação: qualquer mudança precisa de change request formal. Mudança é proposta, estimada (quanto custa?), aprovada, e formalizada em aditivo. Exemplo de processo: (1) Cliente solicita mudança. (2) Fornecedor estima em 2 dias úteis. (3) Cliente aprova ou rejeita. (4) Se aprova, aditivo é assinado, mudança é incorporada ao cronograma. Sem esse processo, creep é garantido.
Sinais de que sua empresa precisa estruturar contrato de projeto
Se você se reconhece em três ou mais cenários abaixo, defina SoW claro e processo formal.
- Projetos anteriores tiveram atraso ou saíram do escopo original
- Não sabe exatamente o que fornecedor vai entregar até começar
- Disputas frequentes sobre "isso era escopo ou não?"
- Não tem critério claro de quando projeto está pronto
- Comunicação com fornecedor é informal (Whatsapp, conversas)"
- Mudanças de escopo são pedidas verbalmente e "resolvidas depois"
- Termo de aceite é assinado apressadamente ou sem validação técnica
Caminhos para estruturar contrato de projeto
Você estrutura SoW e processo, fornecedor segue.
- Perfil necessário: PMO ou gerente de projeto com experiência em contratação
- Tempo estimado: 1-2 semanas para criar template, treinar equipe
- Faz sentido quando: você tem capacidade interna e projetos são frequentes
- Risco principal: template pode ser incompleto se você não tem experiência
Consultor de PM ou integrador estabelece processo.
- Tipo de fornecedor: Consultor de Project Management, integrador sistêmico
- Vantagem: experiência com múltiplos contextos, template pronto
- Faz sentido quando: você quer implementar rapidamente ou tem poucos projetos
- Resultado típico: template de SoW, processo de change, treinamento de equipe
Precisa estruturar contratos de projeto?
Se você quer evitar disputa de escopo e atraso em projetos, o oHub conecta você a consultores de PM e integradores que ajudam a estruturar SoW, processo de change e contrato. Descreva seu contexto e receba propostas de suporte.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é a diferença entre projeto e serviço recorrente?
Projeto: tem início, fim, entrega específica. Serviço recorrente: contínuo, sem fim definido. Projeto é "implementar novo sistema em 6 meses". Serviço recorrente é "suportar sistema após go-live".
Preço fixo ou Time & Materials é melhor?
Preço fixo é melhor se escopo é claro. T&M é melhor se há incerteza. Híbrido (fixo + T&M para mudanças) é mais equilibrado. Sempre detalhar escopo primeiro, depois escolher modelo.
Como formalizar que projeto está pronto para aceite?
Critério de aceite deve estar em SoW (testável, não subjetivo). Validação é feita em testes (funcionalidade, performance, segurança). Termo de aceite é assinado após testes passarem. Sem termo, não libere última parcela.
Como controlar mudanças de escopo durante projeto?
Processo formal de change request: cliente solicita, fornecedor estima custo/prazo, cliente aprova, aditivo é assinado, mudança é implementada. Sem esse processo, escopo creep é garantido.
O que cobrir em Statement of Work?
Objetivo, funcionalidades, tecnologia, arquitetura, cronograma com marcos, entregáveis com critério de qualidade, plano de testes, critério de aceite, processo de mudança, garantia pós-projeto.
Qual é o período de garantia típico em projeto?
30-90 dias é comum. Durante garantia, bugs encontrados são corrigidos sem custo. Após garantia, manutenção é contrato separado pago. Definir em contrato qual é o período e o que é coberto.
Fontes e referências
- Project Management Institute (PMI) — PMBOK Guide: Project Management Body of Knowledge
- ABNT (Associação Brasileira de Normas Técnicas) — Normas de Gestão de Projetos e Serviços
- Gartner — Project Contracting Best Practices and Scope Management
- Forrester — IT Project Delivery and Risk Management Strategies