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. 
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. 
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 
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?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/unidade-1?authuser=0
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. 
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 assumirmos no 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 umposte 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. 
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 interessadas durante 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 dedados, 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 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 
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. 
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 
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 ainda associar 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. 
• Failure Mode Effects Analysis (FMEA) cuja funçãoseria 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). 
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! 
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ção de 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 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. 
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. 
Fechamosassim 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. 
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 
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. 
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çõespor 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 
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. 
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 colunas de 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 
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) 
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) duranteo 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 
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? 
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çaou 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 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?authuser=0
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/atividades?authuser=0
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 incerteza que 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. 
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 
( )Á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 responsabilidadesna 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 
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?authuser=0
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/resumo?authuser=0
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 com os eventos incertos, sejam eles prejudiciais, sejam benéficos aos projetos. Basta compreendermos os conceitos teóricos e a forma mais 
apropriada de aplicabilidade das ferramentas e técnicas aqui descritas e tentar ao máximo colocá-las em prática, pois somente assim as dúvidas surgirão e poderão ser sanadas. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/resumo?authuser=0
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
Unidade 1 Página inicial 
Material Complementar 
Leitura 
Um guia do conhecimento em gerenciamento de projetos (PMBOK) 5ª edição 
Autor: PMI – Project Management Institute 
Editora: Saraiva 
Sinopse : uma ferramenta considerada essencial para todo gerente de projetos. Por quase 3 décadas, 
Um Guia do Conhecimento em Gerenciamento de Projetos (PMBOK® Guide) tem sido uma 
ferramenta primordial para gerenciamento de projetos e uma referência fundamental que deve estar 
na biblioteca de todo gerente de projetos. Nessa edição, há um apêndice que trata das habilidades 
interpessoais que um gerente de projetos utiliza ao gerenciar um projeto. Recomendamos a leitura do 
capítulo 11 ‘Gerenciamento dos riscos em projetos’ páginas 309 a 353. 
Na Web 
O especialista brasileiro em gerenciamento de projetos Ricardo Vargas apresenta um podcast 
explanando as principais ferramentas para que os riscos do projeto possam ser devidamente 
identificados. Baixe o arquivo e ouça-o (necessário recursos de áudio, caixas de som multimídia ou 
fone de ouvido no computador ou tablet) 
Acesse 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/gdrep1/p�gina-inicial/eu-indico?authuser=0
https://getfireshot.com
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial?authuser=0
http://www.google.com/url?q=http%3A%2F%2Fwww.ricardo-vargas.com%2Fpt%2Fpodcasts%2Friskidentification%2F&sa=D&sntz=1&usg=AFQjCNEIDqCPNgSLxq51UaV1sLR2ZrPDIQ
https://sites.google.com/fabrico.com.br/gdrep1/p%C3%A1gina-inicial/refer%C3%AAncias?authuser=0
Unidade 1 Página inicial 
REFERÊNCIAS 
DINSMORE, P. C.; CABANIS-BREWIN, J. AMA manual de gerenciamento de projetos .Rio de Janeiro: Brasport, 2009. 
DINSMORE, P. C.; COOKE-DAVIES, T. J. The right projects done right ! First edition. San Francisco: Jossey-Bass, 2006. 
GREENE, J.; STELLMAN, A. Use a Cabeça, PMP ! 2. ed. Rio de Janeiro: Editora Alta Books, 2010. 
KERZNER, H. Project Management: A systems approach to planning, scheduling and controlling. 10. ed. New York: John Wiley & Sons Inc., 2009. 
MAXIMIANO, A. C. A. Administração de Projetos : como transformar ideias em resultados. 5. ed. São Paulo: Atlas, 2014. 
MELLO, C. H. P. Gestão da