Knowledge base de proyectos: planificar mejor a partir de proyectos cerrados

La mayoría de las estimaciones salen de la memoria. La jefa de proyecto piensa en el último proyecto parecido, añade algo de margen y anota una cifra. Mientras tanto, los valores reales esperan en el archivo: como datos reales de proyectos cerrados. Una knowledge base de proyectos permite consultar esos datos en cada nueva planificación.

Qué gana usted

Antes de cada oferta surge la misma pregunta: ¿cuánto dura esto de verdad y cuánto nos cuesta? Una knowledge base responde con datos propios y le aporta cuatro ventajas.

• Estimaciones de plazo más precisas. Cada tarea recibe la duración que necesitaron de verdad tareas comparables, separada por tipo, proveedor, administración o estación del año.
• Colchones con justificación. En lugar de añadir un diez por ciento a todo, coloque la reserva detrás de las tareas cuya duración varía en sus datos.
• Costes de proyecto previsibles. Conoce el factor con el que su equipo subestima su propio esfuerzo y calcula ofertas y honorarios en consecuencia.
• Menos trabajo extra. Los problemas conocidos ya figuran en el registro inicial del siguiente proyecto, junto con la medida que funcionó la última vez.

El archivo de ejemplo de esta guía muestra la magnitud del efecto: doce proyectos de construcción de un estudio de arquitectura entre 2021 y 2026, unas 1.350 tareas con valores planificados y reales. Construimos el archivo para que cada cifra de este artículo se pueda recalcular; los patrones que contiene los conoce cualquier estudio del sector de la construcción. El efecto se ve con especial claridad en dos escuelas infantiles para el mismo cliente público. Para la Escuela Infantil Girasol, el estudio estimó en 2022 a partir de la experiencia. Cuando dos años después planificó la Escuela Infantil Arcoíris, incorporó los valores reales de los proyectos anteriores.

La diferencia la marcaron la duración de la licencia, la adjudicación y el periodo de obra gruesa: el estudio los planificó con las lecciones de los proyectos anteriores. El archivo completo confirma la imagen. Los siete primeros proyectos terminaron de media un 23 por ciento de su duración planificada tarde. En los tres siguientes, planificados con los proveedores, ingenierías y plazos administrativos del análisis, el retraso se redujo al 8 por ciento.

La teoría: por qué los proyectos rara vez aprenden de los proyectos

«Quienes no pueden recordar el pasado están condenados a repetirlo.»
George Santayana, The Life of Reason, 1905

Los proyectos terminan, el equipo sigue adelante y lo que salió mal se queda en las cabezas. En 2015, el Project Management Institute preguntó en su estudio Pulse of the Profession con qué eficacia transmiten las organizaciones el conocimiento entre proyectos. Solo el 14 por ciento se calificó de muy eficaz. Las organizaciones con una alta tasa de éxito tenían el doble de veces un proceso formal para ello: 75 frente a 35 por ciento.

Tres hallazgos de la investigación explican la brecha.

La falacia de la planificación. Daniel Kahneman y Amos Tversky describieron en 1979 que las personas subestiman sistemáticamente la duración de sus propios proyectos, incluso cuando saben que proyectos similares tardaron más. En «Pensar rápido, pensar despacio» (2011), Kahneman cuenta un proyecto propio de libro de texto: el equipo contaba con unos dos años, equipos comparables habían necesitado de siete a diez, y muchos nunca terminaron. Al final tardó ocho años. Douglas Hofstadter resumió el fenómeno en 1979 en «Gödel, Escher, Bach» como ley: «Siempre lleva más tiempo de lo que se espera, incluso teniendo en cuenta la ley de Hofstadter.» Por qué las personas deciden en un proyecto como deciden lo trata también nuestro resumen de teorías psicológicas para jefes de proyecto.

Visión interna y visión externa. Kahneman distingue dos formas de estimar. Quien adopta la visión interna observa su propio proyecto con sus planes y supuestos. La visión externa pregunta cómo les fue a proyectos comparables y recoge así las perturbaciones que nadie conoce de antemano. Bent Flyvbjerg construyó sobre ella el Reference Class Forecasting: un proyecto nuevo se estima a partir de los resultados reales de una clase de proyectos similares. Su base de datos abarca más de 16.000 proyectos; según «How Big Things Get Done» (2023), solo el 8,5 por ciento cumplió a la vez presupuesto y plazo.

