Você ganhou o contrato. Três semanas após o início do trabalho, o cliente pede uma segunda rodada de designs que nunca foram orçados, e o projeto que você planejou para quatro semanas começa a se estender silenciosamente para seis. Um statement of work é o documento que impede que isso aconteça. Este guia explica o que é um statement of work, as nove partes que todo bom documento deve incluir, um exemplo preenchido e como escrever um que se mantenha firme quando o trabalho fica complicado.

Um statement of work, ou SOW, é um documento que define o trabalho em um projeto ou contrato de serviços: as entregas, o cronograma, as condições de pagamento e os critérios de aceitação, além do que está explicitamente fora do escopo. Ele transforma um acordo feito na fase de proposta em um registro preciso e assinável ao qual ambas as partes podem ser responsabilizadas. Um contrato define a relação jurídica. O SOW define o trabalho.

O que é um statement of work?

Um statement of work é o documento que um prestador de serviços e um cliente assinam para definir exatamente o que será feito, quando, por quanto e como todos saberão que está concluído. Os SOWs são mais comuns em agências, consultorias, serviços profissionais, TI e construção civil, ou seja, em qualquer lugar onde uma empresa entrega um trabalho definido para outra.

É a ponte entre vender e entregar. A proposta dizia o que você poderia fazer. O SOW diz o que você vai fazer, com detalhes suficientes para que ninguém precise adivinhar depois.

Esse nível de detalhe é justamente o ponto. O scope creep não é raro: um estudo do PMI constatou que 52% dos projetos o experimentam, ante 43% cinco anos antes. Um SOW é o seguro mais barato que você pode contratar contra isso, porque o trabalho que está escrito e assinado é um trabalho que ninguém pode expandir silenciosamente.

Statement of work vs scope of work, MSA e contrato

Esses quatro termos são usados como se significassem a mesma coisa. Não significam.

  • Scope of work é uma seção dentro do statement of work: a descrição do trabalho em si. As pessoas frequentemente dizem "scope of work" quando querem dizer o SOW completo, mas tecnicamente o scope é o "o quê" e o SOW é o documento que o envolve com cronogramas, pagamento e critérios de aceitação.
  • Master service agreement (MSA) é o contrato jurídico guarda-chuva que rege toda a relação: responsabilidade, confidencialidade, condições de pagamento e resolução de disputas. Muitos contratos de serviços funcionam com um único MSA e um SOW separado para cada contratação, de modo que os termos jurídicos são acordados uma única vez e apenas o trabalho muda.
  • Contrato é o acordo jurídico vinculante. Um SOW assinado geralmente é um contrato, ou parte de um. Se você estiver comparando os documentos entre si, a diferença entre uma proposta e um contrato é uma leitura complementar bastante útil.

Se você quiser conhecer a origem: o SOW vem das licitações governamentais, onde se distingue de um Performance Work Statement e de um Statement of Objectives. Para trabalhos comerciais, raramente é necessário fazer essa distinção. O que você precisa é ter o trabalho escrito com clareza e assinado.

As 9 partes de um statement of work

