Gestão de riscos em projetos

Prévia do material em texto

Unidade 1 Página inicial 
PLANEJAMENTO E 
IDENTIFICAÇÃO DE 
RISCOS 
Professor (a) : 
Me. Paulo Sampaio 
Objetivos de aprendizagem 
• Levar ao conhecimento do(a) aluno(a) o que é e qual a importância da gestão de riscos em projetos. 
• Abordar os conceitos e os métodos a serem utilizados na estratégia de gerenciamento de riscos. 
• Identificar as possíveis categorias de riscos observando-se a natureza do projeto. 
• Compreender a importância do formato causa-risco-efeito na apresentação do risco do projeto. 
• Identificar as pessoas que possam contribuir no processo de identificação de riscos. 
• Conhecer as principais técnicas e ferramentas de identificação de riscos. 
• Abordar as boas práticas de gestão de riscos em projetos. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial
Plano de estudo 
A seguir, apresentam-se os tópicos que você estudará nesta unidade: 
• Plano de gerenciamento de riscos 
• Categorias de riscos 
• Formas de identificação de riscos 
• Técnicas de identificação de riscos 
Introdução 
Caro(a) aluno(a), nosso estudo baseia-se nos conceitos, ferramentas, técnicas e boas práticas de gestão de riscos em projetos, 
independentemente da sua natureza ou origem. Dizemos isso, porque não importa qual seja o projeto, se simples ou complexo, 
breve ou extenso, sempre haverá riscos associados que poderão representar alguma condição indesejada ou inesperada e que 
serão passíveis de gerenciamento para que seu projeto obtenha o sucesso desejado e apresente os resultados esperados. 
Primeiramente, abordaremos as estratégias necessárias e pertinentes à gestão de riscos, baseadas fundamentalmente no 
planejamento, para que seu projeto não seja baseado somente no empirismo, aumentando assim de forma significativa as chances 
de sucesso. Será a partir delas que teremos a habilidade de formular as diretrizes essenciais do planejamento e tratamento dos 
riscos, compreendendo os conceitos básicos e a importância por meio da análise de probabilidade e impacto de cada evento 
incerto. 
Aprenderemos a definir alguns padrões que serão utilizados ao longo do ciclo de vida do projeto, como as escalas de probabilidade 
e impacto que nos auxiliarão a analisar o risco de forma apropriada, além de conhecer a estrutura de uma matriz de riscos, 
possibilitando o mapeamento prévio dos principais eventos incertos que podem comprometer o sucesso do projeto, muitas vezes 
de forma até irreversível. 
Em seguida, aprenderemos a trabalhar com as categorias distintas de riscos. Podemos agrupar certos riscos em categorias, 
facilitando o trabalho de gestão e controle, pois dessa forma, obteremos uma forma bem organizada de manuseio e tratamento de 
eventos incertos que podem ser correlacionados entre si ou até mesmo similares a outros projetos correntes na companhia. Para 
tanto, vamos conhecer uma ferramenta (conceitual) de estruturação dos riscos chamada Estrutura Analítica dos Riscos, uma 
maneira relativamente simples, visual e eficaz de organizar os eventos com o intuito de mantermos o controle sobre os riscos, 
classificando-os dentro das categorias corretas. 
Prosseguindo com nossos estudos, aprenderemos a identificar quem poderá nos auxiliar no projeto com os processos de 
identificação de riscos, envolvendo-os e engajando-os no time de projeto. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial
https://getfireshot.com
Demonstraremos ainda a importância e relevância da apresentação dos riscos no formato causa-risco-efeito, que proporciona, 
dentre outros aspectos, levantarmos e tratarmos as causas-raiz dos problemas, proporcionando a diminuição ou até a eliminação 
das chances desse tipo de evento ocorrer de forma recorrente. 
Por fim, teremos contato com as principais técnicas de identificação de riscos, as mais utilizadas como prática de mercado nos 
projetos reais nas empresas. Apresentaremos as principais ferramentas homologadas e consagradas que, sem dúvida, auxiliam – e 
muito – no processo de identificação de riscos, após sua compreensão e uso na prática. Compreenderemos ainda a importância do 
registro de riscos como uma boa prática não só para o projeto que estaremos eventualmente gerenciando e também como forma 
de consulta prévia para projetos futuros, uma vez que muitos riscos se apresentam como comuns à maioria deles. 
Temos certeza de que sua curiosidade foi aguçada. Então, vamos iniciar nossa viagem. Seja bem-vindo(a) a bordo! 
Avançar 
DOWNLOAD PDF 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/unidade-1
https://drive.google.com/file/d/1OKQX_RDdpGGnN3BX8AeXkL_OZ1oaftpl/view?usp=sharing
Unidade 1 Página inicial 
PLANO DE GERENCIAMENTO DE 
RISCOS 
Olá! Seja bem-vindo (a) ao início dos nossos estudos sobre gestão de riscos em projetos. Espero que você aproveite ao máximo o 
conteúdo aqui abordado. 
Será nesta etapa da gestão de riscos como um todo que o profissional e especialista de projetos deverá determinar qual a 
abordagem mais adequada para o planejamento das atividades de gerenciamento dos riscos do projeto. Isso envolve tomada de 
decisões de como se deve proceder, se existem modelos prontos que possam ser utilizados, se há uma divisão (ou departamento) 
da companhia que trata das conformidades para riscos comuns à maioria dos projetos, quem deve ser inicialmente envolvido no 
planejamento, além de outras considerações não menos importantes. 
Conceitos importantes para o plano de gerenciamento de riscos 
É importante que iniciemos nossos estudos compreendendo os conceitos sobre riscos. O que vem a ser riscos? Segundo Mulcahy 
(2010), são incertezas inerentes a todo e qualquer tipo de projeto. Entretanto, essas incertezas podem se apresentar como 
eventos bons ou eventos ruins, que trataremos aqui como oportunidades e ameaças, respectivamente. Podemos tomar como 
exemplos de ameaças eventos que impactam negativamente como um incêndio em um projeto de construção civil, e de 
oportunidades eventos que impactam positivamente, como a obtenção de descontos inesperados na aquisição de materiais de 
construção. De qualquer forma, ambos são tratados como riscos. 
Muitas incertezas começam a ser mapeadas ainda na etapa de concepção e iniciação do projeto, quando não temos muita 
informação sobre ele. Nesse momento é muito comum que sejam estabelecidas algumas premissas alinhadas aos objetivos, as 
quais irão nos direcionar durante todo o ciclo de vida do projeto. Mas, então, o que são premissas? 
De acordo com o PMI (2013), premissa do projeto é “um fator do processo de planejamento considerado verdadeiro, real ou certo, 
desprovido de prova ou demonstração”. São como ‘verdades’ que assumimos para que o projeto aconteça (e que esteja mais 
próximo do sucesso). E por que as premissas seriam desprovidas de prova ou demonstração? Pelo simples fato de que as premissas 
podem se tornar instáveis (ou ‘inverdades’) ao longo do ciclo de vida, comprometendo os resultados parciais ou finais do projeto. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial
De acordo com Mulcahy (2010), uma das boas práticas de gestão de riscos é aplicar o teste de estabilidade das premissas . Opa! O 
que é isso? Vamos compreender juntos um pouco desse conceito. 
Como as premissas são as “verdades” que assumimos para que os projetos aconteçam (e sejam um sucesso), as quais são 
registradas nas documentações iniciais do projeto antes mesmo do mapeamento dos riscos preliminares, elas seriam fontes em 
potencial de riscos. Mas, por quê? Porque se assumirmosno início que algo deva ser verdadeiro até que o projeto seja finalizado, 
caso sua estabilidade esteja abalada, tal premissa se tornou falsa, comprometendo os resultados satisfatórios. Muitas vezes as 
premissas são também condicionais. 
Vamos exemplificar? Suponhamos que você tenha sido designado gerente de projetos para a construção de uma ponte sobre um 
rio de proporções medianas em uma cidade do interior. A ponte terá uma extensão de 600 metros sobre o rio, e uma das premissas 
é que haja um poste de iluminação pública a cada 50 metros de cada lado das pistas. Ora, se ao final (ou mesmo no decorrer) da 
construção da obra não houver um poste de iluminação pública conforme o especificado, o projeto falhou nesse quesito e se 
tornou uma ameaça de atendimento ao escopo (ou ainda de qualidade) previamente determinado. Portanto, toda e qualquer 
premissa já pode fazer parte da sua lista inicial de riscos. 
Segundo Dinsmore e Cooke-Davies (2006), a elaboração do Plano de Gerenciamento de Riscos é proporcional à dificuldade que os 
gerentes de projetos têm em demonstrar à maioria das partes interessadas ( stakeholders ), assim como aos patrocinadores do 
projeto ( sponsors ), o valor agregado que esses processos podem prover. 
É uma etapa que se for negligenciada pode gerar sérias consequências, como retrabalho e perda de qualidade na gestão de riscos 
do projeto, ocasionando muitas vezes o não cumprimento dos prazos e do orçamento previamente definidos. Muitos projetos, até 
os menos complexos e de curta duração, fracassam por não terem uma gestão de riscos adequada, na qual cada evento incerto se 
apresenta como uma surpresa que precisa ser solucionada de forma emergente. Dessa forma, perdemos ótimas oportunidades de 
aplicar as estratégias e técnicas mais apropriadas, além de não podermos garantir o controle necessário para que o projeto seja 
finalizado com sucesso (PMI, 2013). 
Precisamos conhecer melhor aqui a definição de stakeholders. As versões em português do PMBOK® os 
denominam como “partes interessadas” do projeto. Porém, o conceito vai um pouco, além disso. 
Independentemente da natureza (origem) do projeto, os stakeholders são aqueles afetados direta ou 
indiretamente e que podem também impactar de forma direta ou indireta os resultados do projeto. São 
classificados muitas vezes de acordo com seu nível de poder (autonomia e autoridade) e de interesse (nos 
resultados satisfatórios) do projeto. Além disso, se não forem gerenciados de maneira adequada podem se 
tornar uma potencial fonte de riscos para o projeto. Os stakeholders têm um papel fundamental na Gestão 
de Riscos. Muitos farão parte do ‘time de riscos’ do projeto e contribuirão não só na identificação como nas 
possíveis soluções propostas por eles mesmos. É muito comum que alguns stakeholders se apresentem 
muitas vezes como os especialistas nos assuntos referentes a determinados riscos do projeto. 
Fonte: PMI (2013). 
Os riscos são caracterizados como as incertezas (ou eventos incertos) existentes em todo e qualquer 
projeto e mudam no decorrer do ciclo de vida. Assim, faz-se necessário seu constante monitoramento. Os 
eventos incertos podem ou não ocorrer durante o desenvolvimento do projeto e podem ter consequências 
más ou boas que chamamos de ameaças e oportunidades, respectivamente. Portanto, é uma boa prática de 
gestão desenvolver o plano de gerenciamento de riscos, que servirá de referência durante todo o ciclo de 
vida e conterá os elementos fundamentais para que os riscos sejam identificados e recebam seus devidos 
tratamentos, aumentando as chances de sucesso do projeto. Nesse ínterim, entram os stakeholders e os 
papéis desempenhados por eles, que serão primordialmente necessários tanto na identificação dos riscos 
como na elaboração de propostas para que eles sejam devidamente tratados, mantendo assim o controle 
sobre as situações adversas inerentes a todo e qualquer projeto. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: PMI (2013). 
De acordo com Greene e Stellman (2010), a finalização do Plano de Gerenciamento de Riscos norteará todo o desenvolvimento do 
plano e tratamento dos riscos que podem (e irão) afetar o projeto. Tem ainda o intuito de auxiliar a identificar quem serão os 
responsáveis por fazer isso e com qual frequência os riscos serão identificados e tratados. 
Resultados do plano de gerenciamento de riscos 
O plano de gerenciamento de riscos proporciona itens úteis para a gestão deles no projeto. Vamos destacar alguns, a seguir, 
segundo Kerzner (2009): 
• Método : definição de quais serão as estratégias para identificação, análise e tratamento dos riscos, bem como se a gestão será 
conduzida por membros do projeto ou a parte por funcionários da empresa ou ainda por uma consultoria externa especializada em 
gestão de riscos. Contempla ainda o uso de padrões, políticas, processos e técnicas desenvolvidos e disponibilizados pelo 
departamento ou divisão de gestão de riscos da companhia, quando este existir. Outro aspecto não menos importante é a 
identificação da necessidade de treinamento de gerenciamento de riscos aos principais stakeholders envolvidos e comprometidos 
com o projeto. Essa iniciativa deve ser focada e acondicionada aos distintos grupos envolvidos e às necessidades peculiares de 
cada projeto (o direcionamento pode variar se for aplicado a membros da alta administração, que serão os tomadores de decisão, 
ou se for aplicado aos membros do time, que serão os executores). 
• Orçamento e periodicidade: necessidade de identificar quanto custará o gerenciamento dos riscos do projeto, assim como 
quando realizá-lo. Porém, vale lembrar que realizar a gestão de riscos pode proporcionar redução de custos efetivos do projeto, 
bem como otimizar os prazos, apenas reduzindo ou eliminado as ameaças e enaltecendo as oportunidades. Também é preciso que 
se repitam os processos de identificação, análise e tratamento de riscos ao longo do ciclo de vida do projeto, uma vez que os 
cenários se modificam durante o desenvolvimento dele. 
• Rastreabilidade: definição de como serão instauradas as auditorias nos processos de gestão dos riscos, quais serão as 
documentações necessárias e como deverão ser registradas as lições aprendidas durante todo o ciclo de vida do projeto. Para 
tanto, e como exemplo, devemos manter um repositório de registro de riscos que podem ser consultados tanto durante o 
desenvolvimento do projeto (como evidências sobre os procedimentos executados) como para consultas futuras a serem utilizados 
por outros projetos futuros. 
• Nível de tolerância das partes interessadas : é natural que as expectativas dos stakeholders não estejam necessariamente 
alinhadas em relação aos resultados esperados (parciais ou finais) do projeto. Da mesma maneira, a tolerância aos riscos tende a 
apresentar o mesmo comportamento, ou seja, pode haver aqueles que possuem baixa tolerância a riscos que envolvam o não 
cumprimento de prazos, já outros não admitem riscos relacionados ao não cumprimento do orçamento pré-estabelecido. Essas 
tolerâncias não devem ser inferidas, e sim identificadas já no início do planejamento, além de ser refinadas continuamente no ciclo 
de vida do projeto. 
• Categorias de riscos: baseadas nos registros históricos e/ou outras fontes de informações utilizadas na elaboração de uma lista 
de riscos classificados por categorias distintas. Podem ser classificados como riscos organizacionais, de ordem técnica ou 
tecnológica, riscos associados à Política da Qualidade da companhia, Riscos Externos, de ordem econômica e estratégica da 
empresa etc. Essa forma de classificação de riscos (relacionados sempre às ameaças e/ou oportunidades) será tratada com mais 
detalhes a seguir. 
• Formatos de relatórios: descrição de relatórios (formato, padrão, conteúdo, periodicidade etc.) que serão utilizados para 
reportar os riscos às partes interessadasdurante o desenvolvimento do projeto. Algumas empresas preferem estabelecer um 
padrão próprio de relatórios, geralmente a serem apresentados para a alta administração da companhia. O intuito principal é levar 
as informações sobre os riscos de forma objetiva e sucinta, inclusive solicitando auxílio dos dirigentes para determinados riscos, 
quando isso for realmente necessário. Um exemplo seria o ‘registro de riscos’ que nada mais é do que um local repositório no qual 
será armazenada a maior quantidade de informações dos riscos identificados. Pode ser de forma eletrônica, em planilhas ou 
arquivos digitais, repositórios compartilhados de dados, papéis e formulários impressos ou até manuscritos. O que realmente 
interessa é que se tenha acesso às informações tão logo sejam solicitadas. Diretrizes de probabilidade e impacto: elaboração das 
escalas de probabilidade e impacto para que os riscos (tanto ameaças quanto oportunidades) possam ser classificados de acordo 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
com sua prioridade e severidade. A definição de uma matriz de probabilidade e impacto tem o intuito de “padronizar” as possíveis 
interpretações por parte do time de gestão de riscos, além de assegurar a compreensão dos riscos pelo time como um todo. 
Podemos analisar, a seguir, exemplos de escalas de probabilidade e de impacto, bem como um modelo de matriz de classificação de 
riscos. De acordo com Mulcahy (2010) faz-se necessário que tanto as escalas quanto a matriz sejam definidas e elaboradas ainda 
na fase de desenvolvimento do plano de gerenciamento de riscos. 
Figura 1 - Escala de probabilidade de riscos 
Fonte: Adaptado de PMI (2013). 
Geralmente, a escala de probabilidade não é maior do que 8 em uma escala de 1 a 10. Isso porque se a 
probabilidade for maior que 8 (ou 80%), você estará lidando não com uma probabilidade de algo acontecer, 
e sim com um fato (algo que muito provavelmente já aconteceu!). 
Fonte: Mulcahy (2010, p. 131). 
Figura 2 - Escala de impacto de riscos 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Adaptado de PMI (2013). 
Os quadros, descritos anteriormente, são apenas uma referência, modelos sugeridos pelo PMI (2013). Você poderá construir sua 
própria tabela de probabilidade e impacto, utilizando a numeração que achar adequada para elaborar suas escalas, podendo, por 
exemplo, reduzir para simplesmente baixo, médio ou alto grau de impacto. 
Apenas não se esqueça de contemplar as dimensões de escopo, prazos, custos e qualidade, pois se qualquer uma destas áreas de 
conhecimento for afetada poderá comprometer os resultados parciais ou totais do seu projeto. Conforme, o grau de tolerância do 
projeto ou dos stakeholders , você poderá ainda alterar os percentuais constantes nos quadros para que reflitam a realidade dos 
principais interessados nos resultados do projeto. 
Figura 3 - Modelo de Matriz de riscos 
Fonte: Adaptado de PMI (2013). 
A tabela de riscos, citada anteriormente, também se trata de um template , podendo ser ajustada de acordo com as necessidades de 
cada projeto. Qualquer zona (vermelha, verde, azul ou cinza) poderá ser expandida ou contraída, refletindo os graus de tolerância a 
riscos por parte dos principais interessados nos resultados do projeto, os stakeholders . Ao alterar o valor das escalas de 
probabilidade e impacto (consequências) os valores resultantes do produto também serão alterados, reclassificando dessa 
maneira os níveis de riscos do projeto. 
Encerramos essa parte com as abordagens sobre os conceitos básicos sobre riscos, a importância do estabelecimento e 
reconhecimento das premissas do projeto, os papéis e responsabilidades dos stakeholders na gestão de riscos, as vantagens de se 
elaborar um plano de gerenciamento de riscos eficaz e as técnicas de definição e elaboração das escalas de probabilidade e 
impacto, além da matriz referencial de riscos. Uma sugestão importante: não se prenda somente a ele, tome o cuidado de realizar 
as pesquisas sugeridas e as leituras complementares, aumentando significativamente dessa maneira as chances de aprendizado 
sobre o tema. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Espero que você tenha aproveitado o conteúdo abordado, pois há muito mais coisas interessantes por vir! 
CATEGORIAS DE RISCOS 
Olá! Vamos dar continuidade aos nossos estudos sobre gestão de riscos. Sua dedicação e entusiasmo farão toda a diferença nesta 
nossa caminhada. Vamos demonstrar agora um dos métodos de se trabalhar com riscos – tanto as oportunidades quanto as 
ameaças –, elaborando uma lista de riscos classificados e que podem ser agrupados em categorias de riscos por terem 
características similares entre si, gerando assim várias categorias distintas. 
Podemos tomar como exemplo de categorias os fornecedores, a tecnologia, o meio ambiente, legislações, condições econômicas, 
recursos etc. É possível utilizar uma ferramenta denominada Estrutura Analítica de Riscos traduzido do inglês Risk Breakdown 
Structure (RBS ) como forma de representação de categorias de riscos. Na Figura 4, temos uma representação gráfica de uma RBS 
em formato de mapa mental: 
Figura 4 - Estrutura Analítica de Riscos 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Adaptado de PMI (2013). 
Vamos entender aqui um pouco do conceito aplicado em uma RBS. Você verá que o nome do projeto está no centro do diagrama. 
Posteriormente, poderá decompor o que chamaremos de categorias de riscos principais (no caso do exemplo citado, 
Gerenciamento de Projetos, Externo, Técnico e Organizacional). Vamos tomar alguns exemplos sobre cada categoria que aparece 
na figura 4. 
Na categoria de Gerenciamento de Projetos é muito comum que riscos referentes às estimativas de prazos e custos das atividades 
sejam identificados, além de problemas de comunicação entre as equipes e os stakeholders . Na categoria ‘Externo’, os órgãos 
reguladores e outros fatores (como até o climático) podem influenciar e gerar riscos que precisam ser tratados ao longo do 
desenvolvimento do projeto. 
Já na categoria técnica, explorar uma nova tecnologia pode gerar inúmeras incertezas que, se não forem tratadas e gerenciadas, 
podem gerar riscos que venham inclusive a comprometer a continuidade do projeto. Por fim, a categoria organizacional pode 
influenciar e muito os resultados do projeto. Conflitos de interesse, diferentes expectativas por parte dos stakeholders e a disputa 
por recursos funcionais dedicados aos projetos podem gerar sérios riscos que acabam por se tornar grandes desafios para a equipe 
de riscos do projeto. 
De acordo com Greene e Stellman (2010), uma vez que você tenha criado as categorias principais, deve agora decompor a 
estrutura em outras mais detalhadas (Técnico/Tecnologia, Externo/Mercado, Organizacional/Recursos e assim por diante). Isso 
deve ser feito justamente para que trabalhe com riscos que podem impactar direta ou indiretamente o seu projeto, contemplando 
várias categorias correlacionadas às principais. 
Observe como essa forma gráfica de representação das categorias de riscos poderá auxiliá-lo a organizar melhor a lista de riscos 
identificados, classificando-os e relacionando-os com as áreas, departamentos ou divisões da companhia. Isso servirá, ainda no 
processo de tratamento de riscos, de grande ajuda para identificar quem serão os responsáveis por tomar uma ação caso o evento 
incerto ocorra. 
Outro aspecto interessante que você deve considerar é a forma gráfica de representação das categorias de riscos em uma 
estrutura hierárquica, o que lhe proporciona maior visibilidade dos problemas (ameaças) e oportunidades que estão rondando seu 
projeto, assim como também permite a mesma visualização e inteligibilidade ao seu time de riscos. Podemos aindaassociar esse 
método a algumas técnicas, por exemplo: 
• Brainstorm, que é uma técnica na qual o time de riscos se reúne em um ambiente e uma rodada de ideias é iniciada. Cada 
membro poderá dizer qual risco consegue visualizar, sem se preocupar muito nesse momento com a qualificação dos dados 
(análise de chances de ocorrer ou ainda o impacto causado caso ocorra). 
• Delphi, relativamente parecida com o brainstorming , porém com a vantagem de os participantes permanecerem anônimos. 
• Análise Strengths , Weaknesses , Opportunities and Threats (SWOT) que em português significa Forças, Fraquezas, 
Oportunidades e Ameaças – é uma técnica que permite explorar os pontos fortes e pontos fracos assim como as oportunidades e 
ameaças inerentes ao projeto e/ou a companhia patrocinadora dele. 
• Diagrama de causa e efeito, que também é conhecido como Diagrama de Ishikawa ou Espinha de Peixe, que se apresenta como 
uma ferramenta de extremo auxílio na identificação de possíveis causas para um único problema. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
• Failure Mode Effects Analysis (FMEA) cuja função seria descobrir as origens de defeitos responsáveis pelas falhas internas e/ou 
externas aplicadas na gestão da qualidade. Além de ser uma ótima ferramenta, é um método que trata as falhas como problemas 
potenciais e que podem ter suas origens identificadas. 
• Obtenção da opinião dos especialistas, que é baseada em entrevistas com o cliente, com a alta administração da companhia 
patrocinadora do projeto, com os especialistas técnicos e de negócio, com os consultores que emprestam (e prestam) seus 
conhecimentos ao projeto, enfim, com todo e qualquer stakeholder que venha agregar valor ao processo de identificação de riscos. 
Todas estas técnicas de identificação de riscos serão abordadas mais a frente e com mais detalhes e exemplos sobre cada uma 
delas. 
Categorias de riscos sempre existirão na maioria (para não dizer todos) dos projetos, por exemplo, riscos associados aos custos e 
prazos preestabelecidos e acordados com o cliente. Para exemplificar melhor, há aquelas que são clássicas e devem ser 
contempladas pela equipe de riscos do projeto. De acordo com Mulcahy (2010), podemos relacionar algumas, porém sem nos 
limitar somente a elas: 
• Técnica : relacionadas geralmente à engenharia ou à tecnologia, na qual pode haver dificuldades técnicas de se atender a algum 
requisito técnico ou de desempenho de materiais (Ex.: obras de engenharia civil ou projetos de Tecnologia da Informação). 
• Produção : riscos associados a problemas de embalagens, logística de matéria-prima, maquinário, armazenamento etc. 
• Fornecedor : podem ser fornecedores de matéria-prima, produtos acabados, módulos intermediários ou ainda mão de obra 
especializada. Geralmente, os riscos associados a fornecedores impactam o projeto de forma parcial ou total, dependendo da sua 
influência. Por exemplo, um projeto no qual 70% dos resultados dependem de um único fornecedor de produtos e de mão de obra 
qualificada). 
• Fatores internos : riscos associados à capacitação do corpo operacional, instalações, equipamentos, recursos materiais etc. 
• Influências externas: perigos relacionados às mudanças de legislações, indisponibilidade de materiais, notificações de órgãos 
regulamentadores, instituições burocráticas governamentais etc. 
• Segurança: ameaças e oportunidades inerentes a vulnerabilidades, segurança pessoal, confidencialidade, conformidades legais, 
condições ergonômicas, condições climáticas, sabotagens etc. 
• Gestão de projetos: falta de capacitação técnica e gerencial por parte do time de projeto, processo de comunicação ineficaz 
entre os stakeholders , falta de uma metodologia de gestão de projetos definida, requisitos de qualidade mal definidos, escopo do 
projeto incompleto ou indefinido etc. 
No momento em que você se reunir com a sua equipe para elaborar uma lista de riscos, a RBS se 
apresentará como uma ferramenta muito útil. As categorias previamente definidas, além de outras que 
podem ser criadas, servirão de um eficaz lembrete quando vocês estiverem em uma sessão de 
brainstorming . Não acha? 
Fonte: Greene e Stellman (2010, p. 548). 
Apesar de a RBS ser uma ferramenta bem interessante e eficaz na identificação de riscos, Mulcahy (2010) recomenda que o uso de 
categorias e agrupamento de riscos seja aplicado somente após um número significativo de riscos terem sido identificados pelo 
time de riscos do projeto, geralmente para que novas ideias surjam por meio do emprego da RBS. Não obstante, não é muito raro 
que em alguns projetos uma categoria completa de riscos tenha sido negligenciada, muitas vezes por falta do uso de uma RBS bem 
elaborado. 
Uma lista de categoria de riscos faz parte de uma base histórica de projetos. Ela pode ser originada de lições aprendidas, 
repositórios de registros de riscos, relatórios de encerramento, relatos de especialistas, enfim, qualquer formato que permita 
registrar informações e dados consolidados de projetos passados (que podem ainda ser internos ou externos à companhia). 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Deve-se tomar muito cuidado com o uso de listas de categorias de riscos, principalmente se forem aplicadas 
logo no início do tratamento (e identificação) deles. Isso porque, não raramente, podem gerar uma falsa 
sensação de segurança ao gerente de projeto em achar que todos os riscos inerentes ao projeto foram já 
cobertos nessa etapa. 
Fonte: Mulcahy (2010, p. 363). 
A indústria petrolífera brasileira se tornou nos últimos anos referência internacional no emprego de novas 
tecnologias no manuseio e extração de óleo presente em águas profundas. Em 2011, uma empresa de 
grande porte desse setor investiu na implementação de uma tecnologia denominada Separação Submarina 
de Água e Óleo (SSAO). Para tanto, uma das boas práticas de gestão de projetos aplicada foi a gestão de 
riscos, pois essa era uma tecnologia pouco explorada até então. A utilização de uma RBS foi crucial para o 
sucesso da iniciativa, pois serviu como fonte de dados dos documentos registrados na companhia, um banco 
de dados com histórico de projetos anteriores e a experiência da equipe. 
De posse dessa documentação, elaborou-se uma RBS detalhada (pela primeira vez no histórico da empresa) 
que foi fundamental para o mapeamento dos potenciais riscos que poderiam prejudicar os resultados 
esperados, principalmente financeiros, pois os investimentos estavam na ordem de milhões de dólares. 
Depoimentos posteriores da equipe do projeto corroboraram a teoria, pois reconheceram que a ferramenta 
os auxiliou de forma extrema no tratamento dos principais riscos (e inéditos nesse caso) até a finalização do 
projeto. 
Fonte: Palma et al. (2011). 
Vimos à técnica de identificação de riscos por agrupamentos e por categorias, por meio da utilização de uma RBS que pode ainda 
ser associada a outras técnicas e ferramentas de identificação de riscos. Discorremos sobre algumas categorias mais usuais de 
riscos, porém, lembrando que não devemos nos limitar somente a elas e que, dependendo de cada tipo de projeto, novas categorias 
e formas de agrupamento de riscos vão surgindo para suprir as necessidades de abrangência dos riscos do projeto. Vamos seguir 
em frente, porque isso está ficando cada vez mais interessante! 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
FORMAS DE IDENTIFICAÇÃO DE 
RISCOS 
Olá! Vamos dar continuidade aos nossos estudos. Até aqui já aprendemos, basicamente, a definir o que é um risco (ameaça ou 
oportunidade) por meio da análise dos impactos com efeitos positivos e negativos e de suas escalas previamente elaboradas no 
plano de gerenciamento de riscos, qual é a melhor forma de representá-lo, além de outras características importantes sobre 
classificaçãode riscos em categorias. Mas, a diversão começa exatamente agora! Pois, é a partir daqui que você colocará a 
criatividade em prática. Dizemos isso porque é na fase de identificação de riscos que temos que exercer nossa capacidade criativa, 
sempre em busca de ameaças ou oportunidades inerentes ao projeto. 
Existem inúmeras formas, técnicas, dinâmicas e boas práticas para se identificarem riscos, tanto das oportunidades quanto das 
ameaças que rondam seu projeto. Técnicas individuais como uso de entrevistas e preenchimento de formulários, técnicas em 
grupo como brainstorm e técnica Delphi, além de outras que serão abordadas com bem mais detalhes no capítulo seguinte. 
O mais importante, no final, é possuir o discernimento de qual a mais apropriada forma de identificação se aplicará, ou melhor, em 
que momento isso deverá ocorrer, pois esse processo de identificação deve ocorrer durante todo o ciclo de vida do projeto 
(KERZNER, 2009). 
Formato causa-risco-efeito 
Uma forma complementar e bem eficaz de se trabalhar com listas de categorias de riscos e, consequentemente, a elaboração de 
uma RBS, é a utilização do formato de causa-risco-efeito, sugerido por Mulcahy (2010). A autora ainda afirma que essa seria a 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
melhor maneira de se definir um risco – tanto como ameaça quanto como oportunidade. Vamos analisar como seria a definição de 
um risco na categoria “Fornecedor”, primeiramente reportando-o de maneira, digamos, “convencional” e, posteriormente, usando o 
emprego do formato causa-risco-efeito sugerido por Mulcahy: 
Modo “convencional” 
• O fornecedor de mão de obra específica e qualificada pode atrasar uma entrega importante, comprometendo a data final do 
projeto. 
Notem que no modo que chamamos de “convencional”, o risco é reportado genericamente e não sugere sequer uma forma de 
resolver o problema. Inúmeras seriam as razões pelas quais o fornecedor poderia atrasar uma entrega importante do projeto, 
ficando assim mais complexo de se indicar uma alternativa de solução. 
Modo causa-risco-efeito 
• Por conta do não conhecimento por parte do fornecedor do cronograma completo do projeto. 
• Pode haver distorções na compreensão das entregas principais (envolvendo escopo e prazo) do projeto. 
• Comprometendo a data de entrega atribuída ao fornecedor e, por consequência, a data final do projeto. 
Já no formato de causa-risco-efeito, tratamos de identificar não somente as consequências (dificultando uma proposta de 
solução), mas também a potencial origem do problema. Nesse exemplo, se atuarmos na origem, ou seja, se levarmos em tempo 
hábil ao conhecimento do fornecedor o cronograma completo do projeto e demonstrarmos em que momento suas atividades se 
encaixam nele, evidenciando a importância do cumprimento dos prazos preestabelecidos, aumentamos significativamente as 
chances de que esse tipo de ameaça não ocorra. 
Essa não é uma forma muito simples de reportar ameaças e/ou oportunidades nos projetos, porém, o importante é buscarmos 
sempre pela raiz principal dos potenciais riscos. É necessário bastante treino para não confundir e priorizar as consequências e não 
a causa-raiz, que se apresenta como a verdadeira ameaça ao projeto. A causa- -raiz é a origem do problema, no qual ele realmente 
se manifesta. Se não tratarmos sua origem, estaremos, na verdade, cuidando de seus sintomas e não o resolvendo por definitivo. 
Essa seria a principal razão pelas quais diversas ameaças ocorrem mais de uma vez, com reincidências. 
Dessa maneira, ao nos esforçarmos para remediar uma situação que se apresenta em primeira instância como inevitável, podemos 
sim diminuir (ou até eliminar) as chances de que ela se manifeste. De acordo com Greene e Stellman (2010), utilizando esse 
formato podemos distinguir até mesmo uma única fonte (causa-raiz) que pode causar inúmeras consequências (efeitos) e que, se 
bem tratada, permite que eliminemos vários riscos inerentes ao mesmo tempo no projeto que estamos gerenciando. 
Olhe para o exemplo acima do fornecedor e faça um exercício mental: Quantas consequências poderiam ser 
evitadas (ou terem os impactos diminuídos) se o fornecedor tivesse conhecimento prévio e plena 
compreensão do cronograma completo do projeto e se soubesse exatamente qual a importância do 
cumprimento dos seus e de outros prazos preestabelecidos e registrados nessa ferramenta? 
Em se tratando de fornecedores (de serviços, produtos, mão de obra qualificada etc.), Dinsmore e Cabanis-Brewin (2009) 
recomendam que sejam tratados também como stakeholders . Ou seja, precisam participar do projeto e não simplesmente 
“fornecer” ou serem cobrados por entregar isso ou aquilo em determinado momento, fase ou etapa. Assim como as demais partes 
interessadas têm necessidades de comunicação, de gerenciamento de expectativas, de participar até mesmo da gestão de riscos 
efetivamente. 
Obviamente não necessitam conhecer toda a estratégia e outras informações muitas vezes confidenciais pertencentes somente à 
companhia patrocinadora do projeto, mas devem saber o suficiente para que se reconheçam como “parte participativa” do projeto, 
observando a importância que suas entregas oferecem ao projeto e quanto agregam valor aos resultados parciais e finais. Se não 
forem bem gerenciados e engajados (comprometidos) com as entregas parciais e finais, podem se tornar fonte de riscos em 
potencial. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Podemos compreender que o engajamento não só dos fornecedores, mas de todos os stakeholders do projeto, é de suma relevância 
até para o seu sucesso. Em outras palavras, e de acordo com Kerzner (2009), determinar quem fará parte da equipe de riscos ao 
longo do ciclo de vida do projeto é comumente visto como um “removedor de obstáculos” nos processos de gestão de riscos. 
Envolver – e de certa forma engajar, comprometer – as pessoas certas durante o processo de identificação de riscos (ameaças e 
oportunidades) pode ser crucial e determinante para o sucesso ou fracasso da iniciativa. 
Alguns stakeholders , por si próprios, podem representar riscos (principalmente ameaças) para os projetos sob seu gerenciamento. 
Isso se deve ao fato de que existe a possibilidade de haver conflito de interesses e também expectativas distintas dentre as partes 
interessadas com relação aos resultados parciais e finais do projeto. Nível de exposição, comprometimento com os benefícios 
adquiridos e mudanças organizacionais, entre outros, são fatores que podem contribuir com essa situação. 
Convidar o cliente a participar do time de riscos também pode ser uma boa ideia. Em um projeto de uma 
rede de restaurante fast food nos Estados Unidos, em 2009, a empresa fornecedora das janelas de contato 
com os clientes (balcão de atendimento por meio de uma janela de vidro) convidou os principais clientes e 
patrocinadores para serem membros do time de riscos. Como resultado, onze novos riscos foram 
identificados, os quais o time de projetos não havia sequer considerado. Isso foi possível porque essas 
pessoas utilizaram antecipadamente as janelas de atendimento (protótipos), como clientes do restaurante, 
e verificaram na prática quais eram os riscos associados que poderiam afetar principalmente a qualidade e a 
pontualidade dos atendimentos. 
Fonte: Mulcahy (2010, p. 71). 
Devemos aqui reforçar a importância da determinação de quem fará parte do time de riscos do projeto, seja de maneira 
circunstancial, seja durante todo o seu ciclo de vida. Para sua melhor compreensão, nenhum stakeholder em potencial deveria ficar 
de fora desse processo, desde o membro representante da mais alta administração até mesmo o aprendiz do departamento X da 
companhia, contanto que este se encontre no contexto do projeto. Todo aquele que vier a ter uma mínima contribuição deve ser 
considerado e consultado,pois pode revelar novas ideias e surpreender até mesmo os mais experientes do time do projeto. 
Para a coleta de informações e identificação dos riscos, o ideal é que toda a equipe esteja reunida em um único local e de forma 
presencial. Essa condição facilita bastante, pois evita ruídos na comunicação, dado que as interações face a face são muito mais 
eficientes por meio da leitura corporal e expressões faciais, enquanto, ocorrem as interlocuções. Obviamente, isso nem sempre é 
possível, pois haverá situações em que estarão envolvidas equipes remotas. 
Para aumentar as chances de sucesso na identificação de riscos nessa condição de time “dispersado” de riscos, destacam-se 
algumas dicas, dentre as quais: 
• Prover uma comunicação eficaz, garantindo que todos tenham acesso aos mesmos níveis de informação. 
• Deixar bem claro quais são os objetivos e resultados esperados para que todos tenham as expectativas alinhadas. 
• Utilizar a técnica do anonimato, isto é, fazer com que os stakeholders contribuam com suas considerações de forma anônima, via 
website , com uma conta de usuário genérica (em que todos tenham o mesmo usuário e senha), por exemplo, para contribuir com 
suas colocações. 
Reuniões virtuais utilizando audioconferência e troca de e-mails têm demonstrado pouca eficácia no processo de identificação de 
riscos, dada à exposição que os membros do time possam sentir, comprometendo a qualidade e a quantidade de riscos 
identificados. Porém, não devem ser simplesmente descartadas, e podem ser complementadas com outras técnicas, dinâmicas e 
boas práticas que vamos discutir na sequência. 
Fechamos assim este conteúdo compreendendo a importância de fazermos a identificação de riscos no formato causa-risco-efeito, 
pois somente assim podemos garantir que os eventos incertos foram resolvidos na sua origem, evitando que sejam reincidentes. 
Vimos ainda que a comunicação é fundamental para todo e qualquer processo onde os stakeholders (sejam eles internos ou 
externos ao projeto) estejam envolvidos, para inclusive aumentar o comprometimento deles com a gestão dos riscos nos projetos. 
Espero que as informações apresentadas até aqui tenham agregado valor ao seu conhecimento. E vamos prosseguir, pois há 
bastante informação relevante mais à frente. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
TÉCNICAS DE IDENTIFICAÇÃO DE 
RISCOS 
Olá, caro(a) aluno(a). Até aqui já elaboramos a metodologia e a estratégia de planejamento dos riscos do projeto. Tomamos o 
cuidado de estabelecer os indicadores (escalas de probabilidade e impacto), observamos a apresentação dos riscos no formato 
causa-risco-efeito e envolvemos (e comprometemos) os stakeholders que poderão contribuir e agregar valor aos processos de 
identificação de riscos. Agora, vamos conhecer as melhores técnicas, ferramentas e boas práticas aplicadas a esse processo de 
extrema importância no gerenciamento de riscos. Você está convidado(a) para ver isso de perto. 
Segundo Kerzner (2009), os riscos – tanto as ameaças quanto às oportunidades – deveriam ser identificados por meio da 
perspectiva do “E se...”, criando assim uma ideia inicialmente condicional para posteriormente concretizá-la como um potencial 
risco aos acontecimentos do projeto. Para você ter uma ideia, seria se perguntar inicialmente “O que poderia dar errado no meu 
projeto?”, não apenas na fase inicial (chamados de riscos preliminares) como ao longo do ciclo de vida dele. 
Assim como acontece com as categorias de riscos, existem inúmeras maneiras, técnicas e dinâmicas de identificá-los, por exemplo, 
as técnicas de Brainstorming , a técnica Delphi, Diagrama de Causa e Efeito, além de outras. Diante disso, vamos abordá-las com 
mais detalhes, das mais às menos utilizadas, das mais complexas às mais simples. Como relatado anteriormente, cabe ao gerente 
de projeto e ao time de riscos o discernimento de qual delas e em qual momento utilizá-las. 
Brainstorming 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Greene e Stellman (2010) sugerem que a técnica de brainstorm seja utilizada como a opção inicial para identificação de riscos do 
projeto. Com o time de riscos reunido em um ambiente, uma rodada de ideias é iniciada, e cada membro poderá dizer qual risco 
consegue “enxergar”, sem se preocupar muito nesse momento com a qualificação dos dados (análise de chances de ocorrer ou 
ainda o impacto causado caso ocorra). Uma pessoa do time vai anotando todas as ideias expressas, enquanto outra, denominada 
facilitador, vai mediando as rodadas e organizando-as; cada elemento deverá dizer apenas uma ideia, passando a vez ao próximo. 
Para facilitar as anotações, o próprio time pode escrever suas ideias em pequenos papéis adesivos ( post - it ) e colocá-los em um flip - 
chart ou quadro branco, por exemplo. Note que essa técnica permite que novas ideias sejam “contaminadas” pelas que já foram 
relatadas, aumentando a profundidade de um assunto abordado pelo time. A dinâmica deverá continuar até que o grupo se 
certifique de que esgotou as possibilidades. É importante que o time de riscos seja bem heterogêneo. 
Isso significa que deve ser composto por profissionais de áreas distintas, porém, relacionadas ao projeto. Vamos dar um exemplo: 
se o seu projeto for um novo produto de uma empresa do setor de agronegócio, é interessante que o time de riscos seja formado 
por engenheiros agrônomos, especialistas do meio, analistas financeiros, profissionais com conhecimento em questões ambientais, 
experts em agrotóxicos etc . 
Se mantivermos apenas um grupo de especialistas, como os engenheiros agrônomos, a lista de riscos será muito pobre para um 
projeto dessa envergadura. 
Em nosso exemplo, a equipe do projeto pensará na construção e elaboração do novo produto, enquanto, representantes da área 
que irão utilizá-lo (ou comercializá- -lo, se for o caso) pensarão em quão difícil será trabalhar com ele, e assim por diante. Dessa 
forma, podemos perceber que riscos distintos, porém correlacionados, serão identificados pelo time. 
Técnica Delphi 
Trata-se de uma técnica relativamente parecida com o brainstorming , porém com a vantagem de os participantes permanecerem 
anônimos. Dizemos vantagem porque quando se está no anonimato normalmente os membros do time se sentem com mais 
liberdade para tocar em assuntos considerados críticos e que podem gerar polêmica, apesar de serem de extrema importância na 
coleta e registro de riscos. E como se dá esse anonimato? Bem, de acordo com o PMI (2013), a técnica envolve o uso e envio de 
requisições específicas – com riqueza de detalhes – a alguns especialistas da área em questão. O facilitador recebe o parecer dos 
especialistas, compila essas informações em uma única lista (tomando o cuidado de manter o anonimato dos participantes) e a 
envia a todos para que expressem novamente as opiniões. 
Note que dessa maneira não há “contaminação” de ideias (pelo menos não tão direta, se comparado com o brainstorming ), e o 
intuito principal é a busca pelo consenso de um assunto considerado complexo e polêmico no projeto. Podemos utilizar como 
exemplo os riscos associados ao uso de uma tecnologia ainda não explorada pela companhia em um projeto de engenharia para um 
novo produto de manufatura. A técnica Delphi ao colher anonimamente as opiniões dos especialistas e buscar um consenso entre 
elas, vem com o intuito de cobrir os possíveis riscos (ameaças e oportunidades) inerentes a esse tipo de projeto. 
A técnica pode ser muito bem aplicada a times remotos (distantes geograficamente) e se mostrar eficaz. Em contrapartida, um 
efeito colateral é tomar demasiado tempo para que os especialistas respondam às requisições enviadas pelo facilitador. 
Uma das boas práticas que pode (e deve) ser aplicada na fase de identificação de riscos é ter listas 
separadas: uma com ameaças e outra com oportunidades –e o registro de riscos que representam as 
oportunidades deve vir primeiro. Não parece muito fácil identificá-las primeiro, porém essa prática pode 
levantar o moral do time e deixá-lo mais à vontade com as técnicas, uma vez que não parecerão tão 
negativos em relatar somente o que pode dar errado no projeto. É muito provável que um membro do time, 
ao relatar sua quarta ou quinta ideia somente de ameaças e catástrofes aos resultados, poderá ficar 
constrangido perante os demais integrantes do grupo, o que fica mais difícil de acontecer com as 
oportunidades. Outra dica importante é que a lista de oportunidades deve ser revisitada após a lista de 
ameaças estar (relativamente) completa. Assim, será menos complexo descobrir novas oportunidades, 
bastando para tanto pensar inversamente às ameaças. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Mulcahy (2010, p. 78). 
Análise SWOT 
A análise Strengths , Weaknesses , Opportunities and Threats (SWOT) traduzida em português para Forças, Fraquezas, 
Oportunidades e Ameaças – constitui uma técnica que permite explorar os pontos fortes e pontos fracos (do projeto ou até mesmo 
da companhia patrocinadora dele), assim como as oportunidades à vista e as ameaças evidentes no momento da análise. Segundo 
Dinsmore e Cabanis-Brewen (2009), é possível analisar os pontos fortes para encontrar as oportunidades correspondentes e, 
posteriormente, utilizar os pontos fracos para auxiliar na identificação das ameaças aos resultados parciais e/ou totais do projeto. 
Esse tipo de análise tende a ser mais bem-sucedido quando aplicado em um workshop do tipo imersão. 
Para termos uma ideia do que isso representa, basta imaginar sessões de brainstorming sucessivas e em território neutro, ou seja, 
com os participantes desprovidos de desvio de atenção como aparelhos de telefone celular, computadores, telefones fixos na mesa 
de trabalho, intervenções por colegas etc. Assim, os esforços são concentrados na identificação dos riscos, enquanto há registros e 
documentação sendo preparados durante o workshop , os quais farão parte posteriormente da documentação de riscos. 
Essa técnica de imersão pode ser aplicada também para outras instâncias, como na fase de determinação e delimitação do escopo 
total ou parcial do projeto. 
Diagrama de Causa e Efeito 
Também conhecido como Diagrama de Ishikawa ou Espinha de Peixe trata-se de uma ferramenta do Gerenciamento da Qualidade 
Total – em inglês Total Quality Management (TQM) – que, segundo Seleme e Stadler (2008), é de extremo auxílio na identificação 
de possíveis causas para um único problema. Alinhada com o formato causa-risco-efeito, foi criado em 1953 por Ishikawa e busca a 
origem do problema, para que se evite atuar no sintoma (efeito), e sim identificar a causa-raiz dele, tornando bem mais eficaz o 
tratamento do risco. 
Utilizamos o Diagrama de Causa e Efeito para obtermos um levantamento sistemático das causas, em que o foco deve estar em 
estruturar o problema e visualizar preliminarmente as possíveis alternativas de resolução, antes mesmo que o evento aconteça. 
Na Figura 5, temos um diagrama básico de Ishikawa, demonstrando os 6 M’s (materiais, máquinas, método, meio ambiente, mão de 
obra e medida), muito utilizados nos processos de controle da qualidade total. 
Figura 5 - Diagrama de Ishikawa (ou Espinha de Peixe ou Diagrama de Causa e Efeito 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Adaptado de Seleme e Stadler (2008, p. 91). 
Por ser uma ferramenta que visa buscar a origem dos problemas – ou pelo menos algumas alternativas de solução para uma 
situação apresentada –, pode ser perfeitamente adaptada para a identificação de riscos. Vamos demonstrar um exemplo prático do 
uso dessa técnica. 
Imaginemos agora que você é o gerente de projetos de um novo sistema para a área de Marketing de uma empresa do setor de 
cosméticos. Sua equipe de riscos identificou a possibilidade de um atraso na entrega de um dos módulos de desenvolvimento do 
programa, de responsabilidade de um fornecedor contratado para esse fim. 
Você, então, decide utilizar uma ferramenta visual para auxiliar o time a descobrir as possíveis causas desse atraso, apresenta o 
Diagrama de Ishikawa a todos e pede para que indiquem algumas potenciais causas-raiz. Após debaterem, apresentam algumas 
alternativas, como segue: 
• Houve muitas mudanças de escopo durante o desenvolvimento. 
• Alguns membros do time de desenvolvimento saíram do projeto, uns foram substituídos e outros tiveram as atividades 
distribuídas para outros membros do time. 
• Esse tipo de programa de computador nunca havia sido desenvolvido antes. 
• Descobriram falta de conhecimento técnico por parte do time sobre um software de desenvolvimento utilizado no projeto. 
Muito provavelmente a adaptação do Diagrama de Ishikawa para esse problema em específico ficaria conforme ilustrado na Figura 
6: 
Figura 6 - Diagrama de Ishikawa para o problema de atraso na entrega do fornecedor 
Fonte: Adaptado de Seleme e Stadler (2008, p. 91). 
O time de projetos pode continuar a inserir algumas possibilidades de causas-raiz até que chegue a um consenso de quais são as 
causas mais prováveis. Se alguma causa- -raiz tiver uma chance maior do que 80% de acontecer serão tratadas como um fato e 
gerenciada como parte do escopo do projeto. Caso o grupo determine que a probabilidade seja menor do que 80% serão tratadas 
como um risco potencial e deve ser incluída no plano de gerenciamento de riscos. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Failure mode effects analysis (FMEA) 
Outra ferramenta do Gerenciamento Total da Qualidade cujo objetivo é buscar as causas-raiz de determinados problemas, 
recorrentes ou não, é a Análise do Modo e Efeito da Falha – em inglês, Failure Mode Effects Analysis –, mais conhecida pela sigla 
nesse idioma FMEA (leia-se Fêméa). Segundo Mello (2011), a função é descobrir as razões de defeitos responsáveis pelas falhas 
internas e/ou externas na gestão da qualidade. Além de uma ferramenta, é um método que trata as falhas como problemas 
potenciais e que podem ter as origens identificadas. 
Como o intuito é identificar as causas possíveis desse problema e eliminá-las – ou pelo menos reduzir drasticamente a chance de 
acontecerem ou voltar a acontecer, além de prever a redução de impactos negativos e indesejáveis –, estamos falando de um 
método de prevenção, e, como tal, pode ser perfeitamente “emprestado” para a gestão de riscos em projetos, dada sua similaridade 
com o formato causa-risco-efeito. 
O método sugere, segundo Sbragio (2009), analisar os modos de falhas – tanto as novas como as recorrentes – e mapear os efeitos 
delas. Isso implica que pode haver mais de um efeito para um único modo de falha e, sendo assim, podemos determinar 
alternativas de solução (de prevenção) e de tratamento dos impactos (de correção, quando o evento incerto já ocorreu) por meio 
de formulários-padrão. 
Para demonstrarmos um exemplo mais prático e compreender melhor o conceito desse método, vamos utilizar o mesmo exemplo 
dado na ferramenta anterior, o Diagrama Ishikawa. Para tanto, vamos reescrever uma das potenciais causas-raiz no formato de 
causa-risco-efeito, como segue: 
• Causa da falha: houve muitas mudanças de escopo durante o desenvolvimento. 
• Risco: o escopo original não pôde ser atendido conforme o previsto. 
• Efeito da falha: ocorreu atraso em uma das entregas de desenvolvimento do sistema. 
Essa análise determina os pontos-chave do método, que utiliza um formulário-padrão e sugere um detalhamento muito maior e 
completo para o tratamento da falha. Apresentaremos, aqui, um formulário básico, porém a ferramenta se apresenta flexível e 
pode se adequar a praticamente qualquer tipo e natureza de projeto, basta compatibilizar as colunasde medidas às necessidades 
do projeto. 
Apesar dessa flexibilidade e adaptabilidade, o método muitas vezes é considerado um processo deveras lento e custoso, uma vez 
que vários stakeholders precisam ser mobilizados para sua elaboração. Contudo, não podemos nos esquecer dos benefícios da ação 
preventiva, quando nos antecipamos aos problemas e conseguimos resolvê-los antes mesmo que a atividade pertinente seja 
executada. 
Podemos tomar como exemplo um membro do time que em determinado momento deseja se desligar do projeto. Não podemos 
nos antecipar a todo e qualquer evento, mas suponhamos que esse profissional deseje sair do time por achar que está sendo 
subutilizado e que suas habilidades não estão sendo aproveitadas como ele gostaria. Se esse potencial evento for mapeado em um 
FMEA, alguma ação preventiva pode ser considerada, como identificar essa negligência no time e mobilizar esse recurso para que 
tenha mais responsabilidades e desafios à altura, componentes partes do incentivo e da motivação. A Figura 7 ilustra a utilização 
do formulário-padrão para o caso analisado. 
Figura 7 - Formulário básico do FMEA 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Adaptado de Sbragio (2009). 
Seguem, a seguir, as tabelas de apoio para compreender as pontuações atribuídas aos níveis de severidade, ocorrência e detecção 
presentes no formulário-padrão do FMEA. 
Tabela 1 - Classificação da Severidade (SEV) 
Fonte: Adaptado de Sbragio (2009) 
Tabela 2 - Classificação da Ocorrência (OCO) 
Fonte: Adaptado de Sbragio (2009). 
Tabela 3 - Classificação da Detecção (DET) 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Fonte: Adaptado de Sbragio (2009). 
Para melhor compreensão do formulário padrão do FMEA, vamos olhar mais atentamente as colunas que recebem pontuações e 
seus impactos no risco que está sendo analisado: 
• Primeiro, avaliamos o risco apresentado e seus possíveis efeitos, aplicando- -lhe uma pontuação referente à sua severidade e 
de acordo com a Tabela 1 (em nosso caso foi aplicado o valor 3, ou seja, não atender o prazo estipulado para uma entrega do 
projeto afeta inicialmente as áreas administrativas relacionadas ao projeto). 
• Posteriormente, avaliamos a frequência com que a potencial causa ocorre (ou poderá ocorrer) durante o ciclo de vida do 
projeto de acordo com a Tabela 2 (aqui, demos a pontuação igual a 3, o que significa que mudanças ocorrem pelo menos uma 
vez por mês). 
• Em seguida, atribuímos uma pontuação de acordo com a Tabela 3 para identificarmos o grau de detecção ao qual o risco está 
sujeito (demos, um valor igual a 3, o que equivale dizer que o time do projeto detecta problemas dessa natureza antes que o 
cliente os perceba). 
• Isso feito, multiplicamos as três colunas e identificamos o Nível de Prioridade do Risco (NPR), que em nosso caso é igual a 27 
(3 x 3 x 3). 
• Após identificarmos o NPR, trabalhamos com um plano de ações (ou um plano que responda ao risco), diminuindo a chance de 
ele ocorrer ou ainda reduzindo os impactos se ele for inevitável, mantendo-o sob nosso controle. 
• Com o plano de ações definido e pronto para ser colocado em ação caso o risco venha a ocorrer, classificamos novamente os 
níveis de severidade, ocorrência e detecção, identificando o novo NPR para esse evento. 
Observe que após esse tratamento, demos a pontuação igual a 2 para o quesito severidade (reduzindo o efeito do impacto 
somente ao projeto); atribuímos um valor igual a 2 para o nível de ocorrência (para pelo menos uma vez a cada trimestre no 
projeto); e um valor igual a 2 para o nível de detecção (correspondendo a uma probabilidade moderada, ou seja, com monitoração 
mais acirrada, porém ainda reativa). Com isso, obtemos um NPR igual a 8 (2 x 2 x 2), bem menor que o nível inicial que tinha um 
valor igual 27. 
O método do formulário-padrão, segundo Sbragio (2009), deve ser aplicado com o intuito de prevenirmos ou detectarmos 
possíveis alterações nas variáveis dos processos pertinentes ao projeto, as quais venham conduzir a um desvio das especificações 
iniciais do planejamento. 
Dessa forma, temos a flexibilidade de aplicarmos esse método antes de o evento ocorrer, de forma preventiva e durante o 
processo de identificação dos riscos, ou mesmo após a ocorrência dele de forma reativa, porém, diminuindo consideravelmente as 
chances que se dê novamente, uma vez que o problema é tratado diretamente na sua causa-raiz. 
Opinião dos especialistas 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
A técnica de obtenção da opinião de especialistas pode ser utilizada a qualquer momento no ciclo de vida do projeto no intuito de 
agregarmos valor aos processos de identificação de riscos. Podemos entrevistar o nosso cliente (que é quem demanda o projeto), a 
alta administração da companhia patrocinadora do projeto, os especialistas técnicos e de negócio, os consultores que emprestam 
(e prestam) seus conhecimentos ao projeto, enfim, todo e qualquer stakeholder que venha agregar valor ao processo de 
identificação de riscos. Segundo Mulcahy (2010), há a vantagem de essa técnica ser aplicada até para times remotos por meio de 
preenchimento de formulários, respostas por e-mail, conference calls (ligações telefônicas), videoconferência ou outro meio de 
comunicação para esse fim. 
Porém, apesar de parecer simples, é necessário todo um planejamento e organização prévios para aplicá-la, além de termos de 
manter o controle sobre os resultados esperados. Como o método é bem similar a uma pesquisa de campo, a preparação 
preliminar da metodologia a ser usada se faz extremamente necessária: é preciso identificar o que realmente se espera obter das 
entrevistas e quais serão as perguntas específicas a serem apresentadas ao público-alvo. É importante fazer com que o seu 
interlocutor perceba a importância desse procedimento (veja, isso não é lá muito fácil!), explicando-lhe de maneira bem objetiva 
por que ele (ou ela) tem papel relevante para o processo e quais são as expectativas sobre os resultados, antes de iniciar a 
entrevista para a coleta de potenciais riscos do projeto. 
Tenha o cuidado de envolver somente as pessoas necessárias do seu time de riscos do projeto para auxiliá- 
lo a conduzir uma entrevista para coleta de potenciais riscos – ameaças ou oportunidades. Organizar uma 
reunião com o time todo e convidar um ou mais especialistas para ser(em) entrevistado(s) é uma técnica que 
muito provavelmente terá pouca chance de sucesso. Selecione apenas as pessoas-chave, as quais poderão 
auxiliá-lo com as perguntas de foro técnico ou de negócios, os quais realmente agregarão valor a esse 
processo de identificação de riscos. 
Uma boa abordagem para essa técnica, segundo Kerzner (2009), é deixar inicialmente o interlocutor bem à vontade, com 
perguntas abertas que façam com que ele reflita sobre o projeto e sua complexidade. Somente então direcione suas perguntas 
objetivas previamente elaboradas. Note que o sucesso da entrevista dependerá muito da habilidade do entrevistador em conduzi- 
la, pois se o interlocutor for interrompido abruptamente, por exemplo, provavelmente a eficácia da entrevista terá sido 
comprometida nesse momento. 
Mantenha o foco nos resultados esperados e cativar a participação dos colaboradores, de modo a obter a maior quantidade e 
qualidade das informações que serão utilizadas. Outras perguntas que não estavam na sua lista preliminar podem surgir. Nessas 
situações, as habilidades do entrevistador devem vir à tona para que os resultados sejam mais satisfatórios. Observe os aspectos 
da linguagem corporal do interlocutor para perceber se a entrevista está sendo agradável ou se está se mostrando uma perda de 
tempo para o entrevistado(nesse caso será hora de mudar de estratégia ou até mesmo mencionar a possibilidade de remarcar a 
entrevista). 
Você poderá, ao perceber que a entrevista está próxima do final, dizer que irá procurá-lo(la) posteriormente para complementar 
algumas informações, enfatizando a importância que ele(ela) representa para o projeto. Permita que o interlocutor faça algumas 
considerações finais e deixe bem claro que você estará à disposição. Deixe todas as formas de contato possível e tenha o cuidado 
de ser solícito quando for abordado, para manter sua credibilidade. Por fim, agradeça cordialmente a participação do interlocutor 
e, se possível, lhe dê algum feedback sobre como as informações foram tratadas durante o desenvolvimento do projeto. 
Você consegue imaginar o quanto um stakeholder ficaria satisfeito – e poderia colaborar ainda mais em uma 
suposta nova abordagem – caso você levasse ao seu conhecimento que alguns itens importantes levantados 
durante a entrevista foram fundamentais para o sucesso parcial ou mesmo total do projeto? 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Registro de riscos 
O registro de riscos nada mais é que um local onde será armazenada a maior quantidade de informações dos riscos identificados. 
Pode ser de forma eletrônica, em planilhas ou arquivos digitais, repositórios compartilhados de dados, papéis e formulários 
impressos ou manuscritos etc. O que importa, na verdade, é que se tenha acesso às informações tão logo sejam solicitadas. O 
registro de riscos, ao longo do ciclo de vida do projeto, torna-se também o histórico do projeto que pode ser consultado para a 
elaboração do planejamento em projetos futuros, uma vez que tanto as ameaças como as oportunidades são muitas vezes 
recorrentes em projetos similares da companhia. 
Manter o hábito de registrar todos os riscos em um repositório único é uma boa prática de gestão de riscos em projetos, segundo 
Mulcahy (2010). Para tanto, apresentamos na Figura 8 uma sugestão de um modelo de registro de riscos, lembrando apenas de que 
se trata de um documento vivo, ou seja, precisa ser revisitado e atualizado periodicamente para manter o controle dos riscos no 
projeto. 
Figura 8 – Modelo de registro de riscos em projetos 
Fonte: Adaptado de Mulcahy (2010, p. 109). 
Alguns termos novos apresentados na Figura 8 precisam de esclarecimentos. De acordo com Valeriano (2004), são os seguintes: 
• Proprietário do risco em potencial: Todo e qualquer risco precisa de um proprietário, que é a pessoa que tomará alguma ação 
caso ele aconteça ou esteja na iminência de acontecer. Geralmente, é aquele que identifica o risco, pois se o stakeholder 
percebeu a ameaça ou oportunidade, muito provavelmente poderá sugerir alternativas de solução e tomar as devidas ações 
quando necessário. Podemos tomar como exemplo um stakeholder que identificou a ameaça de a empresa de transporte não 
enviar recursos suficientes para embalar e carregar os equipamentos, mesas, cadeiras e outros materiais em um projeto de 
mudança de prédio da companhia. Caso essa ameaça ocorra, mesmo após o risco ser tratado, muito provavelmente o 
stakeholder ficará incumbido de providenciar recursos para executar a tarefa e será identificado no registro de riscos como o 
proprietário do risco. Ele também poderá delegar essa função, e tal informação deverá ser inserida no campo em questão. 
• Provável resposta ao risco: Da mesma forma que o stakeholder identificou a ameaça ou oportunidade, poderá sugerir 
alternativas de solução do problema ou mesmo participar da construção da solução junto com outros membros do time. As 
possíveis alternativas devem ser registradas, pois serão muito úteis no processo de gerenciamento dos riscos ao longo do ciclo 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
de vida do projeto. 
• Gatilhos: São geralmente avisos ou pequenos eventos que sinalizam que o risco está prestes a acontecer ou que já aconteceu. 
Os proprietários dos riscos devem observar esses sinais ao longo do ciclo de vida do projeto e tomar a ação correta e necessária 
tão logo se tornarem evidentes. Para exemplificarmos, imaginemos que o gatilho de uma ameaça em um projeto seja o não 
atendimento de uma reunião de status e verificação de entregas parciais de um fornecedor do projeto. Ora, se o fornecedor não 
atendeu à reunião e não enviou nenhuma informação prévia, muito provavelmente está com a data das entregas 
comprometida, sinalizando que a ameaça está prestes a acontecer. 
Se a ação necessária for estabelecer uma auditoria no fornecedor (e se essa condição estiver em cláusula contratual), esse é o 
momento de o proprietário do risco seguir os procedimentos preestabelecidos como resposta a essa ameaça. 
• Riscos por atividade: Você poderá gerenciar os riscos do projeto como um todo; se atividade for muito complexa e apresentar 
mais de um risco, poderá mapeá-los de forma isolada, conforme demonstrado na Figura 8. 
Outras técnicas de identificação de riscos podem ser utilizadas pela equipe de projeto. Podemos utilizar 
formulários a serem preenchidos, que são eficazes quando as equipes são remotas e distantes. Podemos 
fazer uso da análise de ‘pre-mortem’ que seria uma sessão na qual os stakeholders imaginariam que o 
projeto já tivesse terminado e fracassado. Então, poderiam avaliar o que deu errado e por que, identificando 
novas ideias para eventos incertos. Há ainda a técnica do ‘Focus Group’ na qual podemos obter opinião de 
um grupo ao invés de opiniões individuais. Geralmente são aplicadas a um departamento por completo 
(Marketing, por exemplo) que detém o maior conhecimento sobre a área e os riscos relacionados à ela. A 
técnica da árvore de decisão também pode ser utilizada, pois por se tratar de uma ferramenta visual pode 
contribuir para que os stakeholders possam visualizar novas possibilidades de eventos incertos no projeto. 
Fonte: Mulcahy (2010). 
Tivemos oportunidade desta parte dos estudos de abordarmos as principais ferramentas de identificação de riscos, desde as mais 
comuns utilizadas até as mais complexas e específicas. O emprego de cada uma delas deverá ser de discernimento do Gerente de 
Projetos junto a sua equipe, adequando-as às necessidades da gestão dos riscos do projeto. Vimos ainda à importância de se ter 
um repositório como o registro de riscos, para manter sempre à mão informações úteis relacionadas aos eventos incertos do 
projeto. Informações, por exemplo, de quem seria o responsável por monitorar o risco e quais seriam os ‘avisos’ que alertariam que 
o risco está prestes a acontecer – ou que já aconteceu – para que as ações cabíveis possam ser tomadas. 
Chegamos ao final do nosso estudo preliminar sobre gestão de riscos em projetos. Espero que tenham aproveitado os assuntos 
abordados, além de terem aproveitado os exercícios de fixação. Nossa recomendação é que você tome por hábito a pesquisa sobre 
o tema para que possa enriquecer o seu conhecimento e buscar cada vez mais a aplicabilidade em projetos reais. Desejamos que 
este conteúdo possa ter contribuído com os seus estudos. 
• Formato de causa-risco-efeito. 
• Categorias de riscos. 
• Técnicas, ferramentas e boas práticas. 
• Causa-raiz. 
• Registro de riscos. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/atividades
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/unidade-1
https://getfireshot.com
Unidade 1 Página inicial 
ATIVIDADES 
1. Das alternativas, a seguir, qual delas apresenta a melhor definição de risco? 
a) Uma limitação do projeto. 
b) Um problema que já aconteceu no projeto. 
c) Uma oportunidade ou ameaça que pode afetar o projeto. 
d) Um problema que requer atenção do patrocinador para ser resolvido. 
e) Uma incertezaque eu espero acontecer para tomar uma ação corretiva. 
2 . Caso você decida por não fazer o gerenciamento de riscos em projetos, qual das seguintes consequências seria a mais provável 
de acontecer? 
a) Seu cliente ficaria muito satisfeito, pois você estaria reduzindo os prazos do projeto. 
b) Os membros do time de projeto ficariam insatisfeitos. 
c) O projeto custaria mais e levaria mais tempo para ser entregue. 
d) O escopo total do projeto seria entregue com mais qualidade. 
e) Haveria redução no orçamento, pois um menor número de pessoas estaria envolvido no planejamento. 
3. Os dois componentes principais de um risco são: 
a) Tempo e custo. 
b) Qualidade e prazo. 
c) Incertezas e dano causado. 
d) Custos e tomadas de decisões constantes. 
e) Análise de escopo e de impactos. 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/atividades
https://getfireshot.com
4 . Qual das seguintes ações NÃO faz efetivamente parte do Plano de Gerenciamento de Riscos: 
a) Definir papéis e responsabilidades dos membros do time de riscos do projeto. 
b) Estabelecer as estimativas de prazos e custos das atividades do projeto junto aos especialistas. 
c) Estabelecer o formato dos relatórios de riscos a serem utilizados periodicamente. 
d) Definir as escalas de probabilidade e impacto a serem utilizadas no plano de gestão dos riscos. 
e) Desenvolver uma lista de categoria de riscos por meio da elaboração de uma estrutura analítica de riscos 
5. Assinale V (verdadeiro) ou F (falso) nas sentenças a respeito do Plano de Gerenciamento de Riscos em projetos: 
( )As categorias de riscos podem ser definidas como áreas comuns ou fontes de riscos que podem ser agrupados, inclusive 
em projetos similares. 
( )O emprego da RBS deveria ser a primeira técnica a ser utilizada na identificação de riscos. 
( )Os riscos deveriam ser identificados em todas as categorias mais relevantes de riscos. 
( )Categorias de riscos são utilizadas apenas para identificar ameaças em projetos, não se aplicando na identificação de 
oportunidades. 
a) F, F, V, V 
b) V, V, F, F 
c) V, F, V, F 
d) V, V, V, F 
e) F, F, V, F 
6. Qual das ferramentas e técnicas, a seguir, não poderia ser associada a uma categoria de riscos nem utilizada para identificar 
riscos? 
a) Diagrama de causa e efeito 
b) Brainstorm 
c) Análise SWOT 
d) Diagrama e Rede de Precedências 
e) Técnica Delphi 
7. Associe os termos relacionados ao gerenciamento de riscos, a seguir, com as respectivas descrições: 
a) Formato causa-risco-efeito 
b) Lista de categorias de riscos 
c) Causa-raiz 
d) Processo de identificação de riscos 
e) Identificar e mobilizar stakeholders 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/atividades
https://getfireshot.com
( )Áreas comuns ou fontes de riscos similares em projetos 
( )Principal elemento objeto de busca para quem gerencia riscos em projetos. 
( )Parte do processo de designação de papéis e responsabilidades na gestão de riscos. 
( )Como resultado de uma origem, um fato pode ocorrer, o que poderia levar até a uma consequência indesejada. 
( )Determinar riscos específicos por projeto ou por atividade. 
Marque a alternativa correta: 
a) B-C-E-A-D 
b) C-E-A-B-D 
c) A-B-C-D-E 
d) E-A-D-C-B 
e) D-A-E-B-C 
8 . A MELHOR definição de gerenciamento de riscos é: 
a) ( ) O processo de identificar, analisar e responder proativamente a riscos. 
b) ( ) O processo de redução do risco a um nível aceitável para o projeto. 
c) ( ) O processo de garantir que a maioria dos riscos do projeto estejam apenas documentados e controlados. 
d) ( ) Criação do registro dos riscos. 
e) ( ) O processo necessário somente para redução de custo e tempo no projeto. 
9. Qual das sentenças, a seguir, NÃO é verdadeira sobre os processos de gerenciamento de riscos? 
a) Riscos devem ser discutidos em todas as reuniões que a equipe do projeto realizar. 
b) Os riscos devem ser sempre analisados e tratados de acordo com seu impacto e com sua prioridade. 
c) O gerente de projetos é o único profissional responsável pela identificação dos riscos. 
d) Todos os riscos conhecidos e identificados devem ser acrescentados ao registro de riscos. 
e) O projeto pode ter uma equipe de riscos separada do time executor dele. 
10. Trata-se de uma técnica de avaliação de riscos que utiliza como recurso questionários, algumas rodadas, relatórios emitidos de 
forma anônima que são compartilhados com os stakeholders sem que conheçam a fonte da informação. Estamos falando da 
técnica chamada: 
( )Times remotos 
( )Delphi 
( )FMEA 
( )Entrevistas com especialistas 
( )Grupos de afinidades 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/atividades
https://getfireshot.com
11. Você é o gerente de um projeto em uma empresa do setor alimentício. Durante as sessões de identificação de riscos, alguns 
stakeholders garantem que há um risco de categoria técnica evidente no projeto. Outros stakeholders discordam, apontando que as 
possibilidades são praticamente nulas. Um dos membros do primeiro grupo vem lhe procurar pessoalmente e tenta convencê-lo de 
que o risco realmente existe. Quais das seguintes ações você deve fazer primeiro? 
a) Incluir o risco na sua lista de riscos, apesar de tudo. 
b) Conversar com o stakeholder para acalmá-lo, mas não incluir nada de forma indiscriminada na lista de riscos. 
c) Tentar obter mais informações, principalmente sobre a razão pela qual o risco precisa ser incluído na lista. 
d) Solicitar ajuda aos patrocinadores do projeto. 
e) Não incluir o risco e deixar claro para todos que o gerenciamento de riscos está sob sua responsabilidade, por isso, cabe a 
você a última palavra. 
12 . Assinale V (verdadeiro) ou F (falso) para as sentenças abaixo: 
( ) Failure Mode Effects Analysis (FMEA) é um processo que busca o consenso de alguns stakeholders de forma anônima. 
( ) Brainstorming é feito por meio de reuniões com o intuito de obter ideias diversas ou para solucionar problemas. 
( )Diagrama de Ishikawa é uma técnica usada para determinar riscos específicos por projeto ou por atividades. 
( )Registro de riscos é uma lista de riscos identificados – ameaças ou oportunidades – muito importante para o processo de 
gerenciamento de riscos. 
a) V, V, F, F 
b) V, F, V, F 
c) F, F, V, V 
d) F, V, F, V 
e) F, F, F, V 
Resolução das atividades 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/atividades
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/resumo
Unidade 1 Página inicial 
RESUMO 
Este estudo permitiu-nos compreender a importância da abordagem do gerenciamento dos riscos em projetos, pelo simples fato 
de que se nada fizermos com relação aos eventos incertos aos quais todo e qualquer projeto está sujeito, certamente as ameaças 
acontecerão e comprometerão os resultados parciais ou finais esperados, ao passo que as oportunidades não acontecerão sem 
que nada seja feito. 
A gestão de riscos deve ser feita para manter, em primeira instância, a “saúde” do seu projeto (assim como a de seus 
colaboradores). A palavra de ordem para tanto é planejamento, que permitirá definir indicadores (de saúde do projeto) e persegui- 
los da maneira mais eficaz possível. As técnicas, ferramentas e boas práticas abordadas nesta unidade vêm ao encontro dessa 
gestão eficaz, pois o domínio desses elementos visa a garantir o sucesso do projeto, atingindo seus objetivos com a menor perda 
possível, seja financeira, seja de prazos, seja de qualidade do trabalho a ser realizado. 
A apresentação dos riscos de forma clara ao time de riscos do projeto (e aos demais stakeholders ) permite um controle mais rígido 
dos possíveis desvios a que todo e qualquer projeto está sujeito. Os passos iniciais aqui descritos são a base para a compreensão 
das estratégias envolvidas, que regerá todo o processo de maneira organizada, dando visibilidade e credibilidade a quem lida