La incómoda realidad con la que empiezan todos los proyectos

Muchos proyectos empiezan con la idea de que todo puede definirse desde el principio: requisitos, alcance, fechas, e incluso un plan detallado de lo que va a ocurrir.

El problema aparece cuando la realidad cambia, porque siempre cambia. Entonces llegan las desviaciones respecto al plan inicial, cambios de prioridades, y nuevos requerimientos que no se habían contemplado. Lo complicado no es que haya cambios, sino que poco a poco se pierda el foco y nadie tenga claro qué es realmente prioritario.

Pero el extremo contrario tampoco funciona mejor. Arrancar sin entender realmente qué problema se quiere resolver o incluso sin saber quién hace qué, como comentaba en mi anterior post, suele generar el mismo resultado.

Hoy, cualquier organización que gestione proyectos necesita encontrar un equilibrio entre planificación y capacidad de adaptación: saber qué se quiere conseguir, pero aceptando que muchas respuestas solo aparecerán a medida que el proyecto avance.

Ahí es donde herramientas como el acta de constitución, y en general, los enfoques ágiles aportan valor, ayudando a crear proyectos capaces de adaptarse sin perder el rumbo.

1. Empezar un proyecto sin esto claro suele salir caro

1.1 Empezar demasiado rápido

Uno de los errores más habituales es empezar un proyecto demasiado rápido. A veces ocurre por presión del cliente, otras por la urgencia de “ponerse a trabajar cuanto antes”, o porque se da por hecho que los detalles ya se resolverán sobre la marcha.

En ocasiones basta con una idea que parece buena o una necesidad aparentemente urgente para arrancar sin haber aclarado bien los objetivos y el alcance. Y ahí es donde empiezan la improvisación, los cambios constantes y el trabajo que hay que rehacer una y otra vez.

Antes de invertir tiempo, dinero y recursos, conviene plantearse algunas cuestiones:

Parece algo obvio, pero sorprende la cantidad de proyectos que comienzan sin una respuesta clara a estas preguntas.

1.2 La falsa ilusión del control

Tener claridad no significa tener todo definido desde el primer día. Significa comprender suficientemente bien el contexto sin caer en la falsa sensación de que todo está bajo control.

1.2.1 El problema de intentar definirlo todo desde el principio

Creo que es importante tener expectativas realistas: ni todos los requisitos pueden estar definidos desde el principio ni todos los riesgos pueden anticiparse. Asumir cierto nivel de incertidumbre forma parte de cualquier proyecto.

Eso no significa que sea un error dedicar tiempo a entender qué necesitan los usuarios o qué problemas debe resolver el proyecto. Muchas organizaciones intentan reducir la incertidumbre dedicando semanas y meses, a documentar todos los requisitos antes de ejecutar. Y parece bastante lógico: si todo está definido desde el inicio, tendremos menos cambios y menos desviaciones.

Intentar definir todo desde el principio puede generar una falsa sensación de control.

Muchos proyectos evolucionan mientras avanzan: cambian prioridades, aparecen nuevas necesidades y surgen riesgos que nadie había previsto.

Por eso, más documentación no siempre significa más control ni más capacidad de adaptación.

En determinados contextos, una planificación excesivamente rígida puede dificultar justo aquello que el proyecto necesita: aprender y reaccionar a tiempo.

El problema es que intentar anticiparlo absolutamente todo suele volver los proyectos más rígidos, justo cuando más capacidad de adaptación necesitan.

1.2.2 Más documentación no significa más control

Aquí aparece otra confusión bastante habitual: pensar que cuanto más detallado quede todo documentado, mayor control tendremos.

En la práctica, muchas veces ocurre lo contrario. Una documentación excesiva puede volver el proyecto más rígido, y hacer más difícil adaptarse a los cambios. Además, cuando los documentos crecen demasiado, se dejan de consultar o solo se revisan por encima, con lo que la información deja de ser útil.

Evidentemente, esto no significa que la documentación no sea importante. En sectores como construcción, industria, energía, Oil & Gas, o la propia administración pública, la gestión documental suele ser un proceso crítico. Muchas licitaciones parten de especificaciones técnicas muy detalladas que son necesarias para coordinar proveedores y cumplir requisitos regulatorios.

1.2.3 No todos los enfoques gestionan igual la incertidumbre

