Statement of Work (SOW): O que incluir (com template)

Um statement of work (SOW) é o documento que transforma um acordo verbal em um compromisso de projeto vinculante. Sem ele, tanto o cliente quanto o fornecedor entram em um projeto carregando premissas diferentes sobre o que será entregue, quando e a que custo.

Acertar o SOW logo no início economiza semanas de retrabalho, disputas e debates caros sobre escopo mais adiante. Este guia cobre todas as seções que um bom SOW precisa ter, os três tipos disponíveis, como ele se compara a documentos semelhantes e um template que você pode adaptar hoje mesmo.

O que é um statement of work (SOW)?

Um statement of work (SOW) é um documento formal de projeto que define o escopo do trabalho, os entregáveis, o cronograma, os critérios de aceitação e os termos entre um cliente e um fornecedor ou equipe de projeto. É o equivalente contratual do project charter: o charter autoriza o projeto internamente; o SOW rege o acordo externo ou multifuncional que faz o trabalho acontecer.

O SOW responde a cinco perguntas que precisam estar resolvidas antes do início do trabalho:

• O quê está sendo feito? (escopo e entregáveis)
• Como será feito? (metodologia e padrões)
• Quando será feito? (cronograma e marcos)
• Onde será feito? (local e ambiente)
• Quanto vai custar? (termos de pagamento e valores)

Contratos costumam anexar um SOW como um exhibit, tornando-o um documento legalmente referenciado. É por isso que a precisão importa muito mais aqui do que em ferramentas de planejamento interno.

Principais fatos

• Organizações com um processo formal de SOW relatam uma redução de 28% em disputas de escopo e ordens de mudança em comparação com aquelas que dependem apenas de acordos verbais (Project Management Institute, 2023).
• 73% dos projetos de TI que fracassaram citaram requisitos e escopo pouco claros como causa principal (Standish Group CHAOS Report, 2022).
• O SOW médio tem de 3 a 10 páginas em projetos de serviços profissionais; contratos complexos de construção ou governo costumam chegar a mais de 50 páginas (PMI Practice Standard for Project Estimating, 2021).

O que incluir em um statement of work

Todo SOW deve cobrir as seções a seguir. Alguns setores adicionam cláusulas especializadas (segurança, compliance, seguro), mas essas dez formam a base universal.

As seções de escopo e entregáveis carregam o maior peso legal. Linguagem vaga aqui é a maior causa de disputas. "Entregar um site" não é um entregável. "Entregar um site de marketing responsivo, de cinco páginas, com formulário de contato, integração com CMS e conformidade com acessibilidade WCAG 2.1 AA até 31 de julho" é.

A seção de premissas costuma ser deixada de lado, mas é igualmente importante. Se o seu SOW assume que o cliente vai fornecer os ativos de marca na segunda semana e isso não acontece, você precisa de um registro por escrito de que o atraso partiu do cliente, não de você.

Tipos de statement of work

Existem três tipos de SOW, e escolher o certo depende de quão bem o escopo do projeto pode ser definido de antemão.

Um design/detail SOW dá ao cliente controle máximo, mas exige o maior esforço de especificação prévia. Se os requisitos estiverem incompletos, o fornecedor vai seguir exatamente a letra do documento, e o cliente acaba insatisfeito com um resultado tecnicamente compatível.

Um performance-based SOW dá ao fornecedor liberdade para inovar, mas exige resultados claros e mensuráveis. Se os critérios de aceitação forem fracos, disputas sobre se o padrão foi atingido se tornam frequentes.

A maioria dos SOWs do mundo real combina tipos. Um projeto de software pode usar critérios baseados em performance para aceitação de features, ao mesmo tempo em que especifica a composição exata da equipe (level-of-effort) para o staffing.

SOW vs project charter vs scope statement

Esses três documentos costumam confundir as equipes porque se sobrepõem. Veja como diferenciá-los:

Um projeto pode ter os três. O SOW com o cliente define o que o fornecedor deve entregar. O project charter autoriza internamente o PM do fornecedor a mobilizar recursos. O scope statement detalha o trabalho para o planejamento da equipe interna.

O SOW também difere de um Master Service Agreement (MSA). Um MSA estabelece os termos legais gerais para todo o trabalho entre duas partes (responsabilidade, propriedade intelectual, resolução de disputas). Os SOWs são então emitidos sob o MSA para engajamentos específicos. Pense no MSA como o framework e em cada SOW como uma ordem de tarefa dentro dele.

Como escrever um statement of work

Alinhe o escopo, defina entregáveis e aceitação, estabeleça marcos e pagamento, depois trave as mudanças com assinaturas.

Passo 1: Alinhe o escopo antes de escrever

Converse com todas as partes interessadas antes de abrir um documento. Realize um workshop de escopo com o cliente, os líderes de entrega, o jurídico e o financeiro. Use uma matriz de rastreabilidade de requisitos para capturar e vincular requisitos aos entregáveis. A escrita fica fácil assim que você sabe com o que está concordando.

Passo 2: Escreva a visão geral do projeto

Um parágrafo, em linguagem simples. Diga quem é o cliente, quem é o fornecedor, qual problema de negócio o projeto resolve e o resultado de negócio esperado. Evite linguagem de marketing. "Reduzir o tempo de resposta a leads do cliente de 48 horas para menos de 4 horas" é mais útil do que "transformar as operações comerciais do cliente".

Passo 3: Defina o escopo e os itens fora do escopo

Liste todas as tarefas e serviços que fazem parte do engajamento. Depois liste explicitamente o que está fora do escopo. Essa segunda lista é tão importante quanto a primeira. Se você não disser que algo está fora do escopo, algumas partes interessadas vão presumir que está incluído.

