Skip to main content
Volver a Knowledge
Coordinación BIM

Una agenda no garantiza coordinación

Una agenda con puntos genéricos no coordina un proyecto. Los ocho elementos que necesita cada punto para producir una decisión técnica trazable.

Alejandro Leyva Valle
6 min de lectura
Una agenda no garantiza coordinación

Escribo esto desde una experiencia concreta, no desde una generalización. Participé en un proyecto complejo, con equipo BIM y coordinación BIM ya asignados, donde las juntas se realizaban con regularidad. Había convocatoria, había asistentes, había una lista de temas. Y aun así, la información sobre cambios y decisiones no siempre se convertía en acuerdos rastreables. En las reuniones que viví, los asuntos se abordaban sin secuencia ni coherencia entre un punto y el siguiente.

En este caso, el problema no fue la ausencia de reuniones. Fue la estructura de los puntos que se trataban en ellas.

El hecho concreto: "revisión de avance del modelo eléctrico en nivel 2"

Después de manifestar mi inconformidad con la forma en que se estaban llevando esas juntas, empezaron a enviarse agendas por escrito. Un paso adelante — pero uno de los puntos, tal como llegó, decía literalmente: "revisión de avance del modelo eléctrico en nivel 2".

Ese único renglón pretendía cubrir la revisión de una ingeniería completa, dentro de una junta de aproximadamente 30 minutos, sin que se hubiera delimitado antes qué parte del modelo se iba a revisar, contra qué criterio, ni con la presencia garantizada de alguien con la competencia técnica suficiente para validarlo. No es que faltara buena voluntad en la sala. Faltaba la información que hace posible tomar una decisión real en el tiempo disponible.

El resultado no es difícil de imaginar: una reunión que puede consumir su tiempo completo sin producir una revisión técnica válida. No una revisión rechazada, ni una revisión mal hecha — una revisión que, estructuralmente, no podía ocurrir con lo que ese punto de agenda traía consigo.

Este caso no incluye costos, retrasos cuantificados ni errores de construcción atribuibles a este episodio específico, y no los voy a inventar aquí. Lo que sí puedo describir con precisión, porque lo viví, es el patrón: información faltante, decisión sin tomar, responsabilidad sin asignar.

Lo que faltaba no era voluntad — era estructura

Al revisar qué le faltaba a ese punto de agenda, la lista es específica, no genérica:

  • No se habían definido previamente los cambios concretos que debían analizarse.
  • No estaba claro cuál era la información vigente contra la que debía compararse el modelo.
  • No se habían fijado los criterios de ingeniería que definirían si el avance era aceptable.
  • No se había formulado la decisión exacta que la junta debía tomar.
  • No se había confirmado la presencia de una persona con la competencia técnica específica para validar esa parte del modelo.
  • No se había asignado un responsable de cerrar el punto, con una fecha y un criterio de cierre.

Participaban funciones de BIM y coordinación, pero eso no garantizaba la presencia de la competencia técnica necesaria para validar cada asunto. Lo que no existía era una conducción clara: nadie tenía asignado, de forma inequívoca, quién debía preparar el punto, quién debía evaluarlo, quién debía decidir, y quién debía cerrarlo.

Vale la pena decirlo con cuidado: lo anterior describe un mecanismo que observé en este caso concreto, y que reconozco como un riesgo recurrente en la práctica de coordinación técnica — no una afirmación de que toda junta o todo retraso de proyecto sigue necesariamente esta misma secuencia.

El método: ocho elementos por punto de agenda

De esta experiencia se deriva un aprendizaje que aplico más allá de este caso: una agenda no coordina por sí misma. Coordina cuando cada punto que contiene está construido para producir una decisión, no solo para ocupar un espacio en el orden del día.

Un punto de agenda preparado para decidir necesita ocho elementos:

  1. Contexto — qué situación originó este punto y por qué se trae a esta junta específica.
  2. Información de entrada — qué datos, modelos o documentos vigentes deben estar disponibles antes de la discusión.
  3. Decisión requerida — qué se necesita decidir exactamente, formulado como pregunta o alternativa concreta, no como tema abierto.
  4. Participantes técnicamente competentes — quién, por su rol y conocimiento específico, puede evaluar y decidir sobre este punto en particular.
  5. Responsable — quién queda a cargo de que el punto se cierre, más allá de quién habla en la reunión.
  6. Fecha — para cuándo debe estar cerrada la decisión, no solo para cuándo es la junta.
  7. Evidencia esperada — qué prueba o registro confirmará que la decisión se tomó con base suficiente.
  8. Criterio de cierre — qué condición marca que el punto queda resuelto y no debe reabrirse sin nueva información.

"Revisión de avance del modelo eléctrico en nivel 2" no hacía explícitos los elementos necesarios para preparar una decisión técnica. Tal como estaba planteado, no operaba como un punto de agenda: operaba como un título.

De la agenda a un registro que sostiene la coordinación

Esto conecta con una pregunta más amplia: ¿qué ocurre con todo lo que una junta de coordinación identifica — un asunto pendiente, una condición observada, una decisión que quedó a medias — una vez que la reunión termina? Si esa información no queda registrada de forma que se pueda rastrear, el patrón se repite: la siguiente junta vuelve a intentar resolver de memoria lo que ya se había discutido antes.

El Registro de Incidencias Técnicas SORA existe para esa función: convertir un asunto detectado — en una junta, un correo o un reporte de campo — en un registro con identidad única, responsable, fecha objetivo, evidencia de verificación y criterio de cierre. No sustituye la disciplina de construir bien cada punto de agenda; le da continuidad a lo que esa disciplina produce, desde la detección hasta el cierre.

Siguiente paso

Si esta experiencia se parece a algo que has vivido en tu propio proyecto, el primer paso no es una herramienta nueva: es aplicar los ocho elementos a la próxima agenda que redactes. El Registro de Incidencias Técnicas es el paso siguiente, para que lo que esa agenda produzca no se pierda entre una junta y la siguiente.


Los detalles de proyecto, cliente, empresas, nombres y ubicación se han omitido deliberadamente: lo descrito aquí es un patrón real de coordinación técnica, presentado sin información que permita identificar el caso.

Herramienta gratuita relacionada

Lleva esta metodología a la práctica

SORA · Registro de Incidencias Técnicas

Descarga gratuitamente la herramienta de SORA asociada con este artículo y adáptala a las necesidades de tu proyecto.

SORA_Registro_Incidencias_Tecnicas_v1.0.xlsx · v1.0 · .xlsx

¿Tu organización necesita una herramienta adaptada a sus procesos?

Cuéntanos el contexto, los roles, los entregables y los controles que necesitas. SORA puede ayudarte a estructurar una solución técnica específica y definir el alcance adecuado.

Hablar sobre una herramienta adaptada

Etiquetas

Coordinación BIMGestión de ReunionesISO 19650Toma de Decisiones