Soter Ramirez

El entorno de trabajo del proyecto: seis preguntas que tiene que poder contestar

2026-10-31T08:00:00.000-06:00

Integración de Proyectos · Serie 2 · Semana 2 · Tema 2.1

Un proyecto nuevo arranca y alguien pregunta dónde se van a guardar los documentos. La respuesta improvisada de ese día —una carpeta compartida, el canal de mensajería, el correo— acaba siendo el sistema definitivo, y a nadie le pareció una decisión importante en su momento.

Dieciocho meses después, la versión buena de un documento está en tres sitios con tres contenidos distintos, hay decisiones importantes enterradas en hilos de mensajes, y el nuevo integrante tarda dos semanas en enterarse de dónde vive cada cosa.

En el plan de gestión de configuración hay un apartado que dice «ambiente de computación y herramientas», y suele rellenarse con una lista de productos. Vale la pena mirarlo de otra forma: no qué herramientas usas, sino qué preguntas tiene que poder contestar tu entorno de trabajo.

Las seis preguntas

Un entorno de proyecto, del tamaño que sea, debería permitir responder esto sin preguntarle a nadie:

¿Dónde está la versión buena de X? Una respuesta, no dos.
¿Quién decidió esto y por qué? Las decisiones, con su razón, en un sitio buscable.
¿En qué estamos trabajando ahora? El estado del trabajo, visible sin pedirlo.
¿Qué falta para terminar? Lo pendiente, con dueño.
¿Qué cambió desde la última vez que miré? Historial, no solo estado actual.
¿Cómo pido algo o reporto un problema? Un canal, no siete.

Si las seis tienen respuesta clara, el entorno funciona aunque esté montado con herramientas modestas. Si falta alguna, no hay producto que lo arregle.

Las cuatro categorías que hacen falta

Con nombres genéricos a propósito, porque los productos concretos cambian cada dos años y esto no.

1. Repositorio de artefactos. Donde vive lo que se construye, con versiones e historial. Código, diseños, documentos técnicos.

2. Gestor documental. Donde viven los documentos de gestión: plan, actas, informes, contratos. Puede ser el mismo sitio que el anterior; muchas veces no conviene, porque los públicos son distintos.

3. Gestor de trabajo. Tareas, estado, responsable. Es lo que contesta las preguntas 3 y 4.

4. Canal de comunicación. Para lo síncrono y lo informal.

Y una regla que vale más que la elección de herramientas: lo que se decide en el canal de comunicación no está decidido hasta que se escribe en uno de los otros tres. El canal es donde se conversa, no donde se guarda. Un proyecto que usa la mensajería como memoria ha elegido un sistema de archivo que borra lo antiguo y no se puede buscar bien.

El problema real no son las herramientas: es cuántas

La conversación habitual es qué producto elegir. La pregunta que de verdad importa es otra: ¿cuántos sitios distintos tiene que consultar una persona para saber en qué va el proyecto?

Cada herramienta añadida tiene un costo que nadie presupuesta:

Alguien tiene que administrarla y dar de alta a la gente.
Hay que decidir qué va ahí y qué no, y sostener esa decisión.
La información se fragmenta: parte de la respuesta está en una y parte en otra.
Cada integrante nuevo tiene que aprenderla.
Cuando dos herramientas pueden guardar lo mismo, se guarda en las dos y divergen.

Por eso una regla sencilla rinde más que cualquier comparativa de productos: una herramienta por categoría, y si una nueva no sustituye a ninguna, no entra.

Lo que hay que decidir el primer día

No cuesta más de media hora y se paga solo:

Decisión	Por qué importa
Qué tipo de contenido va en cada sitio	Evita que la misma cosa exista en dos lugares
Cómo se nombran los archivos y las versiones	Evita "final_v2_bueno_revisado"
Quién tiene acceso a qué	Más fácil de conceder al inicio que de retirar después
Dónde se registran las decisiones	Es la pregunta 2, y la que menos gente resuelve
Qué pasa cuando alguien sale del proyecto	Accesos, propiedad de documentos, traspaso
Qué se conserva al cerrar y dónde	El proyecto termina; la información sigue haciendo falta

La cuarta fila merece un comentario, porque es la que más se descuida. Un registro de decisiones —una línea por decisión: qué se decidió, cuándo, quién y por qué— es probablemente el artefacto más rentable de un proyecto en relación con lo que cuesta mantenerlo. Cuando alguien pregunta dentro de un año por qué se eligió esa opción, hay respuesta.

Cuando hay proveedores externos

Aquí aparece un problema específico: el proveedor tiene sus herramientas, tú las tuyas, y alguien tiene que decidir dónde vive la verdad.

Dos reglas que ahorran conflictos al cierre:

