Entienda cómo la Prueba de Concepto, Statement of Work, Plan de Ejecución, Design Review y gates previos al inicio validan la solución y la preparación antes de la implantación.
¡Descúbrelo!
La Prueba de Concepto (PoC) y el Statement of Work (SOW) son instrumentos diferentes y complementarios. En una contratación de ingeniería, la PoC sirve para demostrar, mediante una prueba o evaluación objetiva, que una solución propuesta cumple requisitos previamente definidos. El Statement of Work, a su vez, describe cómo se ejecutará el trabajo: alcance, límites, entregables, responsabilidades, metodología, equipo, cronograma, controles, documentos, ensayos y criterios de conclusión.
La diferencia es decisiva porque una contratación puede comprobar que el proveedor posee experiencia y aun así necesitar validar aspectos específicos de la solución o de la movilización. La habilitación responde si el licitante cumple los requisitos de capacidad definidos en el pliego; la PoC puede responder si la solución ofrecida demuestra determinada conformidad; y un SOW o Plan de Ejecución puede responder cómo pretende la contratista organizar la ejecución de ese contrato concreto.
En el régimen de la Ley brasileña n.º 14.133/2021, la prueba de concepto posee fundamento expreso: el art. 17, §3.º, permite el análisis de conformidad de la propuesta del licitante provisionalmente ganador mediante muestras, examen de conformidad y prueba de concepto, entre otros ensayos, siempre que estén previstos en el pliego. El término inglés Statement of Work, por su parte, no constituye una fase autónoma de la licitación brasileña. Cuando se exige un documento con esta función en una contratación pública, su obligación, contenido, momento y consecuencia deben estar anclados en los Términos de Referencia, pliego o contrato, sin convertirse en un requisito retroactivo de habilitación.
La combinación correcta es poderosa: PoC para demostrar requisitos que necesitan ser probados; SOW o Plan de Ejecución para transformar el contrato en método, responsabilidades y secuencia verificable antes de la implantación. Cuando estos instrumentos se planifican desde la fase preparatoria, crean una barrera entre “empresa seleccionada” y “ejecución liberada” sin confundir competencia, habilitación, conformidad de la propuesta y gestión contractual.
PoC y SOW responden a preguntas diferentes
La prueba de concepto prueba una afirmación sobre la solución. El SOW organiza una afirmación sobre el trabajo.
| Instrumento | Pregunta principal | Momento típico | Resultado esperado |
| Habilitación técnica | ¿El licitante demuestra capacidad según el pliego? | licitación | habilitado/inhabilitado |
| Prueba de Concepto | ¿La solución demostrada cumple los requisitos probados? | evaluación de la propuesta, cuando esté prevista | conforme/no conforme |
| Statement of Work | ¿Cómo se ejecutará y controlará el trabajo? | contratación/movilización, cuando esté previsto | documento aprobado/ajustado |
| Plan de Ejecución | ¿Cómo se movilizarán recursos, método, cronograma y controles? | preinicio | preparación para ejecutar |
| Design Review | ¿El detalle técnico está suficientemente maduro para construcción/implantación? | pre-ejecución y por paquetes | liberado/comentado/rechazado |
Mezclar estos papeles produce problemas jurídicos y técnicos. Una PoC no debe utilizarse para escoger subjetivamente la “mejor idea” cuando el pliego definió criterios objetivos de evaluación. Un SOW no debe surgir después de la habilitación como una prueba adicional de capacidad que nadie sabía que tendría que cumplir.
Cuándo la Prueba de Concepto agrega valor real
La PoC es útil cuando una característica crítica de la solución no puede confirmarse con seguridad únicamente mediante documentación declarativa, catálogo o certificación.
Los ejemplos pueden incluir, según el objeto:
- interoperabilidad entre sistemas;
- capacidad de procesar determinado volumen;
- adherencia a un requisito funcional específico;
- compatibilidad con el entorno existente;
- desempeño mensurable en un escenario definido;
- ejecución de un workflow crítico;
- lectura, exportación o integración de datos;
- demostración de una función de seguridad o control;
- validación de interfaz con tecnología legacy.
La PoC no es recomendable simplemente porque el contratante “quiere verla funcionando”. El requisito debe ser relevante, comprobable y proporcional al esfuerzo impuesto al licitante.
La orientación del TCU sobre muestras y prueba de concepto refuerza que la exigencia debe estar justificada y rodeada de criterios objetivos. La prueba debe evaluar aquello que el pliego definió, no preferencias descubiertas durante la sesión.
Cómo especificar una PoC objetiva
Una PoC defendible comienza antes de la licitación, en el diseño de los requisitos. Cuanto más vaga sea la especificación, mayor será la probabilidad de que la prueba se vuelva subjetiva.
Una matriz de PoC puede contener:
| ID | Requisito | Procedimiento de prueba | Entrada | Resultado esperado | Evidencia | Criterio |
| POC-01 | integración con protocolo X | conectar y ejecutar escenario | entorno definido | comunicación íntegra | log + pantalla + archivo | pasa/falla |
| POC-02 | desempeño mínimo | ejecutar carga establecida | dataset estándar | valor ≥ límite | informe exportado | pasa/falla |
| POC-03 | exportación | generar archivo en formato requerido | datos de prueba | archivo válido | archivo nativo | pasa/falla |
| POC-04 | workflow | ejecutar secuencia funcional | guion de acciones | etapas concluidas | registro de ejecución | pasa/falla |
El guion también debe indicar entorno, duración, responsabilidad por infraestructura, condiciones de repetición, tolerancias, tratamiento de fallos, documentación y forma de registrar el resultado.
Cuando la evaluación depende de juicio humano, los criterios deben descomponerse en elementos observables. Expresiones como “interfaz amigable”, “buen desempeño” o “integración satisfactoria” son insuficientes sin una escala o criterio de verificación.
PoC no es una demostración comercial
Demostración comercial y prueba de concepto no son sinónimos. Una demo normalmente presenta funcionalidades escogidas por el proveedor en un entorno controlado por él. La PoC contractual prueba requisitos escogidos por el contratante, según un guion conocido y evidencias definidas.
Esta distinción evita una trampa común: que el proveedor realice una presentación convincente que no prueba las condiciones críticas del objeto.
En la PoC, el contratante debe controlar la pregunta. El proveedor demuestra la respuesta.
Transparencia y observabilidad de la prueba
El procedimiento debe ser auditable. El TCU posee precedentes que exigen criterios detallados y permiten el acompañamiento de la evaluación por los interesados, respetando las reglas del certamen.
Esto significa registrar:
- fecha y entorno;
- participantes;
- versión del producto o solución;
- requisitos probados;
- procedimiento aplicado;
- datos de entrada;
- resultado observado;
- evidencias generadas;
- divergencias y ocurrencias;
- conclusión de cada requisito;
- conclusión global.
Cuando existe un archivo nativo producido por la prueba, su conservación puede ser más útil que un informe PDF aislado. Logs, archivos de configuración, exportaciones, capturas técnicas y hashes pueden reforzar la trazabilidad cuando el objeto justifique este nivel de control.
Dónde entra el Statement of Work
Statement of Work es una expresión utilizada en gestión de proyectos, contratos y procurement para describir el trabajo a realizar. En portugués, su función puede aparecer distribuida entre alcance, especificación técnica, plan de trabajo, plan de ejecución, orden de servicio o documentos equivalentes.
Lo más importante es la función, no el idioma: transformar la obligación contractual en una descripción operacional verificable.
Un buen SOW reduce zonas grises al explicitar:
- objetivo del trabajo;
- fronteras de alcance;
- exclusiones y premisas;
- entregables;
- paquetes y secuencia;
- responsabilidades;
- interfaces con el contratante y terceros;
- equipo y roles;
- metodología;
- cronograma y hitos;
- documentos y submittals;
- criterios de calidad;
- inspecciones y ensayos;
- change control;
- criterios de conclusión y handover.
En la contratación pública, estos elementos no pueden contradecir ni reescribir el objeto después de la disputa. El SOW debe detallar la ejecución dentro de las obligaciones previstas, no renegociar silenciosamente aquello que fue licitado.
El SOW no puede convertirse en una habilitación oculta
Este es probablemente el mayor riesgo de utilizar el concepto de Statement of Work en el post-award.
Imagine un pliego que exige únicamente certificados y equipo mínimo. Después de la habilitación, el contratante solicita un SOW y decide que rechazará a la empresa si la metodología “no demuestra madurez suficiente”, sin que existan criterios previos. En la práctica, se habría creado una nueva barrera de calificación después de la disputa.
La solución es establecer desde la contratación:
- que el documento será exigido;
- su contenido mínimo;
- cuándo será entregado;
- cómo será analizado;
- qué ítems pueden generar comentarios o necesidad de revisión;
- qué condiciones impiden la Orden de Inicio;
- qué aspectos son solo de planificación y no modifican el alcance;
- cómo se resolverán las divergencias.
Así, el documento funciona como instrumento de gestión contractual, no como filtro improvisado.
Del SOW al Plan de Ejecución
En contratos de implantación, el SOW frecuentemente necesita complementarse con un Plan de Ejecución más operacional. El primero establece qué se hará y cómo está estructurado el trabajo; el segundo puede detallar la movilización real, frentes, recursos, métodos y controles.
Una estructura práctica puede contener:
Alcance y WBS
La WBS/EAP descompone el contrato en partes controlables y crea vínculo con cronograma, medición y entregables.
Organización y RACI
La matriz RACI o equivalente identifica quién ejecuta, responde, es consultado e informado para decisiones críticas.
Cronograma e hitos
El cronograma debe reflejar la lógica de ejecución, dependencias, restricciones, aprobaciones, suministros, ensayos y handover — no solo fechas de inicio y finalización.
Materiales y submittals
Los ítems críticos deben tener datasheet, requisito de equivalencia, flujo de análisis y plazo de aprobación compatibles con el cronograma.
QA/QC
El plan de calidad y el PIT/ITP deben definir inspecciones, criterios y puntos de testigo.
Gestión documental
La matriz de entregables debe establecer documentos progresivos, revisiones y relación con medición y aceptación.
Ensayos y comisionamiento
Los ensayos deben estar previstos desde el inicio, con prerrequisitos, instrumentos, evidencias y criterios.
Handover
As-Built, Data Book, manuales, garantías y capacitación no deben surgir como “pendientes finales”; tienen que estar planificados desde la movilización.
Los Términos de Referencia deben preparar el terreno
PoC, SOW, criterios de aceptación y gates solo funcionan cuando se diseñan en la fase preparatoria y aparecen claramente en los documentos de la contratación.
La revisión técnica de los Términos de Referencia permite separar requisito de habilitación, requisito de propuesta, prueba de conformidad y obligación de ejecución.
Si la organización desea utilizar PoC, SOW o un gate previo al inicio, el diseño comienza en los Términos de Referencia para Obras y Servicios de Ingeniería.
La Ley brasileña n.º 14.133/2021 incluye en el contenido del TR elementos como requisitos de la contratación, modelo de ejecución, modelo de gestión del contrato, criterios de medición y pago y forma de selección del proveedor. Esto permite construir un recorrido coherente entre requisito, evaluación y ejecución.
El TR debe distinguir:
- requisito del objeto;
- evidencia exigida en la propuesta;
- evidencia de habilitación;
- requisito probado en la PoC;
- documento exigido después de la contratación;
- condición previa a la Orden de Inicio;
- evidencia de la ejecución;
- criterio de medición;
- criterio de recepción.
Esta separación reduce la posibilidad de que el mismo requisito se exija de maneras diferentes y contradictorias a lo largo del proceso.
Design Review como tercera capa
Superar una PoC no significa que el proyecto ejecutivo esté maduro. Interfaces, constructibilidad, materiales, detalles y criterios de prueba deben verificarse antes de liberar cada paquete.
Design Review reduce el costo de corregir incompatibilidades ya incorporadas en campo.
La PoC demuestra una característica de la solución; el SOW organiza el trabajo; ninguno de los dos sustituye la revisión del proyecto detallado.
Cuando la implantación depende de proyecto ejecutivo, shop drawings o detalles producidos por la contratista, el Design Review actúa sobre interfaces, requisitos, compatibilidad, constructibilidad y madurez antes de la ejecución.
Una secuencia típica puede ser:
- requisitos definidos en el proyecto/TR;
- propuesta evaluada;
- PoC aplicada a los requisitos comprobables, cuando corresponda;
- contratación formalizada;
- SOW/Plan de Ejecución presentado;
- proyecto ejecutivo y submittals revisados;
- pendientes críticos cerrados;
- Orden de Inicio o liberación por paquete.
Esta lógica crea barreras independientes. Una solución puede superar la PoC y aun así tener un detalle de proyecto inadecuado. Un excelente proyecto puede fallar si el Plan de Ejecución no prevé recursos o secuencia coherentes. Cada instrumento verifica una dimensión diferente.
Project Controls transforma el plan en baseline
Un SOW sin baseline se convierte solo en un documento aprobado. WBS, cronograma, hitos y entregables deben alimentar un sistema de control que muestre planificado, realizado, desviación y proyección.
Project Controls transforma el plan en una referencia mensurable para la ejecución.
Aprobar un SOW sin crear una referencia de control reduce su valor. El documento debe conectarse con el cronograma y los indicadores que serán acompañados.
La Gestión de Proyectos y Project Controls puede transformar WBS, hitos, cronograma y costos en baseline. Después, los cambios y desviaciones se evalúan contra esa referencia.
El vínculo puede estructurarse así:
| Elemento del SOW | Control asociado |
| entregable | WBS + hito |
| equipo | plan de movilización |
| material crítico | procurement/submittal schedule |
| método | procedimiento aprobado |
| interfaz | action/RFI register |
| inspección | PIT/ITP |
| documento | MDR |
| prueba | commissioning schedule |
| handover | closeout checklist |
Esto evita que el SOW sea aprobado y luego archivado sin función operacional.
Criterios de liberación: el gate debe ser explícito
Un gate previo al inicio o de liberación por paquete funciona cuando existe un conjunto objetivo de condiciones.
Ejemplo para un frente de instalación:
- proyecto liberado para construcción;
- material aprobado y disponible;
- área liberada;
- equipo autorizado;
- método aprobado;
- prerrequisitos de seguridad cumplidos;
- hold points identificados;
- documentos aplicables en la revisión correcta;
- interfaces resueltas;
- evidencia de que la actividad siguiente puede inspeccionarse/probarse.
El gate puede liberar toda la obra o solo un paquete. En proyectos complejos, liberar por paquete permite mantener el ritmo sin sacrificar el control de madurez.
La prueba de concepto también debe diseñarse para no generar canibalización de riesgo
Un error menos obvio ocurre cuando la organización utiliza la PoC para probar muchas cosas irrelevantes y deja de probar el requisito que realmente determina el éxito de la implantación.
La selección de escenarios debe partir de la matriz de riesgos. Pregunte:
- ¿qué requisito tiene mayor impacto si falla?
- ¿qué característica es difícil de demostrar documentalmente?
- ¿qué incompatibilidad tendría alto costo después de la contratación?
- ¿qué escenario diferencia una solución conforme de una solución meramente declarada?
- ¿qué prueba puede ejecutarse de manera objetiva y proporcional?
El objetivo no es maximizar el número de pruebas. Es maximizar la información útil para la decisión.
Cómo tratar fallos, ajustes y repetición en la PoC
El pliego debe prever cómo se tratarán las ocurrencias. No todo fallo tiene la misma naturaleza.
Puede haber:
- error de configuración corregible dentro del procedimiento;
- fallo del entorno suministrado por el contratante;
- requisito no cumplido por la solución;
- interrupción externa;
- inconsistencia del guion;
- resultado inconcluso.
Sin una regla previa, cada ocurrencia se convierte en una discusión sobre oportunidad de corrección, igualdad de trato y resultado.
El guion debe definir si existe repetición, en qué condiciones y con qué registro. La decisión no debe depender de improvisación durante la prueba.
Auditoría técnica cuando el proceso ya comenzó sin estas barreras
No siempre es posible volver a la fase preparatoria. Un contrato puede estar ya firmado, con ejecución en marcha y dudas sobre documentación, solución, progreso o adherencia al proyecto.
En esta situación, no es correcto inventar una PoC retroactiva para crear un efecto de habilitación. La alternativa es establecer la situación real mediante una Auditoría Técnica de Ingeniería, inspecciones, análisis documental, pruebas independientes y una matriz de pendientes.
La auditoría puede reconstruir:
- baseline aplicable;
- estado del proyecto;
- estado de ejecución;
- documentos recibidos;
- no conformidades;
- pruebas existentes;
- brechas de evidencia;
- riesgos para la continuidad;
- plan de acción.
El principio permanece: utilizar mecanismos válidos para la fase en que el contrato realmente se encuentra.
Una arquitectura integrada de PoC, SOW y ejecución
La arquitectura evidencia que PoC y SOW no son sustitutos. La PoC pertenece a la demostración de conformidad en el momento previsto. El SOW y el Plan de Ejecución pertenecen a la organización del trabajo contratado. El Design Review verifica la madurez del detalle. El gate confirma la preparación. La fiscalización y el comisionamiento verifican la ejecución y el resultado.
Cómo contratar apoyo para estructurar estas capas
En objetos complejos, la elaboración de criterios exige competencias diferentes: proyecto, procurement, licitaciones, gestión de riesgos, planificación, QA/QC y conocimiento del sistema que se implantará.
La contratación de apoyo técnico puede abarcar:
- revisión de requisitos;
- matriz de conformidad de la propuesta;
- diseño de criterios de PoC;
- guion y matriz de pruebas;
- soporte técnico a la sesión de evaluación;
- elaboración/revisión de SOW y Plan de Ejecución;
- Design Review;
- estructuración de WBS y baseline;
- matriz de submittals;
- PIT/ITP;
- criterios de gate y liberación;
- fiscalización y Owner’s Engineering.
La ingeniería consultiva no sustituye al agente público responsable de la decisión. Su función es producir método, evidencia y recomendación técnica para que la autoridad decida con mejor información.
Consideraciones finales
Prueba de Concepto y Statement of Work resuelven problemas diferentes y deben mantenerse distintos.
La PoC es una herramienta de confirmación objetiva de la solución cuando un requisito relevante necesita demostrarse y el pliego previó su utilización. El SOW es un instrumento de definición operacional del trabajo y, en conjunto con el Plan de Ejecución, transforma obligaciones contractuales en método, recursos, entregables, controles y criterios verificables.
La mayor ganancia aparece cuando estos instrumentos forman parte de una arquitectura mayor: requisitos maduros en el TR, calificación adecuada, PoC objetiva, contrato claro, SOW, Plan de Ejecución, Design Review, baseline, gate previo al inicio, fiscalización basada en evidencias, pruebas y aceptación.
La finalidad no es multiplicar documentos. Es crear capas independientes de protección, cada una respondiendo a una pregunta específica antes de que el proyecto avance hacia una etapa en la que la corrección resulte más costosa, lenta o conflictiva.
Cuando el contrato ya está en marcha y las barreras no fueron estructuradas desde el inicio, la respuesta no es crear una PoC retroactiva ni una nueva habilitación.
La Auditoría Técnica establece baseline, evidencias, no conformidades, brechas documentales y plan de acción para recuperar gobernanza.
Referencias técnicas
[1] BRASIL. Ley n.º 14.133, de 1 de abril de 2021 — Ley de Licitaciones y Contratos Administrativos. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] TRIBUNAL DE CUENTAS DE LA UNIÓN DE BRASIL. Licitaciones & Contratos — Muestra y prueba de concepto. Disponible en: https://licitacoesecontratos.tcu.gov.br/5-4-1-2-amostra-e-prova-de-conceito/.
[3] ABOGACÍA GENERAL DE LA UNIÓN DE BRASIL. Modelos de la Ley n.º 14.133/2021 — Pregão y Licitación Competitiva. Disponible en: https://www.gov.br/agu/pt-br/composicao/cgu/cgu/modelos/licitacoesecontratos/14133/pregao-e-concorrencia.
Preguntas frecuentes
La PoC prueba objetivamente si una solución cumple requisitos definidos. El Statement of Work describe el trabajo a ejecutar, incluyendo alcance, entregables, responsabilidades, método, equipo, cronograma, controles y criterios de conclusión.
Sí. El art. 17, §3.º, admite prueba de concepto y otros exámenes de conformidad de la propuesta del licitante provisionalmente ganador, siempre que estén previstos en el pliego.
No. SOW es una práctica de gestión de proyectos y contratos. En contratación pública, cualquier documento con esta función debe estar anclado en el TR, pliego o contrato y no puede crear una habilitación retroactiva.
El diseño debe observar la Ley, el pliego y la jurisprudencia aplicable. El TCU recomienda cautela y, por regla general, dirige la prueba de concepto al licitante provisionalmente ganador, evitando restricciones innecesarias a la competencia.
Objetivo, alcance y exclusiones, entregables, WBS, responsabilidades, equipo, metodología, cronograma, materiales y submittals, QA/QC, documentos, pruebas, cambios, handover y criterios de conclusión.
No. La PoC verifica requisitos de la solución en el momento previsto; el Design Review verifica la madurez del detalle técnico; el comisionamiento verifica desempeño y preparación del activo implantado.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Contratos, Alcance y Entregables
- Gobernanza Documental y Sistema de Gestión de Documentos
Servicios relacionados
- Términos de Referencia para Obras y Servicios de Ingeniería
- Apoyo Técnico a la Licitación y Análisis de Propuestas
- Design Review en Proyectos de Ingeniería
- Gestión de Proyectos — Project Controls
- Auditoría Técnica de Ingeniería
Contenidos principales sobre el tema
- ¿Puede utilizarse pregão para una obra?
- Habilitación y Calificación Técnica en Licitaciones de Ingeniería
- Design Review en Proyectos de Ingeniería
- Plan de Inspección y Ensayos — PIT/ITP
