Barrapunto

Aquí no se salva nadie, así que no hace falta que te sulfures:

• El cliente rara vez tiene una idea clara (si es que tiene una idea) de lo que quiere, y además suele cambiar de idea.
• El comercial no acostumbra a tener una idea de lo que es o no factible, y mucho menos de su coste.
• El jefe de proyecto acostumbra a pensar que está en una fábrica de coches, y planifica con los mismos criterios
• El analista interpreta como quiere (o como puede) lo que el cliente (o el comercial) le dice y mete a menudo sus opiniones (más o menos fundadas) sobre cómo se deben hacer las cosas.
• El programador, en vez de mandar al cuerno al analista por presentarle especificaciones confusas, acostumbra a repetir su mismo comportameinto, interpretando las especificaciones a su manera e, incluso, ignorándolas directamente (lo que no está necesariamente mal, el problema es que tampoco se lo dice a nadie).

El resultado habitual es que, si se logra, se acaba teniendo un producto que realiza una tarea que no es la que ha acabado decidiendo el cliente que quiere (quien echa la bronca al comercial, que es el que tiene más a mano), en un plazo fuera de las previsiones del jefe de proyecto, con unas especificaciones internas parcialmente inadecuadas y a menudo obsoletas por la (anti)colaboración de analistas y programadores.

La presencia de un consultor suele servir para introducir más inestabilidad en el sistema, pues normalmente está fuera del flujo de responsabilidades y comunicación habituales.

No te creas, en todas partes cuecen habas. Por poner un ejemplo, los estudios del departamento de defensa de los EE.UU. indicaban en su momento que un 50% de los proyectos ni siquiera llegaban a terminarse (y menos de un 10%, si mal no recuerdo, se cumplían en plazo y presupuesto). Cierto es que hace décadas de aquellos estudios, pero no me sorprendería encontrarme que no han mejorado mucho.