A maioria das equipes sabe que deveria documentar o escopo e não o faz. Em uma pesquisa do setor, apenas cerca da metade das organizações afirmou "quase sempre" ou "sempre" criar um documento de escopo durante o planejamento. Aqui está a estrutura que torna isso ágil. Trate-a como um esqueleto que você preenche, não como uma página em branco para ficar encarando.

  1. Contexto e objetivos. Por que este projeto existe e qual resultado ele serve. O que um bom exemplo parece: um parágrafo curto que qualquer novo integrante da equipe pudesse ler e entender o propósito do trabalho.
  2. Scope of work. O trabalho específico, descrito como tarefas concretas. O que um bom exemplo parece: verbos e substantivos, não adjetivos. "Criar cinco landing pages", não "entregar uma presença digital incrível".
  3. Entregas. Os itens tangíveis que você entrega, cada um definido. O que um bom exemplo parece: formato e quantidade especificados, por exemplo "cinco designs de página entregues como arquivos Figma".
  4. Fora do escopo. O que você explicitamente não vai fazer. O que um bom exemplo parece: esta é a seção que salva o projeto. Nomeie as solicitações adjacentes mais óbvias (revisões extras, redação, hospedagem) e as exclua por escrito.
  5. Cronograma e marcos. Datas e pontos de verificação. O que um bom exemplo parece: marcos vinculados a entregas, para que o progresso seja visível e não apenas uma data no calendário.
  6. Cronograma de pagamentos. Valores, gatilhos e condições. O que um bom exemplo parece: pagamentos vinculados a marcos ou à aceitação, não apenas a datas, para que receber seja consequência de ter o trabalho aprovado.
  7. Critérios de aceitação. Como uma entrega é considerada concluída. O que um bom exemplo parece: objetivo e verificável, para que "finalizado" seja um fato, não um argumento.
  8. Premissas e dependências. O que você depende do cliente: acessos, conteúdo, aprovações dentro do prazo. O que um bom exemplo parece: identifica as responsabilidades do cliente, para que um atraso causado por ele seja atribuído a ele.
  9. Controle de mudanças. Como uma alteração no escopo é solicitada, precificada e aprovada. O que um bom exemplo parece: um processo escrito e breve, assinado da mesma forma que o SOW original. É isso que transforma um "você pode também..." em uma rápida emenda paga, em vez de uma tarde de trabalho gratuita.

Um exemplo de statement of work

Aqui está o esqueleto preenchido para um pequeno projeto de construção de site, simplificado para mostrar a estrutura.

Projeto: Redesign do site de marketing da Northwind Co.
Objetivos: Substituir o site atual de cinco páginas por um site mais rápido, alinhado à identidade visual e voltado para a captação de leads.
Scope of work: Criar e desenvolver cinco páginas (home, produto, preços, sobre, contato). Migrar o conteúdo existente. Configurar um formulário de lead integrado ao CRM do cliente.
Entregas: Cinco designs de página (Figma), um site construído no CMS do cliente e um formulário de lead conectado.
Fora do escopo: Redação de novos textos, migração de blog, hospedagem contínua, trabalho de SEO e mais de duas rodadas de revisões de design.
Cronograma: Kickoff na semana 1, designs na semana 3, desenvolvimento nas semanas 4 a 5, lançamento na semana 6.
Pagamento: 50% na assinatura, 50% na aceitação do lançamento. Prazo de 14 dias.
Aceitação: Cada página corresponde ao design aprovado e carrega em menos de dois segundos em uma conexão padrão.
Premissas: O cliente fornece logins, assets de marca e textos até o final da semana 1.
Controle de mudanças: Qualquer nova solicitação é dimensionada, precificada e adicionada como uma emenda assinada antes de o trabalho começar.

Observe como as linhas de "fora do escopo" e "aceitação" fazem a maior parte do trabalho de proteção. Elas são a diferença entre um projeto que termina e um que fica à deriva.

Como escrever um statement of work, passo a passo

  1. Comece pelo que você já acordou. Extraia o escopo, o preço e o cronograma da proposta ou do orçamento. Não reinvente condições que você já negociou.
  2. Escreva o escopo como tarefas e, em seguida, escreva o que está fora do escopo. As exclusões não são grosseiras. São o presente mais claro que você pode dar a um cliente, porque definem expectativas honestas.
  3. Defina cada entrega com seus critérios de aceitação. Combine cada "vamos entregar X" com "X está concluído quando Y." Esse único hábito evita a maioria dos conflitos ao final do projeto.
  4. Vincule marcos a pagamentos. Associe cada pagamento a um marco ou a uma entrega aceita, para que o fluxo de caixa acompanhe o progresso.
  5. Adicione premissas e uma cláusula de controle de mudanças. Declare o que você precisa do cliente e o processo exato para lidar com novas solicitações.
  6. Envie para assinatura antes de começar o trabalho. Um SOW que não está assinado é apenas uma expectativa. Assinar primeiro é parte do motivo pelo qual equipes disciplinadas entregam resultados: no setor, apenas 31% dos projetos são concluídos no prazo, dentro do orçamento e dentro do escopo, e um escopo não assinado e pouco claro é uma das principais razões para isso.

