Llegamos a ustedes gracias a:



Reportajes y análisis

Once señales que indican que su proyecto está condenado

No hay aprobación, especificaciones mínimas de objetivos, una mentalidad que dice que 'nada puede salir mal' - así es como se detecta la desaparición antes de que su proyecto de TI cumpla su ignominioso final.

[13/09/2013] El mundo de las TI no es ajeno a los proyectos que arden en llamas. Cualquiera que haya tenido el placer poco envidiable de participar en un esfuerzo fallido de TI, probablemente notó su desaparición mucho antes de la fecha de entrada en funcionamiento. Ese sexto sentido es muy valioso en un campo tan competitivo como el de las TI.
Ya sea que esté buscando evitar ser arrastrado o limpiar un despliegue condenado a la zanja, debe reconocer los signos de una falla inminente, antes que un proyecto se parta en pedazos. Esto puede significar un ahorro.
Hemos reunido 11 banderas rojas que se deben detectar en la evaluación de la salud del proyecto de TI. Sea proactivo cuando encuentre una -o si se puede, simplemente apártese. Su carrera depende de ello.
Bandera Roja Nº 1: El proyecto se ha puesto en marcha sin mayor aprobación
Así es como suele ocurrir: una fuerte personalidad en la empresa tiene una idea "genial", y planea reuniones y asigna recursos sin esperar a saber si la alta dirección está de acuerdo. Muchos de estos proyectos proceden hasta el punto donde el dinero real debe ser gastado, entonces colapsan por completo. A menudo, todos los del proyecto, a excepción de su autor, no saben que el proyecto no ha sido aprobado, ni que el presupuesto no ha sido asignado.
Para evitar tener que cargar con un proyecto así, siempre pregunte quién está patrocinando el proyecto desde la alta dirección y cuál es el presupuesto asignado. No acepte respuestas que dicen que no se ha asignado ningún presupuesto, porque la gente no sabe lo que va a costar hasta que el proyecto esté en marcha.
Bandera Roja Nº 2: No existe un plan detallado del proyecto
El software de planificación de proyectos puede ser complejo y frustrante. Lo único que odio más que hacer la arquitectura de un plan detallado del proyecto es estar involucrado en un proyecto que no tiene uno. Los planes de proyectos formales obligan al director del proyecto a considerar todas las fases y pasos necesarios, y el orden en el que se debe proceder. Para parafrasear una línea muy citada: "El no planificar es planificar el fracaso".
Cualquier proyecto con un cronograma estimado de más de dos semanas debe tener un plan detallado del proyecto. Si le presentan un proyecto que no lo tiene, debe crear uno propio. Además de obligar a que todos consideren todas las tareas y tácticas, el hacerlo le obligará a llegar a un calendario realista. Un plan detallado del proyecto es mucho mejor que las "mejores conjeturas" o corazonadas.
Bandera Roja Nº 3: Las reuniones se han programado sin preocuparse por la disponibilidad de los miembros del equipo
Cuando un jefe de proyecto o equipo programa reuniones importantes arbitrariamente, que están en conflicto con otras reuniones importantes, ya programadas, sabe que el proyecto está destinado al fracaso. Hacerlo asegura que los miembros del equipo estarán ausentes, socavando así el propósito y la eficacia de la reunión.
La solución es simple: Tómese un tiempo antes de programar reuniones para conocer los calendarios de los asistentes importantes. Encuentre disponibilidades comunes y elija un intervalo de tiempo. No vaya demasiado lejos al permitir que los participantes voten -esto puede llevar a malos sentimientos de parte de aquellos cuyas propuestas de intervalos de tiempo fueron rechazadas. En cambio, sea autoritario y elija un horario en el que sepa que podrá contar con la presencia de todos. Ajústelo luego si fuera necesario. Además, conozca los horarios de las reuniones permanentes de los miembros de su equipo para que otros no programen la misma fecha y hora accidentalmente.
Bandera Roja Nº 4: Los usuarios han tenido poca (o ninguna) participación
A todo aquel que ha tomado aunque sea una pequeña clase de informática TI en la universidad se le ha enseñado los principios de participación de los usuarios al iniciar cualquier proyecto. Es por eso que es tan sorprendente ver proyectos grandes y complejos casi completos, antes que lo usuarios proporcionen asesoramiento. He visto muchos proyectos de gran evolución, que se descarrilan porque los usuarios dicen que los líderes no han hecho un determinado proceso, y que el nuevo proceso no funciona bien.
Asegúrese de que los usuarios reales, o sus defensores, sean invitados desde el primer momento. Mientras mayor participación tenga, mayor será su probabilidad de éxito. Si el proyecto abarca varios departamentos, asegúrese de contar con representantes de los usuarios de cada uno. Asegúrese también de que los usuarios sientan que pueden expresar su opinión real.
Bandera Roja Nº 5: El proyecto aborda especificaciones mínimas
Nada mata el éxito del proyecto como la compra del mínimo hardware.
Los vendedores son conocidos por tratar de mantener el costo de un proyecto mediante la subvaloración del hardware necesario para obtener los resultados óptimos. Los vendedores a menudo ofrecen un "mínimo" de especificaciones y la compra de hardware. Los jefes de proyecto inteligentes irán más allá incluso de las especificaciones de hardware recomendadas. Si pasa algo, al menos, los vendedores y los clientes no se señalaran con el dedo sobre las decisiones de compra de hardware. Además, asegúrese de que todo el hardware y software adquirido es compatible y probado con los demás. No querrá que los dedos le señalen si algo sale mal.
Bandera Roja Nº 6: La prueba es una idea de último momento
La prueba es esencial para el éxito del proyecto. Si se trata de pruebas unitarias (que ponen a prueba una de las facetas del sistema) o pruebas integradas (que ponen a prueba todos los componentes, incluidos los sistemas de interconexión existentes), deben ser realizadas por los empleados actuales, junto con un script de prueba. El script de prueba debe incluir todos los insumos, paso a paso, que los evaluadores deben tomar. Y debe detallar, a tiempo, cómo deben ser todas las salidas.
Los datos y procesos de prueba deben abarcar todos los escenarios, incluidos los datos buenos y malos. A veces los resultados de los malos datos conocidos son más interesantes que los de un resultado deseado. Las pruebas deben incluir pruebas de carga para ver cómo funciona el sistema y cómo responde la red bajo mucha utilización y quienes toman las pruebas deben entender los resultados esperados y esperar reportar todas las desviaciones.
Bandera Roja Nº 7: No hay un plan de recuperación en caso de una falla
Los planes no siempre salen como se espera. Cada jefe de proyecto tiene que saber cómo funciona en la vida real -y cuando es el momento de admitir el fracaso y empezar otro día. Cada proyecto debe tener un plan de copia de seguridad de entrada en funcionamiento en caso de que una falla se convierta en la única opción.
Demasiadas entradas en funcionamiento son impulsadas por la creencia de que "nada puede salir mal". Los líderes de estos proyectos a menudo no logran asegurarse de que se han hecho y verificado las copias de seguridad. No desarrollan protocolos para definir el éxito, ni describen lo que se ve como un fracaso antes de tiempo. Ellos no preparan al equipo para que sepa qué hacer en caso de un accidente de entrada en funcionamiento. Muchos proyectos totalmente nuevos golpean un obstáculo fatal solo para descubrir que no pueden ir hacia atrás.
Bandera Roja Nº 8: Las recomendaciones de los expertos han sido rechazadas sin probar los resultados
Hay personas que solicitan el asesoramiento de expertos y los escuchan, y luego elijen un camino diferente. Luego se quejan cuando algo no funciona bien.
No sea esa clase de persona. No deje que esa persona tome las decisiones importantes en su equipo. Está bien pedir el asesoramiento de expertos, solo para hacer algo diferente. A menudo es el signo de un buen líder. Simplemente no lo haga compulsivamente. Y si va en contra de las recomendaciones y las cosas no funcionan, no culpe al consultor.
Incluso si el vendedor o consultor se compromete con su desviación de su recomendación, asegúrese de que el cambio se ponga a prueba. Muchos proyectos han fracasado porque los líderes del proyecto "hicieron unos pequeños cambios" que los vendedores y consultores no aprobaron.
Bandera Roja Nº 9: La fecha de entrada en funcionamiento es un fin de semana o día de fiesta
Muchos líderes del proyecto planean iniciar sus eventos el fin de semana o los días de fiesta debido al menor riesgo de interrupción del servicio para los empleados o clientes. Aunque loable, estas ventanas también tienden a ser los momentos en que el soporte técnico es más difícil de encontrar. Es posible que tenga a su principal proveedor a la mano, pero el soporte técnico de terceros puede estar cerrado o de turno (y no devolverán las llamadas a tiempo), y lo mismo puede decirse de su equipo. Hablar con su mejor solucionador de problemas de base de datos mientras está de vacaciones con su familia, nunca es óptimo.
Bandera Roja Nº 10: No se han establecido las expectativas
Cuando un nuevo sistema va a reemplazar un sistema viejo, es útil que todo el mundo entienda las nuevas expectativas. ¿Cómo va a actuar el nuevo sistema? ¿Cómo son las diferentes transacciones y los tiempos de transacción? ¿A quién llamar en caso de que los usuarios finales tengan problemas? ¿En cuánto tiempo va a estar listo el equipo de solución de problemas de entrada? Un nuevo sistema siempre frustra a las personas, pero si establece expectativas realistas y le da a la gente opciones aceleradas de asistencia, los problemas tienden a desaparecer más rápido y termina con más clientes satisfechos en menor tiempo.
Bandera Roja Nº 11: Escatimar en la capacitación
No puedo decirle cuántos líderes de proyectos se robarán el presupuesto de capacitación cuando se enfrentan a un presupuesto rebalsado. Por lo general, es un líder presumido y muy listo que dice que el sistema es tan fácil que los usuarios no necesitan realmente todo el entrenamiento. Si oye, "Diablos, capacitaremos a cada persona con la mitad de las clases y ellos podrán entrenarse entre sí" o "Nuestros miembros son bastante buenos para averiguar las cosas, ya que pueden entender este nuevo sistema en unos pocos días", sabrá que está entrando al fracaso. No solo los usuarios necesitan capacitación, sino también los líderes del proyecto, los solucionadores de problemas y ayuda al personal de ayuda, también. Esté preparado para retrasar el proyecto si no se da la formación adecuada.
Roger A. Grimes, InfoWorld (EE.UU.)