Conocimiento tácito y explícito. Ikujiro Nonaka e Hirotaka Takeuchi describen en «The Knowledge-Creating Company» (1995) cómo aprenden las organizaciones: transformando el conocimiento que las personas tienen pero apenas expresan en conocimiento documentado. La frase «López siempre entrega tarde» vive en la cabeza de un jefe de obra. «De ocho a doce días laborables de retraso en seis de seis proyectos» lo puede usar también la nueva compañera.

Un plan cerrado es, por tanto, una clase de referencia en bruto. Los valores reales aportan la visión externa; los adjuntos de riesgo y de problema, el conocimiento documentado. Lo que falta es el análisis a través de varios proyectos.

Merlin Project y el servidor MCP

Merlin Project guarda para cada tarea valores planificados, esperados y reales. A ello se suman adjuntos en tareas, asignaciones y recursos, entre ellos Riesgo, Problema e Información. Cómo registrar valores reales en un proyecto en curso lo muestra la serie Registrar el progreso real; los fundamentos los explica el capítulo Comparación planificado/real.

El servidor MCP de Merlin Project da a una IA como Claude acceso de lectura a estos datos. Lo activa por proyecto con el botón «Herramientas de IA» de la barra de herramientas; la configuración se describe en la documentación del MCP. Para la knowledge base cuentan dos propiedades. El servidor trabaja con todos los documentos abiertos y compartidos, y la IA los analiza proyecto a proyecto. Para un archivo, abra por tanto los proyectos cerrados que deben entrar en el análisis. Y el servidor solo lee: ningún plan cambia, y usted mismo traslada las conclusiones al siguiente proyecto. Qué ocurre con sus datos lo explica el artículo sobre soberanía digital y protección de datos.

Un plan cerrado contiene nueve fuentes de aprendizaje. Las secciones numeradas tras la calculadora las tratan en este orden.

Calculadora: lo que su archivo ya ofrece

Cuáles de estos análisis permite hoy su archivo depende de cinco hábitos en Merlin Project. La calculadora pregunta por ellos y muestra qué análisis ya son posibles, cuáles faltan y qué paso abre la mayoría. Cada línea lleva a la sección correspondiente.

1. Comparación planificado/real: el factor de estimación por tipo de tarea

La comparación plan-real sirve para el control del proyecto en curso. A través de varios proyectos se convierte en un instrumento de aprendizaje: la duración real dividida por la planificada da un factor. Si para un tipo de tarea queda por encima de 1 en todos los proyectos, el error de estimación es sistemático. Es la visión externa de Kahneman, aplicada a tareas individuales. Con este factor corrige las nuevas estimaciones antes de que entren en la oferta. La condición previa es la comparabilidad: si una tarea se llama una vez «Proyecto de ejecución de obra gruesa» y otra «PE OG», ningún análisis reconoce la relación.

En Merlin Project, muestre en el esquema las columnas Trabajo planificado, Trabajo real, Finalización planificada y Finalización real. La comparabilidad la garantizan nombres de tarea uniformes o un campo personalizado como «Tipo de tarea» u «Oficio», que crea en el inspector, en Definido por el usuario. Guárdelo en una plantilla de proyecto o en la biblioteca, y cada nuevo proyecto lo llevará desde el principio. A través del servidor MCP, la IA lee los valores planificados y reales de cada tarea.

En nuestro archivo de ejemplo

La licencia en el urbanismo municipal tardó de media el doble de lo planificado; en la Diputación Provincial, exactamente lo planificado. Con un valor único para «Licencia», el estudio habría estimado mal ambas administraciones. De estos factores externos tratan las dos secciones siguientes. Llamativo es el factor del trabajo propio: el proyecto de ejecución tardó en cada uno de los diez proyectos cerrados entre un 13 y un 15 por ciento más de lo planificado. Quien aplica 1,15 planifica, por tanto, con el caso normal medido.

