Gestão de Riscos em Projetos

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
DOWNLOAD PDF
UNICESUMAR | UNIVERSO EAD

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 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.
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 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
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

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
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

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çã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).
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.
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.
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.
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.
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

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)
Tabela 3 - Classificação da Detecção (DET)

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

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ç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
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

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 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
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

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

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

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 Qualidade. São Paulo: Pearson Education do Brasil, 2011.
MULCAHY, R. Risk Management: Tricks of the Trade for Project Managers and PMI-RMP Exam Prep Guide. 2.ed. Minnetonka:
RMC Publications Inc., 2010.
PALMA, M. A. M.; ANDRADE, J. L. P.; PEDRO, J. da S. Gestão de riscos em projeto: contornando incertezas para viabilizar a
implantação de nova tecnologia em uma indústria petrolífera de E&P. Revista de Gestão e Projetos - GeP, São Paulo, v. 2, n. 2, p
102-122, jul./dez. 2011. Disponível em: http://www.revistagep.org/ojs/index.php/gep/article/view/43 Acesso em: 12 jul. 2016. .
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the Project Management Body of Knowledge (PMBOK® Guide) Fifth .
Edition. Newtown Square, 2013.
SELEME, R.; STADLER, H. Controle da Qualidade as ferramentas essenciais. Curitiba: IBPEX, 2008.
:
SBRAGIO, R. Engenharia Econômica e Análise de Riscos. São Paulo: Escola Politécnica da Universidade de São Paulo, 2009.
VALERIANO, D. L. Gerência em projetos: pesquisa, desenvolvimento e Engenharia. São Paulo: Pearson Education do Brasil, 2004.
VARGAS, R. V. Manual prático do plano de projeto utilizando o PMBOK Guide . 3. ed. Rio de Janeiro: Editora Brasport, 2007.
Avançar

APROFUNDANDO
PROJETO CALEIDOSCÓPIO
O projeto aqui descrito trata de um Trabalho de Conclusão de Curso de uma equipe do curso de Cinema, cuja tarefa era produzir
um curta-metragem como produto final do TCC. Ele foi planejado para ser finalizado em nove meses, com um orçamento total em
torno de R$ 322.000,00. Entretanto, a gestão de riscos do projeto foi mal planejada e elaborada, custos de transporte e
alimentação foram subestimados, e uma “análise do que poderia dar errado” em relação às fases do projeto não foi levada em
consideração.
Não havia uma lista de riscos que evidenciassem ameaças que inevitavelmente poderiam acontecer, e tampouco um plano de
remediação havia sido elaborado, prejudicando financeiramente nesse caso o projeto. Os resultados esperados foram
comprometidos e ainda tiveram que tratar dos riscos às pressas, sem uma avaliação prévia dos impactos no projeto como um todo
e sem nenhuma metodologia previamente definida, o que ocasionou em mais perdas financeiras ao projeto.
O que puderam levar dessa situação foi tão somente às lições tiradas para projetos futuros, aprendendo de maneira crítica que
burlar certas etapas da gestão de riscos em projetos pode causar situações irreversíveis.
Fonte: Adaptado de Maximiano (2014, p. 344).
PARABÉNS!
Você aprofundou ainda mais seus estudos!
Avançar

EDITORIAL
DIREÇÃO UNICESUMAR
Reitor Wilson de Matos Silva
Vice-Reitor Wilson de Matos Silva Filho
Pró-Reitor de Administração Wilson de Matos Silva Filho
Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva
Pró-Reitor de Ensino de EAD Janes Fidélis Tomelin
Presidente da Mantenedora Cláudio Ferdinandi
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ Núcleo de Educação . a Distância; SAMPAIO ,
Paulo.
Gestão de Riscos em Projetos. Paulo Sampaio .
Maringá-Pr.: UniCesumar, 2017.
58 p.
“Pós-graduação Universo - EaD”.
1. Gestão. 2. Projetos. 3. EaD. I. Título.
CDD - 22 ed. 658
CIP - NBR 12899 - AACR/2
Pró Reitoria de Ensino EAD Unicesumar
Diretoria de Design Educacional
Equipe Produção de Materiais
Fotos Shutterstock
:
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900
Maringá - Paraná | unicesumar.edu.br | 0800 600 6360
Retornar

ANÁLISES
QUALITATIVA E
QUANTITATIVA DE
RISCOS
Professor (a) :
Me. Paulo Sampaio
• Levar ao conhecimento do(a) aluno(a) acerca do que é e qual a importância da qualificação dos dados sobre os riscos
• Garantir que haja o nivelamento de informações sobre a probabilidade e impacto dos riscos entre os principais stakeholders do
projeto.
• Abordar sobre o teste de estabilidade e veracidade das premissas do projeto, potenciais fontes de riscos.
• Conhecer como obter uma lista priorizada de riscos.
• Compreender os processos pertinentes à Análise Qualitativa dos riscos.
• Aprender como calcular as reservas de contingência de prazos e custos de acordo com o grau de riscos do projeto.
• Explorar técnicas e ferramentas de gestão de riscos que proporcionem informações válidas para a tomada de decisões nos
projetos.
Plano de estudo
• Testes de premissas e qualificação dos dados
• Priorização e classificação dos riscos
• Cálculo da reserva de contingência de prazos e custos
• Técnicas de Modelagem e análise quantitativa dos riscos
Introdução
Caro(a) aluno(a), nesta unidade, partiremos de uma lista com os riscos já identificados por meio de boas práticas de gestão de
riscos, aplicadas pelo gerente de projeto, pelo seu time de apoio e pelos principais stakeholders do projeto. Há inúmeras técnicas
específicas para esse processo, porém para garantir que seja eficaz é necessário que esse processo seja replicado ao longo do ciclo
de vida do projeto, uma vez que quanto mais avançamos e progredimos com a realização das tarefas maior a chance de ocorrência
de eventos incertos.
Primeiramente, vamos discutir algumas técnicas a serem utilizadas para que não ocorram muitas divergências nas pontuações das
escalas para cada risco por parte dos stakeholders buscando passar por um processo de qualificação dos dados e nivelamento das
,
informações entre os mesmos. Compreenderemos a importância do teste de estabilidade e veracidade das premissas do projeto,
estas que são fontes em potencial de riscos, pois se não se mantiverem estáveis passam a se tornar ameaças para o projeto.
Em seguida, abordaremos o tratamento da lista de riscos previamente identificados. De posse dessas informações, descobriremos
como analisar os riscos de forma qualitativa, de maneira ainda um tanto quanto subjetiva, utilizando escalas numéricas de
probabilidade e impacto previamente definidas. O intuito maior com a realização desse processo é a elaboração de uma lista
priorizada de riscos, com os mais significativos (maior chance de acontecerem e/ou com maior impacto ao projeto) no topo da lista
e onde maiores esforços deverão ser empregados. Não podemos esquecer que tanto as ameaças quanto às oportunidades
precisam ser mapeadas e receberem os benefícios da utilização da Análise Qualitativa.
Dando prosseguimento aos nossos estudos, aprenderemos a utilizar métodos confiáveis de cálculo de reservas de contingência em
projetos nos baseando na complexidade e no grau de riscos do projeto. Estas reservas de contingência, tanto de prazos como de
custos, poderão ser utilizadas justamente para o devido tratamento dos eventos incertos no projeto e, se utilizadas, deverão ser
justificadas pelo Gerente do Projeto que prestará conta dos recursos utilizados aos patrocinadores do projeto.
Por fim, abordaremos a Análise Quantitativa dos riscos, apresentando suas melhores e mais eficazes técnicas e ferramentas já
consagradas que podem proporcionar inúmeros benefícios aos projetos. Apesar de serem bem eficazes, aprenderemos que nem
sempre será viável aplicá-las, vários fatores poderão influenciar na realização ou não da Análise Quantitativa de riscos. As decisões
a serem tomadas quase sempre envolverão questões de prazos e custos, recursos muitas vezes escassos na ciência e arte de
gerenciar projetos.
Tenho plena certeza de que sua curiosidade já foi despertada. Então, embarquemos juntos nessa jornada que está pra lá de
motivadora!
Avançar

TESTES DE PREMISSAS E
QUALIFICAÇÃO DOS DADOS
Olá! Seja bem-vindo (a) aos nossos estudos sobre gestão de riscos em projetos, mais especificamente sobre as análises qualitativas
e quantitativas de riscos. Espero que você aproveite muito o conteúdo que aqui será abordado.
Para que a Gestão de Riscos nos projetos que você gerenciará (ou que já esteja gerenciando nesse momento) seja bem-sucedida,
faz-se necessário o consenso e a estabilização das premissas do projeto entre os stakeholders além de termos como garantir que
,
estes mesmos stakeholders possuam o mesmo alinhamento de informações e compreensão acerca dos dados que envolvem e são
pertinentes a cada evento incerto mapeado previamente no planejamento de riscos. Trataremos destes dois importantes assuntos
na abertura desta unidade.
Testes de validade e estabilidade das premissas do projeto
De acordo com o PMI (2013, p. 124), a definição de premissa do projeto é “[...] um fator do processo de planejamento considerado
verdadeiro, real ou certo, desprovido de prova ou demonstração”. Seriam como ‘verdades’ que assumimos para que o projeto
aconteça (e que esteja mais próximo do sucesso) e são registradas nas documentações iniciais do projeto. E por que, oras, são
desprovidas de prova ou demonstração? Bem, pelo simples fato de que as premissas podem se tornar instáveis e/ou ‘inverdades’ ao
longo do ciclo de vida do projeto, comprometendo os resultados parciais ou finais do projeto.
Podemos assumir que toda premissa por definição é uma fonte em potencial de riscos. E sabe por quê? Porque se assumirmos logo
no início que algo deva ser verdadeiro até que o projeto seja finalizado, caso sua estabilidade e/ou validade estejam abaladas, ela
se tornou falsa e, portanto uma ameaça, comprometendo os resultados satisfatórios esperados pelos stakeholders do projeto.
Dessa maneira, toda e qualquer premissa do projeto já deve ser inserida na sua lista de riscos potenciais e ser tratada assim como
os outros eventos incertos levantados durante o processo de identificação de riscos no projeto (tanto oportunidades quanto
ameaças).
Vamos deixar mais fácil o entendimento nesse momento com alguns exemplos de premissas em projetos:
Exemplo 1: Suponhamos que você tenha sido designado como Gerente de Projetos de desenvolvimento de um sistema (programa
de computador) para o departamento de Finanças – Contas a Pagar – da companhia a qual trabalha. O resultado esperado desse
projeto é o sistema desenvolvido, testado e homologado e promovido à produção (usuários das Contas a Pagar utilizando o
programa por meio de seus computadores). Porém, após um levantamento inicial, descobriram que o Hardware disponível para
‘hospedar’ essa aplicação não suportava mais a implantação de nenhum sistema dessa complexidade e magnitude. Podemos
associar, nesse momento, o estabelecimento de uma premissa, ou seja, o sucesso do projeto de desenvolvimento só poderá ocorrer
caso haja a readequação da infraestrutura necessária (novos servidores de aplicação ou remanejamento de aplicações nos
existentes) para hospedagem da nova aplicação. Caso essa ‘verdade assumida’ no início não seja atendida até o final – não existir
Hardware disponível para instalação do sistema ou se ainda não houver mais nenhuma alternativa considerada – todo o projeto de
desenvolvimento do Software está totalmente comprometido.
Exemplo 2: Novamente, você é o Gerente de Projetos da área de manufatura em uma indústria de transformação. Você está
trabalhando arduamente para deixar o planejamento do projeto o mais realista e mais enxuto possível, pois sua equipe de trabalho
é relativamente pequena e não há a possibilidade de aprovações para novas contratações por conta do cenário econômico que a
empresa está enfrentando. Você e sua equipe decidem elaborar uma premissa na documentação inicial, assumindo que o trabalho
cotidiano de três profissionais da empresa não interfira no tempo de dedicação ao projeto. Em outras palavras, os recursos terão
que trabalhar no projeto em full time, possivelmente, delegando as funções operacionais para outros recursos da empresa. Caso
essa condição não aconteça, ou seja, se os trabalhos operacionais influenciarem negativamente o tempo de dedicação destes
funcionários ao longo do ciclo de vida do projeto, os resultados esperados estarão, em médio ou longo prazo, totalmente
comprometidos. Teremos outra condição, na qual a premissa inicial transformou-se em um risco potencial para o projeto, uma
ameaça que poderá levar os recursos humanos do projeto a não cumprirem suas tarefas em tempo hábil, justamente por falta de
dedicação e concorrência com atividades operacionais que, para o projeto em si, pouco agregará.
Neste ínterim, Mulcahy (2010) sugere que o teste de estabilidade e validade das premissas seja feito por meio de escalas e
pontuações dadas pelo time do projeto. A sugestão é que ambas as instâncias (estabilidade e consequência) da premissa sejam
escalonadas de 0 a 10. Um valor entre 5 e 10 para a estabilidade significaria que a premissa ainda é válida. Já uma pontuação entre
5 a 10 para as consequências significaria que essa premissa, caso não seja atendida, causaria um grande impacto no projeto. Logo,
segue um exemplo de análise de estabilidade e validade de premissas utilizando o método sugerido, na tabela 1:
Tabela 1 - Teste de estabilidade e validade de premissas em projetos
Fonte: Adaptado de Mulcahy (2010, p. 129).
Notem que para a premissa que está sendo testada no exemplo, em determinado momento do projeto, sua estabilidade está
ameaçada (sua nota é igual a 3, fora do intervalo de 5 a 10, portanto, com baixa probabilidade de ser verdadeira). Significa que a
condição inicial não está sendo atendida, ou seja, não haverá servidor de programas com recursos disponíveis para hospedar a
aplicação ao final de seu desenvolvimento e homologação. As consequências foram pontuadas como alto impacto (nota 9),
alertando que o projeto como um todo sofre uma séria ameaça caso essa premissa não se torne estável e verdadeira. Portanto,
deve ser inserida na sua lista de riscos (ameaças) e ser tratada como tal, com análises mais profundas a serem discorridas até o final
desta unidade.
Podemos utilizar esse modelo de análise e teste de premissas iniciais em nossos projetos, ou ainda adaptá-lo para as nossas
necessidades, utilizando outra pontuação de escala ou tomando essa sugestão como base para desenvolvermos uma análise
customizada.
Assim como as premissas iniciais são importantes para a avaliação dos riscos nos projetos, temos ainda as
restrições e exclusões do projeto, que em muitas das vezes também são elaboradas e declaradas no
documento inicial do projeto. As restrições são as limitações às quais o projeto está sujeito, podendo ser de
caráter de tempo (o projeto não poderá ser finalizado após uma determinada data) ou de fundos (o projeto
não poderá exceder certa quantia no seu orçamento final), além de outras naturezas. As exclusões são
determinadas durante a elaboração do escopo (o que precisa ser feito e entregue no projeto) e são
registradas como parte do escopo que não será mais contemplado. Para entendermos melhor, seria um
relatório de ordem tributária no nosso exemplo do sistema do departamento de Contas a Pagar, que por
algum motivo foi excluído do escopo original, mas precisa ser registrado. Temos que nos atentar, porém, que
ambos podem tornar-se riscos potenciais para o projeto, caso não tenham sido devidamente discutidos,
registrados e negociados com os principais patrocinadores do projeto, ou em outra circunstância, com o
próprio cliente.
Fonte: PMI (2013, p. 123).
Qualificação dos dados sobre os riscos
Muito bem, já adicionamos nossas premissas iniciais (observado com cuidado também as restrições e exclusões do documento
inicial do projeto) à nossa lista de riscos identificados, que devem ser analisados com mais profundidade. Para tanto, devemos
cuidar em primeira instância da Análise Qualitativa dos riscos identificados (ameaças e oportunidades). Usando para isso escalas
de probabilidade e impacto (características principais dos riscos) previamente estabelecidas para avaliá-la de acordo com as
chances que eles, os riscos, têm de ocorrer durante o ciclo de vida e, se ocorrerem, que tipo ou grau de impacto ocasionarão nos
resultados parciais e totais do projeto.
Podemos compreender que os riscos são constituídos de incertezas, que podem não ser necessariamente ruins, mas que
efetivamente afetam o projeto. Ou seja, segundo o PMI (2013), são eventos incertos que, se ocorrerem, podem impactar tanto de
maneira positiva como negativa os resultados de um projeto. Assim sendo, os riscos podem ser classificados como ameaças
(eventos que impactam negativamente, como um período extenso de chuvas prejudicando uma obra de construção civil) ou como
oportunidades (eventos que impactam positivamente, como a obtenção de descontos inesperados na aquisição de materiais de
acabamento na mesma obra de construção civil). De qualquer forma, ambos os eventos são tratados como riscos.
Pois bem, se estamos falando de eventos incertos, significa que podem ou não ocorrer durante o ciclo de vida do projeto. Assim,
dizemos que existe certa chance do evento acontecer, ou segundo Vargas (2007), uma probabilidade de o evento ocorrer. Caso o
evento incerto ocorra, isso poderá trazer consequências más ou boas que podemos chamar de impacto positivo ou negativo. Dessa
maneira, os riscos e suas intensidades são mensurados de acordo com a probabilidade de acontecerem e o impacto que podem
ocasionar no projeto como um todo.
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 se faz necessário seu constante controle e
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. Às eventuais
chances de ocorrerem denominamos como as ‘probabilidades’ do risco acontecer, com conotação
estatística mesmo. Às consequências que os eventos incertos podem causar ao projeto dá-se o nome de
‘impacto’ que o risco pode causar no projeto, podendo ser positivo ou negativo, dependendo de sua
natureza e abordagem.
Fonte: PMI (2013).
De acordo com o PMI (2013), devemos utilizar escalas (geralmente com intervalos de zero a dez) tanto para pontuarmos as
probabilidades quanto os impactos dos riscos (ameaças e oportunidades) nos projetos que gerenciamos e independente de sua
natureza. Essas escalas de probabilidade e impacto se reduzem a uma matriz de riscos que podemos classificar o risco de acordo
com sua prioridade (assunto que trataremos com mais propriedade um pouco mais a frente). O que devemos ter como ponto de
atenção aqui é a suposta subjetividade do método. Ora, por que o método se demonstra subjetivo? Bem, pelo simples fato de que
cada membro do time de riscos deve dar sua pontuação – de acordo com as informações que possui – para cada evento incerto, a
respeito da chance do mesmo acontecer e, caso ocorra, outra pontuação para o impacto que, conclui, venha causar no projeto.
Note que essas pontuações são dadas, muitas vezes, de forma arbitrária (o que não significa aleatório ou ainda de forma insensata)
e podem variar de acordo com a compreensão que o membro do time de riscos tenha sobre o evento incerto que está sendo
avaliado. O entendimento que um stakeholder do projeto tem (baseado na informação que possui) pode levá-lo a dar uma
pontuação bem divergente em relação a outro stakeholder que pode ter uma informação ou compreensão também divergente
,
sobre o mesmo evento.
Segundo Kerzner (2009), para que isso não ocorra, ou ainda para que possamos diminuir a chance disso acontecer, devemos
trabalhar na qualificação dos dados sobre o evento. Trabalhar na qualificação dos dados significa que você deva garantir que todos
os stakeholders que façam parte do time de riscos tenham o mesmo grau e nível de informação sobre o evento para poder pontuar
(mesmo de maneira subjetiva) por meio de escalas numéricas, as chances do mesmo acontecer e os impactos a ele relacionados.
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!).
Essa qualificação (nivelamento de informações) dos dados do risco deve pelo menos incluir o atendimento a três aspectos
importantes. São eles:
• Confiabilidade e integridade dos dados.
• Quantidade de dados disponível a respeito do risco.
• Nível de compreensão do evento por parte dos envolvidos.
Principalmente, com relação às probabilidades dos eventos incertos acontecerem, Kerzner (2009) sugere o uso de uma escala mais
refinada (que pode até se tornar como um item de consulta) para a pontuação a ser dada pelo stakeholder no momento desse tipo
de análise. Observe a tabela 2, a seguir, com as informações pertinentes à classificação das chances de um evento ocorrer, após a
qualificação dos dados e no intuito de se obter um consenso entre os stakeholders do projeto:
Tabela 2 - O que declarações incertas significam para pessoas diferentes

Fonte: adaptado de Kerzner (2009, p. 764).
Observe que por meio da tabela 2, podemos compreender que não se trata de exatidão quando trabalhamos com possibilidades de
algo ocorrer. Vamos tomar como exemplo as linhas de declarações ‘provável’, ‘pouco provável’ e ‘acredito que possa acontecer’.
Todas elas, apesar de serem declarações distintas e ainda segundo a própria tabela, variam entre 55% e 85% de chance do evento
ocorrer e podem refletir a interpretação de um stakeholder a cerca do evento analisado.
Ora, esse é um intervalo muito grande entre as extremidades, pois se alguém pontua o evento com 5,5 (55% de chance de o evento
ocorrer) e outra pessoa pontua como 8,0 (80%), haverá com toda certeza uma discrepância muito grande nos resultados das
análises. Portanto, de acordo com Kerzner (2009), podemos perceber que a qualificação dos dados nesse momento se faz muito
importante.
Vamos aqui tomar um exemplo um pouco mais prático. Suponhamos que em um projeto importante na empresa a qual você
trabalha estejam trabalhando nesse momento na análise dos riscos identificados previamente. Um dos riscos identificado se trata
de um fornecedor responsável por 25% das entregas totais do projeto e a ameaça associada é de que o fornecedor não faça a
entrega dessa importante etapa do projeto na data especificada.
A empresa fornecedora é conhecida pelos stakeholders do projeto, mas poucos detêm informações relevantes sobre ela. Na
primeira rodada, avaliaram esse risco com uma possibilidade de 40% de ocorrer (com alto impacto, devido à porção grande de
responsabilidade do fornecedor). Essa avaliação foi feita de acordo com as informações que os stakeholders possuíam até o
momento.
Porém, ao consultarem outro departamento da companhia que já tinha feito negócios com essa empresa fornecedora,
identificaram que essa mesma empresa teve problemas de atraso de entregas nos dois últimos projetos aos quais participaram, por
razões obviamente injustificáveis. Apesar disso, a empresa fornecedora detém uma tecnologia muito peculiar no mercado de
trabalho e não seria viável sua substituição em tempo hábil para o projeto.
De posse dessa informação, o time de trabalho certamente avaliaria com muito mais cuidado essa ameaça, atribuindo-lhe uma
pontuação mais condizente com a realidade, permitindo que um plano bem mais elaborado de solução de um potencial problema
pudesse ser desenvolvido pelo time de riscos.
Percebam ainda que após a análise mais detalhada ficou muito mais evidente o atendimento dos três aspectos importantes
relatados um pouco mais acima. Esse seria, então, um dos principais benefícios da qualificação dos dados entre os stakeholders do
projeto no momento das análises das ameaças e oportunidades identificadas.
Foi apresentado em um simpósio sobre Gerenciamento de Riscos em Los Angeles, nos EUA, em Fevereiro
de 2008, os resultados de uma pesquisa feita a respeito das declarações mais comuns e mais subjetivas
acerca das probabilidades de eventos incertos ocorrerem em projetos sobre sistemas e engenharia espacial.
Os resultados compilados indicaram que em mais de 90% dos casos analisados, logo, na primeira instância,
havia respostas tão distintas entre os stakeholders que acabou por gerar um intervalo (entre pontuações
mínimas e máximas) de cerca de 0,7 pontos percentuais. Isso significa que se um stakeholder deu uma
pontuação de 20%, outro deve ter apresentado algo em torno de 90% de chance de o evento ocorrer. A
conclusão foi que declarações muito subjetivas geram com toda certeza discrepâncias enormes e não
devem nunca ser uma das primeiras metodologias a ser aplicada na análise de riscos. Ou seja, quanto mais
for qualificada e nivelada a informação sobre o evento, maior será a eficiência do método de avaliação por
parte dos stakeholders.
Fonte: Kerzner (2009, p. 763).
Muito bem, encerramos essa parte com a compreensão de que os testes de premissas – estabelecidas no início do projeto – são de
muito valor, pois se não forem atendidas até a finalização do projeto poderão se tornar sérias ameaças aos projetos.
Compreendemos os conceitos de ameaças e oportunidades, além das probabilidades e impactos que são características de todo e
qualquer evento incerto do projeto. Além disso, vimos à importância da qualificação dos dados sobre os riscos para que todos os
stakeholders tenham as mesmas condições de avaliá-los, diminuindo a disparidade entre as avaliações utilizando as escalas de
probabilidade e impacto.
Espero que você esteja aproveitando todo o conteúdo abordado até agora, porque há muito mais coisas interessantes por vir!
PRIORIZAÇÃO E CLASSIFICAÇÃO DOS
RISCOS
Olá, vamos dar continuidade aos nossos estudos sobre gestão de riscos. Sua dedicação e entusiasmo farão toda a diferença nessa
nossa jornada juntos!
Agora, aprenderemos que nem todos os riscos precisam ter um plano elaborado e arrojado para respondermos a eles (entenda
aqui que ‘responder’ ao risco significa criar um plano de ação para sabermos o que fazer caso o mesmo ocorra). Mesmo porque,
nem todos têm uma alta chance de ocorrer, ou mesmo que venha a acontecer, o impacto gerado por ele pode não ser assim tão
significativo. Dessa maneira, vamos estudar como fazemos para priorizar os riscos mais importantes e aprender a aplicar esforços
onde realmente agregará valores ao projeto. Mas, que nenhum risco, por mais insignificante que seja, pode ser negligenciado.
Lista priorizada de riscos
Segundo Greene e Stellman (2010), existem riscos e riscos. Alguns causarão inúmeros prejuízos caso aconteçam, porém outros,
mesmo que ocorram não proporcionarão impactos significativos ao seu projeto. Dessa forma, você precisa priorizar a sua lista de
riscos identificados, de modo que seja possível classificá-los – de preferência do mais para o menos significativo – em termos de
probabilidade e impacto, já discutidos anteriormente. Para tanto, realizamos a Análise Qualitativa de Riscos, processo da gestão
de riscos no qual analisamos de forma subjetiva (porém, não de forma aleatória nem tampouco arbitrária) as chances que as
ameaças e/ou oportunidades têm de acontecer e os impactos (positivos ou negativos) que causarão nos resultados parcial ou total
do projeto .
Como já sabemos que esse tipo de análise é um tanto quanto subjetiva – do ponto de vista determinístico – por não ser uma
ciência exata e sim baseada em fatos e/ou outras fontes de dados, vale a pena ressaltar algumas boas práticas, técnicas e
ferramentas para se analisar qualitativamente eventos incertos em projetos:
• Qualificação e equalização dos dados entre os stakeholders, amplamente discutidas anteriormente.
• Determinar a frequência e o tempo de certos riscos também pode ser de grande valia, pois é certo que quanto mais tarde o
risco tende a ocorrer, maior será o impacto que poderá causar, e vice-versa.
• Obtenção da opinião de especialistas, que podem ser tanto os ‘experts’ no assunto em questão (uma tecnologia aplicada ao
projeto, por exemplo) ou componentes do time que já tiveram uma experiência similar no passado.
• Utilização das escalas numéricas de probabilidade e impacto de riscos (tanto as ameaças quanto as oportunidades) para
poder determinar o quão ruim (ou bom) será o impacto caso o evento atinja sua chance máxima de ocorrer. Alinhada à
qualificação dos dados, essa técnica reduz consideravelmente a ocorrência de tendências, a um viés de subestimarmos os
eventos incertos. Veja que se utilizarmos escalas mais simples com graus de variação como ‘baixo, médio e alto’ podemos muitas
vezes negligenciar a eficácia da análise qualitativa, colocando seu projeto em perigo.
Veja abaixo um modelo exemplo de escalas de probabilidade e impacto que podem ser utilizadas para classificar e priorizar os
eventos incertos em seus projetos:
Tabela 3 - Escala de probabilidade de riscos
Fonte: adaptado de PMI (2013).
Note que no exemplo anterior a escala utiliza valores numéricos para que sejam designados aos eventos incertos classificados
pelos stakeholders do time de riscos. Essa técnica tende a cobrir mais intervalos em relação a uma escala com graus de ‘baixo’,
‘médio’ ou ‘alto’simplesmente. Basta identificar que para um valor ‘médio’ teríamos nessa escala um intervalo de 40 a 59% de
chance de ocorrência, ao invés de simplesmente o valor 5 (50%).
Tabela 4 - Escala de impacto de riscos

