Alrededordel 70% de los proyectos de desarrollo de herramientas internas enempresas medianas y grandes fracasa. No llegan a implementarsecorrectamente, apenas se utilizan o terminan abandonándose pocosmeses después de su lanzamiento.[1]
Cuandose analizan los costes reales, el impacto es considerable. El costemedio estimado de un proyecto fallido — sumando el desarrolloinicial, el tiempo invertido por el equipo interno, el coste deoportunidad y la pérdida de productividad durante el proceso— podría superar los 2 millones de euros en proyectos de complejidad media en empresas europeas de tamaño mediano-grande.
Llevamos años acompañando a empresas en el diseño y construcción de herramientas y productos digitales que realmente funcionan. En ese tiempo hemos observado que los mismos errores se repiten con sorprendente regularidad.
En este artículo analizamos las siete causas más frecuentes por las que estos proyectos fracasan y, sobre todo, cómo evitarlas.
Contexto
El dato del 70% de fracaso aparece de forma consistente en cuatro estudios independientes: el Standish Group CHAOS Report 2020[2],el McKinsey Global Survey (2018)[3],el informe de BCG (2020)[4]y el KPMG Programme Management Survey (2002). Aunque sus marcos metodológicos difieren, los resultados convergen.
El coste medio estimado incluye las siguientes partidas, elaboradas a partir de nuestra experiencia en proyectos de digitalización interna en empresas de entre 100 y 5.000 empleados en España y Europa, y coherentes con los rangos documentados por Mc Manus & Wood-Harper(2007)[6]y el PMI Pulse of the Profession (2018):
· Desarrollo tecnológico: en torno a una horquilla de 400 K€ –800 K€.
· Tiempo del equipo interno: 300 K€ – 600 K€.
· Productividad perdida durante la transición: 500 K€ – 1,2 M€.
Por qué fracasa una gran parte de las herramientas internas
7 patrones que aparecen de forma recurrente en proyectos de digitalización interna
En empresas medianas y grandes, es habitual que las herramientas internas empiecen a construirse con una intención clara: mejorar procesos, reducir errores o aumentar la eficiencia de los equipos.
Sin embargo, en la práctica una parte significativa de estos proyectos no llega a consolidarse. Algunas herramientas nunca terminan de implementarse; otras se lanzan pero tienen niveles de uso muy bajos; y otras se abandonan silenciosamente pocos meses después.
Cuando se analizan proyectos de digitalización interna en diferentes organizaciones, aparecen patrones relativamente consistentes en las razones por las que algunos proyectos prosperan y otros no.
A continuación se describen siete factores que aparecen con frecuencia en proyectos que terminan perdiendo tracción.
1. El problema se define sin observar el trabajo real
En muchos proyectos, la definición inicial de la herramienta se realiza desde niveles directivos o técnicos sin un análisis detallado del trabajo cotidiano de los equipos que la utilizarán.
Cuando esto ocurre, es normal que la herramienta responda a cómo se cree que funciona el proceso, pero no necesariamente a cómo funciona en la práctica. El resultado puede ser una solución técnicamente correcta que, sin embargo, encaja mal en el flujo de trabajo real. En muchos casos, los usuarios suelen probar la herramienta durante un tiempo limitado y luego volver gradualmente a los sistemas que ya dominan.
Los proyectos que muestran mayores niveles de adopción suelen empezar con una fase breve de investigación de usuario, centrada en observar procesos reales antes de definir la solución.
2. La primera versión intenta resolver demasiado
Otro patrón frecuente aparece en la definición del alcance inicial.
Con frecuencia, el proyecto intenta cubrir desde el primer momento todos los casos de uso imaginables. El resultado puede ser una primera versión muy compleja, con ciclos de desarrollo largos y difícil de adoptar para los usuarios.
Las herramientas internas que se consolidan con mayor facilidad suelen empezar con un alcance más acotado, centrado en resolver un problema concreto de forma clara.
La complejidad suele incorporarse después, a medida que el sistema empieza a utilizarse y aparecen nuevas necesidades reales.
3. Falta una figura interna responsable del proyecto
La existencia de una figura interna como responsable del proyecto suele ser un factor importante en la evolución de estos proyectos.
Cuando no hay una persona del área de negocio responsable de impulsar la iniciativa, las decisiones pueden dilatarse y la coordinación entre equipos se vuelve más difícil. En muchos casos, esta figura no pertenece al área técnica sino al área que utilizará la herramienta y tiene autoridad suficiente para tomar decisiones operativas.
4. Las decisiones tecnológicas no se alinean con el caso de uso
Las elecciones tecnológicas también pueden influir en la sostenibilidad del proyecto.
En algunos casos, la tecnología se elige por familiaridad del equipo, por coste inicial o por tendencias del momento, en lugar de responder directamente al problema que se quiere resolver.
En proyectos orientados a construir sistemas que conecten y coordinen herramientas internas, suele resultar más efectivo priorizar tecnologías que permitan iteraciones rápidas, mantenimiento sencillo e integración con los sistemas existentes, incluso si no son las más avanzadas desde un punto de vista técnico.
5. No existe una línea base para medir impacto
Un problema habitual aparece cuando el proyecto no documenta el punto de partida antes de comenzar.
Sin métricas iniciales - tiempos de proceso, tasas de error o volumen de trabajo - resulta difícil evaluar el impacto real de la herramienta una vez implementada.
Los proyectos que logran mantener apoyo ejecutivo suelen contar con métricas de negocio claras, que permiten demostrar mejoras en eficiencia o reducción de errores.
6. La adopción del cambio se subestima
En iniciativas de desarrollo de soluciones internas, el desarrollo técnico suele representar solo una parte del trabajo total.
Otra parte importante consiste en gestionar el cambio organizativo: comunicar el propósito del proyecto, formar a los usuarios y acompañar el periodo de transición.
Cuando estas actividades se tratan como un paso final, la adopción suele
7. El proyecto termina en el lanzamiento
Finalmente, algunos proyectos técnicamente exitosos pueden perder tracción después de su lanzamiento.
Las primeras semanas de uso real suelen generar ajustes, dudas o pequeños errores que requieren atención rápida. Y si no existe un soporte claro durante este periodo, algunos usuarios abandonan la herramienta antes de que llegue a consolidarse.
Qué tienen en común los proyectos que sí funcionan
Cuando se analizan proyectos que terminan adoptándose de forma estable dentro de la organización, aparecen algunos elementos recurrentes:
- investigación previa con usuarios reales
- un alcance inicial reducido
- una figura interna responsable del proyecto
- métricas de impacto definidas desde el principio
- una estrategia de adopción organizativa
- soporte activo después del lanzamiento
No necesariamente se trata de proyectos más grandes o más costosos. En muchos casos, simplemente están mejor definidos antes de comenzar.
Checklist de viabilidad antes de iniciar el proyecto
Antes de iniciar el desarrollo de una herramienta interna, te dejamos algunas preguntas básicas que pueden resultar útiles:
- ¿Se ha observado cómo trabajan realmente los usuarios del proceso?
- ¿Existe una persona del área de negocio responsable del proyecto?
- ¿Está definido el alcance de la primera versión?
- ¿Se han documentado métricas de partida?
- ¿Existe un plan para acompañar la adopción del sistema?
Cuando estos elementos están presentes desde el inicio, aumenta significativamente la probabilidad de que la herramienta llegue a integrarse en el trabajo cotidiano de la organización.
En Yellow Glasses, acompañamos a nuestros clientes en este tipo de iniciativas, ayudando a evaluar la viabilidad del proyecto, definir el alcance adecuado y establecer las bases necesarias para que la solución pueda adoptarse de forma efectiva dentro de la organización.
Notas
[1] Nota metodológica: La convergencia en torno al 70% procede de cuatro estudios independientes con marcos distintos: Standish Group CHAOS Report (2020), McKinsey Global Survey (2018), Boston Consulting Group(2020) y KPMG Programme Management Survey (2002). Aunque el objeto deanálisis varía entre proyectos IT y transformaciones digitales, losresultados son consistentes.
[2] The Standish Group. (2020). CHAOS Report 2020: Beyond Infinity. TheStandish Group International.
[3] McKinsey& Company. (2018). Unlocking success in digital transformations.McKinsey Global Survey.https://www.mckinsey.com/~/media/McKinsey/Business%20Functions/Organization/Our%20Insights/Unlocking%20success%20in%20digital%20transformations/Unlocking-success-in-digital-transformations.pdf
[4] Forth,P., Reichert, T., de Laubier, R., & Chakraborty, S. (2020).Flipping the odds of digital transformation success. BostonConsulting Group.https://www.bcg.com/publications/2020/increasing-odds-of-success-in-digital-transformation
[5] The Standish Group International. (1995). The CHAOS Report.https://www.csus.edu/indiv/v/velianitis/161/chaosreport.pdf
[6] McManus,J., & Wood-Harper, T. (2007). A study in project failure. BCS —The Chartered Institute for IT.https://www.bcs.org/articles-opinion-and-research/a-study-in-project-failure
[7] Project Management Institute. (2018). Pulse of the Profession 2018: Successin Disruptive Times. PMI.https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf
Artículos destacados
Explora nuestros últimos artículos y tendencias.
¿No sabes por dónde empezar?
Cuéntanos tu reto y te ayudaremos a identificar la solución más efectiva para tu empresa.Ya sea automatizar un proceso, crear una plataforma o formar a tu equipo, estamos aquí para ayudarte a avanzar sin fricciones.