Comparación planificado/real en Merlin Project

La división del trabajo con las columnas Duración planificada y Duración esperada: para la entrega de ventanas se planificaron 3 semanas, López necesitó 1,35 meses. En la parte inferior aparece el riesgo de esta tarea con sus lecciones aprendidas.

El prompt para probarlo usted mismo

He abierto en Merlin Project diez proyectos cerrados y los he compartido
con las Herramientas de IA. Lee de cada proyecto todas las tareas
terminadas con su duración planificada y real. Agrupa las tareas con el
mismo nombre entre proyectos y calcula para cada tipo de tarea el factor
duración real dividida por duración planificada. Muéstrame una tabla con
número de proyectos, factor medio, valor mínimo y valor máximo. Ordena
por el factor medio, con las mayores desviaciones arriba.

2. Proveedores y socios: la puntualidad en cifras

Las fechas de proveedores y socios son dependencias externas: quedan fuera de su influencia, y cada retraso afecta a todas las sucesoras. El plan recoge el plazo de entrega prometido; la knowledge base añade el plazo cumplido. Así elige proveedores y subcontratistas según su puntualidad medida y planifica para cada uno el plazo de entrega que realmente necesita. Fíjese en el denominador: dos retrasos en dos encargos pesan más que dos en veinte, y solo el número de encargos convierte una impresión en una tasa. Cómo dirigir a los proveedores desde el principio lo describe el artículo sobre gestión de compras.

En Merlin Project, cree las empresas externas como recursos o anote el nombre de la empresa en un campo «Proveedor»; así cada tarea de suministro queda asignada a una empresa. Las tareas retrasadas reciben un adjunto de tipo Problema con categoría, tipo y una breve descripción. La vista Adjuntos lista todos los problemas de un proyecto. La knowledge base necesita ambas cosas: el retraso medido en los valores reales y la causa en el adjunto de problema.

En nuestro archivo de ejemplo

Ventanas López entregó tarde en cada uno de sus seis encargos. En los tres primeros proyectos, esto figuraba en el plan solo como adjunto de problema, como contratiempo aislado. Solo la comparación revela el patrón: de ocho a doce días laborables después de lo prometido, mientras el edificio seguía abierto y la construcción en seco y el contrapiso esperaban. El estudio cambió a Ventanas Moreno, que entregó como mucho un día después de lo prometido. Con el cálculo de estructuras ocurrió algo parecido: Ingeniería Campos entregó dos veces seis días laborables tarde; Benítez se mantuvo en plan en diez encargos.

Un adjunto de problema en Merlin Project

La insolvencia del subcontratista de construcción en seco no figuraba en ningún registro. Como problema con categoría, tipo y estado sigue siendo analizable, y la IA la encuentra al buscar fallos recurrentes.

El prompt para probarlo usted mismo

Lee de todos los proyectos compartidos las tareas en las que participan
empresas externas, con su finalización planificada y real. Calcula por
empresa el número de encargos, el retraso medio en días laborables y el
mayor retraso. Añade los adjuntos de problema de esas tareas y resume las
causas indicadas. ¿Qué empresa resulta poco fiable a lo largo de varios
proyectos, y en qué base de datos se apoya esa conclusión?

3. Administraciones y plazos: duración por organismo

Los trámites administrativos quedan al principio del proyecto, a menudo en la ruta crítica, y cada día de retraso desplaza todo lo que sigue. Leyes y guías indican plazos reglamentarios que poco tienen que ver con el tiempo de tramitación real. Quien planifica con el plazo reglamentario estima desde la visión interna. Si en cambio planifica licencias, inspecciones y plazos de adjudicación con el tiempo de tramitación medido del organismo competente, evita el gran retraso más frecuente al inicio del proyecto.

En Merlin Project, modele licencias y plazos como tareas propias. Los tiempos de espera en los que solo trabaja la administración los crea con duración y sin asignación; el organismo competente lo anota en un campo «Administración». Tras la finalización, introduzca la finalización real, aunque la tarea no tenga trabajo; de lo contrario falta el valor real más importante del proyecto. Qué fases y plazos marcan un proyecto de arquitectura lo resume la guía de gestión de proyectos en arquitectura.