Assim como na escala de probabilidades, utilizamos valores numéricos para a escala de impactos nos riscos do projeto,
demonstrada anteriormente. Note que para cada valor numérico atribuído há uma referência do quão significativo será o impacto
para os quesitos de custo, prazo, escopo e qualidade do projeto. As referências descritas nesta tabela poderão até mesmo ser
utilizadas como argumentação para o time de riscos convencer os demais stakeholders bem como a alta administração da
,
companhia, acerca dos eventos incertos que, se ocorrerem, podem trazer impactos significativos ao projeto.
O emprego de uma matriz de riscos pode também ser muito útil, uma vez que se trata de uma tabela na qual os seus riscos estão
mapeados de acordo com as pontuações que receberam do seu time de riscos. De maneira visual você poderá identificar quais
riscos têm números maiores (probabilidade x impacto ou a classificação do risco), ou seja, aqueles que têm mais chances de
acontecer com impactos (tanto positivos quanto negativos) significativos ao projeto. Estes, sem dúvida, merecem maior atenção
sua e do time do projeto.
Vamos agora fazer uma ponderação significativa com relação à matriz modelo de riscos apresentada a seguir. Segundo o PMI
(2013), você pode muito bem estabelecer uma convenção com a sua equipe de riscos do projeto para determinar os esforços que
deverão ser empregados no tratamento dos riscos gerais do projeto (ameaças e oportunidades). Como seria essa convenção? Bem,
apenas como exemplo, podemos estabelecer um padrão no qual todo e qualquer evento incerto que tivesse uma classificação ( risk
score ) maior ou igual a 0,16 (probabilidade de 80% e impacto igual a 20%) deveria ser movido diretamente para a Análise
Quantitativa e para a elaboração do plano de respostas aos riscos.
Eventos incertos que se situassem na zona amarela, ou seja, com classificações ( risk score ) entre 0,06 e 0,14 passariam por uma
reunião de tomada de decisão da equipe para verificar se deveriam ou não ser movidos para o processo de Análise Quantitativa.
Finalmente, os eventos que estivessem na zona verde com classificações entre 0,01 e 0,05 deveriam apenas ser documentados e
fazer parte da lista de observação ( watch list ) durante todo o ciclo de vida do projeto (observe que riscos que tenham pouca
representatividade hoje podem tomar proporções impactantes à medida que o projeto progride e, por essa razão, devem ser
monitorados constantemente).
Cada vez que você analisa um evento de acordo com sua probabilidade e impacto, gera um risk score para ele. Dessa forma, muitos
riscos que foram identificados – em primeira instância sem nos preocuparmos com sua qualificação – podem ‘descer’ ou ‘subir’ na
lista conforme sua pontuação obtida e ocupando um posicionamento distinto na lista. A esse posicionamento damos também o
nome de risk ranking.
Entretanto, a ideia geral aqui não seria gerar uma simples lista com atribuições numéricas que tornasse possível classificar os
riscos de forma literal e sair distribuindo-os em uma lista priorizada. De acordo com Mulcahy (2010), mais importante que isso é a
obtenção de um panorama geral dos eventos incertos que ameaçam (ou que podem contribuir para o sucesso do projeto) e saber
discernir quais são os que merecem mais atenção e esforços do time de riscos e quais deveriam ser registrados e documentados –
como uma forma eficaz de controle sobre os eventos incertos do projeto.
Dessa forma, poderíamos garantir que o time estaria realmente desprendendo energia e trabalho naquilo que agregaria muito
mais valor aos resultados esperados pelos stakeholders .
Veja, a seguir, um modelo exemplo de matriz de riscos que pode ser utilizado para mapear os eventos incertos em seus projetos:
Tabela 5 - Modelo de Matriz de riscos

Algumas considerações ainda sobre a matriz modelo de riscos:
• Note que ela específica as combinações de probabilidade e impacto, resultando em uma classificação dos riscos (também
denominada de risk score ) como de prioridade baixa (área verde), moderada (área amarela) ou alta (área vermelha). Porém,
mantendo a escala numérica como padrão de pontuação.
• Em seu projeto você pode classificar um risco separadamente para cada objetivo (escopo, tempo, custo) ou determinar uma
classificação geral para cada risco.
• As ameaças que estão na zona de baixo risco (área verde) podem ser incluídas em uma lista de observação (também chamada
de watch list), pois ou possuem bem pouca chance de acontecer ou se ocorrerem seus impactos são na maioria das vezes
desprezíveis (gerenciáveis).
• Observe que a matriz está utilizando escalas numéricas de probabilidade e impacto diferentes das sugeridas nas tabelas 1 e 2.
Por se tratar de um modelo exemplo – portanto, perfeitamente adaptável – essa convenção e padronização deverão ser feitas
no momento em que a equipe estiver planejando e definindo as estratégias de tratamento de riscos, logo no início do
planejamento de riscos do projeto.
O ideal em relação à classificação e uso de escalas de probabilidade e impacto para a análise qualitativa dos
riscos é que você evite usar termos como ‘baixo’, ‘médio’ e ‘alto’, simplesmente. Primeiro porque se você
utilizar escalas numéricas (de 0 a 10, por exemplo) com interpretação em porcentagens intermediárias
(65%, por exemplo, de chance de um evento ocorrer), ainda que se demonstrem subjetivas podem te
proporcionar intervalos mais seguros para poder trabalhar tanto as probabilidades quanto os impactos. Em
segunda instância, pode também diminuir as chances de ambiguidades acontecerem pela interpretação
dúbia ou equivocada de alguns stakeholders com relação ao que ‘baixo’, ‘médio’ e ‘alto’ realmente representa
na classificação de riscos. Principalmente se você tiver uma lista enorme de riscos no mesmo projeto.
Fonte: Greene e Stellman (2010, p. 559).
Risk Score do projeto
Há uma frase muito interessante utilizada principalmente nos estudos sobre a Administração Científica, na qual diz que não é
possível controlar algo que não possa ser medido. Pois bem, podemos muito bem aplicar essa máxima também na gestão de riscos
em projetos. O risk score (pontuação de riscos) do projeto se apresenta como um indicador que deve ser monitorado durante todo
o ciclo de vida do projeto. Segundo Kerzner (2009), ele é obtido a partir da somatória de todos os risk scores (lembrando que
obtemos o risk score de um evento incerto multiplicando sua probabilidade pelo impacto atribuído a ele) e depois a dividindo pelo
número total de riscos identificados e analisados qualitativamente.
Para termos uma ideia melhor, segue o quadro explanatório, a seguir:
Quadro 1 – Cálculo do risk score total do projeto

Fonte: adaptado de Mulcahy (2010, p. 139).
Algumas ponderações sobre o quadro 1 e sobre o cálculo do Risk Score total do projeto:
• Se já tivermos decidido como será a convenção sobre a classificação de riscos, aqueles que têm baixo score não entram no
cálculo do Risk Score do projeto (exemplos #3 e #6 do quadro).
• Note que a sequência de riscos está classificada pelo seu número de identificação (1ª coluna) e não por seu posicionamento na
lista de riscos.
• Riscos que tratam de oportunidades têm seu risk score negativo (#7) e devem ter seu valor subtraído e não somado como
acontece com as ameaças. Porém, deve ser incluído ao número total de riscos no cálculo do Risk Score do projeto.
• O Risk Score total do projeto pode diminuir em relação à Análise Qualitativa aplicada aos eventos incertos. Isso porque após a
Análise Quantitativa (se aplicável) e a elaboração de um plano de respostas aos eventos mais críticos pode fazer com que suas
pontuações de probabilidade e impacto diminuam consideravelmente, consequentemente, seus posicionamentos na lista,
afetando o Risk Score final de maneira positiva.
• Caso o projeto tenha um Risk Score muito alto (acima de 70, por exemplo) mesmo após o processo de Análise Quantitativa e
do plano de respostas aos riscos, uma análise de Go/No-Go deve ser feita, ou seja, decisões devem ser tomadas (geralmente
pela alta administração da companhia) se há viabilidade ainda de continuar investindo no projeto ou encerrá-lo
prematuramente. Medidas de contenção (diminuição do escopo ou do grau de qualidade, por exemplo) podem ser também
tomadas no intuito de reduzir o Risk Score total do projeto, para que continue sendo viável sua finalização.
Vimos aqui os benefícios obtidos ao se criar uma lista priorizada de riscos, baseando- -se na probabilidade do evento acontecer e
no impacto que poderá causar ao projeto. Com a lista priorizada e os riscos classificados, aumentamos as chances de dar foco
naquilo que realmente agregará valor, diminuindo desperdícios de tempo e dinheiro. Aprendemos a interpretar uma matriz de
riscos e a classificar riscos também utilizando esta técnica. Estudamos ainda como calcular o risk score dos riscos, outro índice que
‘ ’
nos auxilia a dar prioridades aos riscos de acordo com seu grau de impacto no projeto versus a probabilidade de ocorrerem. Mas,
vamos seguir em frente, porque isso está ficando cada vez mais interessante!
CÁLCULO DA RESERVA DE
CONTINGÊNCIA DE PRAZOS E CUSTOS
Olá, vamos dar continuidade aos nossos estudos sobre gestão de riscos.
O tratamento de riscos em projetos muitas vezes pode gerar custos, pois as ações necessárias para responder aos riscos (ou
prevenir que aconteçam) podem incidir no orçamento do projeto devido à contratação de maquinário extra, mão de obra
qualificada, produtos substitutos, contratos, etc. Porém, qual deveria ser a porção do orçamento que deveria ser designada para
esse fim? Qual a percentagem do montante que deve ser reservada para responder aos eventos incertos? Essas e outras perguntas
serão respondidas ao longo deste estudo que trata desse cálculo com base na magnitude e na complexidade do projeto.
O valor monetário esperado em projetos
Muito bem, até aqui você aprendeu a estimar a probabilidade e o impacto de cada um dos possíveis eventos inesperados
previamente identificados – mesmo que subjetivamente, por meio inclusive da qualificação e equalização dos dados entre os
stakeholders – e a priorizar sua lista de acordo com a importância e relevância de cada evento, utilizando as técnicas e boas práticas
da Análise Qualitativa dos riscos. Mas, analisando bem, será que todos os eventos, sejam ameaças ou oportunidades, irão mesmo
acontecer? Pense bem, muito provavelmente não!
Sendo assim, mesmo possuindo uma lista priorizada dos riscos (por ordem de chances de acontecer e o impacto gerado caso
ocorra), precisamos de mais informações para conhecer em quais eventos incertos devemos realmente dar mais atenção e prover
o devido tratamento. Segundo Sbragio (2009), os impactos que mais prejudicam os projetos, independente do momento de seu
ciclo de vida, são aqueles relacionados a prazos, custos e qualidade. Os stakeholders podem se demonstrar (e com toda razão)
muito intolerantes a ameaças que causem impactos significativos nessas áreas de conhecimento, bem como apreciarem ganhos
(valores agregados) advindos de oportunidades que venham maximizar as chances de reduzir custos, garantir qualidade
satisfatória ou atingir metas arrojadas de prazos em projetos.
Utilizaremos para tanto o método de cálculo do valor monetário esperado, em Inglês Expected Monetary Value (EMV) sobre os
riscos do projeto, no qual se torna possível determinar quais seriam as prováveis circunstâncias resultantes dos eventos incertos
previamente mapeados, tanto do ponto de vista de custos como de prazos. Esse método, de acordo com Mulcahy (2010),
possibilita a vantagem do time de projetos em ter uma visão sistêmica dos riscos proporcionando oportunidades de economia
financeira, bem como o cálculo de reservas de contingência do montante orçamentário e das estimativas de prazos, relacionando-
as com a complexidade dos riscos e por consequência do próprio projeto. É um método que leva certo tempo para ser empregado
pela equipe de riscos, porém, segundo o PMI (2008), para cada hora que o time de projetos se dedica ao planejamento pode-se
evitar até dez horas de retrabalho nas atividades do projeto.
Como funciona esse método? Basicamente, analisa os custos potenciais que podem incorrer ou no impacto nos prazos pré-
estabelecidos caso ocorra uma ameaça e, em contrapartida, a potencial economia de custos e prazos caso as oportunidades sejam
maximizadas e se tornem realidade. A tabela, a seguir, exemplifica o método, de acordo com a análise de probabilidade e impacto
de cada evento previamente mapeado.
Tabela 5 – Exemplo de cálculo de valor monetário esperado

Bem, inicialmente, devemos fazer a somatória de todos os resultados dos produtos entre as probabilidades e os impactos dos
eventos mapeados. Por exemplo, para o risco #7 há uma probabilidade de 30% de ocorrer um custo extra de R$ 60.000,00 por
alguma razão que foi mapeada. Isso representa um valor de R$ 18.000 como valor monetário esperado (0,30 x 60.000 = 18.000)
para esse risco do projeto e, por se tratar de uma ameaça deve ser somado ao montante total. Para as oportunidades o raciocínio é
o mesmo, porém, são subtraídas do montante obtido (valor representado como negativo, entre parênteses), uma vez que
representam potenciais economias ao orçamento.
Você pode perceber neste exemplo que nem todos os riscos foram considerados para serem devidamente tratados com seus
devidos planos de respostas, mas sim somente aqueles que têm um valor monetário esperado acima de R$ 3.750,00. Todavia,
como boa prática de gestão de riscos, e de acordo com Mulcahy (2010), não podemos nos esquecer de documentar esses riscos
que não foram considerados em seus devidos tratamentos para que possam ser revisitados mais à frente no projeto. Outra
observação importante é que há a possibilidade de se fazer agrupamentos de riscos. Perceba que há três riscos (ameaças) relativos
à mesma atividade B, e que para a atividade C há uma oportunidade e uma ameaça associada.
Depois de fazermos todas as somas (ameaças) e subtrações (oportunidades) de todos os riscos identificados e analisados
qualitativamente, chegamos ao resultado final do EMV. No exemplo acima, o valor total é R$ 47.500. Mas, o que esse número
representa?
Se assumirmos, no exemplo, que todos os riscos do projeto que foram mapeados (note: ainda na fase de planejamento do projeto)
estão aqui representados, esse valor significa, segundo as definições de Greene e Stellman (2010), a reserva de contingência para
esse projeto calculada no momento final do planejamento. Ou seja, para que o orçamento original seja mantido, precisaremos de
uma reserva com esse montante disponível ao longo do ciclo de vida do projeto. O mesmo conceito vale para as oportunidades e
ameaças relacionadas aos prazos das atividades.
Cálculo das reservas de contingência de prazos e custos em

projetos
Para podermos compreender melhor esse método, vamos dar um exemplo a seguir com um exercício que possa refletir a realidade
e ilustrá-lo melhor:
Você é o Gerente de Projetos e está planejando a construção de um novo prédio em um dos campi de uma renomada universidade.
Suas estimativas resultaram em um orçamento de R$ 3,5 milhões e o prazo total de 224 dias. Entretanto, suas análises mais
detalhadas dos riscos (no caso, Análise Qualitativa) trouxeram as seguintes situações:
a) Uma probabilidade de 10% de que um stakeholder (patrocinador) venha a solicitar uma mudança considerável, resultando em
um custo de R$ 55.000,00 e atraso de 32 dias.
b)Uma probabilidade de 15% de que o cimento a ser utilizado na obra seja entregue no custo orçado (devido à estabilidade de
mercado, conturbado nos últimos meses), resultando em uma economia de R$ 75.000,00 e adiantamento do prazo em 28 dias.
c)Uma probabilidade de 25% de que boa parte do aço e vergalhões a serem utilizados na obra sofra uma escassez devido à falta
de matéria-prima no mercado, resultando em um custo extra de R$ 175.000,00 e um atraso de 36 dias.
d)Uma probabilidade de 20% de que a fase de acabamento possa ser mais simples do que o especificado, resultando em R$
25.000,00 de economia no projeto e adiantamento do prazo em 14 dias.
e) Uma probabilidade de 60% de que haja um defeito de especificação técnica no projeto de arquitetura, o que poderá causar
cerca de R$ 95.000,00 de retrabalho e um atraso de 40 dias.
Observação: Note que se faz necessária a interpretação do evento incerto para que identifiquemos de que se trata de uma ameaça
ou de uma oportunidade para o projeto. No exercício anterior, algumas palavras-chave foram grifadas para auxiliar na
identificação.
Pois bem, de acordo com a análise feita, qual seria o Valor Monetário Esperado de custos e de prazos destas ameaças e
oportunidades? Vamos analisar o seguinte quadro:
*) Para efeito de cálculos, a fração foi mantida. Porém, podemos considerar nesse caso um EMV de prazos de 30 dias.

Existem algumas maneiras de se apresentar as reservas de contingência, principalmente de custos em
projetos. Você pode simplesmente aplicar um percentual aleatório (10%, por exemplo) em relação ao
orçamento total do projeto. Essa prática pode te prover uma reserva financeira, mas será difícil de defendê-
la perante a alta administração, simplesmente por não ser suportada por nenhum método. Não seria mais
interessante defender uma reserva de aproximadamente 2,6% (percentual do EMV sobre o orçamento
original) apresentando tais argumentos descritos no nosso exercício exemplo para a alta administração?
Ainda sobre o exemplo do quadro anterior, outras análises podem ser feitas para a compreensão da importância do uso do cálculo
de EMV de custos e prazos. Se assumirmos que estes seriam os únicos riscos deste projeto, podemos observar:
a)Qual seria o melhor caso de custos e prazos (se somente as oportunidades acontecessem?). R$ 3.500.000,00 – 75.000,00 –
25.000,00 = R$ 3.400.000,00 224 – 28 – 14 = 182 dias
Neste caso, deveríamos considerar que a gestão de riscos foi tão eficaz que todas as ameaças foram eliminadas e os esforços
proporcionaram que as oportunidades acontecessem. Note que o time de riscos ao criar meios para que as oportunidades
acontecessem, suas probabilidades foram elevadas a 100% (não mais a 15% e 20% respectivamente). Como as oportunidades
representavam economias de 75 mil e 25 mil e antecipação de 28 dias e 14 dias de maneira respectiva, foi feita uma economia de
R$ 100.000,00 e uma antecipação de prazo de 42 dias devido à eficácia da gestão de riscos.
a)Sem que nenhuma análise detalhada fosse feita, qual seria o valor total do projeto segundo as expectativas dos
patrocinadores do projeto? R$ 3.500.000,00 e 224 dias
Imagine que na apresentação do projeto fossem divulgados esse valor e prazo de finalização do projeto aos patrocinadores e
demais stakeholders. Se esse tipo de análise não fosse feita, a expectativa de gastos e de tempo seriam as que tivessem sido
divulgadas no início do projeto.
a) Qual é o EMV do projeto?

R$ 90.000,00 (soma e subtração dos valores calculados de acordo com a probabilidade e impacto de cada evento incerto do
projeto). ~30 dias (soma e subtração dos dias calculados de acordo com a probabilidade e impacto de cada evento incerto do
projeto).
Estas seriam as reservas de contingência de prazos e custos calculados de acordo com os riscos identificados e analisados do
projeto. Ou seja, seria necessário manter esse montante disponível (além do orçamento original) para que os riscos fossem
devidamente tratados e a reserva de custo cobriria esses gastos. O mesmo conceito se aplica para os prazos, uma reserva de 30
dias deveria ser contemplada no cronograma do projeto para cobrir o tratamento dos eventos incertos pela equipe do projeto,
proporcionando assim o cumprimento dos prazos previamente estabelecidos.
a)Qual seria o pior caso de custos e prazo (se somente as ameaças acontecessem?).
3.500.000,00 + 55.000,00 + 175.000,00 + 95.000,00 = R$ 3.825.000,00 224 + 32 + 36 + 40 = 332 dias
Aqui, podemos compreender que nada foi feito. Ou seja, não houve a devida e justa preocupação com os riscos do projeto nem por
parte da equipe, do gerente do projeto ou de qualquer outro stakeholder Note que se as ameaças não forem devidamente tratadas
.
suas respectivas probabilidades elevam-se a 100%, ocasionando o impacto inicialmente previsto. No nosso exemplo, as ameaças
representam 55 mil, 175 mil e 95 mil, além dos atrasos de 32, 36 e 40 dias, respectivamente. Neste caso, tivemos o orçamento
original excedido em 325 mil e o prazo final postergado em 108 dias (contando os dias úteis de trabalho, em meses isso
representaria algo em torno de cinco meses e meio!).
O método EMV auxilia o Gerente de Projetos e sua equipe a coletar dados a respeito dos custos e prazos e
os riscos inerentes às atividades, baseando- -se na complexidade e grau não só do risco, mas do projeto
como um todo. É importante ressaltar que esses dados devem servir como uma base para argumentação e
negociação com os patrocinadores do projeto, demonstrando que houve um método aplicado e que as
informações provenientes do método, apesar de um tanto quanto subjetivas, não foram adquiridas de
forma empírica (tentativa e erro). Pode ser utilizado com uma ótima fonte de informação para que a alta
administração possa tomar decisões tendo como base as argumentações apresentadas pelo método. Jamais
deve ser encarada como a famosa ‘gordura’ e/ou utilizada para encobrir deficiências, atrasos e
principalmente retrabalhos nas atividades do projeto! Fonte: o autor.
O método do cálculo de EMV nos projetos, segundo Dinsmore e Cabanis-Brewin (2009), visa à economia no orçamento e o
atendimento dos prazos pré-estabelecidos durante a fase de planejamento do projeto. Obviamente que esse método é aplicado no
final da fase de planejamento, quando os riscos foram identificados e analisados antes (ou no início) da fase de execução. Portanto,
o método precisa ser revisitado ao longo do ciclo de vida para que os valores possam ser reajustados frente aos novos riscos que
vão surgindo.
Mas, o ponto mais interessante que devemos ressaltar aqui é que o método nos dá uma visão panorâmica do projeto no momento
de maior visibilidade por parte dos stakeholders Note que as previsões de prazos e custos não são determinísticas, e sim
.
estimativas que culminaram nesses valores por meio de técnicas e boas práticas. O importante é denotar que, por se tratar de uma
ciência inexata e repleta de incertezas, a mensagem que deveria ser percebida é que o projeto, no nosso exemplo, poderia custar
algo entre R$ 3.400.000,00 e R$ 3.825.000,00. Imagine que por conta de uma estratégia da alta administração da empresa haja
uma restrição na qual o projeto não possa custar mais do que R$ 3.600.000,00 ou não ultrapassar 240 dias úteis de projeto. A
análise que foi feita no exercício nos mostra que se nada a respeito dos riscos for feito de maneira séria e profissional essas
restrições se tornam totalmente irreais.
Seria necessário contra argumentar com a alta administração em relação a tais restrições, obviamente que posteriormente à
realização das análises por meio do método EMV e, os dados obtidos após a aplicação do método poderiam ser utilizados como
argumentação para demonstrar que certas restrições podem ser assumidas de maneira mais segura e realística.
Além das reservas de contingência de prazos e custos, devemos ainda contemplar no projeto as Reservas
Gerenciais. Mas, o que as difere, afinal? Reservas de contingência são calculadas por meio do método EMV
e se referem aos riscos desconhecidos conhecidos, ou seja, aqueles identificados e tratados pela equipe de
riscos e outros stakeholders. Já as reservas gerenciais se referem aos riscos desconhecidos, ou seja, aqueles
tão absurdos (muitas vezes trágicos) que não seria possível prevê-los ou mapeá-los durante os processos da
Gestão de Riscos. Podemos tomar como exemplo, o evento das torres gêmeas, em New York do episódio
conhecido como Onze de Setembro de 2001. Imagine que uma empresa tivesse uma filial em uma das
torres, isso provavelmente não estaria no plano de riscos. Ou ainda, imagine você outro exemplo, um
aumento irrefreável na cotação do dólar em um projeto no Brasil baseado nessa moeda. Portanto, para que
seja possível recuperar parte ou a totalidade de um projeto, fatalmente será necessário utilizar as Reservas
Gerenciais – um montante que a alta administração da companhia empregará para sustentar o projeto
(desde que viável) e permitir sua continuidade. Em ambos os casos, se houver necessidade de utilizar um
valor parcial ou o total das reservas, o Gerente de Projetos deverá prestar contas sobre seu emprego. Caso
contrário, os montantes serão devolvidos (parcial ou total) no encerramento do projeto. Fonte: Maximiamo
(2014).
Fechamos aqui esse conteúdo conhecendo os cálculos da reserva de contingência a ser utilizada nos planos de respostas aos
riscos, utilizando o método do valor monetário esperado. Compreendemos que estas reservas, tanto de prazos quanto de custos,
são provenientes da análise mais aprofundada dos riscos e que o montante a ser requisitado será proporcional ao grau de
complexidade do projeto e não mais de forma aleatória e difícil de ser defendida. Espero que as informações apresentadas até aqui
tenham agregado valor ao seu conhecimento. E vamos prosseguindo, pois há bastante informação interessante mais à frente.
TÉCNICAS DE MODELAGEM E ANÁLISE
QUANTITATIVA DOS RISCOS
Olá, caro(a) aluno(a). Até aqui já compreendemos os conceitos sobre a qualificação de dados, testes de premissas, classificação e
priorização dos riscos e cálculos de reservas de contingência. Vamos nos aprofundar um pouco mais na análise quantitativa agora.
O principal intuito da Análise Quantitativa é deixarmos de ser um tanto quanto subjetivo nas análises de probabilidade e impacto
em relação às Análises Qualitativas dos riscos. Nesse tipo de análise devemos procurar ser mais numéricos. Para termos uma ideia,
seria como ao invés de atribuirmos uma chance igual a 2 na escala, atribuirmos uma chance de 40% de alguma ameaça ou
oportunidade ocorrer. Ou ainda atribuirmos ao impacto algo como 3 semanas de atraso ou R$ 100.000,00 de custos extras ao
invés de designar, de maneira subjetiva, o grau 5 em uma escala de impacto. Porém, perceberemos que nem para todos os riscos
esse tipo de análise necessita ser realizada.
A análise quantitativa de riscos

podemos iniciar a compreensão dos processos da Análise Quantitativa de riscos falando sobre a Análise Qualitativa de riscos.
Nessa última, trabalhamos com uma lista de potenciais riscos (ameaças e oportunidades) já identificados e atribuímos a cada um
deles uma pontuação – subjetiva sim, porém com a preocupação da qualificação dos dados e nivelamento de informações entre os
stakeholders – baseada em escalas simples de probabilidade e impacto. Nesse ínterim, de acordo com Greene e Stellman (2010),
devemos tomar a decisão se será necessário analisar com mais profundidade não todos, mas determinados riscos, geralmente
aqueles que são mais impactantes se acontecerem e têm maiores chances de ocorrer ao longo do ciclo de vida do projeto.
Devemos aqui compreender que os riscos no projeto não têm um comportamento linear, ou seja, não irão todos acontecer e muito
menos na sequência e intensidade definidas pela equipe.
De fato, muitos riscos interagem entre si ou em grupos tornando alguns muito mais prováveis e outros simplesmente impossíveis
de acontecer. Dinsmore e CabanisBrewin (2009) afirmam que a análise quantitativa tem o propósito de ‘olhar’ para cada risco de
maneira individual, além de compreender interações entre eles, analisando inclusive tendências e efeitos combinados que podem
interferir ainda mais nos resultados esperados. Para tanto, muitos modelos matemáticos e estatísticos (que muitas vezes se
apresentam como Software de computadores) estão disponíveis para auxiliar nesse tipo de análise mais aprofundada.
Portanto, segundo Mulcahy (2010), executar a análise quantitativa muitas vezes requer investimentos tanto de tempo como de
dinheiro, seja na aquisição de programas específicos e licenciados de computador ou no treinamento de pessoas para utilização
dessas ferramentas. Você, como Gerente de Projetos e suportado por sua equipe, deverá tomar a decisão de realizar ou não essa
análise e em qual proporção dos riscos do projeto. Um meio para tomar essa decisão é avaliar inicialmente o esforço que será
aplicado frente às necessidades do projeto. Aqueles mais complexos, com longa duração e com diversas decisões difíceis a serem
tomadas deveriam passar pela análise quantitativa dos riscos elegíveis aos seus processos.
Já os de curta duração, com menor importância para a companhia e com menor grau de complexidade podem ter seus riscos muito
bem gerenciados e tratados executando apenas os processos da análise qualitativa.
Você e sua equipe podem julgar quais riscos identificados e analisados qualitativamente devem passar pelos processos da análise
quantitativa, baseando-se na sua experiência e da sua equipe, além de ter a chance de poder consultar o histórico de outros
projetos para poderem tomar tal decisão. Entretanto, seguem, a seguir, algumas dicas e informações complementares que podem
lhes auxiliar na decisão se devem ou não executar os processos da análise quantitativa:
• Identifique quais riscos da sua lista que já tiveram a probabilidade de acontecerem – ou o impacto caso aconteça – reduzidos
após executar os processos da análise qualitativa.
• Identifique o Risk Score do projeto (mencionado na aula 2 deste estudo) e verifique com a companhia/cliente se o projeto
está em um nível aceitável de risco, ou seja, se os riscos mapeados estão dentro de um padrão esperado com relação ao produto
ou serviço específico resultado do projeto.
• Identifique quais riscos não foram eliminados – ou tiveram sua probabilidade e/ou impacto reduzidos – e requerem
tratamento específico relacionado a um plano de respostas de riscos.
• Identifique (faça uma simulação) junto a sua equipe quanto tempo durará e quanto o projeto custará se a análise quantitativa
não for executada e nenhuma outra iniciativa de reduzir os riscos for tomada. Caso estes índices estejam satisfatórios é um
bom indício de que seu projeto está, neste momento, sob controle.
Qualquer que seja a decisão tomada por você e por sua equipe tome sempre o cuidado de manter o seu
repositório de registro de riscos o mais atualizado possível. Nunca se sabe quais e quando serão as decisões
a serem tomadas. Afinal, tornar-se refém de dados desatualizados ou inexistentes está muito longe de ser
uma boa prática de gestão de riscos, não acha?
Abordaremos, a partir de agora duas das principais técnicas mais empregadas em análise quantitativa de projetos complexos. São
elas a árvore de decisão e a análise de Monte Carlo.
A técnica da árvore de decisão aplicada como análise quantitativa
de riscos
A técnica da árvore de decisão te conduzirá a um processo de análise de alternativas e/ou cenários distintos e as consequências
associadas a qual alternativa (caminho) você e sua equipe decidir tomar. Geralmente, o modelo trata da dimensão de custos
(podendo também ser adaptado para prazos e qualidade) e a obtenção do maior valor agregado esperado. Alguns modelos
apresentam informações para a tomada de decisão sobre custos (ou outra dimensão) apenas no final das ‘ramificações’ da árvore,
outros podem apresentar essas informações já no meio da árvore.
Segundo Damodaran (2009), as árvores de decisão são geralmente utilizadas em cenários discretos, ou seja, quando o período de
avaliação é relativamente curto e quando a recorrência do evento não se apresenta como algo significativo. São compostas por nós
(nodes), sendo estes os nós raiz, nós de decisão, nós de eventos e nós de fim. Classificam-se na estrutura da árvore como segue a
descrição:
• O nó raiz representa o elemento no qual o tomador de decisão se encontrará diante de uma decisão sobre a solução de um
problema ou de um resultado incerto.
• Os nós de evento são as ramificações do início da árvore e simbolizam as possibilidades dos desfechos, demonstram as
possibilidades de escolhas a serem feitas pelo tomador de decisão.
• Os nós de decisão representam efetivamente as escolhas que o tomador de decisão poderá tomar, baseando-se em
informações pertinentes a cada tipo de escolha a ser tomada, bem como suas respectivas consequências.
• O nós de fim demonstram os desfechos finais de acordo com as escolhas feitas e relativos aos desfechos previamente
ocorridos.
Damodaran (2009), afirma que seriam inúmeras as vantagens de se utilizar esse modelo para análises de riscos. Uma delas seria a
obtenção de respostas dinâmicas aos riscos, pois vincula ações e escolhas aos desfechos da análise dos eventos incertos. Os
valores obtidos por meio das informações pertinentes aos nós de evento também seria uma vantagem significativa, pois se
vislumbram novas perspectivas a cada nova escolha presentes em suas ramificações.
As árvores de decisão se demonstram flexíveis e como uma ferramenta poderosa de análise de riscos, uma vez que lidamos com
estes riscos por etapas, nas quais as decisões para cada uma delas dependem do desfecho das escolhas anteriores. Uma possível
desvantagem seria a aplicabilidade de tal modelo para cenários regularmente discretos com eventos dicotômicos (divisão de um
evento em duas probabilidades distintas), dificultando seu uso em cenários contínuos e sequenciais, aos quais seriam necessárias
mais variáveis para se tomar uma única decisão (ou escolha).
Porém, de acordo com Sbragio (2009), qualquer que seja o modelo aplicado, o intuito sempre será a simulação de eventos futuros
quando tomamos as decisões no presente. Deveria ser aplicado para situações mais complexas de cálculo de valor monetário
esperado, inclusive em relação ao método EMV apresentado anteriormente. Outra característica importante é que esse modelo
trabalha com a máxima da exclusividade mútua, ou seja, dois eventos em julgamento não podem acontecer ambos ao mesmo
tempo. Podemos tomar como um simples exemplo a escolha de um roteiro de viagem de turismo: podemos ir para a Europa ou para
a Austrália escolhendo até para qual destino iremos primeiro, mas nunca para os dois lugares ao mesmo tempo.
Para podermos compreender melhor esse modelo trabalharemos com um exercício prático simulando uma situação real de
tomada de decisão, analisando cada passo dado.
Uma empresa do setor industrial de transformação precisa definir qual o melhor processo de produção a ser aplicado em um novo
produto cujo preço final no mercado será praticado a R$ 10.000,00 (dez mil reais). A área de manufatura junto ao departamento
financeiro levantou as informações de que pelo processo ‘A’ o produto teria como custo unitário o valor de R$ 1.200,00 e junto ao
departamento de Qualidade foi levantado que a probabilidade de sucesso seria de 90%. Para o processo ‘B’, teria um custo unitário
de R$ 700,00 e a probabilidade de sucesso de 80%.
O primeiro passo para desenvolvermos uma solução é desenhar a árvore de decisão com os dados da empresa, como segue na
figura 1:
Figura 1 - Desenho da árvore de decisão
Fonte: adaptado de Sbragio (2009).
O próximo passo é identificar as probabilidades de cada processo e o retorno esperado de cada evento, ainda de acordo com os
dados levantados pela empresa, como demonstra a figura 2:
Figura 2 - Árvore de decisão com os dados da empresa
Para chegar aos valores finais simplesmente multiplicamos a percentagem da chance de cada processo pelo valo final do produto,
se aprovado. Os valores obtidos para os produtos reprovados representam o complemento do valor de cada processo.
Uma vez determinados os dados da empresa na árvore de decisão, calculamos o valor esperado (VE) de cada decisão tomada, de
acordo com os dados dispostos. A figura 3 demonstra os resultados dos cálculos:
Figura 3 - Cálculo do valor esperado (VE) de cada decisão a ser tomada
Como chegamos aos cálculos dos valores esperados referentes a cada decisão sobre qual processo de produção a ser aplicado?
Bem, muito parecido com o cálculo de EMV abordado anteriormente.
Para o processo ‘A’:

