Esta entrada es una traducción de la columna original de Michael Krigsman «CIO Analysis: Why 37 percent of Projects fail» publicada en su blog IT Project Failures, la traducción ha sido realizada con expreso permiso de su autor.
Una nueva investigación identifica cinco razones importantes por la cuales fracasan los proyectos de TI.
Un estudio realizado por la empresa de consultoría de gestión de proyectos, PM Solutions, identifica las causas principales de las fallas de TI.
El informe, denominado Strategies for Project Recovery (PDF), abarca 163 empresas proporcionalmente divididas entre organizaciones pequeñas, medianas y grandes. En promedio, los encuestados gestionan $ 200 millones en proyectos cada año, de los cuales aproximadamente el 37 por ciento están «en riesgo». La empresa promedio en el estudio por lo tanto se enfrenta a «riesgos de» $ 74 millones «en peligro» en los proyectos de cada año.
El estudio identifica cinco causas principales de los proyectos con problemas:
- Requerimientos: No son claros, falta de acuerdo, falta de prioridad, contradictorios, ambiguos, imprecisos.
- Recursos: Falta de recursos, conflictos por los recursos, rotación de personal clave, mala planificación.
- Cronogramas: Demasiado apretados, poco realistas, demasiado optimistas.
- Planificación: En base a datos insuficientes, falta de elementos, estimaciones pobres.
- Riesgos: no identificados o supuestos, no se gestionan.
Según la encuesta, los obstáculos más comunes que interfieren con la recuperación de los proyectos son las siguientes:
- Conseguir la aceptación de las partes interesadas para aceptar los cambios necesarios para poner en marcha nuevamente los proyectos, ya sean cambios en el alcance, presupuesto, recursos, etc.
- Pobre comunicación y compromiso de los interesados, falta de claridad y confianza.
- Conflicto de prioridades y política.
- Encontrar los recursos calificados suficientes y necesarios para completar los proyectos.
- Falta de un proceso o metodología para ayudar a poner en marcha nuevamente el proyecto.
ANÁLISIS ESTRATÉGICO
Este estudio es útil, pero no revolucionario, sino que arroja luz sobre un problema común, reafirma las creencias existentes sobre las causas de las fallas, y llama la atención sobre cuestiones importantes.
La tasa de 37 por ciento de fracaso es notable porque se inscribe en la gama más amplia de estadísticas (de treinta a setenta por ciento) que informan la mayoría de los estudios, a pesar de que es un número sorprendente bajo. El presente informe no se centró en las tasas de fracaso, sino que hizo hincapié en la recuperación de proyectos, que podrían haber afectado a los resultados específicos.
Las tasas de fracaso son muy difíciles de medir y prácticamente imposibles de comparar a través de múltiples estudios por diferentes investigadores. Por lo tanto, tenga en cuenta las tasas específicas de fracaso como sugieren los problemas y la magnitud relativa de la gravedad; las estadísticas de fracaso no son indicadores absolutos.
Sin embargo, es increíble considerar que más de un tercio de los proyectos en este estudio son propensos a tener graves problemas. El impacto financiero de estas fallas es importante y significativo, por decir lo menos.
Es fácil dejar de lado las cinco causas de fracaso antes mencionadas, pensando que no ofrecen nada nuevo. Sin embargo, tales puntos de vista superficiales, no ayudan a resolver el problema. Es mucho mejor reconocer el reto y la dificultad de alinear las expectativas y percepciones a través de un conjunto diverso de partes interesadas, que es un obstáculo fundamental para el éxito del proyecto. Es por eso que este blog habla de gestión del cambio con tanta frecuencia.
Perspectiva del CIO: Reconocer la realidad de los riesgos del proyecto – las vulnerabilidades de las llamadas fuentes «obvias» representan un peligro claro y presente para su organización. Para abordar estos riesgos inherentes, desarrollar mejores métodos para la comunicación, la colaboración y el intercambio de información a través de los silos y los departamentos, tanto en el interior de su organización como con socios externos.
Además, tenga en cuenta los métodos para hacer que sus proyectos sean más adaptativos. En muchos proyectos, la toma de decisiones es una función de pasos, donde se recopila información durante un período relativamente largo que culmina en la revisión y análisis periódicos. Reduzca los tiempos del ciclo de decisión para mantener sus proyectos a las condiciones cambiantes y los requisitos.
Resolver el problema de las fallas de TI es difícil, precisamente porque no hay ni una bala de plata, ni un objetivo claro al que apuntar. Los CIO con visión de futuro reconocen estas realidades e innovan mediante la creación de una campaña de base amplia y a largo plazo para asegurar que los resultados de los proyectos se alinean con los intereses de la organización.
Gestión de Valor Inversiones en Tecnología 
Estimados,
De mi experiencia personal, estoy en total acuerdo con los factores de fracaso identificados, como la falta de claridad y acuerdo en los Requerimientos, el staffing de Recursos de los Proyectos, los Cronogramas más «volutariosos», que realistas, la baja precisión en las estimaciones para la Planificación adecuada y la insuficiente gestión de Riesgos.
Adicionalmente, agregaría dos factores muy críticos para el éxito de los Proyectos, que no se ejecutan efectivamente en los Proyectos, que son los siguientes :
SPONSOREO EJECUTIVO – Contar con un fuerte Sponsoreo Ejecutivo del lado del Cliente/Organización que promueve el cambio.
CHANGE MANAGEMENT – Contar con una eficiente y oportuna Administración y Gestión del Cambio.
Saludos a todos, mis felicitaciones por el Blog,
Carlos
Me gustaMe gusta
Hola Carlos, gracias por tu comentario y palabras 🙂 saludos
Me gustaMe gusta
Carlos y Oscar,
Además de expresar mi absoluto acuerdo con sus comentarios, les quiero comentar que esta situación es muy real y deberíamos de pasar al ¿cómo aplicar las acciones correctivas y preventivas a nivel factor humano, estándares y metodología mientras la operación del negocio continúa?
Conocemos el problema y sabemos qué medidas tomar para resolverlo, ahora cómo le hacemos mientras los proyectos se siguen acumulando y la presión de entrega se incrementa?
Considero que respondiendo a esta pregunta podemos romper el círculo vicioso.
Saludos,
Me gustaMe gusta
Buenas noches a todos
Estoy totalmente de acuerdo con tu punto de vista Oscar acerca de las personas involucradas en el proyecto porque cuando una persona tiene sentido de la propiedad esta persona se esfuerza cada día más por llevar a cabo con éxito el proyecto que está en desarrollo pero al toparse con situaciones en la que se siente rechazada, que su esfuerzo o interés no es tomado en cuenta cae en un estado de depresión que lo único que consigue es disminuir el rendimiento en el trabajo o limitar la actividad vital habitual de la persona provocando perdida de interés en el proyecto, desinterés que puede ser transmitido a otros participantes en el proyecto llevándolo al fracaso.
Me gustaMe gusta
Pingback: CIO analysis: Why 37 percent of projects fail | ZDNet
Buenos días y gracias Carlos por seguir provocándonos con tus acertados artículos.
Nada sorpresivo como comentas los resultados de este estudio ni lo smotivos esgrimidos tampoco me sorpenden, lo cual me preocupa, estamos acabando en una actitud demasiado hierática e inerte.
En mi opinión la clave de los fracasos de un proyecto, salvando todo lo dicho ya por el estudio son 3:
Equipo de proyecto. Las personas, todas, conciben un proyecto como algo temporal, con principio y fin y que por tanto no debe quitarles de su quehacer diario. Una involucración al máximo les dejaría vacíos a medio plazo. Además en las funciones y en el organigrama ese rol nunca aparece, salvo que seas una emprea muy volcada a consultoría y demás ni tampoco aparece en los planes de gestión del desempeño, tampoco se llegan a definir claramente los roles y funcinoes dentro del proyecto, todo queda muy disipado. Todo esto implica poca involucración, si hay alguien que se involucra mucho, parece que es porque no tiene mucho trabajo en su día a día ordinario y está ahí para rellenar, luego están los otros, los que dan la sensación de ultrasaturados cuando no lo están o sí, porque están con otros mil asuntos de mayor presupuesto en juego. Esta tendencia a la desparición provoca desánimo en el resto del grupo y falta de compromiso por una relación que total, siempre tiene un final, acabar muriendo a la tarea, un proyecto acabado no es sino un fardo de tareas nuevas a mantener.
El segundo gran problema creo que es de metodología de proyecto a nivel corporativo. Está claro que las planificaciones, hasta las de los gobiernos, tienen unas desviaciones en tiempo y presupuestarias tremendas, lo que les resta credibilidad y legitimidad para nada y que te seduce a la anarquía en la gestión y a la improvisación. Todavía hoy día mucha gente piensa que el tiempo dedicado a escribir, documentar y planificar es una pérdida de tiempo, lejos de la frase»el tiempo de la reflexion es una economía de tiempo -Publio Siro». A todo esto hay que añadir que tampoco hay unos procesos de formación interna que centre el foco en el más allá del día a dia técnico de programación, donde estan los cursos de gestión de equipos y persona más allá que a 4 directivos? Luego pretendemos que meter a 3 tios muy motivados en un proyecto sea clave de éxito. La motivación no lo es todo, la preparación también es un punto clave. Una gestión de conocimiento corporativa en cuanto a lecciones aprendidas o qué fue mal en otro proyecto desarrollado por la empresa también es otro punto a mejorar.
Usabilidad a posteriori. También quiero hablar de algo que no suele hacerse y es el post-proyecto en cuanto a usabilidad, en proyectos de desarrollo de sw, a menudo pasa que un sw solicitado luego apenas se utiliza en su décima parte, funcionalidades y mucho tiempo tirado a la basura, pese a que el proyecto haya sido un éxito. Esto es como los árbitros en futbol, un buen proyecto es aquel del que no se habla finalizado el partido, pero tampoco hay que olvidarse de que el partido se disputó. Sólo un dato, he analizado el % de programas de nuestra base de datos compuesta por más de 42000 que han sido visualizados al menos 1 vez, y apenas un 48% se ha utilizado en estos 3 últimos años. Os invito a hacer esta investigación en vuestras compañías.Quizá habría que redefinir la palabra éxito en un proyecto.
y como dice el articulo, soy proclive a tiempos cortos, a springs tipo Scrum, si das largos periodos de tiempo, el proyecto se disipa en el día a día, pierde consistencia. Sin ir más lejos, en mi empresa pasó que se desarrollo un sw se dio a testear al usuario «filosofía ahora la pelota esta en su tejado», el programador al ver que no se respondía nada creía que el sw estaba bastante bien y cuando pasado un mes llegamos a fase de implantar, se le da un toque al usuario y resulta que no había probado nada hasta la fecha, se había ido de vacaciones entre otras cosas. Las incidencias siempre surgen el día de antes, todo va mal justo el dia de antes, porque todo se prueba justo el día de antes! Habría que meter más de un auditor o externo de por medio en muchos proyectos.
En resumen, el problema está ahí y seguirá, diremos a negocio que garantizamos el exito en 2 de cada 3 proyectos y ya está. negocio hace lo mismo en sus otros proyectos con otros departamentos. Es un dato que está en la media y con esta percepción, jamás cambiaremos.
Me gustaMe gusta
Hola Oscar, gracias por compartir tus pensamientos.
En tu resumen creo que tenemos un punto fundamental del por qué fallan tanto los proyectos, la actitud de las personas, podemos nombrar y seguir hablando de muchos temas del motivo de las fallas, pero siempre vamos a llegar a uno indiscutido, la actitud de las personas y la gestión del comportamiento humano.
Personalmente estoy cada día más convencido que un proyecto finalmente se trata de gestionar las expectativas y el comportamiento de las personas, solo gestionando este aspecto me parece que podremos cambiar la percepción.
Saludos
Me gustaMe gusta