Uma work breakdown structure (WBS) é uma ferramenta prática aqui. Construa a WBS primeiro e depois use-a para preencher a seção de escopo do seu SOW. A WBS obriga você a decompor o trabalho a um nível em que nada de ambíguo sobreviva.

Passo 4: Defina entregáveis e critérios de aceitação

Para cada entregável, responda: O que é? Em que formato? Quem revisa? Que padrão de qualidade precisa atender? Qual é o prazo de aprovação?

Conecte os critérios de aceitação ao seu project baseline para ter um ponto de referência ao medir o progresso ao longo do projeto.

Passo 5: Construa o cronograma

Mapeie os marcos em datas do calendário. Inclua dependências do lado do cliente (entrega de dados, aprovações, sign-offs) com seus respectivos prazos. Anote quais marcos são gates: o trabalho na próxima fase não pode começar até que o cliente aprove a fase anterior.

Um plano de comunicação combina naturalmente com essa etapa. Defina como o progresso será relatado, com que frequência e para quem.

Passo 6: Combine os termos de pagamento

Especifique o valor total do contrato, o cronograma de pagamento (baseado em marcos ou em calendário), as instruções de faturamento e o que dispara cada pagamento. Inclua disposições sobre atraso de pagamento e o que acontece com o trabalho se o pagamento atrasar.

Passo 7: Adicione a gestão de mudanças e as assinaturas

Defina o processo de solicitação de mudança: quem pode enviar uma mudança, quem a avalia, quanto tempo leva a revisão e como as mudanças afetam preço e cronograma. Ambas as partes assinam. Mantenha as cópias assinadas acessíveis tanto ao PM quanto ao jurídico.

Consulte sua matriz RACI ao atribuir autoridade de aprovação no processo de mudança. Isso evita confusão sobre quem é responsável pelas decisões.

Template de statement of work

Abaixo está uma estrutura mínima de SOW que você pode copiar e adaptar. Substitua os campos entre colchetes pelos detalhes reais do seu projeto.

---

STATEMENT OF WORK

Nome do projeto: [Nome do Projeto] Cliente: [Organização Cliente] Fornecedor/Prestador de Serviço: [Sua Organização] Data de vigência: [Data] Referência do contrato: [Número do MSA ou ID do contrato, se aplicável]

---

1. Visão geral do projeto

[Nome do cliente] está contratando [Nome do fornecedor] para [descrever o que o projeto faz e o resultado de negócio que ele endereça]. Este SOW rege todo o trabalho realizado entre [Data de Início] e [Data de Término].

2. Escopo do trabalho

Dentro do escopo:

• [Tarefa ou serviço 1]
• [Tarefa ou serviço 2]
• [Tarefa ou serviço 3]

Fora do escopo:

• [Item excluído 1]
• [Item excluído 2]

3. Entregáveis

4. Cronograma e marcos

5. Critérios de aceitação

Cada entregável é aceito quando: [descrever o padrão mensurável, por exemplo, "todos os testes automatizados passam com zero defeitos críticos, a equipe de QA do cliente aprova em até 5 dias úteis após a entrega"].

6. Premissas e restrições

• O cliente vai fornecer [dados ou acesso específicos] até [Data].
• O trabalho é realizado em [local ou ambiente].
• Todos os entregáveis estão em [idioma].

7. Termos de pagamento

Valor total do contrato: [Valor] Cronograma de pagamento: [ex.: 30% na execução, 40% na aprovação do marco 2, 30% na aceitação final] Faturamento: [Instruções para envio da fatura]

8. Gestão de mudanças

Mudanças no escopo, cronograma ou custo exigem uma Solicitação de Mudança por escrito enviada a [nome/cargo]. O fornecedor responderá em até [X] dias úteis com uma avaliação de impacto. Nenhuma mudança entra em vigor sem aprovação por escrito de ambas as partes.

9. Assinaturas autorizadas

---

Erros comuns ao escrever um statement of work

Entregáveis vagos. "Um relatório" não é um entregável. "Uma análise escrita de 20 páginas em formato PDF cobrindo X, Y e Z, entregue até [data]" é. Todo entregável precisa de um formato, um padrão de sucesso e um prazo.

Ausência da lista de itens fora do escopo. Clientes frequentemente presumem que trabalhos relacionados estão incluídos, a menos que sejam explicitamente excluídos. Se você não colocar isso por escrito, vai acabar fazendo esse trabalho de graça.

Cronogramas irrealistas sem dependências do cliente. Cronogramas que dependem de ações do cliente (entrega de dados, aprovações, provisionamento de acesso) precisam mostrar essas dependências explicitamente. Se o cliente está duas semanas atrasado com uma exportação de dados, sua data de entrega muda. O SOW deve dizer isso.

Critérios de aceitação que não podem ser medidos. "Alta qualidade" não é um critério de aceitação. "Zero bugs SEV-1, tempo de carregamento abaixo de 2 segundos em conexão 4G, conformidade WCAG 2.1 AA verificada por scan automatizado" é.

Assinatura de uma única parte. Um SOW assinado por apenas uma parte não é um acordo mútuo. Ambas as partes devem assinar antes do início do trabalho.

Ignorar a seção de gestão de mudanças. Equipes que pulam essa seção passam a segunda metade do projeto discutindo se o escopo mudou e quem tem que pagar por isso. Escreva o processo antes que a primeira solicitação de mudança chegue.

---

Um statement of work bem escrito se paga na primeira vez que surge uma disputa de escopo. Com entregáveis claros, critérios de aceitação mensuráveis e um processo de mudança explícito, ambas as partes gastam menos tempo discutindo e mais tempo construindo. Use o template acima como ponto de partida, peça que ambas as partes revisem cuidadosamente cada seção e trate a linha de assinatura como o momento em que o projeto de verdade começa.