Serie PM&IA: Detectando problemas antes de que exista el proyecto (GPT Offer-Contract CrossCheck)
- hace 12 minutos
- 12 Min. de lectura
Hay una fase del proyecto que casi nunca aparece en los roadmaps oficiales del Project Manager. No sale en los manuales, no aparece en la mayoría de metodologías y técnicamente… el proyecto todavía ni siquiera existe.
Ese instante en el que:
Las necesidades del cliente ya se han aclarado,
el comercial ya ha consolidado las ofertas,
las distintas divisiones han enviado sus alcances,
el contrato entra en revisión final,
y alguien lanza la frase:
“¿Puede el PM echarle una última revisión antes de emitir?”
Y de repente el Project Manager entra en escena antes incluso del kick-off, no para planificar, no para ejecutar, sino para intentar detectar problemas que todavía no han ocurrido… pero que probablemente acabarán ocurriendo.
Porque muchos de los grandes problemas de ejecución no nacen en planta, ni durante commissioning, ni siquiera durante el proyecto. Nacen mucho antes, en:
una exclusión mal trasladada,
límites ambiguos,
una interface sin dueño claro,
un requisito RFQ que desapareció entre revisiones,
o dos divisiones asumiendo cosas distintas.
Y lo peligroso es que, en esa fase, casi todo parece correcto, cada documento, por separado, tiene sentido.
El problema aparece cuando empiezas a cruzarlos.
Ahí es donde empiezan a aparecer:
contradicciones,
huecos de alcance,
duplicidades,
responsabilidades ambiguas,
y futuros claims todavía invisibles.
Y normalmente, cuando esos problemas salen a la luz… el contrato ya está firmado.
La realidad: el PM acaba revisando contratos antes de su firma
Sobre el papel, la fase comercial pertenece a ventas, proposal managers, equipos técnicos, legal o departamentos comerciales, y técnicamente es cierto.
El problema es que el proyecto todavía no existe para casi nadie… excepto para el futuro PM. Porque mientras otros ven ofertas, precios, concidiones y cierres comerciales, el Project Manager ya empieza a imaginar interfaces, commissioning, recursos, problemas en planta, claims, retrasos, zonas grises y futuras discusiones con el cliente.
Y por eso ocurre algo muy habitual en proyectos industriales complejos: el PM acaba entrando en la revisión final antes de entregarla al cliente. No porque sea “su responsabilidad oficial”, sino porque muchas veces es la única persona que realmente está pensando en ejecución, especialmente en proyectos donde la complejidad documental crece rápidamente:
RFQs enormes,
ofertas parciales de distintas divisiones,
anexos técnicos,
interfaces cruzadas,
revisiones constantes,
y contratos modificados múltiples veces.
Y ahí aparece un patrón muy típico: cada división revisa “su parte, pero muy poca gente revisa lo que ocurre ENTRE las partes, y precisamente ahí nacen muchos de los problemas más caros del proyecto.
Porque normalmente las contradicciones no están dentro de un documento, sino entre documentos, entre divisiones, o entre distintas interpretaciones del alcance.
Y el PM, debido a su experiencia en ejecución real, suele detectar cosas que para otros todavía son invisibles.
Por ejemplo:
interfaces sin dueño claro,
responsabilidades duplicadas,
límites ambiguos,
exclusiones peligrosas,
requisitos RFQ desaparecidos,
o wording comercial que puede convertirse en un claim meses después.
Por eso, aunque oficialmente “no sea su trabajo”… muchos PMs terminan convirtiéndose en:
la última línea de defensa antes de firmar.
El verdadero problema no son los documentos
El problema real no suele estar dentro de un documento. El problema aparece entre documentos, Y esa diferencia lo cambia todo, porque normalmente cada documento, por separado, parece razonable: La oferta mecánica tiene sentido, la oferta de automatización también, el contrato parece correcto y los anexos, vistos individualmente, no generan alarma.
El problema empieza cuando intentas construir una visión completa del proyecto uniendo todas las piezas. Ahí es donde empiezan a aparecer cosas mucho más peligrosas, porque los proyectos complejos no fallan por un único gran error.
Normalmente fallan por pequeñas inconsistencias, interpretaciones distintas, ownership ambiguo, assumptions incompatibles, o huecos invisibles entre divisiones. Y precisamente esos problemas son los más difíciles de detectar manualmente, especialmente cuando hablamos de cientos de páginas, múltiples revisiones, distintos departamentos, versiones modificadas, y semanas de intercambios documentales.
En ese punto el problema deja de ser técnico, y pasa a ser: un problema de complejidad documental.
Y ahí aparece una realidad incómoda: nadie tiene realmente toda la información consolidada en la cabeza. Cada equipo conoce su scope, sus límites, sus riesgos, pero muy pocas personas tienen una visión cruzada completa del ecosistema contractual y técnico del proyecto, y precisamente ahí es donde suelen esconderse:
los futuros claims,
los conflictos de alcance,
las responsabilidades ambiguas,
y las discusiones que aparecerán meses después durante ejecución.
Muchos de estos problemas no son “errores evidentes”. Son cosas mucho más sutiles, como por ejemplo: una exclusión que desapareció entre versiones, una parte sin ownership claro, un requirement RFQ no trasladado, una responsabilidad duplicada, un wording demasiado abierto, o una interface definida de forma distinta por dos divisiones.
Nada de eso parece dramático durante la fase comercial, hasta que el proyecto arranca, Y entonces aparece el clásico:
“Nosotros entendíamos otra cosa.”
Por eso la revisión cruzada documental no consiste en:
leer PDFs,
resumir documentos,
o buscar palabras clave.
Consiste en: conectar piezas dispersas de información hasta construir la imagen real del proyecto.
Ejemplos reales de problemas típicos
La mayoría de problemas contractuales importantes no aparecen como errores gigantes y evidentes, sin que aparecen como pequeñas grietas documentales. Y durante la fase comercial muchas veces parecen detalles menores, hasta que el proyecto empieza.
Problema típico 1 — El alcance huérfano
Uno de los riesgos más habituales en proyectos industriales complejos es que exista trabajo que aparentemente “alguien hará”… pero nadie ha asumido realmente.
Normalmente ocurre entre divisiones, proveedores, cliente, integradores o interfaces de instalación.
Parte eléctrica asume que parte mecánica suministra los cables de conexión de los instrumentos.
Automatización interpreta que los interfaces de comunicación los pone el cliente.
Nadie define quién realiza el cableado entre skid y MCC.
El suministro de instrumentos aparece parcialmente duplicado… pero incompleto.
El piping externo queda sin ownership claro.
FAT integrado depende de equipos que ninguna división ha incluido.
El SAT requiere personal onsite no asignado a ningún alcance.
La integración software/hardware queda implícita pero no definida.
Conexión y adaptación de utilities interpretado como alcance del cliente
Durante oferta nadie detecta el gap, pero durante ejecución aparecen retrasos, discusion, coste adicional, claims.. y normalmente cada parte interpreta que: “Eso lo hacía otro.”
Problema típico 2 — Exclusiones que desaparecen
Otro patrón extremadamente común es que determinadas exclusiones sobrevivan en versiones iniciales… pero desaparezcan silenciosamente durante consolidación contractual.
Una exclusión aparece en oferta parcial pero no en oferta consolidada.
Legal simplifica wording y elimina limitaciones importantes.
“Civil works excluded” desaparece del contrato final.
El cliente devuelve contrato con modificaciones sutiles no detectadas.
Aclaraciones comerciales nunca llegan a los anexos finales.
Partidas críticas no sobreviven tras revisiones sucesivas.
El cliente interpreta que el alcance quedó finalmente incluido, y el problema normalmente aparece meses después, durante ejecución, o directamente en planta.
Problema típico 3 — Límites de alcance ambiguos
Muchas interfaces parecen claras… hasta que alguien tiene que instalar realmente el sistema, y ahí aparecen los problemas.
No se define quién suministra cableado externo.
Utilities sin punto concreto de conexión.
Diferencias entree P&ID y contrato.
“By others” sin identificar quiénes son realmente “others”.
Interfaces mecánicas definidas distinto en distintas divisiones.
Límites de suministro diferentes entre oferta técnica y comercial.
Durante ejecución nadie tiene claro dónde termina una responsabilidad, dónde empieza la siguiente, o quién debe asumir trabajos adicionales.
Problema típico 4 — Requisitos RFQ que desaparecen
Uno de los riesgos más peligrosos es que requisitos del RFQ original se pierdan entre revisiones, clarificaciones y consolidaciones, especialmente en proyectos largos y con múltiples actores.
FAT completo pedido en RFQ pero reducido en oferta.
Training onsite no trasladado al contrato.
Requisitos documentales omitidos en consolidación.
SAT extendido asumido pero no presupuestado.
Redundancias técnicas desaparecidas entre versiones.
Requisitos regulatorios mencionados solo parcialmente.
Obligaciones de documentación bilingüe no arrastradas.
El cliente sigue esperando los requerimientos originales... aunque nadie lo haya detectado durante cierre contractual.
Problema típico 5 — Duplicidades entre divisiones
A veces el problema no es un gap, es justo lo contrario: dos partes distintas asumen exactamente el mismo alcance.
Dos divisiones incluyen commissioning.
Instalación parcialmente duplicada.
Ambos equipos incluyen project management onsite.
Cableado incluido dos veces.
Equipos compartidos presupuestados por varias partes.
Dos proveedores asumen la misma parte de la integración.
Durante oferta puede parecer “más seguro”, pero durante ejecución se convierte en sobrecostes,
conflictos internos, pérdida de margen, y ownership ambiguo.
Problema típico 6 — Wording comercial peligroso
Y en ocasiones el mayor riesgo no es técnico, es simplemente una frase mal escrita, porque determinadas expresiones comerciales parecen inocentes… hasta que alguien intenta interpretarlas contractualmente.
“Complete solution”.
“Turnkey-ready”.
“Supplier will support all activities”.
“All necessary works included”.
“Integration by supplier”.
“Operational readiness guaranteed”.
“Any required modification”.
Obligaciones abiertas difíciles de limitar durante ejecución, especialmente cuando aparecen cambios, situaciones no previstas, o diferencias de interpretación con cliente.
Lo peligroso: casi nunca parecen graves al principio
Y ese es precisamente el problema. La mayoría de estos issues no parecen críticos durante oferta, no generan alarma inmediata, y muchas veces sobreviven hasta firma.
Pero durante ejecución se convierten en claims, retrasos, retrabajos, conflictos internos, discusiones con cliente, o pérdidas económicas.
Y precisamente por eso la revisión cruzada previa es tan importante.
Porque cuando el proyecto arranca… normalmente ya es demasiado tarde para corregir muchas de estas cosas.
El problema moderno: demasiada complejidad documental
Hace años una oferta compleja podía revisarse relativamente bien de forma manual. Hoy eso cada vez es más difícil porque los proyectos industriales modernos generan cantidades enormes de información: RFQs gigantes, annexes técnicos, condiciones comerciales, ofertas parciales, múltiples revisiones, comentarios legales, correos cruzados, versiones modificadas, y contratos que evolucionan constantemente durante negociación.
Y el problema no es únicamente el volumen. El verdadero problema es:
la cantidad de relaciones cruzadas entre documentos.
En muchos casos el problema deja de ser técnico. Pasa a ser un problema cognitivo, Porque mantener manualmente en la cabeza cientos de páginas, múltiples revisiones, distintos scopes y cambios contractuales empieza a ser prácticamente imposible. Incluso equipos muy experimentados pueden no detectar determinadas inconsistencias. No por falta de conocimiento, sino porque la complejidad documental ya es demasiado alta.
Aquí es donde la IA empieza a aportar valor real
Y este es probablemente uno de los puntos más interesantes de la IA aplicada a Project Management. No hablamos de usar IA para generar texto bonito, resumir PDFs, o hacer automatizaciones superficiales. Hablamos de utilizar IA como herramienta de apoyo al análisis complejo, especialmente en tareas donde existe mucha documentación, muchas relaciones cruzadas, múltiples versiones, y patrones difíciles de detectar manualmente.
La IA tiene algo especialmente útil en este contexto: capacidad para mantener contexto y relacionar información dispersa, y eso encaja perfectamente con uno de los mayores problemas de la fase pre-award:
construir una visión coherente del proyecto completo a partir de documentos fragmentados.
La clave: ampliar capacidad de análisis
Lo interesante no es “delegar” el criterio del PM. Lo interesante es ampliar su capacidad de revisión.
Porque una IA bien orientada puede ayudar a:
detectar inconsistencias,
localizar contradicciones,
comparar versiones,
identificar patrones,
estructurar riesgos,
y señalar posibles zonas grises.
Mientras el Project Manager sigue aportando:
experiencia,
criterio,
contexto,
y entendimiento real de ejecución.
Y precisamente esa combinación "IA + experiencia real de Project Management" es la base de todo el enfoque PM&IA.
PM&IA — Aplicando IA a revisión contractual real
Dentro de la serie PM&IA llevamos tiempo explorando una idea muy concreta: cómo utilizar IA para ayudar en el trabajo real del Project Manager, no para sustituir criterio, no para automatizar decisiones críticas y tampoco para convertir la gestión de proyectos en “chatbots que responden cosas”.
La idea es mucho más práctica. Utilizar IA para ampliar capacidad de análisis, reducir puntos ciegos, estructurar información compleja, detectar patrones, y ayudar a identificar riesgos antes de que aparezcan durante ejecución.
Y uno de los escenarios donde esto más sentido tiene es precisamente la revisión cruzada documental pre-award. Porque aquí el problema no es únicamente leer documentos, el verdadero problema es: entender cómo todos esos documentos interactúan entre sí.
Nace “LK_PMIA Offer-Contract CrossCheck”
Con esa idea construimos: LK_PMIA Offer-Contract CrossCheck, un GPT especializado en revisión cruzada de RFQs, ofertas, contratos, anexos y documentación técnico-comercial de proyectos industriales.
Lo importante no es solamente lo que revisa. Lo importante es cómo trabaja, porque el objetivo nunca fue crear un simple resumidor documental. El objetivo era construir un sistema capaz de:
detectar contradicciones,
identificar gaps de alcance,
localizar ownership ambiguo,
encontrar duplicidades,
revisar interfaces,
y señalar riesgos potenciales antes del inicio del proyecto.
El GPT fue diseñado específicamente pensando en cómo revisa un PM experimentado, es decir, buscando problemas futuros, interfaces débiles, wording peligroso, responsabilidades difusas, y posibles conflictos de ejecución.
No analiza documentos “como un abogado”. Los analiza como alguien que tendrá que ejecutar después el proyecto, y eso cambia completamente el enfoque de revisión.
La parte más interesante: el contexto acumulado
Y aquí aparece probablemente uno de los aspectos más potentes del sistema. Durante la revisión documental el GPT acumula contexto de toda la fase pre-award, y eso transforma completamente el tipo de análisis posible, porque ya no hablamos solamente de subir documentos, resumir PDFs, o responder preguntas aisladas.
Hablamos de construir una visión estructurada del ecosistema contractual y técnico completo del proyecto. Y una vez toda esa información está consolidada el Project Manager puede empezar a hacer preguntas mucho más profundas.
Por ejemplo:
dónde existen interfaces débiles,
qué exclusiones son peligrosas,
qué divisiones tienen ownership ambiguo,
dónde pueden aparecer futuros claims,
qué RFQ requirements desaparecieron,
qué wording puede generar conflicto,
o qué riesgos de commissioning todavía no están visibles.
En cierto modo, el GPT termina convirtiéndose en una memoria estructurada y analítica de toda la fase comercial y contractual del proyecto. Y eso tiene muchísimo valor porque muy pocas personas dentro de un proyecto tienen realmente toda la información consolidada, todas las revisiones cruzadas, y todas las relaciones entre documentos simultáneamente presentes.
Así que aparte del resumen que te da el propio GPT una vez recibida toda la información, es importante resaltar nuevamente que una vez subida toda esa documentación, el PM puede realizar búsquedas, hacer preguntas y conseguir información en más profundidad y detalle con relación a la documentación aportada.
La clave no es la IA. la clave es: combinar IA con experiencia real de ejecución.
Cómo utilizar “LK_PMIA Offer-Contract CrossCheck”
El GPT está pensado para trabajar exactamente igual que lo haría una revisión documental real durante fase pre-award. La idea no es subir todos los documentos desordenadamente y pedir un resumen rápido. La idea es construir progresivamente el contexto completo del proyecto.
Dónde encontrar el GPT
LK_PMIA Offer-Contract CrossCheck está disponible en el siguiente link:
Cómo empezar
El GPT incorpora dos iniciadores de conversación:
“Di hola”
“Say hello”
Estos iniciadores sirven para:
establecer automáticamente el idioma de trabajo,
y mostrar las instrucciones básicas de funcionamiento.
A partir de ahí, lo recomendable es empezar a cargar la documentación de forma estructurada.
Forma recomendada de trabajar
Si bien se pueden subir todos los documentos de golpe, lo ideal es subir los documentos uno a uno, indicando siempre qué representa cada documento.
Por ejemplo: RFQ cliente, oferta mecánica de la división de España, oferta de la división de Alemania, oferta de automatizacion, oferta consollidada, draft del contrato, anexo...
Esto ayuda al GPT a organizar contexto, entender relaciones entre documentos, y preparar mejor la revisión cruzada posterior.
Qué hace el GPT durante la carga documental
Mientras el usuario sigue subiendo documentación, el GPT NO realiza todavía la revisión final, sino que analiza cada documento individualmente, extrae información relevante, y va acumulando contexto.
Para cada documento genera una ficha estructurada con aspectos como alcance incluido, alcance excluido, responsabilidades, exclusiones, ambigüedades y posibles puntos de riesgo.
Todo ello queda consolidado progresivamente dentro del análisis global del proyecto.
Cómo lanzar la revisión final
Cuando toda la documentación ha sido cargada, simplemente se indica al GPT algo como:
“Ya no tengo más documentos”
“Analiza todo”
“Start review”
Y entonces comienza la revisión cruzada completa.
Qué tipo de resultado genera
La revisión final está orientada específicamente a Project Management y pre-award review.
El GPT genera un informe con los siguientes apartados
FASE 1: Resumen documental
te da una tabla resumen con los documentos aportados.
Fase 2-A: Executive Summary
Con:
nivel global de riesgo,
principales amenazas,
issues críticos,
y recomendación general.
Fase 2-B: Tabla de issues
Clasificando contradicciones, gaps, duplicidades, ambiguidades, ownership conflictivo, RFQ no cubierto, wording peligroso, y riesgos potenciales. Todo priorizado por: High, Medium y Low.
Fase 2-C: Scope gaps / tierra de nadie
Detectando elementos:
sin responsable claro,
interfaces débiles,
o alcances parcialmente definidos.
Fase 2-D_ Overlaps / duplicidades
Identificando:
responsabilidades solapadas,
trabajo duplicado,
o ownership múltiple.
Fase 2-E: Preguntas abiertas
Puntos críticos que deberían resolverse antes de emitir oferta, antes de award, o antes de firma contractual.
Fase 2-F: Checklist Go / No-Go
Tabla indicando un punto concreto y el "estado recomendado"
Por ejemplo:
Item | Estado recomendado |
Acceptance protocol viscosidad emitido | NO-GO hasta cerrar |
Método laboratorio definido | NO-GO |
Tolerancias KPI aprobadas | NO-GO |
Responsibility matrix emitida | NO-GO |
Confirmación utilities cliente | Pendiente |
Confirmación paradas planta | Pendiente |
Fase 3: Conclusión PM
Resumen y conclusión desde el punto de vista del PM, dando incluso recomendación de GO / NO-GO
La parte más interesante llega después
Pero probablemente una de las capacidades más potentes del sistema aparece una vez termina la revisión inicial.
Porque en ese momento: toda la documentación ya está consolidada y contextualizada. Y eso permite al Project Manager empezar a realizar preguntas mucho más profundas sobre el proyecto completo.
Por ejemplo:
“¿Dónde ves mayor riesgo de claim?”
“¿Qué divisiones tienen interfaces más débiles?”
“¿Qué assumptions son más peligrosas?”
“¿Qué exclusiones podrían generar conflicto durante commissioning?”
“¿Qué puntos revisarías antes de la reunión con cliente?”
“¿Dónde existen mayores zonas grises?”
“¿Qué wording contractual cambiarías?”
“¿Qué gaps podrían impactar margen?”
Y aquí es donde la experiencia real del PM adquiere todavía más valor porque el GPT puede mantener contexto, relacionar información, estructurar análisis, y detectar patrones, pero sigue siendo el Project Manager quien interpreta riesgos, entiende ejecución, prioriza problemas, y toma decisiones reales.
Y precisamente esa combinación: IA + experiencia operativa del PM es el núcleo de todo el enfoque PM&IA.
Conclusión
Durante muchos años, gran parte de la revisión contractual en proyectos industriales dependió casi exclusivamente de experiencia, memoria, reuniones, y revisiones manuales interminables. En cierta medida eso sigue siendo cierto, porque ningún sistema sustituye el criterio, la experiencia, ni la visión real de ejecución de un Project Manager experimentado.
Pero la realidad es que los proyectos modernos son cada vez más complejos con más documentos, más revisiones, mas divisiones, mas interfaces mas relaciones cruzadas y también más posibilidades de que determinados riesgos pasen desapercibidos hasta que ya es demasiado tarde.
Por eso herramientas como LK_PMIA Offer-Contract CrossCheck no deberían entenderse como sustitutos del PM, sino como amplificadores de capacidad de análisis.
Utilizar inteligencia artificial no para gestionar el proyecto… sino para ayudar a detectar problemas antes de que el proyecto exista realmente, porque cuando el contrato ya está firmado… normalmente ya es demasiado tarde para descubrir ciertas cosas.
Comentarios