Gestao Riscos

8/2/2019 Gestao Riscos

1/85

FACULDADE LOURENO FILHO

CINCIA DA COMPUTAO

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOSUTILIZANDO O PMBOK

FORTALEZA, 2010


2/85

ii

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOSUTILIZANDO O PMBOK

Monografia apresentada ao Curso de Cincia daComputao da Faculdade Loureno Filho, como requisitoparcial para obteno do grau de Bacharel em Cincia da

Computao.

Orientador: Prof. MSc.Emanuel Ferreira Coutinho

Fortaleza, 2010


3/85

iii

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOS UTILIZANDO O PMBOK

Monografia apresentada ao curso de Bacharel em Cincia da Computao, da FaculdadeLoureno Filho, como parte dos requisitos para a obteno do grau de Bacharel em Cincia daComputao.

Aprovada em: ____/_____2010

Conceito obtido: ______________

Composio da Banca Examinadora:

_______________________________________

Prof. MSc. Emanuel Ferreira Coutinho (Orientador)

_______________________________________

Prof. MSc. Andr Barros Pereira

_______________________________________

Profa. MSc. Joo Frederico Roldan Viana

_______________________________________

Prof. MSc. Carlos MansoCoordenador do Curso


4/85

iv

A Helena Lutescia Luna Coelho


5/85

v

AGRADECIMENTOS

Inicialmente, agradeo a minha esposa, Adrienne, pelo incentivo, para que eu mededicasse ao estudo e por seu auxlio no caminho desta empreitada.

Agradeo a minha me, Helena, no s pelo apoio neste trabalho, mas ao longo de

toda a minha vida.

Sou grato principalmente a Deus, por ter me dado a oportunidade, capacitao e portas

abertas para desenvolver este trabalho.


6/85

vi

"Sem o domnio da teoria das probabilidades e

de outros instrumentos de administrao de risco,

os engenheiros jamais teriam projetado as

grandes pontes, os lares ainda seriam aquecidos

por lareiras e as viagens espaciais ainda seriam

um sonho. (...) A capacidade de administrar o

risco e a vontade de correr riscos e de fazer

opes ousadas so elementos-chave da energia

que impulsiona o sistema econmico.

(BERNSTEIN 1997, p. 99)


7/85

vii

RESUMO

Este estudo busca apresentar o funcionamento e a importncia da gerncia de riscos nodesenvolvimento de software com base no PMBOK. A pesquisa aborda sobre o risco, suadefinio, como identific-lo, classific-lo e trat-lo no desenvolvimento de software. No quediz respeito Engenharia de Software foram descritos os modelos de ciclo de vida dosprocessos de desenvolvimento de software, com o objetivo de agregar a idia da gesto deriscos ao ciclo de vida dos projetos. So apresentados tambm, alguns modelos dedesenvolvimento de software como o RUP e o MSF que tambm tratam da gerencia de riscos.A pesquisa tem como foco principal o tratamento de risco no PMBOK, descrevendo emdetalhes a disciplina de gerncia de riscos, bem como as tcnicas utilizadas, constatando queas prticas de gesto de riscos que so utilizadas no PMBOK tambm podem ser agregadas aqualquer metodologia utilizada no desenvolvimento de software. E por fim, comenta-se como

seria importante agregar estas prticas Engenharia de Software.

Palavras-chave: Gerncia de Riscos, MSF, RUP e PMBOK.


8/85

viii

ABSTRACT

This study is in pursuit of a presentation, practicability and importance of risks managementon a software development based on the PMBOK. This research approaches its risk, itsdefinition, as well as its identification, classification that deals with the software development,As per as the software engineering, it was described the models of the software developmentlife cycle processes, in the direction of adding the idea of the risk management to the projectlife cycles. It is presented as well some software development such as: RUP, MSP and thePMBOK. The research keeps its main focus on the PMBOK test achievement, describing indetails the risk management as well as its used techniques, indicating that the riskmanagement practicable means that are used in the PMBOK, can be added to any usedsoftware development methodology. Finally, its a common thought to say how important itwould be to add these procedures to the engineering software that rarely deals with such a

subject.

Key words: Risk Management, MSF, RUP and PMBOK.


9/85

ix

Sumrio

Lista de Figuras.............................................................................................................xiiLista de Quadros..........................................................................................................xiii

1. INTRODUO..........................................................................................................1

1.1 Motivao.............................................................................................................1

1.2 Objetivos...............................................................................................................1

2. RISCO.........................................................................................................................2

2.1 Riscos em desenvolvimento de software..............................................................2

2.2 Categoria de Riscos..............................................................................................22.2.1 Riscos Organizacionais..............................................................................3

2.2.2 Riscos de Gerncia do projeto....................................................................3

2.2.3 Riscos Tcnicos, de Qualidade ou de Desempenho...................................3

2.2.4 Riscos Externos..........................................................................................3

3. GERENCIAMENTO DE RISCOS EM DESENVOLVIMENTO DE SOFTWARE.4

3.1 O Processo de Desenvolvimento de Software......................................................4

3.2 Modelos de Processos de Software......................................................................5

3.3 Gerncia de Riscos no RUP.................................................................................7

3.4 Gerncia de Riscos no CMMI............................................................................10

3.5 Gerncia de Riscos no MSF...............................................................................14

4. PMBOK.....................................................................................................................16

4.1 PMI.....................................................................................................................16

4.2 Gerncia de Projetos com PMBOK....................................................................17

4.3 Gerenciamento de Integrao.............................................................................18

4.4 Gerenciamento de Escopo..................................................................................18

4.5 Gerenciamento de Tempo...................................................................................19

4.6 Gerenciamento do Custo....................................................................................19

4.7 Gerenciamento da Qualidade..............................................................................19

4.8 Gerenciamento de Recursos Humanos...............................................................19

4.9 Gerenciamento da Comunicao........................................................................19

4.10 Gerncia de Aquisies....................................................................................20

4.11 Gerncia de Risco.............................................................................................20

5. Gerenciamento de Riscos no PMBOK......................................................................22


10/85

x

5.1 Processos de gerenciamento de risco..................................................................25

5.1.1 Plano de Gerenciamento do Risco............................................................26

5.1.1.1 Principais Entradas do Plano de gerenciamento de riscos.....................26

5.1.1.2 Tcnicas e Ferramentas.........................................................................30

5.1.1.3 Sadas do Plano de Gerenciamento de Riscos.......................................31

5.1.2 Identificao de Riscos.............................................................................32

5.1.2.1 Principais Entradas de Identificao de Riscos.....................................32

5.1.2.2 Tcnicas e Ferramentas.........................................................................32

5.1.2.3 Sadas da Identificao dos Riscos........................................................41

5.1.3 Anlise Qualitativa de Riscos...................................................................41

5.1.3.1 Principais Entradas da Anlise Qualitativa dos Riscos.........................425.1.3.2 Tcnicas e Ferramentas..........................................................................42

5.1.3.3 Sadas da Anlise Qualitativa de Riscos...............................................45

5.1.4 Anlise Quantitativa.................................................................................46

5.1.4.1 Principais Entradas da Anlise Quantitativa dos Riscos.......................47

5.1.4.2 Ferramentas e Tcnicas.........................................................................48

5.1.4.3 Sadas Anlise Qualitativa de Riscos....................................................48

5.1.5 Planejamento de Respostas a Riscos........................................................495.1.5.1 Entradas do Planejamento de Respostas a Riscos.................................49

5.1.5.2 Tcnicas e Ferramentas para o Planejamento de Resposta ao

Risco..........................................................................................................................................49

5.1.5.3 Sadas para o Planejamento de Resposta ao Risco................................51

5.1.6 Monitoramento e Controle dos Fatores de Risco.....................................52

5.1.6.1 Entradas para o Monitoramento e Controle do Risco............................53

5.1.6.2 Tcnicas e Ferramentas para o Monitoramento e Controle doRisco..........................................................................................................................................54

5.1.6.3 Sadas do Monitoramento e Controle do Risco.....................................55

6. Gerncia de Riscos no PMBOK x Gerncia de Riscos no Desenvolvimento de

Software....................................................................................................................................57

6.1 Planejamento da Gerncia de Riscos......................................................................60

6.2 Identificao dos Riscos..........................................................................................61

6.3 Anlise Qualitativa dos Riscos................................................................................62

6.4 Anlise Quantitativa dos Riscos..............................................................................64


11/85

xi

6.5 Planejamento das Respostas aos Riscos..................................................................67

6.6 Monitorao e Controle dos Riscos........................................................................69

7. Concluso..................................................................................................................71

8. Referncias Bibliogrficas........................................................................................73


12/85

xii

Lista de Figuras

Figura 1: Arquitetura geral do RUP..........................................................................................22Figura 2: Processos da gerncia de risco no modelo MSF.......................................................29

Figura 3: A performance dos projetos que utilizam totalmente, moderadamente,

pouco ou no utilizam o PMBOK.............................................................................................31

Figura 4: Viso geral das reas de conhecimento em gerenciamento de projetos e os

processos de gerenciamento de projetos...................................................................................35

Figura 5: FluxogramadeProcessosde Gerenciamento de riscos do Projeto............................37

Figura 6:Fluxograma dopainelDelphi....................................................................................49Figura 7: Modelo de analise de riscos SWOTMapas Mentais..............................................52

Figura 8:Diagrama deIchikawa ouFishbone..........................................................................54

Figura 9:Diagrama de Influncia.............................................................................................54

Figura 10: Matriz de probabilidade e impacto em cores vermelho, amarelo e verde...............57

Figura 11: Matriz de probabilidade e impacto em tons de branco e preto................................57

Figura 12:ProcessoCclico de Gerncia de Risco...................................................................66

