9 obstáculos a la transferencia de conocimiento en organizaciones basadas en proyectos

Cada proyecto enseña algo a la organización. La parte difícil es conseguir que el siguiente proyecto pueda aprovecharlo. En la mayoría de empresas las lecciones existen, la documentación incluso es razonable y, aun así, el equipo nuevo vuelve a tropezar con la misma piedra con la que tropezó otro equipo seis meses antes.

Esa distancia entre el conocimiento que se genera y el que se aplica es la mayor fuente de desperdicio evitable en organizaciones basadas en proyectos. Una PMO capaz de cerrarla convierte el portafolio entero en un sistema que aprende. Una PMO que no lo hace condena cada proyecto a empezar de cero.

El marco que sigue se apoya en la investigación de B. H. Reich en PMJ sobre gestión del conocimiento en proyectos, actualizada a cómo trabajan en 2026 los equipos distribuidos y asistidos por IA.

Por qué la transferencia de conocimiento en proyectos es un problema aparte

Gestionar el conocimiento en un laboratorio de I+D o en un equipo de producto es complicado, pero al menos el equipo no se mueve. En proyectos la lógica es otra: los equipos se forman, entregan y se disuelven. La experiencia que construyó un proyecto se va por la puerta, muchas veces antes de que a nadie se le ocurra capturarla.

Ese rasgo estructural lo cambia todo. La PMO no está gestionando una wiki, está coordinando una carrera de relevos en la que el testigo tiene que sobrevivir a una docena de cambios de mano. Los obstáculos que vienen a continuación se reducen siempre a uno de estos tres fallos: lecciones que nunca se capturan, lecciones capturadas pero imposibles de encontrar, o lecciones disponibles que nadie consulta.

1. Lecciones que nunca se aprenden de verdad

El fallo más habitual es también el más fácil de describir y el más difícil de corregir. Se celebra la retrospectiva, alguien toma notas, las notas acaban en una carpeta y nadie las abre en el siguiente proyecto.

La solución no pasa por hacer más retrospectivas, sino por conseguir que las lecciones pasadas sean imposibles de ignorar al arrancar uno nuevo. Dos rutinas resuelven la mayor parte del problema:

• Mantener un repositorio buscable, etiquetado por cliente, sector y tipo de proyecto, para que el equipo de kickoff pueda recuperar solo las lecciones que encajan con el trabajo que tiene delante.
• Tratar la línea base anterior como un artefacto, no como un recuerdo. ITM Platform guarda el calendario, esfuerzo y coste aprobados de cada proyecto como una línea base reutilizable, de modo que el nuevo equipo ve exactamente qué se planificó, qué cambió y por qué antes de comprometerse con sus propias estimaciones.

2. Elegir mal el equipo para el trabajo

Aunque haya gente competente disponible, la combinación adecuada de capacidades para un proyecto concreto es difícil de detectar. La experiencia acumulada, el know-how tácito y la dimensión multicultural en proyectos internacionales no se ven en un CV.

Quien planifica nunca es experto profundo en todas las áreas técnicas, así que casi siempre habrá un desajuste entre los requisitos y la capacidad real del equipo. El resultado es un equipo incapaz de transferirse conocimiento internamente porque parte del que necesita ni siquiera está en la sala.

Una PMO que mantiene perfiles estructurados de roles previos, capacidades y resultados de proyecto (a menudo como campos personalizables sobre personas y proyectos) le da al planificador una oportunidad razonable de acertar con la composición a la primera.

3. Volatilidad en los órganos de gobierno

Cuando un miembro del gobierno del proyecto se va a mitad de camino (patrocinador ejecutivo, presidente del comité de seguimiento, incluso el jefe de proyecto), el equipo no solo pierde un nombre en un organigrama. Pierde el contexto no escrito: por qué se recortó el alcance, por qué se prefirió a un determinado proveedor, qué nunca aprobará el patrocinador por mucho que se le presente con otro envoltorio.

La mitigación pasa por documentar las decisiones y su razón, no solo los resultados. Un informe de seguimiento que dice “se eliminó la funcionalidad X” sirve mucho menos seis meses después que uno que dice “se eliminó la funcionalidad X porque el patrocinador señaló riesgo regulatorio en el segundo trimestre”.

4. Falta de reconocimiento de la función de gestión del conocimiento

En la mayoría de organizaciones, la transferencia de conocimiento no tiene dueño. Los jefes de proyecto piensan que la hace la PMO. La PMO piensa que la hacen los responsables de área. Los responsables de área piensan que ocurre por contagio. Nadie se equivoca, y nadie está haciendo el trabajo.

Las PMO más efectivas tratan la transferencia de conocimiento como un entregable con nombre, con cadencia, con presupuesto y con una persona responsable. No hace falta montar un programa enorme; basta con que aparezca en la descripción del puesto de alguien.

5. Integración insuficiente del conocimiento

