Cómo comparar presupuestos de proyectos de datos

Recibir tres presupuestos para el mismo proyecto de datos y que difieran un 300% entre sí es más frecuente de lo que parece. Un proveedor propone 15.000 €, otro 45.000 € y el tercero 8.000 €. Los tres dicen que van a resolver el mismo problema. ¿Cuál es el correcto?

La respuesta corta: probablemente ninguno sea directamente comparable con los otros dos. El de 15.000 € no incluye infraestructura. El de 45.000 € incluye un año de mantenimiento. El de 8.000 € solo cubre la fase de análisis. Comparar precios sin entender el alcance de cada propuesta es uno de los errores más frecuentes en la compra de servicios de datos.

¿Por qué es tan difícil comparar presupuestos de proyectos de datos?

Los proyectos de datos tienen un problema estructural para el comprador: la entidad del trabajo no es visible de forma intuitiva. Si contratas la instalación de una caldera, puedes verificar que está instalada. Si contratas un modelo predictivo, ¿cómo verificas que está bien hecho? ¿Que los resultados son fiables? ¿Que el código es mantenible?

Esa asimetría de información hace que los proveedores menos rigurosos puedan vender proyectos vagos a precios altos, y que los más rigurosos a veces pierdan la venta porque su propuesta es más detallada (y parece más cara aunque sea más honesta). Conocer qué debe incluir una buena propuesta es la herramienta más útil para el comprador.

Pregunta 1: ¿El alcance es específico?

Una propuesta de proyecto de datos rigurosa describe con precisión qué se va a construir: qué fuentes de datos se integran, qué transformaciones se aplican, qué entregables concretos produce (el dashboard en Power BI, el modelo de forecasting, el pipeline de datos automatizado) y cuáles son los criterios de aceptación.

Si una propuesta habla de 'análisis de situación', 'diseño de solución' y 'entrega de informe' sin especificar qué incluye cada una de esas fases, no puedes comparar su precio con una propuesta que detalla exactamente qué modelos se construirán, sobre qué datos y con qué métricas de validación.

Cómo evaluarlo

Pide al proveedor que describa en una frase qué habrá cuando el proyecto termine que no había antes. Si la respuesta es precisa ('un pipeline de datos que transforma y carga diariamente los datos de ventas de tu ERP en Power BI, con un modelo semántico de 15 métricas y 3 informes operativos'), el alcance está claro. Si la respuesta es abstracta, no lo está.

Pregunta 2: ¿Están definidos los entregables y los criterios de aceptación?

Los entregables son los artefactos concretos que el proveedor entrega al cliente: el código fuente, el modelo de datos, el dashboard, la documentación técnica, la formación al equipo. Los criterios de aceptación son las condiciones que deben cumplirse para dar por bueno cada entregable.

Sin criterios de aceptación definidos en la propuesta, cualquier discrepancia sobre si el trabajo está completo se convierte en un conflicto. ¿El dashboard está 'terminado' cuando tiene todos los gráficos solicitados? ¿O también tiene que cargar en menos de 5 segundos y estar documentado? Si eso no se define antes, se negocia cuando ya hay tensión.

Pregunta 3: ¿Qué está incluido en el precio y qué es adicional?

Esta es la pregunta que más diferencias crea entre propuestas aparentemente similares. Algunos presupuestos incluyen en el precio fijo licencias de herramientas, infraestructura cloud, formación al equipo interno y mantenimiento del primer mes. Otros solo incluyen el trabajo de consultoría.

• Infraestructura cloud: ¿el coste de Azure, GCP o AWS está incluido o es coste adicional del cliente?
• Licencias de herramientas: ¿las licencias de Power BI, n8n cloud, Snowflake u otras están en el precio?
• Formación: ¿hay sesiones de formación al equipo interno incluidas?
• Documentación técnica: ¿se entrega documentación del sistema o solo el código?
• Mantenimiento post-entrega: ¿hay un periodo de garantía o soporte incluido tras la entrega?

