Una empresa de servicios profesionales nos pidió ayuda con un proyecto de modernización de su plataforma interna. Habían pedido presupuesto a tres agencias y los números no se parecían en nada: 18.000 €, 45.000 € y 92.000 €. La diferencia entre la propuesta más barata y la más cara era cinco veces. Las tres agencias eran serias y con clientes referenciables. El problema no estaba en ellas.
Estaba en el documento que les habían pasado. Tres páginas con bullets generales, capturas del CRM actual y la frase "queremos modernizarlo y que se conecte con la facturación". Cada agencia interpretó eso como quiso. La de 18.000 había asumido que los datos se migrarían manualmente y que no había integración con SAP. La de 92.000 había incluido una migración asistida con catálogo histórico de cinco años, formación al equipo y dos meses de soporte post-puesta. Estaban cotizando proyectos diferentes con el mismo nombre.
Por qué pasa esto siempre
Las agencias no inventan precios al azar. Calculan horas con cierta estimación de alcance y aplican un margen razonable. Cuando el documento de partida es ambiguo, cada una rellena los huecos según su experiencia previa, su tolerancia al riesgo y su idea de qué necesita el cliente. Una agencia que ha tenido proyectos donde el cliente "se olvidó de mencionar" tres integraciones críticas las añade por defecto al presupuesto. Otra que confía más en aclarar dudas en las primeras reuniones cotiza solo lo que está escrito y deja el resto para "fuera de alcance".
Ninguna está mintiendo. Están cubriendo el riesgo de manera distinta. Y el cliente, al recibir las propuestas, no tiene forma de comparar. Los conceptos no coinciden, las fases no coinciden, los entregables no coinciden. Pedir aclaraciones requiere otro mes de reuniones y al final acaba contratando a la que cae mejor o a la más barata, asumiendo riesgos que descubrirá durante el proyecto.
Qué hace que un pliego sea cotizable sin huecos
Un pliego técnico bien escrito reduce a casi cero las decisiones que tiene que tomar la agencia para presupuestar. No quiere decir que ya esté todo definido al detalle (eso es la fase de diseño técnico-funcional, otra cosa). Quiere decir que las preguntas básicas tienen respuesta cerrada antes de pedir oferta.
La diferencia entre un pliego de tres páginas y uno de quince no son cinco veces más palabras. Es que en el largo nadie tiene que asumir nada. Cuando la agencia lee "el sistema debe importar el catálogo desde el ERP", sabe inmediatamente: qué ERP, qué versión, qué método de exportación está disponible (API, archivo plano, base de datos), con qué frecuencia, qué campos, qué pasa con los productos descatalogados, qué hacer si llega un dato corrupto. Si todo eso está escrito, dos agencias distintas cotizarán dentro de un margen razonable. Si no está escrito, cada una se inventará una respuesta razonable y los presupuestos divergirán.
Esa es la regla: no se trata de tener todo perfecto, se trata de que dos personas leyendo el mismo párrafo entiendan lo mismo.
Cómo se nota cuando el pliego está flojo
Hay tres síntomas que aparecen siempre. El primero es que las agencias preguntan mucho durante la fase de cotización. Las preguntas serias son buena señal (no quieren cotizar a ciegas), pero cuando son veinte y básicas (¿en qué tecnología está el actual?, ¿cuántos usuarios?, ¿queréis app móvil?) significa que falta documentación elemental.
El segundo síntoma son los presupuestos con términos como "fase de descubrimiento", "estimación a refinar tras kick-off" o "rangos sujetos a definición de alcance". Eso significa que la agencia no tiene suficiente para comprometerse y se reserva el derecho a recotizar. Es un presupuesto orientativo disfrazado, no un compromiso.
El tercero es la propia variabilidad entre propuestas. Si el rango entre la más barata y la más cara supera el factor 2, no estás comparando ofertas: estás comparando interpretaciones. Lo correcto es hacer una segunda ronda con un pliego mejorado antes de decidir.
Lo que debería estar resuelto antes de pedir oferta
No hace falta ser una empresa con departamento de IT para escribir un buen pliego. Hace falta haber pensado las cosas a fondo y haberlas puesto por escrito. Estos son los bloques mínimos que deberían estar cerrados:
Contexto y alcance. Qué problema concreto se quiere resolver, qué procesos del negocio están implicados, qué áreas están dentro y cuáles fuera. Esto no es opcional ni resumido: la agencia necesita entender el negocio para cotizar el software.
Sistemas y datos actuales. Qué tecnología tienes hoy, en qué versiones, qué datos hay (volumen, calidad, dónde viven), qué se debe migrar y qué se puede dejar atrás. Si no sabes esto, lo primero antes del pliego es una auditoría interna.
Integraciones esperadas. Listado de todos los sistemas con los que la solución va a hablar, en qué dirección, con qué frecuencia y qué pasa si la integración falla. Aquí aparecen el 80% de los sobrecostes en proyectos mal pliegados.
Usuarios y carga. Cuántas personas usan el sistema, en qué picos, con qué dispositivos, en qué horario. La diferencia entre "20 usuarios oficina" y "200 usuarios incluido equipo de campo en móvil" es enorme y cambia la arquitectura.
Requisitos no funcionales. Tiempos de respuesta esperados, ventanas de mantenimiento aceptables, exigencias de seguridad, cumplimiento legal aplicable, política de copias y recuperación. Lo que no se menciona, no se cotiza.
Criterios de éxito y entregables. Qué considera la empresa que es "terminado". Cuántos entornos (desarrollo, pruebas, producción), qué documentación se entrega, qué formación, qué soporte post-puesta. Si el criterio es ambiguo, la agencia tendrá excusas para cerrar el proyecto antes de que esté realmente listo.
Restricciones. Plazos no negociables, presupuesto máximo si lo hay, tecnologías obligatorias o vetadas, proveedores existentes con los que hay que colaborar. Sirve para que la agencia no proponga algo inviable.
El coste real de no hacerlo
Pedir oferta con un pliego flojo se siente más rápido. Te ahorras dos o tres semanas de trabajo de definición. El problema es que ese ahorro se paga después, casi siempre multiplicado.
En el caso del proyecto que abrió este artículo, decidieron parar el proceso, dedicar un mes a redactar bien el pliego (con apoyo externo) y volver a pedir ofertas. Las nuevas propuestas entraron en un rango de 38.000 a 52.000 €. La dispersión bajó del factor 5 al factor 1,4. El proyecto se firmó con una de las agencias que la primera vez había cotizado 92.000 € (la más cara) y esta vez cotizó 41.000. La diferencia no era margen: era ambigüedad.
Un pliego bien hecho no es burocracia. Es la herramienta que te permite contratar con criterio, comparar ofertas comparables y proteger el proyecto desde el día uno. Cuando un proyecto se desvía en presupuesto, casi siempre se puede rastrear hasta una pregunta que nunca se respondió por escrito.