La mayoría de los fracasos en proyectos tecnológicos que se atribuyen al proveedor en realidad comenzaron en el Statement of Work (SOW), específicamente en requisitos redactados con la vaguedad suficiente para que ambas partes pudieran interpretarlos honestamente de forma distinta. Para cuando esa brecha sale a la luz, ya se convirtió en una orden de cambio o en una disputa, en lugar de una aclaración de cinco minutos durante la definición del alcance.
Por qué los requisitos vagos parecen más seguros, y no lo son
Un requisito específico y medible puede demostrarse incorrecto antes de firmar, lo cual parece más riesgoso que uno vago que no puede refutarse. Pero un requisito vago no elimina ese riesgo, solo lo posterga hasta después del punto en que cambiar de rumbo todavía resulta económico. «Rendimiento de red confiable» no cuesta nada escribirlo, pero cuesta todo litigarlo después; «99.9% de disponibilidad medida mensualmente, excluyendo ventanas de mantenimiento programado de menos de cuatro horas» cuesta apenas unos minutos de reflexión y cierra la brecha antes de que se abra.
Qué debe incluir realmente un SOW tecnológico
Más allá del alcance y el precio, un SOW tecnológico real necesita: criterios de aceptación basados en desempeño y medibles (no «funciona bien», sino un número específico y un método de medición específico), un proceso designado para resolver preguntas de alcance que surjan a mitad del proyecto, los supuestos explícitos sobre los que se basa el precio (para que un supuesto modificado se traduzca visiblemente en una orden de cambio y no en una disputa), y un proceso definido de aceptación y firma de conformidad que indique quién tiene realmente la autoridad para aceptar el entregable.
El lenguaje neutral respecto al proveedor importa más de lo que parece
Los requisitos redactados en torno a la terminología de un producto específico de un proveedor reducen silenciosamente el campo competitivo y dificultan exigir cuentas a cualquiera frente a un estándar independiente. Redactar los requisitos en función del resultado que se necesita —cobertura, capacidad, latencia, comportamiento de integración— en lugar de la lista de características de un producto específico mantiene el campo abierto y hace que los criterios de aceptación tengan sentido sin importar quién gane la licitación.
Criterios de aceptación para un proyecto de diseño o validación de Wi-Fi, en particular
Aquí es donde el lenguaje vago causa más daño en el propio campo de TekFidelity: «cobertura adecuada» no es un criterio de aceptación. Uno real especifica los objetivos de intensidad de señal y capacidad por área, los supuestos de densidad de clientes en los que se basan, y la metodología de validación (un diseño predictivo, un sondeo posterior a la instalación, o ambos) que se utilizará realmente para confirmarlos antes del pago final.
Por qué esto se conecta con el liderazgo de programas, no solo con las adquisiciones
La ambigüedad de un SOW no se queda como un problema de adquisiciones: se convierte en el primer riesgo de ejecución del proyecto, y en el más persistente, reapareciendo cada vez que hay que tomar una decisión que el documento no anticipó. Redactarlo correctamente desde el principio resulta más económico que todo el esfuerzo posterior de gestión de programas dedicado a sortear lo que quedó sin definir.
La conclusión práctica
Antes de que un SOW tecnológico salga a licitación, debe superar una prueba: que dos proveedores razonables puedan leer cada requisito y coincidir en cómo se ve «terminado». Si no es así, esa es la corrección que hay que hacer antes de definir el alcance, no después de adjudicar el contrato. Las prácticas de Estrategia Tecnológica y Modernización y de Liderazgo de Programas y Proyectos de TekFidelity abordan esta disciplina desde un ángulo distinto del mismo problema.