fractal
El Informe del Caos o Chaos Report se publica anualmente para informarnos de como de bien o mal se desarrollan los proyectos. Vamos a ver los resultados del año pasado para ver que grado de éxito en gestión de proyectos alcanzamos.
El informe del Caos viene siendo publicado por Standish group desde 1994 dando una visión sobre el fracaso o éxito de los proyectos.
En el informe del año 2015 han estudiado unos 50.000 proyectos de todo el mundo desde mantenimientos pequeños hasta gigantescos proyectos de reingeniería.
En esta edición se ha modificado la definición de éxito de un proyecto. En lugar de tomar éxito de un proyecto al cumplimiento del triangulo de las tres restricciones: alcance, presupuesto y plazos, la nueva definición de éxito es el cumplimiento de los plazos, del presupuesto y, además, se obtienen resultados satisfactorios (no tiene porqué cumplirse el alcance).
El siguiente gráfico es interactivo te puedes posicionar encima de los sectores para ver la información de cada uno. Dicho gráfico muestra el porcentaje de éxito o fracaso de los proyectos en 2015.
El primer resultado es muy interesante algo más de la cuarta parte de los proyectos fueron exitosos. Poco, ¿no?
Comparemos los datos de este año con los datos de proyectos de años anteriores.
En este nuevo gráfico, que también es interactivo, vas a poder ver los datos calculados en el informe del caos (Chaos report) para los últimos 5 años. Para facilitar la comparación te muestro en 3 series distintas los proyectos exitosos, proyectos discutidos y proyectos fallidos.
Lo primero que me sorprende de esta comparativa, que debemos puntualizar que es del total de proyectos, es que no hay ninguna tendencia en el éxito de los proyectos ni sube ni baja sino que se muestra oscilante sobre los mismos valores: el éxito entorno el 29% y el fracaso entorno al 19%. Los discutidos entorno al 50%.
Es interesante este dato porque parece que no hay mucha influencia ni de metodologías, ciclos de vida, etc. parece que hay otros factores que afectan al éxito o fracaso de los proyectos. Según un estudio del PMI que publicamos el año pasado, ellos también apuntaban en ese sentido Esta es la Clave del Fracaso de tu Proyecto ¡Evítala!.
¿Tendrá que ver el tamaño?
Buscando algún patrón para determinar como maximizar el éxito de los proyectos y minimizar el fracaso, dentro del Chaos Report se muestran estos porcentajes segmentados por el tamaño de los proyectos.
El resultado es claro y puedo decir incluso que esperado.
Es una sensación que solemos tener de que si el proyecto es pequeño tiene más probabilidades de éxito. Cuando un proyecto es pequeño es más fácil de controlar, de manejar, de dirigir y, por tanto, más probable de conseguir el éxito.
Este dato que mostramos en los sectores es el dato agregado de los proyectos exitosos desde 2011 a 2015. El dato es demoledor y confirma todas nuestras espectativas: más del 62% de los proyectos exitosos eran pequeños.
Está claro que los proyectos grandes son exponencialmente más complejos que los proyectos pequeños y los proyectos gigantes son el acabose.
Una importante lección a aprender:
Podríamos decir esa manida frase de Divide y Vencerás, pero no por manida deja de ser menos cierta.
Otra comparativa interesante que nos ofrecen desde el Chaos report es la comparativa del éxito de los proyectos en función de la metodología seguida para su desarrollo: ágil vs predictiva.
Realmente la comparación que nos indica es ágil vs cascada aunque metodologías predictivias hay muchas otras.
Al revisar los datos ten en cuenta que hay muchos más proyectos en cascada que ágiles y que el dato que se muestra es relativo, es decir la muestra en ambos casos tiene distinto tamaño, por lo que puede ser un poco engañoso.
Aún así, por los datos presentados, los proyectos ágiles son mucho más éxitos que los no ágiles.
Mira tu mismo o tu misma la gráfica interactiva.
Si ahora desglosamos los proyectos no sólo por metodología si no además por tamaño, el dato obtenido es realmente interesante:
Aquí la diferencia no es tan grande pero es evidente. Los proyectos ágiles siguen siendo los más exitosos aunque por un margen menor.
Ahora bien cuando subimos en tamaño hacia proyectos grandes la diferencia se vuelve mucho más grande.
¿A quién no le entra miedo de dirigir un proyecto grande?
Con estos datos puede que la metodología en sí no sea el único motivo para la mejora del éxito de los proyectos sino que como comentaba antes, si dividimos nuestro problema en partes más manejables, más pequeñas y lo vamos haciendo poco a poco será más sencillo tener éxito.
Habrá que seguir estudiando esta hipótesis.
¿Qué dato te ha llamado más la atención?
Fuente de los datos: Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch
Este año ha sido complicado. En el sentido de que ha sido un año duro.…
Y el año se acaba. Después de tantos días juntos en este blog hoy llegamos…
Las compañías energéticas están en el ojo del huracán con los precios que estamos sufriendo…
Sin duda hay una creencia muy extendida que piensa que las cosas se consiguen porque…
El Haiku de hoy de Taylor Swift me encanta. Resume perfectamente lo que no debes…
Las ideas innovadoras siempre son interesantes para que nos puedan inspirar. Si además ayudan a…
View Comments
Definitivamente, la gestión de proyectos acertada deberá ser entonces una combinación de las dos metodologías en proyectos cada vez mas pequeños
Creo que la división de proyectos en trozos "manejables" es definitivamente el primer enfoque estratégico que debería hacerse. Lo tengo claro. Y también me parecen definitivos en el éxito de los proyectos los Equipos humanos. Por eso echo muy en falta en la comparativa la relación respecto a la estructura organizacional donde se llevan a cabo. Quizás que se mantenga el grado de exito-fracaso casi lineal a lo largo de los años esté también relacionado con las estructuras organizacionales que seguro se han mantenido sin cambios. ¿Podría ser?
En cualquier caso la libertad de elegir procesos ágiles o en cascada, o ambos, debería existir, para pudieran ser implementados de forma eficiente acorde a los recursos disponibles y el tipo-tamaño de proyecto.
Un saludo
Excelente análisis, definitivamente debemos seguir el camino de las metodologías ágiles para no volver a gráficos como los del primer informe de caos, que eran para llorar.
Por lo menos debemos probar cosas distintas para intentar mejorar los resultados :)
Hola. Yo creo que la etapa de pruebas de usuarios no es planificada ni gestionada con la importancia que se merece. Si bien el PMI ha enfatizado que la toma de requerimientos es fundamental, con lo que concuerdo, también creo que las pruebas de usuarios son una etapa que también es fundamental, en la que, lamentablemente, los conflictos y los problemas de comunicación la llevan. La elaboración de la Estrategia de Pruebas y del correspondiente Plan de Pruebas, pasando previamente por el levantamiento de los casos de prueba del negocio (los usuarios no deben probar piezas de software sino validar el correcto soporte de su negocio en el software por lo que sus casos de prueba NO son los mismos que aplica un área de QA), son etapas a las que no se le da la importancia que merecen y por tanto, suelen no tener la dedicación del esfuerzo necesario; además, el control y gestión de las mismas se hace muchas veces "a mano", con correos electrónicos y excels, con innumerables problemas de comunicación entre TI y el negocio. Este paradigma debe cambiar y con ello, aumentará el éxito de los proyectos TI.
Correcto Carla, de hecho las metodologías ágiles proponen una solución a ambos problemas, usando las historias de usuario y el product backlog.
Yo considero que es mucho más complejo que simplemente pobres, débiles ciclos de pruebas, o incluso una mala orientación de las pruebas (a casos aislados de pruebas, y no a realizar pruebas integrales orientadas al negocio y a su afectación con otros módulos). Puede que un proyecto de desarrollo de software posea una robusta etapa de pruebas (indiferentemente de la metodología de desarrollo de software utilizada), pero si en dichas pruebas ocurren imponderables/sorpresas que resultan en procesos de rediseño y de desarrollo no contemplados o esperados, definitivamente, ya caes en la estadística del CHAOS Report de no cumplir con el Plazo Planificado. Puede que logres adecuar tu software luego de dichas pruebas, y que incluso logres el nuevo esquema de EXITO/LOGRO SATISFACTORIO que ahora pareciera más importante que el ALCANCE (tendríamos que analizar este aspecto en una industria como la del Sector Público en el que te contratan con un cartel de marras y el alcance está claramente delimitado, a veces muy en contra de ese Logro Satisfactorio o del propio Beneficio de la Institución Pública contratante), pero ya lo estarás realizando en un tiempo y quizás un presupuesto mucho mayor al inicialmente planificado o estimado (tu proyecto entonces podrá ser subjetivamente evaluado de fracaso o de DUDOSO, ni les cuento los desgastes de este tipo de situación en el SP por aspectos relacionados con el cobro a proveedores de las Garantías de Ejecución o los impactos económicos que significan los cobros de MULTAS por ATRASOS, SP es para mí la Grandes Ligas en el tema de Desarrollo de Software, no tanto por la complejidad técnica de sus modelos de negocio - existen industrias más complejas, como la petrolera por ejemplo, sino por lo complejo en sí de las Instituciones y el Manejo de las Leyes y Reglamentos de las Contrataciones Administrativas). Es por esa razón, que sigo considerando que lo afirmado por el PMI en relación al pobre proceso de Levantamiento de Información y de Entendimiento de Necesidades, es determinante. Todo importa es mi experiencia como Project Manager de este tipo de proyectos. Yo en lo personal, y luego de pasar de ser un Nobel Director de Proyectos, es decir, luego de pagar el consecuente noviciado en gestión de este tipo de proyectos, incorporo antes del desarrollo, un Modelado del Negocio, para luego pasar al Análisis, Diseño y Desarrollo del Sistema (y si que importan realizar dicho diseño y desarrollo bajo una metodología de Desarrollo Evolutiva , cualquiera que utilices), por que en mi experiencia personal, he llegado a la conclusión que el USUARIO FINAL, cree saber qué es lo que quiere en teoría, pero cuando uno suma EXPERTOS DEL NEGOCIO se abre un panorama de MEJORA de sus PROCESOS en su Cadena de Valor, y luego las Especificaciones y Requerimientos Detallados salen prácticamente sin mayor esfuerzo. Saben qué es difícil? Convencer a Jerarcas a que esta etapa previa (costosa/onerosa) se debe efectuar antes de iniciar a "echar la primera línea de código". Pruebas Importante? Importantísimo diría yo, pero el Levantamiento y Entendimiento de Necesidades es muy pero muy importante. Todo aquello que te asegure (o acorte la brecha) de tener que retroceder, es bienvenido!
Gracias por el aporte Dennys!
A mi parecer en lo posible es mejor dividir un proyecto en pequeños proyectos, por la facilidad de control, incluido en el mejor manejo del equipo del proyecto. Me llamó mucho la atención que los proyectos ágiles sean más exitosos que los predecibles.
La primera parte te doy la razón, porque es un hecho que cuanto más pequeño y menos incertidumbres hay y más manejables son los proyectos. En la segunda es una cuestión de satisfacción con el resultado y aquí ya hay un hecho difícil de cuantificar objetivamente. En los proyectos predictivos era fácil si seguíamos el triangulo de oro: alcance, costo y tiempo, pero en los ágiles depende de la satisfacción con el resultado final y ésta la determina la persona. Si la persona es honesta muy bien, pero como no lo sea... :)
El proceso de levantamiento de información, el entendimiento de necesidades, una buena estructura organizacional, una metodología de desarrollo evolutiva, y la división del proyecto en trozos “manejables” es definitivamente el primer enfoque estratégico que debería hacerse, con lo cual será más sencillo tener éxito.
Gracias Jorge por el aporte. Por lo menos será un buen punto de partida!
gracias por la info, pero me surge la duda de cómo sé qué es un proyecto pequeño, mediano, grande ???? gracias :)
Comentando este artículo, tiene mucha razón en que si es más pequeño mayor acogida tendrá por su menos complejidad, se me viene a la mente cuando eh realizado proyectos en ingeniería en software y basándome en este documento leído, logro entender que la mayoría de los proyectos escogidos tienen su secuencia de análisis, que separan ciertas cosas con su valor respectivo y sale e conclusión del mismo, además que se utiliza mucho en estos los modelos agiles que hasta incluso son los más escogidos entre varios proyectos que utilizan el modelo cascada, tienen una leve similitud pero cada uno es relacionado de acuerdo al desarrollo de su tema.
Creo que si se plantea un proyecto se debe considerar muchas cosas lo primordial creo yo que es el tiempo de desarrollo del proyecto.....por que se puede haber planteado actividades de desarrollo en las cuales se pudo o no haber realizado esa actividad entonces se tiene que volver a realizar un plan de organización y planeación del proyecto.
para realizar nuestros proyectos debemos direccionarnos y escoger bien la metodología para así tener un buen progreso en el mismo y culminarlo con éxito.