Los proyectos que la mayoría de los profesionales de TI temen son las tareas ingratas pero esenciales que obtienen poco reconocimiento o respeto.

La administración de actualizaciones no es glamorosa, pero no mantenerse al día podría causar que su organización sufra una violación de seguridad masiva. Los proyectos de migración a la nube no suelen ser atractivos, pero la ejecución de servidores de correo electrónico on premises en el 2018 es un poco como usar teléfonos rotativos. Las implementaciones y actualizaciones de la planificación de recursos empresariales (ERP) han sido el principal causante del fracaso del proyecto de TI durante más de una década, pero la mayoría de las grandes organizaciones no pueden sobrevivir sin algún tipo de sistema ERP.

La tecnología casi nunca es la causa de infernales proyectos de TI. Con mayor frecuencia, las iniciativas tecnológicas caen en desorden debido a expectativas poco realistas, fallas para determinar un alcance adecuado, choques culturales, postergación o falta de soporte adecuado desde las alturas.

Las soluciones a los infernales proyectos de TI suelen ser sencillas, pero el diablo se encuentra en los detalles.

1. Enormes actualizaciones de último minuto

Las actualizaciones son una de esas tareas esenciales que casi todos los profesionales de TI odian realizar. Pero si la posterga demasiado tiempo o no se asegura de que todas sus máquinas estén actualizadas, su organización podría terminar como Equifax.

“Nos lanzan constantemente grandes proyectos en los que la actualización no ha tenido lugar durante meses o años”, afirmó Oli Thordarson, CEO de la proveedora de servicios de TI, Alvaka Networks. “A veces pueden ser cientos de servidores de producción, junto con servidores de prueba y desarrollo. Saber que si algo sale mal podemos arruinar la gran presencia del nombre de una marca en Internet es estresante. Es por eso que el personal interno a veces posterga las actualizaciones, hasta que repentinamente la gerencia observa la situación y se da cuenta de que es abrumadora”.

Hace unos años, Alvaka estaba haciendo un gran trabajo de actualización de Windows para una estación de policía de la ciudad, afirmó Thordarson. Todo funcionó bien con las desktops del personal de bajo rango. Pero las PC para el jefe de la policía, capitanes y tenientes no funcionaban -y ellos no estaban contentos con eso.

“Los altos mandos de los departamentos de policía no son personas tímidas”, mencionó. “Nos llaman y están muy molestos porque no pueden iniciar sesión y hacer lo que necesitaban hacer”.

Resulta que estaban usando máquinas ligeramente diferentes con aplicaciones de terceros que estaban causando un conflicto. El equipo de Thordarson pudo deshacer las actualizaciones, aislar el problema y arreglarlas en aproximadamente treinta minutos. Pero fue una media hora tensa y estresante.

Los peores trabajos de actualizaciones son aquellos en los que los sistemas se han descuidado durante años, agregó Unnar Gardarsson, CTO de Alvaka -quien dijo ser uno de los pocos profesionales de TI que realmente disfruta de las actualizaciones-.

“El momento ‘oh mie*da’ es cuando he actualizado algo y los servidores demoran demasiado en volver, o no vuelven en absoluto”, afirmó. “En algunos casos, puedo acceder a la consola de recuperación de la máquina virtual y observar el servidor. En otros entornos, todo lo que puedo hacer es actualizar y rezar”.

Lecciones aprendidas: Para evitar las peores situaciones posibles, tenga especial cuidado en asegurarse de tener un plan de backup completamente probado que represente todos los sistemas, indicó Gardarsson.

“Por cada trabajo de actualización que hago, tengo un plan de proyecto que tiene en cuenta todo, desde copias de seguridad normales e instantáneas adicionales, hasta la notificación a las personas y la detención de los servicios”, indicó. “Algunos sistemas son realmente quisquillosos y hay un proceso muy específico para desconectarlos. Es crucial estar preparado y pensar en todas las posibles situaciones”.

2. La gran migración del correo electrónico a la nube

Pasar de una solución de correo electrónico local a una de nube suena simple en principio. Es todo menos eso, afirmó Mike Meikle, CEO de SecureHIM, consultora de seguridad TI para la atención médica.

Por un lado, los usuarios son acaparadores, dijo Meikle. Ellos tienen gigabytes de gigabytes de mensajes que deberían haber borrado hace años, por lo que el volumen total de datos es desalentador. Si se está moviendo de un sistema previo como Lotus Notes (escalofríos), tendrá mucha conversión de datos bajo su responsabilidad. Parte de la información en esos mensajes es altamente confidencial y regulada, por lo que debe asegurarse de cumplir con HIPAA, GDPR, SOX u otras reglamentaciones.

Y, por supuesto, tiene que lidiar con un sistema en el que las personas dependen prácticamente las veinticuatro horas del día, los siete días de la semana para comunicación, programación, reserva de salas de reuniones, etc.

Meikle dijo que ha trabajado en empresas donde la migración a la nube tomó más de un año y requirió mucha instrucción.

