Entenda como Prova de Conceito, Statement of Work, Plano de Execução, Design Review e gates pré-início validam solução e prontidão antes da implantação.
Confira!
Prova de Conceito (PoC) e Statement of Work (SOW) são instrumentos diferentes e complementares. Em uma contratação de engenharia, a PoC serve para demonstrar, mediante teste ou avaliação objetiva, que uma solução proposta atende requisitos previamente definidos. O Statement of Work, por sua vez, descreve como o trabalho será executado: escopo, limites, entregáveis, responsabilidades, metodologia, equipe, cronograma, controles, documentos, testes e critérios de conclusão.
A diferença é decisiva porque uma contratação pode comprovar que o fornecedor possui experiência e ainda assim precisar validar aspectos específicos da solução ou da mobilização. A habilitação responde se o licitante atende aos requisitos de capacidade definidos no edital; a PoC pode responder se a solução ofertada demonstra determinada conformidade; e um SOW ou plano de execução pode responder como o contratado pretende organizar a execução daquele contrato concreto.
No regime da Lei nº 14.133/2021, a prova de conceito possui fundamento expresso: o art. 17, §3º, permite análise de conformidade da proposta do licitante provisoriamente vencedor por meio de amostras, exame de conformidade e prova de conceito, entre outros testes, desde que previstos no edital. Já o termo inglês Statement of Work não constitui uma fase autônoma da licitação brasileira. Quando um documento com essa função é exigido em contratação pública, sua obrigação, conteúdo, momento e consequência precisam estar ancorados no Termo de Referência, edital ou contrato, sem se transformar em requisito retroativo de habilitação.
A combinação correta é poderosa: PoC para demonstrar requisitos que precisam ser testados; SOW ou Plano de Execução para transformar o contrato em método, responsabilidades e sequência verificável antes da implantação. Quando esses instrumentos são planejados desde a fase preparatória, eles criam uma barreira entre “empresa selecionada” e “execução liberada” sem confundir competição, habilitação, conformidade da proposta e gestão contratual.
PoC e SOW respondem a perguntas diferentes
A prova de conceito testa uma afirmação sobre a solução. O SOW organiza uma afirmação sobre o trabalho.
| Instrumento | Pergunta principal | Momento típico | Resultado esperado |
| Habilitação técnica | O licitante demonstra capacidade segundo o edital? | licitação | habilitado/inabilitado |
| Prova de Conceito | A solução demonstrada atende aos requisitos testados? | avaliação da proposta, quando prevista | conforme/não conforme |
| Statement of Work | Como o trabalho será executado e controlado? | contratação/mobilização, quando previsto | documento aprovado/ajustado |
| Plano de Execução | Como recursos, método, cronograma e controles serão mobilizados? | pré-início | prontidão para executar |
| Design Review | O detalhamento técnico está maduro para construção/implantação? | pré-execução e por pacotes | liberado/comentado/rejeitado |
Misturar esses papéis produz problemas jurídicos e técnicos. Uma PoC não deve ser usada para escolher subjetivamente a “melhor ideia” quando o edital definiu critérios objetivos de julgamento. Um SOW não deve surgir depois da habilitação como uma prova adicional de capacidade que ninguém sabia que teria de cumprir.
Quando a Prova de Conceito agrega valor real
A PoC é útil quando uma característica crítica da solução não pode ser confirmada com segurança apenas por documentação declaratória, catálogo ou certificação.
Exemplos podem incluir, conforme o objeto:
- interoperabilidade entre sistemas;
- capacidade de processar determinado volume;
- aderência a requisito funcional específico;
- compatibilidade com ambiente existente;
- desempenho mensurável em cenário definido;
- execução de workflow crítico;
- leitura, exportação ou integração de dados;
- demonstração de função de segurança ou controle;
- validação de interface com tecnologia legada.
A PoC não é recomendável simplesmente porque o contratante “quer ver funcionando”. O requisito precisa ser relevante, testável e proporcional ao esforço imposto ao licitante.
A orientação do TCU sobre amostra e prova de conceito reforça que a exigência precisa ser justificada e cercada de critérios objetivos. O teste deve avaliar aquilo que o edital definiu, e não preferências descobertas durante a sessão.
Como especificar uma PoC objetiva
Uma PoC defensável começa antes da licitação, no desenho dos requisitos. Quanto mais vaga a especificação, maior a probabilidade de o teste se tornar subjetivo.
Uma matriz de PoC pode conter:
| ID | Requisito | Procedimento de teste | Entrada | Resultado esperado | Evidência | Critério |
| POC-01 | integração com protocolo X | conectar e executar cenário | ambiente definido | comunicação íntegra | log + tela + arquivo | passa/falha |
| POC-02 | desempenho mínimo | executar carga estabelecida | dataset padrão | valor ≥ limite | relatório exportado | passa/falha |
| POC-03 | exportação | gerar arquivo em formato requerido | dados de teste | arquivo válido | arquivo nativo | passa/falha |
| POC-04 | workflow | executar sequência funcional | roteiro de ações | etapas concluídas | registro de execução | passa/falha |
O roteiro deve indicar também ambiente, duração, responsabilidade por infraestrutura, condições de repetição, tolerâncias, tratamento de falha, documentação e forma de registro do resultado.
Quando a avaliação depende de julgamento humano, os critérios precisam ser decompostos em elementos observáveis. Expressões como “interface amigável”, “boa performance” ou “integração satisfatória” são insuficientes sem escala ou critério de verificação.
PoC não é demonstração comercial
Demonstração comercial e prova de conceito não são sinônimos. Uma demo normalmente apresenta funcionalidades escolhidas pelo fornecedor em ambiente controlado por ele. A PoC contratual testa requisitos escolhidos pelo contratante, segundo roteiro conhecido e evidências definidas.
Essa distinção evita uma armadilha comum: o fornecedor realizar uma apresentação convincente que não testa as condições críticas do objeto.
Na PoC, o contratante deve controlar a pergunta. O fornecedor demonstra a resposta.
Transparência e observabilidade do teste
O procedimento deve ser auditável. O TCU possui precedentes no sentido de exigir critérios detalhados e permitir acompanhamento da avaliação pelos interessados, preservadas as regras do certame.
Isso significa registrar:
- data e ambiente;
- participantes;
- versão do produto ou solução;
- requisitos testados;
- procedimento aplicado;
- dados de entrada;
- resultado observado;
- evidências geradas;
- divergências e ocorrências;
- conclusão de cada requisito;
- conclusão global.
Quando existe arquivo nativo produzido pelo teste, sua preservação pode ser mais útil do que um relatório em PDF isolado. Logs, arquivos de configuração, exportações, capturas técnicas e hashes podem reforçar rastreabilidade quando o objeto justificar esse nível de controle.
Onde o Statement of Work entra
Statement of Work é uma expressão utilizada em gestão de projetos, contratos e procurement para descrever o trabalho a ser realizado. Em português, sua função pode aparecer distribuída entre escopo, especificação técnica, plano de trabalho, plano de execução, ordem de serviço ou documentos equivalentes.
O mais importante é a função, não o idioma: transformar obrigação contratual em uma descrição operacional verificável.
Um bom SOW reduz zonas cinzentas ao explicitar:
- objetivo do trabalho;
- fronteiras de escopo;
- exclusões e premissas;
- entregáveis;
- pacotes e sequência;
- responsabilidades;
- interfaces com o contratante e terceiros;
- equipe e papéis;
- metodologia;
- cronograma e marcos;
- documentos e submittals;
- critérios de qualidade;
- inspeções e testes;
- change control;
- critérios de conclusão e handover.
Em contratação pública, esses elementos não podem contradizer ou reescrever o objeto depois da disputa. O SOW deve detalhar a execução dentro das obrigações previstas, não renegociar silenciosamente aquilo que foi licitado.
SOW não pode virar uma habilitação oculta
Esse é provavelmente o maior risco de usar o conceito de Statement of Work no pós-award.
Imagine um edital que exige apenas atestados e equipe mínima. Depois da habilitação, o contratante solicita um SOW e decide que rejeitará a empresa se a metodologia “não demonstrar maturidade suficiente”, sem que existam critérios prévios. Na prática, teria sido criada uma nova barreira de qualificação após a disputa.
A solução é estabelecer desde a contratação:
- que o documento será exigido;
- seu conteúdo mínimo;
- quando será entregue;
- como será analisado;
- quais itens podem gerar comentários ou necessidade de revisão;
- quais condições impedem a Ordem de Início;
- quais aspectos são apenas de planejamento e não modificam escopo;
- como divergências serão resolvidas.
Assim, o documento funciona como instrumento de gestão contratual, não como filtro improvisado.
Do SOW para o Plano de Execução
Em contratos de implantação, o SOW frequentemente precisa ser complementado por um Plano de Execução mais operacional. O primeiro estabelece o que será feito e como o trabalho está estruturado; o segundo pode detalhar a mobilização real, frentes, recursos, métodos e controles.
Uma estrutura prática pode conter:
Escopo e WBS
A WBS/EAP decompõe o contrato em partes controláveis e cria vínculo com cronograma, medição e entregáveis.
Organização e RACI
A matriz RACI ou equivalente identifica quem executa, responde, é consultado e informado para decisões críticas.
Cronograma e marcos
O cronograma precisa refletir lógica de execução, dependências, restrições, aprovações, suprimentos, testes e handover — não apenas datas de início e fim.
Materiais e submittals
Itens críticos devem possuir datasheet, requisito de equivalência, fluxo de análise e prazo de aprovação compatíveis com o cronograma.
QA/QC
O plano da qualidade e o PIT/ITP devem definir inspeções, critérios e pontos de testemunho.
Gestão documental
A matriz de entregáveis precisa estabelecer documentos progressivos, revisões e relação com medição e aceite.
Testes e comissionamento
Os testes precisam ser previstos desde o início, com pré-requisitos, instrumentos, evidências e critérios.
Handover
As-Built, Data Book, manuais, garantias e treinamento não devem surgir como “pendências finais”; precisam estar planejados desde a mobilização.
O Termo de Referência precisa preparar o terreno
PoC, SOW, critérios de aceite e gates só funcionam quando são desenhados na fase preparatória e aparecem claramente nos documentos da contratação.
A revisão técnica do Termo de Referência permite separar requisito de habilitação, requisito da proposta, teste de conformidade e obrigação de execução.
Se a organização deseja usar PoC, SOW ou gate de pré-início, o desenho começa no Termo de Referência para Obras e Serviços de Engenharia.
A Lei nº 14.133/2021 inclui no conteúdo do TR elementos como requisitos da contratação, modelo de execução, modelo de gestão do contrato, critérios de medição e pagamento e forma de seleção do fornecedor. Isso permite construir uma jornada coerente entre requisito, avaliação e execução.
O TR precisa distinguir:
- requisito do objeto;
- evidência exigida na proposta;
- evidência de habilitação;
- requisito testado em PoC;
- documento exigido depois da contratação;
- condição pré-Ordem de Início;
- evidência da execução;
- critério de medição;
- critério de recebimento.
Essa separação reduz a chance de que o mesmo requisito seja cobrado de maneiras diferentes e contraditórias ao longo do processo.
Design Review como terceira camada
Passar em uma PoC não significa que o projeto executivo esteja maduro. Interfaces, construtibilidade, materiais, detalhamentos e critérios de teste precisam ser verificados antes da liberação de cada pacote.
Design Review reduz o custo de corrigir incompatibilidades já incorporadas ao campo.
PoC demonstra uma característica da solução; SOW organiza o trabalho; nenhum dos dois substitui a revisão do projeto detalhado.
Quando a implantação depende de projeto executivo, shop drawings ou detalhamentos produzidos pela contratada, o Design Review atua sobre interfaces, requisitos, compatibilidade, construtibilidade e maturidade antes da execução.
Uma sequência típica pode ser:
- requisitos definidos no projeto/TR;
- proposta avaliada;
- PoC aplicada aos requisitos testáveis, quando cabível;
- contratação formalizada;
- SOW/Plano de Execução submetido;
- projeto executivo e submittals revisados;
- pendências críticas fechadas;
- Ordem de Início ou liberação por pacote.
Essa lógica cria barreiras independentes. Uma solução pode passar na PoC e ainda possuir detalhe de projeto inadequado. Um excelente projeto pode falhar se o Plano de Execução não prever recursos ou sequência coerentes. Cada instrumento verifica uma dimensão diferente.
Project Controls transforma o plano em baseline
SOW sem baseline vira apenas um documento aprovado. WBS, cronograma, marcos e entregáveis precisam alimentar um sistema de controle que mostre planejado, realizado, desvio e projeção.
Project Controls transforma o plano em referência mensurável para a execução.
Aprovar um SOW sem criar referência de controle reduz seu valor. O documento precisa se conectar ao cronograma e aos indicadores que serão acompanhados.
A Gestão de Projetos e Project Controls pode transformar WBS, marcos, cronograma e custos em baseline. Depois, mudanças e desvios são avaliados contra essa referência.
O vínculo pode ser estruturado assim:
| Elemento do SOW | Controle associado |
| entregável | WBS + marco |
| equipe | plano de mobilização |
| material crítico | procurement/submittal schedule |
| método | procedimento aprovado |
| interface | action/RFI register |
| inspeção | PIT/ITP |
| documento | MDR |
| teste | commissioning schedule |
| handover | closeout checklist |
Isso evita que o SOW seja aprovado e depois arquivado sem função operacional.
Critérios de liberação: o gate precisa ser explícito
Um gate pré-início ou de liberação por pacote funciona quando existe um conjunto objetivo de condições.
Exemplo para uma frente de instalação:
- projeto liberado para construção;
- material aprovado e disponível;
- área liberada;
- equipe autorizada;
- método aprovado;
- pré-requisitos de segurança atendidos;
- hold points identificados;
- documentos aplicáveis na revisão correta;
- interfaces resolvidas;
- evidência de que a atividade seguinte pode ser inspecionada/testada.
O gate pode liberar toda a obra ou apenas um pacote. Em projetos complexos, liberar por pacote permite manter ritmo sem sacrificar controle de maturidade.
A prova de conceito também precisa ser desenhada para não gerar canibalização de risco
Um erro menos óbvio ocorre quando a organização usa PoC para testar muitas coisas irrelevantes e deixa de testar o requisito que realmente determina o sucesso da implantação.
A seleção dos cenários deve partir da matriz de riscos. Pergunte:
- qual requisito possui maior impacto se falhar?
- qual característica é difícil de comprovar documentalmente?
- qual incompatibilidade teria alto custo depois da contratação?
- qual cenário diferencia solução conformante de solução apenas declaratória?
- qual teste pode ser executado de forma objetiva e proporcional?
O objetivo não é maximizar o número de testes. É maximizar a informação útil para a decisão.
Como tratar falha, ajuste e repetição na PoC
O edital deve prever como ocorrências serão tratadas. Nem toda falha possui a mesma natureza.
Pode haver:
- erro de configuração corrigível dentro do procedimento;
- falha do ambiente fornecido pelo contratante;
- requisito não atendido pela solução;
- interrupção externa;
- inconsistência do roteiro;
- resultado inconclusivo.
Sem regra prévia, cada ocorrência vira discussão sobre oportunidade de correção, isonomia e resultado.
O roteiro precisa definir se existe repetição, em quais condições e com qual registro. A decisão não deve depender de improvisação durante o teste.
Auditoria técnica quando o processo já começou sem essas barreiras
Nem sempre é possível voltar à fase preparatória. Um contrato pode já estar assinado, com execução em andamento e dúvidas sobre documentação, solução, progresso ou aderência ao projeto.
Nessa situação, não é correto inventar uma PoC retroativa para criar efeito de habilitação. A alternativa é estabelecer a situação real por meio de Auditoria Técnica de Engenharia, inspeções, análise documental, testes independentes e matriz de pendências.
A auditoria pode reconstruir:
- baseline aplicável;
- estado do projeto;
- estado de execução;
- documentos recebidos;
- não conformidades;
- testes existentes;
- lacunas de evidência;
- riscos para continuidade;
- plano de ação.
O princípio permanece: usar mecanismos válidos para a fase em que o contrato realmente se encontra.
Uma arquitetura integrada de PoC, SOW e execução
A arquitetura evidencia que PoC e SOW não são substitutos. A PoC pertence à demonstração de conformidade no momento previsto. O SOW e o Plano de Execução pertencem à organização do trabalho contratado. O Design Review verifica maturidade do detalhamento. O gate confirma prontidão. A fiscalização e o comissionamento verificam a execução e o resultado.
Como contratar apoio para estruturar essas camadas
Em objetos complexos, a elaboração dos critérios exige competências diferentes: projeto, procurement, licitações, gestão de riscos, planejamento, QA/QC e conhecimento do sistema a ser implantado.
A contratação de apoio técnico pode abranger:
- revisão de requisitos;
- matriz de conformidade da proposta;
- desenho de critérios de PoC;
- roteiro e matriz de testes;
- suporte técnico à sessão de avaliação;
- elaboração/revisão de SOW e Plano de Execução;
- Design Review;
- estruturação de WBS e baseline;
- matriz de submittals;
- PIT/ITP;
- critérios de gate e liberação;
- fiscalização e Owner’s Engineering.
A engenharia consultiva não substitui o agente público responsável pela decisão. Sua função é produzir método, evidência e recomendação técnica para que a autoridade decida com melhor informação.
Considerações finais
Prova de Conceito e Statement of Work resolvem problemas diferentes e devem permanecer distintos.
A PoC é uma ferramenta de confirmação objetiva da solução quando um requisito relevante precisa ser demonstrado e o edital previu sua utilização. O SOW é um instrumento de definição operacional do trabalho e, em conjunto com o Plano de Execução, transforma obrigações contratuais em método, recursos, entregáveis, controles e critérios verificáveis.
O maior ganho aparece quando esses instrumentos fazem parte de uma arquitetura maior: requisitos maduros no TR, qualificação adequada, PoC objetiva, contrato claro, SOW, Plano de Execução, Design Review, baseline, gate pré-início, fiscalização por evidências, testes e aceite.
A finalidade não é multiplicar documentos. É criar camadas independentes de proteção, cada uma respondendo a uma pergunta específica antes que o empreendimento avance para uma etapa em que a correção se torne mais cara, lenta ou conflituosa.
Quando o contrato já está em andamento e as barreiras não foram estruturadas desde o início, a resposta não é criar uma PoC retroativa ou uma nova habilitação.
Auditoria Técnica estabelece baseline, evidências, não conformidades, lacunas documentais e plano de ação para recuperar governança.
Referências técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] TRIBUNAL DE CONTAS DA UNIÃO. Licitações & Contratos — Amostra e prova de conceito. Disponível em: https://licitacoesecontratos.tcu.gov.br/5-4-1-2-amostra-e-prova-de-conceito/.
[3] ADVOCACIA-GERAL DA UNIÃO. Modelos da Lei nº 14.133/2021 — Pregão e Concorrência. Disponível em: https://www.gov.br/agu/pt-br/composicao/cgu/cgu/modelos/licitacoesecontratos/14133/pregao-e-concorrencia.
Perguntas frequentes
A PoC testa objetivamente se uma solução atende requisitos definidos. O Statement of Work descreve o trabalho a executar, incluindo escopo, entregáveis, responsabilidades, método, equipe, cronograma, controles e critérios de conclusão.
Sim. O art. 17, §3º, admite prova de conceito e outros exames de conformidade da proposta do licitante provisoriamente vencedor, desde que previstos no edital.
Não. SOW é uma prática de gestão de projetos e contratos. Em contratação pública, qualquer documento com essa função precisa estar ancorado no TR, edital ou contrato e não pode criar uma habilitação retroativa.
A modelagem deve observar a Lei, o edital e a jurisprudência aplicável. O TCU recomenda cautela e, em regra, direciona a prova de conceito ao licitante provisoriamente vencedor, evitando restrições desnecessárias à competição.
Objetivo, escopo e exclusões, entregáveis, WBS, responsabilidades, equipe, metodologia, cronograma, materiais e submittals, QA/QC, documentos, testes, mudanças, handover e critérios de conclusão.
Não. A PoC verifica requisitos da solução no momento previsto; Design Review verifica maturidade do detalhamento técnico; comissionamento verifica desempenho e prontidão do ativo implantado.
Materiais técnicos complementares
Soluções relacionadas
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Gestão de Contratos, Escopo e Entregáveis
- Governança Documental e Sistema de Gestão de Documentos
Serviços relacionados
- Termo de Referência para Obras e Serviços de Engenharia
- Apoio Técnico à Licitação e Análise de Propostas
- Design Review em Projetos de Engenharia
- Gestão de Projetos — Project Controls
- Auditoria Técnica de Engenharia
Conteúdos principais sobre o tema
- Pregão pode ser usado para obra?
- Habilitação e Qualificação Técnica em Licitações de Engenharia
- Design Review em Projetos de Engenharia
- Plano de Inspeção e Testes — PIT/ITP