En nuestro archivo de ejemplo

El urbanismo municipal necesitó en cinco proyectos de 59 a 72 días laborables; se habían planificado de 30 a 40. La Diputación Provincial cumplió en cuatro proyectos exactamente los 30 planificados. Con un valor común para ambas administraciones, un estudio se equivoca en semanas con el ayuntamiento o desperdicia reserva con la Diputación. La conclusión: planificar la duración por administración. Las licitaciones públicas siguen la misma lógica. Un recurso contra la adjudicación costó 20 días laborables a la Escuela Infantil Girasol; en la Escuela Infantil Arcoíris, el estudio acordó de antemano la matriz de valoración con el órgano de contratación, y el recurso no llegó.

Duración de la licencia en el plan

En el Residencial del Parque, el estudio planificó 2 meses para el Trámite de licencia; el ayuntamiento necesitó 3,6. El riesgo de abajo registra 32 días de retraso, y la información de cierre da el valor para el próximo proyecto: 65 DL.

El prompt para probarlo usted mismo

Busca en todos los proyectos compartidos las tareas de licencias,
inspecciones y plazos de adjudicación. Indica por tarea el proyecto, la
administración competente según la descripción del proyecto y la duración
planificada y real. Agrupa por administración e indica para cada una la
duración más corta, la típica y la más larga. ¿Qué valor debería usar
para un proyecto nuevo con la misma administración?

4. Rangos: estimación de tres puntos con datos reales

La estimación de tres puntos describe una tarea con tres valores: optimista (O), más probable (M) y pesimista (P). La fórmula PERT (O + 4M + P) / 6 los condensa en un valor esperado y pondera M por cuatro; el contexto lo explica nuestra guía sobre diagramas PERT. Normalmente el equipo adivina los tres valores. Con una knowledge base los mide: O como el valor observado más corto, M como el más frecuente, P como el más largo. Así, las tareas recurrentes reciben un rango fiable en lugar de una cifra que solo acierta de media. Cómo surge de ahí una distribución lo muestra la guía sobre la simulación de Monte Carlo.

Merlin Project guarda por tarea una duración planificada y un valor real; no existe una estimación de tres puntos nativa. Cree dos campos personalizados para O y P y rellénelos en la plantilla con los valores de la knowledge base; la duración planificada sigue siendo M. La IA lee los tres valores a través del servidor MCP y simula con ellos, como muestra el artículo Simulación de Monte Carlo en Merlin Project.

En nuestro archivo de ejemplo

La media y PERT llegan a unos 66 días laborables; el estudio planifica 65 desde 2024. Un valor único oculta, sin embargo, cuánto varía una tarea. En el urbanismo municipal hay 13 días laborables entre el trámite más corto y el más largo; en la Diputación Provincial, ninguno. Solo el primer caso necesita reserva. El rango de 59 a 72 es además la entrada para una simulación de Monte Carlo; con valores medidos sustituye la suposición genérica «duración planificada más o menos un 20 por ciento».

El prompt para probarlo usted mismo

Calcula para cada tipo de tarea que aparezca en al menos tres proyectos
compartidos una estimación de tres puntos a partir de las duraciones
reales: O como valor más corto, M como el más frecuente y P como el más
largo. Indica además el valor esperado PERT (O + 4M + P) / 6. Marca los
tipos de tarea con menos de cinco proyectos como base de datos insegura.

5. Colchones: reserva donde hay dispersión

Un colchón protege una fecha frente a la incertidumbre. Repartido de forma genérica, por ejemplo un diez por ciento por tarea, acaba en tareas estables y falta en las variables. A ello se suma un efecto de comportamiento. Cyril Northcote Parkinson escribió en 1955 en The Economist: «El trabajo se expande hasta llenar el tiempo disponible para completarlo.» Quien da reserva a cada tarea suele verla consumida. Eliyahu Goldratt sacó de ello en «Critical Chain» (1997) la conclusión de retirar la reserva de las tareas y agruparla delante de las fechas críticas. Qué tamaño debe tener ese colchón y dónde va lo dice la knowledge base: detrás de las tareas con mucha dispersión en la ruta crítica. Con la misma reserva cumple entonces las fechas más a menudo.

