Entienda Project Readiness en ingeniería: criterios para Stage-Gate, PDRI, Construction Readiness, procurement, riesgos, commissioning, operación y decisiones de avance.
¡Descúbrelo!
Project Readiness es la evaluación estructurada de cuán preparado está realmente un proyecto para avanzar a una nueva fase, asumir un compromiso de inversión, lanzar procurement, iniciar la construcción, ejecutar commissioning o entrar en operación. El análisis no busca demostrar que todos los riesgos han desaparecido; verifica si requisitos, ingeniería, decisiones, recursos, interfaces, contratos, permisos, planificación y condiciones operativas han alcanzado una madurez compatible con el siguiente paso.
En ingeniería, la readiness debe ser contextual. Un proyecto puede estar listo para iniciar FEED y aun no estar listo para procurement. Puede estar listo para emitir un paquete específico de construcción, pero no para movilizar todos los frentes. Puede estar mecánicamente completado y todavía no estar listo para operación. Por eso, la pregunta correcta no es simplemente “¿el proyecto está listo?”, sino “¿listo para qué, frente a qué criterios, evidencias, riesgos residuales y condiciones?”.
Project Readiness funciona como una disciplina de Project Assurance. Consolida evidencias de distintas funciones y transforma una percepción difusa de preparación en una decisión explícita: go, go condicionado, hold o rework. Cuanto mayor sea el costo de avanzar prematuramente, mayor será el valor de un readiness assessment bien estructurado.
Readiness no significa ausencia de pendientes
Ningún proyecto complejo llega a una decisión relevante con incertidumbre igual a cero. Exigir el cierre absoluto de todos los pendientes puede paralizar la entrega; ignorarlos puede transferir problemas a una fase mucho más costosa.
La función de un readiness assessment es distinguir tres situaciones: pendientes aceptables para la siguiente etapa, pendientes que requieren condiciones o mitigación antes del avance y blockers incompatibles con la decisión pretendida.
Esta lógica cambia la conversación de “¿tenemos ítems abiertos?” a “¿los ítems abiertos son compatibles con el riesgo que estamos a punto de asumir?”.
Project Readiness es relativo al gate
La madurez necesaria depende de la decisión.
| Gate o decisión | Pregunta dominante de readiness |
| autorizar estudio/FEED | ¿la necesidad, la alternativa y la base económica justifican profundizar? |
| autorizar inversión | ¿el alcance, CAPEX, plazo y riesgos poseen madurez suficiente? |
| lanzar procurement | ¿los requisitos e interfaces permiten propuestas comparables? |
| iniciar construcción | ¿ingeniería, materiales, accesos, permisos y frentes están realmente disponibles? |
| iniciar commissioning | ¿los sistemas están completos, configurados y seguros para pruebas? |
| transferir a operación | ¿personas, procedimientos, documentación, mantenimiento y desempeño están preparados? |
Un criterio adecuado para un gate puede ser completamente insuficiente para otro.
Readiness como parte del Stage-Gate
El Stage-Gate en proyectos de ingeniería establece momentos formales de decisión. Project Readiness aporta el análisis de preparación que sustenta esos gates.
Stage-Gate responde cuándo y por quién debe tomarse una decisión. Readiness responde si las condiciones requeridas para esa decisión están presentes y qué exposiciones permanecen.
Una organización madura evita gates basados únicamente en el calendario. Que llegue la fecha prevista no significa que el proyecto haya alcanzado el estado necesario para avanzar.
El calendario no es un criterio de madurez
Las presiones del presupuesto anual, compromisos con proveedores, disponibilidad del equipo o expectativas de la dirección suelen crear una narrativa de que “necesitamos comenzar”.
Estos factores pueden ser legítimos, pero deben tratarse como restricciones de decisión, no como evidencia de readiness.
Si la organización decide avanzar con gaps, la decisión debe registrar cuáles son, quién asume el riesgo, qué condiciones deben cumplirse y qué contingencias fueron establecidas.
Project Readiness y PDRI no son sinónimos
El PDRI — Project Definition Rating Index evalúa principalmente la madurez de definición del proyecto durante Front End Planning. Es una herramienta sumamente relevante para readiness, pero cubre solo una parte de la pregunta.
Project Readiness puede incluir dimensiones que van más allá de scope definition: disponibilidad del equipo, contratación, materiales, permisos, acceso, logística, constructibilidad, sistemas temporales, procedimientos de prueba, capacitación, repuestos, documentación de operación y capacidad organizacional.
Así, PDRI puede ser un input de un readiness assessment más amplio.
Readiness debe ser multidimensional
Los proyectos fallan cuando avanzan prematuramente porque la madurez en una dimensión puede ocultar una debilidad crítica en otra.
Por ejemplo, la ingeniería puede estar 90% completa, pero el 10% restante puede incluir interfaces que impiden la instalación. Los materiales pueden estar comprados mientras el área aún no está liberada. El sistema puede estar instalado mientras todavía no existen procedimientos operativos o backups validados.
Una estructura de readiness debe evaluar el conjunto.
El diagrama no representa pesos universales. Cada proyecto debe calibrar las dimensiones según su gate y perfil de riesgo.
Dimensión 1: necesidad, estrategia y Business Case
Antes de evaluar la ejecución, es necesario confirmar si la decisión sigue alineada con la necesidad de negocio.
Cambios de demanda, tecnología, regulación, estrategia corporativa o costo pueden volver obsoletas las premisas originales. Un proyecto técnicamente maduro puede no estar económica o estratégicamente listo para avanzar.
El Business Case, los beneficios, la alternativa seleccionada y los criterios de éxito deben estar actualizados al nivel exigido por el gate.
Dimensión 2: requisitos y alcance
Scope readiness significa que el proyecto sabe qué debe entregar, para quién y bajo qué criterios.
Los requisitos críticos deben estar identificados, aprobados y trazables. Inclusiones, exclusiones, premisas, límites e interfaces deben tener madurez suficiente para el siguiente compromiso.
El Alcance Contractual en Ingeniería muestra cómo las brechas en esas fronteras se convierten en cambios, conflictos y claims durante la ejecución.
Dimensión 3: madurez de la ingeniería
El porcentaje de ingeniería completada es solo un indicador. Readiness exige identificar qué documentos y decisiones están maduros y cuáles permanecen abiertos.
Diez por ciento de ingeniería pendiente puede ser irrelevante o puede contener la información que define fundaciones, cargas, interfaces, listas de I/O, routing, protección, selectividad, arquitectura de red o lógica operativa.
El análisis debe priorizar criticidad y dependencia, no solo la cantidad de planos emitidos.
Engineering completeness debe medirse por uso previsto
Una forma más útil de evaluar la ingeniería es preguntar si los entregables requeridos para la siguiente actividad están liberados y estables.
Para procurement, debe existir información suficiente para especificar y comparar. Para construcción, planos IFC, detalles, especificaciones e interfaces deben sustentar la ejecución. Para commissioning, configuración, causa y efecto, listas de puntos y criterios funcionales deben estar controlados.
El grado de completitud debe relacionarse con el uso downstream.
Dimensión 4: interfaces
Las interfaces son una de las principales causas de falso readiness. Cada paquete parece listo cuando se evalúa aisladamente, mientras las fronteras entre ellos siguen sin resolverse.
Una matriz de interfaces debe identificar owner, requisitos, estado, dependencias y evidencia de cierre. Las interfaces críticas abiertas deben aparecer como riesgo o blocker.
La System Architecture refuerza que las interfaces son objetos de ingeniería y no simples líneas entre bloques.
Dimensión 5: riesgos y oportunidades
Un proyecto puede estar listo incluso con riesgos elevados, siempre que sean comprendidos, aceptados y tratados de forma coherente con la decisión.
Readiness debe verificar si los riesgos críticos tienen owner, respuesta, trigger, contingencia e impacto conocido. Los riesgos sin respuesta pueden ser más preocupantes que riesgos de mayor impacto nominal ya mitigados.
También deben considerarse riesgos emergentes creados por el propio avance: contratación anticipada, fast-track, ejecución con ingeniería incompleta o dependencia de un único proveedor.
El riesgo residual debe ser explícito
Después de las acciones de mitigación permanece riesgo residual. La decisión del gate debe registrar si ese riesgo está dentro del apetito de riesgo de la organización.
Este punto es relevante porque readiness no debe presentar una imagen de seguridad absoluta. El assessment indica qué está listo, qué permanece expuesto y qué riesgo acepta la autoridad al avanzar.
La gobernanza exige transparencia, no una promesa de certeza.
Dimensión 6: estimación de costos y funding
La readiness financiera implica más que tener presupuesto disponible. La estimación debe ser compatible con la madurez técnica e incluir bases, premisas, contingencias y riesgos coherentes.
También es necesario confirmar funding para la siguiente fase, cash flow, exposición cambiaria cuando corresponda, compromisos ya asumidos y el impacto de long lead items.
Un proyecto sin financiación autorizada o con una estimación incompatible con su definición puede no estar listo para procurement o ejecución.
Dimensión 7: cronograma y lógica de ejecución
El cronograma debe representar cómo se ejecutará realmente el trabajo. Milestones, interfaces, calendarios, restricciones, procurement, ingeniería, construcción y commissioning deben estar integrados.
La readiness para ejecución exige atención especial a los predecesores reales: plano liberado, material disponible, área accesible, equipo movilizado, permiso emitido e interfaz cerrada.
Una actividad programada para comenzar no está lista simplemente porque llegó su fecha.
Lookahead y restricciones
Para construction readiness, un análisis de corto plazo debe verificar las restricciones por frente.
Un lookahead puede identificar trabajo planificado, requisitos de inicio e impedimentos. El objetivo es evitar movilizar equipos hacia frentes que todavía dependen de proyecto, material, equipos, andamios, liberación, acceso o una decisión.
Esta lógica reduce waiting time, improvisación y resecuenciación no planificada.
Dimensión 8: procurement
Los materiales y equipos críticos deben estar alineados con el cronograma y la configuración técnica vigente.
Readiness debe considerar RFQs, propuestas, technical bid evaluation, órdenes de compra emitidas, vendor data, fabricación, FAT, logística, entrega, almacenamiento y preservación.
Comprar demasiado pronto con ingeniería inmadura crea riesgo de cambio. Comprar demasiado tarde crea riesgo de atraso. Readiness ayuda a equilibrar esas exposiciones.
Vendor data forma parte de la ingeniería
En muchos sistemas, el diseño detallado depende de datos del proveedor. Dimensiones, cargas, potencia, protocolos, heat dissipation, conexiones y requisitos de instalación alimentan el desarrollo downstream.
Una orden de compra emitida no significa que el paquete esté listo. Es necesario verificar si los datos requeridos se entregarán a tiempo, serán revisados e incorporados a la configuración.
Esta dependencia debe aparecer en el cronograma y en el readiness assessment.
Dimensión 9: contratos y responsabilidades
Antes de movilizar o contratar, las responsabilidades deben estar suficientemente claras.
¿Quién suministra energía temporal? ¿Quién realiza la integración? ¿Quién proporciona acceso? ¿Quién ejecuta las pruebas? ¿Quién suministra instrumentos? ¿Quién resuelve interfaces? ¿Quién emite As Built? ¿Quién solicita la aceptación?
El Scope of Work en Ingeniería es una de las bases de la readiness contractual porque transforma la solución en obligaciones verificables.
Dimensión 10: permisos, aprobaciones y requisitos regulatorios
Un proyecto puede tener la ingeniería lista y aun así no estar autorizado para ejecutar.
Permisos ambientales, autorizaciones, aprobaciones del cliente, requisitos de utilities, accesos y documentos legales deben verificarse según la etapa.
La ausencia de una sola aprobación crítica puede bloquear un frente completo y generar costos de movilización improductiva.
Dimensión 11: condiciones del sitio
Los proyectos brownfield, retrofit y de infraestructura dependen fuertemente de la calidad de la información existente.
Levantamientos As Built, topografía, geotecnia, interferencias, condiciones estructurales, utilities, redes existentes, accesos y restricciones operativas deben caracterizarse a un nivel adecuado.
Avanzar con un sitio desconocido transfiere incertidumbre al campo, donde el costo del descubrimiento es mayor.
Dimensión 12: constructibilidad
La constructibilidad pregunta si la solución puede ejecutarse de forma segura y eficiente bajo las condiciones reales del sitio.
Secuencia, accesos, izaje, áreas de laydown, trabajo en instalaciones operativas, aislamiento, interferencias, modularización y sistemas temporales deben considerarse.
Un proyecto puede estar “diseñado” y aun así no estar construction-ready.
Cuando un proyecto está presionado a avanzar por calendario, la gobernanza debe separar urgencia de readiness. Criterios claros, blockers y condiciones de gate permiten acelerar conscientemente, sin transformar pendientes de ingeniería en improductividad, cambios y disputas durante la ejecución.
Estructure gates, criterios y decisiones con Gobernanza de Proyectos, Programas y Portafolios
Construction Readiness como disciplina específica
CII desarrolló el Construction Readiness Assessment (CRA) específicamente para evaluar si los proyectos están preparados para construir.
La investigación RT-DCC-02 identificó 228 factores de readiness agrupados en quince categorías y desarrolló un Construction Readiness Score para clasificar proyectos e identificar áreas de mejora. El estudio comparó proyectos considerados construction-ready y construction-not-ready y encontró diferencias de desempeño en costo y plazo.
Esta investigación refuerza una idea práctica: iniciar la construcción antes de resolver las condiciones esenciales no necesariamente acelera el proyecto; puede simplemente anticipar improductividad.
Engineering release no es construction readiness
Emitir un plano IFC es importante, pero no suficiente.
El frente también puede depender de material, mano de obra, herramientas, acceso, predecesores, inspección, permisos, procedimientos, seguridad y logística.
Por eso, construction readiness debe evaluarse por paquete o frente y no solo por el estado documental de la ingeniería.
Workface readiness
En el nivel operativo, workface readiness significa que el equipo puede iniciar y continuar el trabajo sin blockers previsibles.
La organización puede utilizar criterios simples de constraint removal: información, material, equipo, área, personal, herramientas, seguridad, calidad y predecesor.
Un frente liberado sin estos elementos crea ciclos de start-stop que reducen productividad y aumentan la exposición a claims.
Dimensión 13: organización y recursos
Los proyectos también fallan por insuficiencia organizacional. Tener el alcance listo no garantiza que el owner y los proveedores tengan capacidad para ejecutarlo.
Readiness debe evaluar estructura de gobernanza, organigrama, roles, autoridad, capacidad de los equipos, cobertura de disciplinas, disponibilidad de supervisión técnica y canales de escalamiento.
Los cambios de fase suelen aumentar la carga sobre funciones específicas. Procurement puede sobrecargarse durante la contratación; la supervisión crece durante la movilización; commissioning exige competencias propias.
Competencia es diferente de cantidad de personas
Agregar headcount no resuelve una brecha de expertise.
Los sistemas críticos pueden requerir especialistas en protección, automatización, redes, software, calidad, seguridad funcional o commissioning. El readiness assessment debe verificar competencias, no solo un organigrama completo.
También debe considerar dependencia excesiva de una sola persona para decisiones críticas.
Dimensión 14: gobernanza y toma de decisiones
Readiness depende de que las decisiones se tomen en el momento adecuado. Un equipo puede tener información completa y seguir bloqueado porque la autoridad o el proceso de aprobación no están claros.
Matrices de autoridad, foros, SLAs de decisión, change control y escalamiento deben estar establecidos antes de fases de alta velocidad.
La solución de Gobernanza de Proyectos, Programas y Portafolios organiza estos mecanismos para que las decisiones no dependan de acuerdos informales.
Dimensión quince: documentación y configuración
Un proyecto listo debe saber qué configuración está vigente.
Planos, especificaciones, listas, modelos, software, firmware, parámetros y vendor documents deben tener revisiones controladas. El campo debe acceder a la versión correcta.
Readiness también debe verificar flujos de RFI, redline, NCR, punch list, pruebas y As Built para que la ejecución genere evidencia adecuada para handover.
Document Control es infraestructura de ejecución
Document Control suele percibirse como una función administrativa, pero en proyectos complejos es infraestructura operativa.
Sin distribución controlada, un frente puede ejecutar una revisión obsoleta. Sin registros, el equipo no puede reconstruir decisiones. Sin baseline, las pruebas pueden realizarse sobre una configuración no identificada.
Por lo tanto, la readiness documental debe formar parte del gate de ejecución.
Dimensión 16: calidad
El plan de calidad, ITPs, criterios de inspección, hold points, procedimientos y responsabilidades deben acompañar la madurez de la ejecución.
No basta con “inspeccionar después”. Los criterios deben existir antes del trabajo para orientar la ejecución y la recopilación de evidencias.
Esto es especialmente crítico para actividades que quedarán ocultas, energizadas o inaccesibles en fases posteriores.
Dimensión 17: HSE y seguridad operativa
Readiness debe asegurar que los riesgos de seguridad asociados con la siguiente fase hayan sido identificados y controlados.
Permisos de trabajo, análisis de riesgo, aislamiento, LOTO, trabajo en altura, espacios confinados, energía, izaje, acceso e interfaces con operación son ejemplos de condiciones que pueden bloquear la movilización.
En brownfield, la coordinación con instalaciones en operación forma parte de la ingeniería y la planificación, no es una tarea de última hora.
Readiness para commissioning
Commissioning readiness comienza mucho antes de las pruebas. Los sistemas deben tener un estado de completion adecuado, documentación disponible, configuración controlada, punch items clasificados, personal, instrumentos, energía, medios de comunicación y procedimientos aprobados.
También deben estar definidos los límites de sistema y subsistema, la secuencia de energización y las condiciones de seguridad.
Un sistema físicamente instalado puede no estar listo para commissioning.
Mechanical Completion no significa operational readiness
CII enfatiza en su práctica Planning for Startup que el objetivo de un capital project no es solo completar la construcción, sino entregar una unidad funcional dentro del entorno de negocio.
Mechanical Completion indica un hito físico. Aún pueden faltar pruebas funcionales, capacitación, procedimientos, repuestos, integración, documentación, performance testing y transferencia formal.
Readiness debe acompañar esta transición.
Operational Readiness
Operational Readiness verifica si la organización que recibirá el activo está preparada para operarlo con seguridad y desempeño requerido.
Esto incluye personal capacitado, procedimientos, mantenimiento, planes de contingencia, repuestos, herramientas, contratos de soporte, datos de activos, documentación, permisos y criterios de aceptación.
CII mantiene Planning for Startup como best practice a lo largo de varias fases, reforzando que la preparación para operación debe comenzar temprano.
Operación debe participar antes del handover
Involucrar a los usuarios solo al final crea riesgo de requisitos no atendidos y baja apropiación del sistema.
Operación y mantenimiento deben contribuir a requisitos, arquitectura, mantenibilidad, pruebas y criterios de validación durante el desarrollo.
Esta participación reduce la brecha entre “sistema construido conforme al proyecto” y “sistema utilizable en el contexto real”.
Readiness y V-Model
El V-Model en Systems Engineering conecta los requisitos definidos durante el desarrollo con las evidencias de verificación y validación.
Readiness utiliza esta trazabilidad para preguntar si existen evidencias suficientes para avanzar al siguiente nivel de integración o aceptación.
Una prueba no debe comenzar sin criterios y configuración. Un handover no debe ocurrir sin evidencia de requisitos críticos.
Readiness y MBSE
En proyectos que utilizan MBSE — Model-Based Systems Engineering, parte de la readiness puede apoyarse en trazabilidad digital.
Requisitos, elementos de arquitectura, interfaces, riesgos y casos de verificación pueden relacionarse en el modelo. Esto facilita identificar pendientes y el impacto de cambios.
Aun así, readiness también depende de condiciones físicas y organizacionales fuera del modelo: material entregado, equipos movilizados, permisos emitidos y capacitación completada.
Cómo estructurar un Readiness Assessment
El primer paso es definir el gate evaluado. Luego el equipo establece dimensiones, criterios, evidencias, blockers y owners.
Una estructura robusta debe permitir tanto una visión ejecutiva como trazabilidad hasta el detalle.
El resultado no debería ser solo un porcentaje. Debe mostrar dónde están las principales exposiciones y qué condiciones necesitan satisfacerse.
Criterios claros evitan una autoevaluación optimista
Términos como “adecuado”, “suficiente” y “prácticamente completo” deben traducirse en evidencias.
En vez de “ingeniería casi lista”, el criterio puede exigir documentos IFC críticos, interfaces cerradas y vendor data incorporado. En vez de “equipo definido”, puede exigir posiciones críticas movilizadas y autoridad formal establecida.
Cuanto más objetivo sea el criterio, menor será el espacio para readiness por percepción.
Sistema de clasificación
Una organización puede utilizar RAG — red, amber, green — u otra escala.
- Green: condición atendida y evidenciada;
- Amber: condición parcialmente atendida, con riesgo controlable y plan definido;
- Red: condición incompatible con el avance o sin mitigación aceptable.
Lo importante es establecer el significado antes de la evaluación. Cambiar criterios después de conocer el resultado destruye la comparabilidad.
Los blockers deben separarse del score
Un score agregado puede ocultar una falla crítica. Por eso, los blockers deben tratarse de forma independiente.
Ejemplos: permiso obligatorio inexistente, requisito de seguridad no resuelto, material crítico sin fecha, plano esencial no liberado, ausencia de protección para energización o interfaz externa sin acuerdo.
Un único blocker puede justificar un hold aunque la mayoría de los criterios estén green.
Go condicionado
No todo pendiente exige hold. La decisión puede ser go condicionado cuando existen acciones específicas que pueden completarse sin comprometer la seguridad ni la lógica de la fase.
La condición debe tener owner, plazo y mecanismo de verificación. También debe existir una consecuencia si no se cumple.
Go condicionado no puede utilizarse simplemente para empujar blockers hacia la ejecución.
Waiver y aceptación formal de riesgo
En casos excepcionales, la autoridad puede aceptar el avance sin cumplir un criterio específico.
Esto debe tratarse como waiver o aceptación explícita de riesgo, con justificación, impacto, medidas compensatorias y autoridad responsable.
Registrar la excepción preserva la gobernanza y evita que un criterio sea ignorado informalmente solo para proteger el cronograma.
Heatmap de readiness
Una visión ejecutiva puede representar dimensiones y estado por gate.
| Dimensión | Estado | Gap principal | Owner | Condición para avanzar |
| alcance/requisitos | verde | — | ingeniería | atendido |
| interfaces | amarillo | interfaz con utilities | integración | cerrar ICD |
| procurement | amarillo | equipo long lead | procurement | PO hasta fecha límite |
| construcción | rojo | área no liberada | owner | liberación física |
| commissioning | amarillo | procedimiento en revisión | Cx | aprobar antes de energización |
Esta matriz dirige la discusión hacia los ítems que cambian la decisión.
Readiness por paquete o sistema
Los proyectos grandes no necesitan esperar hasta que todas las áreas alcancen el mismo nivel para avanzar selectivamente.
Readiness puede evaluarse por Work Package, área, sistema o subsistema. Esta estrategia permite ejecución progresiva siempre que las interfaces y los riesgos sean comprendidos.
Por ejemplo, las fundaciones de un área pueden estar listas mientras otra espera definición. El gate debe indicar claramente el alcance exacto de la autorización.
Partial Release exige una frontera clara
Liberar parcialmente sin delimitar el alcance crea ambigüedad.
La decisión debe definir qué está autorizado, qué documentos sustentan la liberación, qué interfaces permanecen congeladas y qué actividades no pueden comenzar.
Esto reduce la posibilidad de que una autorización limitada sea interpretada en campo como una aprobación general.
Fast-track aumenta la importancia de readiness
Fast-track superpone ingeniería, procurement y construcción. Esto puede reducir el plazo, pero aumenta la dependencia entre madurez y secuencia.
Readiness no debe impedir fast-track; debe hacer explícito dónde la organización está asumiendo el riesgo de avanzar con información incompleta.
Los paquetes anticipados deben seleccionarse con base en estabilidad suficiente y baja exposición a cambios downstream.
Readiness en proyectos brownfield
Los proyectos en instalaciones existentes enfrentan condiciones no completamente documentadas, operación continua y restricciones de acceso.
Levantamientos, scanning, pruebas, ventanas operativas, aislamiento, interfaces con sistemas legacy y planes de contingencia ganan importancia.
Un frente aparentemente simple puede no estar listo si depende de una parada todavía no aprobada.
Readiness en sistemas tecnológicos
Los sistemas de automatización, seguridad electrónica, telecomunicaciones e infraestructura digital tienen dependencias de software, licencias, servidores, redes, identidad, datos e integraciones.
Hardware instalado no significa sistema listo. Versiones, credenciales, certificados, APIs, firewalls, sincronización, storage y ambientes deben considerarse.
También deben planificarse rollback y backup antes de cambios en sistemas productivos.
Cybersecurity readiness
En sistemas conectados, los requisitos de seguridad deben validarse antes de la entrada en operación.
Cuentas predeterminadas, firmware, hardening, segmentación, backups, logging, acceso remoto y gestión de vulnerabilidades son ejemplos de condiciones que pueden afectar la aceptación.
La readiness operacional debe incluir la capacidad de mantener el sistema seguro después del handover, no solo configurarlo una vez.
Readiness y datos
Los proyectos digitales dependen de datos correctos para configuración, pruebas y operación.
Registros de usuarios, activos, tags, direcciones, listas de puntos, convenciones de nomenclatura y parámetros deben estar disponibles en el formato y momento requeridos.
Datos incompletos pueden bloquear commissioning incluso cuando toda la infraestructura física está lista.
Readiness y Change Management
Los cambios próximos al gate pueden invalidar evidencias anteriores.
Si cambian la arquitectura, los requisitos, equipos o secuencia, el equipo debe evaluar qué criterios de readiness necesitan revisarse.
El Engineering Change Management aporta la gobernanza para controlar impactos y preservar la baseline.
Readiness y Claim Management
Avanzar bajo condiciones incompletas puede generar impactos contractuales. Acceso tardío, información tardía, restricciones no reveladas y cambios de secuencia son fuentes frecuentes de eventos.
El Claim Management ayuda a registrar y tratar estos eventos, pero readiness actúa preventivamente: busca identificar la exposición antes de la movilización.
La prevención es menos costosa que reconstruir la causalidad meses después.
Independent Project Review
Para decisiones críticas, una revisión independiente puede reducir el sesgo del equipo que desarrolló el proyecto.
El reviewer no necesita rediseñar la solución. Su función es verificar si se cumplieron los criterios, si las evidencias sustentan las afirmaciones y si riesgos y gaps fueron presentados con transparencia.
Owner’s Engineering, el PMO o un tercero independiente pueden desempeñar este papel según la gobernanza y criticidad.
En proyectos con múltiples contratos, cada proveedor puede declarar su paquete listo mientras el sistema completo sigue expuesto. El Owner necesita consolidar requisitos, interfaces, documentos, pruebas y condiciones operativas en una visión única antes de autorizar la siguiente fase.
Use Owner’s Engineering para realizar evaluaciones independientes de readiness e integración
Readiness en Owner’s Engineering
La Owner’s Engineering es especialmente adecuada para readiness porque actúa transversalmente sobre múltiples proveedores.
El Owner necesita saber si el conjunto está listo, no solo si cada contratista declaró completado su alcance.
Una evaluación independiente puede integrar ingeniería, contratos, documentos, interfaces, pruebas y condiciones operativas antes de recomendar el avance.
Readiness como sistema continuo, no auditoría de última hora
Evaluar solo en vísperas del gate limita la capacidad de corregir problemas.
La buena práctica es monitorear readiness progresivamente, actualizando gaps y tendencias. Cuando llegue la decisión formal, la mayoría de los blockers ya debería haber sido identificada semanas o meses antes.
El assessment final consolida; no debería descubrir todo por primera vez.
Leading indicators de readiness
Los indicadores adelantados muestran si el proyecto está construyendo condiciones de éxito.
Ejemplos incluyen interfaces críticas cerradas, engineering deliverables liberados a tiempo, long lead items contratados, restricciones removidas, procedimientos aprobados y requisitos con evidencias planificadas.
Estos indicadores son más útiles preventivamente que indicadores de atrasos ya materializados.
Readiness debt
Cuando una organización decide avanzar con pendientes, acumula una especie de readiness debt: trabajo que debería haberse completado antes y que ahora debe resolverse bajo mayor presión.
La deuda puede ser administrable si es pequeña y explícita. Se vuelve peligrosa cuando gates sucesivos transfieren pendientes a la siguiente fase.
El resultado es una ejecución que carga decisiones de concepto, procurement que carga incertidumbres de requisitos y commissioning que descubre problemas de arquitectura.
Evitar la transferencia crónica de pendientes
Una buena gobernanza acompaña el origen y la antigüedad de los gaps.
Si una interfaz abierta durante FEED sigue sin resolverse en construcción, el problema no es solo técnico; es una falla del proceso de decisión.
El readiness assessment debe señalar ítems envejecidos y exigir resolución o aceptación formal de riesgo.
Readiness y contingencia
La contingencia no debe utilizarse para justificar cualquier gap.
La contingencia financiera absorbe incertidumbre de costo; la reserva de plazo absorbe incertidumbre temporal. Ninguna sustituye un requisito, permiso, interfaz o condición física esencial.
El equipo debe diferenciar incertidumbre aceptable de definición insuficiente.
Readiness y decisión ejecutiva
La síntesis ejecutiva debe ser clara: recomendación, blockers, gaps relevantes, riesgo residual, condiciones e impacto de no avanzar.
Un dashboard con decenas de indicadores puede ocultar la decisión. La función del assurance es traducir el detalle técnico a una posición ejecutiva sin esconder la complejidad.
La autoridad necesita saber qué está aceptando.
Estructura recomendada para un informe de readiness
Un informe puede contener objetivo y gate, alcance de la evaluación, criterios, participantes, evidencias, resultado por dimensión, blockers, riesgos, acciones, waivers y recomendación.
El documento también debe registrar la fecha y configuración evaluadas. Readiness es una fotografía de un estado; cambios posteriores pueden invalidarla.
Para gates críticos, la decisión de la autoridad debe adjuntarse al registro.
Cómo definir el owner de cada criterio
Cada criterio necesita un owner responsable de la condición y, cuando corresponda, una parte independiente responsable de la verificación.
Ingeniería puede ser owner de un plano; Project Controls del cronograma; Procurement del equipo; Operación de un procedimiento; HSE de un permiso. El asesor de readiness consolida sin absorber todas las responsabilidades.
Esta división evita que el proceso se convierta en una “auditoría del PM” sin accountability de las disciplinas.
Cadencia de las evaluaciones
La frecuencia depende de la velocidad del proyecto y del gate.
Front End Planning puede utilizar checkpoints en hitos de madurez. Construcción puede monitorear readiness semanalmente por frentes. Commissioning puede requerir reviews por sistema antes de la energización.
La cadencia debe permitir acción entre evaluaciones.
Los thresholds deben calibrarse
Los porcentajes universales son peligrosos. Un threshold adecuado depende de la herramienta, tipo de proyecto, fase y riesgo.
CII tiene benchmarks propios para herramientas como PDRI y Construction Readiness Assessment. Una organización también puede desarrollar thresholds internos basados en desempeño histórico.
Lo importante es no inventar un estado de “85% listo” sin relación con desempeño o criticidad.
Benchmarking interno y mejora continua
Al registrar readiness y resultados de los proyectos, una empresa puede aprender qué gaps realmente anticipan problemas.
Tal vez proyectos con baja madurez de interfaces presenten más cambios; baja readiness de procurement genere atrasos; baja operational readiness aumente punch lists post-handover.
Estas correlaciones permiten mejorar criterios y gates con el tiempo.
Readiness debe medir resultados, no cantidad de documentos
Una carpeta completa puede ocultar un sistema inmaduro. El criterio debe mirar decisiones y condiciones.
Un documento es evidencia cuando demuestra algo: requisito aprobado, interfaz cerrada, cálculo validado, prueba concluida o permiso emitido.
Generar un documento solo para marcar un checklist crea conformidad sin readiness.
Principales errores en Project Readiness
Los errores más comunes son evaluar demasiado tarde, usar porcentajes genéricos, confundir volumen documental con madurez, ocultar blockers en scores promedio, aceptar autoevaluación sin evidencias y avanzar según calendario.
También es problemático evaluar cada disciplina de forma aislada sin analizar interfaces y tratar el go condicionado como autorización para cargar indefiniciones indefinidamente.
Readiness debe aumentar la transparencia, no producir una justificación formal para una decisión ya tomada.
Cuándo utilizar un Project Readiness Assessment
La disciplina agrega valor siempre que el siguiente paso aumente significativamente el costo del cambio o la exposición contractual.
Esto ocurre antes de autorización de inversión, procurement relevante, movilización, inicio de construcción, energización, commissioning, handover y entrada en operación.
Cuanto más irreversible sea el compromiso, más rigurosa debe ser la evaluación.
Consideraciones finales
Project Readiness transforma la decisión de avanzar en una evaluación de condiciones reales. En vez de asumir readiness porque llegó la fecha o porque el equipo “casi terminó”, la organización verifica requisitos, ingeniería, interfaces, riesgos, procurement, contratos, construcción, personas, documentación, commissioning y operación según el gate específico.
La disciplina no busca proyectos sin pendientes. Busca decisiones conscientes: qué gaps son aceptables, cuáles requieren condiciones y cuáles son blockers. Esto permite usar go condicionado y aceptación de riesgo bajo gobernanza, sin ocultar exposición.
Integrado con Stage-Gate, PDRI, Front End Planning y Owner’s Engineering, Project Readiness funciona como una capa de assurance entre planificación y compromiso. Su principal beneficio es evitar que la organización descubra, ya en la siguiente fase, que aquello que parecía avance era solo transferencia de trabajo no resuelto.
Referencias técnicas
[1] CONSTRUCTION INDUSTRY INSTITUTE. Construction Readiness Assessment for Productivity Improvement. RT-DCC-02. Austin: CII. Disponible en: https://www.construction-institute.org/rt-dcc-02
[2] CONSTRUCTION INDUSTRY INSTITUTE. Construction Readiness Assessment for Productivity Improvement. Austin: CII. Disponible en: https://www.construction-institute.org/construction-readiness-assessment-for-productivity-improvement
[3] CONSTRUCTION INDUSTRY INSTITUTE. Project Definition Rating Index (PDRI) Overview. Austin: CII. Disponible en: https://www.construction-institute.org/pdri-overview
[4] CONSTRUCTION INDUSTRY INSTITUTE. Planning for Startup. IR121-2. Austin: CII. Disponible en: https://www.construction-institute.org/planning-for-startup
[5] CONSTRUCTION INDUSTRY INSTITUTE. Achieving Success in the Commissioning and Startup of Capital Projects. IR312-2. Austin: CII, 2015. Disponible en: https://www.construction-institute.org/achieving-success-in-the-commissioning-and-startup-of-capital-projects
[6] U.S. DEPARTMENT OF ENERGY. DOE G 413.3-12A — Front-End Planning and Project Definition Rating Index for Nuclear and Non-Nuclear Construction Projects. Washington, DC: DOE, 2023. Disponible en: https://www.energy.gov/documents/front-end-planning-and-project-definition-rating-index-nuclear-and-non-nuclear
Preguntas frecuentes
Es la evaluación estructurada de las condiciones necesarias para que un proyecto avance con riesgo controlado hacia un gate o fase específica, considerando dimensiones técnicas, organizacionales, contractuales, regulatorias, de construcción y operación.
No. Pueden existir pendientes siempre que sean compatibles con la siguiente etapa, estén evidenciados y tengan tratamiento definido. Blockers y riesgos incompatibles con el avance deben impedir o condicionar la decisión.
PDRI tiene fuerte foco en la madurez de definición del proyecto durante Front End Planning. Project Readiness es más amplio y puede incluir recursos, contratos, materiales, permisos, construcción, commissioning y capacidad operativa.
Es la readiness específica para ejecutar la construcción. Considera ingeniería, materiales, frentes, recursos, planificación, logística, seguridad, interfaces y otras condiciones necesarias para productividad y continuidad del trabajo.
Es la autorización para avanzar sujeta al cumplimiento de condiciones específicas, con owners, plazos y mecanismos de verificación definidos. No debe utilizarse para transferir blockers a la siguiente fase.
La evaluación debe ser multidisciplinaria. En gates relevantes, el PMO, Owner’s Engineering o un tercero independiente pueden facilitar o revisar el análisis para reducir sesgos e integrar evidencias de múltiples proveedores y disciplinas.
Materiales técnicos complementarios
Contenidos principales sobre el tema
- PDRI — Project Definition Rating Index en Ingeniería
- Stage-Gate en proyectos de ingeniería: fases, criterios y gates de decisión
- FEL: la etapa que evita que el proyecto se convierta en un problema jurídico, financiero y operativo
Contenidos técnicos relacionados
- V-Model en Systems Engineering: requisitos, integración, verificación y validación
- System Architecture: cómo estructurar la arquitectura de sistemas complejos
- Claim Management en Proyectos de Ingeniería
Soluciones relacionadas
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