Calculamos as oportunidades (produto aprovado) e ameaças (produto reprovado) de acordo com sua probabilidade e impacto e
chegamos ao resultado do valor esperado, utilizando o mesmo conceito do EMV – oportunidades evitam custos e ameaças geram
custos. Nesse caso, teríamos:
Para o processo ‘B’, utilizamos o mesmo conceito:
Note que inicialmente o valor esperado se apresenta mais atrativo no processo ‘B’ (R$ 9.300,00). Ao realizarmos a análise da
probabilidade versus o potencial impacto causado em ambos, o processo ‘A’ passa a ser o mais atrativo ao final da análise (R$
7.800,00 ao invés de R$ 7.300,00). Se uma análise mais aprofundada não tivesse sido realizada, muito provavelmente a empresa
tomaria a decisão não mais lucrativa na escolha do processo produtivo. Obviamente que outros fatores, se pertinentes, deveriam
ser incluídos como dados da empresa para a tomada de decisão. O efeito colateral disso é que a árvore de decisão vai ficando cada
vez mais complexa, com outros ‘ramos’ adicionados na sua estrutura hierárquica.
Em alguns modelos de árvore de decisão os custos incorridos aparecem somente no final de sua estrutura,
enquanto em outros modelos eles podem aparecer no meio ou até no início. Como o intuito dessa
ferramenta é estruturar todas as possibilidades para se resolver um problema (ou o impacto de um risco), os
custos e pesos podem aparecer em qualquer parte de sua estrutura, e não somente no final.
Fonte: Mulcahy (2010).
A análise de monte carlo
Você já deve ter ouvido em algum noticiário ou telejornal durante as campanhas eleitorais que o candidato X tem, por exemplo,
45% de intenção de votos com margem de erro de dois pontos percentuais. Isso significa que, de acordo com as pesquisas
realizadas a probabilidade de votos que o candidato receberá está entre 43% ou 47% do eleitorado, segundo as estimativas dos
especialistas em Estatística. Pois bem, segundo Dinsmore e Cabanis-Brewin (2009), a técnica de análise Monte Carlo é a
ferramenta quantitativa mais famosa e disseminada de análise de riscos, utilizando modelos matemáticos e estatísticos para isso.
Historicamente, essa técnica foi desenvolvida e utilizada inicialmente pelos cientistas que eram responsáveis pelos projetos da
bomba atômica durante a Segunda Guerra Mundial, e foi batizada com esse nome por causa da cidade de Mônaco na Itália e seus
cassinos na época.
Esse método trabalha com a construção de modelos matemáticos que simulam, de acordo com os dados de entrada, os possíveis
resultados utilizando para isso uma distribuição de probabilidades. Ou seja, não se trata de uma análise determinística, na qual se
você fosse perguntado qual seria a chance de algo acontecer e pudesse responder algo como ‘sete’ em uma escala de zero a dez. De
acordo com Mulcahy (2010), para termos uma ideia de como funciona o método, seria você respondendo algo como ‘há uma
chance de 20% de que o impacto de custo seja de R$ 3.000,00, uma chance de 30% de que o impacto seja de R$ 5.000,00 e etc.’. Só
que para que isso seja possível de responder teríamos que fazer uso deste modelo matemático e probabilístico, que na maioria das
vezes é representado e calculado por software de computadores específicos para essa finalidade.
Vamos utilizar aqui um exemplo para deixar mais claro como funciona o método. Imagine que você é o gerente de projetos em uma
companhia e pergunta a um dos membros de seu time quanto tempo durará determinada atividade sob a responsabilidade dele.
Ele pode responder ’80 horas’, demonstrando segurança ao afirmar tal estimativa. Acontece que em projetos, por se tratar
exclusivamente de estimativas que geram incertezas, não é possível ser tão preciso assim. Pois bem, usando uma boa prática de
gestão de prazos, você pede a ele que lhe dê uma estimativa de três pontos representada por uma pessimista, uma otimista e uma
terceira mais provável. Ele, conhecendo a boa prática lhe apresenta como otimista 70 horas, 100 horas como pessimista e mantém
como 80 a mais provável. Vamos representar essas estimativas em um plano cartesiano para uma compreensão mais visual, como
segue na figura 4:
Figura 4 - Representação gráfica da estimativa de três pontos

Como podemos observar no gráfico, há uma probabilidade da atividade ser executada e finalizada a qualquer momento entre 70 e
100 horas. Mas, se você prestar atenção verá que há um intervalo de probabilidades, não apenas três estimativas distintas. Isso
sugere um grau de incerteza considerável, pois o intervalo é muito grande. A propósito, quanto maior o intervalo entre as
extremidades, maior será o grau de incerteza e, provavelmente, de maior grau será o risco dessa atividade. Se multiplicarmos esse
conceito para várias atividades do projeto o seu grau de risco será gradativa e proporcionalmente maior. Nesse ínterim, a Análise
de Monte Carlo é utilizada, principalmente para realizar o cálculo de possíveis impactos no projeto, por meio de uma simulação. De
acordo com Greene e Stellman (2010), para executar esse tipo de simulação você deverá utilizar inevitavelmente um programa de
computador específico para isso.
O software de computador acumulará todas as informações referentes às estimativas de prazo de todas as atividades do projeto e
processará esses dados por meio de um número enorme de iterações, da ordem de milhares de vezes em muitos casos. Cada
iteração – ou repetição da simulação – devolverá um resultado diferente, até que encontre uma possibilidade mais provável de
finalização das atividades em conjunto, consequentemente, do cronograma do projeto. O mesmo conceito se aplica para as
estimativas de custos do projeto.
O principal objetivo da execução da simulação de Monte Carlo é obter informações, como as citadas, a seguir:
• O grau de probabilidade de que o projeto finalize na data planejada.
• O grau de probabilidade de que o projeto seja completado com o orçamento previamente dimensionado.
O programa de computador ainda pode lhe prover o grau de confiabilidade de suas simulações para que decisões possam ser
tomadas pelos patrocinadores do projeto. Podemos tomar como exemplo um resultado do software que assegura após as
simulações que o cronograma do projeto tem 65% de chances de ser completado na data especificada. Esse é um grau de certeza
muito baixo e poucas empresas arriscariam prosseguir com o projeto nessas condições. Se a data do projeto não puder ser
prorrogada, o plano de gerenciamento de riscos deve ser revisado para auxiliar na redução do prazo total do projeto. Então, novas
simulações do programa de computador deverão ser realizadas para identificar se a probabilidade do projeto ser completado na
data especificada aumentou e se tornou mais factível. Novamente, o mesmo conceito se aplica aos custos do projeto.
Por essa razão, e segundo Dinsmore e Cooke-Davies (2006), a Análise Quantitativa muitas vezes se apresenta como dispendiosa,
pois essas simulações levam um tempo considerável e o ajuste no plano de riscos pode levar mais tempo ainda e custar muito
dinheiro. Como vimos que é necessário avaliar muito bem a necessidade de se realizar a Análise Quantitativa de riscos nos
projetos. Isso dependerá muito do grau de complexidade e incertezas que há no projeto, sua magnitude e extensão, além do
montante empregado e outros fatores determinantes na decisão.
É importante que você note, porém, que com os dados obtidos por meio desse tipo aprofundado de análise você poderá obter
argumentos para demonstrar à alta administração da empresa ou aos patrocinadores que a data ou os custos desejados para o
projeto são realmente infactíveis.
O gerente de projetos e sua equipe devem estar preparados para lidar com os dados e informações
provenientes da Análise Quantitativa de riscos, pois independente do método empregado não será
proporcionado ao gerente ou a equipe qual a melhor decisão a ser tomada. Além disso, conduzir os
processos da Análise Quantitativa requer investimentos em tempo e dinheiro, e até mesmo sua
aplicabilidade é muito questionada em projetos de menor complexidade (de acordo com a classificação do
Risk Score do projeto).
Fonte: o autor.
Encerramos aqui nosso conteúdo especificando com mais precisão os conceitos sobre a análise quantitativa dos riscos em
projetos. Apresentamos e discutimos duas ferramentas importantes aplicadas às análises quantitativas, a árvore de decisões e a
análise de Monte Carlo, ambas baseadas em preceitos da estatística aplicada. Estas ferramentas quando bem aplicadas podem
proporcionar uma grau maior de confiabilidade, inclusive para se tomar decisões de continuar ou não com o projeto, devido sua
alta complexidade e alto grau de risco.
Esperamos 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 sinceramente que este conteúdo possa ter contribuído com os seus estudos e aprendizado.
Avançar

ATIVIDADES
1. Assinale a opção que não contém uma premissa de projeto:
a)A lista corporativa de fornecedores pré-habilitados possui, no mínimo, três fornecedores que já trabalharam com a
tecnologia a ser usada no projeto.
b) O acesso físico ao local da obra será disponibilizado para a plena realização das atividades.
c) O projeto precisa estar pronto até o final de junho.
d) Não haverá desvalorização do câmbio do real em relação ao dólar maior que 10% entre janeiro e outubro.
e)O time interno da empresa contratante deverá prestar suporte às atividades chaves do projeto durante seu
desenvolvimento.
2. A MELHOR definição de gerenciamento de riscos é:
a) O processo de envolver e comprometer os componentes-chaves para uma identificação de riscos mais eficaz.
b) O processo de garantir proativamente que todos os riscos do projeto estão documentados e controlados.
c) Criação do registro dos riscos.
d) O processo de identificar, analisar e responder aos riscos.
e) O processo de redução do risco ao mínimo nível possível para o projeto.
3.Durante o processo de análise prévia de uma lista de riscos identificados, um dos potenciais riscos recebeu baixa pontuação e
provocou questionamentos entre os membros do time de riscos. O que o Gerente de Projetos deveria fazer?
a) Executar os testes de estabilidade das premissas do projeto
b) Aplicar uma sessão completa de brainstorm ao time de riscos
c) Equalizar a compreensão sobre o risco entre os stakeholders

d) Não incluir este risco no processo de análise prévia dos riscos
e) Continuar com o projeto e resolver este problema, se ocorrer, um pouco mais tarde no ciclo de vida do projeto.
4. Você é o gerente de projetos de uma empresa que tem como cliente uma indústria do setor siderúrgico. Você está no meio da
execução do projeto, que deve cumprir um contrato de grandes proporções. O departamento jurídico da sua empresa lhe informa
que um dos fornecedores do projeto – do qual você depende, sofreu um grande pênalti e perdeu o contrato de fornecimento de
uma etapa crítica do projeto. Ao consultar seu plano de riscos você descobre que nem você e nem seu time se prepararam para
essa situação. Qual seria então a MELHOR forma de lidar com essa situação?
a) Recomendar ações preventivas ao time do projeto.
b) Providenciar a contratação de um novo fornecedor qualificado.
c) Aplicar a análise qualitativa para esse evento.
d) Consultar a matriz de riscos, identificando a probabilidade e o impacto causado.
e) Escalar esse problema para a alta administração da empresa.
5. Assinale V (verdadeiro) ou F (falso) nas sentenças a respeito da Análise Qualitativa de Riscos em projetos:
( )Risk Score é um valor numérico de um risco calculado por meio do produto entre probabilidade e impacto atribuídos
subjetivamente.
( )Qualificação dos dados se dá quando há uma compreensão nivelada das informações por parte dos stakeholders do projeto.
( )Classificação dos riscos seria a priorização dos riscos baseando-se no risk score de cada risco.
( )Escalas de probabilidade e impacto são utilizadas para determinar a estabilidade e validade das premissas do projeto, fontes
potenciais de ameaças se não forem bem gerenciadas.
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 dos seguintes procedimentos, a seguir, aumentaria as chances de riscos, caso o gerente de projetos o fizesse (ou não o
fizesse)?
a) Manter-se envolvido nas negociações de contratos.
b) Não se envolver nos processos de contratações de fornecedores do projeto.
c) Procurar por novos riscos baseando-se nas suas próprias experiências.
d) Fazer uso de ferramentas de software para gerenciar eventos incertos.
e) Não aplicar técnicas de resolução de conflitos constantemente.

7. Você, como um ótimo Gerente de Projetos, durante o planejamento de riscos calculou as reservas de contingência de custos
utilizando o método de cálculo pelo EMV.
Entretanto, um dos patrocinadores observou esse montante ‘extra’ no orçamento e simplesmente o retirou do plano de custos por
achar que se tratava de ‘gordura’ sem nenhuma base de sustentação. O que você deveria fazer nesse momento?
a) Dar andamento no projeto mesmo sem a reserva de contingência de custos.
b)Convocar uma reunião extraordinária com seu time e definir uma estratégia para conduzir o projeto sem a reserva de
contingência de custos.
c) Descobrir uma maneira de incluir e ‘esconder’ a reserva de contingência de custos distribuindo-a nas atividades do projeto.
d) Explicar ao stakeholder o método EMV e a forma de calcular a reserva de contingência, utilizando os dados gerados como
base para a argumentação e obter a aprovação da reserva.
e)Escalar o problema no intuito de identificar um stakeholder com maior poder de decisão para aprovar a reserva de
contingência inicial de custos.
8. Qual a principal diferença entre reservas de contingência e reservas gerenciais:
a) Reservas gerenciais são aplicadas para os riscos desconhecidos desconhecidos, enquanto que as reservas de contingências
são para lidar com riscos desconhecidos conhecidos.
b) Reservas gerenciais são utilizadas para lidar com riscos desconhecidos conhecidos, e as reservas de contingência lidam com
os riscos desconhecidos desconhecidos.
c) Ambas são utilizadas para lidar tanto com riscos desconhecidos desconhecidos como com riscos desconhecidos conhecidos.
d)Reservas gerenciais são utilizadas para lidar com riscos de alta severidade, enquanto que as reservas de contingência lidam
com riscos de baixa complexidade.
e) Reservas gerenciais são utilizadas para lidar com riscos de baixa complexidade, enquanto que as reservas de contingência
lidam com riscos de alta severidade.
9. Você é o gerente de projetos de um projeto de readequação de uma linha de montagem de eletrodomésticos. Após análises dos
riscos, sua equipe chegou à conclusão de que há 30% de chance de aumento de R$20.000,00 de um equipamento a ser utilizado,
antes que você possa emitir o pedido de compra. Isso ainda poderá gerar 15 dias de atraso, para poder obter a aprovação de
comprá-lo. Há ainda 25% de chance de sua empresa ter que pagar R$150.000,00 por uma apólice de seguros de outro
equipamento importado, porque seu fornecedor não emite apólices para casos de importação. Por conta do fornecedor não poder
emitir a apólice, ele irá te oferecer um desconto de R$20.000,00 no preço final do equipamento. Qual é o valor monetário
esperado para esse risco?
a) R$15.500,00
b) R$210.000,00
c) R$38.500,00
d) R$14.500,00
e) R$21.200,00
10. Assinale, a seguir, dentre as sentenças, qual delas não seria uma declaração correta:
( O Gerente de Projetos
) e sua equipe deveria ter completado as etapas de definição de escopo do projeto antes de iniciar o
plano de gestão de riscos.
( ) A avaliação numérica dos riscos é a parte mais importante do gerenciamento de riscos.

( ) Você deveria realizar os processo da Análise Qualitativa dos riscos antes de realizar os processos da Análise Quantitativa.
( Os patrocinadores do projeto não deveriam se envolver com questões relacionadas ao plano de gestão de riscos do
)
projeto.
( ) Os resultados da Gestão de Riscos podem ser utilizados para se tomar a decisão de continuar ou não com o projeto.
11. Qual ferramenta de análise de riscos pode ser utilizada para elaborar um modelo de seus riscos por meio de simulações que
calculam diferentes resultados e grau de probabilidades?
a) Árvore de decisão
b) Diagrama de Ishikawa
c) Análise de Monte Carlo
d) Análise de Probabilidade e Impacto
e) Análise de Valor Monetário Esperado
12. A classificação de riscos do projeto ocorre em qual dos processos, a seguir?
a) Planejamento de Riscos do projeto
b) Realizar a Análise Qualitativa de riscos
c) Processo de Identificação dos riscos
d) Realizar a Análise Quantitativa de Riscos
e) Qualificação dos dados e nivelamento das informações aos stakeholders.
1. c) O projeto precisa estar pronto até o final de junho.
2. d) O processo de identificar, analisar e responder aos riscos.
3. c) Equalizar a compreensão sobre o risco entre os stakeholders
4. b) Providenciar a contratação de um novo fornecedor qualificado.
5. d) V, V, V, F
6. b) Não se envolver nos processos de contratações de fornecedores do projeto.
7. d)Explicar ao stakeholder o método EMV e a forma de calcular a reserva de contingência, utilizando os dados gerados como
base para a argumentação e obter a aprovação da reserva.
8. a)Reservas gerenciais são aplicadas para os riscos desconhecidos desconhecidos, enquanto que as reservas de contingências
são para lidar com riscos desconhecidos conhecidos.
9. c) R$38.500,00
10. b) A avaliação numérica dos riscos é a parte mais importante do gerenciamento de riscos.
11. c) Análise de Monte Carlo
12. b) Realizar a Análise Qualitativa de riscos
Avançar

RESUMO
Ao final desta unidade, compreendemos a importância da qualificação dos dados e a preocupação com o nivelamento das
informações entre os stakeholders principalmente para garantirmos que as pontuações de probabilidade e impacto dos riscos não
,
sejam tão divergentes. Observamos a necessidade dos testes das premissas quanto a sua estabilidade e veracidade, pois se não
bem gerenciadas acabam por tornarem-se ameaças iminentes ao projeto. Percebemos que nem todos os eventos incertos
acontecerão no projeto e que se acontecerem não obedecerão a um padrão linear de ocorrência. Daí a importância de obtermos
uma lista priorizada de riscos por meio dos processos da Análise Qualitativa, justamente para conhecermos em quais riscos
devemos concentrar nosso esforços, gerando dessa maneira uma sinergia e eficácia na gestão e tratamento dos eventos incertos
mais significativos.
Aprendemos a como calcular de maneira mais acurada – e de acordo com a magnitude, duração e grau de complexidade dos riscos
– as reservas de contingência de prazos e custos, que serão muitas vezes utilizadas para o próprio e devido tratamento dos riscos
do projeto, uma vez que muitos deles podem gerar custos e levar certo tempo para serem trabalhados de forma adequada.
Vimos que existem algumas ferramentas e técnicas muito eficazes e pertinentes aos processos da Análise Quantitativa dos riscos,
que podem prover informações cruciais para a tomada de decisões complexas no projeto. Porém, como tudo tem seu preço, a
decisão também de se realizar ou não esse tipo de análise mais aprofundada dependerá de fatores relacionados aos prazos e
custos do projeto, sem que comprometam a qualidade planejada, recursos estes que na maioria das vezes são escassos e limitados
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. Experimentem
explorar os materiais complementares, as leituras indicadas, os livros recomendados, materiais disponíveis na Web e afins, no
intuito de obterem melhor compreensão, além de terem contato a respeito dos mesmos temas, porém de um prisma, um aspecto
diferente, visando à complementaridade dos conceitos aqui disseminados
Uma ótima jornada a todos!
Avançar

Na Web
apresenta um podcast de janeiro de 2009 explicando como os
stakeholders possuem visões divergentes sobre um mesmo risco e o que
pode influenciar para o acontecimento desse fenômeno.
Acesse
Avançar

REFERÊNCIAS
DAMODARAM, A. Gestão estratégica do risco uma referência para tomada de riscos empresariais. Porto Alegre: Bookman,
:
2009.
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 ! 01. ed. Jossey-Bass, 2006.
GREENE, J.; STELLMAN, A. Use a Cabeça, PMP !. 02. 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. p. 753-788.
MAXIMIANO, A. C. A. Administração de Projetos como transformar ideias em resultados. 05. ed. São Paulo: Atlas, 2014.
:
MULCAHY, R. Risk Management: Tricks of the Trade for Project Managers and PMI-RMP Exam Prep Guide. 02. ed. RMC
Publications, Inc. 2010.
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the Project Management Body of Knowledge (PMBOK® Guide ). Fifth
SABBAG, J. O.; COSTA, S. M. A. L. Análise de Custos da Produção de Leite: Aplicação do Método de Monte Carlo. Revista Extensão
Rural DEAER – CCR – UFSM, Santa Maria, v.22, n.1, jan./mar. 2015. Disponível em: < http://cascavel.ufsm.br/revistas/ojs-
,
2.2.2/index.php/extensaorural/article/view/14153 >. Acesso em: 12 jul. 2016.
SBRAGIO, R. Engenharia Econômica e Análise de Riscos Escola Politécnica da Universidade de São Paulo, 2009.
.
VARGAS, R. V. FIVE minutes podcast Disponível em: < http://www.ricardo-vargas.com/pt/podcasts/

. >. Acesso em: 12 jul. 2016.
VARGAS, R. V. Manual prático do plano de projeto utilizando o PMBOK Guide. 03. ed., Rio de Janeiro, Editora Brasport, 2007.
Avançar

APROFUNDANDO
APLICAÇÃO PRÁTICA DO MÉTODO DE MONTE CARLO
Em 2012 foi aplicado o método de Análise de Monte Carlo por dois pesquisadores da UNESP da região de Dracena/SP para a
análise dos custos e rentabilidade da produção de leite da região. Foram utilizadas estimativas para a construção de cenários de
parâmetros reincidentes de produção do leite, no intuito de descobrirem relações iterativas entre os custos de produção e a
rentabilidade esperada pelos produtores, com a premissa de compreensão do modelo e maximização dos lucros mitigando os
riscos e reduzindo as perdas inerentes aos processos de produção.
Foram consideradas as distribuições de probabilidades, ou os chamados métodos estocásticos, que pudessem acrescentar
informações relevantes para os processos de tomada de decisões em condições de riscos. E que ainda fossem permitidas análises
simultâneas utilizando variáveis distintas como preço final, custos de produção e rentabilidade. Inicialmente partiram das
premissas que produtores rurais pequenos com produção modesta tendem a obter rentabilidades menores e que as variáveis que
mais poderiam impactar os resultados de rentabilidade seriam o preço da venda do leite versus o volume produzido, em função da
tecnologia escassa empregada no sistema produtivo.
Com a utilização do método de Monte Carlo por meio da análise de iterações em variáveis distintas, chegou-se à conclusão de que
os maiores custos incorridos para os produtores estavam relacionados aos insumos (ração para o gado, maquinário, vacinas, etc.) e
à mão de obra de ordenha. Concluíram, por meio do método, que a maioria dos produtores da região levava prejuízo,
principalmente quando a produção era de dimensões modestas. Se produzissem de maneira isolada não teriam competitividade
frente aos preços praticados de compra e venda de leite na região, portanto, um sistema de cooperativa e produção coletiva dos
pequenos produtores foi sugerido para que os riscos fossem minimizados e o sistema produtivo fosse ao menos viabilizado, porém
com margens de rentabilidade ainda modestas.
Fonte: Sabbag e Costa (2015).
PARABÉNS!
Avançar

EDITORIAL
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ Núcleo de Educação . a Distância; SAMPAIO ,
Paulo.
Gestão de Riscos em Projetos. Paulo Sampaio.
57 p.
CDD - 22 ed. 658
Fotos Shutterstock
:
Retornar

PLANO DE RESPOSTA
AOS RISCOS
Professor (a) :
Me. Paulo Sampaio
• Levar ao conhecimento do(a) aluno(a) sobre a importância das estratégias de tratamento de ameaças e oportunidades no
planejamento de respostas aos riscos do projeto.
• Compreender as características e implicações dos chamados riscos residuais e riscos secundários na gestão de riscos dos
projetos.
• Identificar as melhores técnicas para lidar com os riscos secundários e suas inter-relações com outros riscos do projeto.
• Reconhecer os gatilhos (alertas) que sinalizarão a incidência de um risco ou a sua iminência de ocorrer muito em breve.
• Compreender a importância do proprietário do risco e suas principais responsabilidades frente aos planos de respostas aos
riscos.
• Perceber os resultados satisfatórios do emprego correto de repositórios centralizados de registro de riscos do projeto.
• Conhecer a diferença e a aplicabilidade correta dos planos de contingência e de backup como planos de respostas aos riscos do
projeto.
Plano de estudo
• Plano de Respostas aos Riscos
• Riscos Residuais e Riscos Secundários
• Gatilhos (triggers) e proprietários dos riscos (risk owners)
• Planos de contingência e de backup
Introdução
Caro(a) aluno(a), nesta unidade, partiremos das definições e conceitos relacionados às ameaças e às oportunidades, características
dos eventos incertos, que podem ou não ocorrer nos projetos, pois isso dependerá do sucesso na gestão de riscos do seu projeto.
Você perceberá que há estratégias distintas de tratamento e de respostas aos riscos, dependendo se o evento adverso poderá
causar impactos positivos ou negativos no seu projeto. Afinal, em se tratando de riscos, não haveria dúvidas de que o mais
importante seria eliminar ou reduzir ao máximo os eventos com impactos negativos e maximizar as possibilidades de benefícios
aos resultados do projeto por meio das oportunidades.
Em seguida, trataremos com detalhes sobre os riscos chamados residuais, que são aqueles que basicamente permanecem
oferecendo ameaças mesmo após algumas análises prévias e mudanças no plano original do projeto para reduzir ou eliminar as
chances de que algum evento com impacto negativo ocorra.
Da mesma forma, estudaremos sobre os riscos secundários, que muitas vezes aparecem como efeito colateral de alguma
estratégia ou resposta aplicada ao risco original. Veremos com detalhes como identificar e tratar ambas as situações.
Prosseguindo com nossos estudos, discorreremos sobre a importância da designação do proprietário do risco para cada risco
mapeado do projeto, com o intuito de tomar as ações necessárias e, previamente, planejadas como respostas aos riscos que vierem
a ocorrer. Este importante ‘ator’ da gestão de riscos tem a missão de verificar os gatilhos, ou sinais de alerta que permitem
reconhecer se o risco já aconteceu ou se encontra na iminência de ocorrer, para que as devidas providências sejam tomadas.
Neste momento, poderemos observar também a importância da devida documentação dos eventos incertos, identificando como
principal conceito e ferramenta o repositório único de registro de riscos, que deve ser atualizado durante todo o ciclo de vida do
projeto.
Por fim, estudaremos as boas práticas de elaboração dos planos de contingência e de backup, iniciativas fundamentais para pôr em
prática as estratégias de tratamento e de respostas aos riscos do projeto. Entender como elaborar planos de respostas eficazes
que venham contribuir com a boa gestão de riscos e agregar valores aos resultados e objetivos do projeto. Estas boas práticas
muitas vezes podem trazer o benefício de eliminar possíveis ameaças a elementos vulneráveis do projeto, como o orçamento e o
cumprimento de prazos previamente estabelecidos.
Bem, tenho plena certeza de que sua curiosidade já foi despertada. Então, vamos juntos embarcar nesta jornada que está pra lá de
motivadora.
Avançar