Figura 13: Associao de probabilidades a ndices..................................................................78

Figura 14: Exemplo de prioridade utilizando ndices relacionados a probabilidades

de risco.....................................................................................................................................79


13/85

xiii

Lista de Quadros

Quadro 1: Sntese das disciplinas do RUP................................................................................23

Quadro 2: Objetivos especficos e prticas no CMMI..............................................................27

Quadro3:Processos do gerenciamento de riscos.....................................................................39

Quadro 4: Analise Swot, pontosfortes vrspontosfracos.........................................................50

Quadro 5: Analise Swot, uso do PMBOOK em novos projetos................................................51

Quadro 6: Risco em PMBOK, CMMI-SW, RUP e MSF.........................................................72


14/85

1. INTRODUO

1.1 Motivao

Na vida cotidiana sempre convivemos com riscos. Podemos por exemplo: ser

assaltados, contrair doenas ou sofrer um acidente de carro. Para esses casos h

solues simples como: ter o veculo segurado, vacinar-se ou andar com cinto de

segurana. Dentro de um projeto de desenvolvimento de um sistema no diferente.

Corre-se o risco de indesejveis surpresas. H situaes em que poder incidir um risco

grave e que poder significar o fracasso do prprio projeto.

A Gerncia de Riscos est presente em vrias metodologias de Gesto deProjetos. Neste trabalho ser escolhido como base o modelo de Gerenciamento de

Riscos do PMBOK (Project Management Body of Knowledge) desenvolvido pelo PMI

(Project Managemanent Institute).

O fator de maior peso na escolha do PMBOK como o modelo a ser detalhado o

fato de existir uma disciplina ou grupo de processos que se dedica ao estudo do risco.

1.2 Objetivos

O gerenciamento de riscos parte fundamental da gesto de projetos, porque

aumenta consideravelmente a chance de um projeto ser concludo com sucesso.

O presente trabalho tem como objetivo principal descrever o gerenciamento de

riscos do PMBOK.

Como objetivos especficos, o trabalho mostrar como o risco tratado em

algumas metodologias de gesto de software, far uma comparao e demonstrar a

importncia do gerenciamento de risco dentro da gesto de desenvolvimento desoftware.


15/85

16

2. RISCO

Risco a probabilidade de que um fator de risco venha a assumir um valor que

passa a prejudicar, total ou parcialmente as chances de sucesso de um projeto. Um fator

de risco qualquer evento que possa prejudicar total ou parcialmente, as chances de

sucesso do projeto, isto , as chances do projeto realizar o que foi proposto dentro do

prazo e fluxo de caixa que foram estabelecidos. (ALENCAR E SCHMITZ, 2006)

visto que em gerncia de projetos, o risco est ligado a estas duas palavras:

possibilidade e perigo. No entanto, a viso que temos em gerncia de projetos que

risco qualquer evento potencial que, se concretizado, pode afetar negativamente ou

positivamente o objetivo do projeto.

2.1 Riscos em desenvolvimento desoftware

O desenvolvimento de software uma atividade complexa envolvendo inmeros

fatores que so imprevisveis e de difcil controle, como inovaes tecnolgicas e

mudanas constantes nos requisitos do cliente, dentre muitos outros. Esta complexidadefaz com que grande parte dos projetos de desenvolvimento de software exceda o prazo e

o oramento previstos, alm de no atender s expectativas do cliente em termos de

funcionalidades e qualidade. Diante deste cenrio, um gerenciamento eficaz tem-se

evidenciado como de fundamental importncia para o sucesso de projetos de software.

Uma vez que a incerteza inerente a este tipo de projeto, o gerenciamento de riscos

vem se tornando cada vez mais relevante neste contexto.

2.2 Categoria de Riscos

Os riscos podem ser identificados e organizados dentro das categorias de riscos,

podendo afetar o projeto positivamente ou negativamente. Se bem definidos, devem

refletir os princpios comuns do risco para determinada rea de aplicao.

As categorias de riscos, conforme Project Management Institute (2004), so as

seguintes: Riscos Organizacionais, Riscos de Gerncia do Projeto, Riscos Tcnicos, de

Qualidade ou de Desempenho, e Riscos Externos.


16/85

17

2.2.1Riscos Organizacionais

So riscos Organizacionais aqueles que so ligados poltica e gesto da

empresa como, por exemplo: Tempo e escopo internamente inconsistentes, falta deverba ou verba aplicada inadequadamente, competio de projetos gerando conflito de

recursos e a falta de priorizao dos projetos.

2.2.2Riscos de Gerncia do projeto

Existem vrios motivos que podem fazer com que um bom gestor de projetos

venha a falhar. Como por exemplo: presso de chefias para comear a desenvolver o

projeto, no respeitando o tempo estipulado nem as fases do projeto (diminuto tempo deplanejamento), qualidade inadequada do planejamento, com falhas na programao das

atividades, m distribuio de tempo e de recursos.

2.2.3Riscos Tcnicos, de Qualidade ou de Desempenho

A cada dia surgem novas tecnologias substituindo ou melhorando e extinguindo

outras. Corre-se o risco de confiar em novas tecnologias ainda no comprovadas ou de

baixa qualidade, o que poder acarretar falta de apoio ou de informao no uso daquela

ferramenta. O uso de metas e performances irrealistas ou muito complexas pode afetar o

desenvolvimento do projeto e a qualidade do produto ou servio final.

2.2.4Riscos ExternosQualquer desvio do ambiente ideal para o desenvolvimento do projeto, tais

como: pedidos de demisso, questes trabalhistas, mudana nas prioridades dos scios.Riscos de fora maior tal como mudanas climticas, terremotos, enchentes, guerras

civis. O gerenciamento de risco posto de lado para que as aes de recuperao entrem

em campo.


17/85

18

3. GERENCIAMENTO DE RISCOS EM DESENVOLVIMENTODE SOFTWARE

O gerenciamento de riscos trabalha justamente com a incerteza, visando identificao de problemas potenciais e de oportunidades antes que eles ocorram, com o

objetivo de eliminar ou reduzir a probabilidade de ocorrncia e o impacto de eventos

negativos para os objetivos do projeto, alm de potencializar os efeitos da ocorrncia de

eventos positivos.

O gerenciamento de riscos abordado por vrios modelos que controlam a

qualidade do processo de desenvolvimento de software dentre os quais o PMBOK, o

CMMI, o RUP e o MSF. O CMMI (Capability Maturity Model Integration forSoftware) prov umframeworkpara a implantao e melhoria do processo de software

das organizaes. O RUP (Rational Unified Process) um processo baseado em

melhores prticas de Engenharia de Software. O MSF (Microsoft Solutions Framework)

tem sido usado pela Microsoft como o seu mtodo para desenvolvimento de solues

de software dentro da Microsoft e tambm para os milhares de clientes e parceiros da

Microsoft em todo o mundo. O PMBOK (Project Management Body of

Knowledgement) trata do gerenciamento de projetos de uma forma ampla, no sendoespecfico para software.

Este captulo apresenta um estudo do gerenciamento de riscos no RUP, no

CMMI e no MSF, modelos voltados para o desenvolvimento de software semelhana

do que foi feito em Rocha e Belchior (2004).

3.1 O Processo de Desenvolvimento de Software

Um processo de desenvolvimento de software um conjunto de atividades e

resultados associados que produz um produto de software. (SOMMERVILLE, 2003)

Segundo Sommerville, existem quatro atividades fundamentais de processo, que

so comuns a todos os processos de software:

a. Especificao desoftware: clientes e engenheiros definem o software a serproduzido e as restries para a sua operao;

b. Desenvolvimento desoftware: o software projetado e programado;


18/85

19

c. Validao desoftware: na qual o software verificado para garantir que oque o cliente deseja;

d. Evoluo desoftware: o software modificado para se adaptar s mudanasdos requisitos do cliente e do mercado.

Cada atividade pode ser composta de outras atividades as quais so realizadas

por pessoas que possuem um determinado papel no processo como: programador,

gerente, cliente e outros. Tais pessoas podem utilizar ferramentas e modelos que

automatizem e facilitem os seus trabalhos, e medida que o processo flui, artefatos

(cdigo, documentos, modelos, diagramas, etc...) so produzidos, atualizados e

consumidos nas atividades realizadas.

Sommerville diz ainda que, diferentes tipos de sistemas necessitam de diferentes

processos de desenvolvimento, como exemplo: um software de tempo real de uma

aeronave deve ser completamente especificado antes do incio do desenvolvimento,

enquanto nos sistemas de comrcio eletrnico a especificao e o programa so,

geralmente, desenvolvidos em conjunto. Consequentemente, essas atividades genricas

podem ser organizadas de diferentes maneiras e descritas em nveis diferentes de

detalhes, para diferentes tipos de software. Porm, o uso de um processo de software

inadequado pode reduzir a qualidade ou a utilidade do produto de software a ser

desenvolvido e/ou aumentar os custos de desenvolvimento. (SOMMERVILLE, 2003)

3.2 Modelos de Processos de Software

A importncia da aplicao de metodologias para o desenvolvimento de

software foi crescendo gradualmente, medida que a complexidade das aplicaes

crescia. Atrasos e problemas com o oramento eram problemas comuns maioria dos

projetos, devido falta de uma abordagem especial ao software. Assim, houve anecessidade de se repensar em como de fato desenvolver um software.

Vrios modelos de desenvolvimento foram criados desde ento. Um modelo de

processo de software uma representao abstrata de um processo de software.

(SOMMERVILLE, 2003)

Segundo Sommerville (2003), a maioria dos modelos de processo de software

baseada em um dos trs modelos gerais ou paradigmas de desenvolvimento de software:


19/85

20