Los entregables viven en tu entorno, no en el suyo. Si el código, los diseños o la documentación están en la infraestructura del proveedor, el día que termine el contrato empieza una negociación que podías haber evitado.
Los accesos se retiran el día del cierre. Y eso se planifica antes, porque el día del cierre nadie se acuerda.

Caso práctico: la decisión que nadie recordaba

Escenario construido con patrones habituales; las cifras son ilustrativas.

Un proyecto de catorce meses toma, en el mes dos, una decisión técnica relevante: descartar una integración automática con un sistema externo y hacer una carga manual mensual. Hubo razones —el sistema externo iba a ser sustituido al año siguiente— y la decisión fue correcta.

Se discutió en una llamada y se comunicó por mensajería.

En el mes once entra una persona nueva al equipo, revisa la arquitectura y detecta lo que le parece un error de diseño obvio: una carga manual donde debería haber una integración. Lo plantea. Nadie recuerda con precisión por qué se decidió así; quedan dos versiones distintas de la historia.

Se dedican tres semanas a analizar la integración automática antes de que alguien encuentre, buscando en el historial de mensajes, la conversación original.

Tres semanas de trabajo para recuperar una decisión de treinta minutos. El problema no fue la decisión: fue que se guardó en el único sitio que no está pensado para guardar.

Errores frecuentes

Elegir herramientas antes que reglas. Una herramienta sin acuerdo sobre qué va dentro se llena de todo.

Acumular sin retirar. Se adopta una nueva y la anterior se queda «por si acaso». Ahora hay dos sitios.

Usar la mensajería como archivo. Es el error más extendido y el más caro a medio plazo.

No registrar decisiones. Se recuerdan seis meses; se necesitan durante años.

Dejar los entregables en casa del proveedor. Se descubre al cerrar el contrato.

Montar un entorno desproporcionado. Un proyecto de tres personas con cinco herramientas dedica más tiempo a mantener el entorno que a trabajar.

Checklist

Las seis preguntas del principio, ¿tienen respuesta sin preguntarle a nadie?
¿Hay más de un sitio donde podría estar la versión buena de algo?
¿Existe un registro de decisiones, o las decisiones viven en conversaciones?
¿Cuántas herramientas tiene que aprender alguien que entra mañana?
¿Los entregables están en tu infraestructura o en la del proveedor?
¿Está decidido qué se conserva cuando el proyecto cierre, y dónde?

Para cerrar

El ambiente de trabajo de un proyecto no se elige: se hereda de decisiones improvisadas de la primera semana que nadie volvió a revisar. Media hora al inicio para acordar dónde vive cada cosa vale más que cualquier herramienta que se compre después.

Y de todo lo anterior, si solo se puede hacer una cosa, que sea el registro de decisiones.

Te leo en los comentarios: ¿dónde quedan registradas las decisiones de tu proyecto? ¿Podrías recuperar el porqué de una que se tomó hace un año?

Referencias

IEEE 828, sobre el ambiente y las herramientas en el plan de configuración.
Project Management Institute, Guía del PMBOK, sobre activos de los procesos de la organización y el sistema de información de la dirección de proyectos.
Nygard, M., sobre registros de decisiones de arquitectura como práctica ligera.
ISO 15489, sobre gestión de documentos y su conservación.

← Anterior en la serie: El plan de gestión de configuración: qué escribir y qué dejar fuera

Siguiente en la serie: Quién aprueba un cambio: el apartado que decide si el control funciona →

Este artículo forma parte de Integración de Proyectos, una serie de 20 artículos. Ver todos los de esta serie · Índice completo por materia.

Acta de reunión: decisiones, no relato

2026-10-30T18:00:00.000-06:00

Documentos del Proyecto · Serie 15 · Semana Ejecución y control · Tema 460

El acta de reunión es el documento más frecuente del proyecto: si hay una reunión semanal, son cuarenta actas al año. Y es también donde se ve, con una claridad incómoda, si esas cuarenta reuniones sirvieron para algo.

Para qué sirve, en una línea

Dejar constancia de lo que se decidió y de lo que alguien se comprometió a hacer. Lo demás es relato.

Uno de cada seis

Perlow, Hadley y Eun publicaron en Harvard Business Review en 2017 un trabajo sobre reuniones con un dato de contexto que conviene tener presente: un directivo pasa hoy cerca de 23 horas semanales en reuniones, frente a menos de diez en los años sesenta.

Encuestaron a cerca de doscientos altos directivos de sectores distintos y les preguntaron por sus reuniones. Solo el 17 % dijo que eran, en general, un buen uso del tiempo tanto del grupo como de cada persona.

El resto se repartía así: un 16 % tenía pocas reuniones pero mal llevadas; un 13 % tenía reuniones buenas pero tantas que se comían el trabajo individual; y un 54 % —la mayoría— las tenía demasiado frecuentes, mal situadas y mal llevadas a la vez.

El acta no arregla eso por sí sola. Pero es el único sitio donde queda registrado, semana a semana, si de la reunión salió algo.

