por Sergio Montoro Ten, 25 julio 05

La informática es una ingeniería que sufre un cáncer. El cáncer de la ingenuidad en la planificación de proyectos.
Cuando se empieza a construir un edificio, no se abandona a la mitad porque no satisfacía los requisitos de los usuarios, cuando se acomete una obra hidráulica no se acaba diciendo que falló en el objetivo de transportar agua a las zonas designadas. O, al menos, si sucede, hay un montón de gente que se mete en auténticos problemas.

La informática, sin embargo, es diferente, cada año se cancelan miles de proyectos fallidos.

No pretendo dar en un artículo corto como este la bala de plata para problemas en los que centenares de miles de sesudos expertos como los del Project Management Institute llevan décadas estudiando. Pero si ofrecer un condensado de las causas ocultas del fracaso de proyectos que, supuestamente, están bien planeados y diseñados.

1. El razonamiento común de los programadores es que si se hacen unas buenas especificaciones y un buen diseño y una buena implementación y un buen control de calidad entonces el proyecto funcionará, pero esto es falso, porque un proyecto es justamente eso: un proyecto. No es unas especificaciones, no es una arquitectura, un proyecto es una misión compartida de un grupo de personas.

2. Recorte sibilino de todos los recursos.
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 Portland 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 (a veces ya puestos no hace falta ni siquiera que sea informático). No importa convertir 9 meses en 8 o 100.000 euros del presupuesto en 90.000. Se van metiendo pequeños rejones por todas partes, un poco de cada lado hasta que se arruina cualquier posibilidad de éxito.

Imposibilidad de coordinar esfuerzos.
El segundo motivo no escrito es la dificultad para coordinar a un gran número de partes independientes y con intereses enfrentados. Esencialmente cuantos más miembros en el grupo menores las probabilidades de que funcione. Esto es especialmente cierto en el caso de los proveedores externos que son de naturaleza fagocitaria y buscan la venta por dominio del cliente eliminando a cualquier competidor potencial. El resultado de esta pugna suele ser la destrucción del ecosistema de trabajo y la muerte del proyecto.

3. Obstáculos artificiales.
El tercer motivo es el bloqueo a las iniciativas que podrían salvar el proyecto en un momento dado. Puede ser por razones políticas o porque alguien ha empeñado su orgullo en que las cosas se hagan de una determinada manera. La cuestión es que no dejan a los informáticos trabajar, les imponen restricciones absurdas y demenciales procedimientos operativos kaftkianos los cuales, obviamente, no estaban previstos en el plan inicial de ejecución.