Técnicas de Gestão de Riscos no Planeamento de Projetos

Técnicas de Gestão de Riscos no Planeamento de Projetos

Um registo de riscos com âmbito deficiente descoberto na fase de engenharia detalhada não protege o projeto — documenta o dano. A consequência é tangível: , e .

A gestão de riscos eficaz não é um exercício de conformidade. É uma disciplina de engenharia estruturada que, quando aplicada corretamente, desloca as decisões do combate reativo a incêndios para o controlo proativo.

Contexto de Normas e Requisitos

Vários quadros regulam a prática de gestão de riscos em ambientes de projetos de óleo e gás:

• ISO 31000 estabelece os princípios gerais e diretrizes para a gestão de riscos aplicáveis a qualquer organização ou projeto.
• IEC 62198 fornece diretrizes de aplicação para a gestão de riscos de projetos em vários setores, incluindo indústrias de processo.
• IEC 61511 rege a segurança funcional para sistemas instrumentados de segurança e exige a análise de perigos e riscos como base para a determinação do nível de integridade de segurança — uma entrada direta para os registos de riscos do projeto.
• API RP 17N abrange a fiabilidade, o risco técnico e a gestão da integridade para sistemas de produção submarinos e fornece um quadro estruturado para a tomada de decisões informada pelo risco durante o desenvolvimento do projeto.
• ISO/IEC 31010 fornece um catálogo de técnicas de avaliação de riscos e orientações sobre a seleção do método apropriado para uma determinada situação.

Sempre que um projeto caia sob jurisdição regulatória — UKCS, GoM, plataforma continental norueguesa — a autoridade competente aplicável exigirá tipicamente um safety case formal ou documento equivalente que se baseie diretamente nas avaliações de risco do projeto.

O Processo de Gestão de Riscos nas Fases do Projeto

Alinhar o Processo ao Ciclo de Vida do Projeto

A gestão de riscos deve ser faseada. A aplicação de um único registo de riscos desde o conceito até ao comissionamento sem pontos de revisão estruturados é um modo de falha comum. Cada fase do projeto — seleção de conceito, pré-FEED, FEED, design detalhado, aprovisionamento, construção, pré-comissionamento — tem um perfil de risco diferente, um nível diferente de certeza de design e um custo diferente para agir sobre os riscos identificados.

Na seleção de conceito, os riscos são amplos e estratégicos: incerteza do reservatório, prontidão tecnológica, percurso regulatório, alinhamento de parceiros. No FEED, os riscos tornam-se técnicos e comerciais: aquisição de equipamentos de longo prazo, gestão de interfaces, condições do terreno, qualificação de fornecedores. Na construção, os riscos são em grande parte relacionados com a execução: competência da mão de obra, janelas meteorológicas, disponibilidade de materiais, operações simultâneas.

Métodos de Identificação de Riscos

A escolha da técnica de identificação deve corresponder à fase do projeto e à natureza do perigo:

O HAZOP é frequentemente mal aplicado — executado demasiado cedo quando os P&IDs são imaturos, ou demasiado tarde quando as alterações são proibitivamente caras. O gatilho correto é um conjunto de P&ID congelado e com qualidade IFC.

Avaliação de Riscos: Qualitativa vs. Quantitativa

Para a maioria dos riscos de projeto, uma avaliação qualitativa bem estruturada utilizando uma matriz de consequência-probabilidade é suficiente e proporcionada. A matriz deve ser calibrada para o projeto: as categorias de consequência devem incluir dimensões de segurança, ambientais, de cronograma, de custo e reputacionais, cada uma com descritores definidos em vez de pontuações numéricas arbitrárias.

A avaliação quantitativa de riscos (QRA) é justificada quando:

• O projeto envolve configurações de processo novas ou complexas onde a gravidade da consequência não pode ser limitada qualitativamente.
• Os requisitos regulatórios o especificam — como é comum para instalações offshore, instalações de GNL ou locais onshore densamente povoados.
• Um risco está próximo do limite tolerável/intolerável e a decisão de prosseguir exige uma base numérica defensável.

O resultado de um QRA é tão fiável quanto os dados e pressupostos que o alimentam.

Estratégias de Resposta ao Risco

Quatro estratégias de resposta aplicam-se a qualquer risco identificado. A escolha depende do nível de risco, do custo da resposta e do apetite ao risco do projeto:

Evitar — reestruturar o âmbito ou a abordagem do projeto para eliminar totalmente o risco. Aplicável quando o risco é inaceitavelmente elevado e não existe mitigação credível dentro das restrições de custo. Exemplo: selecionar uma tecnologia comprovada em vez de uma nova quando o cronograma não pode absorver testes de qualificação.

Mitigar — reduzir a probabilidade ou consequência através de controlos de engenharia, salvaguardas procedimentais ou alterações de design. Esta é a resposta mais comum e deve ser orçamentada e atribuída a um proprietário específico.

Transferir — transferir a consequência financeira do risco para um terceiro através de termos contratuais, seguros ou garantias de desempenho. A transferência não elimina o risco; reafeta a exposição financeira. O risco técnico permanece com a equipa do projeto.

Aceitar — reconhecer o risco e prosseguir sem mitigação ativa, tipicamente porque o custo da mitigação excede o impacto esperado. Os riscos aceites devem ser explicitamente documentados e revistos em cada fase. A aceitação passiva — onde um risco simplesmente não é abordado — é uma falha de governação do projeto.