Ciclo predictivo: los requisitos son relativamente claros. Primero se define el alcance del proyecto.

A partir de ahí, se calcula cuánto costará y cuánto tiempo hará falta para completarlo.

Ciclo ágil: el alcance no está claro. Empezamos limitando un presupuesto o un plazo.

Estimamos el alcance a través de un feedback constante con los usuarios.

2. El Acta de Constitución: claridad sin burocracia

Aquí es donde el Acta de Constitución (Project Charter) sigue teniendo mucho sentido, especialmente cuando se utiliza de forma útil y no como un simple documento administrativo que nadie vuelve a consultar.

De hecho, sigue siendo una práctica muy recomendable tanto en enfoques predictivos como en entornos ágiles o adaptativos.

Su verdadero valor es mucho más práctico:

  1. Comunicar oficialmente la existencia del proyecto.
  2. Alinear expectativas entre los interesados.
  3. Reconocer la autoridad del director de proyecto para tomar determinadas decisiones.
Acta de constitución

Y aunque se pueda percibir como un aumento de burocracia, su nombre «Acta de Constitución» no le hace ningún favor. A pesar de eso, ayuda a aclarar algunas preguntas importantes desde el inicio,

  • por qué existe realmente el proyecto
  • qué objetivos persigue
  • quién tiene autoridad para tomar determinadas decisiones
  • cuáles son las restricciones más importantes que condicionarán el trabajo

3. El problema no era recopilar requisitos

Durante años, entrevistas con usuarios, talleres facilitados, prototipos o reuniones con stakeholders han sido algunas de las técnicas más habituales para intentar entender qué necesita realmente el negocio.

Y la realidad es que muchas de esas prácticas siguen siendo imprescindibles, especialmente en entornos regulados o en sectores donde ciertas decisiones deben quedar documentadas desde el inicio.

El problema nunca fue intentar comprender las necesidades del proyecto. La dificultad estaba en convertir toda esa información en especificaciones detalladas que quedaban obsoletas en poco tiempo.

Porque muchos proyectos cambian a medida que avanzan: aparecen nuevas necesidades, evolucionan las prioridades y el propio equipo aprende cosas que al principio todavía no conocía

Precisamente por eso empezaron a ganar fuerza enfoques más iterativos y conversacionales, especialmente en proyectos de software y productos digitales. Las historias de usuario nacen en ese contexto como una forma de mantener conversaciones continuas sobre las necesidades reales del usuario y el valor que el proyecto debe aportar. Precisamente sobre esto, profundizaré en el próximo post.

4. Conclusión

La forma tradicional de gestionar proyectos intentó reducir la incertidumbre definiendo todo desde el principio: requisitos, alcance, planificación e incluso decisiones que todavía no podían entenderse del todo.

El problema es que los proyectos reales rara vez evolucionan de forma tan predecible. Cambian las prioridades, aparecen nuevas necesidades y el propio equipo aprende cosas que al inicio todavía no sabía.

Por eso los proyectos mejor gestionados no son necesariamente los que tienen más documentación o los planes más detallados, sino aquellos que consiguen combinar dos cosas aparentemente difíciles: mantener una dirección clara y, al mismo tiempo, adaptarse a lo que van descubriendo por el camino.

Herramientas como el Acta de Constitución o, en general, los enfoques más iterativos y adaptativos tienen precisamente ese objetivo: ayudar a crear entendimiento compartido sin convertir el proyecto en un proceso rígido incapaz de evolucionar.

Porque al final, ningún proyecto sigue exactamente el plan inicial. El camino se va construyendo mientras avanzas, ajustando decisiones, prioridades y expectativas.

Algo parecido a lo que escribió Antonio Machado:

“Caminante, no hay camino, se hace camino al andar».


Guía para gestión de proyectos

Descarga gratis la guía de gestión de proyectos

Responsable: Ignacio Zabala
Finalidad: Envío de la guía y comunicaciones sobre gestión de proyectos
Legitimación: Consentimiento del interesado
Destinatarios: Mailchimp (plataforma de email marketing)
Derechos: Acceso, rectificación y supresión, entre otros, como se explica en la Política de Privacidad
Información adicional: Puede consultar la información detallada en la Política de Privacidad.

Deja un comentario