Comportamiento de proyectos TI: Están en deuda!
¿Se imaginan que sólo el 32% de los proyectos inmobiliarios o de infraestructura fueran exitosos?
Hace unos días Mario Waissbluth me pidió unos datos sobre tasa de éxito/falla de proyectos tecnológicos en el Estado, o dicho de otra forma proyectos eGov, lo que me llevó a buscar entre mis cachureos, y me di cuenta que mis datos estaban un poco añejos, por lo que me puse a investigar nuevamente y llegué a números un poco más recientes, dicho sea de paso, creo que en Chile nos hace falta una investigación seria al respecto, todos los números que andan dando vuelta, tienen bastante de dígitos oscilantes, si sirve de consuelo los números que existen a nivel internacional tampoco hacen segmentación por industria o sector (público o privado).
El estudio más referenciado es el que realiza la consultora Standish Group, el cual es recurrente y existen datos desde 1994, que apareció por primera vez, estudio denominado Chaos Report. He escuchado algunas críticas a este informe, por ejemplo relacionadas con la definición de exitoso que es muy estricta, pero al menos sirve como referencia y además permite tener una evolución en el tiempo ya que es el único estudio que conozco que se realiza en forma periódica.
Antes de mirar esos números démosle una mirada a otras cifras que andan dando vuelta
- Chaos Report (1994) – 16.2% de los proyectos son exitosos. Del 70% de proyectos no exitosos, 52% corresponden a fallas parciales (expectativas, o tiempos o $)
- Encuesta OASIG (1995) – Las respuestas más optimistas sitúan la tasa de éxito entre 20% y 30%
- Encuesta KPMG Canada (1997) – 61% de los proyectos se consideran fracasados
- Encuesta Conference Board (2001) – 40% de los proyectos no cumplen expectativas de negocios, luego de un año en operación
- Encuesta Robbins-Gioia (2001) – 51% de las implementaciones de ERP son fallidas
- Encuesta Revista Dr. Dobb’s (2007) – 72% de los proyecto de desarrollo e implementación de Data Warehouse con metodologías ágiles, versus 63% con metodologías tradicionales.
Como se puede ver, todos los estudios coinciden en que la tasa de éxito de los proyectos es bastante baja, independiente de cual sea la definición de éxito se utilice. Al observar la evolución de las diferentes mediciones del Chaos Report de Standish como se aprecia en el siguiente gráfico, podemos apreciar un aumento de las tasas de éxito no demasiado significativa pero al menos con una curva positiva, esto se debe fundamentalmente a mejores prácticas de gestión de proyecto, tipo PMI u otros, uso de mejores herramientas y metodologías de desarrollo.
En el ámbito del Estado el comportamiento es incluso peor, según el estudio de eGovernment for Development de la Universidad de Manchester, sólo el 15% de los proyectos son considerados exitosos, la definición que utiliza eGov4Dev es:
Los principales stakeholders del proyecto dicen que se han logrado
los principales objetivos y no han experimentado resultados no
deseados significativos
En la gráfica se detalla el resultado de dicho estudio:
Sería interesante que las autoridades locales pudieran medir nuestro comportamiento, ya que si estamos en los mismos niveles, esto es, 35% totalmente fracasados (nunca se implementaron o abandonaron según definición del eGov4Dev) unos 100 millones de dólares del presupuesto de la nación van a dar a la basura.
Todos los estudios coinciden han las mismas causas de fracaso de los proyectos, las que se pueden resumir en:
- Especificaciones y requerimientos cambiantes o incompletos;
- Falta de involucramiento de usuarios
- Pocos conocimientos técnicos del equipo de proyecto
- Uso inadecuado de métodos y herramientas
- Expectativas poco realistasFalta se soporte gerencial
- Gestión de proyectos débil, lo que incluye no identificación de riesgos, falta de planificación, comunicación deficiente
Referencias
- Standish Group
- ProjectSmart
- The business end of IT project failure
- Why IT projects Fail, Al Niemat, Taimour
- eGovernment for Development, Universidad de Manchester
Alejandro:
copio una parte de un post mío de noviembre de 2006:
Robert L. Glass, en la edición de Agosto de 2005 de la famosa revista Communications of the ACM, bajo el título: «The Standish report: does it really describe a software crisis?» , se pregunta si este reporte, tan citado, realmente describe una crisis del software. Glass nos pide que reconsideremos la relevancia de este reporte.
En el reporte del Standish Group, publicado por primera vez en 1994, y con el título The CHAOS Chronicles, se establece las estadísticas más citadas sobre este tema, a saber: «el 49% de los proyectos termina en más tiempo y con más costo que el presupuestado. O el 23% de los proyectos se cancelan antes de terminar. Al grado que, según Glass, se ha perpetuado la idea de la crísis permanente del software.
Glass es un respetado experto en el área, lleva trabajando unos 45 años en la industria, es académico, y fue nombrado fellow de la ACM en 1998, ha escrito varios libros sobre el tema.
Glass hace una pregunta muy sencilla, ¿ cómo es posible que exista esta crisis en «una era que simplemente no podría ser posible si no fueramos tan existoso para hacer software que haga que los computadores hagan todas las maravillas que hacen?». Claramente hay algo que no le cuadra a Glass.
En el artículo de la ACM Glass explica como ha sido imposible obtener los datos del Standish Group, lo que se tiene son datos de 1994. Raramente se citan reportes que critican al Standish Report, un importantereporte de 2004 elaborado por el Simula Research Laboratory en Noruega cuestiona el hecho de que en 1994 el reporte Standish indicaba que los proyectos estaban excedidos en un 184% en tiempo y presupuesto, y que estas cifras han ido disminuyendo en los informes más recientes.
¿Es que las compañias han mejorado en su capacidad para estimar su desempeño? En su reporte, el grupo de Simula quiere establecer que seguir citando el Reporte Standish no sólo es cuestionable en su validez, sino que el continuo uso de sus resultados impide el progreso en el campo.
Leer más: http://www.lnds.net/2006/11/humanware.html#more#ixzz0bkQvBoJ1
Under Creative Commons License: Attribution Share Alike
Gracias Eduardo por los antecedentes, efectivamente he escuchado y leido varias de las críticas que se le hace al estudio del Standish Group, pero si miras otros números como los KPMG, eGov4Dev y otros que no han usado como base Standish ni tampoco su metodología, no son mucho mejores.
Por otra parte es interesante ver la evolución que muestra el mismo estudio de Standish, Glass no se hace cargo de esa evolución se análisis hasta donde lo conozco los hace sobre el informe de 1994, pero hay varios después
Este es un punto en que estoy en desacuerdo.
Nunca me he tragado eso de que la industria del software tiene una alta tasa de fracasos, al contrario.
Pero como el tema es apasionante, me voy a permitir debatirlo en un post.
Me gustaría saber la referencia a la Encuesta Revista Dr. Dobb’s (2007), tienes el link?
Saludos.
Además la comparación con la industria de la construcción es odiosa por que ya quisiera la industria TI tener los márgenes que manejan en esa industria, sus costos de mano de obra y adicionalmente contar con «inmobiliarias» que asuman los riesgos financieros.
Eduardo me parece bien que estemos en desacuerdo, creo que lo que flata en este tema es debate, análisis, estudio y datos duros.
Efectivamente el tema es apasionante, te pido mires el análisis de eGov4Dev (son un grupo de la Universidad de Manchester, no se trata de la consultora Jabón Copito Limitada), esta el link al final este es más lapidario aún, al menos en mi experiencia son pocos los proyectos que utilizando la definición de éxito de standish o de eGov4Dev, que uno puede discutir si es la correcta o no, no pasan la vara.
No tengo a mano el link te lo busco y te lo paso
Saludos
Ubaldo gracias por el comentario
Por supuesto que es odiosa, eso era lo que buscaba, pero si tu miras las rentabilidades de la industria del software «de verdad» no andan muy lejos. No te quedes con la comparación a nivel local te pido que la hagas en términos más globales. Tu crees que los riesgos financieros de los nuevos desarrollos en la industria del software global lo hacen las mismas empresas, me refiero a MS, Oracle, SAP y otros?
Saludos y bienvenido al debate
Gracias por la bienvenida, el debate y la discusión son mis deportes favoritos.
Si bien es cierto no conozco esos casos en particular, conozco algunos casos cercanos:
Borland en USA, efectivamente utilizaba capitales de riesgo.
En el caso de compañías Alemanas, Dermalog, Muehlbauer, Cognitec que trabajan en el área de biometria y documentos de identificación, gran parte del financiamiento en esos casos corre por cuenta de las propias compañías.
Sin embargo el utilizar estas compañías como parte de la argumentación parece no ser correcto porque ellas desarrollan productos y las estadísticas de fracaso hacen referencia fundamentalmente a «desarrollos a la medida». Muy interesante sería conocer el % de fracasos de MS, Oracle o SAP, separando obviamente lo que es I+D+i. ¿Windows Vista puede ser considerado como un fracaso de la industria TI? Apostaría mi vida a que tiene números azules, pero sin duda tomo más tiempo y recursos que el presupuestado y desde el punto de vista de los usuarios la calidad dejó mucho que desear.
Por otro lado la comparación es odiosa no solo por los temas financieros, sino también porque en los proyectos de construcción, prácticamente no existen cambios.
Hoy por la mañana discutíamos este tema con Eduardo. A la mitad de la construcción del Edificio nadie te pide que los baños que eran de 3×3, ahora incluyan Jacuzzi y Sauna.
La construcción tiene riesgos, supuestos, etc., pero su modelo es un «cascada», donde casi no hay cambios en los requerimientos, ni en el diseño.
El otro punto interesante es también es el comparar metodologías ágiles con las tradicionales. Las metodologías ágiles aceptan el cambio, sus objetivos varían, y con ello los criterios de éxito. Todo es negociable. Teniendo en cuenta esto, ¿cómo puede fallar o fracasar un proyecto con una metodología ágil?, probablemente solo un descalabro mayor puede ser la causa. Por eso no me sorprende que el % de fracaso de los proyectos TI con metodologías ágiles sea menor que el de las tradicionales.
Saludos y gracias por la bienvenida
Ale , siempre leo lo que esribes, raramente opino, puede ser por comodidad o por solamente obtener ideas del resto y no aportar, pero dado que este me toca directo y siendo parte de buenos y malos emprendimientos en materia de proyectos de TI en Gobierno, opino!: los estudios realizados y tus conclusiones no pueden estar mas acertadas. y Quiero aportar respetuosamente lo vivido por mi, en cada uno de los puntos
Esto nos pasa siempre y los equipos TI, somos poco rigurosos en hacerle ver a nuestro cliente los altos impactos en tiempo, costos y calidad, comenzar un proyecto sin tener las cosas claras, Al final terminamos aceptando las condiciones y acpetando las fechas impuestas, no siempre acompañadas de criterios racionales o tecnicos
lo vivido es que en gobierno cuando se desarrolla un proyecto se señala o se vincula con TI, el cliente se desentiende del tema y trapasa toda la responsabilidad del tema al equipo TI, sumandose solo para o cortar la huincha o a criticar por q se produjo tal desvio o error.
No se si en todos los casos pase de esta manera, pero siempre he considerado que no siempre contamos con los mejores equipos TI, para abordar temas con TI de vanguardía , terminando muchas veces aceptando lo que dicen nuestros proveedores por no contar con la capacidad de cuestionar los planteamientos, ojala exisitieran mejores incentivos para tener mejores equipos profesionales .
La verdad creo que compramos muchas herramientas , que parecen resolver nuestros problemas y despues solo se vuelven parte de nuestros costos anuales de mantencion en licencias, en el caso de los metodos, tengo mis dudas creo q somos pocos los que los utilizamos y muchos los que declaran creer en ellos y que todo lo hacen con metodología cuando la realidad es que no poseen ninguna pero si un proveedor de ellos la usa, asumimos por defecto q con eso basta para decir que tenemos metodos.
Creo que eso tiene que ver con lo poco transparente q aveces se es con la real situación de los proyectos, al parecer no nos gusta que se involucren en nuestro negocio, creo que no democratizamos el conocimiento sobre los estados reales de nuestros proyectos. Tambien existe falta de interes de realizar un adecuado seguimiento del proyecto por las gerencias, muchas veces los mareamos con siglas para que no pregunten
Para mi es casi nula, cuesta y cada vez que uno quiere incoorporar estos temas claves para el exito de un proyecto, las orgnizaciones no la valorizan y prefieren quedarse con un vamos bien y estamos avanzando, de esa forma muchos proyectos de Egov planficados para 1 Año, toman entre 5 y 6 años
Las personas involucradas en temas de Egov tenemos un gran desfio por delante no olvidar nunca que los recursos no son infinitos y no nos pertenencen son de todos, por lo que creo q se debe mejorar y el primer paso es sincerando que debemos mejorar, por lo que debemos ser capaces de cambiar estos numeros, que coincido no gustan por que nos tocan el ego, pero son nuestra realidad, asi que a Trabajar.
Un Abrazo a todos y Felz Cumpleaños! Ale
El exitómetro
p => q … si p es falso entonces la implicación es siempre verdadera. Claramente estamos en una trampa, por lo menos las cifras que manejo de mi propia realidad son bastante mas alentadoras :-).
Habriría el debate para preguntarnos por el real éxito de proyectos en otras industrias. El grado de éxito depende claramente del exitómetro que cada uno use.
Por ejemplo, miremos el Legado de la Minería de Clase Mundial que tenemos en Chile, AMSA, ANGLOAMERICAN, CODELCO, …, ahora miremos el Legado Territorial, Social y Ambiental de la Minería: pueblos fantasma en el Norte, alcoholismo, madres multicontratistas, malas condiciones de vida … sin duda un éxito para unos pocos un desastre para los que quedan.
http://www.GlobalReportingInitiative.org está planteando que el exitómetro empresarial cambió y está ligado a la sustentabilidad, operativamente plantea cerca de 80 indicadores económicos, ambientales y sociales, … estamos haciendo Software par este tema.
Malas distinciones, mal presagio
Por otro lado se debe entender que los proyectos TI no son en el aire, es la organización que busca transformarse a si misma y ve en la tecnología una posibilidad. Si el proyecto TI falla la organización fracasa en su propósito, si alcanzamos el propósito entonces el proyecto fue eficaz.
En mi no tan humilde mi opinión, las fallas que he visto, provienen de malas distinciones iniciales (el relacionalismo, oopismo, …). Partir de una buena distinción es la base para un «mal software que siempre se puede mejorar» … una mala distinción solo genera «cosas de las cuales te quieres deshacer» …
Mucho prejuicio y mucha intelectocracia-acreditada, terminan por negar las aproximaciones simples y obvias … como se dice por ahí, «mas discurre un hambriento que cien letrados» … un letrado hambriento sería ideal ;-).
Patrimonio editorial, patrimonio tecnológico, el cómo.
En el caso del Estado (no solo el gobierno), hay muchas líneas de código-propias (o de todos los chilenos) que podrían ser parte del «patrimonio de CHile» … incluida la olvidad Versión 1,0 de ChileCompra de 1999 escrita en Perl y que era OpenSource 😉 … el punto es la sustentabilidad de esas líneas de código y que se permita su sustentación … la falla a veces se explica por que hay fallas de mercado estructurales o porque se quiere ceder el negocio a otro.
El éxito en cualquier industria tiene un denominador común, los que construyen las máquinas que hacen las máquinas tienen serias posibilidades de seguir siendo los que construyen las máquinas que hacen las máquinas 🙂 … entonces ya tenemos una pista para seguir,
saludos
José pepe Flores
jflores@newtenberg.com
Ale, a modo de aportar una «hebra» más a la conversación, y sin tratar de explicar este problema con solo una variante, estimo que uno de los grandes responsables de esta tasa de fracaso comparado con otras industrias está en el hecho que la nuestra es nueva.
En efecto, tomando la construcción como comparativa, el hombre lleva cientos de millones de años construyendo y, durante este tiempo, ha adquirido el conocimiento claro de que es la vivienda, que se puede esperar de ella y, por cierto cómo se construye y administra la construcción. Tanto es así que hoy existen al menos dos carreras universitarias «ancla» para poder solucionar el tema: Arquitectura y construcción. Existen otras como Urbanismo, Sociología, Medio Ambiente, etc. que completan el panorama.
Nuestra industria está, por decir lo menos, en su etapa de la era de piedra, y si me permiten, creo que la edad moderna será cuando seamos capaces de crear seres inteligentes en base a la tecnología con capacidad de discernir en base a experiencias y valores adquiridos.
Manteniendo la comparación, creo que la tasa de errores debe ser similar a la que tenían los etruscos?… La verdad no lo sé pero debe andar por ahí.
En definitiva, nos falta mucho por aprender para mejorar estas tasas. Desde ya, subirle el pelo y pasa de oficio a ciencia, de unidad de apoyo a unidad de frete estratégico.
Y para eso, es necesario, al menos que nos pongamos de acuerdo dónde estamos y ando queremos llegar.
José Antonio Barriga
A riesgo de llegar tarde con este comentario agrego algo. Soy Magister en Ingenieria en Computación en Uruguay, renové mi PMP hace unos meses y he gerenciado más de 20 proyectos de software y afines. En los últimos tiempos he dedicado parte de mi tiempo a las PMO, la estandarización de procesos en las organizaciones y algunas otras cosas. Sobre fines del año pasado, dicté alguna conferencia sobre implantación de Oficinas de Proyectos. En esa conferencia, una de las primeras slights refería precisamente al informe del Standish Group. Había visto algún otro informe (gracias Alejandro por completar esa perspectiva de análisis).
Coincido parcialmente con casi todos los que intervienen e esta discusión. Sin embargo, me parece un aspecto central en la búsqueda de mejora poner el énfasis en los procesos y en la custodia de esos procesos. La inmadurez organizacional, no solo la inmadurez de la industria impacta directamente sobre los productos que se generan a través de proyectos de software. Normalmente, no se sabe lo que se quiere y nosotros no somos capaces de ayudar a dar precisión a la definición.
En lo personal soy dueño de una metodología de gestión de proyectos alineada con la propuesta del PMI y el modelo CMMI en el nivel 3. En más de una organización el intento inicial de mitigar los desvíos en cronograma, alcance y costos se basó en formar PMP y seguir esa metodología, pero no resultó suficiente. Me quedó claro que era necesario un soporte estructural que garantizara y mantuviera la estandarización de esos procesos. Avanzando en esa dirección es que estamos apuntando a implantar Oficinas de Proyectos. No sabemos aún cuánto se mejorarán los resultados pero está claro que es un camino a seguir.
Hola eh encontrado muy interesantes todos los comentarios … no pienso abordar en este tema puesto que sus opiniones son mucho mas valiosas que lo que yo pudiera exponer .. mi problema es que estoy estudiando Informatica en Cuba y mi tesis es sobre la gestion de requisitos… y tengo que realizar un estudio estadistico .. me ayudaria muchisimo que si tienen una informacion mas extensa sobre este tema.. me la hagan llegar … seria de gran ayuda.. gracias y saludos
He tenido ya varias experiencias en proyectos de TI principalmente ligados al área SAP en donde, digamos que existen 2 mundos, la parte estándar y los procesos a la medida que se implementan en esta plataforma que podrían ser como cualquier SW hecho a la medida. Coincido que en los proyectos hay variados factores que contribuyen a posibles desvíos y en mi caso, he vivivo varios. Entre ellos, falta de claridad en los requerimientos, perfiles inadecuados en los usuarios y consultores, falta de proactividad, falta de comunicación, falta de metodología, y otros que se hereden como tiempos reducidos para lograr un proyecto menos costos que pueda competir en el mercado y sea finalmente escogido por el Cliente, pero a que costo…el costo normalmente lo paga en principio el equipo de proyecto y esto termina agotando los márgenes, desgastando al equipo, dejando una mala imagen del equipo y de la empresa que implementa el proyecto.
Creo que hay muy poca metodología que se aplica en la elaboración de las propuestas que cubican lo necesario para hacer proyectos, sobre todo de gran magnitud. Y esto es al largo plazo un punto más para las estadísticas de fracaso.
Me parece que el debate está abierto y los felicito por el tema, es muy interesante y creo necesario concientizar a la industria general que es imperativo aplicar estándares con metodología (lo que claramente encarece) en la creación de proyectos de este tipo.
Saludos
Ale, espero que estés súper. Hay un tema muy relevante y que no está tocado en algunos de los comentarios. Este el Change Management que a veces se hace – las menos – pero basado en metodologías gringas que no funcionan para nuestra idiosincracia (como todas las metodologías gringas). El ChM tiene por objetivo «comprometer a los usuarios con el cambio» y es tan importante como la PMO y el QA y es lo más dificil porque se trabaja sobre actitudes, emociones y comportamientos.
Alejandro, Una duda: abajo los % son de fracaso?
Encuesta Revista Dr. Dobb’s (2007) – 72% de los proyecto de desarrollo e implementación de Data Warehouse con metodologías ágiles, versus 63% con metodologías tradicionales.
Gracias
Pato
Muchas gracias Pato por comentario, totalmente de acuerdo contigo, es un factor muy relevante y poco abordado como mencionas en Chile, en general lo hacemos a la cundidora
—————–
Alejandro Barros
he vivivo varios. Entre ellos, falta de claridad en los requerimientos,
perfiles inadecuados en los usuarios y consultores, falta de
proactividad, falta de comunicación, falta de metodología, y otros que
se hereden como tiempos reducidos para lograr un proyecto menos costos
que pueda competir en el mercado y sea finalmente escogido por el
Cliente, pero a que costo…
Hace un tiempo me llegó un correo, o lo lei en elgún blog un video muy bueno que se realizó en España respecto de la Burbuja inmobiliaria, y la soga al cuello que nos ponemos.
buscaré el link para publicarlo.
Una buena planificación y proyección de los proyectos es fundamental a la hora de ejecutar las acciones, por ello mejor prepararse.
Les invito a visitar MAC UC, sus becas y financiamiento.
Alejandro, conoces mi background y sabes que prácticamente he vivido de las fallas en proyectos TI. Sin embargo puedo decirte que con parametros igual de estrictos otras industrias más maduras, a las que inngablemente les va mejor, no por tanto como se pretende. Los sobrecostos en construcción son enormes y el nivel de satisfacción del comprados final bastante bajo. en industria automotriz, militar, naviera, etc. los sobrecostos y demoras son también significativos. La madurez de estos se nota en que estpan explísitos los tiempos de contingencia y detallados los procesos así como los detalles del producto a obtener (scope & quality management). Eso mismo hace que hablar de éxito en TI también caiga en la subjetividad porque los escenarios malos no se transparentan por el sencillo hecho de que son «anti-comerciales». Como desafío y contraste de lo anterior para compararnos con la construcción: intenta cambiar la posición de una pared divisoria interna de un departamente de un edificio solo 10cm… sencillamente en TI somos malos para decir NO. Abrazo y bueno el artículo!