En Merlin Project, cree los colchones agrupados como tareas propias sin asignación delante del hito que protegen y nómbrelos sin ambigüedad, por ejemplo «Colchón licencia». Durante el proyecto verá cuánta reserva se ha consumido. Dónde tiene holgura propia el diagrama de red lo muestran las columnas Holgura total esperada y Holgura permisible esperada. Si la reserva no alcanza para la fecha deseada, ayudan las técnicas del artículo sobre Fast Tracking, Crashing y Contouring.

En nuestro archivo de ejemplo

Repartida por igual, la reserva falta en la licencia, que en los datos varía hasta 13 días laborables; colocada de forma dirigida, está donde está la dispersión. El tamaño de un colchón se deriva del rango. Si una tarea en el archivo oscila entre 59 y 72 días laborables y usted planifica 66, necesita unos seis días de reserva detrás para una alta puntualidad. En una tarea que en diez proyectos se desvió como mucho un día, se ahorra el recargo. Si la reserva total basta lo responde una simulación de Monte Carlo con P80 o P90.

Donde el plan no tiene margen

La columna Holgura total esperada muestra 0 días para el Trámite de licencia. Como todas las tareas de la ruta crítica, no tiene margen: cada día de retraso desplaza el fin del proyecto. Cuál de ellas necesita un colchón agrupado lo decide la dispersión del archivo.

El prompt para probarlo usted mismo

Lee el plan del proyecto nuevo del documento actual. Compara cada tarea
de la ruta crítica con los rangos de nuestra knowledge base, que te paso
como archivo. Propón detrás de qué tareas debería ir un colchón agrupado
y qué tamaño necesita para que la fecha final se cumpla con
aproximadamente un 80 por ciento de probabilidad. Indica las tareas cuya
duración planificada ya contiene reserva.

6. Estación del año y contexto: factores estacionales

Algunas desviaciones dependen del momento de una tarea. En la construcción, las heladas y la lluvia frenan la obra gruesa y en invierno el contrapiso seca más despacio; en el desarrollo de software influyen las vacaciones o los cierres trimestrales del cliente. Estas influencias afectan a varias tareas a la vez; en la teoría de Monte Carlo se llama correlación. Un factor estacional las incorpora a la estimación de la forma más sencilla: reconoce qué tareas tardan más en determinadas épocas del año y las desplaza o planifica el recargo.

A partir del inicio real, la IA asigna cada tarea de Merlin Project a una estación del año. Los tiempos de secado y de espera dependientes del clima los modela como tareas propias sin asignación, para que su duración siga siendo medible. Las vacaciones de empresa y los festivos los define en los ajustes del proyecto, en Calendario; de lo contrario, las semanas de vacaciones aparecen en la estadística como retraso.

En nuestro archivo de ejemplo

El invierno costó tiempo a cada obra gruesa: un 15 por ciento con el contratista fiable, un 48 con Vargas. Vargas ya construía en verano una cuarta parte más lento de lo planificado. En un proyecto, la obra gruesa se detuvo 15 días laborables por heladas. La regla resultante: no planificar obra gruesa entre diciembre y febrero o incluir en el precio la construcción en invierno con factor y costes. El patrón de Vargas no figuraba en ningún registro de riesgos. Solo se hace visible cuando alguien agrupa los valores reales por empresa y mes.

Un riesgo de invierno en la obra gruesa

El forjado de la planta baja cayó en diciembre. El riesgo Heladas y mal tiempo en la obra gruesa ha ocurrido, con 7 días de retraso y 8.400 euros de coste. Con fecha, valores reales y riesgo, la tarea aporta todo lo que necesita un factor estacional.

El prompt para probarlo usted mismo

Agrupa todas las tareas terminadas de obra gruesa y de secado de los
proyectos compartidos por mes de inicio real y por empresa ejecutora.
Calcula para cada grupo el factor duración real frente a planificada.
¿Hay meses o empresas en los que las mismas tareas tardan claramente
más? ¿Qué factores debería aplicar para una obra gruesa en enero?

7. Esfuerzo de proyecto y costes: lo que cuesta el trabajo propio

