Veja como identificar falhas de governança em projetos de Engenharia por meio de sinais em alçadas, comitês, gates, mudanças, riscos, decisões e autoridade técnica.
Confira!
Falhas de governança em projetos de Engenharia aparecem quando decisões importantes deixam de ter responsável, critério, evidência ou momento adequado. O efeito costuma surgir como atraso, retrabalho, conflito entre áreas, mudança tardia, escalonamento excessivo ou avanço de etapa sem maturidade suficiente.
Identificar essas falhas exige olhar além do cronograma e do status report. Um projeto pode estar formalmente “verde” e ainda possuir requisitos não estabilizados, riscos sem owner, decisões técnicas sem registro, mudanças fora de baseline ou gates tratados apenas como reuniões de passagem. Nesse cenário, o problema não é necessariamente execução: é o sistema pelo qual a organização decide.
A pergunta central é: quem decide o quê, com base em quais critérios, em qual momento e com qual evidência? Quando essa resposta é ambígua, a governança está vulnerável.
Como reconhecer que o problema é governança, e não apenas execução
A primeira tarefa é distinguir falha de execução de falha de governança.
Uma atividade pode atrasar porque levou mais tempo para ser executada. Isso é um problema de execução ou planejamento. Também pode atrasar porque ficou duas semanas aguardando uma decisão que não tinha owner claro. Nesse caso, a causa é governança.
Da mesma forma, um cálculo incorreto é falha técnica de execução. Já um requisito alterado sem atualização de baseline é falha de governança.
| Situação | Natureza predominante |
| atividade técnica demorou acima do previsto | execução |
| decisão ficou sem responsável | governança |
| documento foi emitido com erro | execução / qualidade |
| documento foi produzido com requisito desatualizado | governança / configuração |
| fornecedor não cumpriu prazo | execução / contrato |
| fornecedor recebeu orientações conflitantes | governança |
| risco ocorreu apesar de plano adequado | execução do tratamento |
| risco crítico nunca teve owner | governança |
Essa separação é importante porque soluções erradas aumentam burocracia. Criar comitê não corrige produtividade; pressionar a equipe não resolve uma decisão sem alçada.
Sintomas recorrentes
A governança costuma falhar de forma repetitiva. Alguns sintomas aparecem em diferentes projetos e unidades.
| Sintoma | Hipótese de governança |
| decisões sempre sobem para a diretoria | alçada mal calibrada |
| mudanças acontecem antes da aprovação | change control fraco |
| comitês discutem, mas não concluem | fórum sem mandato |
| projeto passa de gate com pendências essenciais | critério de maturidade insuficiente |
| áreas disputam responsabilidade | decision rights ambíguos |
| fornecedor conduz decisão crítica | autoridade técnica do proprietário enfraquecida |
| riscos permanecem abertos sem resposta | accountability insuficiente |
| decisões são reabertas | critério, registro ou baseline inadequados |
O diagnóstico precisa buscar padrões e amostras de decisões reais, não apenas percepções gerais.
Decision rights, alçadas e escalonamento
Quando decisões simples sobem continuamente e decisões críticas permanecem sem escalonamento, a organização não tem apenas um problema de velocidade: tem um problema de desenho de autoridade.
Governança começa pela clareza de decisão. Atividades podem ser compartilhadas; decisões precisam ter autoridade reconhecida.
A organização deve identificar quais classes de decisão existem: prioridade, requisito, mudança, risco, tecnologia, desvio, aceite, contratação, liberação para próxima fase. Para cada classe, é preciso definir quem recomenda, quem analisa, quem decide, quem precisa ser consultado e quando existe escalonamento.
Alçada adequada não significa centralizar tudo no nível mais alto. Significa posicionar a decisão no nível compatível com seu risco e materialidade.
| Critério de materialidade | Pergunta |
| segurança | a decisão altera exposição de pessoas ou ativos? |
| disponibilidade | pode comprometer operação ou continuidade? |
| custo | ultrapassa limite financeiro relevante? |
| prazo | altera marco crítico? |
| requisito | modifica requisito essencial ou regulatório? |
| reversibilidade | a decisão é difícil de desfazer? |
| precedente | cria padrão para outros projetos? |
| interface | afeta múltiplas disciplinas ou contratos? |
A combinação desses fatores ajuda a determinar quem deve decidir.
Escalonamento excessivo
Quando decisões simples chegam continuamente à diretoria, o problema pode estar em alçadas estreitas, insegurança dos gestores ou ausência de critérios de materialidade.
Isso cria fila decisória, reduz autonomia e aumenta lead time.
O oposto também é perigoso: decisões críticas mantidas em nível baixo sem revisão suficiente.
| Situação | Indicação |
| tudo é escalado | delegação insuficiente |
| quase nada é escalado | risco de autoridade excessiva local |
| escalonamento depende da pessoa | critério inconsistente |
| exceções diferentes chegam ao mesmo fórum | governança pouco proporcional |
| decisão técnica é tomada por autoridade administrativa sem suporte | fronteira mal definida |
Uma boa arquitetura distribui decisão e preserva controle.
Decisões sem owner
Um dos sinais mais claros de falha é uma decisão descrita como “da Engenharia”, “do projeto” ou “do comitê” sem responsável individual ou papel formal.
Isso normalmente resulta em espera ou conflito.
Mudanças de requisito, aceitação de risco residual, seleção de tecnologia, liberação de documento, aprovação de desvio e readiness para operação são exemplos de decisões que precisam de ownership explícito.
Comitês, fóruns e stage-gates
Gate sem evidência é apenas uma reunião. A decisão de avançar precisa considerar maturidade de requisitos, riscos, interfaces, custos e condições para a próxima etapa.
Reunião não é governança. Comitê também não é governança por si só.
Um fórum só agrega valor quando possui mandato: quais decisões pode tomar, quais informações recebe, quem participa, qual quórum é necessário, o que acontece quando não há consenso e como a decisão é registrada.
Sem isso, o comitê se transforma em status meeting.
Como avaliar um fórum decisório
Um diagnóstico pode revisar reuniões e comitês segundo alguns critérios simples.
| Critério | Pergunta |
| finalidade | que decisão o fórum existe para tomar? |
| autoridade | quais decisões são permitidas? |
| participantes | estão presentes os papéis necessários? |
| entrada | quais evidências precisam chegar antes? |
| frequência | o ritmo é compatível com a decisão? |
| saída | decisão, ação, owner e prazo ficam registrados? |
| escalonamento | existe caminho quando o fórum não resolve? |
Se a maior parte das reuniões termina apenas com “vamos verificar”, pode haver um problema de mandato.
Stage-gates
Gate é uma decisão sobre avanço. Não deveria ser uma cerimônia associada a uma data de cronograma.
Um gate precisa verificar se o projeto atingiu maturidade suficiente para comprometer recursos na próxima etapa.
| Dimensão | Evidência típica |
| requisitos | baseline e principais interfaces definidas |
| solução | nível de definição compatível |
| riscos | riscos críticos identificados e tratados |
| custo | estimativa adequada ao estágio |
| prazo | cronograma coerente com escopo |
| contratação | estratégia e pacotes definidos |
| operação | critérios de aceite e handover considerados |
| documentação | entregáveis mínimos disponíveis |
Quando a organização permite avanço mesmo sem atender critérios críticos, o gate perde função de governança.
Mudanças, requisitos, riscos e baseline
Boa parte das falhas de governança se revela quando algo muda.
Projetos de Engenharia mudam naturalmente. O problema é quando a mudança não percorre análise, decisão e atualização de baseline.
Uma alteração de especificação pode afetar custo, prazo, contrato, segurança, operação, documentação e testes. Se apenas uma dessas dimensões for considerada, o projeto cria incoerência.
A sequência de governança deveria ser:
solicitação → análise multidisciplinar → decisão → atualização de baseline → comunicação → implementação → verificação
Se o projeto implementa antes de decidir, a governança foi ultrapassada. Se decide e não atualiza documentos, a configuração fica divergente.
Governança de requisitos
Requisito é um compromisso. Alterá-lo deve ser tratado como decisão, não como simples revisão documental.
A organização precisa identificar owners de requisitos, critérios para baseline, condições para mudança e evidências de verificação.
Requisitos técnicos, operacionais, regulatórios e contratuais podem ter owners diferentes. A governança deve coordenar essas perspectivas.
Governança de riscos
Risco também precisa de autoridade.
Registrar risco sem owner ou sem decisão de tratamento é apenas documentação.
Riscos críticos precisam ser escalados ao nível capaz de autorizar resposta ou aceitar risco residual.
A aceitação não deve acontecer implicitamente pelo simples avanço do cronograma.
Gestão de configuração
A baseline aprovada precisa permanecer coerente entre requisitos, documentos, equipamentos, software e estado físico.
Quando a decisão existe, mas o estado configurado não é atualizado, a governança perde rastreabilidade.
Esse ponto é especialmente importante em ambientes brownfield, projetos multidisciplinares e sistemas críticos.
Technical Authority, independência e decisão técnica
Algumas decisões exigem competência técnica e independência suficientes para resistir a pressões de prazo, custo ou conveniência local.
Technical Authority é um mecanismo possível para essa finalidade.
Ela pode atuar na aprovação de requisitos críticos, aceitação de desvios, mudanças de arquitetura, exceções a standards e readiness técnico.
O papel, entretanto, precisa ser delimitado. Technical Authority não substitui gerente de projeto, responsável técnico legal, gestor contratual ou direção executiva.
| Papel | Responsabilidade típica |
| gestor de projeto | integração de escopo, prazo, custo e risco |
| responsável técnico | responsabilidade profissional pela produção técnica |
| Technical Authority | decisão técnica crítica e exceções |
| Qualidade | processo, conformidade e evidências |
| Contratos | efeitos contratuais e comerciais |
| Operação | requisitos operacionais e aceitação do ativo |
| sponsor | direção e decisões executivas |
A governança funciona quando essas fronteiras são complementares.
Quando falta independência
Se a mesma pessoa produz, revisa e aceita uma decisão crítica, a organização pode perder proteção contra erro ou viés.
Nem toda entrega exige revisão independente. A criticidade deve definir o nível de independência necessário.
Self-check, peer review, Design Review, Technical Assurance e revisão independente são camadas diferentes.
Governança precisa definir onde cada uma é necessária.
Governança de fornecedores, contratos e interfaces
Em projetos terceirizados, governança não pode terminar na fronteira da empresa.
Projetistas, integradores, fabricantes e EPCistas tomam decisões e produzem documentos que afetam o proprietário. O contratante precisa preservar capacidade para especificar, revisar, integrar e aceitar.
Isso não significa microgerenciar o fornecedor. Significa manter autoridade sobre requisitos, desvios, mudanças e aceite.
Um problema comum ocorre quando o fornecedor recebe orientações divergentes de diferentes áreas do cliente. Outro aparece quando Engenharia aprova uma solução tecnicamente, mas Contratos não avalia impacto de prazo ou custo.
A governança deve integrar essas dimensões.
| Interface | Pergunta |
| Engenharia ↔ Contratos | mudança técnica altera obrigação contratual? |
| Engenharia ↔ Suprimentos | fornecedor atende requisitos e risco? |
| Engenharia ↔ Operação | solução atende uso e manutenção? |
| Fornecedor ↔ Owner | quem aprova, comenta e aceita? |
| Projeto ↔ Campo | revisão correta está liberada? |
| Campo ↔ Comissionamento | há readiness para testar? |
Interfaces sem owner produzem conflitos difíceis de rastrear.
Governança de portfólio e priorização
Falhas de governança também aparecem acima do projeto individual.
Quando a organização inicia muitos projetos, disputa recursos críticos e muda prioridades continuamente, o problema pode estar no portfólio.
Governança de portfólio precisa decidir quais iniciativas devem iniciar, continuar, pausar ou ser encerradas.
Um gerente de projeto naturalmente defende sua iniciativa. A organização precisa de critérios acima do projeto para arbitrar prioridade.
Critérios podem incluir alinhamento estratégico, risco, retorno, obrigação regulatória, maturidade, capacidade e dependências.
Sinais de falha no portfólio
Muitos projetos iniciados e poucos concluídos são um sinal clássico. Outros incluem projetos sem sponsor, iniciativas que continuam mesmo após perda do business case, recursos críticos comprometidos acima da capacidade e investimentos que avançam sem maturidade técnica.
A governança precisa permitir dizer “ainda não” ou “não mais”.
Essa capacidade reduz dispersão de recursos e transferência prematura de incerteza para execução.
Project Controls e informação para governança
Governança depende de informação confiável.
Cronograma, custos, forecast, riscos, requisitos e pendências precisam chegar ao nível decisório em formato adequado.
Project Controls possui papel importante porque transforma dados de execução em previsão.
| Informação | Decisão |
| forecast de atraso | recuperar, replanejar ou aceitar |
| tendência de custo | mitigar, aprovar mudança ou rever escopo |
| risco crítico | tratar, transferir ou aceitar |
| requisito não maduro | bloquear ou condicionar avanço |
| pendência crítica | resolver antes do gate |
| baixa readiness | adiar mobilização ou comissionamento |
Se o dado chega tarde, a decisão também chega tarde.
Se o dado mede apenas atividade e não maturidade, o projeto pode parecer saudável sem estar pronto.
Indicadores de governança
Governança pode ser medida.
Tempo médio de decisão, decisões reabertas, exceções fora de alçada, riscos sem owner, mudanças sem baseline, gates condicionais e pendências críticas sem responsável são exemplos.
O indicador precisa ser interpretado. Tempo de decisão menor não significa melhoria se a quantidade de decisões reabertas aumenta.
A governança deve equilibrar velocidade e qualidade.
Como diagnosticar e corrigir falhas de governança
O diagnóstico deve partir de decisões reais.
Entrevistas mostram percepção, mas amostras de decisões revelam o sistema em funcionamento.
É útil selecionar casos de mudança, desvio, risco, gate, contratação e aceite e reconstruir: quem iniciou, quem analisou, quem decidiu, quanto tempo levou, quais evidências foram usadas e quais documentos foram atualizados.
| Etapa do diagnóstico | Objetivo |
| mapear classes de decisão | entender o que precisa de governança |
| mapear papéis | identificar owners e sobreposições |
| revisar alçadas | avaliar proporcionalidade |
| revisar fóruns | verificar mandato e decisão |
| analisar gates | testar maturidade e evidências |
| revisar mudanças | verificar baseline e rastreabilidade |
| medir tempos | localizar filas decisórias |
| amostrar decisões | confrontar processo com prática |
| desenhar TO-BE | corrigir gaps de autoridade |
| testar piloto | validar funcionamento real |
A correção pode envolver matriz de decision rights, redefinição de alçadas, revisão de fóruns, critérios de gate, change control, Technical Authority ou simplificação.
Governança excessiva também é falha
Adicionar controles não é automaticamente melhorar governança.
Múltiplas aprovações, comitês redundantes e gates sem risco correspondente aumentam lead time.
Cada controle deve responder a um risco ou decisão.
Se não reduz risco, não cria evidência ou não melhora a decisão, sua necessidade precisa ser questionada.
Como testar um novo modelo
Implantar governança em toda a organização de uma vez aumenta risco de desenho inadequado.
Um projeto piloto permite verificar clareza de papéis, tempo de decisão, volume de escalonamentos e aderência.
Com base nos resultados, alçadas e fóruns podem ser ajustados antes da expansão.
O modelo está realmente implantado quando funciona em decisões reais, e não apenas quando o procedimento foi aprovado.
Nas decisões em que tecnologia, investimento ou estratégia de contratação podem alterar o rumo do empreendimento, a governança precisa tornar explícitas as opções descartadas e as incertezas assumidas. Uma recomendação consistente compara alternativas com critérios comuns de custo, desempenho, riscos e condições de execução, documentando as premissas que levaram à escolha. Assim, a autoridade responsável pode justificar o compromisso e reconsiderá-lo quando surgirem novas evidências.
Engineering Advisory na estruturação de decisões e critérios técnicos
Quando contratar apoio externo e o que esperar
Apoio externo é útil quando conflitos se repetem, quando a organização não consegue separar autoridade técnica de administrativa, quando precisa revisar alçadas ou quando deseja estruturar Technical Authority, assurance ou gates.
A independência também ajuda quando o próprio modelo atual dificulta questionar práticas existentes.
O trabalho deve produzir mais que organogramas. Espera-se uma arquitetura de decisão com papéis, alçadas, fóruns, critérios, registros, indicadores e roadmap de implantação.
A aceitação deve verificar se as decisões críticas possuem owner, se os fóruns têm mandato, se os gates usam evidências, se mudanças preservam baseline e se stakeholders compreendem suas responsabilidades.
Exemplo: atraso causado por decisão, não por execução
Considere um pacote técnico registrado como dez dias atrasado. O status atribui responsabilidade à Engenharia, mas a reconstrução mostra que o documento estava pronto no prazo e permaneceu nove dias aguardando decisão sobre exceção a um standard corporativo. Três níveis hierárquicos participaram da discussão e nenhum papel tinha autoridade explicitamente definida.
A causa não está na velocidade de produção. Está no desenho da decisão. A correção pode envolver classificação da exceção, critério de materialidade, autoridade, substituto e prazo esperado. Esse tipo de análise evita que a organização trate governança como problema de performance individual.
Velocidade e qualidade decisória precisam ser medidas juntas
Reduzir tempo de decisão é desejável, mas uma governança mais rápida pode ser pior se as decisões precisarem ser reabertas. A análise deve observar estabilidade, suficiência das evidências, atualização de baseline e consequência posterior.
| Indicador | O que ajuda a avaliar |
|---|---|
| tempo médio de decisão | velocidade |
| decisões reabertas | estabilidade |
| mudanças posteriores | maturidade da análise |
| exceções fora de alçada | aderência |
| baseline não atualizada | rastreabilidade |
Urgência não elimina governança
Projetos e operações críticas precisam tomar decisões emergenciais. Isso não significa abandonar governança. Significa possuir um caminho apropriado: alçada emergencial, registro mínimo, limite temporal, responsáveis e revisão posterior.
Sem essa estrutura, exceções emergenciais tornam-se permanentes sem análise e documentos deixam de refletir o estado real. A governança madura permite agir rápido preservando rastreabilidade.
Governança precisa sobreviver à troca de pessoas
Um teste importante é perguntar se o projeto manteria coerência após a substituição de um gerente, coordenador ou especialista. Quando decisões existem apenas na memória dos profissionais, a governança depende de pessoas e não do sistema.
Registros de decisão, baseline, atas decisórias, critérios e trilhas de aprovação preservam contexto e reduzem rediscussão. Essa memória também melhora assurance e transferência para operação.
Como analisar uma decisão real de ponta a ponta
Uma forma objetiva de diagnosticar governança é escolher uma decisão relevante já concluída e reconstruir seu caminho. A análise começa no evento que exigiu decisão, passa pelas informações disponíveis, pelas áreas consultadas, pelo fórum utilizado e termina na atualização dos documentos afetados.
Esse exercício costuma revelar gaps que não aparecem em organogramas: documentos que chegam tarde ao decisor, análises duplicadas, pessoas consultadas sem necessidade, ausência de critério para escalonamento ou decisões que não geram atualização da baseline.
| Passo | Evidência a verificar |
|---|---|
| gatilho | evento, risco, mudança ou desvio que exigiu decisão |
| análise | alternativas, impactos e premissas consideradas |
| autoridade | quem possuía alçada formal |
| fórum | onde a decisão ocorreu |
| registro | ata, decision log, parecer ou aprovação |
| efeito | documentos, contratos e baselines atualizados |
Quando vários casos apresentam o mesmo ponto de ruptura, o problema deixa de ser episódico e passa a indicar falha estrutural.
Accountability: quem responde pelo resultado da decisão
Governança não termina quando alguém aprova. A organização precisa saber quem acompanha consequência, ação decorrente e risco residual. Uma decisão tecnicamente correta pode falhar na implementação se ninguém possuir accountability pelo resultado.
Isso é especialmente importante em mudanças de escopo, exceções e aceites condicionais. Se o decisor aprova uma exceção com ações compensatórias, essas ações precisam de owner, prazo e verificação. Caso contrário, o risco apenas muda de lugar.
Quando o sponsor está ausente ou atua apenas em crise
Projetos também apresentam falha de governança quando o sponsor aparece apenas depois que prazo ou custo já foram comprometidos. O sponsor não precisa participar da operação diária, mas deve assumir decisões estratégicas, remover impedimentos de alto nível e confirmar prioridades.
A ausência de sponsor cria espaço para conflitos entre áreas sem mecanismo de arbitragem. Já a presença excessiva em decisões operacionais pode retirar autonomia da equipe. O desenho deve equilibrar direção e delegação.
Governança de benefícios e resultado esperado
Um projeto pode cumprir prazo e orçamento e ainda entregar pouco valor se a organização perder de vista o benefício esperado. Governança precisa preservar a ligação entre investimento, necessidade e resultado.
Isso significa revisar periodicamente se o business case continua válido, se as premissas mudaram e se os requisitos ainda representam o objetivo original. Projetos que permanecem ativos apenas porque já consumiram recursos demonstram governança fraca de portfólio.
Como tratar desacordo técnico sem paralisar o projeto
Divergência entre especialistas é normal em Engenharia. O problema surge quando não existe mecanismo para resolvê-la. Sem critério de desempate, o projeto pode alternar entre opiniões ou escalar todo conflito para a direção.
O modelo pode prever peer review, Technical Authority, consulta a norma, análise multicritério ou revisão independente conforme criticidade. O importante é definir antes quem possui a palavra final e quais evidências precisam ser consideradas.
Sinais de que a governança está criando burocracia sem reduzir risco
Governança também pode falhar por excesso. Aprovações em série, comitês com sobreposição e relatórios que não suportam decisão aumentam custo de coordenação. Um controle só se justifica quando reduz risco, aumenta transparência, cria evidência ou melhora uma decisão.
Se uma aprovação nunca rejeita, condiciona ou altera nenhuma decisão, sua utilidade deve ser revisada. Se dois fóruns analisam o mesmo tema com os mesmos participantes, pode existir duplicidade. Se o relatório é produzido, mas nenhum indicador possui ação associada, existe formalidade sem governança efetiva.
| Sinal | Possível correção |
|---|---|
| muitas aprovações sequenciais | consolidar ou delegar por risco |
| comitês sobrepostos | redefinir mandato |
| relatórios sem decisão | vincular indicador a ação |
| gates sempre aprovados | revisar critérios e independência |
| decisões reabertas | melhorar evidência e registro |
Governança e maturidade organizacional
O modelo precisa ser proporcional à maturidade da organização. Estruturas muito sofisticadas podem falhar se papéis básicos ainda não estão claros. Em contextos de baixa maturidade, a prioridade pode ser definir owners, alçadas mínimas, registro de decisões e critérios de escalonamento.
À medida que a organização amadurece, pode incorporar assurance, gates mais estruturados, gestão de portfólio e métricas avançadas. Governança deve evoluir em camadas, preservando utilidade operacional.
Como a governança deve lidar com informação incompleta
Decisões de Engenharia raramente são tomadas com informação perfeita. Governança madura não exige certeza absoluta; exige clareza sobre o grau de incerteza e sobre quem pode assumir o risco associado. Isso significa registrar premissas, limitações, dados ausentes e condições que poderiam alterar a decisão.
Quando a informação é insuficiente, existem alternativas diferentes de simplesmente aprovar ou rejeitar: condicionar a decisão, solicitar evidência adicional, limitar validade, adotar solução reversível ou criar gate de confirmação posterior. Esses mecanismos permitem avançar sem transformar incerteza desconhecida em risco oculto.
| Condição | Resposta de governança |
|---|---|
| informação suficiente | decidir e atualizar baseline |
| lacuna pequena e reversível | aprovação condicionada |
| lacuna relevante | solicitar análise adicional |
| risco alto e irreversível | bloquear avanço até evidência |
| urgência operacional | decisão temporária + revisão posterior |
Como separar governança corporativa, de portfólio e de projeto
Outra fonte de conflito é misturar níveis de governança. A camada corporativa define princípios, apetite a risco e padrões. A governança de portfólio arbitra prioridade e capacidade entre iniciativas. A governança de projeto toma decisões dentro da iniciativa. Quando um nível invade sistematicamente o outro, surgem centralização e lentidão.
Uma exceção técnica local pode ser resolvida no projeto quando não cria precedente corporativo. Já a alteração de um standard utilizado por várias unidades pode precisar de autoridade superior. A materialidade e o efeito do precedente ajudam a posicionar a decisão.
Governança também precisa definir como uma decisão termina
Muitas organizações controlam o momento da aprovação, mas não o fechamento. Depois de decidir, é necessário verificar se ações foram executadas, documentos atualizados, stakeholders comunicados e condicionantes encerradas.
Essa etapa de closure é essencial para concessões, mudanças, riscos aceitos e gates condicionais. Sem ela, decisões ficam formalmente aprovadas, mas operacionalmente incompletas.
Um decision log maduro, portanto, não registra apenas “aprovado” ou “rejeitado”. Ele acompanha status das ações decorrentes e evidencia quando a decisão foi efetivamente incorporada ao projeto.
Quando a matriz RACI não é suficiente
RACI ajuda a organizar responsabilidades, mas não define sozinho autoridade decisória. Uma pessoa pode ser accountable por um processo e ainda não possuir alçada para aceitar um desvio técnico ou alterar um requisito. Por isso, projetos complexos precisam complementar RACI com decision rights, limites de materialidade e regras de escalonamento.
A diferença é prática: responsabilidade descreve quem responde por uma atividade ou resultado; autoridade define quem pode comprometer a organização com uma decisão. Misturar esses conceitos cria situações em que todos participam e ninguém efetivamente decide.
Como usar gates condicionais sem mascarar imaturidade
Nem todo gate precisa resultar apenas em aprovação ou reprovação. Em alguns casos, é legítimo avançar com condicionantes. O risco surge quando a aprovação condicional vira mecanismo rotineiro para empurrar pendências críticas para a etapa seguinte.
Uma condicionante deve possuir owner, prazo, evidência de fechamento e limite claro sobre quais atividades podem avançar enquanto ela permanece aberta. Se a pendência afeta segurança, requisito essencial ou irreversibilidade da próxima etapa, o avanço pode não ser justificável.
O histórico de gates condicionais também é um indicador útil. Se a organização acumula condicionantes sem fechamento, a governança está aceitando incerteza em vez de resolvê-la.
Considerações finais
Falhas de governança em projetos de Engenharia aparecem quando decisões deixam de ser explícitas, proporcionais e rastreáveis.
Os sintomas mais visíveis são atraso, retrabalho e conflito, mas a causa pode estar em alçadas, fóruns, gates, mudanças, requisitos, riscos, interfaces ou autoridade técnica.
Identificar corretamente essas falhas exige observar decisões reais e reconstruir como foram tomadas.
A pergunta final é simples e exigente: para cada decisão crítica do projeto, é possível demonstrar quem tinha autoridade, quais critérios foram usados, qual evidência sustentou a escolha e como o resultado foi incorporado à baseline?
Quando a resposta é não, existe um gap de governança a ser tratado.
Por Eng. Altair Andrade Galvão — Diretor de Engenharia e Projetos, A3A Engenharia.
Falhas recorrentes de governança raramente são resolvidas com um único comitê. É necessário alinhar decision rights, alçadas, gates, mudanças, riscos e autoridade técnica em uma arquitetura coerente.
Referências técnicas
[1] ISO. ISO 21505:2017 — Project, programme and portfolio management — Guidance on governance. 2017. Disponível em: https://www.iso.org/standard/63578.html.
[2] ISO. ISO 21500:2021 — Project, programme and portfolio management — Context and concepts. 2021. Disponível em: https://www.iso.org/standard/75704.html.
Perguntas frequentes
Decisões sem owner, escalonamento excessivo, comitês sem mandato, gates sem critérios, mudanças fora de baseline, riscos sem responsável e decisões reabertas são sinais recorrentes.
Não. Gerenciamento coordena a execução; governança define direção, supervisão, responsabilidades, alçadas e mecanismos de decisão.
Quando decisões simples sobem demais, decisões críticas permanecem locais ou stakeholders não sabem quando escalar, a arquitetura de alçadas provavelmente precisa ser revista.
Não em todos os contextos. Ela é útil quando decisões técnicas críticas exigem competência, independência e autoridade explicitamente definidas.
Sim. Aprovações redundantes, comitês duplicados e controles sem efeito sobre risco ou decisão aumentam burocracia e lead time.