“Dado que el correo electrónico es tan omnipresente, si la migración se cae de alguna manera, el área de TI es apuñalada de inmediato”, afirmó. “Incluso en la era de Slack y otras aplicaciones de chat para equipos, la migración de correo electrónico es uno de esos proyectos que TI definitivamente teme”.

Lecciones aprendidas: Al igual que con otros infernales proyectos de TI, es esencial hacer su tarea antes de tiempo. Haga que los requisitos del sistema o dispositivo estén definidos, y reclute a un grupo central de usuarios avanzados para ejecutar una prueba de concepto y pilotos para que pueda resolver la mayoría de los problemas con anticipación.

“No puede ser que las cosas vayan por ahí diciendo: ‘Oh, esto se ve bien'” >, señaló. “Realmente debe conocer sus requisitos de usuario y lo que van a tolerar”.

3. Mandatos de cumplimiento normativo huérfanos al nacer

Hay dos tipos de proyectos de TI: aquellos que reciben un fuerte patrocinio por parte de la alta gerencia debido a que son estratégicos para el éxito de la organización, y los demás. Pero el tipo más infernal es aquel en el que los empleados tuvieron que ser arrastrados pateando y gritando para cumplirlo, con poco apoyo de la alta gerencia.

“Los proyectos regulatorios impulsados por el liderazgo ejecutivo, pero que no cuentan con el respaldo absoluto, son los peores”, afirmó Sheldon C., director de una firma de servicios de TI. (Sheldon no es su verdadero nombre, pidió mantenerse anónimo para evitar ser identificado por sus antiguos colegas).

Hasta hace aproximadamente un año, Sheldon era vicepresidente tecnológico de una gran institución financiera en la costa oeste. Cuando se unió a la compañía, ya estaba en la mira de los reguladores, en parte debido a un plan de recuperación de desastres inadecuado. Los accionistas activos estaban presionando a la institución para que limpiara el desastre, y aunque la alta gerencia estaba detrás del proyecto, los directores del área tenían sus propias prioridades. La DR no estaba en la parte superior de sus listas.

Entonces ellos no participaron. No presentaron los requisitos del área para las prioridades de fail over y de recuperación, ni identificaron datos y aplicaciones de misión crítica. No participaron en pruebas preliminares o avanzadas. Ignoraron los correos electrónicos de Sheldon.

Debido a que las solicitudes venían de TI, los jefes de área se sentían cómodos relegándolos al último lugar, y los patrocinadores del proyecto no hicieron nada para interceder en nombre de Sheldon.

“Le mencioné una y otra vez al CIO que esto estaba sucediendo, por favor ayúdenme”,dijo. “Yo estaba como, ‘Oigan, tenemos problemas’. Solo se escucha el canto de los grillos. “Todavía no he recibido respuesta”. Más grillos. Entonces, el proyecto procedió sin que esos riesgos fuesen reconocidos y aceptados”.

Lecciones aprendidas: Documentar todo el proceso -incluyendo todo intento fallido de lograr que las partes necesarias participen- es fundamental. Pero también necesita distribuir la información a las personas adecuadas, con el fin de que, más adelante, los patrocinadores del proyecto no puedan alegar que no estaban informados.

Y si eso no funciona, reduzca sus pérdidas. En el caso de Sheldon, eso significaba trasladarse a un nuevo puesto, tan pronto se presentara la oportunidad.

“Lo gracioso fue que el CIO sostuvo que el proyecto de DR fue un gran éxito”, mencionó. “Recibí elogios por llevarlo a cabo. Pero sabía que cuando los auditores realmente lo analizaran, aquellos que lo elogiaban tendrían que defender lo sucedido. Cuando la cultura de la compañía lo está preparando para fracasar, esa es una buena señal de que es hora de irse”.

4. ERP es una palabra de cuatro letras

Probablemente ningún tipo de proyecto haya inspirado más angustia o haya inducido más acidez que la implementación de un nuevo sistema ERP.

Tener que conectar el ERP con hardware previo siempre está plagado de peligros; emite barreras lingüísticas y culturales, obteniendo así la receta para un desastre de proporciones épicas, señaló Dan Coleby, director de desempeño empresarial y consultor de IT Lab, compañía de servicios de tecnología con sede en el Reino Unido.

A mediados de la década del 2000, cuando Coleby trabajaba para una firma de consultoría Big 4 en Londres, fue llamado para ayudar a la sucursal japonesa de una gran multinacional a implementar su sistema global de ERP. En el momento en el que Coleby llegó, el proyecto tenía más de dos años y era bastante más económico, parcialmente debido a que una parte del hardware era verdaderamente antiguo.

“Uno de esos sistemas era tan antiguo que tuvimos que pedir prestado un suministro de energía de una exhibición en el Museo Nacional de Computadoras en Tokio en caso de que fallaran”, afirmó. “Solo teníamos ocho horas cada noche para actualizar el sistema ERP con nuevos datos, pero la interfaz tardó veinte horas en ejecutarse, lo que lo hacía básicamente inútil”.

Pero las mayores barreras no eran tecnológicas; fueron las personales y políticas. Coleby tuvo que descubrir cómo hacer que el sistema se pusiera en marcha sin que nadie sea humillado.

