Por qué el 70% de los proyectos de software con proveedores externos fallan

Según el Standish Group Chaos Report, solo el 30% de los proyectos de software se entregan en plazo, presupuesto y con las funcionalidades prometidas. La causa más frecuente no es la tecnología: es elegir mal al proveedor.

Esta guía te da las herramientas para evaluar proveedores sin necesidad de conocimientos técnicos profundos.

Parte 1: Evaluar las capacidades técnicas

1.1 Sobre el equipo real

Las preguntas más importantes son las que más incomodan al proveedor.

Pregunta clave: ¿Quiénes son exactamente las personas que van a trabajar en mi proyecto?

Pide nombres, experiencia relevante y, si es posible, LinkedIn. Los buenos proveedores no tienen problema en presentar a su equipo. Los malos hablan de "nuestro equipo de 30 ingenieros" sin concretar quién hace qué.

[ ] ¿El equipo que presenta la propuesta es el equipo que va a ejecutar?
[ ] ¿Cuántos proyectos simultáneos lleva cada persona del equipo?
[ ] ¿El proveedor subcontrata parte del trabajo? ¿A quién? ¿Dónde?
[ ] ¿Qué pasa si alguien del equipo deja la empresa? ¿Hay plan de continuidad?

1.2 Sobre la experiencia real

[ ] ¿Pueden mostrar proyectos similares al tuyo en complejidad técnica y sector?
[ ] ¿Puedes hablar directamente con un cliente anterior? (Si se niegan, es una señal)
[ ] ¿Tienen experiencia con la normativa aplicable a tu sector (RGPD, HIPAA, MDR, PCI-DSS)?
[ ] ¿El stack tecnológico que proponen es el que usan habitualmente o lo están aprendiendo en tu proyecto?

1.3 Sobre el proceso de desarrollo

[ ] ¿Cómo es su ciclo de desarrollo? ¿Sprints? ¿Waterfall? ¿Cuándo verás algo funcional por primera vez?
[ ] ¿Cómo gestionan los bugs en producción? ¿Qué SLA tienen para incidencias críticas?
[ ] ¿Hacen code reviews? ¿Tienen tests automatizados?
[ ] ¿Cómo documentan el código y la arquitectura?

Parte 2: Evaluar la solidez del negocio

Un proveedor técnicamente competente pero con problemas financieros o de gestión puede dejarte a medias.

[ ] ¿Cuánto tiempo llevan en el mercado? ¿Han sobrevivido a cambios de ciclo económico?
[ ] ¿Cuántas personas tiene el equipo? ¿Cómo está distribuido (senior / junior)?
[ ] ¿Depende el proveedor de un solo cliente para más del 30% de sus ingresos? (Riesgo de que te den prioridad baja si ese cliente les ocupa)
[ ] ¿Tienen productos propios o solo hacen proyectos para clientes? (Los que tienen producto propio suelen tener más criterio técnico)
[ ] ¿Tienen financiación externa (inversores)? ¿Es estable o pueden cambiar de estrategia?

Parte 3: Evaluar la propuesta concreta

3.1 El presupuesto

[ ] ¿El presupuesto incluye un desglose de horas por perfil y funcionalidad?
[ ] ¿Qué está explícitamente excluido del presupuesto? (Hosting, licencias de terceros, formación, soporte post-lanzamiento)
[ ] ¿Cómo se gestionan los cambios de alcance? ¿Hay un proceso formal o se decide "sobre la marcha"?
[ ] ¿Qué garantía ofrecen post-lanzamiento? ¿Cuánto tiempo y qué cubre?

3.2 La propiedad intelectual

Este punto es crítico y muchos directivos no lo revisan hasta que hay un conflicto.

[ ] ¿Quién es propietario del código una vez entregado?
[ ] ¿El proveedor puede reutilizar partes del código en otros proyectos?
[ ] ¿Las librerías de terceros usadas tienen licencias compatibles con el uso comercial?
[ ] Si el proyecto usa modelos de IA, ¿quién es propietario del modelo entrenado?

3.3 La dependencia tecnológica (vendor lock-in)

[ ] ¿El sistema puede ser mantenido por otro equipo si cambias de proveedor?
[ ] ¿El proveedor usa tecnologías estándar del mercado o herramientas propietarias que solo ellos conocen?
[ ] ¿Los datos están en formato exportable? ¿Puedes llevártelos si cambias de proveedor?
[ ] ¿El código fuente te será entregado al final? ¿Y durante el desarrollo (acceso al repositorio)?

Parte 4: Las señales de alerta

🚩 Señales de alerta tempranas

"Podemos hacer cualquier cosa" — Los buenos proveedores especializados dicen "hacemos X muy bien y Y no es nuestro fuerte". Los que dicen poder hacer todo suelen no destacar en nada.

No preguntan nada en la primera reunión — Un proveedor serio necesita entenderte antes de presupuestar. Si van directo a enseñar sus casos de éxito sin preguntarte casi nada, es una mala señal.

El precio es muy inferior al mercado — Alguien asume ese riesgo. Normalmente el cliente, en forma de calidad, retrasos o costes ocultos posteriores.

No pueden mostrar código o demos de proyectos anteriores — Entiende que hay confidencialidad, pero un proveedor bueno puede mostrar algo: una arquitectura anonimizada, un proyecto open source, un prototipo.

Cambios de interlocutor frecuentes — Si en el proceso de venta ya cambian dos veces la persona de contacto, en el proyecto pasará lo mismo.

🟡 Señales que requieren exploración adicional

Equipo muy junior — No es malo per se, pero necesitas entender cómo está supervisado y qué experiencia tiene el equipo de liderazgo técnico.

Solo trabajo remoto con equipo distribuido globalmente — Puede funcionar muy bien, pero requiere más estructura de comunicación. Pregunta cómo gestionan la coordinación y los husos horarios.

Portfolio muy genérico — Si todos sus casos de éxito son "desarrollamos una app" sin contexto de negocio, desafíos técnicos o resultados medibles, probablemente no tienen cultura de medición de impacto.

La reunión de evaluación técnica

Si el proyecto es significativo (más de 50.000 €), considera organizar una reunión técnica donde tu CTO o un consultor externo pueda hacer preguntas técnicas directas al equipo del proveedor.

Preguntas técnicas útiles para esa reunión:

"¿Cómo gestionáis la migración de base de datos en producción sin downtime?"
"¿Cómo haríais el onboarding de un desarrollador nuevo en este proyecto?"
"¿Qué haríais si detectáis una vulnerabilidad de seguridad en producción a las 3AM?"
"¿Cómo medís el rendimiento del sistema en producción?"

Las respuestas revelan mucho sobre la madurez del equipo. Un equipo senior responde con concreción. Un equipo junior responde con generalidades.

Plantilla de evaluación comparativa

Usa esta plantilla para comparar proveedores objetivamente:

| Criterio | Peso | Proveedor A | Proveedor B | Proveedor C | |----------|------|-------------|-------------|-------------| | Experiencia en sector | 20% | /10 | /10 | /10 | | Solidez del equipo | 20% | /10 | /10 | /10 | | Proceso y metodología | 15% | /10 | /10 | /10 | | Transparencia y comunicación | 15% | /10 | /10 | /10 | | Precio y condiciones | 15% | /10 | /10 | /10 | | Referencias de clientes | 15% | /10 | /10 | /10 | | Total ponderado | 100% | /10 | /10 | /10 |

No elijas exclusivamente por precio. El proveedor más barato raramente es el más económico a largo plazo.

Cómo hacer due diligence de un proveedor tecnológico: guía para directivos