Es doloroso asumir un plazo de 22 meses para un proyecto que se quiere obtener en 12, pero forzar el plazo deseado. El plazo más corto es el que con mayor acierto se ha estimado.

.

Añadir personal a un proyecto retrasado. Este es, sin duda, el fallo clásico
más clásico. Y es que el factor humano no escala fácilmente, generalmente
añadir gente a un equipo existente que se encuentra retrasado lo retrasa aún
más puesto que genera mucho trabajo de coordinación adicional, además el
equipo no cuenta en ese momento con la calma necesaria para dar a las
personas nuevas la formación que necesitan del proyecto, con lo cual ésta irá
lenta.

.

Expectativas irrealistas. Una de los causas más frecuentes de fricción entre
desarrolladores y clientes o gestores son expectativas irrealistas. Sensibilizar al
cliente no es un proceso trivial y requiere también una postura suficientemente
razonable de su parte. Una vía de compromiso ante plazos que al cliente le
parecen excesivos puede ser una cuidadosa negociación de los requisitos.

.

Falta del “input” de usuario. Resulta muy difícil para los no informáticos
imaginar hasta qué punto se necesita el detalle de los procesos para
implementarlos bien. TODOS los clientes tienden a quedarse muy en la superficie
de los requerimientos, si los responsables del desarrollo lo admiten, esto se
traduce normalmente en desarrollos que están lejos de cubrir las necesidades del
cliente y con ello en retrasos para lograrlo, lo que a su vez provoca código
“sucio” por los frecuentes cambios, mucho más difícil de mantener y evolucionar.

.

“Wishful thinking”. Esto es básicamente el fenómeno de ponerse la venda en
los ojos ante la voluntad que querer cumplir de cualquier manera un
determinado objetivo por imposible que sea, ¡pero no hay que confundirlo con
optimismo, el optimismo de por sí es sano para un proyecto! Cuantas veces se
habrán escuchado frases como estas:
– ”Ninguno de los miembros del equipo realmente aceptada los plazos del
proyecto, pero pensaron que trabajando duro y si las cosas salían bien,
podrían ser capaces de sacarlo adelante.”
– “No ha hecho falta coordinar mucho los interfaces entre los módulos del
producto, hemos estado hablando bastante y son relativamente simples,
así que no debería haber muchos problemas en la integración.”
– “Al final hemos tenido que subcontratar un equipo de menor cualificación
de lo especificado para el módulo de acceso a base de datos, pero son
gente joven y muy motivados, seguro que lo sacan adelante a tiempo.”
– “No hace falta enseñar al cliente los últimos cambios al prototipo, ya le
conocemos bien y le encantará como haremos la versión final.”
– “El equipo dice que va hacer un esfuerzo extraordinario para cumplir el
plazo, se retrasaron en el primer hito el otro día, pero yo creo que a eso
no hay que darle mucha importancia.”