a. O modelo em cascata: considera as atividades apresentadas anteriormente eas representa como fases separadas de processo, como especificao de

requisitos, projeto de software, implementao, teste e assim por diante.Depois que cada estgio concludo, ele aprovado e o desenvolvimento

prossegue para o estgio seguinte.

b. Desenvolvimento evolucionrio: esta abordagem intercala as atividades deespecificao, desenvolvimento e validao. Um sistema inicial

desenvolvido rapidamente com base em especificaes muito abstratas.

ento refinado com as informaes do cliente, para produzir um sistema que

satisfaa as necessidades deste. O sistema pode, ento, ser entregue. Como

alternativa, ele pode ser reimplementado, utilizando uma abordagem mais

estruturada, para produzir um sistema mais robusto e mais fcil de ser

mantido.

c. Engenharia de software baseada em componentes (CBSR ComponentBased Software Engineering): esta tcnica supe que partes do sistema j

existam. O processo de desenvolvimento concentra-se mais na integrao

dessas partes que no seu desenvolvimento a partir do incio.

Esses trs modelos genricos de processo so amplamente usados na prtica

atual de Engenharia de Software. Eles no so mutuamente exclusivos e freqentemente

so usados em conjunto, especialmente para desenvolvimento de sistemas de grande

porte. Os subsistemas contidos em um sistema maior podem ser desenvolvidos usando

diferentes abordagens.

A primeira proposta para incluir a gerncia de riscos em modelos de

desenvolvimento de software foi feita no final dos anos 80, quando Barry Boehm

props o modelo de desenvolvimento em espiral. (MACHADO, 2002)

Mais tarde, em 1991, o mesmo Barry Boehm publicou um artigo especfico

sobre gerncia de riscos em projetos de desenvolvimento de software.

Ao longo de sua carreira, Boehm teve a chance de observar diversos gerentes de

projetos em ao e com isso pde identificar caractersticas que diferenciam os mais


20/85

21

eficientes dos menos eficientes. Como resultado destas observaes, ele identificou que

uma caracterstica presente em todos os gerentes de projetos eficientes que estes eram

excelentes gerentes de riscos. (BOEHM, 1991)

O artigo publicado por Boehm teve como objetivo tentar definir princpios eprticas baseado nesta caracterstica comum aos gerentes de projetos observados. Desde

ento, a gerncia de riscos em projetos de desenvolvimento de software vem crescendo

em proporo. (MACHADO, 2002)

No incio da dcada de 90, as metodologias de gerncia de projetos costumavam

deixar a gerncia de riscos em segundo plano, normalmente dentro de alguma outra rea

de conhecimento.

Hoje essas mesmas metodologias colocam a gerncia de riscos em posio de

destaque, dedicando captulos exclusivos para essa rea de conhecimento. Foi o caso do

PMBOK, que em 1987 deu maior visibilidade gerncia de riscos dedicando uma rea

de conhecimento especfica para o assunto, e do CMMI, que ao evoluir do SW-CMM

reuniu as prticas referentes gerncia de riscos, at ento inclusas dentro de outras

reas chave de processo, em uma rea de processo tambm especfica para o assunto.

3.3 Gerncia de Riscos no RUP

O Rational Unified Process (RUP) um framework de processo de

desenvolvimento de software definido pela Rational Software Corporation. um

exemplo de modelo de processo de software moderno, inclui as melhores prticas de

Engenharia de Software, utiliza a abordagem iterativa e incremental e tambm traz

elementos de outros modelos genricos de processos.

Foi desenvolvido para ser aplicvel a uma grande classe de projetos distintos epode ser considerado como um framework genrico para processos de desenvolvimento.

Isso significa que ele deve ser adaptado para ser usado eficientemente. A adaptao

pode ser feita para empresas ou mesmo para projetos especficos.

O RUP composto por quatro fases Iniciao, Elaborao, Construo e

Transiocada uma destas com objetivos especficos.

A fase de Iniciao deve estabelecer o escopo e a viabilidade econmica do

projeto. RUP (2003)


21/85

22

O objetivo da fase de Elaborao eliminar os principais riscos e estabelecer

uma arquitetura estvel a partir da qual o sistema poder evoluir.

Na fase de Construo, um produto completo desenvolvido de maneira

iterativa at que esteja pronto para ser passado aos usurios, o que ocorre na fase deTransio, onde uma verso beta do sistema disponibilizada.

Cada fase pode comportar vrias iteraes e cada iterao, por sua vez, est

organizada em disciplinas, que descrevem o que deve ser feito em termos de atividades,

responsveis e artefatos. RUP (2003)

Figura 1Arquitetura Geral do RUP.

Fonte: RUP (2003)

A Figura 1 mostra a arquitetura geral do RUP da seguinte maneira:

O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida

do processo medida que se desenvolve

O eixo vertical representa as disciplinas, que agrupam as atividades de

maneira lgica, por natureza.

Na fase de iniciao o foco principal recai sobre o entendimento dos requisitos e

a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na

fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento

de requisitos e anlise), ainda que algum trabalho de projeto e implementao sejarealizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de


22/85

23

construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e

incrementar o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a

fase de transio concentra-se nos testes, visando garantir que o sistema possui o nvel

adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticasajustadas e elementos esquecidos adicionados.

Quadro 1Sntese das disciplinas do RUP

DISCIPLINAS DO RUP

Modelagem de Negcios

Envolve o entendimento da estrutura e dinmica da organizao cliente,

garantindo que clientes, usurios e desenvolvedores tenham a mesma viso da

organizao para a qual ser feito o desenvolvimento.

Requisitos Envolve a definio dos requisitos do sistema e de como gerenciar escopo emudanas de requisitos.

Anlise e ProjetoEnvolve a traduo dos requisitos numa especificao que descreva como

implementar o sistema. A linguagem UML utilizada para modelar o sistema.

ImplementaoEnvolve o desenvolvimento de cdigo: classes, objetos, etc., testes de unidade

e integrao de subsistemas.

TestesEnvolve a verificao do sistema como um todo, com testes de integrao e

conformidade com os requisitos especificados.

DisponibilizaoEnvolve o empacotamento, distribuio, instalao e treinamento de usurios,

assim como o planejamento e conduo de testes preliminares.

Gerncia de ProjetosEnvolve o gerenciamento de riscos, planejamento e acompanhamento do

rojeto.

Gerncia de Configurao e Mudanas Envolve o gerenciamento dos artefatos gerados durante o desenvolvimento.

AmbienteEnvolve a organizao do ambiente de trabalho para a equipe do projeto e a

configurao do RUP para o projeto.

Fonte: Adaptado pelo autor a partir da RUP (2003)

O gerenciamento de riscos no RUP se prope a balancear objetivosconcorrentes, gerenciar riscos e restries, para que a entrega do produto satisfaa a

seus clientes e usurios.

O gerenciamento de riscos est integrado ao processo de desenvolvimento, onde

as iteraes so planejadas e esto baseadas nos riscos de maior prioridade. Em uma

abordagem iterativa, os riscos so mitigados mais cedo, porque os elementos so

integrados progressivamente.


23/85

24

Uma vez que cada iterao exercita muitos aspectos do projeto, torna-se mais

fcil descobrir at que ponto os riscos percebidos esto se materializando, como

tambm descobrir novos e insuspeitos riscos.

No RUP, a problemtica do risco tratada de uma maneira cooperativa nas

quatro fases da seguinte maneira:

Iniciao: foco no tratamento dos riscos relacionados aos casos de negcio1.

Elaborao: foco principalmente nos riscos tcnicos, examinando-se os riscos

de arquitetura e, se necessrio, revisando-se o escopo do projeto medida que

seus requisitos tornam-se melhor compreendidos.

Construo: foco nos riscos de logstica e na obteno da concluso da maiorparte do trabalho

Transio: foco nos riscos associados com a logstica de entrega do produto seu

usurio.

O papel envolvido com o gerenciamento de riscos no RUP o do gerente do

projeto, que executa as atividades Desenvolver o Plano de Gerenciamento de

Riscos, Identificar e Avaliar Riscos, e Monitorar o Status do Projeto, que tm como

entrada ou sada os artefatos: Viso Geral (documento de requisitos), Planos de

Gerenciamento de Riscos e Lista de Riscos. (PASCALE e BELCHIOR, 2004)

3.4 Gerncia de Riscos no CMMI

O CMMI (Capability Maturity Model Integration) considerado um modelo de

gesto de processos que tem como objetivo prover s empresas, um conjunto de

melhores prticas que possa suportar a melhoria contnua de seu desempenho, bemcomo ser referncia para eventuais comparaes por meio de seus nveis de maturidade

e capacidade.

O CMMI contm prticas (Genricas e Especficas) necessrias maturidade em

disciplinas especficas (Systems Engineering (SE), Software Engineering (SE),

Integrated Product and Process Development(IPPD), Supplier Sourcing (SS)).

1

Caso de Negcio: O caso de negcio (business case) fornece a informao necessria a partir de um ponto de vistade negcio para determinar se o projeto justifica o investimento necessrio para a sua execuo.


24/85

25

Desenvolvido pelo SEI (Software Engineering Institute) daUniversity Carnegie

Mellon, o CMMI uma evoluo do CMM 2 e procura estabelecer um modelo nico

para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

O CMMI-SW contm duas representaes: por estgios, e contnua.A representao por estgios trata do nvel de maturidade da organizao como

um todo, contendo cinco nveis de maturidade: inicial, gerenciado, definido, gerenciado

quantitativamente e em otimizao.

a. A Representao Contnua: Possibilita organizao utilizar a ordem demelhoria que melhor atender os objetivos de negcio da empresa.

caracterizado por Nveis de Capacidade (Capability Levels):

