|
 Recopilando y contrastando las opiniones de autores diferentes, sobre cuáles son las principales causas que hacen fracasar a los proyectos de software, he extraido las más repetidas: tomando de cada uno las 5 razones que considera más importantes, y finalmente del conjunto, las 5 que más se repiten.
Este es el resultado:
Fuentes:
1.- Standish Group, Chaos Report .
2.- Watts S. Humphrey: Winning with software
3.- Focused Perfomance
4.- Coley Consulting
5.- CrossTalk (L.J. May)
6.- Database Design Resource
7.- Ram Sharma
8.- Soraya J. NetoAlvarez
| FUENTES | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | R
| | Requisitos incompletos / Falta de una visión clara | X | | | X | X | X | X | X | 1 | | Implicación insuficiente de los usuarios | X | | | X | X | X | X | X | 2 | | Falta de recursos | X | | | | | | | | 10 | | Expectativas poco realistas | X | X | X | | | | X | | 3 | | Falta de soporte ejecutivo / estructura organizativa inapropiada | X | X | | | | X | | X | 4 | | Gestión inadecuada en entornos multi-proyecto | | | X | | | | | | 11 | | Planificación mala o deficiente | | | X | X | X | | X | | 5 | | Visión y gestión de un ámbito parcial del proyecto | | | X | | | | | X | 8 | | Gestión mala o inadecuada de las personas | | | X | | | | | X | 9 | | Modificación de requisitos / requisitos crecientes | | X | | X | X | X | | | 6 | | Mala gestión de las modificaciones de requisitos | | | | X | | | | | 12 | | Personal técnico incompetente o inadecuado | | X | | | X | X | | | 7 | | Estimación mala o deficiente | | | | | | | X | | 13 | Y los Top 5 son: - Requisitos incompletos /falta de una visión clara
- Implicación insuficiente de los usuarios
- Expectativas poco realistas
- Falta de soporte ejecutivo / estructura organizativa inapropiada
- Planificación mala o deficiente
Es curiosa la diferencia de criterio de los autores, según estén más identificados con el desarrollo basado en planificción predictiva y procesos, o en agilidad y rutinas de trabajo. Para los primeros las principales razones siempre están en el ámbito de la gestión y de los procesos. Whatts S. Humphrey, diseñador y padre de los modelos CMM afirma en Winning with Software : "Software projects rarely fail for technical reasons; invariably, the problem is poor management. Technical problems often exist, but they are rarely decisive". Otras opiniones como las de Steve McConell , afirman que el principal factor determinante para el éxito de un proyecto son las personas "Software development projexts should be staffed with the best people". También en el análisis "post-mortem" de proyectos cerrados, los profesionales y sus consejos suelen estar más cerca de una de estas presunciones: - El software es el resultado de un trabajo intelectual y creativo.
- El software es el resultado de un proceso de trabajo normalizado.
y según cual sea, extraen las moralejas en la línea de la gestión y los procesos, o en la línea técnica
 |
RSS de los comentarios
1/ Incompetencia de los responsables del proyecto
2/ Responsabilidades no claras entre los participantes
3/ Requisitos incompletos / falta de una visión clara
4/ Expectativas poco realistas
5/ Falta de soporte ejecutivo / estructura organizativa inapropiada
Me sorprende que mi nº1 no salga en la lista, ya que los responsables del proyecto son por definición los principales culpables de que el proyecto no salga bien o el principal motivo de que salga adelante.
Las funciones de los responsables del proyecto son detectar y subsanar cualquier problema (por ejemplo, detectar Personal técnico incompetente o inadecuado e intentar dar formación, nuevo personal, alargar plazo... ) ya sea de planificación o gestión.
Pero en concreto, me refiero a que las personas responsables no tengan las habilidades/formación/experiencia suficiente para resolver los problemas detectados. Un analista no es un profesional con cinco años de experiencia, sino una persona que hace buenos análisis y diseñós; un jefe de proyecto no es mi amiguete...
El post me parece muy interesante (igual que navegapolis), felicidades.