PLANOS DE RESPOSTAS AOS RISCOS

Olá! Seja bem-vindo(a) aos nossos estudos sobre gestão de riscos em projetos, mais especificamente sobre o plano de respostas
aos riscos. Espero que você aproveite ao máximo o conteúdo aqui abordado.
Ao contrário do que muitos gestores e stakeholders possam pensar, quando falamos sobre eventos incertos (riscos) pertinentes a
toda e qualquer natureza de projeto, não exatamente deveríamos contemplar apenas ameaças ou algo que supostamente possa
dar errado ao longo do desenvolvimento do projeto. Riscos em projetos podem (e devem) ser encarados também como potenciais
oportunidades que propiciem benefícios aos resultados esperados.
Obviamente, ao identificarmos supostas ameaças e potenciais oportunidades devemos, então, esperar que haja um tratamento
diferenciado para cada uma das situações, nas quais – no final das contas – desejamos que as ameaças sejam praticamente
eliminadas e que as oportunidades aconteçam, proporcionando benefícios inúmeros aos resultados finais dos projetos. Trataremos
do planejamento das respostas aos riscos, processo no qual a equipe do projeto pode fazer toda a diferença, principalmente por
estarem na linha de frente da Gestão de Riscos do projeto.
Definições de ameaças e oportunidades relativas aos riscos em

projetos
Basicamente, e segundo Maximiano (2014), podemos definir os eventos incertos que representam as ameaças como os que
proporcionam impactos negativos, enquanto que os eventos incertos que representam as oportunidades são aqueles que
proporcionam impactos positivos aos projetos. Toda essa informação deveria estar compilada e agrupada em um repositório
denominado ‘Registro de Riscos’ (que pode ser composto por arquivos em papel impresso ou manuscrito, representado como
registros eletrônicos armazenados em servidores de arquivos compartilhados ou até mesmo alocados ‘na nuvem’ em servidores
virtuais de arquivos digitais). Para definirmos melhor o conceito de ameaças e oportunidades em projetos, vamos citar dois
exemplos aleatórios de cada um deles:
• Um exemplo de ameaça em um projeto de construção de um shopping center em uma área urbana seria um grande atraso por
parte dos órgãos públicos competentes locais na emissão da permissão de construção para a construtora responsável pelas
obras civis do projeto.
• Outro exemplo de ameaça pode ser em um projeto de readequação de sistemas de computadores para atendimento – por
parte de uma empresa – a uma legislação fiscal estadual, na qual o governo decide por alterar algumas regras no meio do
projeto, proporcionando a princípio um não cumprimento do prazo pré-determinado de atendimento às leis locais.
• Um exemplo de oportunidade em um projeto de manufatura de um novo produto a ser comercializado por uma empresa do
setor de cosméticos seria a redução de custos na matéria-prima, por conta de um novo fornecedor entrante no mercado e
constante na lista de fornecedores homologados pela empresa.
• Outro exemplo de oportunidade seria a possibilidade de envio de dois profissionais de uma empresa a um país estrangeiro
para treinamento e capacitação em uma tecnologia emergente, totalmente custeado por um fornecedor detentor desse tipo de
tecnologia na sua matriz no exterior.
Poderíamos citar inúmeros exemplos de ambos os casos, porém já podemos ter uma boa ideia do que vem a ser ameaças e/ou
oportunidades em projetos. Podemos ainda perceber que cada tipo de abordagem requer uma resposta adequada às suas
características peculiares, quase que exigindo um tratamento exclusivo para todo e qualquer evento incerto identificado no
projeto. Bem, também é certo que muitos riscos podem ser tratados por meio de um único plano de respostas. Mas, isso nós
veremos mais à frente nesta mesma unidade.
Tanto as ameaças quanto às oportunidades precisam ser analisadas, quando identificadas, de acordo com a
sua probabilidade e impacto. Probabilidade relacionada à chance que o evento tem de acontecer e os
impactos que serão causados caso aconteçam, se serão positivos ou negativos em relação aos resultados
esperados no projeto. As razões principais da Gestão de Riscos em projetos seria a redução ao mínimo (ou a
eliminação) das chances dos eventos incertos com impactos negativos acontecerem, a minimização dos
impactos negativos – caso uma ameaça ocorra inevitavelmente – ou ainda a maximização das chances dos
eventos incertos com impactos positivos acontecerem, proporcionando benefícios aos resultados
esperados no projeto.
Fonte: Dinsmore e Cooke-Davies (2006)
Como fazer com que possamos atribuir um plano de respostas mais adequado aos tipos de riscos que podem acontecer nos
projetos que gerenciamos? Bem, antes de responder a essa pergunta, precisamos estabelecer alguns critérios baseados na
complexidade dos projetos. A complexidade, de acordo com Maximiano (2014), muitas vezes está associada ao número e categoria
de stakeholders direta e indiretamente impactados, ao número e diversidade de fornecedores externos envolvidos, à tecnologia
associada ao projeto, dentre outros critérios.
Pode também estar associada à duração do projeto, pela qual compreendemos que quanto maior for a duração mais complexo será
o projeto. Segundo ainda o autor, a duração do ciclo de vida de um projeto e sua complexidade também estaria associada aos
recursos disponíveis (recursos humanos, financeiros e o próprio tempo), além de outros critérios que tornariam os objetivos do
projeto mais difíceis de serem alcançados em sua plenitude.
Se nos basearmos nessas definições, podemos compreender que para projetos pequenos e de curta duração, se você fizer reuniões
regulares e periódicas com o seu time e com alguns stakeholders chaves, e utilizar algumas técnicas como brainstorm ou
preenchimento de formulários, por exemplo, poderá obter ótimos resultados com relação às respostas que cada risco necessita
para ser tratado ao longo do ciclo de vida do projeto.
Já para os projetos mais complexos e com durações longas, envolvendo um número considerável de stakeholders talvez essa não
,
seja a melhor alternativa. Seria interessante se você pudesse utilizar técnicas diversificadas, como agrupamento de riscos por
categorias e times específicos (categoria de Engenharia aos engenheiros, assuntos relacionados às finanças ao departamento
financeiro, por exemplo), além de poder delegar funções de coordenação a membros específicos do seu time para organizar as
sessões de planejamento de respostas aos riscos identificados. Com essas práticas, e segundo Mulcahy (2010), há um aumento
significativo das chances de sucesso na elaboração dos planos de respostas por parte dos stakeholders comprometidos com o
projeto.
Lembra-se do repositório chamado ‘Registro de Riscos’ que comentamos no início deste estudo? Pois é, lá é o local ideal para
registrar não só as estratégias a serem utilizadas como também quais serão as ações a serem executadas caso uma ameaça ocorra,
quem deverá ser acionado, em que momento do ciclo de vida, além de outras informações pertinentes ao plano de respostas aos
riscos. Por fim, planejar estas respostas aos potenciais riscos seria analisar o que deve ser feito (sempre em busca da melhor
alternativa) caso o risco mapeado venha a acontecer de fato.
Pois bem, conforme comentamos anteriormente algumas respostas planejadas podem servir para várias origens de riscos.
Podemos tomar como exemplo uma série de ameaças relacionadas a uma nova tecnologia a ser explorada pela companhia em um
projeto.
Se o uso desta nova tecnologia trouxer muitas ameaças e o projeto começar a se tornar inviável do ponto de vista da complexidade
atribuída aos riscos, os stakeholders dirigentes podem optar por utilizar uma tecnologia convencional e já homologada.
Dessa maneira, podem eliminar ou reduzir inúmeras ameaças inerentes ao projeto e relacionadas a esta categoria, desde que,
obviamente, os objetivos iniciais possam ser mantidos e os resultados esperados do projeto sejam ainda satisfatórios.
Estratégias de tratamento de riscos
Por outro lado, quando a estratégia de eliminar ou reduzir riscos com apenas uma ação de resposta aos riscos não for possível de
ser utilizada, devemos analisar cada risco e identificar qual seria a melhor estratégia de resposta, de forma bem individual mesmo.
Para tanto, precisamos primeiramente identificar se o evento incerto é relacionado a uma ameaça ou a uma oportunidade. Bem,
isto já foi comentado no início deste capítulo. Definido então o tipo de risco precisamos abordar, segundo Kerzner (2009), as
estratégias recomendadas pelas boas práticas de gestão de riscos, tanto as relacionadas às ameaças quanto às oportunidades. São
elas:
Estratégias relacionadas às ameaças:
• Evitar ( avoidance ) mudança no plano de projeto para eliminar a ameaça do risco. Geralmente, devemos atuar na origem do
:
risco. Ex.: eliminação ou substituição de uma tarefa arriscada do projeto.
• Transferir ( transference ) transferir o impacto negativo de um risco a um terceiro. Ex.: contratar um seguro para o transporte
:
de equipamentos ou transferir uma atividade crítica do projeto para uma empresa mais qualificada (um fornecedor de serviços)
poder executá-la.
• Mitigar ( mitigate ) tomar medidas para reduzir a probabilidade e/ou impacto do risco a um nível aceitável pelos stakeholders
:
do projeto. Ex.: usar equipamentos de proteção individual em uma operação manual com alto risco (mitigar a probabilidade) ou
distribuir as atividades de um membro da equipe para outros membros após sua saída do projeto (mitigar o impacto).
• Aceitar ( acceptance ): pode ser passiva (não fazer nada, quando o impacto não é significativo e pode ser absorvido no projeto)
ou ativa, lançando mão do plano de contingência como resposta ao risco (a ser descrito mais adiante).
Estratégias relacionadas às oportunidades:
• Explorar ( exploit ): explorar a oportunidade fazendo com que a probabilidade da oportunidade aumente. Ex.: examinar com
maior detalhe o perfil técnico de um potencial fornecedor.
• Compartilhar ( share ): reter a oportunidade apropriada ao invés de transferi-la para outros. Ex.: mobilizar um recurso humano
com perfil apropriado para determinada atividade.
• Intensificar ( ehance ) aumentar o tempo esperado, a qualidade ou designar o recurso mais adequado aumentando a
:
probabilidade ou o impacto da ocorrência. Ex.: remanejar atividades críticas no cronograma coincidindo com o período de
disponibilidade de um recurso chave, possibilitando sua atuação no projeto.
• Aceitar ( acceptance ): pode ser passiva (não fazer nada, quando o impacto não é significativo e pode ser absorvido no projeto)
ou ativa, lançando mão do plano de contingência como resposta ao risco (a ser descrito mais adiante).
Observem que a estratégia de ‘aceitar’ um risco pode ser utilizada tanto para o tratamento de uma ameaça quanto de uma
oportunidade, pois em ambos os casos o impacto pode não ser tão significativo a ponto de ter de ser gerenciado, podendo ser
absorvido sem que nenhuma ação precise ser tomada.
Para que possamos fixar bem quais são as estratégias de tratamento dos riscos, devemos associar as
pertinentes às ameaças com aquelas relacionadas com as oportunidades. Devemos evitar uma ameaça
atuando de preferência na sua origem, mas explorar uma oportunidade quando esta tiver mesmo que uma
mínima chance de ocorrer. Transferir uma ameaça quando esta gerar um ônus que deva ser gerenciado por
terceiros e compartilhar o máximo possível quando o ganho potencial de um efeito positivo venha a ser uma
recompensa para os resultados do projeto. Intensificar uma oportunidade ampliando as chances de ela
acontecer ao invés de mitigar as chances ou o impacto de eventos incertos com efeitos negativos. E, por fim,
aceitar tanto ameaças quanto oportunidades quando estas não requerem ações proativas, não sejam
racionais em termos de custos ou seus impactos possam ser absorvidos pelo planejamento do projeto sem
que haja interferências significativas nos resultados do projeto.
Fonte: Dinsmore e Cabanis-Brewin (2009).
Para podermos compreender melhor como seriam aplicadas as estratégias de tratamento de ameaças e oportunidades,
utilizaremos um exemplo de cada circunstância, apresentando, a seguir, algumas sugestões de formulários a serem preenchidos de
acordo com o mapeamento dos riscos e com as interpretações realizadas pelo time do projeto. Observem, para tanto, as tabelas 1
e 2, a seguir:
Tabela 1 - Exemplo de formulário de tratamento de ameaças
Fonte: adaptado de Mulcahy (2010).
Tabela 2 - Exemplo de formulário de tratamento de oportunidades

Segundo Mulcahy (2010), para ambos os exemplos temos a chance de escolher mais de uma ação para um mesmo evento incerto.
Para nossa melhor compreensão, vamos tomar primeiramente o exemplo de uma ameaça ao projeto. Imagine que haja uma chance
de ocorrer uma falha no desenvolvimento de um módulo mecânico específico de uma máquina a ser construída em um
determinado projeto. Podemos tanto identificar ações para evitar que isso aconteça, mobilizando recursos capacitados e
habilitados para essa atividade no cronograma quanto planejar ações para transferir essa ameaça para uma empresa especializada
neste tipo de desenvolvimento, a qual prestará serviços ao projeto.
Da mesma maneira, porém em outro exemplo, imagine agora que haja uma oportunidade de aproveitar a expertise (conhecimento)
pertinente a um fornecedor sobre uma tecnologia ainda não explorada pela empresa patrocinadora do projeto. Podemos tanto
explorar esta oportunidade fazendo com que as chances de que este fornecedor possa vir a prestar serviços ao projeto aumentem
e/ou ainda intensificá-la de modo que o grau de qualidade dos resultados esperados também seja maximizado.
A decisão de qual a melhor alternativa a ser escolhida irá por muitas vezes depender não só dos melhores resultados possíveis
como também de fatores financeiros que possam a vir impactar o orçamento do projeto.
Todo cuidado deve ser tomado para que o planejamento de respostas aos riscos não seja, posteriormente,
arquivado e esquecido, algo relativamente (e infelizmente) comum de acontecer. Afinal, não seria nada
interessante ter todo esse trabalho e ainda presenciar seu projeto fracassar por ações importantes que
deveriam ter sido e não foram apropriada e oportunamente tomadas, correto?
Fonte: o autor.
Encerramos esta primeira parte com conceitos sobre o discernimento entre os tratamentos e estratégias para as ameaças e para as
ameaças em projetos. Vimos que para cada situação de risco, podemos utilizar várias estratégias distintas, sempre com o intuito de
eliminar (ou reduzir) as chances de algo ruim acontecer, reduzir o impacto de forma gerenciável após o evento ter ocorrido ou
ainda intensificando as possibilidades de coisas boas acontecerem no projeto.
Espero que você tenha aproveitado o conteúdo abordado, pois há muito mais coisas interessantes por vir.
RISCOS RESIDUAIS E RISCOS
SECUNDÁRIOS
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 jornada.
Neste momento, abordaremos as diferenças existentes entre riscos residuais e riscos secundários, classificando-os quanto ao
momento da sua ocorrência, quais as circunstâncias propícias em que ambos possam ser evidenciados e ainda quais seriam as
melhores estratégias e táticas para tratá-los – se e quando ocorrerem.
Riscos residuais
Segundo Greene e Stellman (2010), você, enquanto gerente do projeto, e sua equipe deverão implantar as ações planejadas como
respostas aos riscos mapeados e analisados previamente.
Inúmeros esforços poderão ser empregados no intuito principal de planejar como reduzir ou eliminar todas as ameaças inerentes
ao projeto, porém em algum momento uma decisão deverá ser tomada sobre quando devemos interromper o planejamento de
respostas aos riscos. Essa decisão poderá ser baseada, por exemplo, na lista de riscos priorizados, de acordo com sua classificação
quanto à probabilidade de ocorrerem e o impacto (ou dano) que podem causar aos resultados do projeto. Ou seja, devemos
empregar nossos esforços naqueles riscos que realmente podem prejudicar o projeto.
Para compreendermos melhor esse conceito vamos utilizar um exemplo um pouco mais prático. Em todo e qualquer projeto
haverá riscos (no caso ameaças) que terão maiores chances de ocorrerem, por qualquer que seja o motivo, em relação a outros
riscos também identificados. Em contrapartida, devemos analisar também o impacto (ou dano) causado caso o evento ocorra.
Na prática, os riscos com maior prioridade serão aqueles que possuem maiores chances de ocorrerem e que causam maiores
impactos e prejuízos quando ocorrem. No final, são estes que devem merecer nossa atenção e a elaboração do tratamento mais
adequado.
Em determinado momento do planejamento de resposta aos riscos, a equipe e o gerente de projetos deverão ter o discernimento
se os riscos considerados os mais críticos já foram cobertos e ainda decidirem o que fazer com os riscos remanescentes,
geralmente menos prioritários, porém não menos importantes.
De acordo com Mulcahy (2010), alguns riscos (eventos incertos) podem permanecer mesmo após a implantação de mudanças no
plano original do projeto, após a execução de análises prévias (como exemplo de mudanças no plano por conta de eventos incertos,
temos o citado anteriormente, no qual os stakeholders dirigentes decidiram por utilizar uma tecnologia convencional ao invés de
arriscar em uma nova tecnologia?), os quais são denominados de ‘riscos residuais’. Adicionamos a essa classe de riscos àqueles
considerados menos prioritários, citados no parágrafo anterior. A estes riscos inevitavelmente, deveremos criar os planos de
contingência e de backup assuntos que serão abordados mais à frente.
,
Para que seja melhor nossa compreensão sobre riscos residuais, vamos tomar um exemplo segundo Vargas (2007), no qual você
deva considerar um projeto de atendimento e readequação às exigências do governo local nos âmbitos legal e fiscal por uma
empresa. A equipe do projeto, junto ao Gerente de Projetos e os principais stakeholders poderá tomar todas as ações consideradas
,
necessárias para tratar toda e qualquer ameaça inerente a essa natureza de projeto, por meio de mudanças no plano original, como
a contratação de um consultor expert em legislação fiscal que poderá sugerir modificações significativas no levantamento de
‘ ’
dados a serem atendidos.
Estas medidas podem ter proporcionado a eliminação total de alguns riscos e/ ou à diminuição das chances de outros ocorrerem,
trazendo inúmeros benefícios aos resultados do projeto. Mesmo assim, haverá sempre a possibilidade de um ou mais eventos
incertos (ameaças) permanecerem após essas medidas de prevenção, os quais deverão ser tratados como riscos residuais. Para
estes riscos, os quais as medidas preventivas não surtiram efeitos, devemos obrigatoriamente criar planos estratégicos de
respostas os quais compreendem os planos de contingência e de backup, planos estes que serão abordados mais à frente.
Os riscos residuais podem ser classificados também como aqueles que, durante o processo de planejamento
de respostas aos riscos, decidimos pela estratégia de ‘aceitar’ passivamente, provavelmente pelo seu
impacto não ser tão significativo aos resultados do projeto naquele momento. Porém, para que o plano de
Gestão de Riscos seja o mais eficaz possível, devem ser devidamente tratados e comunicados aos principais
stakeholders do projeto. Esse processo deve se repetir durante todo o ciclo de vida, pois podem ter sua
importância e severidade alteradas conforme o andamento do projeto. Por outro lado, os riscos residuais
podem tanto não se manifestar durante o ciclo de vida do projeto como podem gerar até mesmo uma
necessidade de mudança no escopo, orçamento, prazos ou grau de qualidade, previamente planejados pela
equipe do projeto.
Fonte: Vargas (2007).
Riscos secundários
Um risco secundário é aquele que, segundo Kerzner (2009), é gerado por uma estratégia de reposta implantada em outro risco. Ou
seja, responder a um risco pode gerar um novo risco (geralmente ameaças aos resultados esperados). De qualquer forma, o
gerente de projetos e sua equipe devem considerar e incluir os riscos secundários nos processos de planejamento de respostas aos
riscos. Deverão ser analisados e terem suas (novas) probabilidades e impactos avaliados, para que tenham também suas
prioridades e grau de severidade definidos.
Novas estratégias de tratamento devem ser atribuídas aos riscos secundários, no intuito de reduzir ou eliminar as chances de
ocorrerem (se houver tempo hábil para essa ação) ou ainda para que seus impactos sejam mitigados, evitando maiores danos aos
resultados esperados. No entanto, segundo ainda o próprio Kerzner (2009), os riscos secundários não deveriam ter um impacto
maior do que os riscos iniciais pelos quais foram derivados.
Geralmente, os riscos secundários podem ser mapeados se fizermos uma comparação entre as respostas de cada risco em relação
às estratégias adotadas para outros riscos. Para compreendermos melhor esse conceito, vamos analisar a figura 1 que trata dessa
comparação entre três riscos analisados:
Figura 1 - Análise de riscos secundários
Fonte: Adaptado de Mulcahy (2010).
Para termos uma melhor compreensão, abordaremos com um exemplo mais prático sobre como devemos analisar a sugestão do
quadro citado anteriormente. Para tanto, vamos imaginar um cenário no qual temos um projeto de construção de um edifício
residencial de 20 andares, com quatro apartamentos por andar. Neste projeto de obra civil, foram identificados e mapeados,
dentre outros, os seguintes riscos que compõem nossa análise de riscos secundários:
• Risco 1: Por conta de um fornecedor de tijolos e blocos de cimento se declarar em más condições financeiras, as entregas
desse insumo podem se atrasar, comprometendo o cronograma do projeto.
• Risco 2: Os órgãos de controle e liberação de alvará e licença de construção da prefeitura local encontram-se em greve,
podendo comprometer os prazos de início das obras.
• Risco 3: Por complicações de documentação incompleta e excesso de burocracia, os recursos financeiros provenientes de
financiamento junto a uma instituição bancária podem ter sua aprovação postergada.
Para que a análise seja completa, incluiremos nesse cenário as estratégias de respostas para cada risco, como segue:
• Estratégia para o risco #1: Homologar um novo fornecedor em tempo hábil para fornecer os insumos sem comprometer os
prazos do projeto.
• Estratégia para o risco #2: Aguardar o final da greve e obter a licença de construção. Por ser uma restrição externa não há
outro tipo de controle para esse risco.
• Estratégia para o risco #3: Utilizar recursos financeiros próprios da incorporadora até que a documentação esteja
regularizada e o financiamento pela instituição bancária seja liberado.
De acordo com as descrições dos riscos (nesse caso, somente ameaças) quais seriam outras estratégias de
respostas possíveis de serem aplicadas para cada um deles? Será que adotando outras estratégias de
respostas aos riscos, os resultados referentes aos riscos secundários seriam alterados? Avalie.
Pois bem, seguindo o quadro de análises de riscos secundários, temos o seguinte cenário:
• Caso o risco #1 ocorra, sua estratégia de tratamento não causará nenhum dano ou outro efeito ao risco #2 e nem ao risco #3.
• Já o risco #2 e sua devida resposta provocaria um impacto de efeito negativo tanto no risco #1 como no risco #3, pois o fato
de a empresa estar impedida de iniciar a obra no prazo pré-determinado não implica que outros compromissos demandados
pelo projeto não devam ser cumpridos.
• Para o risco #3 e sua estratégia de resposta, os efeitos causados nos riscos #1 seriam positivos, pois significa que a companhia
teria recursos financeiros suficientes para honrar quaisquer compromissos gerados pelas demandas do projeto. Para o risco #2
não haveria qualquer impacto significativo, pois o início das obras, sob o aspecto do risco #2, independe de qual for a origem do
recurso financeiro empregado no empreendimento.
Dessa maneira, e por meio dessa análise segundo Mulcahy (2010), podemos observar as interdependências entre os riscos dos
projetos e identificar os riscos secundários.
Riscos secundários podem ainda ser gerados de forma que não seja possível correlacioná-los com as
estratégias de respostas de outros riscos, ou seja, com antecedência e tempo hábil de manobra como nos
exemplos aqui citados. Eles podem simplesmente ocorrer após a implantação de uma resposta a um risco,
apresentando-se como um elemento surpresa (como no caso de uma estratégia de resposta a uma
determinada ameaça ter consumido mais dinheiro que o planejado, colocando em risco as reservas de
contingência previamente definidas no projeto). Nestes casos, o ideal seria fazer uso do processo formal de
Controle de Mudança Integrada, para que uma nova reserva de contingência complementar fosse aprovada,
após justificada, pela alta administração da companhia.
Fonte: Maximiano (2014).
Vimos aqui a importância do mapeamento dos riscos residuais, aqueles que não conseguimos eliminar fazendo mudanças no plano
original do projeto, por conta de análises que demonstraram que seria possível tomar estas ações prévias. Para estes riscos se
torna inevitável planejar os planos de respostas pertinentes a cada evento incerto avaliado, utilizando a melhor estratégia para
tratá-los de maneira adequada.
O mesmo pode se aplicar aos riscos secundários, aqueles que são gerados quando da implantação de uma resposta ao risco. Estes
precisam ser avaliados no momento de sua ocorrência e decisões precisarão ser tomadas, muitas vezes em caráter de emergência,
pois estes não puderam ser avaliados com a devida antecedência.
Mas, vamos seguir em frente, porque isso está ficando cada vez mais interessante.
GATILHOS (TRIGGERS) E
PROPRIETÁRIOS DOS RISCOS (RISK
OWNERS)
Olá, daremos continuidade aos nossos estudos sobre as melhores práticas de tratamento de eventos incertos, bem como as
estratégias adequadas a serem implantadas de acordo com o grau de ameaça ou de oportunidade oferecida ao projeto.
Todo e qualquer risco, quer seja ele classificado como ameaça ou oportunidade, pode revelar indícios que está prestes a acontecer
ou que já aconteceu. Para estas ocasiões precisamos que alguém esteja atento a esses acontecimentos e saiba exatamente o que
fazer com antecedência. Estas são as importâncias dos gatilhos ( triggers ) e dos proprietários dos riscos ( risk owners ) perante o
planejamento e gestão de riscos em projetos que discutiremos neste capítulo.
Gatilhos (triggers) dos riscos
Segundo Mulcahy (2010), podemos chamar de gatilho – fazendo alusão ao dispositivo responsável pelo disparo de uma arma de
fogo, uma vez que seu acionamento preceda o disparo do projétil, não sendo possível nesse momento reverter o processo algum
sinal de alerta, pequeno evento ou indício de que um risco previamente mapeado esteja prestes a acontecer ou ainda que indique
ao Gerente de Projetos ou à sua equipe que o risco acabou de acontecer (obviamente, com tempo hábil para que se tome uma ação
de mitigação do impacto, já que nesse momento não seja mais possível atuar na sua probabilidade de acontecer).
Os gatilhos são geralmente identificados e associados aos riscos que foram aceitos (ativamente e não de forma passiva), ou seja,
fazem parte dos riscos – na maioria das vezes ameaças – que requerem um plano de resposta adequado e apropriado para que
sejam controlados no projeto. Podem ser identificados ao mesmo tempo em que os próprios riscos são identificados, porém devem
ser registrados no momento em que você estiver planejando (e como parte do) plano de respostas aos riscos mapeados.
Geralmente é possível – e muito produtivo, além de recomendável – identificar o risco e seu respectivo gatilho no momento em
que seu time de riscos estiver atuando nesse processo.
De acordo com Greene e Stellman (2010), existem algumas dicas – na forma de questionamentos – que podem ser respondidos no
intuito de auxiliar no processo da identificação dos gatilhos junto aos riscos identificados. Seriam os seguintes questionamentos
norteadores, que podem ser feitos pelo Gerente de Projetos, pelo time de riscos ou ainda por algum stakeholder que detenha um
conhecimento específico a respeito do risco identificado:
• Como saberemos exatamente quando o risco pode ocorrer?
• Como poderemos estabelecer alguns indicadores para descobrirmos se determinado risco está prestes a ocorrer ou se já
aconteceu?
• Que eventos ou ocasiões serão utilizados como parâmetros para determinarmos o momento imediato antes de o risco
acontecer?
Os gatilhos devem ser monitorados constantemente durante a execução do projeto, mesmo porque se em determinado momento
se manifestarem, devem ser identificados como o ‘disparo’ necessário para o plano de ação que deve ser posto em execução.
É importante que este sinal de alerta seja registrado de forma clara, para que não haja subjetividade quanto a sua ocorrência.
Assim, não restará dúvidas de que o plano de ação deverá ser acionado no momento exato, proporcionando tempo hábil para
manejar a situação e lidar com os impactos de maneira mais eficaz.
Para melhor compreensão vamos apresentar alguns exemplos de riscos (tanto ameaças quanto oportunidades) e seus respectivos
gatilhos associados, segundo Sbragio (2009) para que tenhamos mais facilidade de identificá-los durante o processo de
identificação de riscos e de reconhecê-los quando se manifestarem durante a execução dos projetos:
• Em um projeto nacional que envolva empresas estrangeiras e que parte do orçamento seja expresso em dólares, há uma
restrição com relação à cotação máxima dessa moeda em relação à conversão para o Real. Foi identificado como gatilho de um
risco de comprometimento dos limites do orçamento a cotação do dólar ultrapassar a marca de três reais e cinquenta centavos.
Ao atingir esse patamar (ou muito próximo dele) a ameaça iminente já se manifestou, solicitando que o plano de respostas e
esse risco seja posto em ação.
• Você, que é o Gerente de Projetos, faz uma visita de auditoria a um fornecedor e constata que ele não conseguirá cumprir
uma entrega do projeto na data especificada. Esse fato será o gatilho para que medidas de contingência sejam tomadas em
relação aos resultados esperados para essa entrega do projeto.
• O Gerente de Projetos recebeu a informação durante uma reunião executiva de que a alta administração da companhia
reduziria o grau de qualidade de um entregável, aceitando um produto nacional em substituição a um material importado,
porém mantendo o projeto em nível aceitável de qualidade. Esse foi um gatilho de um risco que comprometia seriamente os
prazos por conta dos processos burocráticos de importação, manifestando-se como uma oportunidade para os resultados do
projeto.
• O relatório final dos testes de um protótipo de um dispositivo industrial indicaram que a qualidade dos resultados esperados
aumentou significativamente, após a contratação de serviços especializados de um fornecedor externo. As atividades
consideradas críticas relacionadas a essa entrega tiveram seu grau de risco diminuídos no projeto por conta do relatório final
dos testes que funcionou como um gatilho para uma oportunidade de ocorrer nessa entrega do projeto.
Baseando-se nos exemplos abordados, você seria capaz de identificar os gatilhos dos riscos e seus
respectivos e possíveis indicadores de que estariam prestes a acontecer ou que já teriam acontecido? Seria
ainda capaz de exercitar mentalmente algumas situações de risco nas quais poderia identificar e mensurar
os gatilhos para estar alertas a eles e tomar as ações necessárias e previamente planejadas? Pense bem.
Responsáveis pelos riscos (risk owners)
De acordo com Mulcahy (2010), os proprietários dos riscos são aqueles que foram designados a estarem de sobreaviso e de alerta
em relação aos gatilhos dos riscos sob sua responsabilidade e ainda a tomarem quando preciso as ações necessárias para cada um
dos riscos, previamente planejadas. Geralmente, são parte do time do projeto ou stakeholders específicos que detém o
conhecimento necessário para tomar as ações corretivas, em caso do risco inevitavelmente ocorrer.
É muito comum que o proprietário de um ou mais riscos do projeto tenha sido aquele que identificou o potencial risco (ameaça ou
oportunidade) durante o processo de identificação e qualificação dos dados (nivelamento de informações entre os stakeholders a
respeito do evento incerto).
Outro fator que pode designá-lo como proprietário do risco é o seu conhecimento acerca do assunto relacionado ao risco. Por
exemplo, riscos em relação ao cumprimento (ou não) de cláusulas contratuais do ponto de vista do jurídico em contratos com
fornecedores podem ter sido identificados por especialistas dessa área. Inevitavelmente serão os proprietários destes riscos,
tomando as ações necessárias previamente planejadas, alertando ao Gerente de Projetos sobre os resultados obtidos após a
implantação da resposta ao risco.
Segundo Kerzner (2009), os proprietários dos riscos teriam ainda um valor inestimável durante os processos de análise de cada
evento incerto, tanto na forma qualitativa como na quantitativa de análise desse risco. Sobretudo, seriam ainda indispensáveis
durante o processo de planejamento das respostas aos riscos, pois em muitas vezes essas respostas requerem ações específicas de
cada área, as quais somente um especialista poderia auxiliar na elaboração de uma resposta eficaz.
Para uma melhor gestão do plano de riscos, e de acordo com Kerzner (2009), o ideal seria identificar os potenciais proprietários
dos riscos ainda no processo de identificação dos riscos e seus respectivos gatilhos, e oficializar o posto de proprietário do risco no
processo de elaboração das respostas aos riscos. Isso porque, é nesse processo que o plano de ação será criado, com datas devidas,
ações a serem executadas, pessoas, grupos ou empresas a serem acionadas pelo proprietário do risco.
Kerzner (2009) relata que a responsabilidade da divulgação e disseminação do plano de respostas aos riscos com seus devidos
proprietários de riscos designados é do Gerente de Projetos, por meio de um plano de comunicação do projeto bem elaborado e
eficaz, para levar ao conhecimento de todos os stakeholders do projeto sobre as ações a serem tomadas e quem seria o responsável
por colocá-las em prática. Dessa maneira, caso o evento incerto ocorresse não haveria razões para que dúvidas viessem à tona
sobre o que fazer, como fazer, quem deveria ser acionado e quem tomaria as iniciativas a respeito do evento incorrido.
Vamos agora exemplificar o emprego dos gatilhos inerentes a todo e qualquer risco, bem como a designação dos proprietários dos
riscos utilizando para tanto um modelo de registro de riscos a ser atualizado constantemente durante não só o planejamento como
também durante a execução do projeto, na figura 2, a seguir:
Figura 2 – Modelo de Registro de Riscos em projetos

