Bromas aparte (más sobre gestión de proyectos)

Sigo con los temas de gestión de proyectos, después de las historias más o menos sarcásticas de algunos posts anteriores [1][2] y los comentarios de algún lector agradecido.

Decíamos ayer que, según el “informe del caos” que publica el Standish Group desde hace más de 15 años, la mayoría  de los proyectos de IT no se pueden considerar exitosos, o sea que rara vez cumplen con los objetivos, tiempos, calidad y costes establecidos. No he podido encontrar el informe de este año (sí que he podido, pero es carísimo) y por lo tanto usaré los datos del año pasado. (Por cierto, decíamos también que los informes de este grupo son muy criticados tanto dentro de la profesión como en la literatura científica, pero son los más consultados y citados).

  • Las empresas perdieron 67 Billones americanos (o sea 67.000 Millones de dólares) el año anterior en proyectos fallidos. Algunas empresas cerraron a lo largo de los últimos años por proyectos de IT equivocados, entre ellos K Mart, la segunda cadena americana de supermercados.
  • Sólo un tercio de los proyectos se consideran un éxito, un cuarto son un completo fracaso y el resto se consideran un éxito a medias.
  • La situación empeoró con la crisis: del 20% de fracasos absolutos se pasó al 25%. No tengo los datos de este año, pero parece que han mejorado algo, al menos han recuperado los niveles anteriores a la crisis. Menos dinero, más fracaso.
  • La principal causa del fracaso es, aparentemente, la falta de involucración de los usuarios (un clásico).
  • La segunda son calendarios optimistas, forzados para reducir los tiempos de entrega o el coste de los proyectos, que cada vez más se contratan a precio cerrado. Como alternativa, se reduce el alcance o la calidad o las pruebas, para hacer que el proyecto encaje en el coste.
  • En realidad, los requerimientos están poco o mal definidos, o porque los usuarios no saben lo que quieren o porque los analistas no lo entienden, o por una mezcla de las dos cosas.
  • El alcance va cambiando a lo largo del proyecto, pero no se cambian en consecuencia los tiempos, los equipos y los costes.
  • Tampoco se involucran los directivos o espónsores del proyecto, que son los que deben asignar recursos, tomar decisiones o hacer cambios. En realidad, la gestión del cambio no son manuales y cursos, sino que el cliente haga lo que tiene que hacer para que el proyecto sea un éxito. Y no lo hace.
  • La ausencia o mala de calidad de las pruebas es la razón siguiente. Puestos a ahorrar, ahorremos en testing.

Como se ve, casi ninguna de estas razones de fracaso tiene que ver con razones “técnicas”, o lo son muy lateralmente (una toma de requerimientos pobre, unas pruebas insuficientes, etc.), ni con la calidad de los profesionales o los productos. Tienen que ver con causas organizativas, o de liderazgo o de gestión. Casi ninguna tiene que ver con que la ingeniería del software ni se estudiaba, hasta hace poco, en los programas de estudios de las ingenierías. Por lo demás, los proyectos que más han crecido estos años son aquéllos en los que se implantan productos o se inventan “andróminas” (plataformas web, juegos, aplicaciones móviles, etc.), que tienen poco que ver con el ciclo de desarrollo convencional.

Se suele decir que la falta de metodología y experiencia en gestión de proyectos es otro factor común de fracaso, pero no sale en los primeros lugares de la lista. Es probable que sea así, y qué otra cosa podría decir yo que me dedico a eso (uno de mis roles es como profesor de las asignaturas de gestión de proyectos).

Sin embargo, mi intuición es que ésto sólo es cierto en parte y que la mejora y la inversión en gestión de proyectos, siendo necesaria, no resolverá que los usuarios sepan lo que quieren, que los directivos se involucren y que dejemos de aceptar las presiones sobre el alcance o el precio para conseguir o mantener un cliente.

Lo dejo aquí, con un poco de suspense, hasta otro post y las opiniones y comentarios de los lectores.

2 Comments

  1. Estoy completamente de acuerdo en todo lo que escribes. Sobre todo en el párrafo-resumen del final, que me parece simplemente demoledor:

    “Sin embargo, mi intuición es que ésto sólo es cierto en parte y que la mejora y la inversión en gestión de proyectos, siendo necesaria, no resolverá que los usuarios sepan lo que quieren, que los directivos se involucren y que dejemos de aceptar las presiones sobre el alcance o el precio para conseguir o mantener un cliente.”

    Saludos.

    Reply
  2. “La segunda son calendarios optimistas, forzados para reducir los tiempos de entrega o el coste de los proyectos, que cada vez más se contratan a precio cerrado. Como alternativa, se reduce el alcance o la calidad o las pruebas, para hacer que el proyecto encaje en el coste.”
    El proyecto en el que me encuentro en la actualidad. Vendieron el proyecto para tres meses, a precio cerrado, y hemos tenido la primera hornada que ya no está que ha durado 4 meses, y la segunda hornada, que entramos un més más tarde (principios de junio), y que nos quedamos para las pruebas integradas (Dios nos coja confesados porque empiezan la semana que viene) las cuales “calculan” que serán hasta mediados de noviembre. O sea, de 3 meses a unos 4,5-5 meses.

    Reply

Trackbacks/Pingbacks

  1. Ágil | iNFoRMáTiCa++ - [...] 1. Las pequeñas mentiras que nos contamos los jefes de proyecto 2. Bromas aparte (más sobre gestión de proyectos)…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
20 Años de Linux: ¿Éxito o Fracaso?

Este 2011 se cumplen 20 años desde aquel memorable momento en el que Linus Torvalds anunciaba en un "foro" que...

Cerrar