Nvel 0: Incompleto (Ad-hoc)

Nvel 1: Executado (Definido)

Nvel 2: Gerenciado / Gerido

Nvel 3: Definido

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente

Nvel 5: Em otimizao (ou Optimizado)

b. Representao Por Estgios: Disponibiliza uma seqncia pr-determinadapara melhoria baseada em estgios que no deve ser desconsiderada, pois

cada estgio serve de base para o prximo.

caracterizado por Nveis de Maturidade (Maturity Levels):

Nvel 1: Inicial (Ad-hoc)

Nvel 2: Gerenciado / Gerido

Nvel 3: Definido

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente

Nvel 5: Em otimizao

2CMM: O CMM foi desenvolvido pela SEI (Software Engineering Institute) em 1986 com o objetivo demelhorar a desenvolvimento de aplicaes em organizaes que trabalham com tecnologia.
http://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/CMMhttp://pt.wikipedia.org/wiki/CMMhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellonhttp://pt.wikipedia.org/wiki/Universidade_Carnegie_Mellon


25/85

26

Cada nvel constitudo por um conjunto de reas de processos, compostas por

objetivos especficos e objetivos genricos. Cada objetivo especfico pode ser composto

por um conjunto de prticas especficas.

Um objetivo especfico (SG, Specific Practices by Goal) descreve as

caractersticas que devem estar presentes para satisfazer uma rea de processo.

Uma prtica especfica (SP, SpecificPractices) a descrio de uma atividade

que considerada importante para se alcanar o objetivo especfico a ela

associado.

A problemtica do risco abordada nas reas de processo Planejamento do

Projeto, Monitorao e Controle do Projeto, e Gerncia de Risco.

As duas primeiras reas de processo esto no nvel 2 e a ltima est no nvel 3

do CMMI-SW. No Planejamento do Projeto, tem-se o SG Desenvolvimento do Plano

do Projeto com a SP Identificar os Riscos do Projeto, que consiste na identificao e

na anlise dos riscos para se determinar o impacto, a probabilidade de ocorrncia e o

perodo em que podem ocorrer, para que os riscos possam ser priorizados. Na

Monitorao e Controle do Projeto, tem-se o SG Monitorar o Projeto de Acordo com o

Plano, onde est inserido a SP Monitorar os Riscos do Projeto.

A Gerncia de Risco no CMMI tem por finalidade identificar potenciais

problemas antes que ocorram, de forma que as atividades de administrao desses riscos

possam ser planejadas e realizadas, de acordo com suas necessidades, ao longo do ciclo

de vida do produto ou projeto, para mitigar possveis impactos adversos. (ROCHA e

BELCHIOR, 2004)

O quadro 2 mostra os objetivos especficos e o resumo de suas prticas.


26/85

27

Quadro 2Objetivos especficos e prticas no CMMI.

Objetivos especficos Prticas

SG 1: Preparar-se para a gerncia de riscos

SP 1.1: Determinar as origens e categorias dos riscos

SP 1.2: Definir os parmetros dos riscos

SP 1.3: Estabelecer uma estratgia de gerncia de riscos

SG 2: Identificar e analisar os riscos

SP 2.1: Identificar os riscos

SP 2.2: Avaliar, categorizar e priorizar os riscos

SG 3: Mitigar os Riscos

SP 3.1: Desenvolver planos de mitigao de riscos

SP 3.2: Implementar os planos de mitigao dos riscos

GG 3: Institucionalizar um processo definido

GP 2.1: Estabelecer uma poltica organizacional

GP 3.1: Estabelecer um processo definido

GP 2.2: Planejar o processo

GP 2.3: Prover recursos

GP 2.4: Atribuir responsabilidades

GP 2.5: Treinar o pessoal

GP 2.6: Gerenciar configuraes

GP 2.7: Identificar e envolver os interessados relevantes

GP 2.8: Monitorar e controlar o processo

GP 3.2: Coletar informaes de melhoria

GP 2.9: Avaliar objetivamente a aderncia

GP 2.10: Revisar a situao com a gerncia de alto nvel

Fonte: ROCHA e BELCHIOR(2004)


27/85

28

3.5 Gerncia de Riscos no MSF

O MSF (Microsoft Solutions Framework) uma srie flexvel e inter-

relacionada de conceitos, modelos e prticas recomendadas que serve como uma basepara planejamento e criao de projetos tecnolgicos. Os princpios e as prticas do

MSF ajudam as organizaes a prever, planejar e implementar solues tecnolgicas

que atendam aos objetivos dos negcios.

A Microsoft criou o MSF em 1994, baseando-se nas prticas recomendadas de

desenvolvimento de produto da Microsoft e das organizaes de TI.

O MSF aborda a gerncia de riscos como uma importante atividade para o

sucesso do projeto, pois tomadas de deciso baseadas em riscos so fundamentais para

esta metodologia.

A gerncia de riscos uma das disciplinas do MSF que precisa ser integrada ao

ciclo de vida do projeto. (MICROSOFT, 2002)

O MSF divide a gerncia de riscos em seis processos:

Identificar: identificar os riscos do projeto e apresent-los equipe do projeto.

Analisar e priorizar: estudar e ordenar os riscos.

Planejar: construir um plano de aes.

Monitorar: acompanhar a situao dos riscos e das aes.

Controlar: integrar a gerncia de riscos s atividades cotidianas do projeto.

Aprender: finalizar o processo registrando numa base de conhecimentos, os

riscos, os planos de ao e contingncia e a aes adotadas para que possam ser

futuramente revistas e analisadas.


28/85

29

Figura 2Processos da gerncia de risco no Modelo MSF.

Fonte: Microsoft (2002)

A Figura 2 apresenta como os seis processos que compem a gerncia de riscosno MSF interagem entre si. A disciplina considera como boas prticas a gerncia pr-

ativa de riscos, a avaliao contnua de riscos e a integrao da disciplina com as

tomadas de decises ao longo do ciclo de vida do projeto. Riscos devem ser

continuamente gerenciados at que sejam mitigados ou at que se tornem um problema

real a ser controlado. (MICROSOFT, 2002)


29/85

30

4. PMBOK

4.1 PMI

O PMI (Project Management Institute) uma organizao internacional sem fins

lucrativos, fundada em 1969 por um grupo de cinco voluntrios, na Filadlfia -

Pensilvnia - EUA. O principal objetivo do PMI tem sido a definio e divulgao das

melhores prticas em gesto de projetos. Alm de desenvolver normas, seminrios,

programas educacionais e certificao profissional. Possui mais de 100.000 (cem mil)

membros em todo o mundo e j certificou mais de 50.000 (cinqenta mil) PMP (Project

Management Professional).

O PMI estima que 10 trilhes de dlares sejam gastos anualmente no mundo emprojetos, o que equivale a aproximadamente 25% do PIB mundial, e que cerca de 16,5

milhes de profissionais esto envolvidos diretamente com a Gerncia de Projetos no

mundo. Este volume de projetos e mudanas constantes no cenrio competitivo mundial

gera a crescente necessidade de resultados mais rpidos, com qualidade e a um custo

competitivo.

Fatores como a globalizao do mercado e aquisies de novas tecnologias

emergentes, tornam cada vez maior a Gerncia de Projetos um assunto da mais altaimportncia para as organizaes e para sua capacidade de sobrevivncia.

Pesquisas realizadas pelo PMI mostram que 75% dos seus membros indicaram

que, nos prximos anos, suas empresas estaro dando maior importncia para a gerncia

de projetos. (PMI-SP, 2009)


30/85

31

Figura 3A performance dos projetos que utilizam totalmente, moderadamente,

pouco ou no utilizam o PMBOK.

Fonte: PMI-SP (2009)

A figura 3 apresenta uma estatstica dos projetos que utilizam o PMBOK. Os

dados afirmam claramente que com a utilizao do PMBOK os projetos tiveram um

desempenho muito melhor quanto s entregas dos prazos e ao oramento. (PMI-SP,

2009)

4.2 Gerncia de Projetos com PMBOK

O desenvolvimento de software tem avanado tecnologicamente em rpidas

propores, mas existem fatores que ocorrem desde o comeo desse avano, so eles: oserros de gesto e a falta de sucesso do software desenvolvido, muitas vezes no

atendendo o que cliente desejava. Para o sucesso ser completo, o produto final deve ser

entregue dentro do prazo, com o custo especificado, e ser realmente aquilo que o cliente

necessitava.

A Gerncia de Projetos uma soluo para os problemas que as equipes de

desenvolvimento de Software vm enfrentando, porque distribuda em reas de

conhecimento, onde cada uma delas descreve seus respectivos processos a fim degarantir que os objetivos planejados sejam atingidos. As tcnicas de gerenciamento de


31/85

32

projetos esto sendo aprimoradas constantemente, buscando sempre garantir o sucesso

dos processos.

O Project Management Body of Knowledge, tambm conhecido como PMBOK

um conjunto de prticas em gerncia de projetos levantado pelo Project ManagementInstitute (PMI) e constituem a base da metodologia de gerncia de projetos do PMI.

Estas prticas so compiladas na forma de um guia, chamado de Guia do Conjunto de

Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006)

O Gerente de projetos a pessoa responsvel pela realizao dos objetivos do

projeto, identificando s necessidades, estabelecendo objetivos claros e possveis de ser

alcanados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender s

expectativas das partes interessadas no projeto. Ele e sua equipe devero seguir um

cdigo de tica e conduta profissional para aqueles que possuem a certificao PMP.

No gerenciamento de projetos so aplicados os conhecimentos, habilidades,

ferramentas e tcnicas s atividades do projeto e realizado atravs da aplicao e da

integrao das seguintes reas de competncias gerncias, so elas: Gerenciamento de

