Estamos hablando de fallas espectaculares que interrumpen las cadenas de suministro, retrasan la presentación de informes financieros y hacen estallar las carreras de ejecutivos aparentemente competentes.

Nunca es una posición popular convertirse en el pronosticador de desastres y fracasos para una organización, por lo cual escribo esta misiva con el pleno entendimiento de que el contenido caerá en oídos sordos y los beneficios potenciales de mi consejo se encontrarán en la pila de “Ojalá tuviéramos…”. Pero escuchen esto: Hay un tsunami de desastres de proyectos que avanzan rápidamente hacia “las costas de la empresa” y no se puede hacer mucho para detenerlo.  

El tipo de desastres de proyectos a los que me refiero no son los que superan el presupuesto y están atrasados, sino los fracasos espectaculares que interrumpen las cadenas de suministro, retrasan la presentación de informes financieros y hacen estallar las carreras de ejecutivos aparentemente competentes. Estos son los tipos de fallas que se crean cuando las empresas “se ponen en marcha” con una implementación que, en retrospectiva, se considerará realizada de manera imprudente.  

Cuatro presagios de la fatalidad

¿Por qué estoy tan convencido de que muchos proyectos están en curso de colisión con el fracaso? Considere lo siguiente:

• Se duplica el volumen. Hay el doble de grandes proyectos programados para entrar en funcionamiento entre mayo y septiembre de este año en comparación con un año normal. Cuando el COVID cerró las actividades a principios de 2020, muchas empresas suspendieron sus grandes programas de transformación habilitados por TI. A principios de 2021, la represa se rompió y las grandes iniciativas programadas para comenzar en 2020 se lanzaron en 2021. Al mismo tiempo, las empresas que originalmente habían planificado lanzar programas en 2021 lo hicieron. ¡Voila! Eso significa duplicar el número de posibles desastres del proyecto. Con los plazos de entrega de la implementación inicial con un promedio de 12 a 18 meses para las principales iniciativas, la mesa está lista.

• Sesgo de actualidad. ¿Cuándo fue la última vez que leyó sobre el fracaso de la puesta en marcha de un proyecto importante? Proyectos como Select Comfort, National Grid, Cover Oregon o el Departamento de Agua y Energía de Los Ángeles (LADWP) han estado fuera del radar durante algunos años, el tiempo suficiente para que se desvanezcan de la memoria de la alta gerencia. La arrogancia organizacional es una fuerza poderosa que a menudo contrarresta la realidad. Cuando no hay noticias de desastres, la amenaza potencial se desvanece. Hay una razón por la cual todos manejamos con más cuidado después de ver un accidente automovilístico.  
• Vacíos de talento. Casi todos los grandes desastres de puesta en marcha se pueden atribuir a la falta de experiencia por parte de los principales miembros del equipo del proyecto. La capacidad de determinar y comunicar los riesgos es obviamente primordial para mitigarlos. Con el doble de proyectos en juego, la capacidad de los integradores de sistemas (SI) para traer talento altamente calificado a todos los programas se ha visto muy disminuida. Combine esto con la “gran resignación” y las tasas de deserción que se han duplicado en los últimos 6 meses, y verá que el nivel de conciencia situacional en estos programas se ha reducido drásticamente.
• Métodos no probados. Hemos visto muchos proyectos con dificultades en las áreas de pruebas de sistemas integrados durante la pandemia. El origen del impacto en la productividad a menudo se remonta a la falta de ubicación de los equipos de proyecto. Sin estar juntos, los miembros del equipo no aprenden tan rápido de sus vecinos y los consejos y trucos no se transmiten tan fácilmente. Ahora avance rápidamente hasta después de la implementación y considere el impacto potencial en miles de usuarios que pueden no tener a los superusuarios en la silla de al lado para guiarlos a través del inicio. No hay razón para creer que las mismas dificultades que vimos en las pruebas se solucionarían milagrosamente después del despliegue.

Cómo evitar desastres informáticos

¿Hay formas de evitar el tsunami de los desastres? La respuesta es, lamentablemente, no. La suerte está echada. ¿Existen tácticas que puedan implementarse en programas individuales para prevenir un desastre? Afortunadamente, esa respuesta es sí. Aquí hay algunas recomendaciones simples:

• Hágalo realidad. Pídale a su área de Ingeniería de Desarrollo que prepare una presentación sobre las lecciones aprendidas de los principales desastres del programa. No es necesario que sea usted el “mensajero al que le disparan en la playa”. Obtenga esta presentación ante el comité directivo lo antes posible para demostrar que está tomando las medidas adecuadas para proteger el negocio.  
• Establezca los criterios de puesta en marcha desde el principio. Demasiados programas conforman los criterios de entrada 2 o 3 meses antes de la puesta en marcha específica. Cuando este es el caso, el criterio se convierte en “¿Qué podemos lograr antes de la puesta en marcha?”, en lugar de “¿Dónde deberíamos estar?”. Esto es particularmente cierto para los proyectos que están bajo estrés presupuestario.
• Vista independiente . El buen juicio se ve fácilmente empañado por las evaluaciones de costos hundidos y la planificación injustificada del mejor de los casos. Una opinión independiente puede ser muy aleccionadora.

Me doy cuenta de que esta publicación es probablemente un poco deprimente o puede percibirse como sensacionalista, pero si usted pone los engranes en movimiento –incluso para evitar el desastre de un solo proyecto–, ¡entonces valió la pena!   

John Belden, CIO.com