Según un estudio (pdf) de la empresa IT Value Research Standish Group y del que me he enterado por ZDNet, el 68% de los proyectos de IT no cumplen las expectativas iniciales (que es una traducción amable del término "failed").
Y la razón principal que esgrimen para ese fracaso es la toma deficiente de los requerimientos.
Otros datos que me llaman la atención de los que se desprenden del estudio son que las compañías que usan metodologías deficientes para la recogida de los requerimientos, en media:
- sufren un sobrecoste del 60%, en tiempo y presupuesto.
- tienen una tasa de fracaso de sus proyectos que triplica a las que sí las tienen
- despilfarran el 41% de su presupuesto en desarrollo, software y servicios externos como consecuencia de esa mala gestión.
No tengo datos estadísticos al respecto, sólo mi percepción de bastantes años pero no me crujen esas cifras. Los proyectos de IT, particularmente los relacionados con sistemas de gestión, son proyectos en cascada por excelencia, es decir secuenciales, donde se hace una gran toma de requerimientos, luego el gran análisis y con todo eso se parametriza el sistema de turno y se le añaden los consabidos desarrollos.
Estamos hablando de proyectos de alrededor de un año, entre pitos y flautas, donde la toma de requerimientos se hace, en el mejor de los casos, enseñando un prototipo preconfigurado que nada tiene que ver con lo que luego acabará siendo el sistema. Total que no se empieza a ver nada de como está quedando el sistema hasta prácticamente el final... y los más viejos del lugar ya estarán atisbando hacia donde me estoy dirigiendo... pero ese es tema de otro post.
Legnitapress también se hace eco del estudio.
El título del post viene de la conocida/novelada anécdota de la campaña electoral de la primera elección de Bill Clinton.
Entradas relacionadas:
3 comentarios:
¿todavía hay gente haciendo proyectos en cascada?
...
De todas maneras, muchas veces la captura no es mala, pero se empieza a estropear al plasmarlos en papel, luego al leerlos otra persona fuera de contexto, al transmitirlos alguien que solo sabe lo que ha leido, y sobre todo se estropean al no ser validados de manera incremental ;)
Aaay!
Validados en forma incremental... con que solo fueran validados *funcionalmente* y no solo "a duras penas tecnicamente" me daria con un canto en los dientes....
Y claro, si los requerimientos fueran de servicio y no de aplicacion ya... ¡¡que te iba yo a decir!!
Antonio
La pregunta es: Podemos seguir considerando la toma de requerimientos (como la entendemos hoy) como algo que determina el éxito de un proyecto?
A la velocidad que cambia la economía y los objetivos de las empresas, Cómo puede un sistema, resistir el paso del tiempo de varios meses (o años!)
Soy de los "viejos del lugar" y no he puesto en práctica lo que voy a decir, pero supongo que hay que cambiar la forma de atacar los problemas, atomizando mucho, implantaciones parciales, requerimientos continuos, el cliente integrado en el equipo...no se.
Me ha gustado mucho el título ;-)
Publicar un comentario