O modelo sugerido acima por Mulcahy (2010) pode ser interpretado como a base de um plano de resposta a um risco, bastando
acrescentar outras informações pertinentes, por exemplo, as datas devidas dos acontecimentos, dados de quem precisaria ser
acionado, stakeholders envolvidos, bem como outras informações que se fizerem necessárias.
Alguns proprietários de riscos não precisam necessariamente ser o executor de uma ação de mitigação do
impacto caso um evento incerto (principalmente ameaças) tenha incorrido. Muitas vezes lhes faltarão
autonomia (poder de decisão) e/ou autoridade (liderança hierárquica) para poderem por em prática as ações
necessárias para tratar devidamente o risco. Porém, serão eles os responsáveis por monitorar os gatilhos e
acionar devidamente o stakeholder (ou um grupo deles) para que decisões sejam tomadas ou ações
específicas sejam tomadas. Seria de sua responsabilidade ainda reportar ao Gerente de Projetos sobre os
resultados obtidos se foram eficazes ou se necessitam de atenção e alerta mesmo após a implantação das
respostas previamente planejadas.
Fonte: Valeriano (2004).
Proprietários das ações sobre os riscos (risk action owner)
Alguns projetos podem ser demasiado complexos e terem várias atividades associadas a muitos e críticos riscos, com sérios
impactos caso ocorram. De acordo com Sbragio (2009), nestes casos, os proprietários dos riscos podem ter pessoas que irão os
auxiliar a lidar com os riscos e a implantar respostas pré-aprovadas aos riscos (principalmente ameaças) considerados mais críticos
e emergentes. A esses stakeholders chamamos de proprietários das ações sobre os riscos. Eles não possuem necessariamente as
responsabilidades sobre os riscos, função essa que é designada sempre ao proprietário do risco.
Porém, segundo Sbragio (2009), podem ser responsabilizados por executar ações, geralmente operacionais, aprovadas
previamente no intuito de mitigar os impactos causados pelo evento incerto. Um bom exemplo para essa situação seria a execução
de um plano de ação, no qual um proprietário das ações sobre os riscos acionaria a contratação temporária de um operário em uma
obra civil para auxiliar na execução da pintura de uma fachada de um prédio, na fase de acabamento do edifício. A contratação e o
acompanhamento das atividades seriam de responsabilidade do proprietário das ações sobre esse risco e o reporte ao Gerente de
Projetos seria feito pelo Engenheiro de Obras, designado previamente como o proprietário do risco de não concluir as obras de
acabamento da fachada do edifício em tempo hábil.
Você pode ter vários proprietários de riscos para uma mesma ou várias atividades do projeto e vários proprietários de ações sobre
os riscos que irão os auxiliar com relação à implantação do plano de respostas aos riscos, desde que tudo seja documentado e
registrado de maneira apropriada, permitindo que esteja tudo sob o controle do Gerente de Projetos. Novamente, o registro de
riscos é o local (e documentação) mais recomendado para armazenar essas informações e dar visibilidade aos stakeholders acerca
do plano de respostas aos riscos e seus atores a serem acionados, caso seja necessário.
Os proprietários dos riscos e os proprietários das ações sobre os riscos explanados acima não devem ser
confundidos com os responsáveis pela execução das atividades do projeto. Isso pode até acontecer, porém
não é uma regra. O recurso designado para executar as atividades não deveria ser responsabilizado pelo
reporte caso um ou mais risco inerente às atividades sob sua responsabilidade ocorram e não tenha a
função de proprietário do risco acumulada. Todavia, nesse caso, o proprietário do risco deve prestar contas
ao Gerente de Projetos com relação aos riscos ocorridos e sobre os resultados obtidos após a implantação
das respostas previamente planejadas. Para tanto, é necessário que haja um processo de comunicação
robusto e eficaz entre os atores aqui referenciados, para que os resultados da Gestão de Riscos seja a mais
eficaz possível e os resultados obtidos sejam também os mais satisfatórios possíveis.
Fonte: o autor.
Os benefícios de um plano de respostas eficaz
Vamos pensar por um momento em um projeto que você esteja gerenciando no momento (ou, se não for esse o caso, tente
imaginar que estivesse gerenciando um projeto bem importante na sua carreira). O que aconteceria se eventos incertos críticos
aparecessem no seu projeto? Provavelmente, você convocaria uma reunião de emergência com seus principais stakeholders no
intuito de encontrar as melhores alternativas de solução para os problemas em questão.
Todavia, explorando um pouco mais esse cenário, pense que cada minuto que você estivesse com os stakeholders do projeto seria
precioso, pois seu projeto estaria sendo impactado quanto aos recursos que muitas vezes já são escassos, como prazos e custos,
por exemplo. O fato de você ser rápido e reunir os interessados em busca de uma solução seriam louvável, do ponto de vista do
gerenciamento de riscos em projetos.
Mas, não se esqueça de que essa situação seria (muito provável) bem recorrente. Então, os esforços empregados na Gestão de
Riscos seriam enormes, pois estaríamos agindo em uma condição reativa ao invés de buscarmos pró-atividade.
Por outro lado, e de acordo com Sbragio (2009), podemos analisar esse cenário com um pouco mais de senso crítico e organização.
Imagine a mesma situação descrita anteriormente, porém assuma que estes mesmos eventos incertos críticos tivessem sido já
identificados, analisados e planos de respostas tivessem sido elaborados para cada um deles. O plano de ação adequado e
apropriado seria posto em execução pelo proprietário do risco (ou pelo proprietário de ações sobre os riscos, se fosse este o caso),
as reuniões seriam desnecessárias e os impactados seriam devidamente mitigados. Daria para imaginar quantas reuniões seriam
evitadas e quanto o tempo dos stakeholders e os prazos do seu projeto poderiam ser otimizados.
Este seria o verdadeiro intuito pelo qual os esforços empregados nos processos de planejamento do plano de gestão dos riscos se
autojustificariam. Os riscos majoritários já estariam endereçados e seus respectivos gatilhos e proprietários estariam designados,
bastando por em ação os planos de respostas que haviam sido planejados previamente. Dessa maneira, segundo Sbragio (2009),
podemos assumir que atuaríamos em condições pró-ativas e não mais reativas, proporcionando maior efetividade e eficácia ao
lidar com os eventos incertos do projeto.
Muito bem, ao final deste estudo pudemos perceber que realmente há a necessidade do comprometimento dos stakeholders para a
realização da Gestão de Riscos em projetos. O proprietário do risco ( risk owner ) e o proprietário das ações sobre os riscos exercem
um papel fundamental na execução dos planos de respostas aos riscos, não só na implantação dos planos de respostas aos riscos,
como também no monitoramento constante dos sinais de alerta – os gatilhos – que lhes fornecerão informações preciosas de
quando devem efetivamente entrar em ação. Tudo isso sob a supervisão do Gerente de Projetos, que deverá monitorar a
efetividade dos resultados dos planos de ação e, caso necessário, tomar outras ações corretivas para garantir a qualidade nos
resultados alinhados aos objetivos iniciais do projeto.
Vamos seguir em frente, porque o próximo assunto é muito interessante.
PLANOS DE CONTINGÊNCIA E DE
BACKUP
Olá, depois de percebermos a importância em designar os proprietários dos riscos, vamos aqui estudar mais algumas
responsabilidades destes stakeholders, no que consta sobre os planos de ação que devem ser implantados, caso algum evento
incerto ocorra.
Eventos incertos em projetos podem ser eliminados ou terem suas chances de acontecerem bem diminuídas, caso sejam
susceptíveis à mudança nos planos originais do projeto. Para aqueles eventos incertos que não comportam essa possibilidade,
temos que desenvolver os planos de contingência como respostas e que devem ser aplicados de acordo com a estratégia escolhida
como tratamento ao risco. Devemos ainda contemplar um plano backup para quando o tratamento ao risco (contingência) não
surtiu os efeitos desejados.
O plano de contingência
Segundo Mulcahy (2010), os planos de ação – ou planos de respostas aos riscos – que são colocados em execução caso aconteça
uma ameaça ou uma oportunidade são chamados de Planos de Contingência. Estes planos são desenvolvidos com antecedência,
ou seja, são planejados pelo time do projeto bem antes de o evento incerto ocorrer. Podem ser desenvolvidos tanto para as
ameaças como para as oportunidades, bastando para isso que seja escolhida uma ou mais estratégias de tratamento de riscos,
discutidas no início do capítulo 1.
De acordo com Greene e Stellman (2010), cada evento incerto no projeto deve ter pelo menos um plano de contingência atribuído
a ele. Obviamente, um mesmo evento incerto poderá ter mais de um plano de contingência como resposta, não importando se
tratamos de uma ameaça ou de uma oportunidade. Alguns fatores críticos como custos, prazos, qualidade e cumprimento do
escopo precisam ser analisados criteriosamente durante a elaboração e/ou execução do plano de respostas a um ou mais eventos
incertos, pois devemos atribuir ao risco o plano de contingência que traga mais benefícios e menor (ou de preferência nenhum)
efeito colateral. Na elaboração do plano de contingência, segundo ainda Greene e Stellman (2010), alguns quesitos precisam ser
observados, como segue:
I)Tome o devido cuidado para que haja um proprietário do risco (risk owner) atribuído ao evento incerto e ao respectivo plano
de contingência. Mesmo se houver mais de um plano de contingência para o mesmo evento, tenha certeza de que apenas um
proprietário do risco seja designado para observar os gatilhos e colocar o plano de ação em prática.
II)Os planos de contingência podem ser desenvolvidos pelo time do projeto, pelo proprietário do risco que muitas vezes detém
o conhecimento sobre o tema, por stakeholders que venham a contribuir para a estratégia de tratamento de cada evento ou
ainda por especialistas na área de assunto do risco, que podem agregar muito valor nos planos que responderão aos riscos
mapeados.
III)Os planos de contingência devem estar devidamente documentados e registrados, para que haja um controle eficaz sobre
eles e para que seja possível divulgá-los aos stakeholders e acompanhar seus andamentos, se foram implantados, se estão em
execução e quais foram os resultados obtidos. O repositório de registro de riscos apresentado no capítulo anterior é uma boa
sugestão de documentação destes planos.
IV) Para projetos mais complexos e riscos que envolvam muitas áreas poderá ser contemplado o proprietário das ações sobre os
riscos, aquele que deverá auxiliar o proprietário do risco implantando soluções já previamente aprovadas e reportar a ele sobre
os resultados obtidos.
V) Um bom plano de contingência deve conter pelo menos as informações do risco, qual a ação estratégica considerada a mais
adequada foi adotada, quem seria o proprietário do risco, o eventual proprietário das ações sobre os riscos – se aplicável –,
quem ou qual empresa/fornecedor deverá ser acionado em caso de necessidade, a devida data de ocorrência e se haveria algum
risco correlacionado com o evento incerto em questão. Outras informações que forem consideradas pertinentes pelo time do
projeto deverão ser agregadas ao plano.
Para nossa melhor compreensão, vamos elucidar aqui alguns exemplos do que seria um plano de contingência elaborado a partir
de um evento incerto previamente mapeado durante o planejamento dos riscos em um projeto.
Exemplo 1: Para um pequeno projeto que seria um evento de premiação a pesquisadores acadêmicos reconhecidos pela
comunidade científica nacional e internacional, há um risco de chover no dia do evento e comprometer a cerimônia, uma vez que a
mesma acontecerá em espaço aberto por conta de atrações externas. O plano de contingência adotado foi a mitigação do impacto
por meio da contratação de uma empresa especializada em coberturas temporárias e eficazes contra chuvas moderadas, que seria
suficiente para garantir o sucesso do evento. Essa empresa permaneceria de sobreaviso e, próximo à data do evento, seria
acionada para montagem da estrutura, caso houvesse uma alta probabilidade de chuva no período.
Exemplo 2: Para um projeto de desenvolvimento de um novo produto de uma indústria química foi identificado um risco de uma
empresa importadora não conseguir entregar a quantidade suficiente de um componente químico importado e específico,
considerado como matéria-prima base para a produção na escala desejada. O plano de contingência adotado foi evitar que o
evento ocorra, cadastrando e homologando um fornecedor local de um componente nacional e compatível, com perdas aceitáveis
no padrão de qualidade exigido pela companhia. Dessa forma, haveria como garantir o fornecimento contínuo do componente
substituto caso o importador não conseguisse atender à demanda.
O plano de backup
Imagine agora uma situação crítica: o que aconteceria se o plano de contingência não funcionasse de acordo com o planejado?
Temos que lembrar que nesse momento do projeto estamos lidando com eventos incertos que muito provavelmente causarão
impactos consideráveis no seu projeto. De acordo com Kerzner (2009), caso o plano de contingência não funcione conforme
desejado devemos ter um plano alternativo caso este venha a falhar. A este plano chamamos de plano de backup .
Seria algo como o plano ‘A’, ou o planejamento original da atividade (ou um conjunto delas), que precisou de um plano ‘B’, ou o de
contingência para garantir que obtivéssemos sucesso e, em caso de falha deste, fosse necessário ainda utilizarmos o plano ‘C’ para
que aumentássemos ainda mais a chance de sucesso não só das atividades, mas de uma forma contínua e iterativa, o sucesso do
projeto como um todo.
Caso o plano de backup deva ser colocado em prática, a responsabilidade por fazê-lo continua sendo do proprietário do risco, que
observou o gatilho relacionado ao evento incerto, colocou em execução o plano de contingência correspondente, mensurou sua
eficácia e, como não obteve o resultado esperado lançou mão do plano de backup previamente elaborado e aprovado pelo time do
projeto. Em alguns casos, conforme comentado anteriormente, essa função pode ser desempenhada pelo proprietário das ações
dos riscos, que irá executar o plano backup e reportar ao proprietário do risco os efeitos decorrentes de tal ação.
Compreenda que o ‘gatilho’ nesse caso seria a constatação de que os resultados obtidos pela execução do plano de contingência
não surtiram os efeitos desejados e, previamente, planejados. O plano de backup deve ser elaborado de uma maneira bem similar
ao plano de contingência, inclusive observando-se os quesitos de I a V descritos anteriormente. Para uma melhor compreensão,
vamos tomar os exemplos dos planos de contingência descritos anteriormente e avaliar como seriam elaborados os planos backup
de cada um como resposta aos riscos:
Exemplo 1 Imagine que no dia do evento as coberturas temporárias para chuvas moderadas já tivessem sido instaladas pela
:
empresa contratada, pois as probabilidades de chuvas no dia do evento eram muito altas. Porém, horas antes do início do evento,
fortes chuvas e ventos comprometessem inclusive as estruturas previamente montadas para acomodar os convidados,
impossibilitando a cerimônia ao ar livre. Como o plano de contingência falhou, o plano backup seria acionado e a cerimônia
aconteceria em um salão previamente reservado, abrindo mão nesse caso das atrações externas. Houve mudanças em relação ao
plano original, porém sem comprometer o objetivo principal do projeto que era a cerimônia de premiação dos pesquisadores
acadêmicos.
Exemplo 2: Imagine agora a situação em que o importador não consiga atender à demanda do componente importado específico e
o fornecedor do produto substituto compatível também sinalize que não poderá efetuar as entregas dos lotes adquiridos do
componente nacional. O plano de contingência – dessa vez com um impacto absorvível de qualidade do produto – falhou e um
plano de backup deverá ser posto em ação. Para tanto, a equipe do projeto considerou o cadastro e homologação de um segundo
fornecedor local do componente substituto. Mesmo os preços do segundo fornecedor sendo mais altos, os objetivos do projeto
foram alcançados e o impacto de custos foi absorvido no projeto, após os estudos de viabilidade demonstrar que essa seria uma
saída alternativa.
Note que, em ambos os casos houve impacto de custos após a implantação dos planos de respostas aos riscos (levando em
consideração também o impacto na qualidade, pois não houve atrações externas no primeiro caso e perda absorvível de qualidade
no novo produto químico). Segundo Dinsmore e Cabanis-Brewin (2009), os custos das alternativas de respostas devem ser
calculados e registrados com antecedência, ou seja, ainda na fase de planejamento do projeto e da gestão de riscos. Nos exemplos
citados, tanto a reserva e utilização do salão como pagar mais caro por lotes de matéria-prima do componente químico substituto
gerariam custos que não estavam previstos no orçamento original do projeto.
Para que seja possível implantar os planos de respostas – tanto o plano de contingência como o plano backup – e por em prática as
ações pertinentes a cada um deles que possam gerar custos, devemos fazer uso da reserva de contingência, ou seja, um montante a
ser acrescentado no orçamento original. Existem algumas formas de cálculo dessa reserva, porém a mais recomendável segundo
Mulcahy (2010) é a que é determinada de acordo com o grau de riscos do projeto. Dessa maneira, quanto mais complexo e longo
for o projeto, maiores serão os riscos e suas complexidades, aumentado o montante da reserva de contingência.
Devemos lembrar ainda que a reserva de contingência é um montante que deverá ser utilizado em caso de implantação de um
plano de contingência ou de backup e que, após a utilização deste recurso, o Gerente de Projetos e sua equipe deverão prestar
contas do dinheiro utilizado aos investidores. Caso nem todos os planos de respostas sejam implantados, por conta de alguns
eventos incertos não terem se manifestado, esta reserva deverá ser parcial e, proporcionalmente, devolvida aos patrocinadores do
projeto.
Cuidado com os planos de contingência e de backup. Eles podem gerar impactos maiores que os próprios
riscos. Pode até parecer estranho, porém alguns gerentes de projetos ou mesmo o próprio time de trabalho
podem criar planos de respostas que podem gerar impactos financeiros – ou até mesmo impactos nos
prazos – maiores do que os riscos (ameaças) originais. É necessário que o gerente de projetos tome alguns
procedimentos para garantir que este erro crasso não seja cometido no seu projeto.
Fonte: Kerzner (2009).
Segundo Mulcahy (2010), uma das boas práticas de gestão de riscos é registrar os eventos, suas características e toda e qualquer
informação pertinente que venha a auxiliar na gestão e tratamento dos eventos incertos. Portanto, os registros dos planos de
contingência e de backup são também elegíveis a fazerem parte do registro de riscos do projeto. Na figura 3, podemos observar a
inclusão destas informações, complementando os registros iniciais da gestão de riscos do projeto:
Figura 3 – Modelo de Registro de Riscos com planos de contingência e de backup acoplados
Note que neste momento de registro de riscos, a coluna de ‘provável resposta ao risco’ foi complementada pelas colunas de ‘plano
de contingência’ e de ‘plano de backup que são efetivamente as colunas nas quais se deverão detalhar os planos de tratamento do
’,
evento incerto com as informações necessárias para esse fim.

Este modelo poderá tanto ser usado no mapeamento e planejamento dos planos de respostas aos riscos quanto durante as
reuniões de andamento e status do projeto com a alta administração da companhia. De acordo com Dinsmore e Cooke-Davies
(2006), os registros dos riscos deverão se tornar um pequeno banco de dados com informações sobre os eventuais riscos inerentes
ao projeto, que deverá ser alterado e atualizado sempre que houver mudanças significativas. Novos riscos deverão ser
adicionados, analisados e tratados como em um processo contínuo até a realização completa do projeto.
Perceba ainda que para os planos de contingência e de backup os gatilhos deverão ser identificados e monitorados, pois estes
alertas servirão como indicadores de que os devidos planos deverão ser postos em ação. Podemos identificar os gatilhos que
estavam sendo monitorados observando os exemplos 1 e 2 em ‘O plano de backup’. No exemplo 1, o gatilho do plano de backup
seria a incidência de fortes chuvas e ventos, comprometendo a realização do evento nas áreas externas e no exemplo 2 seria o
fornecedor homologado pelo plano de contingência sinalizar que não poderia cumprir como os acordos de entregas da matéria-
prima necessária para o projeto. Nos dois casos, como já vimos, os planos de backup (ou planos ‘C’) tiveram de ser implantados, pois
os respectivos planos de contingência (planos ‘B’) fatalmente falharam.
Segundo Greene e Stellman (2010), a gestão de riscos em projetos requer, principalmente em projetos mais complexos, um plano
meticuloso e detalhado, às vezes até contemplando a redundância da contingência como respostas aos eventos incertos, para que
as ameaças sejam tratadas e as oportunidades elevadas, e o seu projeto se aproxime mais da possibilidade de ser implantado com
sucesso.
As boas práticas de gestão riscos sugerem que haja um planejamento prévio e um plano de ação elaborado e
associado a cada um dos eventos incertos que necessitem de solução durante o ciclo de vida do projeto.
Você poderia se imaginar como gerente de projetos de um projeto no qual não houvesse preocupação
nenhuma com mapeamento de riscos e cada evento – por menor que fosse – se apresentasse como uma
surpresa pronta para ser trabalhada, e ainda de maneira bem recorrente?
Fonte: o autor.
Chegamos ao final do nosso estudo preliminar sobre os planos de respostas aos riscos em projetos. Ao final deste estudo podemos
observar que a elaboração dos planos de contingência e de backup é uma tarefa nada fácil e que se faz necessário o auxílio de
especialistas, muitas vezes da área da companhia pertinente aos eventos incertos, para que a eficácia dos planos seja satisfatória.
Aliado a estas práticas, o registro constante dos riscos e a manutenção da informação se mostra crucial para uma gestão de riscos a
qual venha agregar valor aos resultados do projeto.
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.
Avançar

ATIVIDADES
1.A estratégia de tratamento de riscos que geralmente reduz as chances ou o impacto de um evento incerto sem que os objetivos
do projeto sejam alterados, é chamada de:
a) Evitar
b) Aceitar
c) Mitigar
d) Explorar
e) Transferir
2.Eventos futuros que podem prover efeitos positivos e valores agregados aos resultados do projeto quando bem tratados são
chamados de:
a) Riscos favoráveis
b) Elementos surpresas
c) Relações risco-benefício
d) Oportunidades
e) Contingências
3. Qual das seguintes alternativas melhor descreve a estratégia de evitar os eventos incertos durante o planejamento de respostas
aos riscos?
a) Reduzir as chances de o evento ocorrer.
b) Delegar as responsabilidades para um terceiro.
c) Eliminar a ameaça atuando na sua causa raiz.
d) Não tomar nenhuma ação proativa e registrar o ocorrido.

e) Compartilhar o ocorrido com o maior número de stakeholders quanto possível.
4.Você, que é o gerente de projetos de uma empresa, está analisando junto à sua equipe alguns riscos que ocorreram por conta das
respostas de outros riscos do projeto. Estamos falando de qual tipo de riscos?
a) Riscos identificados e mapeados
b) Riscos secundários
c) Riscos complementares
d) Riscos residuais
e) Riscos cumulativos
5 Assinale V (verdadeiro) ou F (falso) nas sentenças

. a respeito dos riscos residuais e secundários nos projetos:
( )Riscos residuais são aqueles que permanecem mesmo após estratégias aplicadas segundo o plano de respostas aos riscos.
( )Riscos residuais são aqueles causados após uma estratégia de resposta a um risco primário ter sido implantada.
( )Riscos secundários são aqueles que permanecem mesmo após estratégias aplicadas segundo o plano de respostas aos riscos.
( )Riscos secundários são aqueles que a equipe decidiu por aceitar passivamente, uma vez que seus impactos eram
insignificantes aos resultados esperados do projeto.
a) F, F, V, V
b) V, V, F, F
c) V, F, V, F
d) V, F, F, F
e) F, F, V, F
6 Você (gerente do projeto) e sua equipe e mais alguns stakeholders estão discutindo sobre os riscos de uma lista recém-revisada,
.
quando percebem e identificam alguns riscos considerados residuais dentre outros na lista. O que seria mais recomendado que
vocês fizessem com estes riscos residuais?
a) Absolutamente nada. São riscos que a própria equipe decidiu por aceitá-los passivamente.
b) Implantar os planos de contingência ou de backup, caso os riscos ocorram.
c) Deixar estes riscos em uma lista de espera.
d) Como eles foram gerados por meio de um risco primário, tratá-los com baixa prioridade.
e) Reunir-se com mais stakeholders e solicitar a opinião deles.
7 Associe cada sentença com seu respectivo significado,

. a seguir:
I. Proprietário do risco
II. Riscos secundários

III. Proprietário das ações sobre os riscos
IV. Gatilhos
V. Riscos residuais
( )Alertas ou sinais que demonstram que o risco está prestes a ocorrer ou que acabou de ocorrer.
( )Riscos que são gerados por meio da implantação de uma resposta a um outro risco.
( )Pessoa designada pelo proprietário do risco para implantar soluções e respostas pré-aprovadas aos riscos.
( )Riscos que permanecem mesmo após mudanças terem sido feitas no plano original do projeto.
( )O stakeholder designado pelo Gerente de Projetos que deverá monitorar os alertas e possíveis sinais de que o risco está
prestes a acontecer ou que acabou de acontecer e tomar as devidas ações previamente planejadas.
Assinale a alternativa correta.
I. I – II – III – IV – V.
II. II – I – IV – III – V.
III. IV – II – III –V – I.
IV. III – II – I – V – IV.
V. V – III – I – IV – II.
8. Qual das alternativas, a seguir, NÃO deveria fazer parte do registro de riscos?
a) Matriz de probabilidade e impacto
b) Causas raiz
c) Potencial proprietário do risco
d) Gatilhos
e) Categoria do risco
9. O gatilho de um risco pode ser interpretado como:
a) Um evento incerto que ainda não ocorreu.
b) Documentação exclusiva para o proprietário do risco reportar os resultados ao Gerente de Projetos.
c) Um alerta ou sinal prévio indicando que um risco ocorreu recentemente ou que está prestes a ocorrer.
d) Um esboço do planejamento de riscos indicando quando e o que fazer caso um risco mapeado ocorra.
e)Um aviso de que o proprietário de um risco recém reportou os resultados obtidos ao Gerente de Projetos, após a
implantação de uma resposta previamente aprovada para um risco.
10. O plano de contingência se difere do plano de backup, pois o plano de backup:
a) É posto em ação depois do plano de contingência.
b) Pode ser criado antes do plano de contingência.
c) Pode requerer aprovação da alta administração, ao passo que o plano de contingência já é previamente aprovado.
d) É gerenciado pelo Gerente de Projetos enquanto que o plano de contingência é gerenciado pelo proprietário do risco.
e)É de responsabilidade do proprietário do risco e o plano de contingência é de responsabilidade do proprietário das ações
sobre os riscos.
11. Durante a execução de um projeto um risco que havia sido identificado de fato ocorreu e o plano de contingência foi acionado.
Quais das seguintes ações o gerente de projetos deveria fazer enquanto o proprietário do risco coloca em ação o plano de
contingência?
a) Fazer a análise qualitativa do risco.
b) Criar o plano de backup.
c) Auxiliar o proprietário do risco.
d) Verificar se o plano de contingência é adequado e, caso não seja, ajustá-lo adequadamente.
e) Levar ao conhecimento da alta administração sobre o gatilho que disparou o plano de contingência.
12. Um risco (ameaça) previamente identificado e mapeado ocorreu em um projeto, porém, o gerente de projetos deste projeto
não pôde ser localizado. Qual seria a melhor das alternativas a ser colocada em prática nesse caso?
a) Solicitaria auxílio da alta administração da empresa.
b) Tentaria improvisar uma medida paliativa até que o gerente de projetos fosse encontrado.
c) Implantaria o plano de contingência.
d) Implantaria um plano de contingência que foi utilizado em um projeto similar, e prepararia um relatório completo sobre os
resultados para quando o gerente de projetos fosse localizado.
e) Acionaria o time do projeto para discutir sobre uma possível solução.
Avançar

