Cinco razones por que cancelan los proyectos de TI
Un reciente estudio señaló las 5 principales razones por la que expertos en el área de TI han cancelado proyectos antes de su terminación. Veamos estas cinco razones
—————————————————————————————————————
Una encuesta entre expertos en TI reveló que el 43% de las organizaciones donde trabajan han recientemente cesado un proyecto de TI. Este estudio conducido por la ISACA, un grupo gubernamental de TI independiente, resaltó las 5 razones principales por las cuales los proyectos son cancelados antes de que se completen.
He aquí la lista, con comentarios en cada una:
1. Las necesidades de negocio cambiaron: 30%
Hay muchas condiciones y situaciones donde el negocio legítimamente cambia sus requerimientos luego de comenzar un proyecto. Si el proyecto ya no provee de un valor significativo, entonces es mejor dejar de tirar dinero bueno luego del mal.
Por otro lado, algunas organizaciones deliberadamente obscurecen los requerimientos viciados al decir que los requerimientos de negocio han evolucionado. Obviamente, ,esto no es sano y es una verdadera indicación de un fracaso.
2. No entregó lo que se prometió: 23%
Esta es un problema típico de expectativas: promete lo que sea para obtener los recursos y preocúpate mas tarde de las consecuencias. Los administradores con poca visión, no se dan cuenta que el fondeo es menos importante que el entregar un valor sustantivo. El fracaso es inevitable cuanto los administradores no identifican claramente y entregan el valor al negocio.
En algunos casos, el proyecto en realidad si proveía de valor, pero la organización no lo reconoció debido a problemas de comunicación. En una entrada reciente aquí, se explica mas a detalle este asunto:
Muchas organizaciones dan por hecho a su CIO cuando el departamento de TI consistentemente entrega los beneficios sin cacareo o atención; tristemente, este error humano es muy común. En ese caso las relaciones públicas son una buena idea, especialmente si el CIO no es un gran comunicador. Claro esta, que el CIO debería mejorar sus habilidades de comunicación, pero eso es otra historia.
3. El proyecto dejó de ser una prioridad: 14%
Si la organización cambio de dirección sin una buena razón, haciendo que el proyecto sea superfluo, el proyecto estratégico viciado fue el problema. Sin embargo, si los requerimientos de negocio cambiaron por una buena razón, como se sugiere en el punto uno, no es necesariamente un problema.
En general, este es un punto obvio, cancelar los proyectos sin una buena razón es una señal definitiva de fracaso.
4. El proyecto se salió del presupuesto: 13%
Por encima, los proyecto sobre-presupuestados son la premisa básica del fracaso. De hecho estoy sorprendido que este número no sea más elevado, por que el costo no anticipado siempre es una bandera roja de alarma.
Al mismo tiempo, algunos proyectos se salen del presupuesto debido a incrementos de alcance inteligentes que proveen de valor adiciona. Por ejemplo, mientras se automatiza dos departamentos, el equipo del proyecto se da cuenta que puede integrar a un tercer departamento por solo un costo marginal. En esos casos, seguir adelante es probablemente la mejor decisión a tomar, aunque el costo aumente.
Aunque el pretender usar el desempeño presupuestal como una medida métrica de éxito o fracaso es tentador, este enfoque puede ser sobre-simplista y se pueden ignorar matices importantes relacionados con el valor del negocio. Sin embargo, cuando sea que el proyecto se sale del presupuesto el equipo debe ofrecer una explicación detallada.
5. El proyecto no se alineó a la estrategia de negocio: 7%
Este indicador clásico de fracaso sugiere que el proyecto fue enraizado en un análisis pobre de los requerimientos. Sin embargo, al igual que los puntos anteriores, es también posible que las necesidades del negocio hayan cambiado lo que provoca que el proyecto se haya hecho obsoleto.
=====
Esta encuesta es muy interesante al resaltar las principales razones relacionadas con los fracasos de los proyectos. Sin embargo, algunas de las preguntas son demasiado ambiguas como para que puedan proveer de conclusiones simples. En general, el comprender si el proyecto fue un éxito requiere examinar el ambiente del negocio y el contexto.
Fuente Original [TechRepublic]