Os erros que permitem o scope creep

A maioria dos problemas de escopo tem origem nas mesmas lacunas:

  • Entregas vagas. "Um site" abre espaço para discussão. "Cinco páginas, estes templates, este CMS" não abre.
  • Nenhuma seção de fora do escopo. Se você não especifica o que não está fazendo, o cliente vai assumir que está.
  • Sem critérios de aceitação. Sem um critério para definir "concluído," qualquer entrega pode ser reaberta.
  • Sem controle de mudanças. Sem um processo documentado, cada nova solicitação vira uma negociação, e geralmente uma gratuita.
  • Sem assinatura. Um SOW não assinado não protege ninguém.

Essas lacunas são caras. O PMI estimou que as organizações desperdiçam cerca de 10% de cada dólar investido por causa de baixo desempenho em projetos. Um SOW mais rigoroso é uma das formas mais acessíveis de recuperar parte desse valor.

De um negócio fechado a um SOW assinado, sem redigitar nada

A maioria dos SOWs ainda é criada manualmente: abrir o documento do último cliente, fazer localizar e substituir os nomes, reinserir o escopo e os valores, exportar um PDF, enviá-lo por e-mail e correr atrás da assinatura. Cada etapa é uma chance de enviar o número errado.

Os dados de que você precisa já estão no seu CRM. O negócio que você acabou de fechar já tem o cliente, os itens, o preço e o responsável vinculados a ele. O Portant gera o statement of work a partir de um modelo que você já usa, preenche com os dados do seu negócio no HubSpot, incluindo os itens de linha, e adiciona eSignature integrada, para que o documento assinado sincronize de volta ao registro do negócio com o status rastreado. Você mantém seu próprio modelo e formato. Ninguém redigita um negócio que já existe no CRM. É a mesma ideia por trás da automação de documentos em geral: pare de recriar documentos que você já tem.

Perguntas frequentes

O que é um statement of work em gerenciamento de projetos?

Em gerenciamento de projetos, o statement of work é o documento que define o escopo, as entregas, o cronograma e os critérios de aceitação do projeto antes do início dos trabalhos. É o documento de referência ao qual todos recorrem quando surge uma dúvida sobre escopo.

Quem redige o statement of work?

Geralmente o prestador de serviços elabora o documento, pois conhece o trabalho, e o cliente revisa e assina. Em projetos maiores, um gerente de projetos ou líder de conta é o responsável, frequentemente partindo da proposta que o vendedor já havia acordado.

Um statement of work tem validade legal?

Um SOW assinado é geralmente vinculante, seja como contrato autônomo ou como ordem de serviço dentro de um contrato-mestre de serviços. Peça a um advogado que revise seu modelo de contrato pelo menos uma vez, especialmente as cláusulas de pagamento, responsabilidade e rescisão.

Qual é a diferença entre um statement of work e uma ordem de compra?

Um statement of work descreve o trabalho a ser realizado e como será avaliado como concluído. Uma ordem de compra é a autorização do comprador para gastar um valor determinado nesse trabalho. O SOW define o escopo; a ordem de compra compromete o orçamento.

Qual deve ser o tamanho de um statement of work?

O suficiente para eliminar ambiguidades, e nada além disso. Um SOW de serviços objetivo geralmente tem de duas a quatro páginas. A clareza importa mais do que a extensão: um SOW enxuto de três páginas é melhor do que um de dez páginas cheio de informações desnecessárias.

Se seus SOWs vivem em um Google Doc que você copia e edita novamente para cada cliente, você pode conectar esse modelo ao seu CRM e enviá-lo para assinatura em um único fluxo. Veja como o Portant cria e envia um statement of work a partir de um HubSpot document template.