RESUMO
Ao final desta unidade, compreendemos o quão é importante termos o discernimento de que eventos incertos em projetos podem
se apresentar tanto na forma de ameaças como de oportunidades. Para tanto, torna-se altamente recomendável que você
monitore durante o ciclo do projeto não só os eventos incertos com impactos negativos e domine as técnicas e ferramentas
utilizadas para tratá-los, como também poder identificar e fazer acontecer os eventos com impactos positivos, muitas vezes
benéficos aos resultados do projeto.
Vimos que, ao se deparar com as ameaças do projeto devemos ter o discernimento correto para identificar e aplicar de maneira
eficaz qual a estratégia de tratamento mais adequada. Teremos que decidir se atuaremos na sua origem e evitaremos que a ameaça
ocorra, se poderemos atuar na redução da chance do evento ocorrer ou somente no impacto após ter ocorrido ou ainda se iremos
transferir este risco de maneira que o conjunto de atividades de alto risco possa ser executado por profissionais mais qualificados
para tal tarefa. Da mesma maneira, percebemos que as estratégias de tratamento de oportunidades, depois de aplicadas, devem
elevá-las às condições necessárias para que ocorram e tragam ótimos resultados aos objetivos do projeto.
Aprendemos ainda que os riscos residuais são aqueles que permanecem mesmo depois de os planos do projeto terem sido
alterados por meio das análises prévias e que carecem de um plano de resposta adequado para que não comprometam os
resultados do projeto. Vimos ainda que, mesmo depois de implantarmos um plano de contingência (ou o plano ‘B’) como resposta a
um evento incerto, outros riscos podem ser gerados e necessitam de ser tratados com a mesma eficácia. A estes chamamos de
riscos secundários.
Estudamos também a importância de um ‘ator’ importante na gestão de riscos, o proprietário do risco, que deverá monitorar os
eventos do projeto e perceber se o gatilho (ou sinal de alerta) se manifestou e demonstra que o risco está na iminência de
acontecer ou se já aconteceu. Para tanto, deverá executar o plano de contingência previamente elaborado e, caso não tenha obtido
sucesso, aplicar o plano de backup (ou plano ‘C’) para garantir a eficácia das estratégias de tratamento de riscos, minimizando ao
máximo os danos no projeto.
Você também deve ter percebido a importância da utilização e atualização dos registros dos riscos, repositório responsável por
dar visibilidade e controle sobre os riscos identificados e mapeados, de forma que possam ser tratados de maneira adequada pelo
time do projeto, sem que haja muitas possibilidades de perda ou de comprometimento das informações manipuladas sobre os
eventos incertos do projeto.
De posse destas e de outras técnicas, ferramentas e boas práticas de gestão de riscos, além de muita dedicação ao planejamento
adequado e ao controle na execução dos planos elaborados, tenha certeza de que você contribuirá e muito para que os resultados
dos projetos estejam o mais próximo e fiel possível aos objetivos previamente traçados.
Uma ótima jornada a todos.
Avançar

Na Web
apresenta um podcast de dezembro de 2007 explicando as mais variadas
respostas que podem ser dadas aos riscos em projetos, visando reduzir ao
máximo os impactos negativos do projeto, bem como alavancar os seus
resultados favoráveis. 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

REFERÊNCIAS
DINSMORE, P. C.; CABANIS-BREWIN, J. AMA manual de gerenciamento de projetos Rio de Janeiro: Brasport, 2009.
.
DINSMORE, Paul C.; COOKE-DAVIES, Terence J. The right projects done right !.01.ed. JosseyBass, 2006.
KERZNER, H. Project Management: A systems approach to planning, scheduling and controlling. 10. ed. New York: John Wiley &
Sons Inc., 2009. p. 753-788.
MAXIMIANO, A. C. A. Administração de Projetos como transformar ideias em resultados. 05. ed. São Paulo: Atlas, 2014.
:
MULCAHY, R. Risk Management: Tricks of the Trade for Project Managers and PMI-RMP Exam Prep Guide. 02. ed. RMC
SBRAGIO, R. Engenharia Econômica e Análise de Riscos. Escola Politécnica da Universidade de São Paulo, 2009.
SECRETARIA de Estado da Defesa Civil, Governo de Santa Catarina. Disponível em:

http://www.defesacivil.sc.gov.br/index.php/gestao-de-risco-2013/plano-de-contigencia-2013.html . Acesso em: 12 jul. 2016.
SILVA, L. F. C. P. Gestão de riscos em tecnologia da informação como fator crítico de sucesso na gestão da segurança da
informação dos órgãos da administração pública federal: estudo de caso da Empresa Brasileira de Correios e Telégrafos – ECT.
Disponível em: http://repositorio.unb.br/handle/10482/7473 Acesso em: 12 jul. 2016.
.
VARGAS, R. V. FIVE minutes podcast Disponível em: http://www.ricardo-vargas.com/pt/podcasts/ Acesso em: 12

. . jul. 2016.
VARGAS, R. V. Manual prático do plano de projeto utilizando o PMBOK Guide . 3. ed., Rio de Janeiro, Editora Brasport, 2007.
Avançar

APROFUNDANDO
GESTÃO DE RISCOS DE UM PROJETO DE TECNOLOGIA DA

INFORMAÇÃO PARA A EMPRESA BRASILEIRA DE CORREIOS E
TELÉGRAFOS – ECT – DE BRASÍLIA DISTRITO FEDERAL
Em 2010 foi feito um estudo de caso sobre a Gestão de Riscos aplicada a um projeto de Segurança da Informação da Empresa
Brasileira de Correios e Telégrafos do Distrito Federal. O intuito principal, ou a hipótese apresentada por Silva (2010), era de
demonstrar a eficácia da aplicabilidade das boas práticas de Gestão de Riscos associada aos preceitos da Segurança da Informação
em sistemas de Tecnologia da Informação para a companhia.
Segundo Silva (2010), um dos processos que contribuiu significativamente para corroborar com a hipótese levantada foi o
processo de tratamento dos riscos, no qual se estabelecia ações específicas acerca dos eventos incertos que haviam sido
mapeados previamente. Estas ações específicas se traduziam nos planos de contingência e de backup para o devido tratamento e
aplicação das estratégias de respostas aos riscos relacionados à Segurança da Informação dos sistemas correntes da companhia.
De acordo com Silva (2010), foi feita uma comparação entre dois projetos distintos, porém da mesma natureza, ou seja,
implantação da Segurança da Informação em sistemas de TI. Dentre os projetos, apenas um contemplava as boas práticas de
gestão de riscos em projetos associadas aos elementos de Segurança da Informação e suas possíveis ameaças e vulnerabilidades.
Silva (2010) afirma que as hipóteses iniciais foram confirmadas, pois se admitiu a proposição de que a Segurança da Informação
aplicada a sistemas de Tecnologia da Informação é mais eficiente e eficaz quando adotada a Gestão de Riscos em projetos desta
natureza.
O ponto mais significativo gerado pela inserção da Gestão de Riscos neste tipo de projeto foi a mudança de paradigma gerada nos
principais stakeholders do projeto, os quais mudaram seus conceitos com relação ao grau de tolerância aos eventos incertos. Ao
serem submetidos aos processos de análise de probabilidade e impacto das possíveis ameaças e vulnerabilidades, bem com o
devido tratamento das oportunidades a serem exploradas no projeto, estes stakeholders obtiveram o aprimoramento de seus
conceitos não só à tolerância aos graus de riscos como também a devida importância à elaboração dos planos de respostas aos
eventos incertos previamente identificados e mapeados, proporcionando benefícios inúmeros nos resultados esperados ao
término do projeto.
Fonte: Silva (2010, on-line).
PARABÉNS!
Avançar

EDITORIAL
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ Núcleo de Educação .
a Distância; SAMPAIO Paulo. ,
51 p.
CDD - 22 ed. 658
Fotos Shutterstock
:
Retornar

MONITORAMENTO,
CONTROLE E
GOVERNANÇA DE
RISCOS
Professor (a) :
Me. Paulo Sampaio
• Levar ao conhecimento do(a) aluno(a) sobre a importância do estabelecimento de métricas e indicadores para auxiliar no
diagnóstico de execuçãodos planos de respostas aos riscos.
• Compreender as necessidades de se estar em conformidade com os planos de gestão dos riscos durante os processos de
execução do projeto.
• Identificar as melhores técnicas para se tomar as devidas decisões e implantar as ações corretivas para trazer o projeto ao seu
curso natural.
• Reconhecer as melhores políticas, procedimentos, padrões e boas práticas de gestão de riscos a serem implantadas nas
organizações.
• Compreender a importância da instauração de auditoria de riscos no intuito de buscar a melhoria contínua nos processos de
gestão de riscos dos projetos.
• Entender a importância do estabelecimento da governança de riscos, incentivando uma cultura de gestão de riscos nas
companhias.
• Reconhecer e compreender os benefícios providos pelo uso de uma base de dados histórica de riscos, proveniente das lições
aprendidas sobre os riscos nos projetos das organizações.
Plano de estudo
• Garantia da conformidade e métricas
• Tomada de ações corretivas e avaliação da efetividade
• Padrões, procedimentos, políticas e boas práticas
• Auditorias, lições aprendidas e comprometimento dos stakeholders
Introdução
Caro(a) aluno(a), nosso estudo baseia-se nas abordagens sobre as boas práticas, técnicas e ferramentas aplicadas à gestão de
riscos em projetos, independentemente da sua natureza ou origem. Na verdade 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 a efetividade dos planos de respostas aos riscos previamente elaborados para cada risco
identificado no projeto. Observaremos ainda as implicações e impacto da implantação destes planos de ação, buscando sempre
gerenciar e controlar o progresso do plano de riscos. Estudaremos a elaboração e aplicação de métricas apropriadas que irão nos
auxiliar a identificar se o planejamento de riscos está sendo executado de acordo com o que foi planejado e se está em
conformidade com os planos iniciais do projeto. Estudaremos como fazer o uso correto das reservas de prazo e de custo que são
utilizadas como reservas de contingência no caso da ocorrência do risco já mapeado, analisado e com seu devido plano de resposta
desenvolvido.
Em seguida, compreenderemos como os processos de medição do status do projeto podem nos auxiliar na aplicação das ações
corretivas e/ou alternativas de solução, quando aplicáveis, com o intuito de trazer o projeto de volta ao seu curso original.
Estudaremos o emprego da análise de valor agregado em projetos, uma ferramenta prática que pode nos auxiliar a reavaliar os
planos de respostas aos riscos desenvolvidos previamente. Poderemos ainda observar que nem todo risco pode se mapeado
durante a fase de planejamento. Para estes riscos que certamente surgirão ao longo do desenvolvimento do projeto teremos que –
após analisar a intensidade do impacto que poderão causar – criar novos planos de respostas a estes riscos.
Prosseguindo, abordaremos quais seriam as melhores políticas, procedimentos, padrões e boas práticas relativas à gestão de
riscos em projetos que deveriam ser implantadas nas organizações que desenvolvem projetos frequentemente. Veremos que, uma
vez que o plano de gestão de riscos esteja desenvolvido, não significa que ele não deva ser revisitado e reavaliado.
Compreenderemos que o plano do projeto não pode ser ‘engavetado’ depois de pronto, temos que encará-lo como um documento
vivo com processos que precisam ser revisados constantemente para, inclusive, aumentarmos as chances de que o plano seja
implantado de maneira correta e eficaz. Analisaremos o grau de tolerância de riscos por parte dos stakeholders do projeto e da
companhia como um todo.
Por fim, avaliaremos a importância do estabelecimento de auditorias periódicas nos processos de gestão dos riscos, bem como
entender a necessidade de processos comunicacionais eficazes ao longo do ciclo de vida e os benefícios propostos pela
implantação de uma governança de riscos. Estudaremos como a utilização das informações provenientes das lições aprendidas
registradas a partir de experiências obtidas dos processos de gestão de riscos pode fazer grande diferença em projetos posteriores
nas organizações.
Bem, tenho plena certeza de que sua curiosidade já foi despertada. Então, vamos juntos embarcar nessa jornada que está pra lá de
motivadora.
Avançar

GARANTIA DA CONFORMIDADE E
MÉTRICAS
Olá! Seja bem-vindo (a) aos nossos estudos sobre gestão de riscos em projetos, mais especificamente sobre o controle e
monitoramento de riscos, dando ênfase nas boas práticas de estabelecimento de métricas e da garantia de estar em conformidade
com o planejamento original e inicial. Espero que você aproveite muito o conteúdo que aqui será abordado.
Os processos de controle e monitoramento de riscos requerem não só a aplicabilidade do plano de respostas aos riscos, a
observação das suas implicações e o gerenciamento do progresso do plano de riscos previamente elaborado, mas também o
estabelecimento e aplicação de métricas para garantir que o plano de riscos seja executado de acordo com o que foi planejado. É a
partir destes processos que será possível a identificação da eficácia do plano de riscos, se estes planos estariam sendo executados
em conformidade com o planejamento prévio pela equipe de projetos. É por meio do controle e monitoramento de riscos que você
perceberá se os planos foram bem elaborados ou se precisam de ajustes para se tornar eficazes.
Aplicação dos planos de respostas aos riscos e a garantia da

conformidade
Nessa fase do projeto é que poderemos realmente perceber o quanto o planejamento elaborado terá um real efeito positivo (ou
não) sobre os riscos identificados e tratados pela equipe do projeto. De acordo com Dinsmore e Cabanis-Brewen (2009), existe
uma grande necessidade em atender a todos os riscos identificados na fase ainda de planejamento, pois somente assim será
possível responder a novos riscos e desenvolver novas respostas, durante todo o ciclo de vida do projeto.
Isso porque a gestão de riscos se apresenta como um processo cíclico, ou seja, não deveria ser feito apenas uma vez no projeto. Se
você e sua equipe elaborarem um excelente plano de gestão de riscos ainda na fase de planejamento do projeto e, estando pronto
este plano, encerrar as atividades de monitoramento de novos riscos e engavetar seu plano para uso somente caso aconteçam os
eventos ali mapeados, estará perdendo inúmeras chances de identificação e tratamento de novos riscos que certamente ocorrerão
durante o desenvolvimento do projeto. Todos os seus esforços até então terão resultados parcialmente satisfatórios e seu projeto
estará inevitavelmente ameaçado.
Segundo Dinsmore e Cabanis-Brewen (2009), a etapa de monitoramento e controle requer atenção exclusiva às aplicações dos
planos de respostas previamente elaborados aos riscos mapeados, assim como a observação de novos eventos incertos que
aparecerão regularmente no projeto. É muito importante estabelecer um processo robusto de comunicação em diferentes níveis
para os diferentes stakeholders por meio da produção de modelos de relatórios de riscos continuamente elaborados e revisados
pela equipe do projeto. Afinal, o propósito maior seria gerenciar efetivamente os eventos incertos que, muito provavelmente,
envolveria não só a equipe direta do projeto assim como outros stakeholders de outras áreas e departamentos da companhia.
Nesse ínterim, uma boa prática que se faz comum nos processos de monitoramento e controle de projetos é o estabelecimento de
reuniões de avaliação periódicas – também chamadas de reuniões de andamento, reuniões executivas ou de apresentação de
status do projeto – para que sejam revisados os pontos de controle e para que seja atualizado o registro de riscos (repositório
único e acumulativo de registro dos eventos incertos do projeto, de responsabilidade de controle pelo gerente de projetos). A
revisão do registro de riscos faz parte do processo de controle dos riscos, pois aumenta as chances de avaliação da implantação
dos planos de respostas, bem como auxilia nos processos de identificação de novos riscos. As reuniões de andamento.
A exposição aos riscos varia constantemente seja por fatores internos e/ou externos, por ações – ou inações – dos diferentes
stakeholders, incluindo fornecedores, colaboradores e até mesmo os patrocinadores e maiores interessados nos resultados do
projeto. Portanto, o monitoramento constante sobre novos eventos é uma boa prática que permite identificar tanto novas
ameaças quanto oportunidades ao longo de todo o ciclo de vida do projeto. Para os processos de gestão de riscos, permanecer
inerte e reativo significa “andar para trás”.
A maioria dos gerentes de projetos sabe que devem permanecer em constante observação sobre as
atividades que pertencem ao caminho crítico do projeto, ou seja, aquelas atividades que se sofrerem atraso
poderão comprometer a data final de entrega do projeto. Dessa forma, seria também interessante
determinarem no conjunto de atividades que compõem o escopo aquelas que representariam um novo
‘caminho crítico’, mas dessa vez com os riscos que tivessem os maiores níveis de ‘risk score’ (maior chance de
acontecer com o maior impacto aos resultados esperados). Isso não significaria que os eventos incertos
ocorreriam em sequência como as atividades do caminho crítico e sim que o caminho das atividades com os
maiores ‘risk score’ deveriam ser gerenciado tão de perto quanto as do caminho crítico. Fonte: Mulcahy
(2010).
A garantia da conformidade na gestão de riscos, segundo Greene e Stellman (2010), pode ser compreendida como o atendimento
pleno durante a execução de um plano de resposta a um evento incerto que tenha ocorrido, eliminando os impactos negativos
produzidos por ele ou, na pior das hipóteses, deixando-o gerenciável. A simples análise dos resultados após a implantação da
resposta ao risco pode prover esse grau de informação.
O estabelecimento de métricas também pode ser uma boa prática para identificar o atendimento à conformidade dos processos de
gestão de riscos. Podemos tomar como exemplo a comparação que pode ser feita entre o real desempenho do projeto com o
planejado, por se tratar de uma forma de dizer se um ou mais riscos já aconteceram ou têm grandes chances de acontecer. Se você
por acaso descobrir que está acima do orçamento planejado para uma data específica de medição, um risco que você não previu
pode estar surgindo.
De acordo com Greene e Stellman (2010), procurar por tendências e/ou padrões nas variações de prazos e custos durante o
desenvolvimento do projeto pode muitas vezes indicar que riscos aconteceram antes que você pudesse tê-los mapeados com
antecedência. De qualquer forma, esta seria uma ação proativa e o isentaria de ser um gerente de projetos e riscos que age de
forma sempre reativa a problemas inerentes a todo e qualquer projeto de qualquer natureza.
Fatores que podem influenciar na eficácia da gestão de riscos do

projeto
Segundo Dinsmore e Cabanis-Brewen (2009), existem algumas questões que precisam ser consideradas para que a gestão de
riscos esteja mais próxima de ser eficaz. O principal deles seria o fato de que o gerenciamento de riscos (e mesmo outros planos do
projeto) é feito e executado por pessoas. Pode parecer óbvio, mas deve ser relevado o fato de que introduzir o fator humano no
quadro requer gerenciamento proativo, pois as atitudes (ou a falta delas) das pessoas exercem influências significativas sobre os
processos do risco, que deve ser reconhecido e gerenciado.
A situação pode ainda ser agravada quando há conflitos de interesses múltiplos nos resultados dos objetivos traçados,
comprometendo ainda mais o panorama de riscos do projeto.
Outro fator que tem influência significativa é a cultura da organização patrocinadora do projeto, também conhecido pelos ativos
de processos organizacionais ou ainda o modus operandi característico da companhia. A falta de respaldo da alta administração
‘ ’
que pode não dar a devida credibilidade aos processos de gestão de riscos, que considera a alocação de recursos para tratamento
dos riscos como desperdício ou que considera a existência de uma ameaça como um sinal de fraqueza, além de outras condutas
similares, pode ser determinante no sucesso ou não da gestão de riscos, aproximando ou afastando os resultados dos processos da
eficácia desejada.
Mais um fator que pode ter influências (positivas ou negativas) é a existência (ou não) de uma infraestrutura apropriada que dê
suporte aos processos de gestão de riscos na companhia. As ferramentas de software adequadas, a capacitação dos colaboradores,
elaboração de modelos, contratação de serviços especializados etc. exercem uma papel fundamental na eficácia da gestão de
riscos. Estes recursos aliados à integração de outros elementos de gestão do projeto contribuem e muito para os fatores de
sucesso do gerenciamento de riscos nos projetos
A intenção de observar estes fatores é a de identificar, buscar e promover nas organizações a maturidade necessária para uma
gestão de riscos eficaz. Dinsmore e Cabanis-Brewen (2009) nos alerta que o desenvolvimento de uma cultura de gestão de riscos
nas empresas sugere pró-atividade e eficácia nos processos de tratamento dos eventos incertos, proporcionando pessoas
capacitadas que utilizam ferramentas adequadas e apropriadas para lidar com as incertezas nos projetos. A união destes fatores
em caráter positivo leva a crer que não haveria motivos para que os riscos fossem temidos, muito ao contrário, seriam até bem
vistos como uma oportunidade de poder trabalhar e fortalecer as fraquezas e de explorar os eventos incertos com impactos
positivos, no intuito de beneficiar os resultados esperados.
Segundo o que nos diz Kerzner (2009), subestimar a complexidade de um projeto e de seu conjunto de incertezas pode ser um erro
fatal e irreversível. Por mais simples que possa parecer em primeira instância, todo e qualquer projeto é inerente a eventos
incertos que podem vir tanto a prejudicar como trazer coisas boas que devem ser aproveitadas a qualquer momento .
Mas isto se torna possível apenas quando incutirmos, além das boas práticas de identificação, análise e tratamento dos riscos, o
controle e o monitoramento constante para concluirmos se as ações planejadas e implantadas surtiram (ou não) os efeitos
esperados ou se necessitam de ajustes para que haja melhoria contínua nos processos de gestão de riscos.
Os benefícios obtidos a partir da utilização de uma abordagem estruturada de gerenciamento de riscos são, segundo Kerzner
(2009), evidentes. Proporcionam projetos mais bem sucedidos, menor número de surpresas, menos desperdícios e retrabalhos,
uma equipe mais motivada, menos amadorismo e empirismo nos processos, mais credibilidade por parte da alta administração,
eficácia elevada, além de outros tantos. Dessa maneira, para termos uma melhor compreensão, Kerzner (2009) arrisca dizer que o
conjunto de processos de gestão de riscos está, dentre os elementos da gestão de projetos, como a mais importante área de
conhecimento aplicada no gerenciamento de projetos.
Para que possamos fixar bem quais são os fatores de influência na eficácia da gestão de riscos vamos
apresentá-los de forma sintetizada e resumida. Gerenciamento de riscos é feito por pessoas e, portanto,
tem caráter humano inserido no contexto e exige o gerenciamento proativo de recursos humanos. A cultura
da organização e seus processos internos influenciam significativamente os resultados da gestão de riscos,
principalmente por refletir a identidade da empresa nos processos e resultados esperados na gestão dos
eventos incertos do projeto. A utilização de uma estrutura e ferramental adequado, além da formação e
capacitação do pessoal envolvido é outro fator de relevância para a eficácia, pois a falta da abordagem
estruturada leva a deficiências que levam ao fracasso as tentativas de se fazer uma gestão de riscos com
resultados satisfatórios. A união destes fatores em caráter positivo sugere que os riscos não deveriam ser
temidos, e sim encarados como oportunidades para que a organização pudesse lidar com suas fraquezas e
forças, tratando as ameaças e aproveitando os eventuais benefícios que possam surgir ao longo do ciclo de
vida do projeto. Fonte: Dinsmore e Cabanis-Brewin (2009).
A gestão das reservas de contingência e de gerenciamento
De acordo com Mulcahy (2010), o gerente de projetos trabalhou muito durante a fase de planejamento para conseguir aprovação
da reserva de contingência (reservas de prazos e custos para lidar com os riscos conhecidos e mapeados) e da reserva de
gerenciamento (reservas geralmente de custos e muitas vezes também de prazos para lidar com os riscos desconhecidos, ou
aqueles que não foram possíveis de serem mapeados durante o planejamento dos riscos). Mas é na fase de execução, controle e
monitoramento do projeto que estas reservas devem ser utilizadas, protegidas e na qual o gerente de projetos deve prestar conta
do destino de tais reservas.
Seria natural então que a utilização principalmente da reserva de contingência fosse encarada como uma forma de parametrizar,
ou estabelecer métricas, de como e quando foi utilizada e primordialmente se ocorreu conforme o planejado. Apesar de não existir
como padronizar o uso de reservas de contingência, pois cada projeto é sempre único e específico, podemos identificar maneiras
de medir a eficácia de seu emprego, simplesmente comparando sua utilização com os resultados esperados determinados durante
a fase de planejamento.
Para melhorar nossa compreensão, vamos trabalhar com os seguintes exemplos:
Exemplo 1: O gerente de projetos durante o processo de verificação de escopo de uma entrega do projeto por um fornecedor
identificou um risco de que haveria atrasos, pois o escopo não havia sido ainda completado, custando ao projeto vinte mil reais a
mais por esse atraso. Esse risco tinha sido previamente mapeado e tratado, desta maneira este montante estava disponível nas
reservas de contingência o qual foi empregado e mitigou o risco iminente.
Exemplo 2: Durante o desenvolvimento do projeto, a alta administração da companhia determinou que o projeto devesse ser
abreviado em três semanas, em relação ao prazo planejado, por questões estratégicas para que a empresa se sobressaísse no
mercado. Para tanto, estaria liberando o uso de horas extras ao time do projeto para completá-lo na nova data especificada pelos
patrocinadores. Essa condição havia sido mapeada e contemplada nas reservas de contingência. Dessa forma, o montante
reservado atendeu as expectativas dos stakeholders com relação aos resultados esperados.
Exemplo 3: A alta administração da empresa solicitou uma adição e mudança de escopo no projeto, acrescentando novas
funcionalidades no produto final. Nesse caso, como não se trata especificamente de um risco, deve ser tratado como uma
solicitação de mudança e deve passar por um processo formal de Controle Integrado de Mudanças, que requer novas aprovações
de prazo e custos frente às novas condições de escopo do projeto. Portanto, não deve utilizar da reserva de contingências para
esse fim.
Exemplo 4: Um novo risco de origem externa ao projeto foi identificado, porém sua probabilidade ainda se apresenta como incerta
e os impactos ao projeto não puderam ser determinados pela equipe de riscos, principalmente por falta de informação adequada.
O risco ocorre e se lança mão da reserva de gerenciamento, uma vez que não estava previsto nas reservas de contingência
(utilizadas apenas para riscos conhecidos).
Note que nos exemplos descritos, podemos identificar sem muitas dificuldades o emprego das reservas de contingência e de
gerenciamento, e até mesmo quando não devemos utilizar das reservas para propósitos inadequados. Essa seria, segundo Mulcahy
(2010), uma forma de estabelecer métricas comparativas que viessem a auxiliar na evidência da conformidade da execução em
relação ao planejamento de riscos.
O monitoramento e controle das reservas de contingência e gerenciamento é um processo de muita

importância. A compreensão dos stakeholders sobre os conceitos das reservas também se faz importante e
deve ocorrer ainda na fase de planejamento. Essa boa prática auxilia e muito para que as reservas não sejam
utilizadas de maneira inadequada, como para cobrir adições incontroladas de escopo ou para acobertar
ineficiência no desempenho das equipes, sendo utilizadas para cobrir gastos com retrabalho nas atividades
do projeto. Fonte: o autor.
Encerramos esta primeira parte com conceitos sobre os processos de garantia da conformidade e do estabelecimento das métricas
que possam vir a colaborar com o controle sobre o andamento do projeto. Muitas são as ações que contribuem significativamente
para a eficácia dos planos de riscos implantados, assim como seu emprego de maneira adequada contribuem com a obtenção da
maturidade de gestão de riscos na empresa, aumentando as chances de sucesso de seus projetos.
Espero que você tenha aproveitado o conteúdo abordado, pois há muito mais coisas interessantes por vir.
TOMADA DE AÇÕES CORRETIVAS E