Qué lleva

Fecha, duración y quién asistió. Y quién faltó, que a veces explica más.
Decisiones tomadas. Cada una con su motivo en una línea.
Compromisos. Qué, quién y para cuándo. Los tres campos, sin excepción.
Asuntos abiertos, con responsable de cerrarlos.
Lo que se pospuso y a qué fecha.

Lo que no lleva: quién dijo qué. Un acta que transcribe la discusión convierte cada reunión siguiente en una sesión de exégesis.

La prueba de la media página

Si el acta de una reunión de una hora ocupa tres páginas, casi siempre significa que la reunión fue una puesta en común y no una reunión de decisión. Media página con tres decisiones y cuatro compromisos vale más que tres páginas de relato fiel.

Y hay una consecuencia práctica de esto: si al escribir el acta te sale vacía, no es culpa del acta. Es el diagnóstico de la reunión, y es información que merece la pena mirar.

Las dos reglas que la hacen funcionar

Se lee en voz alta antes de terminar. Los últimos cinco minutos, los compromisos en alto: «Ana, la estimación de la integración, jueves. ¿De acuerdo?». Se corrige ahí lo que no era, y desaparece la conversación de la semana siguiente sobre lo que cada uno entendió.

Se envía el mismo día. Un acta que llega tres días después ya no puede corregirse contra la memoria de nadie, y para entonces la mitad de los compromisos deberían estar en marcha.

La primera lista de cada reunión

El primer punto del orden del día no debería ser un tema: debería ser los compromisos del acta anterior, uno por uno, hechos o no hechos.

Cuesta tres minutos y cambia el comportamiento de un equipo entero en dos o tres semanas. Un compromiso que se va a repasar en voz alta delante de todos se cumple; uno que se anota y nadie vuelve a mirar, no.

Qué la vuelve papel mojado

Compromisos sin fecha o sin nombre. «Se queda en revisar el documento» no es un compromiso: es una frase.
Transcripción en vez de decisiones. Nadie la lee y todo el mundo la cita.
Sin los motivos de las decisiones. Dentro de tres meses la decisión se vuelve a discutir porque nadie recuerda por qué se tomó.
Se envía tarde. Pierde la mitad de su utilidad.
No se repasa la anterior. Y los compromisos se convierten en opcionales.
Se hacen actas de reuniones que no decidían nada. Documentar una reunión inútil no la mejora; solo la deja por escrito.

Y si me falta lo que pide

No me da tiempo a escribirla. Escríbela durante la reunión, en la pantalla compartida, delante de todos. Se acaba antes, y además se corrige sola.

Nadie asume compromisos concretos. Ese es el problema, y el acta solo lo está enseñando. Pregunta en la reunión: «¿quién lo hace y para cuándo?». El silencio que a veces sigue es información valiosa.

Mi organización pide un formato larguísimo. Rellénalo, y manda además el resumen de media página en el cuerpo del correo. Ese es el que se lee.

Caso práctico: cuarenta actas y ninguna decisión

Escenario construido con patrones habituales; las cifras son ilustrativas.

Un proyecto de un año con reunión de seguimiento semanal de hora y media, ocho asistentes. Actas impecables: orden del día, resumen de cada punto, dos o tres páginas cada una. Cuarenta y una actas al terminar.

En el cierre, alguien hizo un recuento para la relación de documentos: cuántas decisiones había en esas cuarenta y una actas.

Salieron once. Y de compromisos con nombre y fecha, veintitrés.

Hora y media por ocho personas por cuarenta semanas son cerca de quinientas horas de trabajo: unas tres personas-mes, para once decisiones.

El resto del tiempo se había ido en algo que las actas describían fielmente: cada asistente contaba cómo iba lo suyo, al resto le interesaba una parte pequeña de eso, y no se decidía nada porque la reunión no estaba pensada para decidir.

Las actas no fallaron. Fueron la única prueba de que la reunión llevaba cuarenta semanas sin cumplir su función, y estuvieron ahí desde la cuarta.

Lo que se probó en el proyecto siguiente: informe escrito de estado el día antes, reunión de cuarenta minutos solo para lo que hubiera que decidir, y primer punto siempre los compromisos de la anterior. Bajó a la mitad el tiempo y subió a cuarenta y siete el número de decisiones registradas en un año.

Checklist

¿Cada compromiso tiene qué, quién y cuándo?
¿Las decisiones llevan su motivo?
¿Se leen los compromisos en voz alta antes de terminar?
¿Se envía el mismo día?
¿El primer punto del orden del día son los compromisos anteriores?
¿Cuántas decisiones hay en tus últimas cuatro actas?

Para cerrar

El acta no es la memoria de la reunión: es su resultado. Y si haces el recuento de decisiones de tus últimas cuatro actas y sale cero, el documento está funcionando perfectamente —te está diciendo algo que convenía saber—.