Integrao, Gerenciamento de Escopo, Gerenciamento de Tempo, Gerenciamento do

Custo, Gerenciamento da Qualidade, Gerenciamento dos Recursos Humanos,

Gerenciamento da Comunicao, Gerncia de Aquisies e Gerncia de Riscos. (PMI,

2004; DINSMORE, 2005; GURGEL, 2007)

4.3 Gerenciamento de Integrao

A Gerncia de Integrao tem como objetivo fazer o controle geral das

mudanas e monitorar a execuo do plano do projeto, desde seu inicio com o termo de

abertura do projeto at seu final com o encerramento do projeto, realizando negociaes

dos objetivos conflitantes, dando alternativas ao projeto com a finalidade de atender asnecessidades e expectativas de todas as partes interessadas.

4.4 Gerenciamento de Escopo

O objetivo principal dessa gerncia definir e manter o desenvolvimento do

projeto dentro do escopo desenhado, controlando o que deve e o que no deve estar

includo no projeto, tendo a segurana, que realmente a necessidade do cliente, e


32/85

33

qualquer mudana que venha a se realizar no escopo dever ter o consentimento do

cliente.

4.5 Gerenciamento de Tempo

Tem como objetivo principal controlar o tempo das atividades garantindo que o

projeto cumpra seu prazo contratual.

4.6 Gerenciamento do Custo

A responsabilidade da Gerncia de Custo gerenciar o caixa do projeto, desde a

estimativa de custo total do projeto, bem como o controle das despesas para cada

atividade dentro do projeto, garantido que o mesmo seja realizado dentro do oramento

estipulado.

4.7 Gerenciamento da Qualidade

O gerenciamento da qualidade responsvel por garantir a aceitao do softwareao cliente, ou seja, o controle de qualidade do projeto, verificando se ele satisfaz as

exigncias para o que foi desenvolvido, e se cumpre as expectativas e as necessidades

do cliente.

4.8 Gerenciamento de Recursos Humanos

O Gerenciamento de Recursos Humanos tem como objetivo administrar a mo

de obra humana, atribuir funes e responsabilidades, relaes interpessoais e de

equipe, buscando sempre o melhor aproveitamento das pessoas envolvidas no projeto.

4.9 Gerenciamento da Comunicao

O Gerenciamento de Comunicaes responsvel pela conectividade de

informaes do projeto a todos os stakeholders e outras gerncias. Todas as gernciasdo projeto interagem entre si e com as demais reas de conhecimento. A Gerncia de


33/85

34

Comunicaes do Projeto inclui os processos que garantem a coleta, a distribuio, o

armazenamento e o controle bsico das informaes do projeto, fornecendo a ligao

entre pessoas, idias e informaes. Todos os envolvidos no projeto devem estar

preparados para enviar e receber as informaes e os processos que envolvem essagerncia que consiste em: planejar da forma mais conveniente a disponibilizar as

informaes e comunicaes necessrias para os evolvidos no projeto, relatando as

informaes de desempenho at o encerramento das fases do projeto.

4.10 Gerncia de Aquisies

A Gerncia de Aquisies responsvel pela administrao de compras econtrataes de servios para o projeto.

4.11 Gerncia de Risco

Gerncia de Risco o objeto de estudo da monografia e ser detalhado no

prximo captulo. O objetivo principal dessa gerncia maximizar os resultados de

ocorrncias positivas e minimizar as consequncias negativas ou at mesmo eliminar

eventos adversos, tratando e controlando os riscos.

A figura 4 apresenta as reas de conhecimento e os processos pelos quais so

responsveis.


34/85

35

Figura 4Viso Geral das reas de conhecimento em gerenciamento de projetos e osprocessos de gerenciamento de projetos.

Fonte: PMI (2004)


35/85

36

5. GERENCIAMENTO DE RISCOS NO PMBOK

O gerenciamento de Riscos um processo sistemtico usado para identificar,

analisar e responder aos riscos do projeto cujo objetivo maximizar a probabilidade dos

eventos positivos e se possvel neutralizar os eventos negativos ou minimizar suas

consequncias para o objetivo do projeto.

O risco dentro de um projeto uma condio incerta de ocorrer, e se ocorrer ter

sempre um impacto positivo ou negativo sobre pelo menos um dos objetivos do projeto,

como: o tempo, o custo, o escopo ou a qualidade. O risco poder ter uma ou mais causas

e um ou mais impactos. Por exemplo, uma causa pode ser: a falta de pessoal suficiente

para trabalhar dentro de uma rea de conhecimento do projeto, o evento do risco podeser a contratao inadequada de pessoal, podendo comprometer o cronograma, a

qualidade e o custo do projeto.

Os riscos tambm podem abranger os aspectos organizacionais como prticas

deficientes de gerenciamento de impacto. Por exemplo, a falta de sistemas de

gerenciamento integrados, vrios projetos simultneos, dependncia externa fora do

controle do gerente do projeto, etc. (VARGAS, 2009)

A figura 5 apresenta uma viso geral dos processos do gerenciamento de riscosno PMBOK. O quadro referente ao gerenciamento de riscos do projeto foi isolado para

fornecer uma viso ampliada dos processos de gerenciamento de risco do projeto,

conforme demonstrado no quadro 3.


36/85

37

Figura 5FluxogramadeProcessosde

Gerenciamento de Riscos do Projeto.

Fonte: PMI (2004)


37/85

38

5.1 Processos de gerenciamento de risco

O inicio de um projeto marcado por um grande esforo. No planejamento do

projeto, so realizadas reunies tendo como foco os objetivos do projeto: Escopo,Qualidade, Prazo e Custo. Neste momento j importante pensar nos riscos pois

medida que os objetivos vo se consolidando, os possveis riscos vo se tornando mais

provveis, podendo comprometer o andamento do projeto.

Os processos do gerenciamento de riscos do projeto esto dispostos da seguinte

forma:

a.

Plano de Gerenciamento do Risco: decide como abordar, planejar eexecutar as atividades de gerncia de risco para um projeto;

b. Identificao dos Fatores de Risco: determina quais riscos podem afetar oprojeto e documenta suas caractersticas;

c. Anlise Qualitativa de Risco: realiza uma anlise qualitativa dos riscos e ascondies para priorizar seus efeitos nos objetivos do projeto.

d. Anlise Quantitativa de Risco: mede a probabilidade atravs de umaanlise numrica e as conseqncias dos riscos e estima suas implicaes

para os objetivos do projeto.

e. Planejamento de resposta ao Risco: desenvolve procedimentos e tcnicaspara melhorar as oportunidades e reduzir as ameaas para os objetivos do

projeto.

f. Monitoramento e Controle do Risco: monitora riscos residuais identificanovos riscos, executa planos de reduo de risco e avalia sua eficcia durante

todo o ciclo do projeto.

Esses processos no ocorrem isoladamente, eles interagem entre si e tambm

com processos de outras reas.


38/85

39

Quadro 3Processos do Gerenciamento de Riscos. (PMI, 2004)

Fonte:PMI (2004)

1. Plano de Gerncia de Risco

1.1 Entradas

Fatores ambientais

Ativos de processosorganizacionais

Declarao do escopo do projeto

Plano de gerenciamento doprojeto

1.2 Tcnicas e Ferramentas

Reunies de planejamento

1.3 Sadas

Plano de gerenciamento deriscos

2. Identificao do Risco

2.1 Entradas

Plano de gerenciamento deriscosDeclarao do escopo do projeto

Fatores ambientais




Reviso da documentao

Tcnicas de coleta deinformaes.

Anlise da lista de verificao

Anlise das premissas

Tcnicas de diagramao

2.3 Sadas

Registro de riscos

3. Anlise Qualitativa do risco

3.1 Entradas



Plano de gerenciamento de riscos

Registro de riscos


Avaliao de probabilidadeimpacto de riscos

Matriz de probabilidade eimpacto do risco

Avaliao da qualidade dosdados sobre o risco

Categorizao de riscos

Avaliao da urgncia do risco

3.3 Sadas

Registro de riscos atualizados

1. Plano de Gerncia de Risco

1.1 Entradas

Fatores ambientais





Reunies de planejamento

1.3 Sadas

Plano de gerenciamento deriscos

2. Identificao do Risco

2.1 Entradas

Plano de gerenciamento deriscosDeclarao do escopo do projeto

Fatores ambientais




Reviso da documentao

Tcnicas de coleta deinformaes.

Anlise da lista de verificao

Anlise das premissas

Tcnicas de diagramao

2.3 Sadas

Registro de riscos

3. Anlise Qualitativa do risco

3.1 Entradas



Plano de gerenciamento de riscos

Registro de riscos


Avaliao de probabilidadeimpacto de riscos

Matriz de probabilidade eimpacto do risco

Avaliao da qualidade dosdados sobre o risco

Categorizao de riscos

Avaliao da urgncia do risco

3.3 Sadas


4.3 Sadas

Registro de riscosatualizados

5.3 Sadas


Plano de gerenciamento doprojeto (atualizaes)

Acordos contratuaisrelacionados a riscos

4. Anlise quantitativa do risco


Tcnicas de representao ecoleta de dados.

Anlise quantitativa de riscose tcnicas de modelagem

5. Plano de Resposta ao risco

5.1 Entradas

Plano de gerenciamento de riscoRegistro de Riscos


Estratgias para riscosnegativos ou ameaas

Estratgias para riscospositivos ou oportunidades

Estratgias para ameaas eoportunidades

Estratgia para respostascontigenciadas

6. Monitorando e Controlando risco

6.1 Entradas

Plano de gerenciamento de risco

Registro de Riscos

Solicitao de mudanas aprovadas

Informaes sobre o desempenhodo trabalho