AVALIAÇÃO DA EFETIVIDADE
Olá! Daremos continuidade aos nossos estudos sobre gerenciamento de riscos. Sua dedicação e entusiasmo farão com certeza
toda a diferença nessa nossa jornada.
Neste momento, abordaremos a aplicabilidade, por meio da medição de desempenho, das ações corretivas e/ou soluções
alternativas para trazer o projeto de volta ao seu curso original, caso algum desvio significativo seja identificado durante as
verificações dos processos de monitoramento e controle dos riscos no projeto.
Mantenha o controle sobre os riscos do projeto
Os processos de monitoramento e controle dos riscos incluem não só o estabelecimento de métricas e avaliações de desempenho,
como também a aplicabilidade de ações corretivas para trazer o projeto no curso correto, além de prever a medição dos efeitos
surtidos para conhecer se há ou não necessidade de tomar ainda mais medidas corretivas.
Maximiano (2014) considera importante a elaboração de planos para que o desempenho de execução do projeto seja medido e
confrontado com o que foi planejado constantemente. Essa seria, segundo o autor, a melhor forma de garantir a avaliação
constante dos riscos do projeto.
Como sugestão, Maximiano (2014) afirma que a medição do desempenho durante a execução do plano de gestão dos riscos
deveria analisar, inicialmente, o número de novos riscos identificados que não constavam na avaliação de riscos original e o
número de soluções de contorno implantadas até o momento presente da avaliação.
Compreenda como soluções de contorno as ações que devem ser tomadas com relação a novos riscos que poderão surgir no
projeto e que não puderam ser identificadas durante o processo de identificação dos riscos. Caso o número de riscos identificados
durante a execução do projeto seja muito significativa, este seria o momento do time do projeto junto ao Gerente de projetos
questionarem a eficácia dos processos de identificação e análise dos riscos durante o início do planejamento.
Como consequência, um número também significativo de soluções de contorno indicaria a falta de planejamento adequado de
riscos e provavelmente você teria vários problemas para cuidar durante a execução do projeto.
Contudo, e segundo Maximiano (2014), as soluções de contorno acabam por ter seu valor agregado, pois sem a elaboração e
implantação de planos emergentes de tratamento de riscos identificados e até então desconhecidos ficaria muito difícil trazer o
projeto de volta ao seu curso planejado. Essa prática requer muitas vezes o uso de criatividade e maturidade na gestão de riscos
em projetos, pois muitas vezes se faz necessário desenvolver soluções imediatas buscando a mesma eficácia proposta nos planos
de respostas aos riscos que puderam ser planejados com mais tempo e dedicação pelo time de riscos do projeto.
Os processos de revisão de riscos, por meio de reuniões periódicas de avaliação de desempenho, são uma maneira eficaz de
controlar os riscos e gerenciar as mudanças e ajustes que se fizerem necessários ao longo do ciclo de vida do projeto. Podem
também ser um meio relativamente rápido e eficiente de identificar novos eventos incertos e de dar visibilidade acerca do
gerenciamento e controle sobre os riscos aos principais stakeholders.
Segundo Sbragio (2009), as boas práticas de gestão de riscos sugerem que as reuniões de andamento do projeto e de revisão de
riscos sejam feitas com a periodicidade de acordo com a complexidade do projeto e que deveriam estar pelo menos presentes os
proprietários dos riscos (responsáveis por colocarem em práticas os planos de respostas aos riscos), o time de projetos – ou time
riscos, se houver – e outros stakeholders pertinentes, além do próprio Gerente de Projetos.
Algumas perguntas norteadoras podem ser utilizadas durante as reuniões de revisão de riscos, por exemplo, quais foram os riscos
adicionais encontrados desde a última reunião de revisão, quais planos de respostas aos riscos precisam ser revistos e quem
poderia ser agregado ao time de riscos que pudesse contribuir com a identificação e avaliação de novos riscos.
Outra prática que pode ser empregada é a utilização de um comitê de riscos, que pode ser formado por stakeholders que não
necessariamente fazem parte do time usual de revisão de riscos. Membros da alta administração, especialistas de áreas específicas
da companhia (finanças, tributário, jurídico etc.), e até outros gerentes de projetos podem contribuir e muito nos processos de
revisão de riscos com novas perspectivas, principalmente em projetos de alta complexidade.
Muitos estudos sobre gestão de riscos em projetos indicam que, em média, solucionar os problemas fica
entre 75 e 100 vezes mais dispendioso do que planejar para preveni-los. Essa informação nos faz refletir
sobre quanto tempo e dinheiro estariam disponíveis caso os eventos incertos tenham sido propriamente
identificados e mapeados durante a fase de planejamento dos riscos. Dessa maneira, o Gerente de Projetos
deveriam dedicar seu tempo implantando os planos de respostas aos riscos ao invés de criar e implantar
soluções de contorno para riscos não previamente identificados. Fonte: Vargas (2007).
O uso da análise de valor agregado como controle de riscos

A análise de valor agregado é sem dúvida uma poderosa ferramenta de controle e monitoramento aplicada aos projetos e, segundo
Mulcahy (2010), há inúmeras vantagens em utilizá-la como ferramenta de controle na gestão de riscos. A análise de valor agregado
é uma ferramenta utilizada para medir quantitativamente e monitorar o desempenho do projeto como um todo durante a
execução, sempre em comparação com os valores planejados. Ela mede o quanto de valor tem sido agregado ao projeto e à
empresa (em termos de trabalho realizado e entregue), porém sempre de olho nos requisitos de desempenho de prazos e custos
previamente orçados.
A análise de valor agregado traz um panorama geral do projeto, proporcionando o conhecimento do status atual do projeto
baseado nas métricas de desempenho principalmente de prazos e de custos. Note que na 2ª coluna do Quadro 1, que será
mostrado a seguir, há valores numéricos provenientes de cálculos pertinentes ao método.
Note ainda que estes índices de desempenho demonstrados podem auxiliar e muito na gestão de riscos, pois há sempre vários
deles relacionados aos prazos das entregas e aos custos previstos no orçamento original do projeto. Eles estão relacionados com o
quanto se agrega de valor ao projeto, ou seja, integra em um único método de medida de desempenho os custos, prazos e escopo
do projeto.
Para melhor compreensão, podemos tomar os seguintes exemplos didáticos, para cada um dos índices de desempenho (custo e
prazo):
• Imagine um projeto de construção de quatro muros ao redor de um terreno quadrado, no qual teremos apenas um recurso
construindo os muros e cada lado tendo a duração de um dia de trabalho (8 horas) para ser construído ao custo de 1.000 reais
(cada um dos lados). Logo, o projeto terá duração de quatro dias. Ao final do terceiro dia (ponto de medição do projeto), temos a
seguinte situação:
º Primeiro muro completo com custo de 1.000 reais.
º Segundo muro completo com custo de 1.200 reais.
º Terceiro muro com 50% completo e custo de 600 reais.
º Quarto muro com construção ainda não iniciada.
º Os custos incorridos até o momento são de 2.800 reais (1.000 + 1.200+ 600, respectivamente).
º O valor planejado até o momento seria de 3.000 reais, ou seja, deveriam estar prontos três muros custando 1.000 reais
cada um ao final do terceiro dia.
º O valor agregado ao projeto até o momento foi de 2.500 reais, pois foram entregues dois muros e meio, representando,
respectivamente, 1.000 reais (1º muro completo) mais 1.000 reais (2º muro completo) e mais 500 reais (metade apenas do
3º muro está pronta).
O método da Análise de Valor Agregado, segundo Mulcahy (2010), calcula os índices de custo e prazo da seguinte forma:
• Índice de desempenho de custo: divide-se o valor agregado (2.500 reais) pelo custo incorrido até o momento da medição (no
caso, 2.800 reais). Chega-se ao valor de 0,89, o qual representa que para cada Real investido no projeto somente 89 centavos é
aproveitado e 11 centavos é o custo da ineficiência das atividades do projeto.
• Índice de desempenho de prazo: divide-se o valor agregado (2.500 reais) pelo valor planejado até o momento da medição (no
caso, 3.000 reais). Chega-se ao valor de 0,83, o qual representa que o projeto tem um andamento igual a 83% da velocidade
planejada.
• O ideal é que cada índice esteja próximo a 1, ou seja, que cada Real empregado seja aproveitado e que esteja a 100% da
velocidade planejada.
• Qualquer índice acima de 1 significa que o projeto está provendo economias e/ou está mais veloz que o planejado, podendo
até ser entregue antes.
• Tudo indica que se o projeto continuar neste ritmo e com estes gastos, teremos atrasos e o orçamento original será excedido.
Podemos reconhecer facilmente estes índices no Quadro 1 para nossa melhor compreensão:
Quadro 1 - Análise de Valor Agregado do projeto

Número não proveniente dos cálculos da análise de valor agregado
(*) e sim das estimativas de custos que incidem no projeto
como um todo.
A análise de valor agregado traz um panorama geral do projeto, proporcionando o conhecimento do status atual do projeto
baseado nas métricas de desempenho principalmente de prazos e de custos. Note que na 2ª coluna do quadro há valores
numéricos provenientes de cálculos pertinentes ao método, que não se trata do nosso foco no momento. Note que Porém, estes
índices de desempenho demonstrados podem auxiliar e muito na gestão de riscos, pois há sempre vários deles relacionados aos
prazos das entregas e aos custos previstos no orçamento original do projeto. Eles estão relacionados com o quanto se agrega de
valor ao projeto, ou seja, integra em um único método de medida de desempenho os custos, prazos e escopo do projeto. Para
melhor compreensão, podemos tomar os exemplos abaixo, para cada um dos índices de desempenho (custo e prazo):
• Imagine um projeto de construção de quatro muros ao redor de um terreno quadrado, no qual teremos apenas um recurso
construindo os muros e cada lado levará um dia de trabalho (8 horas) para ser construído ao custo de 1.000 reais cada um. Logo,
o projeto terá duração de quatro dias. Ao final do terceiro dia (ponto de medição do projeto), temos a seguinte situação:
º Primeiro muro completo com custo de 1.000 reais.
º Segundo muro completo com custo de 1.200 reais.
º Terceiro muro com 50% completo e custo de 600 reais.
º Quarto muro com construção ainda não iniciada.
• Os custos incorridos até o momento são de 2.800 reais (1.000 + 1.200 + 600, respectivamente).
• O valor planejado até o momento seria de 3.000 reais, ou seja, deveriam estar prontos três muros custando 1.000 reais cada
um ao final do terceiro dia .
• O valor agregado ao projeto até o momento foi de 2.500 reais, pois foram entregues dois muros e meio, representando,
respectivamente, 1.000 reais (1º muro completo) mais 1.000 reais (2º muro completo) e mais 500 reais (metade apenas do 3º
muro está pronta).
• O método da Análise de Valor Agregado, segundo Mulcahy (2010), calcula os índices de custo e prazo da seguinte forma:
º Índice de desempenho de custo: divide-se o valor agregado (2.500 reais) pelo custo incorrido até o momento da medição
(no caso, 2.800 reais). Chega-se ao valor de 0,89, o qual representa que a cada Real investido no projeto somente 89
centavos é aproveitado e 11 centavos é o custo da ineficiência das atividades do projeto.
º Índice de desempenho de prazo: divide-se o valor agregado (2.500 reais) pelo valor planejado até o momento da medição
(no caso, 3.000 reais). Chega-se ao valor de 0,83, o qual representa que o projeto tem um andamento igual a 83% da
ºO ideal é que cada índice esteja próximo a 1, ou seja, que cada Real empregado seja aproveitado e que esteja a 100% da
º Qualquer índice acima de 1 significa que o projeto está provendo economias e/ou está mais veloz que o planejado, podendo
até ser entregue antes.
ºTudo indica que se o projeto continuar neste ritmo e com estes gastos, teremos atrasos e o orçamento original será
excedido.
Podemos reconhecer facilmente estes índices no Quadro 1 já citado para nossa melhor compreensão.
Segundo Mulcahy (2010), se há uma ameaça de atraso de uma importante entrega de escopo em um projeto, muito provavelmente
ela foi mapeada durante o planejamento dos riscos. Uma avaliação mais detalhada pode auxiliar no levantamento de quais
atividades estariam levando mais tempo que o planejado e as ações de correção podem perfeitamente coincidir com os planos de
respostas aos riscos já previamente elaborados.
Estes planos deveriam ser implantados e uma nova medição dos índices de desempenho de prazos deveria ser feita, para descobrir
se as ações corretivas surtiram os efeitos desejados. O mesmo conceito pode ser aplicado às ameaças relacionadas aos custos do
projeto e ao índice de desempenho de custos, sugerindo pequenos ajustes e/ou a implantação dos planos de respostas aos riscos
relativos a essa dimensão do projeto.
Os planos de gerenciamento do projeto, bem como os planos de respostas aos riscos devem ser avaliados, reavaliados e
atualizados (quando aplicável) durante todo o ciclo de vida do projeto.
De acordo com Mulcahy (2010), conforme o projeto progride e avança em direção ao cumprimento dos objetivos, o time de riscos
vai se tornando mais familiar com os padrões e tendências do projeto e podem até conseguir identificar que determinado risk ‘
score de um risco ou que o número de riscos não identificados durante o planejamento podem ser um importante sinal de alerta.
’
Assim como um número significativo de soluções de contorno e um grande número de solicitação de mudanças no plano também
podem ser sinais de alerta de que o projeto não vai bem e precisam ser interpretados, principalmente pelo Gerente de Projetos.
Este tipo de situação requer uma reavaliação do plano de gerenciamento do projeto e a revisão detalhada e possível atualização do
registro de riscos.
Mulcahy (2010) relata que todo e qualquer projeto possui requerimentos técnicos que precisam ser atendidos, pois está embutido
no atendimento aos objetivos e nos fatores de sucesso do projeto. Podemos utilizar como exemplos a funcionalidade dos sistemas
desenvolvidos para computadores, a robustez e resistência da estrutura de um prédio comercial ou ainda a durabilidade e ciclo de
vida de produtos manufaturados. Se estes requerimentos sofrerem desvios em relação ao plano original, os processos de
identificação, análise e tratamento de riscos devem ser revisados e alterados durante a execução das ações corretivas para
trazerem o projeto ao seu curso original. Dependendo do grau de desvio os riscos podem ser tão graves que podem impedir o
atendimento aos requerimentos de escopo do projeto. Como um novo exemplo, podemos citar que mudanças significativas no
desempenho de custos podem comprometer seriamente os requisitos de qualidade, prazos ou atendimento às expectativas do
cliente (ou patrocinador) do projeto.
Segundo Mulcahy (2010), uma atenção especial também deve ser dada às restrições iniciais ao implantarmos as soluções de
contorno ou os planos de respostas aos riscos, restrições estas que impõem algumas limitações ao desenvolvimento do projeto.
Podemos tomar como exemplo alguma restrição orçamentária, de prazos e datas que não admitem negociações (como datas
relacionadas a eventos comemorativos, festas, lançamento de produtos novos etc.), de origem tecnológica ou até mesmo de
disponibilidade de recursos humanos.
Segundo Sbragio (2009), estas restrições precisam ser observadas durante as implantações das respostas aos riscos, pois se
houver, por exemplo, uma limitação orçamentária, os resultados obtidos após a aplicação do plano de respostas não deveria, em
hipótese alguma, ferir ou comprometer essa restrição, ou seja, uma medida de correção de um risco não poderia impactar os
custos do projeto causando uma nova ameaça aos resultados esperados. O mesmo conceito se aplica aos prazos, nos casos em que
as limitações sejam relacionadas às datas de entregas parciais e/ou totais que não possuem flexibilidade de negociação.
A gestão de riscos, mais precisamente o controle e monitoramento de riscos, deveria ser implantada sob os
princípios das tomadas de decisão, procurando encorajar os participantes a prover suas opiniões com o
intuito de contribuir significativamente para o desempenho do gerenciamento dos riscos. Além disso, a alta
administração da empresa deveria não somente participar como também prover uma atmosfera apropriada
aos demais colaboradores da companhia e dos projetos, para que se sintam a vontade em poder executar
suas funções com desempenho e qualidade. Com o respaldo e participação efetiva da alta administração nas
tomadas de decisões baseadas nas boas práticas de gestão de riscos se torna possível demonstrar aos
demais stakeholders a devida importância dos processos de identificação, análise e tratamento de riscos,
disseminando uma cultura de gerenciamento dos eventos incertos dos projetos na companhia. Fonte:
Kerzner (2009).
Vimos aqui a importância das análises de desempenho do projeto e dos planos de respostas aos riscos, para que as devidas ações
corretivas sejam tomadas e nova análise de desempenho seja feita, para observar se surtiram os efeitos desejados. Certamente
seu projeto, por menos complexo que seja, apresentará desvios durante a execução e as boas práticas de monitoramento e
controle dos riscos serão imprescindíveis para trazer seu projeto ao curso natural novamente. Vimos também que a análise de
valor agregado pode trazer inúmeros benefícios à gestão de riscos, desde que utilizada de forma apropriada. Mas, vamos seguir em
frente, porque o assunto está ficando cada vez mais interessante.
PADRÕES, PROCEDIMENTOS,
POLÍTICAS E BOAS PRÁTICAS
Olá, daremos continuidade aos nossos estudos sobre as melhores práticas de monitoramento e controle dos riscos em projetos.
Veremos agora quais são os processos de estabelecimento da política de tolerância aos riscos na Organização, bem como os
processos de identificação das melhores práticas e métodos de identificação e qualificação de novos riscos durante a execução do
projeto. Compreenda que estes são os riscos que não puderam ser identificados e mapeados durante os processos de identificação
e de planejamento do tratamento adequado aos riscos.
Reavaliação dos riscos do projeto
De acordo com Kerzner (2009), os processos de monitoramento e controle dos riscos requerem também a identificação, análise,
tratamento e a elaboração dos planos de respostas, exatamente como deve acontecer durante os processos de planejamento
referente aos riscos.
Existem duas razões principais para que haja a reavaliação dos riscos no projeto. Uma delas deveria acontecer quando novos riscos
são identificados e a outra é quando ocorrem mudanças – mesmo que controladas – nos planos originais do projeto.
Os processos de identificação de novos riscos podem acontecer durante sessões de brainstorm (rodada de sugestões, opiniões e
‘ ’
ponderações por parte do time de riscos), durante as reuniões de andamento e de solução de problemas ou ainda durante a
execução do projeto, sempre em alerta para novas ameaças ou oportunidades que possam aparecer no caminho. Seria de
responsabilidade do Gerente de Projetos observar novos possíveis riscos como fomentar e incentivar ao seu time a fazer o mesmo,
além de convocar reuniões de identificação de novos riscos, de acordo com o andamento do projeto.
Vargas (2007) afirma que não importa o quão completo esteja seu planejamento de riscos, os riscos não identificados aparecerão e
as necessidades de mudanças existirão. Não é por acaso que o processo é denominado de ‘Controle Integrado de Mudanças’, pois
qualquer solicitação de mudanças em relação ao plano original de custos, prazos, qualidade ou de escopo deve ter seus impactos
avaliados em todas as outras áreas de conhecimento do projeto. Por essa principal razão é que o Gerente de Projetos precisa estar
alerta e utilizar das técnicas de identificação e tratamento de riscos toda vez que uma mudança significativa ocorrer em qualquer
instância do projeto.
Isso implica na revisão e reavaliação dos riscos existentes já mapeados, ajustes (se necessário) e criação de novos planos de
respostas e atualizações constantes no registro de riscos. Caso o Gerente de Projetos ignore novos riscos durante a execução e/ ou
monitoramento ou perca o controle dos riscos previamente mapeados, estará ele inserindo riscos no projeto e comprometendo
todos os benefícios obtidos durante a fase de planejamento. Não só os resultados parciais ou totais estarão ameaçados como
muito provavelmente sua reputação e carreira profissional também estará em jogo.
Identifique mais riscos durante os processos de verificação do escopo
Os processos de verificação do escopo ocorrem quando o Gerente de Projetos analisa as entregas parciais e
as confronta com os requisitos iniciais do projeto para identificar se estão em conformidade e se atendem
às expectativas do cliente, no intuito de obter aceitação e aprovação formal sobre estas entregas. Riscos
adicionais podem ser identificados durante esse processo por meio de questionamentos ao cliente a
respeito do cumprimento do escopo, se estão conforme suas expectativas e se atendem às demandas dos
departamentos ou da divisão da companhia ou ainda alguma outra questão de ordem técnica ou gerencial
que auxilie na identificação de novos riscos dessa natureza. Esteja preparado e prepare seu time para
realizar os questionamentos e estarem aptos a identificar novos riscos sob a perspectiva de seus clientes.
Fonte: Dinsmore e Cookie-Davies (2006).
Maximiano (2014) nos dá algumas sugestões a respeito das necessidades de reestimativas relativas aos planos de gestão de riscos.
Faz-se necessário reavaliar e, caso necessário, reestimar atividades, fases ou o projeto como um todo quando novos riscos são
identificados, novas análises determinarem que o risk score de algumas atividades modificaram-se, caso a prioridade de alguns
‘ ’
riscos tenham sido alteradas, reservas de contingência foram utilizadas mais cedo do que se esperava, quando há muitas mudanças
no projeto, quando muitos riscos não identificados aparecem no projeto e, ainda, quando há substituição do Gerente de Projetos
do projeto.
A própria ação de reestimar atividades ou fases pode gerar novos riscos, pois existe a possibilidade de impactar prazos pré-
determinados ( milestones ) e comprometer o orçamento do projeto, além dos quesitos tangíveis de qualidade. Nestes casos,
conforme mencionado anteriormente, é de responsabilidade do Gerente de Projetos junto ao seu time e stakeholders chaves
reavaliar os impactos no projeto como um todo, sempre com o intuito de preservar o atendimento aos objetivos iniciais do projeto.
Neste ínterim e de acordo com Maximiano (2014), não podemos nos esquecer de que o projeto – qualquer que seja sua natureza
ou propósito – é repleto de incertezas, por conta das estimativas de prazos e custos. A própria definição de estimativas já nos diz
que não se trata de uma ciência exata, que podem mudar baseadas na experiência e no conhecimento técnico do projeto, por causa
de mudanças no projeto e até por causa das mudanças nos planos de gestão de riscos.
Dessa forma, durante a execução do projeto as estimativas deveriam ser reavaliadas e alteradas (caso houvesse necessidade)
durante todo o ciclo de vida do projeto. Afinal, seria bem menos impactante se o time de projetos identificasse uma ameaça a uma
atividade ou fase do projeto reavaliando suas estimativas de prazos e custos e tomando ações pró-ativas do que se as
descobrissem tardiamente e tivessem que elaborar planos emergenciais de solução de contorno. O papel do Gerente de Projetos,
aliado ao estabelecimento de procedimentos e políticas internas de tratamento de riscos da companhia, não deveria ser estático e
nem agir reativamente a situações surpresa, e sim interagir proativamente com sua equipe, visando garantir que os requisitos
necessários para o sucesso do projeto fossem sempre alcançados.
Segundo Greene e Stellman (2010), exemplos de políticas e procedimentos podem ser compreendidos como aqueles aplicáveis a
todo e qualquer projeto da companhia e que incluem tolerância a riscos (que será visto com mais detalhes à frente), métodos
específicos de identificação de riscos, além de escalas padrão de probabilidade e de impacto utilizadas nas análises de risk score
‘ ’
dos eventos incertos do projeto. Podem ainda ser definidos como:

• A padronização na participação de fornecedores externos nos processos de gerenciamento dos riscos.
• A definição de quem deveria ser capacitado a respeito das boas práticas de gestão de riscos.
• A devida atenção e documentação dos quesitos financeiros e tributários dos projetos comuns à companhia.
• A definição de qual deveria ser a periodicidade na qual os riscos seriam revisados e outras políticas e padrões que venham
agregar valor aos projetos desenvolvidos pela companhia.
Baseando-se nessas informações o gerente de projetos deveria iniciar os levantamentos primários sobre os riscos tomando o
devido cuidado em atender a estas políticas e procedimentos comuns aos projetos da organização. Tais políticas e boas práticas
deveriam ser elaboradas no intuito de aumentar as chances de sucesso do projeto e da eficácia nos processos de gestão de riscos.
O estabelecimento de políticas, procedimentos, padrões e boas práticas na organização podem auxiliar e

muito nas abordagens iniciais sobre o plano de gerenciamento de riscos de um projeto. Seja um
departamento, uma divisão ou uma área que tenha por missão gerenciar uma base histórica de projetos e
aperfeiçoar continuamente as informações pertinentes aos riscos mais comuns e torná-las utilizáveis aos
projetos da empresa. Caso sua empresa ainda não possua essa cultura, já imaginou os benefícios
provenientes dessa iniciativa? Não seria agora o momento de estruturar algo parecido na sua área de
gerenciamento de projetos?
Grau de tolerância aos riscos do projeto
Sbragio (2009) nos alerta com relação ao grau de tolerância aos riscos por parte dos stakeholders do projeto. O grau de tolerância
aos riscos não está somente e efetivamente associado ao bom humor, crenças ou estado de espírito do stakeholder no momento da
avaliação. Está mais associado com o grau de impacto com o qual o stakeholder terá que lidar caso o risco ocorra e quais as medidas
corretivas terão de ser aplicadas e o seu envolvimento nestas ações. Implica também na intensidade que afetará sua rotina e suas
responsabilidades perante os resultados do projeto.
O grau de tolerância também está associado às atividades e ao papel desempenhado no projeto por parte do stakeholder pois se ,
uma ameaça previamente mapeada comprometer suas ações rotineiras e exigir esforços além do planejado, ou seja, deixá-lo
desconfortável e em exposição desnecessária, certamente seu grau de tolerância a determinado risco será menor, em comparação
a outro stakeholder do projeto.
Podemos tomar como exemplo uma ameaça inerente ao departamento de Logística da empresa, como o não cumprimento do
prazo de uma entrega parcial do novo sistema de computador para essa área. O grau de tolerância a essa ameaça é bem menor
para o operador de Logística do que para outro stakeholder do projeto, do departamento de RH por exemplo.
A consequência é que, se ambos pertencerem ao mesmo time de riscos, cada um terá uma abordagem diferente das probabilidades
e impactos dos riscos pertinentes às operações logísticas. Uma forma de contornar essa situação seria fazer uso da qualificação
dos dados ainda nos processos de análise, ou seja, levar ao conhecimento de todos sobre as informações referentes ao evento
incerto, buscando o nivelamento do grau de informação para que o grau de tolerância a uma ameaça em específico fosse menos
díspar e desencontrada possível.
De acordo ainda com Sbragio (2009) podemos compreender também como grau de tolerância de riscos o quanto a companhia está
disposta a correr determinados riscos, principalmente por conta da sua estrutura organizacional, cultura ou segmento de atuação.
Como exemplos, uma companhia do setor financeiro teria um grau de tolerância muito baixo aos riscos externos relacionados ao
mercado financeiro ou uma companhia do segmento da construção civil estaria menos apta a correr riscos relacionados ao
mercado imobiliário. Esse tipo de análise permite que alguns procedimentos e políticas de gestão e tratamento de riscos já possam
ser estabelecidos nas empresas para que sejam seguidos, se não por todos, pelo menos pela maioria dos projetos desenvolvidos
pela companhia. A análise do grau de tolerância aos riscos do projeto é um processo que deve ocorrer na fase de desenvolvimento
dos planos de gestão dos riscos.
Apesar do grau de tolerância aos riscos parecer algo bem peculiar e relativo a um stakeholder isoladamente,
essa não seria a abordagem mais correta a ser considerada. A melhor prática aplicada a este conceito seria
analisar os impactos causados por um determinado risco do ponto de vista de uma posição de trabalho,
responsabilidade ou determinada operação, porém não de forma isolada. As atividades do projeto são
constituídas de processos encadeados que precisam ser analisados de forma sistêmica. Dessa maneira,
mesmo quando mencionamos o grau de tolerância de um stakeholder ou área específica estamos avaliando
a tolerância aos riscos de forma mais abrangente, envolvendo na solução não só o time de projetos como
também outros stakeholders que podem ser afetados direta ou indiretamente e que possam ser impactados
pela ocorrência de um risco em específico. Fonte: Sbragio (2009).
Muito bem, ao final deste estudo pudemos perceber a importância do estabelecimento de padrões, procedimentos, políticas e
boas práticas relacionadas aos planos de gestão de riscos do projeto. Avaliamos os benefícios e resultados esperados na utilização
dessa abordagem e a proposta da disseminação dessa cultura nas empresas. Pudemos ainda compreender o quanto essa
abordagem aliada à compreensão sobre o grau de tolerância aos riscos por parte dos stakeholders e da própria organização podem
contribuir para a identificação de novos riscos e o estabelecimento do controle sobre a gestão de riscos, consequentemente do
projeto como um todo.
Vamos seguir em frente, porque o próximo assunto é também muito interessante.
AUDITORIAS, LIÇÕES APRENDIDAS E