Te leo en los comentarios: tu reunión semanal, ¿cuántas horas de gente cuesta al mes?

Referencias

Perlow, L., Hadley, C. y Eun, E., Stop the Meeting Madness, Harvard Business Review, julio-agosto de 2017.
Project Management Institute, Guía del PMBOK, sobre gestionar las comunicaciones y el registro de decisiones.
ISO 21502:2020, sobre información y documentación del proyecto.

← Anterior en la serie: Lección aprendida: sin culpables no sale

Siguiente en la serie: Auditoría de calidad: mirar el proceso →

Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.

Priorizar restricciones: la media página del acta que evita la reunión del mes siete

2026-10-30T08:00:00.000-06:00

Recuperación de Proyectos · Serie 14 · Semana 1 · Tema 1.3

En la entrega anterior de esta serie vimos que las restricciones de un proyecto son seis, no tres: alcance, tiempo, costo, calidad, riesgo y recursos. Y que la pregunta importante no es cuál se respeta, sino cuál manda cuando hay que elegir.

Toca lo difícil: cómo se decide eso, quién lo decide, y qué hacer cuando la respuesta honesta de todo el mundo es «todas».

Por qué priorizar cuesta tanto

Porque priorizar significa decir en voz alta qué estás dispuesto a sacrificar, y eso tiene dos costos que nadie quiere pagar.

Un costo político. Cada restricción tiene un defensor. El comercial defiende la fecha, finanzas el costo, el área usuaria el alcance, calidad la calidad. Decir «la fecha manda» es decirle a alguien que su variable va a ceder, delante de testigos.

Un costo de compromiso. Mientras nada esté priorizado, todos pueden creer que su variable se va a respetar. La ambigüedad es cómoda. Se paga después, cuando llega el conflicto y ya no hay margen.

Por eso la conversación se aplaza sistemáticamente. Y por eso, cuando por fin ocurre, ocurre en el peor momento: con el proyecto en crisis y con alguien decidiendo bajo presión.

El método de los tres niveles

Hay una forma de tener esa conversación que funciona porque limita las opciones. Cada restricción se clasifica en uno de tres niveles, y —esta es la clave— solo una puede estar en el primero.

Restringida. No se mueve. Es el límite duro. Solo una.
Optimizable. Se busca el mejor resultado posible sin violar la restringida. Una o dos.
Aceptada. Se ajusta para que las otras se cumplan. El resto.

La regla de «solo una restringida» es lo que hace útil el ejercicio. Si permites dos, el grupo pondrá cuatro, y volverás a no tener prioridad.

Ejemplos que se explican solos

Tipo de proyecto	Restringida	Optimizable	Aceptada
Cumplimiento con fecha legal	Tiempo	Costo	Alcance, calidad opcional
Producto con riesgo para personas	Calidad	Alcance	Tiempo, costo
Financiado por un fondo cerrado	Costo	Alcance	Tiempo
Lanzamiento ligado a una feria	Tiempo	Calidad	Alcance, costo
Prueba de concepto	Costo	Tiempo	Alcance, riesgo alto aceptado

Fíjate en la última columna: siempre hay algo aceptado. Un proyecto donde nada se acepta es un proyecto que va a pagar con las restricciones invisibles —riesgo y equipo— sin que nadie lo haya decidido.

Las preguntas que sacan la prioridad real

Preguntar «¿qué es más importante, la fecha o el alcance?» produce «las dos». Estas preguntas producen respuestas:

«Si llegamos a la fecha con el 80% del alcance, ¿lo lanzamos o lo retrasamos?» La respuesta ordena tiempo y alcance en diez segundos.
«¿Qué pasa exactamente el día después de la fecha si no está?» Si la respuesta tiene consecuencias concretas —una multa, un contrato, una feria— el tiempo es restringido. Si es «quedaríamos mal», no lo es.
«¿Preferirías entregar tarde o entregar con defectos conocidos?» Ordena tiempo y calidad.
«Si hiciera falta un 20% más de presupuesto para llegar, ¿existe?» Si la respuesta es no, el costo es restringido, lo diga quien lo diga.
«¿Qué parte del alcance quitarías si tuvieras que quitar algo?» Si nadie puede contestar, el alcance no está priorizado internamente, y ese es un problema anterior.

Todas tienen la misma forma: plantean el sacrificio en concreto en lugar de en abstracto. En abstracto todo es prioritario; en concreto, la gente elige.

Quién decide

El patrocinador, no el director de proyecto. Y conviene que quede por escrito con su firma, por una razón práctica: cuando llegue el conflicto —y llegará— la decisión ya estará tomada y no habrá que renegociarla en caliente.

Si el patrocinador no quiere pronunciarse, eso también es información. Significa que el proyecto no tiene prioridad establecida y que cada conflicto se va a resolver por quien grite más fuerte ese día.

La prioridad cambia, y hay que decirlo

