La TI con esteroides: los beneficios (y los riesgos) de acelerar la tecnología
por Bent Flyvbjerg and Alexander Budzier
En 1998, RIM lanzó el BlackBerry. Un año después, la segunda versión tenía un teclado completo. Al parecer, esa era la función que los usuarios estaban esperando. La demanda del BlackBerry 850 se disparó. En 2004, RIM había adquirido 1 millón de suscriptores y solo tres años después superó la marca de los 10 millones. En 2007, RIM celebró su 12 millones de suscriptores y generó 1670 millones de dólares en ingresos. El mismo año, Apple lanzó su iPhone, con pantalla táctil y una mejor navegación por Internet. En 2008, RIM intentó igualar al nuevo competidor. Sin embargo, el nuevo teléfono, su software y las aplicaciones disponibles no lograron entusiasmar a la crítica ni a los clientes.
Cuando se trata de la innovación en industrias con ventanas de oportunidades estratégicamente reducidas, la velocidad lo es todo. RIM es solo la última empresa en aprender esta lección. Antes, Motorola y Palm corrieron una suerte similar.
Este ritmo acelerado, lo que los académicos y los periodistas han llamado innovación en esteroides — está empezando a llegar a los departamentos de TI.
El primer gran cambio en la velocidad de entrega de TI fue la proliferación de ofertas «como servicio». Hasta la fecha, la tendencia se ha asociado a productos bastante estándar, como el software de gestión de las relaciones con los clientes, los servidores web o las bases de datos SQL, pero la teoría del dilema del innovador sugiere que lo más probable es que avance en la lista en el futuro. Las innovaciones disruptivas comienzan en la parte más baja y alta de las materias primas y se mueven al alza con el tiempo, y lo más probable es que la TI no sea la excepción.
La mayoría de los CIO se beneficiarán de esta tendencia mediante el aumento de la competencia, mejores precios y un aprovisionamiento más rápido. Al mismo tiempo, la tendencia también aumenta las expectativas de los clientes internos de los directores de TI de ofrecer mejores soluciones a una mayor velocidad.
Un segundo factor que acelera la entrega de TI es la filosofía de desarrollo de software iterativo conocida como «desarrollo ágil». Si bien la definición de ágil sigue siendo muy amplia, los valores fundamentales son la flexibilidad, la interacción individual, el enfoque en los resultados y la colaboración, en lugar de enfoques más rígidos basados en la planificación. Si bien no es tan antiguo ni tan maduro como los sistemas en la nube, merece un análisis más detallado. Los proyectos ágiles se han centrado en los sistemas estándar y no críticos. La pregunta crucial es si el método se puede escalar correctamente. En la medida en que la agilidad se convierta en el método por defecto para crear proyectos de TI a gran escala, aumentará la demanda para acelerar la entrega de los proyectos de TI. A su vez, la cartera de proyectos de TI corporativos necesita adaptarse.
Estas presiones para acelerar la entrega de TI no llegan ni un momento demasiado pronto. Investigación ha demostrado que cuanto más largo sea un proyecto de TI, mayor es el riesgo de sobrecostes y más retrasos en la programación. Demostró que cuanto más largo sea el proyecto, mayor será la volatilidad de los requisitos y, a su vez, mayor será el riesgo del proyecto. Una implicación es que cualquier método de gestión de proyectos que se base en el supuesto de que los requisitos se pueden congelar se ha preparado para el fracaso, otra buena razón por la que la agilidad podría llegar para quedarse.
Nuestra propia investigación ha analizado el problema con más detenimiento. Los resultados preliminares de una encuesta realizada a casi 4 300 proyectos de TI revelaron que los cronogramas de proyectos largos aumentan los riesgos en todos los tipos de proyectos, no solo en los proyectos de desarrollo de software. Además, descubrimos que cuanto más largo sea un proyecto, mayor será el riesgo de que se convierta en un cisne negro. Un cisne negro es un proyecto que se sale de control e implica enormes sobrecostes y retrasos en la programación. Cada año de duración adicional del proyecto aumenta las probabilidades de que un proyecto se convierta en un cisne negro un 27%.
La velocidad de ejecución de los proyectos de TI está aumentando y debería mejorar el rendimiento de los proyectos y reducir los riesgos. Sin embargo, la tendencia no está exenta de posibles inconvenientes, como ilustra el caso de una gran empresa multinacional de telecomunicaciones. El recién creado CIO implementó una política sencilla para frenar los crecientes sobrecostes y los retrasos en la programación que afectaban a la cartera de proyectos de TI de la empresa: no proyectos de más de 12 meses. Otros responsables de la toma de decisiones han ido aún más lejos: el gobierno estatal de Australia del Sur declaró recientemente solo iniciaría proyectos de TI, y se estima que tardarían menos de 90 días.
Esta sencilla táctica parece estar respaldada por la investigación. Sin embargo, la política, en el caso de la telecomunicación, tuvo consecuencias no deseadas. El anuncio de que solo se aprobarían proyectos cortos llevó a preferir innovaciones pequeñas y fragmentarias. La mayoría se centra en reducir los costes de TI. Sin querer, este sesgo de selección añadió complejidad a una arquitectura de TI ya de por sí compleja. Después de cuatro años, se habían hecho tantos cambios en los sistemas que los lanzamientos de nuevos productos no solo se hicieron prohibitivamente caros, sino que también tardaron mucho en comercializarse. Prácticamente se impidieron las innovaciones al sofocar la complejidad. Se necesitó otro proyecto de TI muy grande con todos los riesgos que ello conlleva para limpiar la arquitectura de TI, reducir las complejidades y recuperar las capacidades necesarias para competir en el futuro.
El caso demuestra que una estrategia exitosa requiere que el CIO sepa cuándo la organización de TI puede y debe actuar rápidamente para reducir los riesgos y cuándo la organización necesita ir despacio, incluso si eso implica mayores riesgos.
Se podría argumentar que ver los proyectos de TI únicamente como partidas presupuestarias en un calendario es demasiado abstracto como para captar las complejidades de la toma de decisiones y la ejecución de los proyectos de TI. Sin embargo, hemos observado que los proyectos de TI se planifican y supervisan con muy poca información. Los datos básicos de presupuesto y programación son indicadores importantes para dirigir la organización de los proyectos de TI. Un CIO debe saber cuándo la organización de TI puede y debe ir rápido y cuándo es mejor hacer frente a las poderosas fuerzas que exigen que la TI entregue cada vez más rápido. En resumen, el liderazgo estratégico de TI en un mundo de alta velocidad consiste en mezclar lo rápido y lo lento.
Reinventar la TI corporativa
Un HBR Insight Center
Artículos Relacionados
La IA es genial en las tareas rutinarias. He aquí por qué los consejos de administración deberían resistirse a utilizarla.
Investigación: Cuando el esfuerzo adicional le hace empeorar en su trabajo
A todos nos ha pasado: después de intentar proactivamente agilizar un proceso en el trabajo, se siente mentalmente agotado y menos capaz de realizar bien otras tareas. Pero, ¿tomar la iniciativa para mejorar las tareas de su trabajo le hizo realmente peor en otras actividades al final del día? Un nuevo estudio de trabajadores franceses ha encontrado pruebas contundentes de que cuanto más intentan los trabajadores mejorar las tareas, peor es su rendimiento mental a la hora de cerrar. Esto tiene implicaciones sobre cómo las empresas pueden apoyar mejor a sus equipos para que tengan lo que necesitan para ser proactivos sin fatigarse mentalmente.
En tiempos inciertos, hágase estas preguntas antes de tomar una decisión
En medio de la inestabilidad geopolítica, las conmociones climáticas, la disrupción de la IA, etc., los líderes de hoy en día no navegan por las crisis ocasionales, sino que operan en un estado de perma-crisis.