Desde decirles a todos que son “sus clientes” hasta establecer una estrategia de nube, estas “mejores prácticas de la industria” seguramente reducirán sus posibilidades de éxito de TI.

¿Qué hace que las organizaciones de TI fracasen? A menudo, es la adopción de lo que se describe como “mejores prácticas de la industria” por parte de personas que deberían saber más pero no saben, probablemente porque nunca han tenido que hacer el trabajo.

Desde establecer clientes internos hasta instituir devoluciones de cargo e insistir en el ROI, muchos de estos consejos parecen plausibles cuando se ven a 10,000 metros de altitud o más. No obstante, si usted rasca la superficie, comenzará a descubrir que estas recetas infalibles para el éxito de TI son a menudo fórmulas para el fracaso.

1. Dígale a todos que son sus clientes

¿Busca fallar? Asegúrese de que todos en TI le digan a todos fuera de TI: “Eres mi cliente. Mi trabajo es superar tus expectativas” (o, peor aún, “mi trabajo es hacerte feliz”).

Los empleados fuera de TI no son clientes de TI. Son colegas de TI, con quienes esta área colabora como iguales cuando sucede algo bueno para la empresa en su conjunto. 

La legitimación de la idea de los clientes internos coloca a TI en una posición subordinada, donde todos en TI tienen que hacer felices a sus colegas, ya sea que tenga sentido para el negocio o no, y mucho menos si alienta a los clientes reales de la empresa a comprar más productos y servicios.

2. Establezca SLA y trátelos como contratos

¿Quiere hacer algo de daño? Establezca acuerdos de nivel de servicio (SLA) formales, insista en que sus “clientes internos” los firmen y trate estos SLA como contratos.

Y si realmente quiere que TI falle, discuta si ha cumplido con sus SLA cada vez que un “cliente interno” (ahí está esa frase nuevamente) sugiere que TI no está haciendo lo que necesita que haga. Es una excelente manera de mantener las relaciones a distancia.

Si prefiere el éxito, entonces recordará que las relaciones requieren confianza, que la confianza no existe a menos que reconozca a sus colegas como personas reales, que si les cae bien, trabajarán con usted para solucionar cualquier problema y que el propósito de los contratos no es definir las relaciones, es definir lo que sucede cuando no hay confianza y algo sale muy mal.

3. Cuente historias de usuarios tontos

Usted los conoce. Hay chistes clásicos como: “Hey, usted tiene un apagón en la pantalla”, “Permítame aclarar esto: ¿está teniendo un corte de energía y no puede entender por qué su PC no arranca?” o “Le dije que intentara invertir el enchufe su impresora… ¡y era un enchufe de tres clavijas (risas)!”.

Bueno, pues ríase cuando otros miembros del personal de TI se lo digan, especialmente cuando tienen nombres adjuntos. O si quiere asegurarse de que falla TI, dígaselo usted mismo. De esa manera se correrá la voz de que ni usted ni nadie más en TI tiene respeto por nadie más.

Eso ayudará a la causa.

4. Instituir devoluciones de cargo

Esta es una excelente manera de desalentar el uso de la tecnología de la información: instituya devoluciones de cargos. Y no cualquier contracargo: los cuidadosamente calculados que generan facturas que detallan cada categoría de gastos en los que ha incurrido cada centro de costos, desde ciclos de CPU hasta almacenamiento SAN y NAS (sepárelos, por supuesto), horas de desarrollador y llamadas a la mesa de ayuda, facturado en incrementos de 10 minutos.

Nada fomenta la colaboración como discutir sobre la precisión de las facturas que determinan qué bolsillo corporativo debe guardar el dinero.

5. Insista en el ROI

¿Quiere asegurarse que los proyectos críticos no reciban financiación? Insista en que el proceso de gobierno de TI requiere un retorno de la inversión claro, tangible y financiero. Hacer eso prácticamente asegura un deslizamiento hacia la obsolescencia, mientras que la tecnología que ayuda a los departamentos de negocios a brindar mejores resultados más rápido no recibe fondos y los proyectos que ayudan a impulsar la satisfacción del cliente (aumentar las ventas y reducir el costo de las ventas, pero no en formas en que TI puede probar) son objeto de burlas en la oficina de la esquina, junto con quien los propuso.

6. Carta de proyectos de TI

¿Quiere una fórmula para la disfunción empresarial/TI? Defina proyectos en términos de entrega de software para que el trabajo de TI se realice cuando el software satisfaga los requisitos y cumpla con las especificaciones.

De esa manera, cuando la gerencia empresarial se queje de que el software no hace lo que necesitan que haga, usted está en una posición perfecta para argumentar que hace exactamente lo que se supone que debe hacer, porque cumple con las especificaciones, ¿no es así? Y si eso falla y el proyecto no cumple con los requisitos, entonces puede argumentar que los requisitos eran incorrectos. ¿Y de quién es la culpa? De los gerentes de negocios que los aprobaron, por supuesto.

O bien, podría hacer lo que funciona: comenzando con la forma en que nombra sus proyectos, defina cada uno en términos de resultados comerciales (“aumentar la efectividad de las ventas”), no en términos de software (“implementar Salesforce.com”, por ejemplo).

7. Asignar patrocinadores del proyecto

Es bien sabido que cada proyecto debe tener un patrocinador comercial o tiene pocas posibilidades de éxito. Pero, ¿quiere asegurarse de que un proyecto fracase? Asígnele uno.