Un error común es tratar la priorización como algo del acta de constitución que no se toca.

Las prioridades cambian legítimamente: un competidor se adelanta y el tiempo pasa a mandar; un incidente de seguridad y la calidad pasa a mandar; un recorte presupuestario y el costo.

Lo que no puede pasar es que cambien en silencio. Cuando la dirección empieza a insistir en la fecha de un proyecto que estaba priorizado por calidad, la priorización ya cambió aunque nadie lo haya anunciado. Y el equipo lo nota antes que nadie, porque es quien recibe la presión.

La pregunta que lo hace explícito, en la reunión donde se nota el cambio: «entiendo que ahora manda la fecha. ¿Qué pasa a ser aceptado?». Es incómoda y obliga a que el cambio se decida en vez de ocurrir.

Caso práctico: el proyecto con cuatro prioridades

Escenario construido con patrones habituales; las cifras son ilustrativas.

Un proyecto de doce meses arranca con un acta que dice, literalmente, que son críticos el cumplimiento de la fecha, el respeto del presupuesto, la entrega completa del alcance comprometido y la calidad del producto.

Cuatro restricciones marcadas como no negociables. Nadie lo objetó en su momento: todas parecían razonables por separado.

En el mes siete aparece un retraso de cinco semanas. Se convoca un comité para decidir. La reunión dura dos horas y no decide nada, porque cualquier salida viola algo que el acta declaró crítico. Se acuerda «recuperar el tiempo con mayor eficiencia», que no es una decisión.

Lo que ocurrió después fue lo previsible: el equipo recortó pruebas y alargó jornadas durante diez semanas. Nadie lo autorizó y todo el mundo lo sabía.

El proyecto entregó en fecha, con presupuesto, con el alcance completo y con una calidad que produjo tres incidentes serios en los cuatro meses siguientes, más cuatro salidas del equipo.

Las cuatro restricciones declaradas se cumplieron. Se pagó con las dos que nadie había puesto en el acta.

El acta no estaba equivocada por ambiciosa: estaba equivocada por no elegir. Una priorización que no sacrifica nada no es una priorización.

Cómo dejarlo por escrito

Media página en el acta de constitución, con esta forma:

Prioridad de restricciones. Restringida: tiempo — la fecha del 30 de abril viene de una obligación contractual y no se mueve. Optimizable: calidad — se buscará el mayor nivel posible dentro de esa fecha. Aceptadas: alcance (se entregará por fases si hace falta) y costo (hay margen aprobado del 15%). Esta prioridad se revisa si cambian las condiciones, y el cambio se comunica al equipo por escrito.

Cinco líneas que ahorran la reunión de dos horas del mes siete.

Checklist

¿Hay una sola restricción marcada como no negociable, o hay tres?
¿Está por escrito y firmada por el patrocinador?
¿El equipo la conoce, o solo está en el acta?
¿Qué restricción está declarada como aceptada? Si ninguna, ¿con qué estás pagando?
¿Ha cambiado la prioridad de hecho en los últimos meses sin que nadie lo anuncie?
Cuando hubo un conflicto, ¿se resolvió aplicando la prioridad o se convocó otra reunión?

Para cerrar

Priorizar restricciones no hace el proyecto más fácil: hace que las decisiones difíciles se tomen cuando son baratas, en frío y por quien tiene autoridad, en lugar de en el mes siete, bajo presión y por omisión.

Es media página, y es probablemente la media página más rentable del acta de constitución.

Te leo en los comentarios: en tu proyecto actual, si tuvieras que marcar una sola restricción como intocable, ¿cuál sería? ¿Coincide con la que marcaría tu patrocinador?

Referencias

Wysocki, R., Effective Project Management, sobre clasificación de restricciones en fija, mejorable y flexible.
Project Management Institute, Guía del PMBOK, sobre restricciones en competencia y acta de constitución.
DeMarco, T. y Lister, T., Peopleware, sobre el costo oculto de la sobrecarga.
Goldratt, E., Critical Chain, sobre gestión de holguras y presión de fechas.

← Anterior en la serie: La triple restricción ya no son tres: qué cambió y por qué importa

Siguiente en la serie: Qué es exactamente un proyecto fracasado (son cuatro cosas distintas) →

Este artículo forma parte de Recuperación de Proyectos, una serie de 61 artículos. Ver todos los de esta serie · Índice completo por materia.

Lección aprendida: sin culpables no sale

2026-10-29T18:00:00.000-06:00

Documentos del Proyecto · Serie 15 · Semana Ejecución y control · Tema 450

Todas las metodologías piden lecciones aprendidas. Todas las organizaciones dicen que las recogen. Y casi ninguna las usa, por una razón que no tiene nada que ver con el formato del documento.

Para qué sirve, en una línea

Dejar escrito algo que este proyecto ha descubierto, en términos que le sirvan a alguien que aún no ha empezado el suyo.

