Technical Authority en ingeniería: autoridad técnica, delegación, independencia, requisitos, desviaciones, stage-gates, decisiones y gobernanza.
¡Descúbrelo!
Technical Authority é um mecanismo de governança pelo qual uma organização delega autoridade técnica formal a pessoas ou funções qualificadas para estabelecer, interpretar, manter e defender requisitos, critérios e posições técnicas dentro de limites definidos. O objetivo não é criar uma segunda gestão do projeto, mas assegurar que decisões relevantes para segurança, desempenho, integridade, conformidade e arquitetura sejam avaliadas por uma instância técnica com competência e mandato claros.
En proyectos de ingeniería, la necesidad aparece cuando plazo, costo, alcance, interés comercial o presión operacional pueden competir con requisitos técnicos. Sin una arquitectura de autoridad, las decisiones críticas tienden a depender de influencia informal, seniority percibida o negociación entre áreas. Con una estructura formal, queda definido quién puede aprobar desviaciones, quién interpreta requisitos, quién acepta riesgos técnicos dentro de determinada autoridad y cuándo una cuestión debe escalarse.
Technical Authority no elimina la responsabilidad del gerente de proyecto, del sponsor ni del propietario. Separa perspectivas complementarias: la gestión sigue siendo responsable de la entrega y de los compromisos del proyecto, mientras la autoridad técnica protege criterios, requisitos y límites técnicos que no deberían modificarse sin una evaluación y aprobación adecuadas.
Technical Authority es una función de gobernanza, no un cargo genérico
El término puede designar una persona, una función o una cadena de delegación. El elemento esencial es la combinación de competencia técnica, autoridad formal, independencia suficiente y rendición de cuentas.
NASA utiliza Technical Authority como parte de su sistema de checks and balances, separando autoridad programática y autoridad técnica para que las decisiones no se tomen de forma aislada. En empresas de ingeniería, infraestructura y activos industriales, el mismo principio puede adaptarse sin copiar la estructura institucional de NASA: disciplinas y sistemas críticos reciben autoridades explícitamente definidas para requisitos, estándares, desviaciones y decisiones técnicas.
Esto es diferente de simplemente nombrar al profesional más experimentado. La seniority sin mandato formal no resuelve conflictos de decisión; un mandato sin competencia técnica tampoco.
Gobernanza y gestión deben permanecer diferenciadas
ABNT NBR ISO 21505 diferencia gobernanza y gestión: la gobernanza autoriza, dirige, establece límites y supervisa; la gestión opera dentro de esas restricciones para alcanzar los objetivos organizacionales.
Una estructura de Technical Authority se sitúa en esa frontera. No debe elaborar el cronograma, administrar contrataciones ni sustituir la coordinación cotidiana. Su función es asegurar que determinadas decisiones técnicas respeten principios, requisitos, tolerancias y criterios definidos por la organización.
Esta separación evita dos errores: transformar la autoridad técnica en un gerente paralelo del proyecto o, en el extremo opuesto, dejarla sin poder real para impedir una decisión técnicamente inadecuada.
La autoridad técnica debe nacer dentro del framework de gobernanza. Mandato, límites, rendición de cuentas y escalamiento deben ser explícitos para que las decisiones técnicas no dependan únicamente de una jerarquía informal.
La autoridad técnica necesita una cadena explícita de delegación
Una organización madura puede responder quién concedió la autoridad, sobre qué dominio, con qué límites y durante cuánto tiempo. La delegación puede ser corporativa, por disciplina, sistema, activo, programa o proyecto.
| Elemento | Definición esperada |
| dominio | disciplina, sistema, activo o requisito cubierto |
| autoridad | decisiones que la función puede tomar o aprobar |
| límites | valor, riesgo, criticidad, fase o tipo de desviación |
| escalamiento | autoridad superior para conflitos ou exceções |
| sustitución | quién responde en caso de ausencia o impedimento |
| evidencia | registro formal de la decisión y su justificación |
O objetivo é impedir que a autoridad exista apenas como percepção cultural. Uma decisão técnica relevante precisa ser rastreável ao mandato que permitiu tomá-la.
Technical Authority y Project Assurance no son lo mismo
O Project Assurance en Ingeniería aporta confianza independiente a la gobernanza sobre si el proyecto se está conduciendo adecuadamente y si riesgos, procesos, requisitos y controles están funcionando. Technical Authority tiene otra responsabilidad: tomar, aprobar o sostener determinadas posiciones técnicas dentro de una autoridad formal.
Assurance puede recomendar que un requisito no está adecuadamente controlado. La autoridad técnica puede ser la instancia responsable de decidir sobre la interpretación de ese requisito, aprobar una excepción o rechazar la desviación.
En organizaciones pequeñas, la misma persona puede acumular funciones, pero los roles deben seguir conceptualmente separados para evitar autoevaluación y conflictos de interés.
Technical Authority y Design Authority también deben diferenciarse
Design Authority suele estar asociada a la integridad de una solución, arquitectura o configuración de diseño. Technical Authority puede tener un alcance más amplio, incluyendo políticas, requisitos, estándares, criterios de ingeniería, seguridad, métodos y excepciones.
En algunos contextos, Design Authority es una manifestación específica de la autoridad técnica sobre el diseño. En otros, la organización separa autoridad por disciplina, sistema y arquitectura. El nombre es menos importante que la definición explícita de responsabilidad.
O Design Management en Ingeniería organiza el proceso de desarrollo del proyecto; Technical Authority establece o protege límites decisorios que ese proceso debe respetar.
Los requisitos técnicos necesitan un propietario de autoridad
A Gestión de Requisitos en Ingeniería funciona mejor cuando los requisitos críticos tienen origen, responsable, método de verificación y autoridad definida para interpretación y cambio.
No todo requisito exige aprobación de una Technical Authority. El modelo debe ser proporcional. Los requisitos de seguridad, desempeño crítico, interfaces sistémicas, cumplimiento regulatorio, capacidad, disponibilidad, protección e integridad estructural o funcional tienden a exigir controles más fuertes.
Cuando no existe una autoridad definida, las solicitudes de cambio pueden circular por varias áreas hasta que prevalezca la decisión de quien tenga mayor influencia circunstancial.
Los requisitos críticos necesitan una autoridad definida para interpretación y cambio. La trazabilidad técnica pierde fuerza cuando nadie sabe quién puede aceptar una desviación, modificar la baseline o reconocer la evidencia de cumplimiento.
Gestión de Requisitos, Evidencias y Criterios de Aceptación →
Las desviaciones, waivers y excepciones necesitan autoridad técnica
Los proyectos reales conviven con incompatibilidades de campo, indisponibilidad de equipos, cambios de proveedor, restricciones de plazo y nueva información. La gobernanza técnica no debe fingir que las desviaciones no existirán; debe definir cómo serán evaluadas.
Una solicitud de desviación técnicamente controlada debería identificar el requisito afectado, la condición propuesta, la justificación, alternativas evaluadas, impactos en seguridad, desempeño, confiabilidad, interfaces, costo y plazo, riesgos residuales, verificaciones adicionales y la autoridad necesaria para aprobación.
La decisión puede incluir aprobación condicionada, solución temporal, mitigación obligatoria, limitación operacional o necesidad de una nueva revisión.
Las interfaces son puntos clásicos de conflicto de autoridad
A Gestión de Interfaces en Proyectos de Ingeniería aborda los límites entre sistemas, disciplinas, contratos y organizaciones. Es en esos límites donde con frecuencia surge la pregunta: ¿quién tiene la decisión final?
Una interfaz eléctrica puede involucrar potencia disponible, protección, selectividad, mando y automatización. Una interfaz civil-electromecánica puede involucrar cargas, inserts, accesos y tolerancias. Una interfaz de telecomunicaciones puede involucrar protocolos, direccionamiento, sincronización y ciberseguridad.
La matriz de interfaces debería indicar no solo responsables de producir información, sino también la autoridad para resolver divergencias que superan la coordinación rutinaria.
La independencia debe ser suficiente para sostener una posición técnica
Una autoridad técnica incapaz de discrepar del equipo que controla su presupuesto, evaluación o prioridad puede existir solo formalmente. La independencia no tiene por qué significar una organización separada en todos los casos, pero el diseño debe reducir conflictos de interés incompatibles con la criticidad de la decisión.
Cuanto mayor sea el riesgo técnico, más relevante es separar quién produce, quién revisa y quién autoriza. Esta lógica también sustenta revisiones independientes, assurance y determinados stage-gates.
Independencia, sin embargo, no significa ausencia de integración. Technical Authority debe participar lo suficientemente temprano para que su actuación no se limite a un veto tardío.
La independencia no es aislamiento: es la capacidad de sostener una conclusión técnica sin un conflicto de interés incompatible. Cuanto mayor sea la criticidad, más importante es separar producción, revisión, assurance y autoridad decisoria.
Los stage-gates deben explicitar qué decisiones son técnicas
Los gates de decisión son más robustos cuando distinguen autorización de negocio, autorización programática y aceptación técnica. Un gate puede decidir si el proyecto debe continuar, pero esa decisión depende de evidencias que pueden exigir aprobación técnica previa.
Los criterios típicos incluyen madurez de requisitos, resolución de riesgos críticos, integridad de interfaces, conclusión de Design Reviews, estado de desviaciones, readiness para contratación, readiness para pruebas y cumplimiento de criterios de seguridad.
A Gobernanza de Proyectos, Programas y Portafolios debe definir estas autoridades sin transformar cada gate en una reunión excesivamente burocrática.
La autoridad puede distribuirse por niveles de criticidad
Un modelo escalable evita que todas las decisiones lleguen a la máxima autoridad. La organización puede establecer niveles para decisiones rutinarias, decisiones multidisciplinarias, cambios que afectan requisitos críticos y excepciones de alta consecuencia.
La clasificación puede combinar consecuencia, reversibilidad, impacto sistémico, exposición regulatoria e incertidumbre. El objetivo es mantener las decisiones simples cerca del equipo y elevar solamente aquello que realmente exige autoridad adicional.
Las decisiones técnicas deben producir registros técnicos
Sin registro, la organización pierde la memoria de por qué se adoptó determinada solución. Technical Authority debe operar con artefactos proporcionales al riesgo: decision log, dictamen, technical query, deviation request, waiver, acta decisoria, aprobación en workflow o registro en sistema de requisitos.
El registro debería preservar problema, opciones, criterios, evidencias, decisión, condiciones, responsables, fecha e impactos asociados.
Esta disciplina conecta Technical Authority con la gestión documental, Engineering Change Management y la construcción de un historial utilizable en operación, auditorías y proyectos futuros.
Technical Authority participa en el cambio, pero no sustituye Change Control
Un cambio relevante puede exigir evaluación técnica, comercial, contractual, financiera y de plazo. Technical Authority es responsable de la parte dentro de su autoridad, no de toda la decisión integrada.
En Engineering Change Management, la autoridad técnica debe aparecer en el flujo como aprobador o consultado según el tipo de cambio. Después de la decisión, requisitos, documentos, modelos, interfaces, contratos y verificaciones deben actualizarse de manera consistente.
Esta integración impide que una aprobación técnica se confunda con una autorización contractual o que una autorización comercial modifique silenciosamente la baseline técnica.
Competencia y sucesión forman parte del modelo
Delegar autoridad exige criterios de competencia. Experiencia, formación, conocimiento del activo, dominio normativo, capacidad de juicio e independencia son dimensiones más útiles que un título jerárquico aislado.
La organización también necesita sucesión. Una función crítica dependiente de una sola persona crea riesgo operacional y puede paralizar aprobaciones. Una matriz de competencias, autoridades sustitutas y registros de delegación reducen esa dependencia.
La autoridad debe revisarse cuando cambian la función, el proyecto, el riesgo, el alcance o la estructura organizacional.
Technical Authority debe adaptarse a la escala de la organización
No toda empresa necesita una red formal equivalente a la de una agencia espacial. En una organización menor, el modelo puede ser una matriz de autoridades por disciplina y un procedimiento de escalamiento. En una cartera extensa de CAPEX, puede exigir autoridades por disciplina, sistema y nivel organizacional.
El criterio es proporcionalidad: formalización suficiente para evitar ambigüedad decisoria sin crear una cadena que retrase decisiones simples.
A Gestión de Ingeniería proporciona el contexto más amplio en el que autoridades, requisitos, interfaces, assurance, PMO y controles deben funcionar como un sistema integrado.
Señales de que una organización necesita formalizar la autoridad técnica
Algunos síntomas aparecen antes de un incidente: decisiones críticas sin responsable claro, repetición de discusiones ya cerradas, desviaciones aprobadas sin trazabilidad, proveedores interpretando requisitos de maneras diferentes, conflictos recurrentes entre disciplinas, aprobaciones basadas únicamente en el cargo, ingeniería presionada para aceptar una solución sin evaluación registrada o cambios que no llegan a los documentos afectados.
Otra señal es la dependencia de personas específicas para desbloquear cualquier cuestión técnica. Esto indica que la autoridad existe informalmente, pero no fue transformada en un proceso institucional.
Formalizar significa transformar influencia dispersa en responsabilidad verificable.
Una buena Technical Authority mejora la calidad de la decisión técnica
El resultado esperado no es producir más aprobaciones. Es garantizar que las decisiones relevantes se tomen en el nivel correcto, por personas competentes, con evidencias suficientes, límites conocidos y posibilidad de escalamiento.
Cuando esta estructura está integrada con la gobernanza, requisitos, interfaces, Design Review, Project Assurance y change control dejan de operar como mecanismos aislados. La organización pasa a tener una arquitectura explícita para decidir, registrar, cuestionar y sostener posiciones técnicas a lo largo del ciclo de vida.
Referencias técnicas
[1] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. Technical Authority. Office of the Chief Engineer. Washington, DC: NASA.
[2] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. NPR 7120.5F — NASA Space Flight Program and Project Management Requirements, Chapter 3: Technical Authority. Washington, DC: NASA.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21505:2017 — Project, programme and portfolio management — Guidance on governance. Geneva: ISO, 2017.
Preguntas frecuentes
Es una función de gobernanza con autoridad técnica formalmente delegada para establecer, interpretar, mantener o aprobar requisitos, criterios, desviaciones y decisiones dentro de un dominio y una autoridad definidos.
No. El gerente de proyecto sigue siendo responsable de la entrega y de los compromisos del proyecto. Technical Authority protege decisiones y límites técnicos específicos dentro de la estructura de gobernanza.
Project Assurance aporta una visión independiente sobre la salud y la confianza del proyecto. Technical Authority tiene mandato para tomar, aprobar o sostener determinadas decisiones técnicas.
No necesariamente. Design Authority suele concentrarse en la integridad de la solución o arquitectura de diseño. Technical Authority puede tener un alcance más amplio sobre requisitos, estándares, disciplinas, sistemas, desviaciones y criterios técnicos.
Cuando hay decisiones críticas sin propietario claro, conflictos recurrentes entre disciplinas, desviaciones sin trazabilidad, alta criticidad técnica, múltiples proveedores o presión de plazo y costo que pueda comprometer requisitos y riesgos.
Definiendo dominios, niveles de autoridad, criterios de criticidad, cadena de escalamiento y registros proporcionales al riesgo, manteniendo las decisiones rutinarias en el equipo y elevando únicamente excepciones relevantes.
Materiales técnicos complementarios
Soluciones relacionadas
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Gestión de Contratos, Alcance y Entregables
Servicios de ingeniería relacionados
- Owner’s Engineering
- Design Review en Proyectos de Ingeniería
- Gestión de Proyectos de Ingeniería
- Project Controls
Contenidos técnicos relacionados
- Project Assurance en Ingeniería
- Gestión de Requisitos en Ingeniería
- Gestión de Interfaces en Proyectos de Ingeniería
- Design Management en Ingeniería
- Engineering Change Management en Proyectos de Ingeniería
- Design Review en Proyectos de Ingeniería
Guías, frameworks y referencias