Relatrios de desempenho


Reavaliao de riscos

Auditorias de risco

Anlise das tendncias e da variao

Medio do desempenho tcnico

Anlise das reservas

Reunies de andamento

6.3 Sadas

Registro de riscos(atualizaes)Mudanas solicitadasAes corretivas recomendadasAtivos de processos organizacionais(atualizaes)Plano de gerenciamento do projeto(atualizaes)

4.1 Entradas

Ativos de processos

organizacionais



Registro de Riscos identificados

Plano de gerenciamento do projeto Cronograma Custos

4.3 Sadas

Registro de riscosatualizados

5.3 Sadas


Plano de gerenciamento doprojeto (atualizaes)

Acordos contratuaisrelacionados a riscos

4. Anlise quantitativa do risco


Tcnicas de representao ecoleta de dados.

Anlise quantitativa de riscose tcnicas de modelagem

5. Plano de Resposta ao risco

5.1 Entradas

Plano de gerenciamento de riscoRegistro de Riscos


Estratgias para riscosnegativos ou ameaas

Estratgias para riscospositivos ou oportunidades

Estratgias para ameaas eoportunidades

Estratgia para respostascontigenciadas

6. Monitorando e Controlando risco

6.1 Entradas


Registro de Riscos

Solicitao de mudanas aprovadas

Informaes sobre o desempenhodo trabalho

Relatrios de desempenho


Reavaliao de riscos

Auditorias de risco

Anlise das tendncias e da variao

Medio do desempenho tcnico

Anlise das reservas

Reunies de andamento

6.3 Sadas

Registro de riscos(atualizaes)Mudanas solicitadasAes corretivas recomendadasAtivos de processos organizacionais(atualizaes)Plano de gerenciamento do projeto(atualizaes)

4.1 Entradas

Ativos de processos

organizacionais



Registro de Riscos identificados

Plano de gerenciamento do projeto Cronograma Custos


39/85

40

5.1.1Plano de Gerenciamento do Risco

Dentro de um processo de administrao de risco, o seu plano de gerenciamento

visa garantir que o tipo, o nvel e a visibilidade da Gerncia de Risco sejam compatveiscom o risco e com a importncia do projeto. O Plano gerencial de riscos deve ser

terminado j no incio do planejamento do projeto, por ser essencial para executar com

sucesso as outras atividades de planejamento.

O Plano do Gerenciamento do Risco , portanto, um documento que explica

como ser desenvolvido o processo gerencial do risco, o custo estimado e investido e a

nomeao de responsabilidades aos gestores e envolvidos. Os processos do Plano de

Gerenciamento de Riscos no atuam isoladamente, interagem entre si e com os

processos de outras reas, ocorrendo pelo menos uma vez em cada projeto (ALENCAR

e SCHMITZ. 2006; GURGEL. 2007 e SOARES. 2007).

5.1.1.1Principais Entradas do Plano de gerenciamento de riscos

As principais entradas so desenvolvidas inicialmente nas seguintes reas:

Gerenciamento da Integrao e no Gerenciamento de escopo. So elas: fatores

ambientais, ativos de processos organizacionais, declarao de escopo do projeto e

plano de gerenciamento do projeto. PMI (2004)

Fatores Ambientais: tudo deve ser considerado no projeto, inclusive os fatores

ambientais da empresa, pois eles podero influenciar no sucesso do projeto. Como, por

exemplo:

Polticas de gerncia do risco da organizao: algumas organizaes possuem

essa abordagem pr-definida para anlise de risco para cada projeto.

a.Tolerncia aos riscos: pr-definir as diferentes tolerncias aos riscos, atravsde polticas ou aes;

b.Bancos de dados comerciais: por exemplo: dados padronizados deestimativa de custos, informaes sobre estudos de risco do setor e banco de

dados de risco.

c.Sistema de informaes do gerenciamento do projeto: por exemplo, umconjunto de ferramentas automatizadas, como uma ferramenta de software


40/85

41

para elaborao de cronogramas, um sistema de gerenciamento de

configurao, um sistema de coleta e distribuio de informaes ou

interfaces Web para outros sistemas on-line automatizados.

Ativos de Processos organizacionais: so considerados ativos de processos

organizacionais as polticas, procedimentos, planos e diretrizes formais e informais.

Tambm podem ser representados pelo aprendizado e o conhecimento adquirido em

projetos anteriores. Podendo agrupar-se em duas categorias:

a.Processos e procedimentos da empresa: como, por exemplo, as normas,polticas de gerenciamento de projetos, contrataes, polticas e

procedimentos de qualidade (auditoria de processos, metas de melhoria,

listas de verificao e processos padronizados), procedimentos para

gerenciar os problemas e defeitos de maneira que sejam identificados e

controlados, procedimentos para controlar mudanas de normas e polticas

(como elas sero aprovadas e validadas), procedimentos para controlar os

riscos e suas categorias, impacto e definio de probabilidade e matriz de

probabilidade e impacto.