El motivo real de que no funcionen

Amy Edmondson, de Harvard, hace desde hace años una pregunta a los directivos con los que trabaja. Primero: de los fallos que ocurren en su organización, ¿cuántos son de verdad reprochables, es decir, alguien hizo algo que no debía? Las respuestas van de un 2 a un 5 %.

Después pregunta cuántos se tratan como reprochables. Ahí, cuenta ella, suele haber una pausa o una risa incómoda antes de contestar: entre un 70 y un 90 %.

Esa distancia explica el documento entero. Si casi cualquier fallo se va a tratar como culpa de alguien, nadie lo cuenta. Y lo que no se cuenta no se aprende.

Edmondson ordena los fallos en un abanico que va de lo reprochable a lo encomiable: desviarse a propósito de un procedimiento, hacerlo por descuido, no tener la capacidad o la formación necesarias, seguir correctamente un proceso que estaba mal diseñado, enfrentarse a una tarea demasiado difícil para salir bien siempre, y toparse con la complejidad de un sistema que se rompe en una combinación nueva.

Solo los dos primeros son razonablemente reprochables. Los demás son información, y son la mayoría.

Qué lleva una lección aprendida

Situación. Qué pasó, con datos y fechas. Sin nombres.
Por qué pasó. La causa, no el síntoma.
Consecuencia. Cuánto costó, en dinero o en días. Sin cifra, la lección no convence a nadie.
Qué haríamos distinto. Una acción concreta, no un propósito.
A quién le sirve y cuándo. El campo que decide si alguien la va a encontrar.

«Mejorar la comunicación» no es una lección

Es la frase que aparece en la mitad de los repositorios de lecciones aprendidas del mundo, y no dice nada: ni qué hacer, ni cuándo, ni quién.

Una lección aprendida se escribe en imperativo y con detalle suficiente para ejecutarla:

«No fijar hitos de validación con el área financiera entre el día 25 y el 5 del mes siguiente: es su periodo de cierre y no hay disponibilidad real. Detectado en dos proyectos. Coste del segundo: seis semanas.»

Eso sí lo puede aplicar alguien que no estuvo.

El problema de encontrarlas

Hay repositorios con ochocientas lecciones aprendidas que nadie consulta. No porque no valgan: porque buscar entre ochocientas es peor que no buscar.

Dos cosas lo arreglan, y ninguna es una herramienta:

Etiquetar por momento de uso, no por materia. No «riesgos», sino «al planificar el arranque», «al contratar un proveedor», «al cerrar una fase». Así la lección aparece cuando toca.
Convertir las buenas en otra cosa. Una lección que se repite dos veces deja de ser una lección: se convierte en una línea de una plantilla, un punto de una lista de comprobación o una pregunta en un formulario. Ahí sí se aplica sola, sin que nadie recuerde buscarla.

Qué la vuelve papel mojado

Se escriben solo al cerrar. A los ocho meses nadie recuerda el detalle que hacía útil la lección.
Solo se registran fracasos. Lo que salió bien también se aprende, y además anima a escribir.
Llevan nombres. Y entonces son un informe disciplinario disfrazado, y se acabó la fuente.
Sin coste. «Hubo retrasos» no mueve a nadie; «seis semanas» sí.
Nadie las lee al empezar. El momento de consultarlas es la planificación, no el cierre.
Genéricas. «Mejorar la comunicación» ocupa sitio y no aporta nada.

Y si me falta lo que pide

No consigo que el equipo cuente lo que salió mal. Cambia la unidad de análisis: pregunta por el proceso, no por las personas. «¿Qué hizo que esto fuera difícil de hacer bien?» saca mucho más que «¿qué pasó?».

No sé la causa real. Escríbelo igual, diciendo que no se sabe. Una lección honesta con la causa abierta es mejor que una causa inventada que despiste al siguiente.

Nadie va a leer esto. Probablemente tengas razón. Por eso la lección buena no termina en el repositorio: termina en una plantilla o en una lista de comprobación que sí se usa.

Caso práctico: la lección que estaba escrita dos veces

Escenario construido con patrones habituales; las cifras son ilustrativas.

Una organización con una oficina de proyectos ordenada y un repositorio de lecciones aprendidas con más de cuatrocientas entradas, alimentado religiosamente en cada cierre.

Un proyecto de implantación se atascó en las pruebas de aceptación porque el área usuaria no tenía gente disponible: coincidió con su periodo de mayor carga operativa. Seis semanas de retraso y un equipo entero esperando.

En el cierre se escribió la lección, correctamente redactada.

Al archivarla, alguien buscó por curiosidad y encontró dos entradas anteriores que decían esencialmente lo mismo, de proyectos de 2022 y 2023. Las tres estaban etiquetadas como «gestión de interesados».

