fmea em riscos
DESCRIPTION
arquivo sobre FMEA e prevenção dos riscosTRANSCRIPT
-
Universidade Federal de Santa CatarinaCentro Tecnolgico
Curso de Bacharelado em Sistemas de Informao
USO DO FMEA COMO FERRAMENTA PARA ANLISE DE RISCOS EM PROJETOS
RAFAEL MOREIRA DOMINGUES
Florianpolis SC
Ano 2008/1
-
RAFAEL MOREIRA DOMINGUES
USO DO FMEA COMO FERRAMENTA PARA ANLISE DE RISCOS EM PROJETOS
Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de
Bacharel em Sistemas de Informao
Orientadora: Profa. Dra. Maria Marta Leite
Banca ExaminadoraProf. Dr. Joo Cndido Dovicchi
Profa. Dra. Elizabeth Sueli Specialski
-
Sumrio.........................................................................................................................INTRODUO 6
...................................................................................Objetivo Geral 10
......................................................................Objetivos Especficos 10..................................................DEFINIES E CONCEITOS RELACIONADOS A RISCO 12
..............................................................................................................................PROJETO 13................................................................GERENCIAMENTO DE RISCOS EM PROJETOS 22
...................................Planejamento do gerenciamento de riscos 24
...................................................................Identificao de Riscos 24
.........................................................Anlise Qualitativa de Riscos 25
.......................................................Anlise Quantitativa de Riscos 27
..............................................Planejamento de respostas a riscos 29
............................................Monitoramento e controle dos riscos 30.....................................................................................................................................FMEA 32
..............................................................................FMEA de Projeto 36
.............................................................................FMEA de Sistema 39
...........................................................................FMEA de Processo 40
..............................................................................FMEA de Servio 48...............................................................USO DO FMEA EM CONJUNTO COM O PMBOK 50
.........................................................................................................................CONCLUSO 56.......................................................................................................TRABALHOS FUTUROS 58
......................................................................................................................REFERNCIAS 59
-
Lista de Abreviaturas e Siglas
ASQ: American Society for Quality
DFMEA: Design Failure Mode and Effects Analysis
FMEA: Failure Mode and Effects Analysis
NASA: National Aeronautics and Space Administration
PFMEA: Process Failure Mode And Effects Analysis
PMBoK: Project Management Body of Knowlodge
PMI: Project Management Institute
-
1 INTRODUO
Sempre que se olha para o futuro lida-se com incertezas. As pessoas
sempre tiveram que lidar com este fato, e, conseqentemente, correr riscos ao longo
de toda a histria da humanidade (SALLES JR. et al., 2006, p. 20). Entretanto, no
se pode considerar a incerteza como uma questo de sorte ou azar. Se algum
deseja ter domnio sobre os acontecimentos futuros, deve exercitar a sua
capacidade de previso (SALLES JR. et al, 2006, p. 24-25).
A administrao de riscos surgiu como uma forma de mensurar e
controlar a incerteza, atribuindo-lhe um tamanho ou valor atravs da probabilidade.
Afinal, s possvel controlar e gerenciar aquilo que pode ser mensurado (SALLES
JR et al, p. 20).
Este conceito importante em reas como a financeira e a de seguros,
visto que elas vivem do risco. Mas tambm fundamental em gerenciamento de
projetos, visto que todo projeto envolve um certo grau de incerteza (GIDO e
CLEMENTS, 2007, p. 5). Por isso existe uma disciplina em gerenciamento de
projetos que busca mensurar e gerenciar as incertezas decorrentes de um projeto,
denominada gerenciamento de riscos.
No mbito de projetos, riscos so eventos em potencial que podem
ameaar ou beneficiar um projeto (HELDMAN, 2005, p. 3). No mesmo sentido, o
PMBoK (Project Management Body of Knowlodge Corpo de Conhecimentos de
Gerenciamento em Projetos) caracteriza como objetivos da gerncia de riscos
aumentar a probabilidade e o impacto de eventos positivos e diminuir a
probabilidade e o impacto de eventos adversos ao projeto (PMI, 2004, p. 237).
Quando um risco assumido com conscincia, espera-se que o retorno
deste seja melhor do que o nus em caso de perda (HELDMAN, 2004, p. 2).
Entretanto, importante ressaltar que riscos podem ser benefcios potenciais, ou
seja, oportunidades que traro um impacto positivo ao projeto.
Porm, mesmo na literatura de gerenciamento de projetos, comum
considerar o risco apenas no sentido de ameaa. Esta a viso de autores como
6
-
ALENCAR e SCHMITZ (2005, p. 18), que definem risco como a probabilidade de
que um fator de risco venha a assumir um valor que possa prejudicar, total ou
parcialmente, as chances de sucesso de um projeto (ALENCAR e SCHMITZ, 2005,
p. 18), e KASSE (2004), que define risco como a possibilidade de perda e
complementa esta definio dizendo que riscos so eventos futuros, com
probabilidade de ocorrncia e com potencialidade para perdas (KASSE, 2004).
Entretanto, Heldman (HELDMAN, 2004, p. 3) explica que este enfoque no se deve
ao fato de se ter uma viso pessimista, e sim que riscos negativos so assassinos
de projetos.
Para evitar que os riscos negativos eliminem as chances de sucesso de
um projeto, evitar que as perdas com uma falha de um projeto tenha conseqncias
mais graves, e evitar que oportunidades passem desapercebidas, gerentes de
projetos devem valer-se de ferramentas, tcnicas e metodologias para identificar,
documentar, priorizar, monitorar, e traar planos de ao para quando um risco for
detectado (PMI, 2004, p. 237-238).
Estas ferramentas podem ser classificadas em indutivas ou dedutivas.
Induo constitui pensar de casos individuais para uma concluso genrica. Se,
considerando um determinado sistema, ns postulamos uma falha particular ou
condio inicial, e tentamos descobrir o efeito desta falha ou condio na operao
do sistema, ns estamos construindo uma anlise de sistema indutiva (VESELY e
GOLDBERG 1981).
J a deduo constitui pensar do geral para o especfico. Em uma
anlise de sistema dedutiva, ns postulamos que um sistema falhou de alguma
forma, e tentamos descobrir de que modo o comportamento do sistema ou de um
componente contribuiu para a falha (VESELY e GOLDBERG, 1981).
Este trabalho trata sobre a utilizao de uma ferramenta indutiva para
auxiliar gerentes de projetos nas atividades de identificao, documentao,
priorizao e monitoramento de riscos em seus projetos. Esta ferramenta,
denominada Failure Mode and Effect Analysis (FMEA), surgiu no exrcito americano
como forma de reduzir a quantidade e a probabilidade de falhas em equipamentos
7
-
que no poderiam ser consertados. Mais tarde ela foi adotada e aprimorada pela
indstria automobilstica, a fim de evitar que problemas chegassem at o
consumidor (DAILEY, 2004, p. 5).
O FMEA um procedimento analtico que tem como objetivo verificar
todos os componentes de um sistema, analisando seus modos de falha e, por
conseqncia, o seu efeito na confiabilidade do produto, sistema ou funo
necessria (PMI, 2004, p. 351-352). Apesar do enfoque inicial desta tcnica ser a
qualidade percebe-se sua utilidade para o gerenciamento de riscos, visto seu
enfoque em identificar modos de falha.
8
-
1.1 JUSTIFICATIVA
Segundo o CHAOS Report 2007, relatrio publicado pela Standish Group
(STANDISH GROUP, 2007, p. 1), com o resultado de pesquisas sobre a qualidade
dos projetos no mundo, a quantidade de projetos entregues no prazo, dentro do
oramento e com todos os requisitos atendidos cresceu de 26% em 1998 para 35%
em 2006. Esta estatstica complementada com a reduo do nmero de projetos
que falharam, os quais representavam 28% em 1998 e em 2006 passaram a
representar 19%. Entretanto, a quantidade de projetos que tiveram algum problema
em algum destes pilares continuou representando 46% dos projetos. Isto significa
que em 2006, 65% dos projetos tiveram algum tipo de problema.
Porm, mesmo tendo em vista estes dados, a gerncia de riscos
provavelmente uma das reas de conhecimento da gerncia de projetos que com
mais freqncia deixada de lado em projetos de pequeno e mdio porte
(HELDMAN, 2005, p. 4).
Segundo Heldman (HELDMAN, 2005, p. 4), aplicar o gerenciamento de
riscos ajuda a gerenciar projetos de sucesso, que melhoram o desempenho, lucro,
eficincia, provem melhor presena de mercado, e auxiliam a alcanar os objetivos
da organizao.
Um dos fatores que dificulta a implantao da gerncia de riscos o fato
da documentao de referncia como o CMMI (SEI, 2006) e o PMBoK (PMI,
2004), no apresentam um mtodo especfico para esta atividade. Esta informao
confirmada por CALSAVARA et al (2000), que diz que para manterem-se genricos
o suficiente para poderem ser adaptados aos vrios contextos a que se destinam,
estes modelos e normas estabelecem o que deve ser feito e no como deve ser
implementado.
Considerando o que foi citado, percebe-se que necessrio auxiliar e
apoiar gerentes de projetos de pequeno e mdio porte no que tange a gerncia de
9
-
riscos. Se esta for aplicada de forma pr-ativa, a chance de um projeto morrer
inesperadamente, e levar junto com ele muitos recursos, reduzida.
1.2 OBJETIVOS
1.2.1 OBJETIVO GERAL
Este trabalho tem como objetivo demonstrar o uso de uma metodologia
indutiva (FMEA) para realizar a anlise e gerncia de riscos em projetos segundo o
que proposto pelo PMBoK verso 2004.
1.2.2 OBJETIVOS ESPECFICOS
- Apresentar um estudo sobre a rea de Gerenciamento de Riscos do
PMBoK.
- Apresentar os pressupostos bsicos da metodologia FMEA.
- Demonstrar a possibilidade do uso da metodologia FMEA de forma
anloga ao que proposto no captulo de Gerenciamento de Riscos
do PMBoK.
1.3 DELIMITAO DO ESCOPO
O trabalho abordar conceitos das metodologias PMBoK, edio de 2004
mantida pela PMI, e FMEA, edio de 2003 mantida pela ASQ.
1.4 HIPTESE DA PESQUISA
Conforme descrito no PMBoK, as normas do gerenciamento de projetos
no abordam todos os detalhes de todos os tpicos (PMI, 2004, p. 4). Em paralelo,
h uma metodologia bem documentada, testada e largamente utilizada na indstria
10
-
para aumentar a qualidade dos produtos entregues aos clientes. Podemos utilizar
esta metodologia bem-documentada em conjunto com a disciplina de gerncia de
riscos do PMBoK?
1.5 METODOLOGIA DE DESENVOLVIMENTO
Ser realizada uma pesquisa bibliogrfica sobre FMEA e o Corpo de
Conhecimentos de Gerenciamento em Projetos (PMBoK), e proposta uma forma de
utilizao do FMEA como ferramenta para o realizao do Gerenciamento de Riscos
em Projetos.
1.6 ORGANIZAO DO TRABALHO
O presente trabalho est dividido em quatro partes: introduo,
fundamentao, anlise e consideraes finais. Na Introduo esto contidos a
justificativa, os objetivos, e a hiptese do trabalho. Na Fundamentao esto
contidos os captulos de Riscos, Projetos, Gerenciamento de Projetos, PMBoK,
Gerenciamento de Riscos em Projetos segundo o PMBoK e FMEA. Em Anlise, est
a proposta de utilizao do PMBoK em conjunto com o FMEA. Nas Consideraes
Finais esto os captulos de Concluso, Trabalhos Futuros e Referncias
Bibliogrficas.
11
-
2 DEFINIES E CONCEITOS RELACIONADOS A RISCO
No senso comum, riscos so sempre eventos negativos. Pode-se
confirmar isto com o conceito de risco nos dicionrios Houaiss, que o define como
probabilidade de insucesso, de malogro de determinada coisa, em funo de
acontecimento eventual, incerto, cuja ocorrncia no depende exclusivamente da
vontade dos interessados (HOUAISS E VILLAR, 2001), e Aurlio, onde diz perigo
ou possibilidade de perigo (FERREIRA, 2000).
Esta definio tambm pode ser encontrada na literatura de
gerenciamento de projetos, como exemplo o caso dos autores Alencar et al
(ALENCAR et al, 2005, p. 18), que definem fator de risco como qualquer evento que
possa prejudicar, total ou parcialmente, as chances de sucesso do projeto, e por
sua vez, risco como a probabilidade de que um fator de risco venha a assumir um
valor que possa prejudicar, total ou parcialmente, as chances de sucesso de um
projeto.
Segundo Salles Jr. et al (SALLES JR et al, 2006, p.20), a origem da
palavra risco do italiano antigo e do latim, onde significava respectivamente
ousar (BERNSTEIN, 1997 apud SALLES JR. et al, 2006, p.20), e incerteza; neste
sentido, a palavra risco deve ser interpretada como um conjunto de incertezas
encontradas quando ousamos fazer algo.
Tambm pode acontecer uma confuso entre risco e problema. Porm,
h uma clara distino entre ambos: problemas esto acontecendo, enquanto riscos
podem acontecer. Um projeto que possui vrios riscos negativos, no
necessariamente possui problemas (HELDMAN, 2005, p. 15).
Sempre que existe um risco, existe a possibilidade de retorno positivo.
Os primeiros registros sobre riscos esto ligados teoria das probabilidades, que
foram desenvolvidas para aplicao em jogos, notadamente os de azar (SALLES
JR. et al, 2006, p. 20). Segundo HELDMAN (2005), as organizaes e pessoas
assumem riscos quando o benefcio do risco maior que as conseqncias da falha.
12
-
3 PROJETO
Na lngua portuguesa a palavra Projeto um homnimo que significa
tanto concepo tcnica, desenho (como no Ingls design), quanto um conjunto de
esforos, tarefas e recursos para se atingir a um objetivo (equivalente ao termo
Ingls project) (GIDO e CLEMENTS, 2007, p. 4). O Projeto ao qual referem-se este
trabalho e suas referncias o equivalente a palavra inglesa project.
Segundo a definio do PMI (2004, p. 21), projeto um esforo
temporrio empreendido para criar um produto, servio ou resultado exclusivo. Gido
e Clements (GIDO e CLEMENTS, 2007, p. 4) complementam que projeto um
esforo para se atingir um objetivo especfico por meio de um conjunto nico de
tarefas inter-relacionadas e da utilizao eficaz de recursos.
Todos os projetos comeam com objetivos. O objetivo do projeto
alcanar e satisfazer os objetivos que os stakeholders1 aceitaram quando o projeto
foi iniciado (HELDMAN, 2005, p. 3). Os objetivos normalmente so definidos por seu
escopo, cronograma e custo (GIDO e CLEMENTS, 2007 p. 4). Estes fatores so
definidos no PMBoK como escopo, tempo e custo do projeto, e so denominados
como restrio tripla, e o seu balanceamento definir a qualidade do projeto. Estes
fatores esto intimamente relacionados, sendo que se algum mudar, pelo menos
outro dever ser afetado (PMI, 2004, p. 24).
O escopo do projeto definido pelo PMBoK como o trabalho que precisa
ser realizado para entregar um produto, servio ou resultado com caractersticas e
funes especificadas (PMI, 2004, p. 104). Gido e Cliements (GIDO e CLEMENTS,
2007, p. 6) complementam dizendo que o escopo do projeto refere-se ao processo
que deve ser realizado para que todos os itens, produtos ou servios tangveis a
serem fornecidos cumpram os requisitos ou critrios de aceitao acordados no
incio do projeto.
13
1 Stakeholder: Pessoas e organizaes, como clientes, patrocinadores, organizaes executoras e o pblico, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execuo ou trmino do projeto. Elas podem tambm exercer influncia sobre o projeto e suas entregas (PMI, 2004, p.371)
-
O projeto temporrio porque tem um incio e um fim definidos, sendo
que considera-se como fim quando os objetivos estabelecidos no incio forem
atingidos ou quando constatar-se que eles no podero ser alcanados (PMI, 2004).
O projeto tem por caracterstica ser temporrio e exclusivo para ser
diferenciado de um trabalho operacional. Ambos so realizados por pessoas,
restringidos por recursos limitados, planejados, executados e controlados. Porm, as
atividades operacionais so contnuas e repetitivas (PMI, 2004, p. 22).
3.1 GERENCIAMENTO DE PROJETOS
Segundo o PMBoK, o gerenciamento de projetos a aplicao de
conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de
atender aos seus requisitos (PMI, 2004, p. 8).
J Gido e Clements (GIDO e CLEMENTS, 2007) explicam que gesto de
projeto significa planejar o trabalho e depois executar o plano, ou seja, gesto de
projeto envolve primeiro um processo de estabelecimento de um plano e depois a
implementao deste plano para atingir o objetivo do projeto.
3.2 PMBOK
O PMBoK, publicado quadrianualmente pelo PMI, a soma dos
conhecimentos intrnsecos profisso de Gerenciamento de Projetos (PMI, 2004),
e tem como objetivo identificar o subconjunto do conjunto de conhecimentos em
gerenciamento de projetos que amplamente reconhecido como boa prtica (PMI,
2004). Este captulo ser desenvolvido utilizando o PMBoK (PMI, 2004) como nica
referncia.
O PMBoK baseia-se em processos para a realizao do projeto. Processo
um conjunto de aes e atividades inter-relacionadas realizadas para obter um
conjunto especificado de produtos, resultados ou servios (PMI, 2004, p. 373). Todo
14
-
processo utiliza conhecimento, habilidades, ferramentas e tcnicas do
gerenciamento de projetos, que recebem entradas e geram sadas. (PMI, 2004, p.
37). Ao todo, o PMBoK descreve 44 processos (PMI, 2004, p. VIII).
Entradas, no contexto do PMBoK, so itens internos ou externos ao
projeto, que so exigidos por um processo para que ele seja realizado. Esta entrada
pode ser uma sada de um processo antecessor (PMI, 2004, p. 362). Por sua vez,
sadas so produtos, resultados ou servios gerados por um processo (PMI, 2004,
p. 376).
Dentro de um processo a transformao de uma entrada em uma
sada realizada por ferramentas e tcnicas do gerenciamento de projetos.
Ferramentas so sempre tangveis, e usadas na realizao de uma atividade para
produzir um produto ou resultado (PMI, 2004, p. 364), enquanto tcnicas so
procedimentos sistemticos para realizar uma atividade a fim de produzir um
produto ou resultado ou oferecer um servio, e que pode empregar uma ou mais
ferramentas (PMI, 2004, p. 378).
Em sua terceira edio, o PMBoK est dividido em trs sees,
denominadas de estrutura do gerenciamento de projetos, norma de
gerenciamento de projetos e reas de conhecimento em gerenciamento de
projetos.
A primeira seo, a estrutura de gerenciamento de projetos, uma
introduo ao gerenciamento de projetos, explicando termos-chave do ciclo de vida
e organizao do projeto.
A segunda seo, norma de gerenciamento de projetos, explica os cinco
grupos de processos de gerenciamento de um projeto. Um processo um conjunto
de aes e atividade inter-relacionadas realizadas para obter um conjunto pr-
especificado de produtos, resultados ou servios (PMI, 2004, p. 38).
Entretanto, no se deve considerar cada grupo como uma fase do projeto.
Em um projeto dividido em fases, cada fase deve repetir os cinco grupos de
processos (PMI, 2004, p. 41).
15
-
O primeiro grupo de processos o de iniciao, onde desenvolve-se o
termo de abertura do projeto ou da fase, e a declarao do escopo preliminar do
projeto, ou seja, a iniciao de uma nova fase, sua validao e refinamento (PMI,
2004, p. 45).
O grupo seguinte o de planejamento, onde so desenvolvidas todas as
atividades decorrentes do planejamento, conforme ilustrado na figura 3.1. Destas
pode-se destacar o desenvolvido o plano de gerenciamento do projeto, que se
tornar a principal fonte de informaes de como o projeto ser planejado,
executado, monitorado e controlado, e encerrado (PMI, 2004, p. 48); a definio do
escopo do projeto, onde elaborada a sua definio detalhada, e o planejamento do
gerenciamento, identificao, anlise qualitativa, anlise quantitativa e planejamento
de respostas a riscos, temas que ainda sero abordados com mais detalhes neste
trabalho.
Os processos usados para terminar o trabalho definido no plano de
gerenciamento do projeto constituem o grupo de processos de execuo, onde
alm da execuo do projeto ser orientada, a equipe do projeto mobilizada (ou
contratada) e desenvolvida, as informaes so disponibilizadas s partes
interessadas e fornecedores so selecionados.
16
-
Figura 3.1 - Grupo de processos de planejamento (PMI, 2004, p. 47)
O grupo de processos de monitoramento e controle formado pelos
processos responsveis pela observao da execuo do projeto, permitindo que a
equipe tenha uma viso clara da sade do projeto, de forma que possveis
problemas possam ser identificados no momento adequado e que possam ser
17
-
tomadas aes corretivas, quando necessrio, para controlar a execuo do
projeto (PMI, 2004, p. 59).
Finalmente, o grupo de processos de encerramento, onde esto os
processos responsveis por finalizar formalmente todas as atividades do projeto ou
da fase, entregando o produto terminado ou encerrando o projeto cancelado (PMI,
2004, p. 66).
A terceira seo, denominada reas de conhecimento em gerenciamento
de projetos, discorre sobre nove reas de conhecimento em gerenciamento de
projetos. So elas: integrao, escopo, tempo, custos, qualidade, recursos humanos,
comunicaes, riscos e aquisies do projeto (PMI, 2004, p. 71). Os processos
desta terceira seo so os mesmos apresentados na segunda seo, porm
classificando os processos por rea de conhecimento, e no por etapa no
desenvolvimento do projeto. Alm disso, na terceira seo os processos so
abordados de forma mais detalhada. O relacionamento entre as duas sees pode
ser observado na tabela 3.1.
A primeira rea de conhecimento, denominada gerenciamento de
integrao do projeto, inclui os processos e as atividades necessrias para
identificar, definir, combinar, unificar e coordenar os diversos processos e atividades
de gerenciamento de projetos dentro dos grupos de processos de gerenciamento de
projetos (PMI, 2004, p. 77).
A integrao requisitada sempre que processos de diferentes reas
necessitam interagir. Entre os processos da integrao, podemos destacar o
desenvolvimento do termo de abertura, do escopo preliminar e do plano de
gerenciamento do projeto, a orientao da execuo e o monitoramento do trabalho,
e o encerramento do projeto (PMI, 2004, p. 78).
O gerenciamento do escopo do projeto a segunda rea de
conhecimento do PMBoK. O objetivo do gerenciamento do escopo garantir que o
projeto inclua todo o trabalho necessrio, e somente ele, para terminar o projeto com
sucesso (PMI, 2004, p. 103).
18
-
Tabela 3.1 - Mapeamento entre grupos de processos e reas de conhecimento (PMI, 2004, p. 70)
19
-
A palavra escopo pode se referir a duas definies distintas. A primeira
o escopo do produto, que identifica as caractersticas e funes que descrevem
um produto, servio ou resultado (PMI, 2004, p. 104). A outra o escopo do
projeto, que define o trabalho que precisa ser realizado para entregar um produto,
servio ou resultado com as caractersticas e funes especificadas (PMI, 2004, p.
104). O captulo de gerenciamento do escopo do projeto refere-se ao segundo
conceito.
Entre os processos da rea de conhecimento em gerenciamento do
escopo do projeto pode-se destacar o planejamento, a definio detalhada, a
verificao e o controle do escopo, e a criao da Estrutura Analtica do Projeto
(EAP). A EAP, tambm chamada de WBS ou Work Breakdown Structure, uma
estrutura que visa organizar e definir o escopo total do projeto, decompondo o
escopo em pacotes de trabalho, (PMI, 2004, p. 363) que por sua vez inclui as
atividades do cronograma e os marcos do cronograma necessrios para terminar a
entrega (PMI, 2004, p. 371).
A rea de conhecimento gerenciamento de tempo do projeto inclui os
processos necessrios para realizar o projeto dentro do prazo. Os seis processos
descritos nesta rea de conhecimento interagem entre si e entre processos de
outras reas de conhecimento. Entretanto, estes seis processos podem se sobrepor
ou se unirem em um nico, dependendo da abrangncia do escopo (PMI, 2004, p.
123).
A quarta rea de conhecimento trata dos custos do projeto. Esta rea,
denominada de gerenciamento de custos do projeto visa garantir que o projeto seja
concludo dentro do oramento aprovado, e trata principalmente do custo dos
recursos necessrios para terminar as atividades do cronograma (PMI, 2004, p.
156).
Os processos de gerenciamento de qualidade do projeto compem a
quinta rea de conhecimento, e so responsveis por garantir que o projeto atenda
s necessidades que motivaram a sua realizao. A descrio desta rea de
conhecimento procurou ser compatvel com a da ISO, Gerenciamento de Qualidade
20
-
Total (GQT), Seis Sigma, FMEA, revises de projeto, voz do cliente, custo da
qualidade e melhoria contnua (PMI, 2004, p. 180).
A sexta rea de conhecimento a de gerenciamento de recursos
humanos do projeto. Esta rea responsvel por organizar e gerenciar a equipe do
projeto, ou seja, as pessoas com funes e responsabilidades atribudas para o
trmino do projeto (PMI, 2004, p. 199).
A stima rea, denominada gerenciamento das comunicaes do
projeto, constituda dos processos necessrios para garantir a gerao, coleta,
distribuio, armazenamento, recuperao e destinao final das informaes sobre
o projeto de forma oportuna e adequada (PMI, 2004, p. 221)
O gerenciamento de riscos do projeto aparece no PMBoK como oitava
rea, e constituda pelos processos responsveis pela anlise, respostas,
monitoramento e controle e planejamento do gerenciamento de riscos em um
projeto (PMI, 2004, p. 237). Este captulo ser descrito com mais detalhes nos
captulos seguintes.
A ltima rea de conhecimento a ser descrita pelo PMBoK denominada
de gerenciamento de aquisies do projeto. Esta rea composta pelos processos
para comprar ou adquirir produtos, servios ou resultados necessrios de fora da
equipe do projeto para realizar o trabalho (PMI, 2004, p. 269).
Esta rea tambm responsvel pelo gerenciamento de contratos, tanto
com fornecedores quanto com clientes, e pela administrao de obrigaes
contratuais estabelecidas para a equipe do projeto (PMI, 2004, p. 269).
21
-
4 GERENCIAMENTO DE RISCOS EM PROJETOS
O gerenciamento de riscos consiste em identificar as possveis incertezas
e tentar control-las. O nvel de conhecimento em algum assunto pode ser dividido
em trs categorias: quanto todas as informaes sobre algo so conhecidas, h a
certeza absoluta. Este caso no pode ser classificado como risco, e sim como um
caso conhecido. Quando se detm apenas algumas informaes sobre algo, h a
incerteza, visto que no se tem todas as informaes necessrias para prever um
fato. E quando no h nenhuma informao sobre algo, temos a total incerteza
(SALLES JR. et al., 2006, p. 26).
O gerenciamento de riscos deve ser realizado dentro do espectro da
incerteza, conforme apresentado na figura 4.1.
Figura 4.1 - Espectro do Gerenciamento de Riscos do projeto. Adaptado de SALLES JR. (2006), p. 26
Segundo HELDMAN (2005), a gerncia de riscos constituda de cinco
passos bsicos:
identificao e documentao de riscos;
anlise e priorizao;
preparao de um plano de aes;
22
-
monitoramento e controle do plano;
realizao de auditorias e revises.
importante que todos os passos do gerenciamento de riscos sejam
executados. Conforme RAMOS (2006),
O processo de gesto de riscos deve ser seguido em sua
totalidade. De nada adianta durante a fase de
planejamento do projeto fazer o planejamento de
gerenciamento dos riscos, a identificao dos riscos,
anlise qualitativa e quantitativa, elaborar um plano de
respostas aos riscos e deixar este plano arquivado.
preciso que o processo de monitoramento e controle de
riscos tambm seja executado.
Segundo HELDMAN (HELDMAN, 2005, p. 10-12), os riscos tendem a
acontecer no incio do projeto. Porm, quanto mais avanado o estgio do projeto,
maior ser o impacto de um risco. Isto nos leva a reforar que a gerncia de riscos
deve ser feita durante todo o projeto, e no apenas em alguns momentos deste.
Segundo esta autora, a gerncia de riscos significa investir competncias,
conhecimento e ferramentas de gerncia de riscos para reduzir perigos a um nvel
aceitvel, enquanto maximiza-se oportunidades.
O conceito mais aceito para risco em gerenciamento de projetos como
apresentado no PMBoK, que o define como sendo um evento ou condio incerta
que, se ocorrer, ter um efeito positivo ou negativo sobre pelo menos um objetivo do
projeto, como tempo, custo, escopo ou qualidade (PMI, 2004, p. 8).
Com isso, o PMBoK especifica que o objetivo do gerenciamento de
riscos do projeto aumentar a probabilidade e o impacto dos eventos positivos e
23
-
diminuir a probabilidade e o impacto dos eventos adversos ao projeto (PMI, 2004, p.
237).
Nos prximos tpicos, sero descritos os processos da rea de
conhecimento em gerenciamento de riscos, de acordo com a verso de 2004 do
PMBoK.
4.1.1 PLANEJAMENTO DO GERENCIAMENTO DE RISCOS
O planejamento do gerenciamento de riscos deve ser feito no incio do
projeto. Ele o processo de decidir como abordar e executar as atividades de
gerenciamento de riscos em um projeto (PMI, 2004). Uma das sadas desta fase a
metodologia abordagens, ferramentas e fontes de dados que sero utilizadas no
gerenciamento de riscos.
4.1.2 IDENTIFICAO DE RISCOS
Identificao de riscos um processo que deve ser desenvolvido durante
todo o ciclo de vida do projeto, visto que novos riscos podem ser identificados a
qualquer momento. Ela determina os riscos que podem afetar o projeto e
documenta suas caractersticas (PMI, 2004).
O processo de Identificao de riscos normalmente conduz ao processo Anlise qualitativa de riscos. Alternativamente, tambm
pode conduzir diretamente ao processo Anlise quantitativa de riscos, quando realizado por um gerente de riscos experiente. (PMI, 2004).
Este processo utiliza como entrada os fatores ambientais da empresa,
ativos de processos organizacionais (informaes de projetos anteriores),
declarao de escopo do projeto, plano de gerenciamento de riscos e o plano de
gerenciamento do projeto.
Entre as ferramentas e tcnicas da Identificao de riscos, esto as
revises da documentao, tcnicas de coleta de informaes, anlise da lista de
verificao, anlise das premissas e tcnicas com diagramas.
24
-
Tcnicas de coleta de informaes so especificadas no PMBoK como
Brainstorming, tcnica Delphi (onde especialistas preenchem um questionrio
anonimamente, e as respostas so discutidas posteriormente), entrevistas com
participantes experientes, partes interessadas e especialistas, identificao da
causa-raiz e anlise de pontos fortes e fracos, oportunidades e ameaas.
A sada deste processo o registro de riscos, que constitudo por uma
lista de riscos identificados e as respostas possveis, as suas causas-raiz, e a lista
de categorias de risco atualizada.
4.1.3 ANLISE QUALITATIVA DE RISCOS
A anlise qualitativa de riscos prioriza os riscos identificados no processo
de identificao de riscos. Conforme descrito no PMBoK, ela avalia a prioridade dos
riscos identificados usando a probabilidade deles ocorrerem, o impacto
correspondente nos objetivos do projeto se os riscos realmente ocorrerem, alm de
outros fatores, como o prazo e tolerncia a risco das restries de custo,
cronograma, escopo e qualidade do projeto (PMI, 2004).
As ferramentas utilizadas por este processo so a avaliao de
probabilidade e impacto dos riscos, a matriz de probabilidade e impacto, a avaliao
da qualidade dos dados sobre riscos, a categorizao de riscos e a avaliao da
urgncia do risco.
A avaliao de probabilidade e impacto de riscos , como o nome sugere,
investiga as probabilidades e os impactos que um risco que venha a ocorrer tem
sobre cada objetivo do projeto. Estas informaes so necessrias para a
construo da Matriz de Probabilidade e Impacto, e nesta etapa so definidas as
escalas que sero utilizadas. Para a probabilidade, utilizam-se valores desde muito
improvvel at quase certeza. Alternativamente, possvel usar probabilidades
numricas atribudas em uma escala geral (PMI, 2004). Por sua vez, as escalas de
impacto so especficas do objetivo potencialmente afetado, do tipo e tamanho do
projeto, da situao financeira e estratgias da organizao e da sensibilidade da
organizao a impactos especficos (PMI, 2004). Para esta, utiliza-se valores
25
-
desde muito baixo at muito alto, sendo que a estes podem ser atribudos valores
lineares (como uma progresso aritmtica), ou no-lineares, como o apresentado na
Figura 4.2. As escalas no-lineares podem representar o desejo da organizao de
evitar ameaas de alto impacto ou de explorar oportunidades de alto impacto,
mesmo se elas tiverem uma probabilidade relativamente baixa. No uso de escalas
no-lineares importante entender o significado dos nmeros e como se relacionam
entre si, como so derivados e o feito que podem ter sobre os diversos objetivos do
projeto (PMI, 2004).
Figura 4.2 - Matriz de probabilidade e impacto (PMI, 2004, p. 252)
A matriz de probabilidade e impacto obtida atravs dos resultados das
definies de probabilidade e impacto dos riscos. Ela constitui uma tabela, onde o
valor definido para as probabilidades multiplicado pelo valor definido para o
impacto, resultando um valor que define a prioridade do risco. A tabela til para
26
-
definir quais riscos so prioritrios, e para facilitar a identificao, orienta-se utilizar a
cor vermelha para riscos altos, amarela para riscos moderados e verde para riscos
baixos. No caso de a matriz ser em preto e branco, utiliza-se os tons de cinza para
indicar a grau do risco, sendo o tom mais escuro o mais alto.
A avaliao da qualidade dos dados sobre riscos visa garantir que os
dados sobre riscos possuem um grau de utilidade relevante para o gerenciamento
de riscos. Ela envolve examinar at que ponto o risco entendido e tambm a
exatido, qualidade, confiabilidade e integridade dos dados sobre riscos (PMI,
2004).
A categorizao de riscos constitui agrupar os riscos por fonte de risco,
pela rea do projeto afetada ou por outra categoria til, para determinar as reas do
projeto mais expostas aos efeitos da incerteza (PMI, 2004). Este agrupamento
pode possibilitar o desenvolvimento de respostas a riscos eficazes (PMI, 2004).
Por ltimo, a avaliao da urgncia do risco orienta que deve-se
considerar mais urgentes os riscos que exigem respostas a curto prazo.
A anlise qualitativa de riscos tem como sada a atualizao do registro
de riscos, incluindo a classificao relativa ou a lista de prioridades dos riscos do
projeto, o seu agrupamento por categorias, uma lista de riscos que exigem resposta
a curto prazo, a lista de riscos para anlise e resposta adicionais e a lista de
observao de riscos de baixa prioridade.
4.1.4 ANLISE QUANTITATIVA DE RISCOS
Nesta etapa, os processos priorizados na anlise qualitativa de riscos tm
seus efeitos analisados e atribuda uma classificao numrica a eles. Este
processo usa tcnicas como a simulao de Monte Carlo e a anlise da rvore de
deciso para (PMI, 2004):
- Quantificar os possveis resultados do projeto e suas probabilidades.
- Avaliar a probabilidade de atingir objetivos especficos do projeto.
27
-
- Identificar os riscos que exigem mais ateno quantificando sua
contribuio relativa para o risco total do projeto.
- Determinar a melhor deciso de gerenciamento de projetos quando
algumas condies ou resultados forem incertos.
A anlise quantitativa de riscos utiliza duas tcnicas para fazer as anlises
probabilsticas no gerenciamento de riscos: tcnicas de representao e coleta de
dados, e anlise quantitativa de riscos e tcnicas de modelagem.
Esto descritas como tcnicas de representao e coleta de dados as
entrevistas, que consistem em coletar informaes em diferentes cenrios (como
otimista, pessimista e mais provvel ou mdia), a distribuio de probabilidades, que
podem ser feitas com valores contnuos (para representar incerteza nos valores,
como por exemplo os custos dos componentes ou a durao das atividades), ou
discretos (para representar eventos incertos, como um cenrio possvel em uma
rvore de deciso), e a opinio especializada, a fim de validar os dados e as
tcnicas.
Como anlise quantitativa de riscos e tcnicas de modelagem,
comumente so utilizadas as seguintes tcnicas:
- anlise de sensibilidade, que examina a extenso com que a
incerteza de cada elemento do projeto afeta o objetivo que est sendo
examinado quando todos os outros elementos incertos so mantidos
em seus valores de linha de base (PMI, 2004);
- anlise do valor monetrio esperado, conceito estatstico que calcula
o resultado mdio quando o futuro inclui cenrios que podem ou no
acontecer (PMI, 2004);
- anlise da rvore de deciso, que descreve uma situao que est
sendo considerada e as implicaes de cada uma das escolhas
disponveis e cenrios possveis (PMI, 2004);
28
-
- modelagem e simulao, onde o modelo do projeto calculado
muitas vezes (iterado), sendo os valores das entradas randomizados a
partir de uma funo de distribuio de probabilidades (PMI, 2004).
A sada da Anlise Quantitativa de Riscos consiste em uma nova
atualizao do registro de riscos, tendo como componentes principais:
- anlise probabilstica do projeto;
- probabilidade de realizao dos objetivos de custo e tempo;
- lista priorizada de riscos quantificados;
- tendncias dos resultados da anlise quantitativa de riscos.
4.1.5 PLANEJAMENTO DE RESPOSTAS A RISCOS
A funo do planejamento de respostas a riscos determinar aes para
aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto (PMI,
2004). Nele so definidas as estratgias que sero utilizadas caso um risco seja
detectado, assim como identificados e designados responsveis para cada risco
acordado.
Trs estratgias so definidas para lidar com riscos negativos:
- Prevenir: significa que as ameaas devem ser eliminadas, isolando
assim os objetivos do projeto do impacto do risco ou flexibilizando o
objetivo que est sendo ameaado.
- Transferir: mais eficaz quando relacionada a riscos financeiros, a
transferncia de riscos no os elimina. Apenas os transfere para
terceiros a responsabilidade de seu gerenciamento. Exemplos de
transferncia so seguros e garantias.
- Mitigar: a mitigao de riscos exige a reduo da probabilidade e/ou
impacto de um evento de risco adverso at um limite aceitvel (PMI,
2004). A mitigao considera que menos prejudicial reduzir a
29
-
probabilidade ou impacto do risco enquanto ele est ocorrendo, do
que arcar com as conseqncias de seu acontecimento.
De mesma forma, trs so as estratgias definidas para lidar com os
riscos positivos:
- Explorar: estratgia que visa garantir que a oportunidade seja
concretizada.
- Compartilhar: de forma similar a transferncia, o compartilhamento
atribui a propriedade do risco a terceiros, porm visa que estes
possam capturar melhor a oportunidade em benefcio do projeto.
- Melhorar: visa aumentar a probabilidade ou o impacto positivo do
risco, atravs da identificao e maximizao de seus principais
acionadores.
Alm destas estratgias, existe ainda uma quarta utilizada tanto para
ameaas quanto para oportunidades, denominada de Aceitao. A aceitao
adotada porque raramente possvel eliminar todos os riscos de um projeto (PMI,
2004). A aceitao pode ser passiva ou ativa. Quando passiva, a equipe trata as
ameaas e oportunidades conforme ocorrem. Quando ativa, normalmente so
estabelecidas reservas para contingncias.
O PMBoK define ainda estratgias para respostas contingenciadas, que
devem ser usadas somente em caso de determinados eventos acontecerem. Os
eventos que provocam a resposta da contingncia [] devem ser definidos e
acompanhados (PMI, 2004).
4.1.6 MONITORAMENTO E CONTROLE DOS RISCOS
O Monitoramento e Controle de riscos um processo contnuo que deve
ser executado durante toda a vida do projeto. Seu objetivo encontrar novos riscos,
e monitorar as mudanas dos j identificados. Conforme descrito no PMBoK,
monitoramento e controle de riscos o processo de identificao, anlise e
30
-
planejamento dos riscos recm-surgidos, acompanhamento dos riscos identificados
e dos que esto na lista de observao, re-anlise dos riscos existentes,
monitoramento das condies de acionamento de planos de contingncia,
monitoramento dos riscos residuais e reviso da execuo de respostas a riscos
enquanto avalia sua eficcia (PMI, 2004).
O PMBoK ainda orienta que o monitoramento e controle de riscos deve
determinar se:
- As premissas do projeto continuam vlidas.
- O risco, conforme avaliado, mudou seu estado anterior.
- Os procedimentos e polticas de gerenciamento de riscos adequados
esto sendo seguidos.
- As reservas para contingncias dos custos ou do cronograma devem
ser modificadas de acordo com os riscos do projeto.
O monitoramento e controle de riscos consiste em reavaliar os riscos,
audit-los, realizao de anlise de tendncias e da variao, medio do
desempenho tcnico, anlise das reservas e a realizao de reunies de
andamento.
31
-
5 FMEA
Em 1949, foi criado no exrcito americano um processo formal
denominado Procedures for Performing a Failure Mode, Effects and Criticality
Analysis (Procedimentos para desenvolver uma anlise de modo, efeitos e
criticidade de falhas), que mais tarde foi denominado apenas FMEA (Failure Mode
and Effects Analysis, ou Anlise de Modo e Efeito de Falhas). Nos anos 60, a NASA
desenvolveu esta tcnica como parte do programa Apollo, com o objetivo de eliminar
falhas em equipamentos que no teriam como ser consertados aps lanados
(DAILEY, 2004, p.5).
FMEA uma tcnica de engenharia usada para definir, identificar e
eliminar falhas, problemas e erros conhecidos e/ou potenciais de sistemas, projetos,
processos e/ou servios antes que eles cheguem ao consumidor (STAMATIS, 2003
apud OMDAHL, 1988 apud ASQC, 1983).
O principal objetivo do FMEA evitar que problemas cheguem at o
consumidor final do produto, sistema, processo ou servio. Por isso, FMEA prov um
mtodo sistemtico para examinar todos os modos que uma falha pode ocorrer
(STAMATIS, 2003, p. 22).
Neste sentido, RAMOS (2006) explica que a tcnica de FMEA foi criada
com enfoque no projeto de novos produtos e processos, mas devido a sua grande
utilidade, passou a ser aplicada de diferentes formas e em diferentes tipos de
organizaes (RAMOS, 2006).
O FMEA surgiu da combinao de cinco tcnicas : Kaizen, Brainstorming,
Regra de Pareto, Anlise de Causa Raiz e Mapeamento de Processo (DAILEY,
2004, p. 6). Atualmente, so aceitos trs padres de FMEA: o J1739, mantido pela
SAE (Sociedade dos Engenheiros Automotivos), o FMEA-3, da AIAG (Grupo de
Ao da Indstria Automotiva), e a terceira edio do Manual de FMEA da ASQ
(Associao Americana para Qualidade) (DAILEY, 2004, p. 19). Este trabalho
utilizar como principal fonte o FMEA mantido pela ASQ, escrito por D. H. Stamatis
em 2003.
32
-
5.1 TIPOS DE FMEA
Originalmente existem dois tipos de FMEA: de Projeto ou DFMEA (Design
Failure Mode and Effects Analysis) e de Processo ou PFMEA (Process Failure Mode
and Effects Analysis) (DAILEY, 2004, p. 7 e QUALITY ASSOCIATES
INTERNATIONAL). Segundo Dailey (2004, p. 7), pode-se ainda personalizar o
FMEA utilizando critrios particulares. Segundo este autor esta personalizao um
adicional importante ao FMEA, por considerar atributos exclusivos de cada projeto, e
evitar o uso de material com direitos autorais.
Entretanto, Stamatis apresenta vrios outros tipos de FMEA, dos quais
pode-se destacar: de Sistema (System FMEA), uma variao do DFMEA realizada
anteriormente a este, com o objetivo de analisar sistemas e subsistemas no incio da
concepo do projeto; e de Servio (Service FMEA), uma variao do PFMEA,
realizado em substituio a este quando no h entrega de um produto, e sim de um
servio. Seu objetivo identificar modos de falha potenciais ou conhecidos e prover
aes corretivas e investigativas a um servio antes que ele alcance o consumidor
(STAMATIS, 2003, p. 40-43, 185).
Estes FMEAs propostos por Stamatis complementam e interagem com os
FMEAs originais, de projeto (Design), que segundo este autor utilizado para
analisar produtos antes que sejam disponibilizados para a produo, e de processo
(Process), usado para analisar os processos de manufatura e montagem.
Segundo o modelo de Stamatis, a sada do FMEA de Sistema utilizada
como entrada no FMEA de Projeto, que por sua vez vira entrada para o FMEA de
Processo e/ou de Servio (STAMATIS, 2003, p. 107), conforme a Figura 5.1.
33
-
Figura 5.1 Relao entre FMEA de Sistema, Projeto e Processo ou Servio. Adaptado de STAMATIS (2003), p. 108 e 110.
A relao entre o modo de falha e a(s) causa(s) no linear ou um-a-um.
Admite-se que exista uma ou vrias causas para um modo de falha. Deve-se
sempre listar todas as causas possveis. Quanto mais causas forem identificadas no
FMEA de Sistema, mais fcil ficar o FMEA de Projeto (STAMATIS, 2003, p.
119-120).
Todos os FMEAs so variaes de uma mesma tabela, com pequenas
modificaes que auxiliam na execuo da tarefa a que ele se prope. A figura 5.2
demonstra um modelo com o mnimo de colunas que uma tabela de DFMEA deve
possuir.
34
-
Figura 5.2 Modelo de DFMEA (STAMATIS, 2003, p. 135)
35
-
Um dos principais pontos do FMEA a classificao dos modos de falha
em itens de classificao, que definem trs pontos: o impacto de um modo de falha
(item 15 na figura 5.2), a capacidade de deteco para este modo de falha (item 19
na figura 5.2), e a freqncia que a falha pode ocorrer (item 17 na figura 5.2). O
produto destes trs valores cria o RPN (item 20 na figura 5.2), ou Risk Priority
Number. A funo do RPN priorizar os riscos mais crticos, com maior chance de
ocorrncia e menor probabilidade de deteco.
Cada projeto possui seus prprios itens de classificao, que devem ser
personalizados. Geralmente, h duas maneiras que os itens de classificao so
formulados: Qualitativos e quantitativos. Em ambos os casos, os valores numricos
podem ser de 1 a 5 ou de 1 a 10, sendo que de 1 a 10 a forma mais
comum (STAMATIS, 2003, p. 111).
Um dos objetivos do FMEA tomar as atitudes necessrias para que o
RPN de todos os modos de falha seja inferior a 50 , considerando que se adote 95%
de confiana, e que os trs itens de classificao estejam no intervalo de 1 a 10
(STAMATIS, 2003, p. 30).
5.1.1 FMEA DE PROJETO
O FMEA de Projeto (Design FMEA), tambm chamado de DFMEA, tem
como objetivo identificar os modos de falha, promovendo aes investigativas e
corretivas antes que a primeira produo ocorra. A primeira produo vista como a
que gera algum produto ou servio ao consumidor com a inteno de ser pago
(STAMATIS, 2003, p. 129).
Geralmente, no FMEA de Projeto utiliza-se uma lista estruturada de
materiais como informao bsica (DAILEY, 2004, p. 7). Ele normalmente
realizado durante o processo de engenharia do sistema, desenvolvimento do
produto, pesquisa e desenvolvimento, marketing, manufatura ou uma combinao
destes (BLANCHARD, 1986 apud STAMATIS, 2003, p.129).
36
-
Existem dois requisitos para a realizao de um FMEA de Projeto: a
identificao do formulrio correto, visto que no h um padro, e cada empresa
deve desenvolver o seu, baseado nas necessidades do consumidor e das suas
prprias; e a identificao dos itens para classificao, que tambm no possuem
um padro (STAMATIS, 2003, p. 133-134).
O DFMEA, segundo o modelo da ASQ, utiliza como entrada o resultado
do FMEA de Sistema, e fornece dados para os FMEAs de Servio e de Processo.
Para desempenh-lo, considera-se que o sistema est na melhor forma possvel.
Caso contrrio, os FMEAs de Sistema e de Projeto sero feitos simultaneamente, e
tendero a nunca terminar suas tarefas (STAMATIS, 2003, p. 133).
Algumas perguntas a serem feitas durante a execuo de um DFMEA so:- O que o produto faz, e quais so suas intenes de
uso? - Como o produto executa suas funes? - Que matrias-primas e componentes so utilizados para construir o produto? - Como, e em
que condies, o produto se comunica com outros produtos? - Que sub-produtos so criados pelo produto ou pelo uso do produto? -
Como o produto usado, mantido, consertado e descartado? - Quais so as etapas de manufatura na produo do produto? - Que fontes
de energia esto envolvidas e como? - Quem utilizar ou estar nas vizinhanas do produto, e quais so as capacidades e limitaes
destes indivduos? (STAMATIS, 2003, p. 132)
A tabela 5.1 apresenta uma sugesto de itens de classificao para o
Impacto, enquanto a tabela 5.2 apresenta uma sugesto para a capacidade de
deteco, e a tabela 5.3 para a ocorrncia. Nesta ltima tabela, consta uma coluna
para representar a nmero acumulado de falhas de componentes a cada 1000
exemplares (Cumulative Number of component Failures per 1000), identificada por
CNF/1000.
37
-
Tabela 5.1 - Guia de Impacto para FMEA de Projeto. Adaptado de STAMATIS (2003), p. 141
Tabela 5.2 - Guia de capacidade de deteco para FMEA de Projeto. Adaptado de STAMATIS (2003), p. 149
38
-
Tabela 5.3 - Guia de ocorrncia para FMEA de Projeto. Adaptado de STAMATIS (2003), p. 144
5.1.2 FMEA DE SISTEMA
O FMEA de Sistema uma variao de DFMEA, e utilizado
para analisar sistemas no estgio inicial de concepo e projeto (STAMATIS, 2003,
p. 40). Basicamente, ele utilizado durante o processo de engenharia do sistema,
desenvolvimento do produto, pesquisa e desenvolvimento, ou uma combinao
destes itens (BLANCHARD 1986, apud STAMATIS, 2003, p. 107).
O ganho que se obtm do FMEA de sistema demonstrar um balano
entre fatores operacionais e econmicos. Para alcanar este objetivo, o FMEA de
Sistema deve basear seus requisitos em expectativas e necessidades slidas dos
clientes (STAMATIS, 2003, p. 108). Assim como nos demais FMEAs, no existe um
formulrio padro para o FMEA de Sistema, visto que cada empresa possui clientes
com problemas diferentes (STAMATIS, 2003, p. 111).
39
-
5.1.3 FMEA DE PROCESSO
O FMEA de Processo (Process FMEA), tambm denominado PFMEA, ,
ao lado do DFMEA um dos tipos primrios de FMEA. Assim como o FMEA de
Projeto, o FMEA de Processo deve ser executado antes de o primeiro ciclo de
produo ocorrer. Esta definio de primeira execuo importante porque exclui
testes e prottipos, e nesta fase mudanas no projeto no causam grande impacto
(STAMATIS, 2003, p. 155).
A diferena entre o FMEA de Processo e o FMEA de Projeto est na
origem da informao: enquanto o FMEA de Projeto utiliza uma lista estruturada de
materiais, o FMEA de Processo utiliza diagramas de fluxo de processo como
documento fonte (DAILEY, 2004, p. 7).
O resultado esperado do FMEA de Processo um produto livre de
defeitos, ou a informao necessria para ser usada como base para o produto,
montagem e/ou o FMEA de Servio (STAMATIS, 2003, p. 155).
Entretanto, sabido que no fcil conhecer todos os processos no incio
da produo. Muitas vezes, o conhecimento sobre os processos desenvolvido no
decorrer do tempo. Ento, o FMEA de Processo se torna um documento vivo
(dinmico como contrrio a esttico) para refletir as mudanas nos
processos (STAMATIS, 2003, p. 156).
Geralmente, h dois tipos bsicos de tcnicas para conhecimento dos
processos que so utilizadas nos estgios iniciais. A primeira denomina-se Estudos
sobre habilidades do processo (process capability studies), onde so determinadas
as capacidades herdadas de elementos especficos do processo de produo.
A segunda denomina-se avaliao do processo obrigatrio (mandatory
process evaluation), onde cada empresa estabelece pontos de avaliao para
variveis especficas que so crticas para a operao ou o consumidor. Pode-se
sugerir como pontos obrigatrios de avaliao a certificao de funcionrios, a
validao de ferramentas, os processos crticos (que envolvem segurana,
40
-
consumidores ou regulamentos governamentais), e operaes de teste (STAMATIS,
2003, p. 156-157).
O objetivo do FMEA de processo definir, demonstrar e maximizar
solues de engenharia em resposta qualidade, confiabilidade, manuteno, custo
e produtividade (STAMATIS, 2003, p. 157).
Para alcanar este objetivo, o FMEA de processo deve basear seus requerimentos em necessidades, desejos e expectativas slidos do
consumidor. Como uma regra geral, estas informaes devem ser resultado de um QFD, ou uma necessidade interna para melhoria, ou
os resultados do FMEA de projeto (STAMATIS, 2003, p. 157).
A citada Distribuio de Qualidade de Funo (Quality Function
Deployment ou QFD) trata-se de um mtodo estruturado em que os requerimentos
do consumidor so traduzidos em requerimentos tcnicos apropriados, para cada
estgio do desenvolvimento e produo do produto (STAMATIS, 2003, p. 433).
Assim como no FMEA de Projeto, a tabela e os itens de classificao
devem ser personalizados. A figura 5.3 apresenta uma sugesto de modelo para o
FMEA de Projeto. Ele dividido em trs partes: A primeira, representada pelos itens
de 1 a 9, refletem uma introduo tabela. Estes itens no so obrigatrios, porm
fornecem informaes importantes que podem ser necessrias no curso do
desenvolvimento do FMEA (STAMATIS, 2003, p. 161).
A segunda parte representada pelos itens de 10 a 23. Estes itens so
obrigatrios para um FMEA de Processo. A ordem das colunas pode ser alterada, e
outras podem ser adicionadas. Porm, nenhuma coluna deve ser removida. Estes
itens devem ser vistos como o corpo do FMEA de Projeto (STAMATIS, 2003, p. 161).
A terceira parte so os itens 24 e 25. Estes itens so apenas assinaturas,
e assim como a primeira parte, no so obrigatrios. Porm, eles refletem a
autoridade e a responsabilidade da equipe em se comprometer com o projeto de
escrever o FMEA (STAMATIS, 2003, p. 161).
41
-
Figura 5.3 - Modelo de PFMEA (STAMATIS, 2003, p. 162)
42
-
Por ser a parte obrigatria do FMEA de processo, sero descritos apenas
os itens de 10 a 23, conforme o exposto por Stamatis (2003), nas pginas de 161 a
182.
O item 10, Funo do Processo, deve conter a inteno, propsito ou
objetivo do processo. Este item deve conter o que o processo , e no o que deveria
ser. Geralmente, identifica-se a funo do processo com um diagrama de fluxo
seguido por uma anlise de tarefas (STAMATIS, 2003, p. 163-165).
O item 11, Modo de Falha Potencial, identifica o problema, a
preocupao, a oportunidade de melhorar, a falha, a rejeio ou o defeito. Quanto
mais especfico for, melhor a oportunidade de identificao os efeitos e causas da
falha. Uma falha de processo ocorre quando um produto no protege contra riscos
de danos pessoais, falha em executar as funes desejadas com segurana, ou
falha em minimizar conseqncias evitveis no evento ou no acidente. Para cada
funo identificada no item 10, deve-se listar a falha correspondente da funo,
sendo que possvel haver mais de uma (STAMATIS, 2003, p. 165-166).
O item 12, Efeito Potencial da Falha, dever conter os efeitos potenciais
da falha, que a conseqncia de sua falha no prximo processo, operao,
produto, consumidor e/ou normas governamentais. Para identificar efeitos
potenciais, alguns dos documentos que devem ser revistos so: dados histricos,
documentos de garantia, reclamaes de usurios, dados de servios, dados de
confiabilidade, estudos de viabilidade, FMEAs similares passados - tanto de
processo quanto de projeto (STAMATIS, 2003, p. 166-168).
A coluna 13, abreviada como CC para Caractersticas Crticas (tambm
representada por um delta invertido, ou seja, um tringulo com um dos vrtices
apontando para baixo), deve ser preenchida apenas com um S de Sim, ou com um
N de No. Seu objetivo marcar uma caracterstica crtica potencial que deve ou
no existir. Exemplos de caractersticas crticas potenciais so dimenses, testes,
especificaes, e utilizao (STAMATIS, 2003, p. 167-168).
A coluna 14, abreviada como SEV, denominada impacto do efeito ou
severidade do efeito, e deve conter o grau indicativo da seriedade do efeito
43
-
potencial do modo de falha do processo. H uma correlao direta entre o efeito e o
impacto. Para fins de avaliao, normalmente h uma tabela que reflete os assuntos
da empresa em conjunto com o consumidor e/ou as normas governamentais. Um
exemplo de tabela de impacto apresentado na tabela 5.4.
Tabela 5.4 - Grau de Impacto do processo e/ou servio. Adaptado de Stamatis (2003), p. 169-170.
44
-
O Item 15, Causas Potenciais da Falha, representa a deficincia no
processo que resulta no modo de falha. Ela deve ser enfatizada repetidamente que
quando se foca na causa, deve-se olhar na causa raiz, no no sintoma da
falha. (STAMATIS, 2003, p. 168). Quanto mais se foca na causa raiz, mais se
compreende a falha. Portanto, primordial ser especfico neste campo. Um dos
mtodos utilizados para este campo perguntar cinco por qus em seqncia. A
relao entre modo de falha e suas causas no linear ou um-a-um. Muitas vezes,
h vrias causas para um modo de falha (STAMATIS, 2003, p. 168-172).
A coluna 16, abreviada como OCC, indica o valor correspondente ao
nmero estimado de freqncias e/ou nmero acumulado de falhas que poderiam
ocorrer para uma dada causa, sobre uma dada quantidade de partes produzidas
com os controles existentes (STAMATIS, 2003, p. 172). Quando a freqncia de
acontecimentos calculada, ela deve ser feita para todos os modos de falha. Se no
possvel estimar, deve-se utilizar o valor mximo (10). H uma grande variedade
de formas de gerar os ndices de ocorrncia. Uma sugesto dada na tabela 5.5.
Tambm pode-se selecionar utilizando um dos seguintes critrios: Escala FITS (1
FIT igual a aproximadamente uma ocorrncia a cada 109h), ndice de potencial de
processo (Process Capability Index ou Cpk, mtodo estatstico que verifica se a
distribuio da variao de um processo controlado est dentro de limites
especificados), ou critrios subjetivos (quando no h dados disponveis)
(STAMATIS, 2003, p. 172-173)
A coluna 17, Mtodo de Deteco, deve conter um mtodo, teste ou
anlise de engenharia. Estes mtodos podem ser simples (brainstorming, auditoria)
ou avanados (anlise de elementos finitos, padres militares, simulao
computacional, testes de laboratrio). Independente da tcnica, o objetivo detectar
o problema antes que ele chegue ao consumidor (STAMATIS, 2003, p. 173-178).
A coluna 18, Deteco, deve conter o ndice correspondente
probabilidade que os controles do processo atual iro detectar uma causa raiz
especfica de um modo de falha antes que a parte deixe a rea de
produo (STAMATIS, 2003, p. 178). Para identificar um ndice de deteco, deve-
45
-
se estivar a habilidade que cada um dos controles identificados no item 17 tem para
detectar a falha antes que ela atinja o consumidor. Deve-se tomar cuidado para no
considerar que a capacidade de deteco baixa apenas porque a ocorrncia
baixa. Estes valores podem ou no estar relacionados. Se a habilidade de deteco
dos controles for desconhecida, deve-se considerar o valor mximo (10). Um
exemplo de tabela de deteco apresentado na Tabela 5.6.
Tabela 5.5 - ndice de ocorrncia para PFMEA. Adaptado de Stamatis (2003), p. 174
A coluna 19, denominada RPN, possui o produto das colunas 14, 16 e 18.
O RPN, sigla para Risk Priority Number (Nmero de Prioridade de Risco), define a
prioridade de uma falha. Por si s, o RPN no possui nenhum significado. Eles so
utilizados apenas para indexar (definir) as deficincias potenciais do
processo (STAMATIS, 2003, p. 179). No FMEA de Processo, deve-se lembrar que o
objetivo reduzir o RPN, mas priorizando primeiro as falhas de maior impacto, em
seguida as de maior ocorrncia e, por ltimo, as de pior deteco. O impacto pode
ser reduzido apenas atravs de uma mudana no projeto. Se isto for possvel, ento
46
-
a falha eliminada (STAMATIS, 2003, p. 179). A ocorrncia pode ser reduzida ao
melhorar especificaes tcnicas e/ou requerimentos no processo que almejam
prevenir as causas ou reduzir a freqncia. E a deteco pode ser reduzida ao
melhorar as tcnicas de avaliao, aumentando o tamanho da amostra, ou
adicionando um equipamento detector.
Tabela 5.6 - ndice de capacidade de deteco para PFMEA. Adaptado de Stamatis (2003), p. 180
Todo FMEA deve possuir uma ao recomendada para reduzir o impacto,
ocorrncia ou aumentar a deteco de um modo de falha. O espao para isto a
coluna 20, na tabela proposta. A ao recomendada deve ser aes especficas ou
deve ser estudos futuros (STAMATIS, 2003, p. 179).
47
-
A coluna 21, denominada Pessoa/rea responsvel e data de finalizao
deve identificar a pessoa/rea responsvel pelo modo de falha, e a data de
finalizao da ao recomendada (STAMATIS, 2003, p. 181).
Por sua vez, a coluna 22 identifica que aes foram tomadas pela pessoa
responsvel, descrita na coluna 21. A ao tomada pode ter sido uma das aes
recomendadas, porm nem todas as aes recomendadas podem ter sido tomadas,
e pode-se executar outras aes que no constavam no documento (STAMATIS,
2003, p. 181).
O campo 23 deve constar, em suas quatro colunas, a reavaliao das
conseqncias do impacto, ocorrncia e deteco do modo de falha. Os resultados
devem ser revistos pela equipe do FMEA e um novo RPN deve ser calculado, e as
falhas indexadas (STAMATIS, 2003, p. 181). Este processo repetido at que a
equipe decida que todas as informaes relevantes foram cobertas. Se nenhuma
ao for tomada, estas colunas devem permanecer em branco.
5.1.4 FMEA DE SERVIO
O FMEA de Servio (Service FMEA) uma variao do PFMEA (FMEA de
Processo). Seu objetivo identificar modos de falha potenciais e prover aes
corretivas e investigativas antes do primeiro servio. (STAMATIS, 2003, p. 185). As
aplicaes do FMEA de servio so diversas, sendo que pode-se destacar o caso de
contratos de manuteno, instituies financeiras, escritrios de advocacia,
organizaes que lidam com questes de segurana, todos os contratos de
engenharia, indstria do turismo, instituies educacionais e governamentais
(STAMATIS, 2003, p. 185 - 187).
Geralmente, utilizam-se duas tcnicas bsicas para identificar os servios
nos estgios iniciais: Estudos de habilidade de processo, onde normalmente as
perguntas feitas so este servio pode ser feito, e como a organizao pode
prover este servio; e identificao de servios obrigatrios, onde a organizao
define variveis especficas que so crticas para o servio ou o consumidor
(STAMATIS, 2003, p. 189).
48
-
Algumas perguntas especficas para a realizao do FMEA de servio seriam: Qual a verdadeira performance e efetividade do
servio? O que faz o servio e o quais so suas intenes de uso? Qual a verdadeira efetividade do suporte? Os requerimentos
especificados inicialmente so apropriados para o servio? Eles esto sendo alcanados? Como o servio desenvolve sua funo? Que
materiais, e/ou outros servios so usados para entregar o servio? Como, e em que condies, o servio interfere com outros servios
(existentes ou planejados)? Que subprodutos so criados pelo servio ou pela entrega do servio? Como o servio utilizado,
mantido, modificado e descontinuado? Quais so os procedimentos operacionais para a entrega do servio? (STAMATIS, 2003, p. 191)
Servios envolvem a utilizao de seis componentes: trabalho, mquinas,
mtodos, materiais, medidas e ambiente. O objetivo do FMEA de Servio definir,
demonstrar e maximizar as solues em relao a qualidade, confiabilidade,
manuteno, custo e produtividade. (STAMATIS, 2003, p. 188-189).
49
-
6 USO DO FMEA EM CONJUNTO COM O PMBOK
Conforme descrito pelos autores de FMEA Stamatis (2003) e Dailey
(2004), o FMEA um formulrio que pode e deve ser personalizado para cada
situao, projeto ou empresa. Este captulo apresentar uma sugesto de
modificaes e modo de utilizao do FMEA com o objetivo de transform-lo em
uma ferramenta de gerenciamento de riscos em projetos.
Como o PMBoK um conjunto de melhores prticas, percebe-se algumas
semelhanas deste com o FMEA. Isto se deve tanto ao fato de ambos terem em
suas origens um conjunto de tcnicas em comum (Brainstorming, Pareto, Kaizen,
mapeamento de processos e Causa Raiz), quanto ao fato de o prprio FMEA ser
citado no documento mantido pela PMI, como no captulo da rea de conhecimento
em gerenciamento de qualidade em projetos.
Outro fator que auxilia a correlao entre o PMBoK e o FMEA o fato de
o PMBoK ser orientado a processos. Isto facilita a implantao da tcnica de FMEA,
em particular o FMEA de Processo, em um projeto que siga as prticas e
recomendaes do PMBoK.
Uma desvantagem do FMEA para o gerenciamento de riscos que ele foi
concebido para encontrar problemas potenciais no projeto, sistema ou processo, o
que acaba excluindo seu uso como ferramenta para anlise de riscos positivos.
Segundo o apresentado por Stamatis (2003), existem quatro tipos de
FMEA, sendo dois destes, de Projeto e de Processo, os tipos bsicos apresentados
por DAILEY (2004), e os outros dois, de Sistema e de Servio, derivados destes.
Segundo o que j apresentado neste trabalho, atravs da figura 5.1, o FMEA de
Sistema gerar as informaes necessrias para o FMEA de Projeto, que por sua
vez gerar as informaes necessrias para os FMEAs de Processo ou de Servio.
Em seu processo de Planejamento de respostas a riscos, o PMBoK
sugere classificar os riscos negativos ou ameaas com trs possveis estratgias:
Prevenir, Transferir ou Mitigar (PMI, 2004, p. 262). Para utilizar o FMEA como
50
-
ferramenta, a coluna para esta informao deve ser adicionada, a fim de manter esta
recomendao do PMBoK. Na figura 6.1 esta coluna denominada Estratgia.
O FMEA de Sistema, segundo Stamatis, visa analisar sistemas e
subsistemas nos estgios de conceito inicial e projeto. Tambm chamado de FMEA
conceitual, o FMEA de Sistema considerado uma introduo ao FMEA de Projeto.
Com esta informao, pode-se considerar o FMEA de Sistema o
formulrio ideal para o incio do projeto, a ser realizado em conjunto ao Grupo de
Processos de Iniciao, que possui entre seus processos o desenvolvimento do
termo de abertura do projeto e declarao inicial do escopo. Entretanto, importante
ressaltar que o FMEA de Sistema no deve ficar restrito aos processos do grupo de
processos de iniciao. Apenas deve-se comear a utiliz-lo nesta etapa.
Desta forma, sugere-se preencher a coluna Funo no projeto com cada
rea de conhecimento do PMBoK, conforme apresentado na figura 6.1. O objetivo
evitar que algum problema em alguma das reas passe desapercebido.
Aps serem levantadas as falhas potenciais neste nvel de FMEA e do
PMBoK, segundo Stamatis (2003) deve-se iniciar o FMEA de Projeto. Segundo este
autor, o FMEA de Projeto deve ser realizado durante o processo de engenharia do
sistema, desenvolvimento do produto, pesquisa e desenvolvimento, marketing,
manufatura ou uma combinao destes (STAMATIS 2003, p. 129 apud Branchard,
1986).
Por esta etapa necessitar de um nvel de detalhamento maior que a
anterior, sugere-se que seja desenvolvida uma tabela de FMEA de Projeto para cada
rea de conhecimento do PMBoK, e seja preenchida a coluna Funo no Projeto
com o nome de cada processo recomendado pelo PMBoK realizado. Na figura 6.2
est ilustrado um exemplo de FMEA de Projeto com a rea de conhecimento de
Gerenciamento de Aquisies em Projetos.
51
-
Figura 6.1 - Sugesto de FMEA de Sistema em conformidade com o PMBoK
52
-
Figura 6.2 - Sugesto de FMEA de Projeto, para a rea de Gerenciamento de Aquisies
53
-
Para a realizao do FMEA de Processo, que conforme o conceito do
FMEA deve ser o mais especfico de todos, sugere-se que para os processos com
RPN mais elevado, e cuja estratgia seja mitigar ou prevenir, desenvolva-se um
FMEA de Processo para detalhar melhor os modos de falha e as aes
recomendadas para cada um dos escolhidos. Segundo Stamatis (2003),
geralmente, a funo do processo identificada com diagrama de fluxo seguido por
uma anlise de tarefas (STAMATIS, 2003, p. 163).
importante lembrar que anlise de tarefas e identificao de tarefas no
so a mesma coisa. Enquanto a identificao de tarefas define o trabalho atravs de
anlises de sistema, linhas de tempo, anlise de tempo e movimento, anlise de
confiabilidade humana e diagrama de seqncia operacional (STAMATIS, 2003, p.
164), a anlise de tarefas define o que inicia a tarefa, os equipamentos usados para
realiz-la, a resposta humana, o retorno (feedback) da tarefa e as caractersticas da
sada da tarefa (STAMATIS, 2003, p. 164).
Os ndices de impacto, freqncia e capacidade de deteco tambm
devem ser personalizados dependendo do tipo de projeto e empresa executora.
Recomenda-se que sejam utilizados os ndices e guias apresentados para o FMEA
de Processo como base da personalizao.
54
-
55
-
7 CONCLUSO
Apesar de ser uma rea muitas vezes deixada de lado, o Gerenciamento
de Riscos demonstra ser to importante para o sucesso de um projeto quanto as
demais atividades do gerenciamento de projetos. Ignor-lo andar na escurido,
tornando o projeto vulnervel e com tendncia a ter crises, e em alguns casos
pnico, quando um evento inesperado ocorre. Da mesma forma, no realizar o
gerenciamento de riscos por consider-lo uma lista de problemas potenciais do
projeto significa perder a chance de corrigi-los, ou pelo menos mant-los sob
controle.
Em um ambiente onde no possvel ter conhecimento de todos os fatos
futuros, o gerenciamento de riscos a melhor forma de mensurar e controlar estas
incertezas. Por isso, ele uma atividade que deve ser realizada durante todo o
andamento do projeto, principalmente por sua relao probabilidade/impacto: Riscos
identificados e prevenidos, transferidos ou mitigados no incio do projeto tendem a
ter um impacto pequeno no projeto. Entretanto, quanto mais tarde os riscos so
identificados, maior o impacto que ele causar nos fatores de sucesso do projeto.
Porm, de nada adianta identificar os riscos no incio do projeto e no tomar as
medidas necessrias para monitorar ou controlar sua ocorrncia e impacto.
Por sua vez, o PMI atravs de seu Guia do Conjunto de Conhecimentos
em Gerenciamento de Projetos - PMBoK, tem desempenhado um papel importante
na formao de gerentes de projetos, e contribudo para que boas prticas se
disseminem pelas mais diversas reas da sociedade. Isto se deve ao fato de o
PMBoK ser um guia genrico, o que facilita a sua adoo em praticamente todas as
reas que envolvem planejamento e execuo de projetos. Entretanto, o PMBoK
demonstra ser um guia voltado a grandes projetos, onde uma grande quantidade de
pessoas esto envolvidas. Porm, mesmo para gerentes de projetos menores h
boas prticas e orientaes importantes, que certamente auxiliaro na execuo de
um gerenciamento de projetos mais consciente, e por conseqncia em um produto
ou servio final de maior qualidade.
56
-
Composta basicamente por uma tabela e ndices de classificao, o
FMEA mostrou-se uma tcnica simples, porm baseada em conceitos importantes e
com um grande xito ao que se prope. Como uma tcnica utilizada na engenharia,
em grande escala na indstria, requerida por algumas certificaes e que envolve
at causas legais e jurdicas, pode-se consider-la uma tcnica com um alto grau de
maturidade. O FMEA tem a vantagem de tambm ter sido criada com um enfoque
genrico, a fim de cobrir as mais diversas reas e situaes. Entretanto, sua
maleabilidade associada a seus slidos conceitos e bases facilitam sua
compreenso e implantao.
importante lembrar que cada projeto possui suas particularidades, e por
conseqncia, a necessidade e a utilidade de cada ferramenta pode variar. Apesar
de a proposta apresentada neste trabalho ser genrica o suficiente para ser utilizada
em qualquer tipo de projeto, o FMEA no deve ser adotado como nica tcnica para
gerenciamento de riscos em grandes projetos. Nestes casos, sempre deve-se utilizar
outras tcnicas em conjunto com o proposto, como simulao de Monte Carlo ou
Tcnica Delphi.
Espera-se que este trabalho seja til principalmente para gerentes de
pequenos e mdios projetos, onde a gerncia de riscos uma atividade cara muitas
vezes, mas que pode salvar o projeto e a empresa de uma grande perda.
57
-
7.1TRABALHOS FUTUROS
Recomenda-se, como trabalho futuro, a anlise ou desenvolvimento de
uma tcnica que busque identificar, planejar e monitorar os riscos positivos de um
projeto.
Outro trabalho possvel, que serviria como complemento deste, seriam
ndices de impacto, freqncia e capacidade de deteco que sirvam de referncia
para cada rea de conhecimento do PMBoK.
58
-
8 REFERNCIAS
ALENCAR, Antnio; SCHMITZ, Eber. Analise de Risco em Gerencia de Projetos. Rio
de Janeiro: Brasport, 2005. 172p.
BARALDI, Paulo. Gerenciamento de Riscos Empresariais. Rio de Janeiro: Elsevier,
2005. 268p.
HELDMAN, Kim. Project Manager's Spootlight on Risk Management. Alameda:
Harbor Light Press, 2005. 224p.
VESELY, W.; GOLDBERG, F. Fault Tree Handbook. Washington: U.S. Nuclear
Regulatory Commission, 1981. 216p.
WESNER, Seibert. Estudo de Caso sobre Gerncia de Projetos com Foco em
Gerncia de Riscos. Canoas: ULBRA, 2004. 85p.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conjunto de Conhecimentos
em Gerenciamento de Projetos. 3 edio. Newtown Square: PMI,
2004. 405p.
GREENFIELD, Michael. Risk Management Tools. Langley Research Center: NASA,
2000. 27p. Obtido em http://www.hq.nasa.gov/office/codeq/risk/
rmt.pdf
RAMOS, Eliani F. A gesto de Riscos usando FMEA. Revista Mundo PM nmero 10,
2006. Pginas 71 a 74.
HOUAISS, Antnio; VILLAR, Mauro S. Dicionrio Houaiss da Lngua Portuguesa.
Rio de Janeiro: Objetiva, 2001, 2922p.
FERREIRA, Aurlio B. H. Miniaurlio Sculo XXI: O minidicionrio da lngua
portuguesa. 4 edio. Rio de Janeiro: Nova Fronteira, 2000, 790p.
KASSE, Tim. Pratical Insight into CMMI. Boston Londres: Artech House, 2004,
323p.
CALSAVARA, Alcides; MACHADO, Cristina A. F.; REINEHR, Sheila S.; BURNETT,
Robert C. Aderncia do RUP norma NBR ISO/IEC 12207. Paran:
2000. Disponvel em http://www.pr.gov.br/batebyte/edicoes/2000/
bb104/software.htm . Acessado em 1/10/2007.
59
-
STAMATIS, D. H. Failure Mode and Effect Analysis: FMEA from Theory to Execution.
ASQ Quality Press, 2003, 445p.
EUROPEAN COOPERATION FOR SPACE STANDARDIZATION. Space Product
Assurance: Failure Modes, Effects, and Criticality Analysis (FMECA).
Noordwijk, 2001.
SOFTWARE ENGINEERING INSTITUTE (SEI). CMMI for Development, Version 1.2.
Pittsburgh: Carnegie Mellon University, 2006. 573p.
SALLES JR., C. A. C; SOLER, A. M; VALLOE, J. A. S; RABECHINI JR. , R.
Gerenciamento de Riscos em Projetos. Rio de Janeiro: Editora FGV,
2006. 160p.
GIDO, J.; CLEMENTS, J. P. Gesto de Projetos: Traduo da 3a edio norte-
americana. So Paulo: Thomson Learning, 2007. 451p.
DAILEY, K. W. The FMEA Pocket Handbook. DW Publishing Co.: 2004. 40p.
STANDISH GROUP: Chaos Report 2007: The 10 Laws os Chaos. Estados Unidos:
2007. 12p.
60