b.Base de conhecimento corporativo da empresa para armazenar erecuperar informaes: por exemplo, arquivos de projeto (escopo, custo,

cronograma, qualidade, desempenho, registro de riscos (aes de resposta

planejada e impacto de risco definido), base de dados financeira contendo

informaes como pessoal contratado, custos incorridos, oramento e

estouro nos custos do projeto.

Declarao do escopo do projeto: descreve os principais objetivos do projeto,

permitindo que a equipe do projeto realize um planejamento mais detalhado, servindo

de orientao para a equipe do projeto durante a execuo, auxiliando a avaliar as

solicitaes de mudana e verificar se estas esto dentro ou fora dos limites

estabelecidos no projeto. Quanto maior for o grau e o nvel de detalhamento da

declarao de escopo do projeto, melhor ser definido o trabalho que ser realizado pela


41/85

42

equipe ajudando a planejar, gerenciar e controlar sua execuo. A declarao do escopo

detalhada do projeto poder incluir as seguintes informaes:

a.

Objetivos do projeto: os critrios mensurveis do sucesso do projeto estoincludos na declarao do escopo. Os objetivos podem ser de ordem tcnica,

de negcios, custo, cronograma e qualidade. Os objetivos do projeto tambm

podem incluir metas de custo, cronograma e qualidade, e estas definidas em

uma determinada moeda como parmetros.

b. Descrio do escopo do produto: descreve as caractersticas do produto,servio ou resultado do por que da realizao do projeto. medida que o

projeto avana as caractersticas sero mais detalhadas, elas podem variar

com o tempo, contanto que forneam detalhes suficientes para dar suporte ao

planejamento posterior do escopo do projeto.

c. Requisitos do projeto: so as normas, especificaes ou outros documentosformalmente impostos, com descrio das condies a serem seguidas

projeto para atender a um determinado contrato. As expectativas e

necessidades das partes interessadas devero ser transformadas em requisitosprioritrios.

d. Limites do projeto: identifica o que est includo dentro do projeto edescreve explicitamente o que est fora do projeto, para prevenir que a parte

interessada cobre que um determinado produto, servio ou resultado

especfico seja componente do projeto.

e. Entregas do projeto: as entregas3 possuem os relatrios de gerenciamentode projetos e sua documentao e dependendo da declarao do escopo do

projeto, as entregas podem ser descritas de forma sumarizada ou detalhada.

3A entrega qualquer produto, resultado ou capacidade para realizar um servio exclusivo e verificvelidentificvel ma documentao do plano de gerenciamento do projeto e que deve ser produzido e

fornecido para terminar o projeto - Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos(Guia PMBOK)3 edio.


42/85

43

f. Critrios de aceitao de produtos: define o processo e os critrios paraaceitar os produtos terminados.

g.

Restries do projeto: lista e descreve as restries especficas do projetoassociadas ao escopo do projeto que limitam as opes da equipe. As

restries listadas na declarao do escopo do projeto so normalmente mais

numerosas e mais detalhadas do que as listadas no termo de abertura do

projeto.

h. Premissas do projeto: lista e descreve as premissas especficas do projetoassociadas ao escopo do projeto e o impacto potencial dessas premissas, se

no forem confirmadas. Frequentemente, as equipes de projetos identificam,

documentam e validam as premissas como parte do seu processo de

planejamento. As premissas listadas na declarao do escopo detalhada do

projeto so normalmente mais numerosas e mais detalhadas do que as

listadas no termo de abertura do projeto.

i. Organizao inicial do projeto: os membros da equipe do projeto e aspartes interessadas so identificados e tambm documentada.

j. Riscos iniciais definidos: Identifica os riscos conhecidos.

k. Marcos do cronograma: Os marcos so identificados e datados. Essas dataspodem ser consideradas como restries do cronograma.

l. Limitao de fundos: Descreve qualquer limitao dos recursos financeirosdo projeto, uma limitao do valor total ou uma limitao imposta em prazos

especificados.

m. Estimativa de custos: A estimativa de custos do projeto indica o custo totalesperado do projeto e normalmente precedida de um modificador que

fornece alguma indicao de exatido como, por exemplo, conceitual ou

definitiva.


43/85

44

n. Requisitos do gerenciamento de configurao do projeto: Descreve onvel de gerenciamento de configurao e controle de mudanas que ser

implementado no projeto.

o. Especificaes do projeto: Identifica os documentos de especificao comos quais o projeto deve estar de acordo.

p. Requisitos de aprovao: Identifica os requisitos de aprovao que podemser aplicados a itens como objetivos, entregas, documentos e trabalho do

projeto.

Plano de Gerenciamento do Projeto: O contedo do plano de gerenciamento

do Projeto est compreendido em trs partes:

a. Definio de papis e responsabilidades: definir as responsabilidades e osnveis de autoridade das pessoas que iro influir no plano.

b. Estrutura analtica do Projeto (EAP): um agrupamento orientado aosubproduto dos elementos do projeto que organiza e define o escopo total do

projeto. O trabalho que no est na EAP est fora do escopo do projeto.

c. Oramento da Gerncia de Risco: estabelece um oramento para agerncia do risco para o projeto.

5.1.1.2Tcnicas e FerramentasDe acordo com a PMI (2004), so as principais tcnicas e ferramentas do Plano

Gerencial do Risco:

Reunies de planejamento: o gerente do projeto, lderes de equipe do projeto

organizam reunies de planejamento para elaborao do plano de gerncia do risco,

podendo usar modelos de gerncia do risco ou outros inputs quando necessrios.


44/85

45

5.1.1.3Sadas do Plano de Gerenciamento de RiscosA ltima etapa do plano de gerenciamento do risco a formalizao dos

documentos de sada. Estes serviro de entrada para a prxima fase do processo de

gerenciamento do risco.Plano de gerncia de riscos: descreve como identificar o risco, a anlise

qualitativa e quantitativa, plano de respostas, estrutura do monitoramento e controle a

ser realizado durante o ciclo de vida do projeto e o oramento do plano da Gerncia de

Riscos. O plano de gerncia de risco no enderea respostas para riscos individuais este

alcanado no plano de resposta ao risco. A seguir o contedo detalhado do referido

plano

a. Contedo do plano de gerncia de riscos:Metodologias: define as abordagens, ferramentas, e fontes de dados

que podem ser usados para gerenciar o risco do projeto. Diferentes tipos

de avaliaes podem ser apropriados, dependendo do estgio do projeto,

quantidade de informao disponvel, e flexibilidade restante na gerncia

de risco.

Papis e responsabilidades: Definem a liderana, o suporte e os

membros da equipe de gerncia de risco para cada ao no plano de

gerncia de risco. Equipes de gerncia externa podem agir com mais

independncia para analisar de forma imparcial os riscos do projeto.

Oramento: estabelece um oramento para a gerncia do risco para o

projeto.

Momento: define com que frequncia o processo de gerncia do risco

ser realizado durante o ciclo de vida do projeto.

Ganho e interpretao: mtodos apropriados de interpretao e ganho

para identificar o momento e o tipo de anlise de quantificao e

qualificao do risco em que comea a ser realizado.

Critrios. Os critrios que diro que o risco est de acordo, quem e de

que maneira. O dono do projeto, cliente ou o patrocinador podem ter

diferentes critrios de risco. Os formulrios com o objetivo dos critrios

de aceitao pelo qual a equipe medir a eficincia da execuo do plano

de resposta ao risco.


45/85

46

Formatos de relatrios: Definem como os resultados do processo de

gerncia do risco sero documentados, analisados e comunicados para a

equipe do projeto, partes envolvidas, patrocinador e outros.

Investigao: documentos relativos s observaes das atividades derisco sero registrados para o benefcio do projeto, futuras necessidades,

e lies aprendidas. Eles serviro de base para a auditoria dos processos.

5.1.2Identificao de RiscosA identificao dos riscos visa especificar todos os riscos que podem afetar o

projeto, documentando as suas caractersticas. Participam desta atividade: o gerente de

projetos, membros da equipe, especialistas no assunto (externos ao projeto), clientes e

usurios finais, todos devem ser incentivados a identificar os riscos e ela dever ser feita

durante todo o projeto, pois os riscos so mutveis ao longo da execuo do projeto.

(ALENCAR, 2006)

5.1.2.1Principais Entradas de Identificao de RiscosSo as principais entradas de informaes para identificao dos riscos:

declarao do escopo e plano de gerenciamento de riscos as sadas do planejamento

definio dos riscos de acordo com as categorias e informaes histricas de projetos

anteriores ou banco de dados comerciais, estudos acadmicos, benchmarking, e outros

estudos publicados podem estar disponveis para pesquisa.

5.1.2.2Tcnicas e FerramentasSo as principais tcnicas e ferramentas de identificao do risco:

Reviso da documentao: consiste na reviso do escopo do projeto como um

todo e detalhadamente, pesquisa em arquivos de projetos anteriores e outras

informaes.

Tcnicas de informaes garantidas: exemplo de tcnicas de obteno de

informao usadas para identificar os riscos:

a. Brainstorming uma das tcnicas de identificao de risco maisutilizadas. A meta obter uma lista de riscos bem abrangente que possa


46/85

47

ser dirigida mais tarde para os processos qualitativos e quantitativos da

anlise de risco. (PMI, 2004; GURGEL, 2007; DINSMORE, 2005)

A equipe do projeto normalmente apresenta um brainstorming,

embora um conjunto de especialistas multidisciplinar possadesenvolver esta tcnica tambm. Sob a liderana de um

facilitador, estas pessoas geram idias sobre o risco do projeto.

Fontes de risco so identificadas num escopo amplo e anunciadas

para que todos possam examinar durante a reunio. Riscos so

ento categorizadas pelo tipo de risco, e se suas definies esto

precisas.

As quatro principais regras do brainstorming so:

I. Crticas so rejeitadas: Esta provavelmente a regra maisimportante. O princpio do julgamento no pode operar. A

falha do grupo ao cumprir esta regra a razo mais crtica

para que a sesso de brainstorming no obtenha sucesso.

Esta regra aquela que primariamente diferencia um

brainstorming clssico dos mtodos de conferncia

tradicionais.

II. Criatividade bem-vinda: Esta regra utilizada paraencorajar os participantes a sugerir qualquer idia que lhes

venha mente, sem preconceitos. necessrio deixar as

inibies para trs enquanto as idias so geradas. Quando

se segue esta regra, cria-se automaticamente um clima de

brainstorming apropriado.

III. Quantidade necessria: Quanto mais idias foremgeradas, maior a possibilidades de encontrar uma idia

valiosa. Quantidade gera qualidade.

IV. Combinao e aperfeioamento so necessrios: Oobjetivo desta regra encorajar a gerao de idias

adicionais para a construo e reconstruo sobre as idias

dos outros.

b.

Tcnica Delphi: trata-se de um mtodo que permite descobrir opiniesde especialistas em um assunto determinado como risco do projeto. Os


47/85

48

especialistas em risco do projeto so identificados, mas participam

anonimamente. (PMI, 2004; GURGEL, 2007; DINSMORE, 2005).

I.

PainelDelphi: um facilitador atravs da realizao de umasrie de questionrios solicita idias sobre os riscos de

projeto importantes. Os resultados depois de agregados so

enviados aos especialistas para reformular as proposies

apresentadas e incluir comentrios adicionais. Um consenso

com relao aos principais riscos do projeto pode ser

alcanado em algumas etapas desse processo. A tcnica

Delphi ajuda a reduzir influncias nas informaes e evita

que qualquer pessoa sofra uma influncia indevida como

consequncia.O nmero de rondas trabalhadas varia de

acordo com o grau de consenso atingido pelos especialistas,

sendo esse consenso entendido a nvel individual. Ou seja,

se houver uma discrepncia muito elevada na opinio de um

dado especialista nas vrias rondas, no se poder chegar a

um consenso. As opinies podem, no entanto variar de

ronda para ronda, uma vez que como so introduzidas novas

questes em cada questionrio, o especialista pode mudar

de opinio em relao s questes que considera mais

relevante. Este mtodo distingue-se essencialmente por trs

caractersticas bsicas, o anonimato, a integrao com

feedbackcontrolado e as respostas estatsticas do grupo. As

principais caractersticas do mtodo Delphi consistem

ento, na utilizao de um painel de peritos para obter

conhecimento, o fato de os participantes no terem

confrontao frente a frente, a garantia de anonimato das

respostas dadas pelos participantes e o uso de ferramentas

estatsticas simples para identificar padres de acordo. Com

efeito, uma das grandes vantagens deste mtodo permitir

que pessoas que no se conhecem, desenvolvam um projeto

comum, e sem ter que revelar as suas opinies uns aos


48/85

49

outros, cheguem a um acordo geral sobre uma dada rea de

interesse. A figura 6 apresenta um organograma que

demonstra os passos da tcnica Painel Delphi.

Figura 6Fluxograma do Painel Delphi.

Fonte: GURGEL (2007)

c. Entrevistas: uma tcnica simples, porm os riscos podem seridentificados quando entrevistamos gerentes de projeto ou especialistas

no assunto, que baseados em suas experincias podem fornecer

informaes teis para o entrevistador. Devem-se escolher indivduos

apropriados, deixando-os a par do projeto, fornecendo o escopo e a lista

de hipteses. (PMI, 2004; GURGEL, 2007 e DINSMORE, 2005)

Realizao de umquestionrio/inqurito

Anlise das Respostas doquestionrio

Sim No

Tabelamento das respostas e entrega dainformao ao grupo

Desenvolvimento do questionrio

seguinte

Compilao dos resultados numresumo final

Atingiu-seconsenso?

Incio

Fim


49/85

50

d. Anlise SWOT (Foras Strengths; Fraquezas Weaknesses;Oportunidades - Opportunities e Ameaas - Threats): uma

ferramenta simples utilizada para fazer a anlise do ambiente, podendo

ser ampliao da base para identificao de riscos, onde as foras efraquezas se relacionam com o ambiente interno e as oportunidades e

ameaas esto relacionadas a fatores externos. O ambiente interno pode

ser controlado atravs de polticas implantadas dentro da organizao,

ressaltando os pontos fortes e controlando ou minimizando os pontos

fracos. O ambiente externo foge do controle dos dirigentes, porm o fato

de no poder controlar no significa que no se pode conhec-lo e

monitor-lo com frequncia, tentando aproveitar as oportunidades e

tentar se planejar para evitar as ameaas.

A anlise SWOT pode servir para analisar um projeto ou parte de um

projeto, dividindo as grandes reas. Realizam-se os seguintes

questionamentos no quadro 4.

Quadro 4Anlise SWOT, pontos fortes x pontos fracos.


No quadro 5 demonstrado um caso de adoo da analise SWOTem umaempresa.

Ambiente Interno

PONTOS FORTES PONTOS FRACOS

OPORTUNIDADES AMEAAS

1. O que voc (empresa/equipe/pessoa) faz bem?

2. Que recursos especiais voc possui e pode aproveitar ?

3. O que outros (empresas/equipes/pessoas) acham quevoc faz bem?

1. No que voc pode melhorar?

2. Onde voc tem menos recursos que os outros?

3. O que outros acham que so suas fraquezas?

1. Que ameaas (leis, regulamentos, concorrentes)

podem lhe prejudicar ?

2. O que seu concorrente est fazendo?

1. Quais so as oportunidades externas que voc pode

identificar?

2. Que tendncias e novas tecnologias voc pode

aproveitar em seu favor?

Ambiente Externo


50/85

51

Quadro 5Anlise de RiscoSWOT

Uso do PMBOOK em novos Projetos.


Com apenas alguns minutos de reunio, o gerente do projeto num clima

de informalidade e simplicidade levanta os primeiros dados e ainda

aproxima o gerente da sua equipe ou cliente.

Cada sentena uma hiptese considerada como verdadeira, logo, cada

premissa precisa ser levantada, validada e colocada em uma lista de

riscos, levando em considerao o impacto na tomada de decises, se

alguma premissa se mostrar falsa.

Quanto mais informao se obtm sobre cada item identificado, maior

a chance de se tomar a deciso certa. Aps a anlise do quadro 5, novos

pontos vo surgindo antes de uma tomada de deciso.

A expanso de um item na anlise de SWOT migra para o uso de um

Mapa Mental como na figura 7.


51/85

52

Figura 7Modelo de Analise de Riscos SWOT

Mapas Mentais.


Uma anlise SWOTpode trazer organizao que a utiliza um conjunto

de informaes importantes para a tomada de decises, quando realizada atravs

de Mapas Mentais, temos condies de conduzir reunies eficazes com clientes

e membros da equipe levantando pontos que iro nos auxiliar em uma anlise

mais completa. (PMI, 2004; GURGEL, 2007)

Para completar, os Mapas Mentais nos permitem rapidamente ampliar aviso que temos dos pontos registrados durante a reunio, de forma a

identificarmos seus componentes mais importantes (como em uma estrutura

analtica de projetos) e at mesmo trabalhar em uma rpida diviso de tarefas

entre os participantes de uma reunio para uma efetiva tomada de deciso.

e. Checklist: uma ferramentapara a identificao de risco que elaboradacom base em informaes de um histrico e no conhecimento de projetos

anteriores, similares ou de outras fontes de informao. Porm todo o

cuidado pouco para no se limitar s categorias da lista Deve-se ter


52/85

53

ateno para explorar itens que no aparecem em um checklistpadro

caso eles paream importantes ao projeto especfico. O checklist deve

conter os itens de todos os tipos possveis de riscos do projeto.

importante conferir o checklist como um passo formal de cadaprocedimento de fechamento de projeto para melhorar a lista de riscos

potenciais, e das descries dos riscos.

f. Anlise das hipteses ou premissas: Cada projeto concebido edesenvolvido baseado em um conjunto de hipteses, cenrios, ou

dedues. Anlise de hipteses uma tcnica que explora a validade das

hipteses. Ela identifica riscos ao projeto como imperfeies,

inconsistncias, ou falta de hipteses.

g. Diagrama de causa e efeito tambm conhecido como diagramaIshikawa ou Espinha de Peixe (Fishbone) uma tcnica usada para

identificar e arranjar as causas de um evento ou um problema ou um

resultado. O diagrama de causa e efeito ilustra hierarquicamente as

causas de um problema de acordo com o seu nvel de detalhe ou

importncia e um resultado dado. Sua representao pode ser observadana figura 8. A utilizao do diagrama de causa e efeito tem boa aplicao

na identificao de causas de riscos.(GURGEL, 2007)


53/85

54

Figura 8Diagrama de Ichikawa ou Fishbone.


h. Digramas de influncia uma representao grfica do problemamostrando influncias, time ordering de eventos, e outras relaes entrevariveis e conseqncias. A figura 9 apresenta um exemplo do diagrama

de influncias.

Figura 9Diagrama de Influncia.


Efeito


54/85

55

5.1.2.3Sadas da Identificao dos Riscos

So as principais sadas no processo de identificao dos riscos:

Os Registros dos riscos: so compostos pelas listas dos riscos identificados,lista de possveis respostas e atualizao da Categoria dos Riscos.

Os Detonadores: algumas vezes chamados de sintomas de risco ou sinais de

advertncia, so indicaes que um risco ocorreu ou est preste a ocorrer. Por exemplo:

O fracasso no cumprimento dos marcos estabelecidos pode ser um sinal de advertncia

de atraso no cronograma.

A Entrada em outros processos: Identificao de um risco pode indicar a

necessidade de uma ao futura em outra rea. Por exemplo, o escopo pode no ter

detalhes suficientes que permitam a identificao adequada de riscos, ou o cronograma

pode no estar completo ou inteiramente lgico.

5.1.3Anlise Qualitativa de RiscosA anlise qualitativa o processo de avaliar o impacto e a probabilidade dos

riscos identificados. Permite qualificar e classificar os riscos em funo do seu efeito

potencial individual e prioriz-los em funo do seu efeito potencial para o projeto

como um todo.

As organizaes podem melhorar o desempenho do projeto de modo eficaz se

concentrando nos riscos de alta prioridade. A anlise qualitativa de riscos avalia a

prioridade dos riscos identificados usando a probabilidade de eles 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)A anlise qualitativa de riscos normalmente uma maneira rpida e econmica

