Estimaciones ¿Por qué terminan siendo incorrectas?

Mientras participaba en una discusión sobre prácticas en gestión de proyectos de software, surgió el tema que nos afecta a todos y que parece no tener solución.
Tanto si formas parte de un equipo de desarrollo como si gestionas proyectos de software, te has tenido que enfrentar con las estimaciones, que por lo general terminan siendo incorrectas.

Según Shari Lawrence Pfleeger en su libro Ingeniería de Software teoría y práctica, hay muchas razones por las que se hacen estimaciones incorrectas.
Una investigación llevada a cabo en 150 empresas, indica que el 35% de los gerentes afirmaron que las estimaciones fueron insatisfactorias por las siguientes causas:

- Pedidos frecuentes de cambio por parte de los usuarios
- Tareas pasadas por alto- Pérdida de comprensión de los usuarios de sus propios requerimientos
- Análisis insuficiente cuando se desarrolla una estimación
- Pérdida de coordinación del desarrollo de sistemas, servicios técnicos, operaciones, administración de datos y otras funciones durante el desarrollo
- Pérdida de un método adecuado o guías para la estimación

Incluso se menciona el tema de los costos ocultos, por ejemplo que a veces se necesita un mínimo de espacio y silencio para trabajar, no recibir llamadas, visitas, etc, etc.

Todas las metodologías que se utilicen para estimar, ya sean los 38 factores de productividad de Walston y Felix, el metamodelo de Bailey y Basili, COCOMO I y COCOMO II de Barry Boehm e incluso las estimaciones en puntos de historia para nuestros proyectos ágiles, requieren de experiencia acumulada. O sea, muchos proyectos que el equipo haya realizado junto.

Todavía recuerdo cuando estimamos nuestro primer proyecto con Planning Poker asignando puntos de historia. No teníamos la menor idea de cuantos puntos ponerle a cada historia de usuario.En el segundo proyecto ya arrancamos con las métricas de velocidad del primero. En el tercero fue aún mejor.

Es cuestión de experiencia y sobre todo tener presente que las estimaciones en equipo son siempre mas precisas que la estimación de un solo experto.

De todas formas voy a diferir con uno de los puntos mencionados en el libro.
No creo que un problema se deba a que los usuarios no saben lo que quieren o a la pérdida de comprensión de sus propios requerimientos, ya que es nuestra tarea guiarlos para que se puedan bajar correctamente sus necesidades y transformarlas en requerimientos.

¿Que opinan ustedes?