Pregunta 4: ¿Cómo son los hitos de pago?

El esquema de pago es un indicador de cómo trabaja el proveedor. Un esquema razonable liga los pagos a los entregables verificables: un porcentaje al inicio, pagos intermedios en hitos concretos y el saldo al completar el proyecto con criterios de aceptación cumplidos.

El pago del 100% por adelantado sin hitos intermedios no debería ser aceptable para ningún proyecto de más de 2-3 semanas. El pago en un único pago final tampoco es razonable para el proveedor en proyectos largos. Lo normal es un esquema de 30-40% inicio, el resto en 2-3 hitos verificables.

Pregunta 5: ¿Qué pasa si el alcance cambia?

El cambio de alcance en proyectos de datos es inevitable. Aparecen nuevas fuentes de datos no previstas, los requisitos del dashboard evolucionan durante el desarrollo o el modelo predictivo requiere más iteraciones de las esperadas. Cómo gestiona el proveedor esos cambios determina en gran medida cómo será la relación.

Una propuesta rigurosa describe el proceso de control de cambios: qué mecanismo existe para solicitar cambios de alcance, cómo se estima el impacto en tiempo y coste y quién aprueba los cambios. Si la propuesta no menciona nada sobre esto, pregúntalo directamente antes de firmar.

Cómo comparar propuestas que usan metodologías distintas

El problema más frecuente al comparar presupuestos de proyectos de datos es que cada proveedor usa una metodología diferente: uno trabaja por sprints, otro por fases de proyecto clásico, otro ofrece una bolsa de horas. Las tres pueden ser perfectamente válidas, pero son difíciles de comparar directamente.

La clave es reducir todo al mismo denominador: qué problema resuelve, qué entregables produce, en qué plazo y con qué garantías. Si puedes responder esas cuatro preguntas para cada propuesta con el mismo nivel de detalle, ya tienes una base de comparación común. Si no puedes porque alguna propuesta no es suficientemente concreta, esa imprecisión es ya información relevante sobre el proveedor.

Señales de presupuesto inflado o incompleto

Hay patrones en los presupuestos que indican problemas potenciales. Aquí van los más frecuentes.

Señales de presupuesto posiblemente inflado

• Incluye fases de 'consultoría estratégica' o 'análisis de situación' de varias semanas antes de proponer nada concreto.
• Propone un equipo de 4-5 personas para un proyecto que un equipo de 2 podría completar bien.
• El precio por hora implícito supera significativamente el mercado sin justificación en el perfil del equipo.
• Los entregables son documentos y presentaciones, no sistemas o código en producción.

Señales de presupuesto posiblemente incompleto

• El precio no incluye infraestructura cloud ni licencias, que pueden ser un coste relevante a largo plazo.
• No hay ninguna mención al mantenimiento post-entrega.
• El plazo propuesto es significativamente más corto que el mercado sin explicación.
• No se mencionan pruebas, validación con datos reales ni formación al equipo.

Preguntas frecuentes

¿Cómo sé si un presupuesto de proyecto de datos es caro o barato?

La referencia es la relación entre precio y alcance, no el precio absoluto. Un presupuesto de 30.000 € puede ser barato para una plataforma de datos completa y caro para un dashboard. Asegúrate de entender qué incluye cada propuesta antes de comparar precios.

¿Qué pasa si el proveedor pide el 100% por adelantado?

Es una señal de alerta. Los proyectos bien gestionados tienen hitos intermedios y el pago debería estar ligado a entregables verificables. Un esquema razonable es 30-40% al inicio, el resto en hitos concretos.

¿Cómo comparo dos propuestas con metodologías distintas?

Reduce ambas al mismo denominador: qué problema resuelve, qué entregables produce, en qué plazo y con qué garantías. Si no puedes hacer esa comparación porque una propuesta es imprecisa, esa imprecisión ya es información sobre ese proveedor.