Si Aquiles hubiese sido CIO, el autoengaño serÃa su talón. EstarÃa seguro de que la alineación del negocio-TI está ajustada, la seguridad de la información es a prueba de balas, y todos los proyectos culminan a tiempo.
Por: Bob Lewis
Cio.com
SÃ: los CIO preparan el escenario para el desastre engañándose a sà mismos.
“Oh, qué enmarañada red tejemos la primera vez que la práctica de engañar”, decÃa el novelista escocés Walter Scott.
Pero no importa lo enredado de la red cuando alguien más es el objetivo, pero no tiene nada de lÃo lo que sucede cuando nos estamos engañando a nosotros mismos.
Y nos engañamos a nosotros mismos no porque – deliberadamente – queramos:
• Establecer las prioridades equivocadas.
• Tomar las decisiones equivocadas. Perseguir los objetivos equivocados.
Por supuesto, no es eso sino que la ilusión es mucho más fácil que mirar el mundo.
Veamos aquà (SÓLO) TRES (03) de las situaciones comunes en las que los CIOs le mienten no al personal de TI o a sus colegas del negocio, sino a ellos mismos.
Auto-engaño de CIO #1: Estamos alineados con el negocio
“Alinear la TI con el negocio” suena tanto como una gran cosa para hacer que muchos CIOs instituyen elaborados procesos de gobierno de TI para asegurarse de que suceda.
Es una pena que pocas empresas de cualquier tamaño estén alineadas con ellas mismas.
Alinearse con el negocio generalmente se reduce a aplacar a los jugadores de poder polÃtico o instituir un sistema de reintegro.
Devoluciones. SÃ, devoluciones. Es IT como manitas: Le daremos todo lo que usted pide, siempre y cuando financie el proyecto.
Con las devoluciones de cargo, es posible que la TI no esté alineada con el negocio pero está alineada con el presupuesto de la empresa.
Si eso se alinea con el negocio, todo es buen. Y, si no lo hace, bueno, es problema de otra persona.
Auto-engaño de CIO #2: La única razón para actualizar el software es cuando una nueva versión proporciona un valor comercial importante
Este no sólo suena convincente: suena ejecutivo.
Un CIO que hace esto está claramente centrado en el negocio (y alineándolo con él) y no puede ser acusado de gastar en tecnologÃa por el bien de la tecnologÃa.
Aún mejor, el presupuesto de TI puede reducirse porque no tiene que cubrir el costo de mantener las cosas al dÃa.
Los CIOs que se comportan como señalamos en este punto, sin embargo, nunca han sobrevivido a un salto de varias tecnologÃas para obtener mejoras pero son un éxito en culpar cuando comienza el lÃo.
Las actualizaciones de software son mantenimiento preventivo: usted lo paga ahora o lo paga más adelante.
Más tarde – siempre – es un número más grande.
Auto-engaño de CIO #3: ¿El gran proyecto de misión crÃtica que está retrasado? Nos pondremos al dÃa en la siguiente fase y lo entregaremos a tiempo
Aquà está la progresión habitual:
Caso de negocio: Es delgada. Asà que cualquiera que sea la idea de este incipiente desastre es lo que los gerentes han hecho desde antes de que se inventaran las hojas de cálculo: se mueven y giran hasta que el ROI supera la tasa de obstáculos, convenciéndose de que sus suposiciones revisadas son todavÃa, si no totalmente razonables, al menos tienen un fuerte viento de cola.
Requisitos y especificaciones: La estimación de la fase de requisitos y especificaciones es un lÃo.
Cuanto más grande es el proyecto, más incógnitas se esconden. Cada una de ellas complica más las cosas.
La fase de requisitos y especificaciones siempre es larga, pero está bien.
Todo el mundo sabe que cuando el diseño es más profundo, menos tiempo se necesita para la codificación y las pruebas.
Entonces lo inventaremos.
Planificación: TI alineada con el negocio y todo, planificación va de derecha a izquierda, comenzando con la fecha de entrega y trabajando a cualquier horario podrán conseguir este objetivo.
Esta vez es el director del proyecto quien, en la desesperación, toca el violÃn y el twiddles hasta que el programa parece plausible, siempre y cuando nadie lo mire demasiado de cerca.
No lo harán: les dice lo que quieren oÃr.
Amarillo: Es el estado del proyecto, también conocido como retraso sin posibilidad de salvación pero con el tiempo suficiente antes de la fecha lÃmite para que la negación todavÃa reemplace a la realidad.
Los directores de proyecto toman dos acciones cuando un proyecto alcanza esta etapa.
Primero, exprimen las pruebas. Esto pone tanto el proyecto como el cutis del equipo en verde.
Segundo, comienzan una búsqueda de empleo antes de que el proyecto acabe con su reputación.
El nivel uno de prueba: Con estándares lo suficientemente laxos y suficiente influencia polÃtica, incluso el peor código puede llegar a la producción.
El nivel dos de pruebas: También conocido como PROD. Siempre prueba, y prueba a fondo.
La única pregunta es si se realizaron pruebas exhaustivas antes o después de que el software entrara en producción.
Fuera de los carriles: El nuevo CIO detiene el choque de trenes. Su predecesor culpa al director del proyecto.
El director del proyecto asiste a las reuniones del PMI de la misma manera que los que tienen problemas con el alcohol van a AA.
¿Quieres una lÃnea final para todo esto? Aquà está: si estás seguro – sobre cualquier cosa – es muy probable que estés equivocado.
Si usted es un CIO y está seguro acerca de cualquiera de estos temas – o, para el caso, cualquier otro – hágase esta simple pregunta: ¿Por qué?