COMPROMETIMENTO DOS
STAKEHOLDERS
Olá, depois de descobrirmos a importância da elaboração e implantação dos procedimentos, políticas e boas práticas de gestão de
riscos vamos discorrer agora sobre os processos de encerramento, comunicação e a utilização das lições aprendidas oriundas do
gerenciamento de riscos.
No nosso último estudo sobre Monitoramento e Controle de Riscos, vamos explorar os processos que levam à execução de
auditorias para medição de desempenho do plano de riscos. Vamos abordar como a captura das lições aprendidas relacionadas aos
riscos envolvendo os principais stakeholders ajuda a estabelecer um processo de melhoria contínua. Vamos ainda compreender os
processos de comunicação e de encerramento de riscos e como a aplicabilidade da Governança de riscos auxilia na elaboração do
planejamento de riscos para novos projetos, sem que haja necessidade de o iniciarmos do zero.
A medição de desempenho por meio da auditoria de riscos
Uma das maneiras de se medir o desempenho do plano de riscos e ainda com uma visão diferenciada, pois permite uma análise
sobre as atividades e ações do time de projeto e se elas estão funcionando da maneira esperada. Segundo Vargas (2007), a
auditoria de riscos permite e proporciona a revisão sobre os riscos, se os proprietários dos riscos adequados foram designados
corretamente para cada risco – determinando ainda sua eficiência – e analisa a efetividade dos planos de contingência (plano ‘B’) e
de backup (contingência do plano ‘B’, caso esse venha a falhar) implantados como plano de respostas aos riscos.
É um processo que deve ser aplicado no projeto durante sua execução e os resultados das auditorias podem sugerir a substituição
do proprietário do risco, bem como ajustes e mudanças significativas nos planos de contingência e de backup de respostas aos
riscos. Pode ser elaborado e executado pelo Gerente de Projetos, por ele junto ao seu time de projetos ou, em projetos mais
complexos e longos, por empresas especializadas nessa atividade. De acordo com Vargas (2007), baseia-se nas medidas de
desempenho e conversas com os proprietários dos riscos e na avaliação dos resultados provenientes das ações corretivas tomadas
ao longo da execução do projeto.
Podemos compreender como medida de desempenho toda e qualquer análise sobre as ações corretivas tomadas para trazer o
projeto ao seu curso original. É esperado que estas medidas tenham a eficácia necessária para realmente corrigir os desvios e
trazer as atividades e demais funcionalidades do projeto sob controle novamente.
Para tomarmos um exemplo prático, imagine que ao ser realizada uma auditoria de riscos em determinado período do projeto,
apurou-se gastos excessivos de acordo e em relação ao planejamento prévio para o período analisado. Estes gastos foram
provenientes de eventos incertos que ocorreram, não haviam sido mapeados e tratados pelo time de riscos e causaram impactos
financeiros significativos ao desempenho de custos do projeto. Neste caso a auditoria de riscos, infelizmente, detectou que o plano
original de gestão de riscos estava falho e medidas emergenciais de revisão e análise mais profunda do plano de gestão por parte
do time de riscos se fizesse necessária.
A auditoria de riscos pode sugerir mudanças nos planos do projeto e, depois de implantadas estas melhorias, novas medições são
realizadas para se descobrir se os resultados foram satisfatórios. Além de serem utilizadas durante a execução do projeto são
também registradas para serem utilizadas como lições aprendidas posteriormente. A máxima sobre este processo seria ‘Nunca
pare de procurar por novos riscos e de adaptar suas estratégias para lidar com eles’ (GREENE; STELLMAN, 2010).
Auditorias de riscos são diferentes dos processos de revisão de riscos, apesar de muita gente confundir o
conceito sobre ambas. A melhor maneira para termos um discernimento mais seguro entre elas é que a
auditoria de riscos tem um olhar sobre o passado para descobrir o que deu certo e o que deu errado,
enquanto que a revisão de riscos olha para o futuro com o intuito principal de descobrir o que de errado ou
certo poderia acontecer de acordo com os planos e informações até o presente momento. Fonte: Mulcahy
(2010).
Processos de comunicação e a gestão de riscos
De acordo com o PMI (2013), o Gerente de Projetos deveria despender cerca de 90% de seu tempo nos processos
comunicacionais que permeiam por todas as áreas de conhecimento assim como por todo o ciclo de vida do projeto. Podemos
observar a seguinte definição sobre a comunicação em projetos:
O gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as
informações do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas,
gerenciadas, controladas, monitoradas e finalmente dispostas de maneira oportuna e apropriada. (PMI,
2013).
Não poderia ser diferente com relação aos processos de gestão de riscos. De acordo com Kerzner (2009), os processos
comunicacionais aplicados à gestão de riscos são cruciais como fator de contribuição no sucesso do projeto e o Gerente de
Projetos eficaz deveria manter os stakeholders muito bem atualizados acerca do status das atividades e do andamento do plano de
riscos do projeto.
Cabe ao Gerente de Projetos o papel de identificar corretamente os stakeholders e previamente identificar suas necessidades, bem
como a forma de engajá-los para que possam também contribuir para que os resultados dos objetivos sejam satisfatórios,
incluindo os resultados dos planos de gestão dos riscos. Kerzner (2009) relata ainda que o Gerente de projetos deveria prover
regularmente as informações necessárias aos stakeholders para que possam exercer suas funções no projeto e contribuírem para
as realizações. Dessa forma haveria motivação e cooperação, aumento de desempenho e outros benefícios provenientes de uma
gestão eficaz da comunicação por parte do Gerente de Projetos.
Segundo Sbragio (2009), os riscos deveriam ser encarados como atividades normais do projeto, pois não seriam parte do projeto e
poderiam impactar o projeto caso viessem a ocorrer? Pois então, os riscos também podem ser comunicados aos stakeholders por
meio do conhecimento do plano de gerenciamento do projeto, dos relatórios periódicos sobre o andamento do projeto, dos
relatórios de status das atividades, da visibilidade do registro de riscos e dos relatórios de auditoria de riscos. Podemos ainda
compreender melhor a importância da comunicação na gestão dos riscos (e do projeto) observando a falha ou falta dela junto aos
stakeholders.
Segundo o PMSURVEY (2014) – banco de dados sobre estatísticas de projetos que tem como colaboradoras empresas de médio e
grande porte em vários países do mundo – a falha (ou falta) da comunicação em projetos tem responsabilidade em mais de 60% das
causas de fracassos em projetos.
Segundo Mulcahy (2010), é importante observar duas coisas importantes ao comunicar status sobre a gestão de riscos em
projetos: a primeira delas é que um bom relatório de status não seria simplesmente um print de tela de um software de
‘ ’
computador.
Os programas de computador de Gestão de Riscos são desenvolvidos – na maioria das vezes – para contemplar os principais
processos de gestão durante o ciclo de vida dos projetos. O Gerente de Projetos utiliza suas funcionalidades e características para
gerenciar não somente os eventos incertos inerentes a todo e qualquer projeto, como também para organizar a equipe de riscos,
suas tarefas relacionadas às estratégias de respostas, bem como os recursos designados para esse fim. No entanto, não seria tão
eficaz para comunicar, dar visibilidade ou incentivar discussões em busca de soluções por parte dos stakeholders.
Figura 1 – Exemplo de relatório de status gerenciável de riscos

Fonte: o autor.
Para que uma reunião de status fosse mais produtiva e eficaz seria bem mais interessante sintetizar as informações em formatos
de relatórios mais gerenciáveis, com foco nas informações que realmente interessam e comunicam bem ao stakeholder A figura .
demonstra um exemplo de relatório de status gerenciável, com dados extraídos dos programas de computador de gestão de riscos.
Note que as informações expostas levam ao conhecimento dos participantes sobre o real problema, se são de natureza interna ou
externa à companhia, sobre o grau do risco (alto, médio ou baixo, para efeitos de visibilidade), a possível alternativa de solução e a
quem deve ser endereçado. Ou seja, em um único quadro você pode comunicar os principais riscos de um projeto dando
visibilidade a todos sobre quais medidas estão sendo tomadas para que sejam devidamente tratados.
Caso seja necessário, você pode até levar consigo informações mais detalhadas para serem apresentadas. Porém, reuniões deste
tipo costumam ser rápidas, objetivas e diretas, o que não deixa muito espaço para apresentações longas e complexas.
A segunda coisa importante é que deveria obrigatoriamente incluir uma lista dos riscos correntes considerados como altamente
prioritários. Os status de riscos, bem como custos e prazos, poderiam ser indicados como as cores do semáforo (uma comum
convenção), com a cor vermelha para indicar problemas sérios, a cor amarela para indicar situações de perigo e a cor verde para
sinalizar que tudo está correndo muito bem.
Mulcahy (2010) nos alerta que, se você tem intenção de incluir os status dos riscos no seu relatório periódico você deveria se
preocupar em coletar o máximo possível de informações sobre os riscos do projeto. Estas informações podem ser coletadas via e-
mail ou formulários específicos de coletas de dados. Mas, o mais importante é que quanto mais consistentes forem as informações
apresentadas, melhor será o desempenho do time de trabalho e maiores serão as chances de fazerem bem o trabalho logo da
primeira vez, reduzindo e muito o retrabalho nas suas atividades.
Pode parecer incrível, mas o simples fato de você listar os riscos mais prioritários em um relatório periódico
durante uma reunião pode diminuir significativamente a chance de eles ocorrerem. Isso acontece porque a
equipe de projetos e os principais stakeholders tendem a manter o foco nestes riscos, pois todos
conhecerão sobre eles e todos estarão, mesmo que não diretamente, observando se têm chance de ocorrer
ou não. Se você teve o cuidado ainda de incluir as possíveis origens do risco, maior a possibilidade de
manterem mais foco nesta lista. Esta boa prática pode ainda ser melhorada se você tiver o hábito de,
durante suas reuniões de andamento do projeto, incluir discussões sobre os riscos mais prioritários, revelar
suas origens e os impactos que poderão causar caso ocorram. Não seria apenas uma dramatização de um
evento, mas uma forma eficaz de comunicar eventos incertos em projetos. Fonte: Kerzner (2009).
As lições aprendidas do plano de gestão de riscos
Presente em quase todos os processos de Gestão de Projetos, esta é uma prática que tem um efeito muito produtivo, se e quando
aplicada de maneira correta. Segundo o PMI (2013), faz parte inclusive dos ativos de processo organizacionais, como está definido
abaixo:
Ativos de processo organizacionais [...] informações históricas e base de conhecimento de lições aprendidas
(por exemplo, projetos, registros e documentos; todas as informações e documentação de encerramento do
projeto, informações a respeito de resultados de projetos e de decisões de seleção de projetos anteriores, e
informações de desempenho dos mesmos; e informações sobre as atividades de gerenciamento dos riscos).
Como podemos notar, presente também na gestão de riscos do projeto.
De acordo com Vargas (2007), as lições aprendidas em gestão de riscos deveriam incluir uma avaliação bem apurada do registro de
riscos. Mesmo porque esta avaliação teria o principal propósito de identificar o que foi feito que deu bons resultados e o que deu
de errado, e ainda o que poderia ser feito de maneira diferente no próximo projeto. São registros valiosos que podem ser
elaborados pelo Gerente de Projetos e pelo seu time – com contribuição de outros stakeholders – e que deveriam ser
armazenados para consulta em projetos futuros. Como se fosse uma base de dados de históricos de projetos disponível para
outros Gerentes de Projetos utilizarem como dados iniciais para a elaboração do plano de gestão de riscos em seus projetos.
As lições aprendidas, como você deve ter percebido, pode ser proveniente dos processos de auditoria de riscos, comentada
anteriormente. Vargas (2007) afirma que a formalização dessa base de dados histórica de projetos tem por objetivo prevenir que
os mesmos erros sejam cometidos em projetos posteriores, implicar melhorias contínuas nos processos de gestão de riscos e até
evitar desperdícios de tempo e dinheiro em projetos futuros. A avaliação das lições aprendidas deveria ainda contemplar as áreas
de gestão do projeto como um todo (não só se atendo à gestão de riscos), de gerenciamento incluindo os processos de
comunicação e liderança e as questões técnicas envolvidas no projeto.
De acordo com Greene e Stellman (2010), uma das melhores formas de se adquirir lições aprendidas a respeito da gestão de riscos
é você mesmo promovê-la. Fomentar novas ideias e reconhecê-las, criar um ambiente de entusiasmo (não de competição) e incitar
a criatividade são atitudes que podem incentivar os stakeholders não só em querer colaborar mais com o projeto, mas também em
criar uma cultura de registros dos acontecimentos para que sejam utilizados posteriormente em outros projetos.
Processos finais de controle e monitoramento de riscos
De acordo com Vargas (2007), um dos processos importantes do controle e monitoramento de riscos é a manutenção constante do
registro de riscos, de maneira que proporcione o rastreamento do evento incerto desde sua identificação, análise e tratamento
adequado até o seu fechamento. Informações como os resultados das reavaliações e da auditoria de riscos, o fechamento dos
riscos que tiveram seus planos de respostas implantados de modo eficaz, detalhamento do que aconteceu quando o risco se
manifestou e as lições aprendidas deveriam estar presentes no registro de riscos do projeto.
De acordo com Mulcahy (2010), o principal propósito da governança de riscos é estar o tempo todo alinhado com os princípios do
controle e monitoramento dos riscos. A governança deveria estar presente durante todo o ciclo de vida do projeto e abordar a
supervisão de todos os processos de gestão de riscos, buscando garantir que as atividades de gestão de riscos sejam consistentes e
agreguem valor não só ao projeto como também à companhia. A governança de riscos deveria ser estabelecida na gestão de riscos
para que fosse possível oferecer ao Gerente de Projetos subsídios para que ele pudesse iniciar o planejamento de gestão de riscos
do seu projeto não do zero, mas de uma base já consolidada com informações sobre as principais falhas e acertos de projetos
anteriores.
Mulcahy (2010) afirma que o gerenciamento de riscos deveria ser, na sua essência, a somatória de processos otimistas, mesmo
quando se está identificando ameaças graves ao projeto. Trata-se de tomar o controle da situação e estar no comando, quando
bem aplicadas às boas práticas de gestão de riscos.
Quando este comportamento e atitude são tidos como exemplo, principalmente pela figura do Gerente de Projetos, há uma forte
tendência em se criar um ambiente amistoso e produtivo entre os stakeholders do projeto. Dessa maneira, mesmo com os
problemas pertinentes a todo e qualquer projeto, estima-se que o time buscará sempre a sinergia necessária para desempenhar
seus papéis e responsabilidades de forma profissional, buscando resultados cada vez mais satisfatórios nos projetos.
Chegamos ao final do nosso estudo a respeito do controle e monitoramento de riscos, mais precisamente sobre os processos de
auditoria de riscos, os processos comunicacionais necessários para a compreensão dos riscos por parte dos stakeholders e os
benefícios gerados pela criação e manutenção da base de dados histórica por meio do registro das lições aprendidas sobre os
riscos do projeto.
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.
Avançar

ATIVIDADES
1. A gestão das reservas de contingência seria de responsabilidade principal:
a) Do proprietário do risco associado
b) Da alta administração do projeto
c) Do Gerente de Projetos do projeto
d) Do principal stakeholder do time de riscos
e) Do auditor externo ao projeto e à companhia
2. Assinale nas sentenças, a seguir, a única que se apresenta como incorreta:
( ) A gestão de riscos em um projeto deve ser tratada como um documento vivo e cíclico que não deveria ser feita uma única
vez.
( ) Reuniões de avaliações periódicas dos riscos faz parte dos processos de monitoramento e controle dos riscos.
( ) Não há uma regra específica que padronize o uso de reservas de contingências na gestão de riscos em projetos.
( ) Eventos incertos nos projetos ocorrem na mesma sequência que as atividades do caminho crítico do projeto.
( ) Os ativos de processos organizacionais de uma empresa podem influenciar na eficácia da gestão de riscos nos projetos.
3. Qual das seguintes alternativas NÃO seria uma verdade sobre a gestão de riscos?
a) Riscos devem analisados de acordo com seu impacto e sua chance de ocorrer
b) A equipe de projetos e o Gerente de Projetos devem elaborar relatórios de riscos distintos para diferentes stakeholders.
c) O gerente de projetos deveria ser o único responsável por identificar novos riscos no projeto.
d) Na gestão de riscos estar em conformidade significa implantar o plano de resposta ao risco de acordo com as ações
planejadas.
e) Reservas de contingência deveriam ser aplicadas somente aos riscos conhecidos e previamente mapeados.
4. Associe os termos com suas respectivas definições, assinalando nos parênteses a letra correspondente ao termo específico:
I. Processos de monitoramento e controle de riscos
II. Soluções de contorno
III. Análise de Valor Agregado
IV. Revisão de riscos
V. Ações corretivas
( Método de medição quantitativa

) e monitoração de desempenho de execução geral do projeto em relação ao planejamento
inicial.
( ) Mudanças implantadas para trazer o projeto de volta ao seu curso natural.
( Implantação dos planos de respostas aos riscos, caso o mesmo ocorra, identificar novos riscos
) e avaliar a efetividade das
respostas aos riscos.
( ) Respostas não planejadas aos riscos não identificados que ocorreram no projeto.
( ) Análise dos planos de gestão dos riscos elaborados pelo time de riscos para determinar se ainda são apropriados.
a) III – V – I– II – IV.
b) I – V – II – IV – III.
c) IV – V – III – I– II.
d) V – II – I – III – IV.
e) II – I – IV – III – V.
5. Qual a periodicidade adequada pela qual o Gerente de Projetos deveria discutir sobre os riscos com sua equipe de projeto?
a) Durante o desenvolvimento dos planos de respostas aos riscos.
b) Durante a aplicação da análise de valor agregado.
c) Em toda reunião de andamento e de status do projeto.
d) Duas vezes por semana.
e) Somente na presença na alta administração da companhia.
6. Qual das sentenças abaixo você consideraria como FALSA?
a) Índice de desempenho de custos acima de 1,0 significa boa situação do projeto.
b) A implantação de soluções de contorno pode prejudicar o desempenho do projeto.
c) Reuniões de andamento do projeto devem ser periodicamente conduzidas pelo Gerente de Projetos.
d) As restrições iniciais do projeto devem ser analisadas ao se implantar um plano de resposta ao risco.
e) A alta administração de uma empresa deveria participar efetivamente dos processos de gerenciamento de riscos.
7. A revisão e reavaliação dos riscos já mapeados no projeto incluem todas as sentenças seguintes, EXCETO:
a) Avaliação da alteração na lista de prioridade dos riscos.
b) Monitoramento dos riscos presente no registro de riscos.
c) Ajustes no ‘risk score’ de riscos que ainda não ocorreram no projeto.
d) Análise das solicitações e implantações de mudanças no projeto.
e) Registro da efetividade dos planos de contingência e de backup.
8. O grau de tolerância aos riscos deveria ser identificado durante qual processo da gestão de riscos?
a) Análise Quantitativa dos riscos.
b) Elaboração dos planos de respostas aos riscos.
c) Revisão e reavaliação do registro de riscos.
d) Elaboração do planejamento dos riscos do projeto.
e) Controle e monitoramento dos riscos
9. Associe os termos com suas respectivas definições, assinalando nos parênteses a letra correspondente ao termo específico:
I. Avaliação da efetividade
II. Reavaliação dos riscos
III. Grau de tolerância aos riscos
IV. Revisão de riscos
V. Política e procedimentos na gestão de riscos
( ) O quanto um stakeholder ou a organização como um todo está disposta a correr certos riscos.
( ) Muito produtivo para as abordagens iniciais de todo e qualquer projeto da companhia.
( ) Medições para avaliar e determinar os resultados da ações tomadas.
( ) Processo de identificação de novos riscos quando mudanças são feitas no projeto.
( ) Análise dos planos de gestão dos riscos elaborados pelo time de riscos para determinar se ainda são apropriados.
a) I – III – V – IV – II.
b) III – V – I– II – IV.
c) II – V – IV – III – I.
d) V – IV – I – III – II.
e) IV – II – III –V – I.
10. Qual das alternativas tem a MELHOR descrição dos processos de auditoria de riscos:
a) O gerente de projetos tem a responsabilidade de auditar sozinho cada risco do projeto.
b) Um auditor interno revisa cada processo para descobrir se a equipe não está gerando novos riscos.
c) Os stakeholders se reúnem e discutem como tratarão os resultados da auditoria de riscos.
d) Os processos de auditoria de riscos olham para o passado para descobrir o que deu certo ou errado, enquanto que a revisão
de riscos olha para o futuro.
e) O time de projetos nomeia um auditor de riscos que responderá diretamente ao Gerente de Projetos.
11. Com qual propósito se deveria garantir a existência da governança de riscos no projeto?
a) Determinar as responsabilidades dos proprietários de cada risco.
b) Dar subsídios para que o time de projetos possa compreender melhor as necessidades do cliente.
c) Garantir a consistência das práticas de gestão de riscos ao longo do ciclo de vida do projeto e na companhia como um todo.
d) Verificar se o plano de contingência é adequado e, caso não seja, ajustá-lo adequadamente.
e) Levar ao conhecimento da alta administração sobre determinados riscos com alto impacto para o projeto.
12. Qual das seguintes sentenças você consideraria como NÃO correta?
a) Os processos comunicacionais são importantes para o Gerente de Projetos poder passar informações aos stakeholders.
b) Lições aprendidas de gestão de riscos podem ser representadas por um repositório de dados na forma de documentos
eletrônicos.
c)Post Mortem é uma técnica que simula o projeto já encerrado para identificar possíveis problemas que poderiam ter
acontecido.
d) A maioria dos riscos pode ser fechada antes mesmo do encerramento total do projeto.
e) Auditoria de riscos é realizada para se identificar novos riscos.
Avançar

RESUMO
Ao final desta unidade compreendemos o quão importante se mostra o estabelecimento de métricas e indicadores que auxiliam na
identificação se os planos de gestão de riscos estão sendo executados de acordo com o que planejamos e se encontram em
conformidade, ou seja, se há desvios e se estão sendo controlados adequadamente.
Aprendemos em quais circunstâncias devemos empregar as reservas de contingência (aquelas obtidas a partir das análises mais
detalhadas dos riscos conhecidos pelo time do projeto) e das reservas de gerenciamento (providas pela alta administração das
companhias, para os riscos que não puderam ser identificados durante o planejamento).
Pudemos aprender como as ações corretivas se fazem necessárias na gestão de riscos, pois devemos estudar sempre cenários
possíveis e simular situações para encontrar as melhores alternativas de solução e então aplicá-las.
Abordamos a efetividade de uma ferramenta muito útil, a análise de valor agregado, como indicador de desempenho dos
processos de gestão dos riscos. Pudemos avaliar que os resultados desse tipo de análise, principalmente com relação aos
indicadores de custos e prazos, são de muita utilidade enquanto avaliamos os riscos do projeto associados a estes recursos.
Vimos que nem todo risco pode ser identificado e tratado na fase de planejamento e que para os riscos desconhecidos que vão
surgindo durante o desenvolvimento do projeto precisamos também responder a eles, criando estratégias de tratamento para
diminuir os impactos causados por eles.
Abordamos o estabelecimento das melhores políticas, procedimentos e boas práticas de gestão dos riscos, como a criação de uma
base de dados histórica de projetos e de gestão de riscos baseada em lições aprendidas a serem utilizadas em projetos posteriores
nas organizações. Vimos ainda a importância da implantação de uma governança de riscos, que contemplam inclusive auditorias
periódicas nos processos de gestão dos riscos, buscando sempre a melhoria contínua nestes processos.
Por fim, pudemos compreender o quão importante é a atuação e postura tanto do Gerente de Projetos e de seu time quanto dos
integrantes da alta administração das organizações frente às boas práticas de gestão de riscos. Este engajamento associado às
ferramentas, técnicas e boas práticas de gestão de riscos nos mostrou que o intuito principal seria o implantar uma cultura de
gestão de riscos na companhia, disseminando-a aos seus colaboradores e incentivando a aplicação de bons hábitos de gestão de
riscos. Aprendemos que estas iniciativas podem proporcionar aos stakeholders do projeto ser cada vez mais colaborativos e
voltados a prover ótimos resultados aos objetivos dos projetos.
De posse destas e de outras técnicas, ferramentas e boas práticas de gestão de riscos, além de muita dedicação ao planejamento
adequado e ao controle na execução dos planos elaborados, tenha certeza de que você irá contribuir e muito para que os
resultados dos projetos estejam o mais próximo e fiel possível aos objetivos previamente traçados.
Uma ótima jornada a todos.
Avançar

Na Web
apresenta um podcast de dezembro de 2010 discute a importância do
monitoramento e controle dos riscos no processo de gerenciamento de
riscos. Ricardo afirma que os riscos são “vivos” e que o monitoramento é a
única garantia de que a resposta a ser dada será realmente efetiva. 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

REFERÊNCIAS
DINSMORE, P.C.; CABANIS-BREWIN, J. AMA manual de gerenciamento de projetos Rio de Janeiro: Brasport, 2009.
.
KERZNER, H. Project Management A systems approach to planning, scheduling and controlling. 10. ed. New York: John Wiley &
:
Sons Inc., 2009. p. 753-788.
MAXIMIANO, A. C. A. Administração de Projetos como transformar ideias em resultados.

: 5. ed. São Paulo: Atlas, 2014.
MULCAHY, Rita Risk Management Tricks of the Trade for Project Managers and PMI-RMP Exam Prep Guide. 2.ed. RMC
. :
PMSURVEY, World Report 2014. A Global initiative of PMI Chapters Disponível em: Acesso em: 13. Jul. 2016.
. .
SBRAGIO, R. Engenharia Econômica e Análise de Riscos. Escola Politécnica da Universidade de São Paulo, 2009.
SILVA, A. F. de A.; ARAÚJO, R. Â.; CABRAL, S. Integração da gestão estratégica, governança e gestão de riscos Impacto da crise de :
2008 em duas companhias de alimentos. Disponível em: www.spell.org.br/documentos/download/18404 Acesso em: 13. Jul. .
2016.
SOFTEXPERT, Software para Análise e Gestão de Riscos Corporativos – ERM. Disponível em: http://www.tgnbrasil.com.br/gestao-
de-riscos-corporativos-erm/ Acesso em: 13. Jul. 2016.
.
STEX, Tecnologia para Execução da Estratégia. Disponível em: http://www.stex.com.br/ Acesso em: 13. Jul. 2016. .
VARGAS, Ricardo V. FIVE minutes podcast. Disponível em: Acesso em: 13. Jul. 2016.
.
VARGAS, Ricardo V. Manual prático do plano de projeto utilizando o PMBOK Guide . 3. ed., Rio de Janeiro, Editora Brasport,
2007.
Avançar

APROFUNDANDO
INTEGRAÇÃO DA GESTÃO ESTRATÉGICA, GOVERNANÇA E

GESTÃO DE RISCOS: IMPACTO DA CRISE DE 2008 EM DUAS
COMPANHIAS DE ALIMENTOS
O relato de caso a seguir traz à luz a importância da implantação de uma política de riscos e da governança aplicada à gestão de
riscos em duas companhias do segmento alimentício. Trata-se da empresa Sadia, que à época da avaliação – 2008 – apresentava
dificuldades financeiras e prejuízos nas suas operações e da empresa Perdigão, que no mesmo período apresentava resultados
mais satisfatórios.
Porém segundo Silva, Araújo e Cabral (2013), estes resultados não eram suficientes para se sustentarem em um mercado tão
competitivo frente à crise de 2008. A empresa Perdigão empregava processos mais robustos de análise e gestão de riscos e exercia
algumas políticas de riscos em seus projetos, principalmente de natureza financeira, enquanto que a Sadia, apesar de ser uma
empresa de grande porte, não aplicava políticas robustas de riscos. Nesse quesito, a Sadia tinha uma gestão familiar e pouco
aderente à gestão de riscos em seus projetos.
A Sadia era uma empresa que buscava diversificar sua linha de produtos buscando sempre a inovação e a Perdigão era uma
companhia que buscava excelência nas suas operações, objetivando a sua eficiência produtiva e comercial. As duas empresas se
fundiram em meados de 2009 dando origem à BRF Brasil Foods, na qual as políticas, procedimentos e governança de riscos antes
aplicada somente a Perdigão, tiveram seus processos revistos e foram incorporadas à nova empresa criada na fusão.
Com as novas políticas de gestão de riscos elaboradas para a nova empresa os resultados financeiros começaram a se estabilizar e
se tornaram competitivos no segmento novamente. Houve um processo de lição aprendida, porém ao custo de uma elevada perda
financeira e administrativa enfrentada pela Sadia. Após a fusão das companhias, a política financeira para o mercado de câmbio se
manteve próxima das orientações aplicadas anteriormente pela Perdigão, porém com índices ainda mais conservadores.
Compreendemos que as práticas de governança de riscos são constituídas por diversos procedimentos característicos. Portanto,
se torna crucial não apenas analisar a aplicabilidade dessas práticas, mas também analisar como estão sendo monitoradas na
companhia. O fato nos revelou a necessidade de se revisarem as estratégias de gestão e governança de riscos nos projetos das
organizações, principalmente de natureza financeira, para que possam manter ou, na melhor das hipóteses, aumentar seu poder de
competitividade no segmento de atuação.
Fonte: Silva, Araújo e Cabral (2013, on-line).
PARABÉNS!
Avançar

EDITORIAL
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ Núcleo de Educação .
a Distância; SAMPAIO Paulo. ,
54 p.
CDD - 22 ed. 658
Fotos Shutterstock
:
Retornar

Gestão de Riscos em Projetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestão de Riscos em Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

Unidade 1 Página inicial

Me. Paulo Sampaio

• 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 gerenciamento de riscos

• Formas de identificação de riscos

• Técnicas de identificação de riscos

Primeiramente, abordaremos as estratégias necessárias e pertinentes à gestão de riscos, baseadas fundamentalmente no

UNICESUMAR | UNIVERSO EAD

Conceitos importantes para o plano de gerenciamento de riscos

que é isso? Vamos compreender juntos um pouco desse conceito.

Precisamos conhecer melhor aqui a definição de stakeholders. As versões em português do PMBOK® os

Fonte: PMI (2013).

Resultados do plano de gerenciamento de riscos

Figura 1 - Escala de probabilidade de riscos

Fonte: Adaptado de PMI (2013).

Fonte: Mulcahy (2010, p. 131).

Figura 2 - Escala de impacto de riscos

principais interessados nos resultados do projeto.

Figura 3 - Modelo de Matriz de riscos

Fonte: Adaptado de PMI (2013).

Figura 4 - Estrutura Analítica de Riscos

• Delphi, relativamente parecida com o brainstorming porém com

• Produção riscos associados

• Fatores internos riscos associados

projeto incompleto ou indefinido etc.

Fonte: Greene e Stellman (2010, p. 548).

Fonte: Mulcahy (2010, p. 363).

Fonte: Palma et al. (2011).

Fonte: Mulcahy (2010, p. 71).

Diagrama de Causa e Efeito

Figura 5 - Diagrama de Ishikawa (ou Espinha de Peixe ou Diagrama de Causa e Efeito

• Houve muitas mudanças de escopo durante o desenvolvimento.

• Esse tipo de programa de computador nunca havia sido desenvolvido antes.

Figura 6 - Diagrama de Ishikawa para o problema de atraso na entrega do fornecedor

Fonte: Adaptado de Seleme e Stadler (2008, p. 91).

• 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.

Figura 7 - Formulário básico 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)

Opinião dos especialistas

Figura 8 – Modelo de registro de riscos em projetos

Fonte: Adaptado de Mulcahy (2010, p. 109).

Fonte: Mulcahy (2010).

• Técnicas, ferramentas e boas práticas.

UNICESUMAR | UNIVERSO EAD

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.

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.

3. Os dois componentes principais de um risco são: