El arte (y la ciencia) del cambio de rumbo en los proyectos de TI

0
13

La agilidad y la resiliencia son habilidades que se han convertido en palabras de moda en estos días, pero también lo es la capacidad de cambiar de rumbo. Podría decirse que, en los últimos meses, el mayor cambio de dirección en los proyectos para todos los CIO fue detener lo que estaban haciendo para mover sus organizaciones a un trabajo remoto completo -prácticamente de la noche a la mañana- después de que comenzara la pandemia de COVID-19.

Eso es diferente a cuando los proyectos en marcha cambian de curso, algo que sucede a menudo. Sin embargo, reconocer cuándo es el momento de cambiar de dirección -y cómo hacerlo- es algo así como un arte. Estos líderes de TI se han encontrado en posiciones en las que tenían que cambiar de rumbo y ahora tienen algunos consejos que ofrecer.

Sea audaz
Es importante reconocer cuando algo no funciona -o cuando está fallando por completo- y tomar medidas rápidas para dar un giro.

Por ejemplo, en el 2017, Mars Global tenía un proyecto en marcha para reemplazar un sistema legado de gestión de almacenes en su unidad de nutrición para mascotas en Rusia. Después de probar aproximadamente el 70% de las funcionalidades del nuevo sistema, el equipo descubrió varios problemas que hicieron que la fecha de lanzamiento (el primer trimestre del 2018) no fuera factible, recuerda Miao Song, CIO global de Mars Petcare.

«La causa fue que la plantilla global no se ajustaba a las necesidades locales de la operación”, explica. «Después de una cuidadosa revisión, tomamos una decisión audaz: suspender el proyecto y evaluar rápidamente otra tecnología… que había sido prometedora con otras compañías de bienes envasados en Rusia”.

En ese momento, afirma Song, tomó la difícil decisión de eliminar el proyecto existente e ir en una dirección diferente. Finalmente, los ejecutivos optaron por implementar SAP Extended Warehouse Management en varias de sus instalaciones en Rusia, lo que, según ella, resultó ser la decisión correcta para el negocio.

«Vemos los proyectos que necesitan una corrección de curso como oportunidades, en lugar de fracasos, no solo desde la perspectiva de la gestión, sino también desde la perspectiva del aprendizaje del liderazgo”, afirma Song. «La clave del éxito es crear un ambiente seguro para que las personas aprendan rápidamente de estas experiencias y se adapten a la situación, encuentren diferentes soluciones y solucionen rápidamente el problema”.

Como CIO, Song afirma: «siempre aliento el aprendizaje y la mentalidad abierta”.

Analizar, adoptar y adaptar
Cuando Chris Zeller piensa en proyectos que necesitan un cambio de rumbo, los compara a trabajar en un hospital. «¿Recuerda el programa de televisión ER en los años ochenta? Cuando se trata de nuevos desafíos, analizo lo que hago de igual manera que un médico o una enfermera en la sala de emergencias”, afirma Zeller, director de TI en la compañía de vitaminas y suplementos Country Life. «Uno prioriza y clasifica los diferentes eventos que ocurren. Alguien que no puede respirar tiene prioridad sobre alguien con un hueso roto”.

Esto significa una evaluación constante mientras el proyecto está en marcha, afirma Zeller. Incluso cuando un equipo avanza con el plan y los objetivos que tienen que cumplir, las cosas saldrán mal y un buen líder será flexible y ágil, afirma.

«También implica un trabajo muy cercano con el equipo ejecutivo y su apoyo” para saber cuándo es el momento de cambiar de dirección, afirma Zeller. «Me gusta usar las tres As: analizar, adoptar y adaptar”.

Y sea resiliente para poder «recuperarse rápidamente de condiciones difíciles”, agrega Song. «En este proyecto, la capacidad de recuperación del equipo les permitió cambiar la situación”.

Escuche a sus clientes -y observe a la competencia
A menudo, los proyectos se prueban cuando están en la fase de diseño, y existen algunas indicaciones seguras de que algo no está bien, afirma Dave Garrett, director de estrategia y crecimiento del Project Management Institute.

La retroalimentación negativa es obvia, pero a veces hay que leer los signos más sutiles. Uno de ellos es cuando «no hay expectativa y nadie pregunta: ‘¿Cuánto costará y puedo tenerlo ahora?’”, afirma Garrett. «Si uno está creando algo atractivo, esas son las preguntas que va a escuchar”.

También tenga en cuenta los cambios en el panorama competitivo, afirma. Si no hay una sensación de urgencia para introducir un producto en el mercado, existe una buena probabilidad de que no tenga éxito. «Esto sucede mucho en la industria farmacéutica; si tiene dos medicamentos contra el cáncer diferentes, por lo general, el primero en el mercado gana y el segundo tendrá que cerrar porque experimentará dificultades para obtener la adopción del mercado”, afirma Garrett.

Las pruebas rápidas son muy importantes, concuerda Song. Organice la implementación en sprints individuales, aconseja. Sobre el proyecto de almacenes de Mars Global, afirma: «En lugar de avanzar lentamente por todo el proyecto como una sola entidad, el equipo del proyecto pudo trabajar más rápidamente garantizando el éxito de cada fase, así como financiando el proyecto por etapas. Las funcionalidades también se probaron cuidadosamente”.

Tampoco puede tener una visión estrecha y solo enfocarse en el resultado final, esa es una receta para el desastre.

«Si, por el contrario, uno se centra en los resultados -¿qué debería hacer el producto por sus clientes?- tiene más espacio y abre su mente y su visión a diferentes posibilidades para llegar allí”, afirma Garrett. «Un producto podría cambiar con el tiempo y existe mayor discusión sobre las diferentes formas de lograr ese resultado”.

Preste atención a los datos y a su personal
Aprender a cambiar de dirección no es solo un arte, sino una ciencia. Cuando usted tiene datos, es difícil discutir sobre lo que le afirman los hechos.

Eso es lo que Robert Rosales aprendió durante la implementación de un proyecto de sistema de planilla. Rosales, director de TI en Oak Harbor Freight Lines, un operador de servicios de transporte premium en la costa oeste, afirma que uno de sus programadores estaba trabajando en la creación de una interfaz para el sistema. El proyecto se completó en más del 75% cuando el programador se dio cuenta de que las API requeridas para crear la interfaz tendrían que pasar por un proveedor externo.

«Ese no iba a ser un proceso sostenible”, afirma Rosales. «Hubo múltiples puntos de estancamiento potenciales porque no era una extracción directa de la API de la base de datos del proveedor”. El equipo del proyecto consideró que el proceso sería demasiado engorroso y crearía retrasos.

El proveedor no tenía otro producto disponible, por lo que Oak Harbor dejó el proveedor y eligió uno diferente, el cual ofrecía una mejor solución para la interfaz, afirma.

Esto hirió muchos egos entre los que promovían el proyecto, afirma Rosales. «Tenía que enfatizar que el proyecto era para la empresa y no para una persona”.

Por lo general, cuando esto sucede, existe una tendencia de querer mantener el rumbo, agrega.

«Pero hay que prestar atención a los datos y al consejo del personal técnico. En este caso, el programador”, afirma Rosales. «Uno quiere mucho compromiso y poco estrés. …Si hubiera pasado en el primer cuarto del camino, definitivamente habría sido mucho más fácil”.

Aún así, Rosales cree que «si uno reduce sus pérdidas, aún está en ventaja con respecto a continuar alimentando un proyecto que va a fracasar”. Sin embargo, Rosales admite que la conversación con la alta gerencia no fue fácil. Hubo diferentes grupos: aquellos que sentían que debían continuar debido a todo el tiempo y el dinero ya invertidos, y aquellos que se dieron cuenta de que sería difícil dar soporte al sistema en el futuro.

Ahora, el equipo está comenzando desde cero. «Sin embargo, en realidad, lo principal es que no estamos perdiendo la visión -necesitamos un nuevo sistema de planilla- solo tenemos que tomar un camino diferente para llegar allí”. El equipo aún habría llegado a la meta si hubiesen continuado el camino en el que se encontraban, afirma, pero el sistema «habría estado lleno de golpes y contusiones y no hubiera sido sostenible en el futuro”.

La persona que lidera el proyecto no será necesariamente la que identifique cuándo es necesario cambiar su rumbo, afirma Garrett del PMI. «Es probable que sea identificado por la persona más cercana al cliente o más cercana al producto”.

Rosales afirma que antes de que creciera el problema, se aseguró de que «mis datos estaban en orden y podían expresar el peligro en el futuro”. Hizo su propia investigación una vez que el programador acudió a él. Luego tuvo una conversación con uno de los principales líderes. «Uno prueba las aguas y luego recibe los comentarios” antes de alertar al resto de la administración, afirma.

Piense en plataformas, no en proyectos
Históricamente, el envejecimiento de la tecnología se abordó con un enfoque de «pensamiento basado en proyectos” en AvidXchange, proveedor de software de automatización de pagos, afirma Angelic Gibson, CIO. Eso significaba arreglar un área de la plataforma según fuera necesario y luego seguir adelante, «en lugar de alejarse y tener un enfoque de plataforma”, afirma ella.

