A DSM representa e permite visualização das relações e dependências entre objetos. Como já apresentado, a DSM foi introduzida por Steward (1981), inicialmente, utilizada para tarefas com foco de planejamento, e também tem sido amplamente utilizado com componentes de produtos, projetos e pessoas. A decisão de utilizar a DSM para um novo objeto, o risco no gerenciamento de projetos foi definido por Ludovic após exaustivas revisões bibliográficas de Danilovic, Browning, Eppinger e Sosa. Ludovic definiu interação de risco como sendo a existência de uma possível relação de precedência entre dois riscos.
Devido à complexidade cada vez mais crescente as quais os projetos devem superar, identificar riscos de projetos nunca foi um tema tão atual, e estes estão aumentando em número e criticidade. Decompor a lista de riscos de projetos em agrupamentos menores torna-os mais fáceis de serem gerenciados. Todavia, atualmente, as técnicas existentes são, em sua maioria, mono criteriosas em relação aos parâmetros de risco, tais como natureza ou nível de criticidade. Esses limites ocorrem devido as interações entre os riscos do projeto não serem devidamente consideradas pois os riscos interdependentes do projeto são geridos como se fossem independentes. Como referência para análise do processo de gerenciamento de projetos, no presente trabalho é considerada a estrutura proposta pelo PMI, publicada através do PMBOK. O guia PMBOK descreve apenas os processos de gerenciamento de projetos, identificando sua natureza em termos de integração entre processos, suas interações e seus objetivos. Os processos de gerenciamento de projetos descritos pelo PMBOK são agrupados em 5 categorias: iniciação, planejamento, execução, monitoramento e controle, e por final encerramento. As áreas de conhecimento por sua vez são: integração, escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos, aquisições e partes interessadas.
Os grupos de processos são ligados e interagem entre si durante toda a execução do projeto, estes grupos podem ter aspectos de todas as 10 áreas de conhecimento. Os grupos de processos relacionam-se com as áreas de conhecimento e formam o universo
do gerenciamento de projetos. Os 5 grupos de processos identificados pela estrutura de gerenciamento de projetos proposta pelo PMBOK são:
• Iniciação: fase inicial em que se define e autoriza formalmente o início de projeto ou fase. Na iniciação ocorre o estabelecimento da visão do projeto, alinhando os interesses das partes interessadas com o objetivo. Nesta etapa o termo de abertura do projeto é desenvolvido, direcionando a aplicação dos recursos do projeto, e as partes interessadas são identificadas;
• Planejamento: fase de definição e refinamento dos objetivos e planejamento das atividades necessárias para atingir os objetivos e obedecer ao escopo para qual o projeto se propõe. O planejamento desenvolve todo o plano de gerenciamento e os documentos que serão utilizados na execução de um projeto, explorando os aspectos de escopo, tempo, custo, qualidade, comunicações, recursos humanos, riscos, aquisições e gerenciamento das partes interessadas. O plano de gerenciamento do projeto desenvolvido possui sub-planos auxiliares direcionados a todas as áreas de conhecimento, o que torna o planejamento do projeto integrado.
• Execução: consiste dos processos executados para concluir o trabalho determinado pelo plano de projeto. Este grupo de processo integra pessoas e outros recursos para realização do planejamento, assim como gerencia as expectativas das partes interessadas. Nesta etapa os entregáveis são controlados e as informações sobre estes resultados irão compor relatórios de desempenho do projeto.
• Monitoramento e Controle: grupo de processo que monitora e controla todo o esforço do projeto através da medição do desempenho em comparação com as especificações do plano de gerenciamento. Identifica também possíveis necessidades de ações corretivas no plano de gerenciamento e inicia as respectivas mudanças. O aspecto positivo deste grupo de processo é o monitoramento contínuo que fornece à equipe a visão sobre a saúde do projeto e identifica prioridades.
• Encerramento: etapa em que ocorrem a formalização da aceitação do resultado do projeto, conclusão formal de todas as atividades e registro de lições aprendidas ao longo do projeto.
As áreas de conhecimento representam um conjunto completo de conceitos, termos e atividades que compõe um campo profissional, campo de gerenciamento de projetos, ou área de especialização. O guia PMBOK define 10 áreas de conhecimento, contudo, para esse trabalho, somente o Gerenciamento de Riscos será detalhado. Ele consiste nos "processos referentes a identificação, análise e respostas aos riscos, estes processos minimizam as influências dos riscos nos objetivos do projeto aumentando a probabilidade de resultados positivos. A equipe de projeto deve estar preparada para trabalhar tanto com os riscos conhecidos como os desconhecidos evitando assim problemas no andamento do projeto”.
Conforme detalhado nas fases de projeto, quando projetos em termos de sistemas de acompanhamento com várias fases são abordados, muitas dependências e interdependências entre as fases, subsistemas e outras entidades podem ser identificadas. Isso pode levar a problemas de comunicação e coordenação perante situações de tomada de decisão. Ou seja, a complexidade do projeto, descrita em (Baccarini, 1996; Edmonds, 1999; Laurikkala et al, 2001) envolve questões em tomadas de decisão para situações complexas (Phelan, 1995; Earl et al, 2001; Vidal et al, 2010). Assim como a incerteza e instabilidade inerente aos projetos, a complexidade também se apresenta como um dos principais fatores de risco. Além de que, a complexidade reduz a visão geral de todos os eventos de um projeto para os tomadores de decisão reduzindo, assim, a eficiência de suas decisões.
O processo de gerenciamento de riscos é classicamente dividido em quatro etapas principais como mostrado na Figura 23: identificação, análise, planejamento de respostas, monitoramento e controle (PMI, 2013)
Figura 23. Processo gerenciamento de projeto de risco tradicional. (PMBOK 2016)
De acordo com Raz & Hillson, as origens da gestão de risco operacional podem ser atribuídas à disciplina da engenharia de segurança. Muitas metodologias de gerenciamento de risco e ferramentas associadas foram desenvolvidas, com abordagens qualitativas e/ou quantitativas, muitas vezes baseadas nos dois conceitos de probabilidade e impacto. As metodologias atuais estão focadas apenas em alguns aspectos da complexidade da rede de risco, como por exemplo, a identificação de conexão simples entre causa e efeito. Porém, alguns fenômenos ainda não são levados em consideração pelas metodologias existentes de gerenciamento de risco, como loops, reações em cadeia ou acoplamentos não-lineares. Por esse motivo, visando estabelecer
uma melhor integração dos fenômenos complexos que as metodologias de risco precisam ser desenvolvidas.
Identificação de riscos é o processo de determinar quais eventos, eles podem ocorrer, poderiam afetar positiva ou negativamente os objetivos do projeto. Métodos de identificação de risco são classificados de acordo com duas famílias diferentes: a identificação de riscos diretos ou indiretos (Raz e Hillson, 2005). O número de riscos da lista gerada pode variar de algumas dezenas a algumas centenas. Em seguida, são decompostos em subgrupos, tornando-os mais gerenciáveis. Esta lista é incluída na metodologia ou classificados de acordo com a natureza dos riscos.
Durante a análise de risco, os riscos são priorizados, essencialmente de acordo com a sua probabilidade e impacto. Escalas de avaliação de risco são frequentemente definidos em termos de criticidade, que é geralmente uma função de probabilidade e impacto. O principal resultado da análise de risco é uma lista ou gráfico, o que permite que os tomadores de decisão para categorizar os riscos como alto, médio ou baixo em termos do indicador escolhido.
Os próximos passos são o planejamento de resposta a riscos e monitoramento. Estas etapas devem ser executadas após uma análise de risco do projeto inovador com base em interações de risco, uma vez que os métodos atuais têm mostrado os seus limites.
O objetivo inicial dos processos de agrupamento risco é o de facilitar a gestão dos riscos em termos de tomada de decisão. No caso de agrupamento, o objetivo principal é facilitar a identificação dos proprietários dos riscos, sejam individuais ou entidades (devido a suas habilidades e competências), e, em seguida, para facilitar a alocação de recursos adicionais ou de contingência.
No caso de aglomeração por valor, o principal objetivo é priorizar riscos, a fim de tomar decisões sobre o futuro plano de mitigação e como afetam os recursos resultantes. Como eles estão classificando riscos com base em uma de suas características, esses métodos não incluem suas possíveis interações. Portanto, em ambos os casos, há muitas interações entre agrupamentos. Isso pode resultar em uma falta de coordenação entre os intervenientes na tomada de decisões, devido à falta de consciência do impacto global da decisão de um, principalmente fora do agrupamento considerado.
No caso da gestão de risco, a maioria dos métodos usam listas, triagem ou classificação de riscos, como visto anteriormente. O tópico que deixa a desejar relacionado as metodologias atuais é que as interações de risco do projeto não estão incluídas de forma clara.
Um estudo anterior que havia realizado cerca de 23 metodologias de análise de risco permitiu a identificação questões relacionadas com a complexidade (Marle, 2008). Por exemplo, pode haver propagação de um risco “a montante” para inúmeros riscos “a jusante”, o clímax desse fenômeno sendo as famosas perigos do efeito dominó. No entanto, alguns trabalhos têm sido feitos para modelar interdependências mais complexas entre riscos como redes de Bayesian, por exemplo, que ligam vários riscos, de múltiplas entradas para várias saídas, mas eles têm condições de validade específicas: as ligações devem ser orientadas e eles estão mais adaptados às redes acíclicas. No entanto, laços são um grande perigo durante os projetos e são ainda mais complicados de entender, uma vez que os riscos que existem dentro de um loop são susceptíveis a serem heterogêneos (diferentes naturezas). É possível resolver esta questão usando redes dinâmicas de Bayesian, mas o esforço necessário para reunir as probabilidades condicionais e executar redes dinâmicas para o grande número de possíveis malhas torna impróprios para ambientes de projeto reais. Há, portanto, necessidade crucial de elaboração de agrupamentos menores para melhor consciência, consideração e gestão de riscos do projeto, sabendo que eles estão interligados. Nesta fase, surge uma questão de gestão, já que as decisões podem ser bloqueadas, retardadas ou ineficazes; caso as interações sejam pouco levadas em conta. Faz-se necessária, portanto, uma nova metodologia de agregação que considerasse as interações entre os riscos, em termos de existência e força. Em primeiro lugar, precisaria identificar as possíveis interações de risco, e o conjunto seria sintetizado por meio da representação binária matriz. A matriz, posteriormente, precisaria então ser transformada para numérica utilizando os princípios da AHP (Analytic Hierarchy Process, do inglês Processo de hierarquia analítica) (Saaty,1980).
A RSM surge como uma proposta de Ludovic (2008) de que as interações entre riscos de projetos fossem estudadas através de uma ferramenta eficaz de inter- relacionamento: a DSM. Essa metodologia reduz as interfaces ao lidar-se com riscos,
fazendo com que a taxa de interação seja máxima dentro do agrupamento e mínima fora, facilitando a coordenação de projetos complexos. A Ilustração de uma RSM e a Rede de risco de projeto são mostrados na Figura 24.
Figura 24. Ilustração de uma (a) RSM e (b) Rede de risco de projeto. (Fang 2012)
Considerando uma avaliação de processo, o cronograma do projeto pode fornecer informações sobre as relações entre a sequência de atividades que possibilita a ligação entre dois riscos e permite a identificação de atraso entre eles. Para uma relação entre 2 componentes, seja funcional, estrutural ou física, os riscos que podem estar relacionados às funções, qualidade, atraso ou custo do produto podem ser vinculados, uma vez que, um problema sobre um componente pode influenciar outro. De maneira semelhante, a
Domain Mapping Matrix - DMM (do inglês, Matriz de mapeamento de domínio. É a matriz
não quadrada que mapeia o domínio de uma DSM em relação ao domínio de outra DSM) e a Multiple Domain Matrix - MDM (do inglês, Múltipla Matriz de Domínio. Representam mais de um tipo de DSM em uma única matriz) são úteis na identificação de interações de risco em diferentes domínios do projeto.
Existem muitos riscos de naturezas diferentes, tornando sua identificação uma tarefa exaustiva. Assim, realizar o agrupamento de um grupo em grupos menores faz-se necessário e, portanto, mais fácil de gerenciar. Esses riscos estão interconectados, o que significa que não são eventos independentes, e essa dependência causa alguns
problemas na tomada de decisões do gerenciamento de riscos no qual são necessárias tomadas de decisão sobre priorização de risco e ações de mitigação de risco.
Matriz de Estruturas de Risco é uma matriz binária e quadrada na qual RSMij = 1 quando há um link de causalidade potencial de Rj para Ri, conforme descrito em Marle & Vidal (2008). A RSM é uma DSM com riscos de projeto como elementos do sistema. A RSM permite obter informações exaustivas e consistentes sobre as interações entre os riscos, pois as interações entre Ri e Rj ficam em destaque. Se Ri demonstra Rj como uma causa, mas Rj não declarou Ri como uma consequência, então há uma incompatibilidade e cada item encontrado de desencontro é estudado e resolvido, como trabalhos análogos de Sosa (2004) sobre interações entre atores. A RSM também pode ser considerada como uma MDM porque os riscos residem e podem interagir em diferentes domínios do projeto, conforme explorado por Biedermann & Lindemann (2008).
Fang (2012), Marle (2013) e Ludovic (2010) afirmam que as inter-relações entre objetos do projeto, como atividades, atores e componentes do produto, podem facilitar a identificação de inter-relações entre os riscos relacionados a esses objetos. O objetivo da Matriz de Estrutura de Risco (RSM) é agrupar os riscos em agrupamentos, a fim de alcançar um maior número de interações dentro do projeto, facilitando a coordenação dos assuntos envolvidos no processo de gerenciamento de riscos do projeto. A Figura 25 mostra o impacto nas variáveis sofridos de acordo com o tempo de vida do projeto. No início, o risco é alto e o custo gasto para resolvê-los é baixo. Conforme o projeto avança, a situação se inverte. A Figura 26 mostra exatamante esse comportamento dos riscos de acordo com as etapas de desenvolvimento do produto
Figura 25. Impacto nas variáveis sofridos de acordo com o tempo de vida do projeto (PMI 2016)
Figura 26. Diminuição dos riscos de acordo com as etapas de desenvolvimento do produto (Browning 2002 adaptado)
A matriz binária RSM pode ser transformada em uma numérica para melhorar a avaliação entre força das interdependências chamada de Risk Numerical Matrix (RNM do inglês, Matriz Numérica de Risco). Da mesma forma que Chen e Lin (2003), Ludovic (2010) propôs uma abordagem contemplando cinco etapas para capturar a força das interações dos riscos, o que permite que a matriz numérica seja construída.
• Etapa 1: Decompor o problema em dois subproblemas; • Etapa 2: Comparar a força das interações;
• Etapa 3: Extrair os auto vetores;
• Etapa 4: Agregar os resultados matrizes de causa / efeito; • Etapa 5: Compilar os resultados na matriz numérica final.
Apesar da relevância da RNM para ponderar as relações entre os riscos, essa abordagem numérica da RSM não será utilizada no desenvolvimento desse projeto por já estar presente na ferramenta FMEA.