Nadie las había encontrado porque nadie buscaba «gestión de interesados» mientras montaba un cronograma. Y aunque hubiera buscado, esa etiqueta tenía setenta y una entradas.

La organización había aprendido la lección tres veces y no la había incorporado ninguna.

Lo que se hizo entonces no fue escribir una cuarta. Fue añadir una línea a la lista de comprobación de planificación: «¿Se ha cruzado el cronograma con los periodos de máxima carga de las áreas que tienen que validar?».

Una pregunta en una lista que sí se usa vale más que cuarenta lecciones en un repositorio que no se abre.

Checklist

¿Se recogen durante el proyecto, no solo al cerrar?
¿Están sin nombres?
¿Cada una dice cuánto costó?
¿Están en imperativo y se pueden ejecutar?
¿Están etiquetadas por el momento en que sirven?
¿Alguna se ha convertido ya en una línea de plantilla o de checklist?
¿Alguien consultó el repositorio al planificar este proyecto?

Para cerrar

El objetivo no es tener muchas lecciones aprendidas: es tener pocas y que estén incorporadas donde se trabaja. Una lección que sigue siendo una lección al cabo de tres proyectos no se ha aprendido; solo se ha escrito tres veces.

Te leo en los comentarios: ¿cuándo fue la última vez que alguien de tu organización consultó una lección aprendida antes de empezar algo?

Referencias

Edmondson, A., Strategies for Learning from Failure, Harvard Business Review, abril de 2011, sobre el abanico de causas del fracaso y la distancia entre los fallos reprochables y los tratados como tales.
Project Management Institute, Guía del PMBOK, sobre el registro de lecciones aprendidas y los activos de los procesos de la organización.
ISO 21502:2020, sobre aprendizaje organizativo a partir de los proyectos.

← Anterior en la serie: Trabajar en equipo también se evalúa

Siguiente en la serie: Acta de reunión: decisiones, no relato →

Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.

Qué hace realmente un director de programas (y qué no debería hacer)

2026-10-29T08:00:00.000-06:00

Programas y Portafolios de Proyectos · Serie 13 · Semana 1 · Tema 1.3

Ya establecimos en qué se diferencian proyecto, programa y portafolio. Queda la pregunta práctica: si te nombran director de programa el lunes, ¿qué haces exactamente?

Porque el título suena a director de proyecto con más proyectos, y no lo es. Es un oficio distinto, con un entregable distinto, y quien lo ejerce como si fuera dirección de proyectos ampliada termina siendo un coordinador de reuniones caro.

El cambio de entregable

Un director de proyecto responde de un producto. Un director de programa responde de un beneficio: un cambio medible en la organización que ningún componente por separado puede producir.

La diferencia se nota en la pregunta que cada uno se hace al levantarse:

Director de proyecto: ¿voy a entregar esto a tiempo y con el alcance acordado?
Director de programa: ¿esto que estamos entregando va a producir el cambio que prometimos?

La segunda pregunta se puede responder «no» aunque todos los proyectos vayan en verde. De hecho, ese es el escenario más frecuente y el motivo de que el papel exista.

Las cinco cosas que hace realmente

1. Mantener vivo el caso de beneficios

Un programa se aprueba con una promesa: si hacemos esto, pasará aquello. Dieciocho meses después, el mercado cambió, el patrocinador se fue y nadie ha vuelto a mirar si la promesa sigue en pie.

El director de programa es quien tiene que preguntar, periódicamente y en voz alta: ¿esto sigue teniendo sentido? Es la pregunta más impopular del puesto, porque su respuesta puede ser cancelar algo en lo que ya se gastó dinero.

En la práctica se traduce en revisar el caso de negocio cada trimestre, no el avance: el avance ya lo reportan los proyectos.

2. Ordenar la secuencia

Cuatro proyectos que terminan a tiempo en el orden equivocado pueden no producir nada. Si el sistema entra antes de que la gente esté formada, durante tres meses se trabaja peor que antes.

El director de programa decide qué va antes de qué, y —más difícil— hace que un proyecto espere aunque esté listo. Ningún director de proyecto va a proponer eso; para él, esperar es puro costo.

3. Arbitrar dependencias y recursos

Cuando el proyecto A necesita algo del B, alguien por encima de los dos tiene que decidir. Sin ese árbitro, la decisión la toma quien tiene más carácter o más urgencia, que no es el criterio de la organización.

Aquí está buena parte del trabajo diario, y es el que menos se parece a dirigir un proyecto: no hay cronograma que actualizar, hay conversaciones que sostener.

4. Gestionar los interesados del nivel superior

Un programa toca varias direcciones. Sus interlocutores son directivos, no jefes de área, y esperan hablar con alguien de su nivel sobre impacto, no sobre porcentajes de avance.

Esto exige traducir: convertir el estado de doce proyectos en tres frases sobre si el beneficio prometido sigue en camino.

5. Cerrar el programa cuando toca

