Los proyectos de tecnología de la información (TI) no suelen fracasar por errores de ejecución aislados. Lo hacen, en la mayoría de los casos, desde mucho antes; por ejemplo, en la formulación, cuando las proyecciones ignoran cómo se genera el valor a lo largo del tiempo. También en la evaluación, cuando se aplican modelos que no capturan la realidad de lo intangible. Y en el seguimiento, cuando la gobernanza financiera se limita a controlar el gasto sin preguntarse si lo que se está construyendo tiene realmente sentido para el negocio.

El llamado “efecto W” (Segars & Chatterjee, 2010) ilustra con precisión esta dinámica (ver Figura 1). Incluso en proyectos exitosos, el valor económico agregado (EVA) tiende a caer al inicio, lo cual es esperable, ya que se invierte en infraestructura, se interrumpen procesos y se reentrena al personal. Entre los 12 y 16 meses, hay más costos que beneficios. Luego aparece una recuperación parcial —beneficios tácticos, rápidos—, pero esta no dura mucho. Llega una segunda curva descendente: los sistemas se complejizan, la integración tarda, los usuarios dudan. El negocio parece más lento y más costoso. Solo después de este ciclo —a veces tras más de tres años— se empieza a consolidar un valor sostenido. No es lineal. No es cómodo. Pero así funciona.

El problema es que las decisiones de inversión suelen ignorar esta curva. Como bien sugiere The Economist (2025), la mayoría de grandes fracasos en TI se explican porque se promete mucho y demasiado rápido, sin validar las condiciones necesarias para que los beneficios ocurran. Se estiman indicadores como el ROI como si se tratara de una planta industrial. Se proyecta un VAN positivo asumiendo eficiencia inmediata. Pero la tecnología no transforma por sí sola. Requiere algo más: tiempo, capacidades, estructura y, sobre todo, realismo.

Por eso, enfoques como el benefit management son más que útiles: son urgentes. No se trata de una técnica más. Es un cambio en la forma en que pensamos las inversiones. Desde el inicio, este enfoque exige un mapa de beneficios concreto, no solo deseado. ¿Qué se espera lograr? ¿Cómo se medirá? ¿Quién es responsable? ¿Qué condiciones deben cumplirse? Si no se puede responder con claridad, quizá no es un proyecto listo para ser aprobado. Este enfoque permite construir estimadores de retorno a la inversión más acordes con la realidad. No modelos cerrados, lineales y definitivos, sino trayectorias posibles: escenarios. Uno optimista, con plena adopción. Uno realista, con retrasos y aprendizajes. Uno crítico, con resistencia organizacional o falta de uso. En este sentido, la función financiera deja de ser quien aprueba o niega recursos, y se convierte en quien ayuda a entender la maduración del valor. Pasa de ser el auditor del pasado a ser partícipe del diseño del futuro.

Aquí vale introducir otro elemento clave. Ray et al. (2010) demostraron que el valor de la TI no reside en la tecnología en sí, sino en la forma en que esta se combina con capacidades informacionales: infraestructura técnica, habilidades humanas, relaciones entre áreas. Un software sofisticado, sin capacidades para entenderlo, adoptarlo y conectarlo al negocio, es solo un gasto. De hecho, puede incluso destruir valor. Esto no es intuición: es evidencia.

¿Y entonces? ¿Qué implica esto para la formulación? Que antes de hacer números, hay que mirar hacia adentro. ¿La organización está lista? ¿Tiene las competencias necesarias? ¿Cuenta con procesos que soporten el cambio? ¿Existen mecanismos reales para capturar los beneficios? Si no es así, el ROI proyectado será apenas un deseo. No es una crítica al modelo financiero, sino una advertencia sobre su uso en contextos que no son predecibles.

En este marco, hablar de retorno no es solo proyectar flujos de caja. Es preguntarse: ¿cuándo emerge el valor? ¿Qué lo activa? ¿Qué lo frena? ¿Qué se debe construir antes de que aparezca? Ignorar estas preguntas es repetir la historia de siempre: invertir, ejecutar, frustrarse.

No se trata de tener miedo a invertir en tecnología. Se trata de hacerlo con los ojos abiertos. De entender que lo intangible no se gobierna igual que lo físico. De aceptar que no todo valor es inmediato, pero sí puede ser sostenido si se prepara bien el terreno. Formular bien, evaluar mejor y diseñar retornos realistas no es un lujo metodológico. Es la diferencia entre transformar y simplemente gastar.

Referencias

• Mason Advisory. (2024). Delivering value from IT investment. https://masonadvisory.com/insights/delivering-value-from-it-investment/ 
• McKinsey & Company. (2023). Delivering value to customers. https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/delivering-value-to-customers 
• Project Management Institute (PMI). Delivering business value. https://www.pmi.org/learning/library/delivering-business-value-9378   (Consultado el 02/05/2025)
• Ray, G., Xue, L., & Barney, J. B. (2013). Impact of Information Technology Capital on Firm Scope and Performance: The Role of Asset Characteristics. Academy of Management Journal, 56(4), 1125–1147. https://doi.org/10.5465/amj.2010.0874  
• Segars, A., & Chatterjee, D. (2010). Diets That Don’t Work: Where Enterprise Resource Planning Goes Wrong. Wall Street Journal (Eastern ed.), Dow Jones & Co., Inc.
• The Economist. (2025, May 8). Why so many IT projects go so horribly wrong. https://www.economist.com/business/2025/05/08/why-so-many-it-projects-go-so-horribly-wrong  
• CIO Index. Value Delivery. https://cioindex.com/cio-training/courses/cios-guide-to-it-governance/lessons/it-governance-components/topic/value-delivery/   (Consultado el 02/05/2025)

Lee la nota completa aquí.