Los costes se desvían en dos puntos: en los servicios externos, por modificados y subidas de precios, y en el trabajo propio. Muchos pasan por alto la segunda fuente porque no aparece en ninguna factura. Con unos honorarios a tanto alzado, el estudio asume cada hora subestimada; qué tipo de contrato reparte qué riesgo lo explica el artículo sobre precio fijo, T&M y reembolso de costes. En el proyecto en curso, el análisis del valor ganado muestra la desviación, y el índice de rendimiento del costo CPI, el rendimiento por euro gastado. A lo largo de proyectos cerrados, de ahí surge un factor de cálculo, y las ofertas y los honorarios reflejan el esfuerzo que su equipo realmente necesita.

Con una tarifa por hora para cada recurso, Merlin Project calcula a partir del trabajo planificado y real los costes planificados y reales; cómo crear costes lo muestra el capítulo Costes. Los indicadores del análisis del valor ganado (PV, EV, AC, CPI, SPI) se refieren a la fecha de estado de los ajustes del proyecto. Para ver la carga de trabajo a través de los proyectos, todos comparten un pool de recursos. Además, el servidor MCP proporciona valores distribuidos en el tiempo para costes, trabajo y valor ganado, es decir, la evolución por semanas o meses.

En nuestro archivo de ejemplo

El estudio subestimó su proyecto de ejecución en cada proyecto, en el caso normal un 15 por ciento. En diez proyectos esto suma 118 días laborables o 86.848 euros con una tarifa de 92 euros por hora, que no figuraban en ningún honorario. Los mismos datos contienen un segundo patrón: cuando tres proyectos estaban a la vez en proyecto de ejecución, el factor subía a entre 1,35 y 1,37, y la dirección de proyecto notificaba sobrecarga. Para el cálculo significa un recargo del 15 por ciento sobre la planificación propia y como máximo dos proyectos en paralelo en esta fase. En los costes externos destaca la subida de los costes de construcción en 2021 y 2022: afectó a cada proyecto iniciado en esos años, con entre 20.000 y 137.800 euros por encima del presupuesto.

Esfuerzo de proyecto en la comparación planificado/real

Las columnas muestran Trabajo planificado, Trabajo real, Coste planificado y Coste real. La Fase 5 Proyecto de ejecución del Residencial del Parque costó 69.920,00 € en lugar de 51.520,00 €. El problema de abajo nombra la causa: Dirección de proyecto sobrecargada.

El prompt para probarlo usted mismo

Lee de todos los proyectos compartidos el trabajo planificado y real y
los costes planificados y reales por fase. Calcula para cada fase el
factor real frente a planificado y el sobrecoste en euros. Comprueba
además, a partir de las fechas reales, cuántos proyectos estaban a la vez
en proyecto de ejecución y si el factor sube en ese caso.

8. Riesgos y problemas: calibrar probabilidades

Un registro de riesgos contiene estimaciones: ¿con qué probabilidad ocurre un riesgo y cuánto cuesta entonces? Al final del proyecto se sabe qué pasó. La comparación de ambas cosas se llama calibración. Si un equipo bien calibrado valora riesgos con un 30 por ciento, ocurren aproximadamente tres de cada diez. Si la tasa se desvía mucho, el registro dirige la atención a los puntos equivocados. Con valores calibrados, el siguiente registro arranca con los riesgos que en su caso realmente ocurren. Los problemas completan la imagen con sucesos que nadie esperaba como riesgo.

En Merlin Project, el tipo de adjunto Riesgo tiene, además de probabilidad e impacto, cuatro campos para el desenlace: Ha ocurrido, Coste, Retraso y Lecciones aprendidas. Coste y retraso documentan; Merlin no los incorpora al plan ni al presupuesto. Rellene los campos como muy tarde al cierre del proyecto; de lo contrario, el registro se queda en una lista de temores. Las perturbaciones imprevistas las registra como Problema. Los fundamentos los explica el capítulo Gestión de riesgos; el control en el proyecto en curso, la guía sobre gestión de riesgos con Merlin Project.

En nuestro archivo de ejemplo