Los patrocinadores, patrocinadores reales, y no los “patrocinadores sólo de nombre”), quieren que su proyecto tenga éxito en lo profundo de sus entrañas. Están dispuestos a asumir riesgos si es necesario para asegurarse de que sus proyectos tengan éxito, y arriesgan sus nombres y reputaciones con respecto a los beneficios comerciales de sus proyectos. ¿Cree que alguien que ha sido asignado para ser patrocinador hará esas cosas? Yo tampoco.

8. Establezca una estrategia de computación en la nube

Esta es una manera maravillosa de garantizar fallas de TI: establezca una estrategia de computación en la nube. De esa manera puede asumir la conclusión. Sabe que debe estar en la nube, por lo que el propósito de la estrategia es hacerlo realidad.

Haga lo que haga, no piense más que eso. No considere una arquitectura técnica administrada, definida en términos de servicios. Después de todo, hacerlo podría llevarlo a creer que los servicios son lo que necesita y que la nube podría ser una forma de proporcionar algunos de ellos.

Es una vieja regla: la forma sigue a la función. Los servicios son las funciones. La nube es una forma que podrían tomar algunos de sus servicios necesarios. Evite pensar de esa manera, a menos que desee que TI tenga éxito. Entonces es obligatorio.

9. Sea ágil. 

Las metodologías ágiles tienen mucho a su favor. Un requisito previo para el éxito es un alto nivel de participación informal del usuario, de modo que las correcciones de curso sean frecuentes y pequeñas, los desarrolladores vean el progreso todos los días y las pruebas de aceptación del usuario ocurran a diario.

Offshore tiene una cosa a su favor: un menor costo de mano de obra por hora. Lo que no tiene a su favor es ninguna posibilidad del alto nivel de participación informal del usuario del que depende Agile. Combine una diferencia de 12 zonas horarias, barreras de idioma, un abismo cultural e interacciones limitadas a lo que se puede manejar con conferencias web, y verá que Agile es bastante desafiante.

Es posible hacer que funcione, pero no es para los débiles de corazón, y ciertamente no lo es para las organizaciones de TI que son principiantes en Agile.

10. Interrumpir las interrupciones con interrupciones

El siguiente paso para asegurar el fracaso de TI es insistir en que todos realicen varias tareas a la vez. Después de todo, es una habilidad muy deseable, ¿verdad? Esto significa reducir la productividad y la calidad al tiempo que aumenta el estrés en el intento de hacer más.

Cada vez que sienta la tentación de pedirle a alguien que deje de hacer lo que está haciendo para trabajar en otra cosa, recuerde: los humanos no realizan múltiples tareas. Lo mejor que pueden hacer es ir y venir de una tarea a otra. Cada vez que lo hacen, pierden el tiempo cambiando de marcha mental, y cuanto más concentración requiere una tarea, más tiempo pierden cuando tienen que hacerlo.

¿Quiere que TI tenga éxito en su lugar? Deje que las personas terminen lo que están trabajando antes de pasar a otra cosa.

11. Haz malabarismos con muchos proyectos

TI nunca tiene suficiente personal para manejar todo lo que todos quieren, por lo que tiene sentido hacer todo lo posible para entregarlo de todos modos lanzando muchos proyectos y moviendo empleados de un lado a otro entre ellos.

Es decir, si desea que todos los proyectos tomen mucho más tiempo, cuesten mucho más y brinden resultados por debajo del estándar.

Si desea que TI desarrolle una buena reputación, establezca esta regla: cada proyecto que se lance contará con todo el personal, y “con todo el personal” significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Haga esto, y cada proyecto terminará antes de que cualquier proyecto hubiera terminado si hubiera seguido haciendo malabarismos con todos.

12. Terminar con la ‘sombra TI’

No hay duda de que cuando los departamentos comerciales implementan su propia TI, pueden suceder cosas malas. Ese podría parecer un argumento convincente, pero solo cuenta un tercio de la historia. El segundo tercio: los departamentos comerciales se involucran en esfuerzos de combinación porque TI no tiene suficiente personal para resolver los (generalmente) problemas de pequeñas empresas que asume TI en la sombra. Lo que coloca a TI en la incómoda posición de obligar a los departamentos comerciales a hacer todo en Excel, incluso cuando hay alternativas superiores disponibles.

Ese es el segundo tercio. ¿El tercero? Buena suerte tratando de acabar con Shadow IT. Es terriblemente difícil incluso detectar el uso comercial de aplicaciones basadas en la nube. 

13. Diga “no” o “sí” sin importar la solicitud

La última y mejor manera de garantizar la falla de TI es decir “no” o “sí” sin importar la solicitud. Diga no, y dañará sus relaciones. Diga que sí, y estará haciendo promesas que no puede cumplir porque usted y todos los demás ya tienen su tiempo totalmente contabilizado.

La respuesta correcta si desea tener éxito es: “Podemos hacer eso. Esto es lo que se necesitará”.

Hay una regla inviolable de gestión de solicitudes, ya sea que la solicitud sea un cambio en el alcance del proyecto, una mejora de software o proporcionar una computadora portátil a alguien que no está programado para recibir una: nunca y nada serán gratis.

No diga que no. No diga que sí. Explique lo que tendrá que hacer para satisfacer las solicitudes. Lo que sigue será una conversación más que una discusión.

Mucho mejor.

Bob Lewis, CIO.com