Cuando uno aplica el ‘pensamiento de plataforma’, «realmente puede comprender dónde están los puntos de fricción y separarlos e innovar más rápido”, señala.

Existen varios productos que conforman la cartera de AvidXchange, y Gibson se encontró «lidiando con el pensamiento basado en silos” cuando la actualización estaba en marcha. Cuando se unió a la compañía hace año y medio, «literalmente pusimos una pausa en el trabajo y pasamos al pensamiento basado en plataforma”.

Gibson pasó sus primeros seis meses evaluando el estado de la tecnología y afirma que, cuando miró lo que sus clientes querían, «nuestra línea de producción no fue lo suficientemente rápida”.

Tiene que ser más ágil, afirma, y los líderes deben comprender todas las métricas clave en el camino. Al igual que Rosales, afirma Gibson, necesita datos para sustentar su caso. Pasó tiempo monitoreando el uso de su plataforma para comprender los patrones.

«La idea de volar a ciegas sin datos sería paralizante”, afirma.

Si existen espacios vacíos en los datos, depende de los líderes de TI idear una estrategia para cerrarlos, agrega. «Debe eliminar todos los puntos de fricción, desde la idea hasta la producción, ya sea en sus procesos o en las tecnologías con las que está trabajando”.

Tenga cuidado con los prejuicios -y evalúe constantemente
A veces las personas están casadas con una tecnología en particular y desarrollan ciertos sesgos, afirma Gibson. «Pero, si probamos y aprendemos que hay demasiada fricción para absorber la tecnología en la producción, no deberíamos pasar ciclos tratando de que funcione”.

En lugar de utilizar una tecnología que parece genial, que puede no ser adecuada para el caso de negocios, los líderes de TI deberían considerar el problema que están tratando de resolver, afirma.

Haciéndose eco de Zeller, de Country Life, Gibson afirma que el arte del cambio de rumbo del proyecto requiere poder evaluar y analizar si sus procesos son ágiles y pueden satisfacer las necesidades de sus clientes de manera oportuna.

«No me gusta la idea de fracasar, sino de probar para aprender y usar esos aprendizajes para informar el siguiente paso”, señala.

Según Gibson, los indicadores principales de cuándo es el momento de un cambio de rumbo para el proyecto son cuando los plazos para la producción de algo de valor son muy largos, cuando es difícil de implementar y cuando está cambiando constantemente las cosas y causando tasas de incidentes de proyecto más altas de lo normal. Ahí es cuando es hora de retirarse y evaluar.

El problema se vuelve más claro cuando existen varios obstáculos frente a usted, afirma. «Puede intentar sobreponerse a las cosas, pero a medida que se encuentra introduciendo más soluciones, se da cuenta… el camino no es tan recto como pensaba. Ahí es cuando se da cuenta de que tiene que hacer u giro”.

En su caso, «arrojamos todo contra la pared”. Una de las formas en que TI resolvió el problema de la agilidad fue pasar a microservicios y crearon APIs a las que los minoristas y socios de fidelización se suscribirían, afirma.

Alinearse siempre con el valor de negocio
Los proyectos exitosos exigen alineación a todo nivel, afirma Garrett, de PMI, de modo que todos conduzcan hacia el mismo objetivo. «A veces, en el mundo ágil, llamamos a eso la definición de lo terminado -¿cómo se ve ‘terminado’ en un producto?”

Si comprende la totalidad del valor que se le entrega al cliente, le ayuda a decidir cuándo necesita cambiar de rumbo, sostiene. Un líder efectivo podrá determinar los lugares donde TI necesita enfocar su energía, afirma.

Los objetivos de negocio están cambiando más rápido que nunca, y los proyectos son inherentemente globales y necesitan crecer en escala, señala Garrett. Combine eso con una competencia intensa, y los proyectos digitales tienden a crecer. Los CIO deben pensar en el valor que están entregando.

«Si un equipo no está prestando atención a lo que usted está diciendo y no le están entendiendo con respecto al valor que está produciendo, dé un paso atrás”, aconseja. Concéntrese en lo que les importa y lo que los frustra y resuelva eso. «Si no está produciendo valor, ¿qué es lo que puede producir que agregará valor?”.

Al igual que el enfoque de plataforma versus proyecto de Gibson, Garrett también sugiere que los CIO se enfoquen en concentrarse en el cliente, en lugar de centrarse en el producto. «Usted está resolviendo sus necesidades más urgentes frente a las que se resuelven con el producto que ya tiene. Averigüe dónde está el problema y aborde eso”, afirma.

Esther Shein, CIO.com – CIOPeru.pe