¿Porqué fallan los proyectos informáticos?

La gran cantidad de proyectos cancelados todos los años nos dice que algo funciona muy mal en la ingeniería informática. ¿Qué es?

Según una encuesta del 2004, el 71 por ciento de los proyectos de sistemas terminan fracasando. ¿Cuál es el problema con el IT y cómo resolverlo?

En 1985 un grupo de profesionales de West Yarmouth, Massachussets creó el Standish Group con una visión: obtener información de los proyectos fallidos de IT. El objetivo: encontrar (y combatir) las causas de los fracasos.

Con el tiempo, la seriedad y el profesionalismo del Standish Group lo convirtieron en un referente mundial sobre los factores que inciden en el éxito o fracaso de los proyectos de IT. Sus análisis apuntan fundamentalmente a los proyectos de software y se aplican tanto a los desarrollos como a la implementación de paquetes (SAP, Oracle, Microsoft, etc.)

A lo largo del tiempo, el Standish Group relevó 50.000 proyectos fallidos. Así, sus conclusiones nos brindan interesantes pistas sobre dónde poner el foco para mejorarlos. Veamos lo que ocurrió en la última década...

En 1994, el 31 por ciento de los proyectos fueron cancelados. El 53 por ciento registró enormes desvíos en presupuesto y en cronograma. Sólo el 16 por ciento se completó en tiempo y dentro de los costos presupuestados (apenas nueve por ciento en el caso de grandes empresas). Para colmo, de la funcionalidad comprometida sólo se cumplió, en promedio, con el 61 por ciento (42 por ciento en grandes empresas).En vista de estos fracasos, durante los últimos diez años, la industria invirtió varios miles de millones de dólares en el desarrollo y perfeccionamiento de metodologías y tecnologías (CMMI, ITIL, SOA, etc.) destinadas a mejorar la administración y productividad de los proyectos de software. ¿Sirvieron estas inversiones? Veamos los resultados de la encuesta del 2004...

La buena noticia: los proyectos exitosos crecieron al 29 por ciento. La mala noticia: los proyectos fracasados representan el 71 por ciento.

¿No es aterrador? Siete de cada diez proyectos se cancelaron o registraron desvíos del 45 por ciento sobre lo presupuestado en costos y del 63 por ciento de lo previsto en tiempos. Por otro lado, apenas se cumplió con el 67 por ciento de la funcionalidad comprometida.

Según el informe de Standish las diez principales causas de los fracasos son las siguientes (por orden de importancia):

1) Escasa participación de los usuarios finales (12,8%): El usuario es quien finalmente evaluará y aprobará o desaprobará el proyecto terminado. Por eso siempre se debe siempre de involucrar al usuario en la definición del proyecto y en los subsiguientes pasos. Se deben establecer canales y vías de comunicación constante con el usuario para poder brindarle la mayor información posible del avance del proyecto, para que éste pueda valorarlo y dar su feedback, que es la base para hacer los reajustes sin algo no estuviese del todo bien.

2) Requerimientos y especificaciones incompletas (12,3%): La ingeniería de requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

La ambigüedad ayuda a generar falsas expectativas y provoca enormes pérdidas de tiempo cuando lo que se implementa es la solución equivocada.

3) Cambios frecuentes en los requerimientos y especificaciones (11,8%): Durante el proceso de construcción de un sistema de información es común encontrarse con usuarios ávidos en añadirles nuevas funcionalidades o características al mismo. Esto se constituye en un factor peligroso ya que el equipo de desarrollo podría perder días, semanas y hasta meses valiosos haciendo algo que al usuario inicialmente no especificó. Los requerimientos de los usuarios tienen contienen generalmente muchas ambigüedades, malos entendidos, inconsistencias y omisiones.

4) Falta de soporte ejecutivo (7,5%): Todo proceso de cambio tecnológico genera cierto grado de oposición en las organizaciones. En este sentido los funcionarios de mayor rango deben estar comprometidos con este proceso y este compromiso debe ser transmitido a los demás miembros de la organización.

5) Incompetencia tecnológica (7,0%): La incompetencia tecnológica proviene de la resistencia, psicológica o cultural, de los usuarios para modernizar sus procedimientos de trabajo, roles y obligaciones organizacionales.

6) Falta o recorte de recursos (6,4%): La asignación de recursos humanos y materiales suele ser, en la práctica, uno de los aspectos que mas complicaciones produce en un proyecto. La definición y asignación de recursos implica de hecho prever tres elementos:

• Qué tipo de recursos se van a usar
• En qué cantidad
• Durante cuanto tiempo

La mayoría de proyectos grandes que fracasan lo hacen porque se reducen sutilmente todos los recursos necesarios para llevarlos a cabo. Cualquier albañil sabe que hay una proporción correcta entre cal y cemento y que no se puede quitar un 5% de hierro a un edificio porque los precios del acero se hayan disparado. En informática, en cambio, es normal contratar un profesional de 3 años en experiencia en el puesto de uno de 5. No importa convertir 9 meses en 8 o US$100.000 del presupuesto en US$90.000. Se van metiendo pequeños recortes por todas partes, un poco de cada lado hasta que se arruina cualquier posibilidad de éxito

7) Expectativas no realistas (5,9%): Comparta toda la información posible con sus clientes, evitando el uso de la jerga técnica, y ayude a los clientes en la descripción de sus necesidades.

Aclare las percepciones de sus clientes y explicite las limitaciones de manera frontal y honesta.

8) Objetivos poco claros (5,3%): Un principio básico en la gestión de proyectos es que los objetivos estén definidos a priori y con un grado de suficiente de claridad y precisión. Los objetivos generalmente son: el resultado , el costo y el plazo del proyecto. Estos tres objetivos son inseparables y forman un sistema en el que cada modificación de cada una de las partes afecta a las restantes. Dado que la maximización individual de los tres criterios básicos no es posible, es necesario maximizar una cierta combinación entre ellos.

9) Cronogramas irreales (4,3%): Se deben estimar plazos realistas para cada una de las etapas del proyecto teniendo en cuenta los recursos disponibles. Es frecuente que los plazos se definan sin criterios técnicos

10) Nuevas tecnologías (3,7%):

Observemos que de los diez factores mencionados, siete están referidos a factores humanos (1 a 4 y 7 a 9). Si bien algunas de las metodologías cubren temas de comunicación, manejo de conflictos y negociación, en su abordaje se pone mucho más énfasis en los elementos hard (duros) que en los suaves (soft). Así, muchas metodologías cometen el error de prestigiar el contenido procedimental por encima del conceptual. Es decir, se apunta más al COMO que al QUE.

En este marco, para incrementar los resultados de los proyectos de IT, es fundamental reformar la educación en sistemas, adoptando un enfoque original y desafiante que comprenda no sólo la difusión de metodologías, técnicas y experiencias sino también el replanteo de varios paradigmas incorporando nuevos marcos conceptuales.