Riscos do projeto e riscos corporativos: como conectar

A área de riscos da empresa apresenta ao conselho um mapa com quinze riscos corporativos. Na mesma semana, a equipe de implantação do novo sistema de gestão discute, no seu registro, o risco de a migração de dados atrasar o fechamento contábil de janeiro. Os dois documentos falam de assuntos ligados, usam escalas diferentes e não se citam. A gestão de riscos corporativos e a gestão de riscos do projeto existem na mesma organização, mas muitas vezes correm em trilhos paralelos.

O custo dessa separação aparece de dois jeitos. Riscos do projeto que ameaçam a empresa inteira ficam presos no registro da equipe, sem chegar a quem pode decidir. E riscos corporativos que deveriam orientar o projeto (dependência de um fornecedor, exigência regulatória, limite de endividamento) nunca chegam ao gerente de projetos.

A seguir estão a diferença entre os dois níveis, os critérios para levar um risco de um para o outro e uma forma prática de traduzir a régua corporativa para o registro do projeto. O ciclo de gestão de riscos dentro do projeto está no guia de gestão de riscos em projetos.

O que é gestão de riscos corporativos

Gestão de riscos corporativos, também chamada de ERM (do inglês Enterprise Risk Management), é a gestão dos riscos que afetam os objetivos permanentes da organização: estratégia, resultado financeiro, conformidade, reputação, segurança das pessoas e continuidade do negócio. Ela não olha uma entrega; olha o que pode impedir a empresa de cumprir o que prometeu a acionistas, clientes, reguladores e sociedade.

Três referências aparecem com frequência:

• ISO 31000:2018: norma de diretrizes com princípios, estrutura e processo de gestão de riscos para qualquer organização. A parte de estrutura trata justamente de integrar a gestão de riscos à governança e às atividades, incluindo projetos. A aplicação ao projeto está no artigo sobre a ISO 31000 aplicada à gestão de riscos em projetos.
• COSO ERM: a estrutura do Committee of Sponsoring Organizations of the Treadway Commission (COSO), na versão de 2017, liga a gestão de riscos à estratégia e ao desempenho, organizada em cinco componentes e vinte princípios.
• Modelo das Três Linhas: publicado pelo Institute of Internal Auditors (IIA) em 2020, separa papéis. A primeira linha é a gestão que entrega produtos e serviços e gerencia os riscos do seu trabalho, e os projetos estão aqui. A segunda linha apoia e questiona com especialidade em riscos, controles e conformidade. A terceira é a auditoria interna, que avalia de forma independente.

Na prática brasileira, a gestão de riscos corporativos costuma ficar com uma área de riscos, controles internos ou compliance, ligada a um comitê ou ao conselho. Em empresas menores, ela pode ser só uma matriz anual feita pela diretoria.

Risco do projeto x risco corporativo: o que muda

O mesmo evento pode ter as duas leituras. Um atraso de 30 dias na implantação do sistema é, para o projeto, um risco de prazo com impacto 4. Para a empresa, só importa se ele levar a algo maior, como perder a data de uma obrigação fiscal, que entra num risco corporativo de conformidade.

Onde os dois níveis se encontram

A ligação corre em três sentidos.

De cima para baixo. A organização define apetite, critérios e categorias de risco, e o projeto herda essas regras. Riscos corporativos já conhecidos (fornecedor único de tecnologia, falta de pessoas qualificadas, mudança regulatória no setor) devem aparecer no registro dos projetos que podem ser afetados por eles. A forma de transformar o apetite da empresa em limites concretos está no artigo sobre apetite e tolerância a riscos.

De baixo para cima. Riscos identificados no projeto sobem quando o efeito ou a decisão passa da alçada do projeto. No vocabulário do PMBOK, guia do Project Management Institute (PMI), é a estratégia de escalar, que vale tanto para ameaças quanto para oportunidades.

Para depois do projeto. O projeto cria riscos que vão viver na operação: um sistema novo traz risco de indisponibilidade, um produto lançado traz risco de recall, uma obra entregue traz risco de manutenção. Esses riscos devem ser passados à área que vai operar a entrega, e não encerrados junto com o projeto.

Quando um risco do projeto deve subir

Escalar não é pedir ajuda para qualquer risco alto. Use critérios escritos no plano de gerenciamento de riscos. Os mais comuns:

1. O efeito ultrapassa o projeto. O risco afeta outras áreas, outros projetos, clientes externos ou a reputação da empresa.
2. A resposta está fora da alçada. A decisão exige dinheiro acima da reserva de contingência, mudança de contrato, troca de fornecedor estratégico ou uma escolha que só a diretoria pode fazer.
3. O risco toca uma categoria de apetite muito baixo. Segurança das pessoas, conformidade legal, proteção de dados e continuidade costumam ter regra própria: qualquer risco relevante nessas categorias vai para a área de riscos ou de compliance, mesmo que a nota no projeto seja média.
4. O risco cruza um limite definido. Por exemplo, pontuação 20 ou mais na matriz, ou um impacto em reais acima de um valor aprovado pelo patrocinador.
5. O mesmo risco aparece em vários projetos. Três projetos apontando o mesmo fornecedor como fonte de atraso indicam um risco do portfólio, não de cada projeto.