El registro madura con el tiempo. Los cuatro primeros proyectos contienen en total siete riesgos; el retraso de las ventanas solo lo recogían como problema. A partir del quinto proyecto, el estudio incorporó las lecciones de los proyectos anteriores como riesgos con medidas. La calibración trajo dos correcciones. El riesgo de subsuelo figuraba en seis obras nuevas con un 30 por ciento en el registro y ocurrió una vez, en un solar con edificación existente; para urbanizaciones nuevas bajó al 15 por ciento. El retraso en la entrega de López, que ocurrió en los tres encargos, lo resolvió un cambio de proveedor. Un tercer patrón, el contratista de obra gruesa lento en invierno, no apareció en ningún registro. Por eso una knowledge base necesita ambas fuentes: riesgos documentados y desviaciones puras en los valores reales.

Un riesgo cerrado

Retraso en la entrega de ventanas, ocurrido con 12 días de retraso y 10.800 euros de coste. Solo los campos de cierre, aquí como columnas del registro, convierten un temor en un dato para la calibración.

El prompt para probarlo usted mismo

Lee de todos los proyectos compartidos los adjuntos de riesgo con título,
probabilidad, Ha ocurrido, Coste, Retraso y Lecciones aprendidas, así
como todos los adjuntos de problema. Agrupa los riesgos similares entre
proyectos. Compara para cada riesgo la probabilidad estimada con la tasa
observada. Enumera además los problemas que aparecieron varias veces pero
no figuraban como riesgo en ningún registro. Crea a partir de ello un
registro inicial para un proyecto nuevo con probabilidad propuesta,
impacto típico y medida probada.

9. Lessons learned: reglas con ámbito de aplicación

Las lecciones aprendidas aportan la justificación de las cifras: por qué algo tardó más y qué ayuda la próxima vez. Su valor depende de dos cosas. La primera es la actitud en la reunión de cierre. Norman Kerth formuló en 2001 para ello la «Prime Directive» de la retrospectiva: «Independientemente de lo que descubramos, entendemos y creemos de verdad que todos hicieron el mejor trabajo posible, dado lo que sabían en ese momento, sus capacidades y habilidades, los recursos disponibles y la situación concreta.» Quien busca culpables no obtiene respuestas sinceras. La segunda es el ámbito de aplicación: una lección de una rehabilitación de un edificio antiguo no vale automáticamente para una obra nueva, y sin indicar para qué vale se queda en anécdota. Con ámbito de aplicación, la lección la encuentran también los compañeros y compañeras que no participaron. El marco formal lo describe el proceso de cierre.

En Merlin Project, adjunte al hito «Cierre del proyecto» un adjunto de tipo Información con las lessons learned: qué salió mal, qué funcionó y para qué tipo de proyecto vale la lección. Las lecciones sobre riesgos concretos van en su campo Lecciones aprendidas; allí siguen vinculadas a la frecuencia, el coste y el retraso. Un tipo propio «Lessons learned» para informaciones lo crea en los ajustes del proyecto, en Listas de valores.

En nuestro archivo de ejemplo

Dos rehabilitaciones de edificios antiguos muestran la fuerza de una lección con ámbito de aplicación. En el edificio modernista, los operarios encontraron amianto durante el vaciado interior: 22 días laborables de paralización y 38.000 euros de modificado. La lección decía «estudio de sustancias peligrosas antes de licitar, válido para toda rehabilitación de edificio existente». En la posterior casa de entramado, el estudio encargó la investigación antes de licitar; así, el saneamiento ya figuraba en el pliego de mediciones.

Con los cambios a petición de promotores privados ocurrió algo parecido. Los Pareados Las Viñas perdieron 15 días laborables y 37.500 euros por cambios en los acabados; por eso, una vivienda unifamiliar posterior recibió una fecha límite de elección de materiales antes del inicio de los acabados.

Lessons learned al cierre del proyecto

Un adjunto de información en el hito Cierre del proyecto registra qué salió mal y qué funcionó. A través del servidor MCP, la IA lo lee junto con los valores reales.

El prompt para probarlo usted mismo