Los proyectos grandes mezclan expertise de varios dominios. El riesgo no es que cada experto se equivoque en lo suyo, sino que nadie sea responsable de encajar las piezas de forma coherente.

Aquí es donde el jefe de proyecto se gana el papel. El PM no es el experto más profundo en ningún tema concreto y no debería disimularlo. Su trabajo es asegurarse de que los expertos se hablan, de que las interfaces entre sus aportaciones están explícitas y de que el resultado integrado sigue teniendo sentido para el cliente.

6. Transferencia incompleta desde proveedores y consultores externos

Los proyectos complejos casi siempre incorporan especialistas externos. La transferencia entre el consultor y el equipo interno es donde más conocimiento crítico se pierde, y casi siempre por motivos comerciales comprensibles: el consultor quiere proteger su propiedad intelectual, el equipo va con prisas y nadie agenda un traspaso serio.

La mayoría de los fallos que se atribuyen a “el proveedor no entregó” son en realidad fallos de transferencia de conocimiento en la fase de diseño. Algunas medidas preventivas ayudan:

• Definir los artefactos de traspaso en el contrato, no después del kickoff.
• Exigir una demostración funcional, no una presentación, como prueba de la transferencia.
• Tener desde el primer día a una persona del equipo interno acompañando al consultor.

7. Bajas en el equipo

Cuando una persona clave se va, esté previsto o no, se marcha con un trozo irrecuperable de contexto. Una parte se puede documentar; otra parte es directamente irrecuperable.

El objetivo realista no es capturarlo todo, sino capturar lo más caro de volver a aprender. Una entrevista corta en el momento de la salida, centrada en las decisiones tomadas, los proveedores en los que se confía y las trampas que conviene esquivar, vale por diez “documentos de salida” genéricos.

Para profundizar en continuidad de equipo y asignación de recursos, nuestra entrada sobre gestión de recursos humanos en proyectos entra en detalle en cómo planificar estos traspasos antes de que se produzcan.

8. Sin mapa de conocimiento por rol

La mayoría de equipos no sabe en realidad quién sabe qué. El resultado es una ruleta de escalado: la pregunta cae en la persona más visible, no en la más informada, las decisiones las toma quien no debería y los expertos adecuados se quedan enterrados.

Un mapa de conocimiento por roles (quién maneja qué capacidad, quién ya ha hecho este tipo de trabajo, quién es la segunda opción si la primera no está disponible) hace legible la competencia del equipo. Investigadores como Crowston y Kammerer, o Faraj y Sproull, llevan décadas documentando que los equipos que mantienen este mapa obtienen mejores resultados en trabajo intensivo en integración.

En 2026 el mapa no tiene por qué ser un documento estático. Con herramientas de portafolio asistidas por IA se le puede preguntar al sistema directamente. PMPilot, el asistente de IA de ITM Platform, permite a la PMO interrogar el portafolio en lenguaje natural, incluyendo preguntas del tipo “quién ha trabajado en proyectos de migración de datos en los últimos dos años” gracias a su capa de análisis de datos.

9. Pérdida de conocimiento entre fases

A medida que el proyecto pasa de diseño a construcción, de construcción a pruebas, de pruebas a operación, la composición del equipo cambia. Cada traspaso es una oportunidad de perder contexto.

La documentación escrita por sí sola rara vez sobrevive intacta al viaje. Se cuelan interpretaciones subjetivas, desaparece el porqué que justificaba una elección de diseño y la fase siguiente acaba reconstruyendo a oscuras una decisión que ya estaba tomada.

Dos rutinas amortiguan ese efecto:

• Capturar el porqué, no solo el qué. Un párrafo breve explicando por qué se tomó una decisión evita que la siguiente fase la reabra.
• Usar multimedia cuando aporta. Una grabación de dos minutos del responsable saliente suele ser más clara que dos páginas de prosa.

Cómo convierte una PMO estos obstáculos en un sistema

Ninguno de estos nueve obstáculos se resuelve con una plantilla o una herramienta aislada. Lo que hace una PMO seria es construir un sistema discreto y repetible:

• Una línea base de lo que se planificó en cada proyecto, para que el siguiente equipo arranque desde datos, no desde la memoria.
• Una biblioteca de qué cambió y por qué, para que el contexto sobreviva a los traspasos.
• Un mapa de capacidades que se consulta, no solo se mantiene, para que la gente adecuada acabe en el trabajo adecuado.
• Un protocolo de traspaso, tanto para transiciones internas del equipo como para salidas de proveedores externos.

Cada elemento es una rutina pequeña. Apilados, son lo que separa a una organización que aprende de otra que se limita a ejecutar proyectos.

Próximos pasos

• Echa un vistazo a nuestros artículos sobre PMO para seguir construyendo una oficina de proyectos orientada al aprendizaje.
• Descubre cómo ITM Platform da visibilidad de portafolio, líneas base y análisis con IA desde un único espacio de trabajo.