Ao escalar, registre para quem o risco foi, quando e qual decisão foi pedida. Depois de aceito por quem tem a autoridade, o risco passa a ser gerido naquele nível; no projeto, ele pode continuar no registro como informação, com a situação "escalado", para que a equipe saiba que existe e acompanhe o efeito sobre o trabalho.

Como traduzir a régua corporativa para o projeto

O ponto mais difícil da conexão é a escala. A área de riscos mede impacto em resultado anual; o projeto mede em dias e reais do orçamento. Sem tradução, ninguém sabe se um risco 16 do projeto é grande para a empresa.

1. Peça os critérios corporativos. Escala de impacto, escala de probabilidade, categorias e o que cada nível exige.
2. Use as mesmas categorias. Se a empresa separa riscos estratégicos, operacionais, financeiros, de conformidade e de reputação, inclua essa classificação como coluna no registro do projeto, ao lado das categorias técnicas.
3. Monte uma tabela de equivalência de impacto. Ela mostra a partir de que ponto um impacto do projeto passa a ter peso para a empresa.
4. Defina o gatilho de escalonamento com base na tabela, e não no julgamento de cada gerente.

Exemplo ilustrativo de equivalência para uma empresa de médio porte:

A tabela não precisa ser perfeita. Precisa existir e ser aprovada, para que o gerente de projetos não decida sozinho o que é grave para a empresa.

O papel do PMO na ponte

O escritório de projetos (PMO) é quem costuma fazer a ligação no dia a dia. Ele consolida os riscos dos projetos, enxerga padrões que nenhum projeto vê sozinho e leva ao comitê o que é sistêmico. Na prática, o PMO:

• padroniza escala, faixas e categorias em todos os projetos, para que os riscos possam ser somados e comparados;
• reúne os riscos escalados e os repetidos numa visão de portfólio;
• acompanha poucos indicadores de risco do conjunto de projetos, como os descritos no artigo sobre KRI e indicadores de risco;
• devolve aos gerentes os riscos corporativos que afetam os projetos;
• garante que os riscos deixados para a operação tenham dono depois do encerramento.

Como desenhar e implantar esse processo no escritório de projetos está detalhado em processo de gestão de riscos no PMO.

Exemplo ilustrativo: um risco que sobe

Numa implantação de sistema de gestão, a equipe registra: "Porque os dados de clientes serão migrados por um fornecedor externo sem cláusula específica de proteção de dados, pode haver tratamento indevido de dados pessoais, o que exporia a empresa a sanções da Lei Geral de Proteção de Dados (LGPD) e a dano de imagem."

No projeto, a nota fica em probabilidade 2 e impacto 5, pontuação 10 (alto). A resposta técnica (mitigar com anonimização dos dados de teste e acesso restrito) cabe na equipe. Mas o efeito, sanção e reputação, é corporativo, e a correção do contrato exige o jurídico. Pelo critério 3, o risco é escalado à área de compliance, que inclui a cláusula no contrato e associa o caso ao risco corporativo de proteção de dados. No registro do projeto, a ação de mitigação continua com dono e prazo, e o risco ganha a anotação de que a parte contratual foi escalada.

Erros comuns na conexão entre os dois níveis

• Escalar tudo. O comitê recebe dezenas de riscos e passa a ignorar todos.
• Não escalar nada. O gerente tenta resolver sozinho o que exige decisão da diretoria e o risco vira problema.
• Escalas que não conversam. Impacto 5 no projeto e "alto" no mapa corporativo sem nenhuma equivalência escrita.
• Encerrar os riscos junto com o projeto. Os riscos que passam para a operação ficam sem dono.
• Tratar a área de riscos como plateia. Ela é segunda linha: apoia, questiona e define critérios, mas a gestão do risco do projeto continua com quem faz o projeto.

Comece pela ligação mais simples

Peça à área de riscos ou à diretoria a matriz corporativa atual, marque quais riscos dela tocam o seu projeto e acrescente ao seu registro uma coluna com a categoria corporativa. Depois escreva, no plano de gerenciamento de riscos, os critérios para escalar e a tabela de equivalência de impacto. Se a sua organização tem vários projetos e ninguém consolida os riscos, o problema provavelmente está na estrutura de governança. O diagnóstico de PMO gratuito da Projeto Diário avalia, em seis dimensões, se as alçadas de decisão são conhecidas, se os projetos usam os mesmos indicadores de prazo, custo e riscos e se a diretoria recebe uma visão consolidada, e indica a primeira ação para cada ponto fraco.