Lee los adjuntos de información del hito «Cierre del proyecto» y el campo
Lecciones aprendidas de todos los riesgos de los proyectos compartidos.
Formula a partir de ellos reglas transferibles. Indica para cada regla a
qué tipo de proyecto, fase u oficio se aplica, en cuántos proyectos está
respaldada y en qué proyectos se basa. Omite los casos aislados que solo
ocurrieron una vez y no indican causa.

Del archivo a la knowledge base

De los nueve análisis surge la knowledge base. Para que el equipo la use, necesita una forma fija que crezca después de cada proyecto. Ha dado buen resultado un proyecto de documentación con cinco capítulos que la IA rellena a partir de los proyectos de Merlin:

Knowledge-base-proyectos/
├── index.adoc                 Para qué, estado de los datos, uso
├── 1-proyectos/               una ficha por proyecto cerrado
├── 2-indicadores/             factores de estimación, rangos, costes
├── 3-riesgos-y-lecciones/     catálogo de riesgos, lessons learned, registro inicial
├── 4-plantillas/              prompts y listas de comprobación
└── 5-metodologia/             base de datos, reglas de mantenimiento, glosario

La ficha de cada proyecto recoge tipo de proyecto, periodo, plazo y costes en comparación planificado/real, además de las cinco mayores desviaciones, los riesgos ocurridos y las lessons learned. La IA calcula los capítulos 2 y 3 a partir de todas las fichas, y cada valor remite a los proyectos de los que procede. Como archivos AsciiDoc, adoc Studio exporta los capítulos como sitio web, cuya navegación surge de carpetas y archivos; una estructura lista para adaptar la ofrece la plantilla de proyecto para documentación. Como la knowledge base contiene nombres de clientes, costes y fechas, debe estar en un servidor protegido.

Después de cada proyecto cerrado se añade una ficha, la IA recalcula los capítulos 2 y 3 y usted vuelve a exportar el sitio web.

Qué debería mantener a partir de hoy

Cinco hábitos deciden si su archivo mostrará patrones o lagunas dentro de un año. La calculadora muestra dónde está hoy.

1. Registrar los valores reales a tiempo: inicio real, finalización real y trabajo real de cada tarea terminada, también en tiempos de espera y licencias.
2. Clasificar las tareas, lo más sencillo con un campo para el tipo de tarea o etiquetas en una plantilla de proyecto común. Los nombres de tarea fijos de la plantilla cumplen la misma función, siempre que nadie los modifique.
3. Asignar los socios externos, como recurso o campo, para poder medir su puntualidad.
4. Cerrar los riesgos con Ha ocurrido, Coste, Retraso y Lecciones aprendidas, como muy tarde al cierre del proyecto.
5. Lessons learned con ámbito de aplicación como adjunto de información en el hito «Cierre del proyecto».

Límites del análisis

Una knowledge base aporta valores de experiencia que ganan precisión con cada proyecto. Tiene cuatro límites.

• Muestras pequeñas. Dos entregas tardías en dos encargos son un indicio. Pida a la IA que indique el número de proyectos de cada valor y trate como provisionales los valores de menos de cinco proyectos.
• Correlación sin causa. Si el contratista de obra gruesa fue más lento en invierno por el tiempo, por su carga de trabajo o por ambas cosas, las cifras solas no lo dicen. La justificación está en las lessons learned.
• Condiciones cambiantes. Un equipo nuevo, un procedimiento nuevo en el ayuntamiento o un mercado distinto devalúan los valores antiguos. Feche cada valor y pondere más los proyectos recientes.
• Solo acceso de lectura. El servidor MCP de Merlin Project actualmente solo lee. Los factores, colchones y registros iniciales los traslada usted mismo al nuevo plan. Los clientes en la nube como Claude envían los datos del plan consultados al proveedor; un modelo local los mantiene en su Mac.

Sobre esta knowledge base se apoya el siguiente paso. Con el registro inicial del capítulo 3 y los rangos del capítulo 2, usted controla los riesgos del proyecto en curso; cómo funciona en Merlin Project lo muestra la guía sobre gestión de riesgos con Merlin Project e IA.

Si tiene alguna pregunta sobre este artículo del blog o desea debatirlo, esperamos su contribución en nuestro foro.