Y «cuando toca» no es el día que termina el último proyecto. Es cuando el beneficio se ha medido o cuando está claro que no se va a producir.

Un programa que cierra a la vez que su último componente no ha hecho la mitad de su trabajo.

Lo que NO debe hacer

Tan importante como lo anterior, porque es donde se pierde el papel.

No dirige los proyectos. Si el director de programa entra a decidir el cronograma de un componente, ha sustituido a su director de proyecto y ha dejado vacante el puesto que ocupaba él.

Esta es la deriva más común, y es comprensible: cuando un proyecto va mal, la tentación de meter mano es enorme, sobre todo si vienes de dirigir proyectos y se te da bien. Pero mientras estás arreglando ese cronograma, nadie está mirando el beneficio conjunto.

No es un consolidador de informes. Si su aporte es juntar doce estados en una presentación, el papel se puede automatizar y la organización no está obteniendo nada.

No arbitra solo cuando le llaman. Los conflictos que llegan solos son los ruidosos. Los caros son silenciosos: dos equipos que asumen cosas incompatibles y no lo saben.

La herramienta principal: el mapa de beneficios

Si el director de programa tiene un solo artefacto propio, es este. Encadena, de izquierda a derecha:

Entregables → capacidades → cambios en la forma de trabajar → beneficios → objetivo estratégico

Un ejemplo:

Entregable: un portal de autoservicio.
Capacidad: los responsables de área pueden dar de alta a alguien sin pasar por recursos humanos.
Cambio: efectivamente lo hacen, y el procedimiento anterior se retira.
Beneficio: el tiempo de incorporación baja de veinte a ocho días.
Objetivo: absorber el crecimiento previsto sin ampliar el área administrativa.

La utilidad del mapa está en el eslabón del cambio, que es donde se rompen casi todos los programas. Entregar el portal es un proyecto. Que la gente lo use y se retire el procedimiento viejo no es de nadie, y sin eso el beneficio no aparece.

Dibujar ese mapa al inicio obliga a asignar dueño a cada eslabón, incluido ese.

Caso práctico: el programa que entregó todo y no cambió nada

Escenario construido con patrones habituales; las cifras son ilustrativas.

Un programa de cuatro proyectos para reducir el tiempo de atención a clientes nuevos. Sistema nuevo, proceso rediseñado, formación impartida, proveedor renegociado. Los cuatro terminan; tres en fecha.

Catorce meses después, el tiempo de atención bajó un 9% sobre un objetivo del 50%.

El director de programa había hecho un trabajo impecable de coordinación: dependencias resueltas, riesgos compartidos gestionados, informes puntuales. Lo que no hizo fue preguntar, en el mes seis, si alguien estaba comprobando que los responsables de área usaran el proceso nuevo.

No lo usaban. El proceso viejo seguía disponible, era conocido y nadie lo retiró. Formar a la gente estaba en el alcance del proyecto de formación; retirar la alternativa antigua no estaba en el alcance de nadie.

Ese hueco —entre la capacidad entregada y el cambio de comportamiento— es exactamente el territorio del director de programa. Es lo único que no puede delegar hacia abajo.

Cómo saber si el papel está funcionando

¿Puede el director de programa decir, sin consultar, cuál es el beneficio y cómo va?
¿Ha pedido alguna vez que un proyecto listo espere, por el bien del conjunto?
¿Ha planteado la posibilidad de cancelar algo?
¿Su informe habla de beneficios o es la suma de los avances?
¿Existe un mapa de beneficios con dueño para cada eslabón, incluido el del cambio de comportamiento?
¿La fecha de cierre del programa es posterior a la del último proyecto?

Si la respuesta a la mayoría es no, hay alguien con el título y el puesto está vacante.

Para cerrar

Dirigir un programa no es dirigir muchos proyectos: es responsabilizarse del hueco que queda entre lo que se entrega y lo que cambia. Ese hueco no aparece en ningún cronograma, no lo reporta nadie y es donde se pierde la mayor parte del dinero que las organizaciones invierten en proyectos que salieron bien.

Te leo en los comentarios: ¿has visto un programa donde todos los proyectos cumplieron y el beneficio no apareció? ¿Qué eslabón faltó?

Referencias

Project Management Institute, The Standard for Program Management.
Office of Government Commerce, Managing Successful Programmes (MSP), sobre mapas de beneficios.
Ward, J. y Daniel, E., Benefits Management, sobre la cadena entregable-capacidad-beneficio.
ISO 21503, orientación sobre dirección de programas.

← Anterior en la serie: Cómo se relacionan proyecto, programa y portafolio cuando comparten la misma gente

Siguiente en la serie: Dirección de portafolios: elegir bien no basta si no puedes ejecutarlo →

Este artículo forma parte de Programas y Portafolios de Proyectos, una serie de 42 artículos. Ver todos los de esta serie · Índice completo por materia.