La reunión de seguimiento del martes termina con la misma sensación de inquietud. Tú eres el gestor del proyecto: el líder técnico afirma que la integración de la API ya no tiene bloqueos, el proveedor promete enviar las especificaciones actualizadas y tu patrocinador pregunta si se mantienen los plazos para la fecha de lanzamiento. Diez minutos después, envías un resumen de la reunión. Para el jueves, el equipo de QA está probando una versión incorrecta, las especificaciones del proveedor nunca llegan y tu patrocinador reenvía tu propio resumen preguntando quién aprobó el cambio de alcance. El problema que impide avanzar no es técnico; radica en determinar quién es responsable del siguiente paso y qué constituye el registro oficial de la decisión. Cada día de retraso conlleva más trabajo de rectificación, reuniones de seguimiento adicionales y un riesgo creciente para la fecha prevista.
Puedes solucionar esto sin añadir otra reunión. Necesitas un proceso repetible para pasar de la conversación a la ejecución, una forma de convertir las decisiones en tareas asignadas a responsables con fechas límite, y un lugar claro donde resida la información veraz del proyecto. Esta lección utiliza una cronología de una semana para diagnosticar dónde se pierden los resultados; luego presenta un flujo de trabajo que conecta las reuniones con la ejecución y, finalmente, muestra en qué puntos de ese flujo la IA resulta útil y en cuáles no.
Antes de examinar la cronología, intenta predecir cuál es el primer punto de fallo que transforma un correo electrónico de resumen rutinario en trabajo adicional para el equipo.
Al analizar la cronología de los hechos, rara vez el problema es que nadie tomó notas. Lo habitual es que la reunión haya generado al menos uno de estos resultados y nadie lo haya tratado como un entregable.
Se discutió una decisión, pero nunca se designó a un responsable de la misma; por tanto, más tarde nadie puede confirmar si realmente se decidió algo o si solo se debatió. Se dio por hecho una transferencia de trabajo —como que el equipo de desarrollo enviaría la compilación al de QA—, pero nunca se asignó como una tarea con un responsable y una fecha de entrega, por lo que compite con todo lo demás en la cola de trabajo de los desarrolladores. Se mencionó una dependencia —como las especificaciones de un proveedor externo—, pero no se registró en el mismo sistema que las tareas internas, manteniéndose invisible hasta que se convierte en un bloqueo. El patrocinador hizo una pregunta que requería elegir una opción, pero la respuesta quedó enterrada en un resumen extenso; como resultado, el patrocinador vuelve a preguntar y tu credibilidad se ve afectada.
Un error común de los gestores de proyectos (PM) es considerar el correo electrónico de resumen como la meta final. Da sensación de responsabilidad porque documenta lo sucedido. La consecuencia es que la documentación sustituye a la asunción de responsabilidades, y el proyecto entra en un ciclo interminable de recordatorios, aclaraciones y retrabajo.
Cuando una reunión genera trabajo, necesitas un proceso que transforme la conversación en bruto en elementos gestionables del proyecto. El objetivo no es tomar mejores notas, sino lograr una conversión predecible de los resultados de la reunión en acciones concretas, una conversión que perdure más allá de los cambios de herramientas o de los fallos de memoria.
Antes de ver el proceso, identifica qué paso omitido causa más daño a tus proyectos cuando se acumulan las reuniones.