Aprenda a usar la matriz RACI en proyectos de ingeniería para definir responsables, aprobadores, consultados e informados, reduciendo conflictos y fallas de comunicación.
¡Descúbrelo!
En proyectos de ingeniería, muchas fallas no ocurren por falta de capacidad técnica, sino por falta de claridad sobre las responsabilidades. ¿Quién ejecuta? ¿Quién aprueba? ¿Quién necesita ser consultado antes de la decisión? ¿Quién debe solamente ser informado? Cuando estas respuestas no están claras, surgen retrasos, retrabajo, decisiones contradictorias, conflictos entre proveedores y dificultades en la aceptación técnica.
La matriz RACI es una herramienta simple y muy útil para organizar responsabilidades en proyectos, contratos, obras, servicios de consultoría, comisionamiento, due diligence, procurement, coordinación de proyectos y Owner’s Engineering.
En ingeniería, la matriz RACI ayuda a transformar papeles difusos en una estructura objetiva de gobernanza. Define quién es responsable de ejecutar una actividad, quién responde por la decisión, quién necesita ser consultado y quién debe ser informado.
Cuando se aplica correctamente, la matriz RACI reduce ambigüedades, mejora la comunicación, apoya la toma de decisiones y ayuda al contratante a controlar interfaces críticas.
¿Qué es una matriz RACI?
La matriz RACI es una herramienta de asignación de responsabilidades. El término RACI proviene de cuatro papeles:
| Letra | Término | Función |
|---|---|---|
| R | Responsible | Quien ejecuta la actividad o entrega el resultado |
| A | Accountable | Quien responde por la decisión, aprobación o resultado final |
| C | Consulted | Quien debe ser consultado antes de la decisión o ejecución |
| I | Informed | Quien debe ser informado sobre avance, decisión o resultado |
En español, estos papeles pueden interpretarse como Responsable, Aprobador o responsable final, Consultado e Informado. El punto más importante es diferenciar quién ejecuta de quién aprueba. En muchos proyectos de ingeniería, esta distinción evita conflictos relevantes.
¿Por qué usar una matriz RACI en proyectos de ingeniería?
Los proyectos de ingeniería involucran múltiples partes: contratante, proyectistas, consultores, integradores, proveedores, operación, mantenimiento, compras, jurídico, supervisión, comisionamiento y, en algunos casos, Owner’s Engineering. Sin una estructura clara, las responsabilidades pueden superponerse o quedar descubiertas.
| Sin matriz RACI | Con matriz RACI |
|---|---|
| Responsabilidades ambiguas | Papeles definidos por actividad |
| Decisiones sin dueño claro | Responsable de la aprobación identificado |
| Consultas realizadas demasiado tarde | Partes consultadas definidas previamente |
| Comunicación excesiva o insuficiente | Informados definidos de forma objetiva |
| Conflictos entre áreas y proveedores | Interfaces mejor controladas |
| Retrasos por indefinición | Flujo de decisión más claro |
En la práctica, la matriz RACI funciona como un mapa de responsabilidades. No sustituye al contrato, alcance, cronograma o matriz de riesgos, sino que complementa estos instrumentos.
La responsabilidad clara forma parte de la gobernanza, no solo de la organización del equipo. Cuando actividades, aprobaciones y consultas atraviesan áreas y proveedores, la RACI necesita estar integrada al flujo real de decisiones del proyecto.
RACI es un mecanismo de gobernanza, no solo una hoja de cálculo
Una matriz RACI madura no comienza con la pregunta “¿qué letra colocar para cada persona?”. Comienza por la gobernanza: qué decisiones existen, quién posee autoridad para tomarlas, qué entregables necesitan un responsable, qué conocimiento debe incorporarse antes de la decisión y qué partes necesitan recibir información para cumplir sus propias obligaciones.
El PMBOK® Guide — Eighth Edition, disponible en el acervo técnico de A3A, trata la gobernanza como la estructura que organiza sistemas, procesos, papeles, responsabilidades y modelos de decisión del proyecto. En este contexto, la publicación presenta la RACI como un ejemplo de mecanismo de gobernanza. Esto es relevante porque desplaza la herramienta del campo de la “hoja de tareas” hacia el campo de la accountability, autoridad y coordinación.
En un proyecto de ingeniería, un mismo entregable puede atravesar varios niveles. El proyectista produce, un coordinador verifica, el Owner’s Engineer analiza, operación valida un requisito y el propietario toma la decisión de aceptar o no determinado resultado. Si la RACI trata todo esto como una única actividad genérica, ocultará justamente las fronteras que debería esclarecer.
Por eso, la matriz debe ser coherente con el contrato, estructura organizacional, matriz de autoridad, gestión de interfaces, plan de comunicación y flujos de cambios. Cuando estos instrumentos señalan responsables diferentes, existe una inconsistencia de gobernanza que debe resolverse, no apenas una celda a corregir.
Qué aporta la ABNT NBR ISO 21502 a la lógica de responsabilidades
La ABNT NBR ISO 21502:2021, consultada en la Knowledge Base de A3A, no prescribe una matriz RACI obligatoria, pero establece la base que justifica su uso. La norma orienta que la organización temporal del proyecto defina papeles, responsabilidades y autoridades, disponga de líneas de reporte claras y sea comunicada a todos los involucrados.
Una matriz RACI útil necesita reflejar autoridad real. Definir Accountable sin verificar delegación, contrato y gobernanza crea apenas una responsabilidad nominal y transfiere el conflicto a la ejecución.
La norma también exige que las responsabilidades sean suficientemente claras para que cada persona comprenda no solo su propio papel, sino también los papeles de las personas con las que trabaja. En ingeniería multidisciplinaria, esta orientación es especialmente importante: proyectista, proveedor, supervisión, operación y propietario necesitan conocer las fronteras entre producir, verificar, recomendar, autorizar y aceptar.
Otro punto central es el límite de autoridad. La ISO 21502 diferencia las responsabilidades del patrocinador, gerente de proyecto, líderes de paquetes de trabajo, equipo y estructuras de apoyo como PMO. También prevé escalamiento cuando riesgos, cuestiones o cambios superan la autoridad delegada. Por lo tanto, marcar a alguien como A sin verificar si esa función puede efectivamente tomar la decisión contradice la propia lógica de gobernanza.
La trazabilidad también importa. Una responsabilidad indicada en la RACI debe ser compatible con el contrato, plan de gestión, procedimientos de aprobación y documentos de delegación de autoridad. Una “verdad en la matriz” y otra “verdad en el contrato” crea exposición justamente en momentos de mayor criticidad: cambio de alcance, reclamación, aprobación de proyecto, energización, comisionamiento y aceptación.
Papel, función, persona y organización no son lo mismo
Una RACI debe trabajar preferentemente con papeles o funciones, y no solamente con nombres de personas. Las personas pueden ser sustituidas; la responsabilidad institucional debe permanecer. Columnas como “Gerente del Proyecto”, “Coordinación Eléctrica”, “Owner’s Engineer”, “Operación”, “Proveedor del Sistema” y “Supervisión” tienden a ser más robustas que nombres individuales.
También es importante mantener consistencia de nivel. Mezclar en una misma matriz una empresa, una persona, una disciplina y un departamento sin criterio puede producir ambigüedad. En proyectos mayores, puede haber una capa contractual por organización y otra capa operacional por función. El objetivo no es producir la matriz más detallada posible, sino el nivel de detalle necesario para eliminar dudas sobre responsabilidad y decisión.
Diferencia entre Responsible y Accountable
La mayor dificultad en el uso de la matriz RACI suele estar en la diferencia entre Responsible y Accountable.
El Responsible es quien ejecuta la actividad. Puede haber más de una persona o equipo responsable de la ejecución, aunque es recomendable evitar exceso de responsables para no diluir el trabajo.
El Accountable es quien responde por la aprobación o el resultado final. En general, debe existir solo un accountable por actividad. Cuando hay muchos aprobadores finales, la decisión se vuelve lenta, conflictiva o sin dueño.
| Papel | Pregunta que responde | Ejemplo en ingeniería |
|---|---|---|
| Responsible | ¿Quién hace? | El proyectista elabora el plano técnico |
| Accountable | ¿Quién aprueba o responde por el resultado? | El coordinador técnico aprueba el entregable |
| Consulted | ¿Quién necesita opinar antes? | Operación valida un requisito de mantenimiento |
| Informed | ¿Quién necesita saber después? | La gestión contractual recibe la actualización |
Ejemplo de matriz RACI en proyectos de ingeniería
La matriz RACI normalmente cruza actividades con papeles, equipos o partes interesadas. El ejemplo siguiente muestra una aplicación simplificada en un proyecto técnico.
| Actividad | Contratante | Consultoría Técnica | Proyectista | Proveedor | Operación |
|---|---|---|---|---|---|
| Definir requisitos técnicos | A | R | C | I | C |
| Elaborar proyecto básico | A | R | C | I | C |
| Evaluar propuesta técnica | A | R | C | C | I |
| Ejecutar instalación | I | C | C | R | I |
| Acompañar pruebas | A | R | C | R | C |
| Validar aceptación técnica | A | R | C | C | C |
| Recibir documentación final | A | R | C | R | I |
Este modelo debe adaptarse al contrato, tamaño del proyecto y nivel de criticidad del entregable. En proyectos mayores, la matriz puede detallarse por disciplina, paquete de trabajo, etapa o entregable.
¿Cuándo crear una matriz RACI?
La matriz RACI debe crearse antes de que comiencen las actividades críticas. El mejor momento suele ser durante la planificación, estructuración del alcance, elaboración del proyecto básico, contratación o movilización del proyecto.
Es especialmente útil cuando hay:
- múltiples proveedores o disciplinas;
- interfaces entre proyecto, obra, operación y mantenimiento;
- contratante con varias áreas involucradas;
- proceso de aprobación técnica complejo;
- servicios de ingeniería consultiva u Owner’s Engineering;
- comisionamiento y aceptación técnica;
- due diligence técnica o auditoría;
- riesgo de conflicto entre alcance, contrato y operación.
Cómo construir una matriz RACI paso a paso
Una matriz RACI eficiente depende de claridad de alcance y de una buena comprensión de las partes involucradas.
1. Liste las actividades o entregables
Comience por las actividades relevantes del proyecto. En ingeniería, puede ser más útil trabajar por entregables: proyecto básico, matriz de requisitos, propuesta técnica, revisión de proyecto, informe de due diligence, plan de pruebas, comisionamiento, documentación final y aceptación técnica.
2. Liste los papeles involucrados
Incluya áreas, equipos o funciones, no necesariamente nombres individuales. Ejemplos: contratante, consultoría técnica, proyectista, integrador, proveedor, operación, mantenimiento, compras, jurídico, supervisión y Owner’s Engineering.
3. Asigne R, A, C e I
Para cada actividad, defina quién ejecuta, quién aprueba, quién debe ser consultado y quién debe ser informado. Evite exceso de responsables y procure mantener apenas un Accountable por línea.
4. Revise conflictos y brechas
Verifique si hay actividades sin responsable, sin aprobador, con demasiados aprobadores o con partes críticas ausentes. Estos puntos indican riesgo de gobernanza.
5. Valide con los stakeholders
La matriz RACI solo funciona si las partes involucradas reconocen los papeles definidos. Debe validarse con las áreas impactadas antes de la ejecución. El análisis de stakeholders ayuda a identificar quién necesita participar de esta validación y sobre qué decisiones posee influencia, impacto o legitimidad.
6. Actualice cuando el proyecto cambie
Los proyectos cambian. Si se modifican alcance, proveedores, fases o responsabilidades, la matriz RACI también debe revisarse.
Reglas prácticas para una buena matriz RACI
| Regla | Por qué importa |
|---|---|
| Tener al menos un Responsible por actividad | Evita actividad sin ejecutor |
| Tener solo un Accountable por actividad | Evita decisión sin dueño claro |
| Evitar exceso de Consulted | Reduce lentitud en el flujo de decisión |
| Definir Informed con criterio | Evita comunicación excesiva o insuficiente |
| Revisar actividades sin R o A | Indica brecha de responsabilidad |
| Revisar actividades con muchos R | Puede indicar responsabilidad diluida |
| Alinear la matriz con el contrato | Evita conflicto entre gobernanza y obligación contractual |
| Actualizar después de cambios de alcance | Mantiene la matriz útil durante el proyecto |
Matriz RACI en Ingeniería Consultiva
En la ingeniería consultiva, la matriz RACI es útil porque organiza la relación entre contratante, consultoría, proyectistas, proveedores y operación.
Ayuda a definir quién analiza, quién recomienda, quién aprueba, quién ejecuta y quién necesita ser informado. Esto es importante porque la consultoría técnica normalmente apoya la decisión, pero no siempre es la autoridad final de aprobación.
Por ejemplo, en un análisis de propuesta técnica, la consultoría puede ser responsable de evaluar técnicamente, mientras el contratante es Accountable por la decisión de contratación. Compras y jurídico pueden ser consultados, y operación puede ser informada o consultada dependiendo del impacto.
Este uso se conecta directamente al papel de la Ingeniería Consultiva en el apoyo a decisiones técnicas del contratante.
Matriz RACI en Owner’s Engineering
En Owner’s Engineering, la matriz RACI es especialmente importante porque el Owner’s Engineer actúa en nombre del propietario, pero no sustituye todas las responsabilidades del contratante.
La matriz ayuda a definir límites de actuación entre propietario, Owner’s Engineer, contratista EPC, proyectistas, supervisión, operación y proveedores.
| Actividad | Propietario | Owner’s Engineer | Contratista EPC | Operación |
|---|---|---|---|---|
| Definir requisitos del propietario | A | R | C | C |
| Revisar proyecto ejecutivo | A | R | R | C |
| Acompañar avance técnico | I | R | R | I |
| Validar pruebas y comisionamiento | A | R | R | C |
| Recomendar aceptación técnica | A | R | C | C |
Esta claridad reduce conflicto de autoridad y mejora la gobernanza técnica del proyecto.
En estructuras con propietario, consultoría, proyectistas y contratistas, la RACI necesita respetar las autoridades formales y hacer explícitas las fronteras de actuación. Es especialmente útil para evitar que la coordinación técnica se confunda con transferencia de responsabilidad contractual.
Matriz RACI en Due Diligence Técnica
En una due diligence técnica, la matriz RACI ayuda a organizar la recopilación de documentos, entrevistas, inspecciones, análisis de evidencias, validación de hallazgos, matriz de riesgos y plan de acción.
Sin claridad de papeles, la due diligence puede retrasarse porque los documentos no se envían, las áreas no responden, los proveedores no facilitan información o las decisiones quedan pendientes.
Este uso se conecta al artículo Informe de Due Diligence Técnica: evidencias, matriz de riesgos y plan de acción, porque la calidad del informe depende de la calidad de la información recopilada y de la definición de los responsables de proporcionarla.
Matriz RACI en el análisis de propuesta técnica
En el análisis de propuesta técnica de ingeniería, la matriz RACI ayuda a definir quién compara alcance, quién evalúa precio, quién verifica riesgos, quién consulta operación, quién interactúa con el proveedor y quién aprueba la recomendación final.
| Etapa | Ingeniería | Compras | Jurídico | Operación | Consultoría Técnica |
|---|---|---|---|---|---|
| Definir criterios técnicos | A | C | I | C | R |
| Solicitar aclaraciones | C | A/R | I | C | R |
| Igualar propuestas | A | C | I | C | R |
| Evaluar riesgos contractuales | C | R | A | I | C |
| Emitir recomendación técnica | A | I | I | C | R |
Esta organización evita que la decisión de contratación quede fragmentada entre áreas sin un responsable final definido.
Matriz RACI en el proyecto básico
El proyecto básico depende de definiciones claras de alcance, requisitos, premisas, interfaces, criterios de aceptación y responsabilidades. La matriz RACI ayuda a definir quién proporciona información, quién consolida requisitos, quién valida premisas y quién aprueba el documento final.
También puede utilizarse junto con el checklist de proyecto básico, especialmente antes de licitar o contratar una obra o servicio técnico.
Matriz RACI en el comisionamiento y aceptación técnica
En el comisionamiento y en la aceptación técnica, la matriz RACI es importante porque pruebas, pendientes, evidencias y documentación final involucran muchas partes.
| Actividad | Contratante | Comisionamiento | Proveedor | Operación |
|---|---|---|---|---|
| Definir criterios de aceptación | A | R | C | C |
| Ejecutar pruebas | I | C | R | C |
| Registrar evidencias | I | R | R | I |
| Clasificar pendientes | A | R | C | C |
| Validar aceptación técnica | A | R | C | C |
| Recibir capacitación | A | C | R | R |
Esta matriz evita que pendientes críticos queden sin dueño y que la aceptación sea firmada sin validación adecuada.
Matriz RACI en coordinación de proyectos BIM
En proyectos multidisciplinarios y BIM, la matriz RACI ayuda a definir responsabilidades entre coordinación, modeladores, proyectistas, contratante, coordinación de interferencias y operación.
Puede apoyar decisiones sobre quién actualiza el modelo, quién valida interferencias, quién aprueba cambios, quién responde por disciplina y quién debe ser informado en cada ciclo de revisión.
Este uso complementa el artículo sobre Coordinación de Proyectos en BIM.
Matriz RACI vs. matriz de riesgos
La matriz RACI y la matriz de riesgos son herramientas diferentes, pero complementarias.
| Herramienta | Finalidad | Pregunta principal |
|---|---|---|
| Matriz RACI | Definir papeles y responsabilidades | ¿Quién hace, aprueba, consulta e informa? |
| Matriz de riesgos | Clasificar riesgos y prioridades | ¿Qué puede afectar el proyecto y cómo responder? |
En proyectos de ingeniería, la matriz de riesgos puede indicar un riesgo crítico, mientras la matriz RACI define quién será responsable de tratar ese riesgo, quién aprueba la respuesta, quién debe ser consultado y quién necesita ser informado.
Errores comunes al usar una matriz RACI
| Error | Consecuencia |
|---|---|
| Tener varios Accountable en la misma actividad | Decisión lenta o sin dueño claro |
| No definir Responsible | Actividad sin ejecutor |
| Colocar a todos como Consulted | Proceso pesado y lento |
| Informar a demasiadas personas | Ruido de comunicación |
| No validar la matriz con las partes | Baja adhesión durante el proyecto |
| No actualizar después de un cambio de alcance | La matriz queda desactualizada |
| Confundir RACI con organigrama | El foco sale de las actividades y pasa a la jerarquía |
| No conectar la matriz al contrato | Riesgo de conflicto entre práctica y obligación contractual |
RACI no sustituye contrato, organigrama, EDT/WBS o plan de comunicación
Una de las causas de matrices excesivamente grandes es intentar que la RACI responda preguntas que pertenecen a otros instrumentos. El contrato define obligaciones, derechos y responsabilidades formales; el organigrama muestra relaciones jerárquicas; la EDT/WBS descompone el alcance; el análisis de stakeholders identifica influencia, impacto y necesidad de involucramiento; el plan de comunicación define información, canal y frecuencia; la matriz de interfaces controla fronteras y dependencias.
La RACI conecta parte de estos elementos al trabajo cotidiano. Ayuda a responder quién ejecuta, quién responde por el resultado, quién debe contribuir antes de una decisión y quién necesita ser informado. Si existe conflicto entre la matriz y una obligación contractual, el problema no se resuelve “siguiendo la RACI”: la inconsistencia debe analizarse y preservarse la fuente formal de autoridad.
RACI y análisis de stakeholders: C e I no deben elegirse al azar
Los papeles Consulted e Informed dependen directamente de la comprensión de las partes interesadas. El PMBOK 8 describe el análisis de stakeholders a partir de dimensiones como posición, papel, interés, expectativas, actitud, conocimiento e influencia. El artículo sobre análisis de stakeholders profundiza esta lógica para proyectos de ingeniería.
Un área puede tener baja autoridad formal y aun así poseer conocimiento crítico que exige consulta. Operación puede no ejecutar el proyecto, pero ser fuertemente impactada por la solución y necesitar participar en la definición de requisitos y aceptación. Un organismo regulador puede no aparecer en el equipo, pero sus decisiones pueden condicionar hitos. Por eso, C e I no deben distribuirse solamente por jerarquía o por la lista de participantes de las reuniones.
El mapeo de stakeholders ayuda a no olvidar actores relevantes, mientras la matriz de stakeholders ayuda a priorizar el nivel de atención. La RACI utiliza esta información para una pregunta más operacional: ¿en qué actividad o decisión esta parte realmente necesita actuar?
RACI y plan de comunicación: responsabilidad no es flujo de información
Marcar una función como I no significa colocarla en copia en todos los correos. Marcar una función como C tampoco significa invitarla a todas las reuniones. La RACI identifica la necesidad de participación; el plan de comunicación en proyectos debe definir contenido, canal, momento, frecuencia, formato y mecanismo de feedback.
La ABNT NBR ISO 21502 orienta que la comunicación sea planificada según las necesidades de las partes y que las interacciones sean eficaces. Un equipo puede tener una RACI técnicamente correcta y aun así fallar porque las consultas ocurren tarde, las decisiones no se registran o las personas informadas reciben volumen excesivo sin contexto. La matriz es una entrada para el sistema de comunicación, no su sustituto.
RACI y gestión de interfaces: responsabilidad a ambos lados de la frontera
Las interfaces técnicas y contractuales son puntos en los que la claridad de responsabilidad produce impacto directo. Una interfaz existe porque dos o más elementos dependen uno del otro: pueden intercambiar energía, señal, información, espacio, requisitos, documentos, datos o condiciones operacionales.
Imagine una integración entre un sistema de seguridad y la red corporativa. El integrador puede ser R por la configuración de su aplicación; TI puede ser R por la configuración de la red bajo su administración; el propietario puede ser A por una decisión de arquitectura; ciberseguridad puede ser C y operación puede ser C o I. Si la línea dice solamente “integración”, múltiples R parecen conflicto. Si se separan parámetros, entregas y decisiones, la responsabilidad se vuelve comprensible.
Por eso, RACI y Interface Management necesitan dialogar. La matriz de interfaces muestra dónde existen dependencias; la RACI ayuda a organizar quién actúa, quién decide, quién proporciona información y quién debe participar del cierre de la interfaz.
RACI en riesgos, cuestiones y cambios
La ISO 21502 trata riesgos y cuestiones con atribución clara de responsabilidad y prevé escalamiento cuando una decisión supera la autoridad del equipo. Esta lógica es directamente aplicable a la RACI. Un gerente de proyecto puede ser R por coordinar el análisis de una cuestión, mientras el patrocinador es A por una decisión que supera el límite delegado. Especialistas entran como C y áreas impactadas pueden ser I o C.
En la gestión de riesgos en proyectos, definir un risk owner sin esclarecer su autoridad e interfaces también puede generar responsabilidad nominal. El registro de riesgos necesita identificar quién conduce la respuesta, quién autoriza recursos o cambios y cuándo el asunto debe escalarse.
En el control de cambios, la separación es todavía más evidente: quien solicita no es necesariamente quien analiza; quien analiza no es necesariamente quien autoriza; quien implementa no es necesariamente quien verifica. Una RACI específica para change control puede impedir alteraciones ejecutadas sin análisis de impacto o aprobación válida.
RACI en requisitos, verificación, validación y aceptación
Los proyectos de ingeniería frecuentemente tratan elaboración, revisión, verificación, validación y aceptación como si fueran el mismo acto. No lo son. La gestión de requisitos necesita identificar quién proporciona necesidades, quién consolida requisitos, quién verifica su implementación y quién valida si la solución atiende al uso previsto.
En el cierre, la pregunta no es solamente quién ejecutó. Es quién verificó, quién recomendó, quién poseía autoridad para aceptar y qué evidencias sustentan esa decisión.
En aceptación técnica, un proveedor puede ser R por ejecutar pruebas y entregar evidencias. Una consultoría puede ser R por analizar resultados y recomendar la aceptación. El propietario, sin embargo, puede continuar siendo A por la decisión formal. Colocar a la consultoría como A apenas porque realizó el análisis puede transferir, en el papel, una autoridad que no fue delegada contractualmente.
RACI en contratos y Owner’s Engineering
La matriz RACI no transfiere obligación contractual. Si el contrato atribuye al contratista la responsabilidad por el proyecto ejecutivo, una hoja interna no puede descaracterizar esa obligación. Del mismo modo, el hecho de que un Owner’s Engineer revise documentos, acompañe pruebas o recomiende decisiones no significa que haya pasado a ser responsable por la ejecución técnica del contratista.
La responsabilidad técnica mal definida tiende a transformarse en disputa de alcance. RACI, contrato y matriz de interfaces necesitan apuntar a la misma frontera de responsabilidad.
En Owner’s Engineering, la RACI es particularmente valiosa para separar recomendación técnica de decisión del propietario. El Owner’s Engineer puede conducir Design Reviews, análisis, diligencias, supervisión, verificación de evidencias y recomendaciones. Decisiones relacionadas con presupuesto, apetito de riesgo, cambios contractuales y aceptación formal pueden permanecer con el propietario.
Cómo el modelo de contratación altera la matriz RACI
La PMI Construction Extension disponible en el KB muestra cómo proyectos de ingeniería y construcción reúnen propietario, proyectista, constructor, especialistas, organismos reguladores y otras partes, y cómo las responsabilidades cambian según la estrategia de entrega. Aunque es una referencia histórica, esta observación continúa siendo útil para comprender por qué una RACI no debe copiarse de un contrato a otro.
En design-bid-build, proyecto y construcción tienden a estar separados: el proyectista responde por la documentación de proyecto, el contratista ejecuta y el propietario administra aprobaciones y cambios conforme a los contratos. En design-build, una única organización concentra proyecto y construcción, reduciendo algunas interfaces externas, pero manteniendo la necesidad de separar producción, verificación y aceptación.
En EPC, el contratista asume una amplia integración de ingeniería, procurement y construcción. La RACI necesita respetar esta asignación para no recrear microgestión por parte del propietario, pero debe continuar identificando requisitos, hitos, cambios, interfaces externas y aceptaciones que permanecen bajo autoridad del owner. En EPCM o múltiples paquetes, la cantidad de interfaces aumenta porque la organización gestora coordina actividades ejecutadas por otros contratistas.
Por lo tanto, una RACI técnicamente buena para EPC puede ser inadecuada para EPCM, Design-Build o una contratación fragmentada. El contrato y la estrategia de entrega son entradas obligatorias para la matriz.
La RACI cambia a lo largo del ciclo de vida del proyecto
La organización y las responsabilidades no permanecen estáticas. En la concepción, patrocinador y propietario concentran decisiones de inversión, mientras especialistas producen estudios. En la planificación y proyecto básico, entran requisitos, interfaces y estrategia de contratación. En el proyecto ejecutivo, proyectistas y vendors asumen fuerte responsabilidad de producción, mientras coordinación y Design Review ganan peso.
Durante procurement y fabricación, ingeniería, suministros, jurídico y proveedores comparten diferentes responsabilidades. En la implantación, contratistas de campo, supervisión, planificación, seguridad y operación ganan protagonismo. En el comisionamiento y handover, la distribución cambia nuevamente hacia pruebas, evidencias, capacitación, documentación, validación operacional y aceptación.
Esto justifica matrices específicas por fase o una matriz controlada por revisiones. La misma columna “Contratante” puede tener papel de A en concepción, C en determinados detalles de proyecto y nuevamente A en la aceptación final. La gobernanza debe acompañar la evolución del emprendimiento.
Cómo controlar la RACI como documento vivo
Una matriz que orienta decisiones necesita ser controlada como información de proyecto. Debe poseer responsable por mantenimiento, versión, fecha, alcance de aplicación, fuente de autoridad y disparadores de revisión. Cambios de fase, proveedor, estructura organizacional, contrato, alcance o delegación de autoridad son eventos que justifican revisión.
En ambientes con GED o CDE, el equipo debe consultar una fuente única. Las versiones locales paralelas son especialmente peligrosas porque una actualización de responsabilidad puede ser conocida por un área e ignorada por otra. El registro de stakeholders también debe acompañar cambios relevantes de funciones, influencia y participación.
Indicadores que muestran si la RACI está funcionando
El éxito de la RACI no se mide por la cantidad de celdas llenas, sino por la reducción de ambigüedad. Algunos signos de baja madurez son decisiones vencidas por falta de autoridad clara, actividades iniciadas sin responsable, cuestiones escaladas repetidamente por disputa de papel, cambios implementados sin aprobación, interfaces reabiertas y reuniones cuya pauta recurrente es descubrir “quién debería resolver”.
También conviene observar la distribución vertical de la matriz. Una función con A en casi todas las líneas puede convertirse en cuello de botella decisorio; una disciplina marcada como C en todo puede paralizar el flujo; varios R sin delimitación pueden indicar que el objeto de la línea es demasiado amplio. La lectura vertical complementa la lectura actividad por actividad y permite detectar problemas de diseño organizacional.
Cómo el PMBOK 8 apoya el uso de la matriz RACI
El PMBOK 8ª edición es una referencia importante para el uso de la matriz RACI porque refuerza gobernanza, foco en valor, stakeholders, recursos, áreas de enfoque del proyecto, tailoring y procurement.
| Elemento del PMBOK 8 | Aplicación en la matriz RACI |
|---|---|
| Governance Performance Domain | Define cómo se organizan decisiones, responsabilidades y supervisión |
| Stakeholders Performance Domain | Ayuda a identificar partes involucradas, influencia y necesidad de comunicación |
| Resources Performance Domain | Relaciona recursos, equipos y responsabilidades de ejecución |
| Scope Performance Domain | Conecta responsabilidades a entregables y requisitos |
| Focus Areas | Permite aplicar RACI en iniciación, planificación, ejecución, monitoreo y cierre |
| Procurement Appendix | Apoya la definición de papeles en contratación, proveedores, selección y gestión contractual |
| Tailoring | Adapta la matriz al tamaño, complejidad y criticidad del proyecto |
Checklist práctico para revisar una matriz RACI
| Pregunta | Estado | Observación |
|---|---|---|
| ¿Todas las actividades críticas están listadas? | Sí / No / Parcial | Evitar brechas de gobernanza |
| ¿Cada actividad tiene al menos un Responsible? | Sí / No / Parcial | Garantizar ejecutor definido |
| ¿Cada actividad tiene solo un Accountable? | Sí / No / Parcial | Evitar decisión sin dueño |
| ¿Los Consulted son realmente necesarios? | Sí / No / Parcial | Evitar exceso de consulta |
| ¿Los Informed fueron definidos con criterio? | Sí / No / Parcial | Evitar ruido de comunicación |
| ¿La matriz está alineada con el contrato? | Sí / No / Parcial | Evitar conflicto con obligaciones formales |
| ¿La matriz fue validada con los stakeholders? | Sí / No / Parcial | Aumentar adhesión |
| ¿La matriz será actualizada cuando haya cambios? | Sí / No / Parcial | Mantener utilidad durante el proyecto |
Referencias técnicas
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gestión de proyectos, programas y portafolios — Orientación sobre gestión de proyectos. Rio de Janeiro: ABNT, 2021.
[2] PROJECT MANAGEMENT INSTITUTE. The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8. ed. Newtown Square: PMI, 2025. Disponible en: https://www.pmi.org/standards/pmbok.
[3] PROJECT MANAGEMENT INSTITUTE. Construction Extension to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition. Newtown Square: PMI, 2003.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Disponible en: https://www.iso.org/standard/74947.html.
Preguntas frecuentes
Es una matriz de responsabilidades que asocia actividades o entregables a los papeles Responsible, Accountable, Consulted e Informed, haciendo explícito quién ejecuta, quién responde por el resultado, quién debe ser consultado y quién necesita ser informado.
RACI significa Responsible, Accountable, Consulted e Informed. En español corresponden aproximadamente a responsable de la ejecución, responsable final o aprobador, consultado e informado.
Responsible ejecuta o coordina la ejecución de la actividad. Accountable responde por el resultado y la decisión final. Una buena matriz evita múltiples Accountable para la misma actividad.
Liste actividades o entregables, identifique los papeles involucrados, asigne R, A, C e I, revise brechas y conflictos, valide con los stakeholders y actualice la matriz siempre que cambien responsabilidades o interfaces.
Sí. Reduce ambigüedades entre contratante, proyectistas, supervisión, proveedores, operación y demás partes, principalmente en interfaces, aprobaciones, revisiones, comisionamiento y aceptación.
No. La RACI organiza responsabilidades operacionales y de gobernanza, pero no altera obligaciones contractuales, competencias legales o responsabilidades profesionales formalmente establecidas.
La validación debe involucrar a los responsables por los principales entregables y decisiones, especialmente quien ejerce el papel Accountable y las áreas u organizaciones afectadas por las asignaciones.
Siempre que exista un cambio relevante de alcance, equipo, contrato, proveedor, fase del proyecto, responsabilidades, interfaces o proceso de aprobación.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Contratos, Alcance y Entregables
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Pendientes, RFIs y No Conformidades
Servicios relacionados
Contenidos principales sobre el tema
- Gestión de stakeholders en proyectos: identificación, involucramiento y comunicación
- Análisis de Stakeholders: influencia, impacto, legitimidad, urgencia y priorización en proyectos
- Matriz de Stakeholders: influencia, interés, impacto y priorización en proyectos
- Gestión de Interfaces en Proyectos de Ingeniería
Contenidos técnicos correlatos