Risco de Cronograma e Gestão de Margem

O risco de cronograma é frequentemente subestimado porque as equipas de projeto confundem um caminho crítico determinístico com uma previsão fiável. Um modelo de caminho crítico com margem zero em cada atividade principal não é um cronograma — é uma aspiração otimista.

A simulação de Monte Carlo aplicada ao cronograma do projeto gera uma distribuição de probabilidade das datas de conclusão com base no intervalo de durações atribuídas às atividades individuais. O resultado — uma curva de probabilidade acumulada — permite à equipa do projeto selecionar uma data de conclusão alvo num nível de confiança apropriado, em vez de se comprometer com o cenário mais otimista.

As entradas principais para um modelo de risco de cronograma credível incluem:

• Estimativas de duração realistas de três pontos (mínima, mais provável, máxima) para cada atividade, desenvolvidas pelos líderes de disciplina que detêm o trabalho.
• Modelação explícita de eventos de risco — riscos discretos que, se ocorrerem, adicionam duração ou criam ciclos de retrabalho.
• Correlação entre atividades relacionadas — atrasos na entrega de equipamentos, por exemplo, afetam simultaneamente múltiplas atividades de instalação downstream.

Cenário Ilustrativo: Registo de Riscos de FEED de Tieback Submarino

O que se segue é um exemplo ilustrativo construído para demonstrar a aplicação das técnicas descritas. Não representa um projeto ou incidente específico nomeado.

Considere um projeto de tieback submarino em FEED. O registo de riscos identifica um item de longo prazo — um módulo de controlo submarino de um único fornecedor qualificado — como um risco de aprovisionamento crítico para o cronograma. A avaliação qualitativa inicial coloca este risco na célula de elevada consequência e probabilidade moderada da matriz do projeto.

A equipa do projeto aplica uma análise bow-tie: a ameaça é o atraso no fabrico do fornecedor; as barreiras incluem a colocação antecipada da ordem de compra, pagamentos contratuais por marcos e um programa de inspeção do fornecedor. A consequência, se as barreiras falharem, é um atraso na data do primeiro óleo.

A estratégia de resposta selecionada é a mitigação combinada com transferência parcial: a ordem de compra é colocada na conclusão do FEED com indemnizações contratuais por atraso na entrega, e o modelo de cronograma é atualizado para incluir um evento de risco discreto representando um cenário de atraso do fornecedor. O resultado de Monte Carlo confirma que a data de conclusão do projeto ao nível de confiança exigido requer uma contingência de cronograma adicional além do caminho crítico determinístico.

Esta contingência é financiada explicitamente na estimativa de custo de sanção do projeto — não absorvida numa linha de contingência geral que mascara o impulsionador específico.

Checklist de Gestão de Riscos do Projeto

Use o seguinte em cada revisão de etapa (gate review) do projeto:

Qualidade do Registro de Riscos

• [ ] Todos os riscos possuem um responsável definido, não uma equipe ou disciplina
• [ ] As classificações de consequência e probabilidade utilizam a matriz calibrada específica do projeto, não padrões genéricos
• [ ] Riscos aceitos são explicitamente documentados com justificativa
• [ ] O registro foi atualizado desde a etapa anterior

Abrangência da Identificação

• [ ] O HAZID ou equivalente foi concluído e as descobertas estão refletidas no registro
• [ ] Equipamentos de longo prazo de entrega e itens de fornecedor único são capturados como riscos de cronograma
• [ ] Riscos de interface (entre contratadas, entre projeto e operações) estão explicitamente listados
• [ ] Riscos do caminho de aprovação regulatória estão incluídos

Risco de Cronograma

• [ ] Estimativas de três pontos foram preparadas para atividades do caminho crítico
• [ ] Uma simulação de Monte Carlo foi executada e a data de conclusão meta é declarada em um nível de confiança definido
• [ ] A folga (float) não é utilizada como o principal buffer de risco

Ações de Resposta

• [ ] Cada risco de alta classificação possui uma ação de mitigação documentada com uma data de conclusão
• [ ] Os custos de mitigação estão incluídos na estimativa de custos do projeto
• [ ] Mecanismos de transferência (contratos, seguros) são confirmados, não presumidos

Governança

• [ ] O registro de riscos foi revisado pelo patrocinador do projeto
• [ ] Riscos que se aproximam do limite tolerável/intolerável foram escalados para revisão independente

Conclusão

A gestão de riscos no planejamento do projeto só é eficaz quando é contínua, apropriada para a fase e de propriedade da equipe de engenharia, em vez de delegada a uma função de controle de projeto. As ferramentas — HAZID, HAZOP, bow-tie, Monte Carlo — estão bem estabelecidas. Os modos de falha estão igualmente bem estabelecidos: identificação tardia, matrizes genéricas, riscos sem dono e registros que são atualizados para revisões de etapa e depois arquivados.

O próximo passo imediato para qualquer equipe de projeto que esteja revisando sua abordagem atual é auditar o registro de riscos em relação ao checklist acima e fazer uma pergunta direta para cada risco de alta classificação: quem é o dono disso, qual é a ação de mitigação e essa ação está financiada e programada? Se a resposta a qualquer parte for incerta, o risco não está sendo gerenciado — está apenas registrado.