“No se me permitió cuestionar la arquitectura, la estrategia o el enfoque global de la compañía en relación a la tecnología”, afirmó Coleby. “Terminé persuadiendo a los japoneses de cambiar sus procesos de negocios para que usen menos información. Recorté alrededor del 90% de los datos para que el sistema pudiera funcionar en menos de ocho horas”.

Lección aprendida:La tecnología por sí sola no es la respuesta; las personas y el proceso son igual de esenciales, dijo Coleby.

“En IT Lab siempre abordamos la organización, la estructura, el proceso y el ámbito de la gobernanza de TI, porque eso siempre es tan importante como la tecnología misma”

5. Falta de alcance y exceso de promesas

Ya sea por un exceso de optimismo, un deseo de impresionar al jefe, o una falla al establecer debidamente el alcance de los proyectos, la subestimación del tiempo y el esfuerzo necesarios para producir una aplicación puede hacer que un proyecto desafiante se convierta en uno infernal.

“Usted puede ver que las personas se muestran muy optimistas respecto a lo que pueden ofrecer en un corto período de tiempo, especialmente en compañías de rápido movimiento”, afirmó Alan Zucker, director fundador de Project Management Essentials.

A fines de la década de los noventa, Zucker estaba trabajando como gerente de proyectos en el área de contabilidad de una compañía de telecomunicaciones Fortune 100. El operador facturaba más de mil millones de dólares al mes y utilizaba cientos de hojas de cálculo y bases de datos interconectadas para realizar un seguimiento de todo. La solución fue crear una sola aplicación para cerrar los libros cada mes, usando Sybase en la parte posterior con una interfaz de Power Builder.

Después de una reorganización de la compañía, la responsabilidad del proyecto recayó en el grupo de Zucker.

“Al grupo de TI se le ocurrió una idea realmente elegante, que consistía en cargar todo en una base de datos y dejar que los contables construyeran sus propias reglas comerciales”, afirmó.

Pero habían prometido producir la aplicación en nueve meses. Cuando Zucker heredó el proyecto, cuatro meses después, no se había escrito ni una sola línea de código. El grupo de TI aún estaba recopilando los requisitos del usuario. Y descubrieron que el trabajo era mucho más complicado de lo que nadie había previsto.

Fue entonces cuando comenzaron a señalar a los responsables, mencionó Zucker.

“Mi contraparte en la organización de TI comenzó a ponerse a la defensiva”, señaló. “Él escribía estos correos electrónicos de varias páginas y daban la impresión de tratarse de investigaciones policiales. ‘En esta fecha en este momento, tal y tal dijeron esto…’ y así sucesivamente. Se convirtió en esta situación cada vez más intensa donde simplemente no hubo conversaciones constructivas”.

Después de que el gerente de TI fue reasignado y Zucker consiguió un nuevo socio, así como un calendario más permisivo, el proyecto pudo avanzar. La aplicación terminó siendo un éxito, pero tomó otros dos años hasta en ser terminada.

Lecciones aprendidas: Zucker afirmó que se dio cuenta de que, en el futuro, necesitaba alejarse de la confrontación y encontrar la manera de que ambas partes salieran victoriosas. También aprendió que está bien pedir más recursos y restablecer los términos originales del proyecto. Y, por último, fue una lección sobre cómo cambiar un solo recurso -o una persona- puede mejorar totalmente la dinámica del equipo.

6. Peticiones especiales por parte de la alta gerencia

Es posible que haya estandarizado su organización global en Android, pero husmear en el iPhone del CEO contra su voluntad. O tal vez un director al frente de la junta solicite una solución personalizada para su área.

En el caso ideal, las solicitudes de proyectos se califican según los planes estratégicos y se determinan necesarios para que la empresa alcance objetivos específicos antes de que se aprueben y se presupuesten.

“La mayoría de las organizaciones no son así”, afirmó Meikle. “Muchas veces es quien tiene mayor poder político el que lleva a cabo sus planes”.

Incluso las empresas más herméticas pueden caer presas de los caprichos de quienes ejercen la mayor influencia, indicó. En muchos casos, eso sucede porque el CIO no tiene el poder político para negarse.

“Cuando se trata de empujar, por lo general se pliegan como un traje barato”, dijo. “Aún están en la mesa de los niños en Acción de Gracias, comiendo la salsa de arándanos enlatados”.

Lecciones aprendidas: Si no tiene un proceso de admisión para proyectos de TI, espere que aquellos con mayor influencia pasen por alto sus prioridades, afirmó Meikle. Debe saber quiénes son su gobernanza clave, su principal riesgo, y sus grupos de interés de cumplimiento normativo más importantes, así como asegurarse de que TI tenga un asiento en la mesa de cada comité directivo.

“Necesita a la alta gerencia en su campo para gestionar eficazmente la entrada y el flujo de trabajo del proyecto de TI”, agregó. “De lo contrario, financiará cada capricho ejecutivo con su presupuesto de TI mientras absorbe sus recursos, dejando migajas para proyectos menos glamorosos pero críticos, como infraestructura y redes”.

-Dan Tynan, CIO (EE.UU.)