de estabelecer prioridades para o planejamento de respostas a riscos, e estabelece a base

para a anlise quantitativa de riscos, se esta for necessria. A anlise qualitativa de

riscos deve ser reexaminada durante o ciclo de vida do projeto para acompanhar as

mudanas nos riscos do projeto. (PMI, 2004)


55/85

56

5.1.3.1Principais Entradas da Anlise Qualitativa dos Riscos

So as principais entradas de informaes para a realizao da anlise qualitativa

dos riscos:Os Ativos de processos organizacionais: deve-se utilizar dos dados de lies

aprendidas em projetos passados;

A Declarao do escopo do projeto: atravs desse documento pode-se avaliar

se o projeto de alta complexidade, recorrentes ou de baixa complexidade Portanto

focar-nos mais complexos que tendem a ter mais incertezas.

O Plano de gerenciamento de riscos: no plano de gerenciamento de riscos

esto inclusas funes e responsabilidades para conduzir o gerenciamento de riscos,

oramentos e atividades do cronograma para gerenciamento de riscos, categorias de

risco, definio de probabilidade e impacto, a matriz de probabilidade e impacto e

reviso das tolerncias a risco das partes. Todas essas entradas so geralmente

adequadas ao projeto durante o processo, por isso devem ser revistos quando da Anlise

qualitativa.

O Registro de riscos: contm a lista de riscos identificados, nela so descritos

os riscos identificados, incluindo suas causas-raiz e as premissas incertas do projeto.

5.1.3.2Tcnicas e Ferramentas

So as principais tcnicas e ferramentas utilizadas na anlise qualitativa do risco:

A Avaliao de probabilidade e impacto de riscos: investiga a probabilidade

de cada risco especfico ocorrer e o efeito potencial sobre um objetivo do projeto, como

tempo, custo, escopo ou qualidade, inclusive os efeitos negativos das ameaas e osefeitos positivos das oportunidades. A coleta de dados em entrevistas ou reunies com

participantes e at especialistas de fora do projeto ajudam a avaliar a probabilidade e o

impacto do risco. Tudo dever estar registrado para uma futura pesquisa

A Matriz de probabilidade e impacto: normalmente realizada usando uma

tabela de pesquisa ou uma matriz de probabilidade e impacto. Essa matriz especifica as

combinaes de probabilidade e impacto que levam classificao dos riscos como de

prioridade baixa, moderada ou alta.


56/85

57

Probabilidade

Alto Mdio Baixo

Impacto

Alto Alto Alto Mdio

Mdio Alto Mdio Baixo

Baixo Mdio Baixo Baixo

a. Metodologia: Cada organizao determina as combinaes deprobabilidade e impacto e definem os riscos como ma figura 10.

Risco alto (condio vermelha);

Risco moderado (condio amarela) e

Risco baixo (condio verde).

Figura 10Matriz de probabilidade e impacto em cores vermelho, amarelo e verde.Fonte: Elaborada pelo autor.

b. Ou uma matriz em preto e branco, essas condies podem ser indicadaspelos diferentes tons de cinza de acordo com a figura 11.

a rea cinza escuro (com os nmeros mais altos) -

representa risco alto;

a rea cinza mdio (com os nmeros mais baixos)

representa risco baixo; e

a rea cinza claro (com nmeros intermedirios)

representa risco moderado.

Figura 11Matriz de probabilidade e impacto em tons de branco e preto.Fonte: Elaborada pelo autor.

Probabilidade

Alto Mdio Baixo

Impacto

Alto Alto Alto Mdio

Mdio Alto Mdio Baixo

Baixo Mdio Baixo Baixo


57/85

58

A pontuao do risco ajuda a orientar as respostas a riscos. Por exemplo, riscos

que, se ocorrerem, tero u

Gestao Riscos

Documents

Transcript of Gestao Riscos