3.

Metodologias de Gerenciamento de Riscos

A complexidade que caracteriza a implantao de um sistema ERP uma das maiores preocupaes das organizaes que pretendem desenvolver projetos desta natureza. Como vimos no captulo anterior, existem muitos fatores que influenciam de forma negativa no objetivo de se conseguir uma implantao com sucesso de um sistema ERP. Fatores estes que podem ser evitados ou que podem ter seus impactos minimizados atravs de efetivo levantamento dos riscos inerentes a este tipo de projeto. Um procedimento vital no sentido de se evitar desvios nos objetivos do gerenciamento de um projeto de implantao de um sistema ERP, e que crucial para o sucesso deste projeto, o gerenciamento de riscos (Cleland e Ireland,
PUC-Rio - Certificao Digital N 0421051/CA

2000). Embora alguns destes desvios no possam ser previstos, outros, se identificados a tempo, podem ser controlados atravs de aes de preveno sobre a sua atuao. O gerenciamento de riscos adiciona ao gerenciamento de projetos uma abordagem estruturada para identificao e anlise de riscos no incio do planejamento do projeto e no decorrer das fases do desenvolvimento do software. (Gusmo e Moura, 2004)

3.1. Definio de risco A palavra riscos deriva do italiano antigo resicare que significa ousar. Neste sentido, risco uma opo e no um destino. Correr riscos faz parte da histria antiga (Bernstein, 1997). Nas ltimas dcadas a palavra riscos tem sido utilizada nos mais diversos objetivos tais como: riscos de negcios, riscos sociais, riscos econmicos, riscos de segurana, riscos polticos, entre outros. No que tange a gerenciamento de projetos, a sua aplicao se volta para os seus impactos no sucesso da execuo dos projetos, como podemos ver nas

45 definies seguintes, dadas pelas maiores instituies de gerenciamento de projetos do mundo: Risco um evento ou condio incerta que, se ocorrer, tem um efeito positivo ou negativo sobre ao menos um dos objetivos do projeto. (PMI, 2004). Segundo a Associao Brasileira de Gerenciamento de Projetos - ABGP, representante oficial do International Project Management Association - IPMA no Brasil, riscos so acontecimentos com impacto negativo (prejuzos ou danos) ao sucesso geral do projeto, ou so eventos que podem causar prejuzos que no puderam ser previstos. (Santos e Carvalho, 2005). Segundo a Association for Project Management, risco a combinao da probabilidade ou frequncia de ocorrncia de uma ameaa ou oportunidade definida e a magnitude das consequncias de sua ocorrncia (APM, 2006). Analisando as definies acima, podemos concluir que os riscos so condies ou circunstncias futuras que podero proporcionar um impacto
PUC-Rio - Certificao Digital N 0421051/CA

favorvel ou desfavorvel ao empreendimento. O risco tambm algo que est relacionado escolha, no ao acaso, pois decorre da incerteza inerente ao conjunto de possveis conseqncias (ganhos e perdas) que resultam de decises tomadas diariamente pelas organizaes.

3.2. Definio de gerenciamento de riscos Segundo o Project Management Institute - PMI, o gerenciamento de riscos um processo sistemtico que tem por objetivo identificar, analisar e responder aos riscos de um projeto. Seu objetivo o de diminuir ou at eliminar a probabilidade e o impacto de um evento negativo, ou seja adverso ao projeto, acontecer. Por outro lado, ele tambm se preocupa em aumentar a probabilidade e impacto de um evento positivo, ou seja, benfico para o projeto, acontecer (PMI, 2004). Segundo a ABGP, a gesto de riscos aplicadas em projetos consiste nos processos de identificao, classificao e quantificao dos riscos, bem como no gerenciamento das aes de resposta a todos riscos do projeto. (Santos e Carvalho, 2005).

46 uma aplicao sistemtica de polticas, procedimentos, mtodos e prticas para as tarefas de identificar, analisar, avaliar, tratar e monitorar os riscos. o processo no qual as decises so tomadas para aceitar riscos conhecidos e avaliados e/ou para a implementao de aes para reduzir as consequncias ou a probabilidade de ocorrncia destes riscos. (APM, 2006). O gerenciamento de riscos uma forma organizada de identificar e medir os riscos de desenvolver, selecionar e gerenciar as opes para o seu controle. (Kerzner, 2006). Analisando as definies acima, podemos concluir que o gerenciamento de riscos justamente um conjunto de processos proativos que so acionados para identificar e analisar riscos e executar aes para eliminar ou minimizar os problemas antes que ocorram e, conseqentemente, aumentar a probabilidade de sucesso dos projetos. Por isto importante que exista uma metodologia que organize estes
PUC-Rio - Certificao Digital N 0421051/CA

passos com o objetivo de se alcanar um efetivo controle dos riscos inerentes a um projeto. Mesmo a mais simples deciso gerencial ou de negcio envolve riscos em suas aes. Pelo fato dos projetos necessitarem de tomadas de deciso durante praticamente todo o seu ciclo de vida, gerenciar riscos torna-se um fator crtico de sucesso deste tipo de empreendimento (Pritchard, 2001). A seguir ser feita a anlise de algumas metodologias de riscos e ao final ser feito um estudo comparativo, no sentido de verificar suas semelhanas. As metodologias analisadas sero a de Boehm, a do Rational Unified Process RUP, a do Capability Maturity Model CMMI e a do PMI.

3.3. O gerenciamento de riscos na abordagem de Boehm Barry Boehm, ao apresentar o seu modelo em espiral (figura 7) no final dos anos 80, foi o pioneiro na incluso da gerncia de riscos no ciclo de vida de desenvolvimento de software. Neste modelo, a anlise dos riscos do projeto feita a cada iterao (Machado, 2002). Ele critica expressamente o processo de desenvolvimento clssico (em cascata), afirmando que estes modelos sequenciais fazem com que os

47 desenvolvedores acabem prometendo elaborar mais funcionalidades do software do que deveriam, sem antes entender quais so as implicaes resultantes dos riscos envolvidos (Boehm, 1991).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 7 Modelo de desenvolvimento em espiral de Barry Boehm (Fonte: Roque, 1998)

O objetivo do modelo espiral (figura 7) o de prover um metamodelo que possa acomodar diversos processos especficos. Isto significa que podemos encaixar, neste modelo, as principais caractersticas de outros modelos, adaptando-os a necessidades especficas de desenvolvedores ou a particularidades do software a ser desenvolvido (Matoso, 2004). Sua principal inovao guiar o processo de desenvolvimento gerado a partir deste metamodelo, com base em anlise de riscos e um planejamento que realizado durante toda a evoluo do desenvolvimento (Matoso, 2004). O modelo espiral descreve um fluxo de atividades cclico e evolutivo constitudo de quatro estgios. No estgio 1 devem ser determinados os objetivos, as solues alternativas e as restries. No estgio 2, por sua vez, devem ser analisados os riscos das decises tomadas no estgio anterior atravs da

48 construo de prottipos ou simulaes do software. O estgio 3 consiste nas atividades da fase de construo que incluem a especificao da soluo, sua codificao e posterior verificao. No estgio 4 feita a reviso das etapas anteriores e o planejamento da prxima fase. Neste planejamento, dependendo dos resultados obtidos nos estgios anteriores - decises, anlise de riscos e verificao - pode-se optar por seguir o desenvolvimento em outro tipo de modelo (Matoso, 2004). Segundo Boehm (1991), a identificao e respectivas aes com o risco no incio do desenvolvimento, diminuem os custos e ajudam a prevenir os impactos negativos que podem ser causados por ele. A metodologia de gerenciamento de riscos desenvolvida por Boehm, com base no modelo espiral apresentado, composta por duas grandes fases: Avaliao de Riscos (Identificao, Anlise e Priorizao de riscos) e Controle
PUC-Rio - Certificao Digital N 0421051/CA

dos Riscos (Plano de gerenciamento de riscos, Resoluo dos riscos e Monitoramento dos riscos), conforme pode ser visto na figura 8:

Figura 8 Processo de Gerncia de Riscos proposto por Boehm (Fonte: Boehm, 1991)

Como podemos observar, cada uma das fases composta por trs atividades secundrias, que, por sua vez, possuem tcnicas que as auxiliam a

49 alcanar os seus objetivos. A seguir sero apresentados os objetivos das atividades que compem a metodologia. Avaliao de Riscos: A identificao de riscos tem por objetivo a criao de uma lista com os riscos identificados que possam vir a impactar o sucesso do projeto. A anlise de riscos tem por objetivo executar a avaliao da probabilidade de ocorrncia e do tamanho do impacto que pode ser causado por cada um dos riscos identificados, com o objetivo de compr os seus graus de criticidades. A priorizao de riscos tem por objetivo criar um ranking priorizado dos riscos identificados e analisados de acordo com o seu grau de criticidade. Controle de Riscos: O planejamento da gerncia de riscos tem por objetivo a elaborao de um
PUC-Rio - Certificao Digital N 0421051/CA

planejamento de como devero ser gerenciados os riscos identificados qualificados e priorizados para que fiquem sob controle. A resoluo de riscos tem por objetivo a definio de aes para eliminar a probabilidade de ocorrncia de um risco ou minimizar os seus impactos para os objetivos do projeto. A monitorao de riscos tem por objetivo o monitoramento do progresso do projeto tendo por base o controle efetivo dos riscos do projeto atravs de aes corretivas, sempre que for necessrio. 3.4. O gerenciamento de riscos na abordagem do RUP O RUP um processo de engenharia de software que fornece uma abordagem disciplinada no que tange a assumir as responsabilidades e tarefas necessrias dentro do desenvolvimento organizado de um software. Seu objetivo o de assegurar que o produto gerado seja de alta qualidade, e que tenha sido desenvolvido dentro do cronograma e do oramento planejado, gerando assim uma satisfao das necessidades dos usurios finais (Kruchten, 2003). O RUP tem como base seis boas prticas de desenvolvimento de software: O desenvolvimento iterativo do software, onde os requisitos so implementados

50 gradativamente, o que faz com que os riscos sejam identificados e controlados prematuramente; o gerenciamento dos requisitos, que permite um maior controle sobre as necessidades dos stakeholders; a utilizao de uma arquitetura baseada em componentes, que gera a possibilidade do desenvolvimento isolado de partes do software, trazendo como benefcio o desenvolvimento de componentes genricos; uma modelagem visual, onde os modelos so simplificaes da realidade e com isto facilitam o entendimento do sistema pelos stakeholders; uma verificao contnua da qualidade, onde os testes so realizados ao final de cada iterao; e o estabelecimento de um processo de gerenciamento de mudanas, que garante que os stakeholders estejam sincronizados com as definies e eventuais mudanas que aconteam no sistema (Kruchten, 2003), O ciclo de vida proposto pelo RUP composto de quatro fases seqenciais que possuem atividades e objetivos especficos como pode ser visto na figura 9:
PUC-Rio - Certificao Digital N 0421051/CA

Figura 9 Fases do RUP (Traduzido da Fonte: Rational Software Corporation, 2003)

A fase de concepo tem como objetivo a definio do escopo do projeto e a posterior obteno do aceite de todos os stakeholders, com o intuito de garantir que suas expectativas sero atendidas. O primeiro marco do ciclo de vida do RUP chamado de Marco de Objetivos do Ciclo de Vida (Lifecycle Objectives LCO) alcanado quando existir a concordncia de todos os stakeholders sobre os requisitos levantados para o desenvolvimento da soluo e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de elaborao tem como objetivo a construo de uma arquitetura consistente e estvel para abrigar o software. A implementao dos requisitos mais crticos vai contribuir para que este fato se torne possvel. O segundo marco do ciclo de vida do RUP chamado de Marco de Arquitetura

51 (Lifecycle Architecture LCA) alcanado quando este objetivo tiver sido satisfeito e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de construo tem como objetivo finalizar o desenvolvimento do software atravs da implementao dos requisitos restantes dentro da arquitetura criada na fase anterior. O terceiro marco do ciclo de vida chamado de Marco de Capacidade Inicial de Operao (Initial Operational Capability IOC) alcanado quando o software estiver completo e suficientemente estvel para entrar em operao e, com isto, esta fase finalizada (Rational Software Corporation, 2003). A fase de transio tem como objetivo a garantia da disponibilizao do software para os seus usurios finais atravs de atividades como testes finais, documentao, homologao e treinamento. O quarto marco do ciclo de vida do RUP, que o seu marco final, chamado de Marco de Capacidade Inicial de Operao (Initial Operational Capability IOC) alcanado quando todos os
PUC-Rio - Certificao Digital N 0421051/CA

critrios de aceitao do software definidos pelos usurios finais tiverem sido satisfeitos e, com isto, esta fase finalizada (Rational Software Corporation, 2003). Esta a estrutura dinmica do RUP (composta por fases) que representa a dimenso do tempo no processo. Porm, ele tambm possui uma estrutura esttica que descreve como os elementos do processo so agrupados em disciplinas, que so um conjunto de atividades relacionadas maior rea de interesse dentro do processo. A figura 10 mostra a estrutura esttica e dinmica do RUP:

Figura 10 Estrutura dinmica e esttica do RUP (Traduzido da Fonte: Rational Software Corporation, 2003)

52 A disciplina Modelagem de Negcios abrange todas as tcnicas de modelagem que podem ser utilizadas para modelar visualmente o negcio. A disciplina Requisitos tem a finalidade de definir o que o sistema deve fazer. A disciplina Anlise e Design objetiva mostrar como os casos de uso do sistema sero realizados na implementao. A disciplina Implementao tem a funo de implementar e realizar teste do desenvolvedor em componentes de software. A disciplina Teste tem a funo de integrar e testar o sistema. J o objetivo da disciplina Implantao assegurar uma transio bem-sucedida do sistema, desenvolvido para seus usurios. A disciplina Gerenciamento de Configurao e Mudana, por sua vez, se preocupa em restringir e gerenciar alteraes nos itens de configurao do sistema. A disciplina Gerenciamento de Projeto tem a finalidade de fornecer uma estrutura para gerenciamento de projeto de software, fornecendo um guia prtico para planejamento, recrutamento, execuo e monitoramento de projeto e uma
PUC-Rio - Certificao Digital N 0421051/CA

estrutura para o gerenciamento de risco. Finalmente, a disciplina Ambiente cuida de definir e gerenciar o ambiente no qual o sistema est sendo desenvolvido (Rational Software Corporation, 2003). A figura 11 mostra todas as atividades que compem a disciplina Gerenciamento de Projeto:

Figura 11 RUP: Disciplina Gerenciamento de Projeto: Viso Geral da Atividade (Fonte: Rational Software Corporation 2003)

53 A gerncia de riscos no RUP utilizada em suas fases de desenvolvimento do produto, de forma sistemtica: Concepo nfase nos riscos dos requisitos de negcio; Elaborao foco nos riscos tcnicos de definio da arquitetura do software; Construo tratamento dos riscos lgicos envolvidos na construo do produto; Transio os riscos funcionais de utilizao do software (Kruchten, 2003). 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 sada os artefatos Plano de Gerenciamento de Riscos e Lista de Risco, que sero entrada para vrias atividades desta disciplina. A atividade Desenvolver o Plano de Gerenciamento de Riscos tem o objetivo de criar um plano documentado para identificar, analisar e priorizar riscos bem como identificar as estratgias de gerenciamento para os riscos mais
PUC-Rio - Certificao Digital N 0421051/CA

significativos do projeto. Este plano documentado o artefato Plano de Gerenciamento de Riscos. A atividade Identificar e Avaliar Riscos executa, com base no Plano de Gerenciamento de Riscos, a identificao, anlise e priorizao dos riscos do projeto bem como a determinao das estratgias mais apropriadas para gerenciar estes riscos. Esta atividade tambm reavalia os riscos no final de cada iterao. O artefato Lista de Riscos a sada desta atividade, criada no incio do projeto e atualizada nas demais atividades da disciplina. A atividade Monitorar Status do Projeto captura e avalia o status atual do projeto, utilizando os artefatos Plano de Gerenciamento de Risco e Lista de Risco como entradas e, dependendo das anlises deste status, atualiza a Lista de Riscos. 3.5. O gerenciamento de riscos na abordagem do CMMI A Software Engineering Institute (SEI), que faz parte da Carnegie Mellon University, um centro de pesquisa e desenvolvimento criado em 1984 e patrocinado pelo Departamento de Defesa dos Estados Unidos da Amrica, que prov uma prtica avanada de engenharia de software qualificando graus de qualidade de software (SEI, 2006).

54 Em 1987, a SEI criou um modelo chamado CMM (Capability Maturity Model), composto por documentos de maturidade de processos e por um questionrio de maturidade, que tinha por objetivo medir a qualidade dos processos de uma organizao e classific-los por nveis de maturidade (SEI, 2006). Em 1991, o SEI evoluiu a estrutura de maturidade de processo para o SWCMM (Capability Maturity Model for Software) que foi o primeiro modelo desenvolvido na rea de maturidade e capacidade organizacional, na rea de desenvolvimento de software (SEI, 2006). partir da outros modelos foram criados para cobrir outras reas de interesse da organizao como o SA-CMM (Capability Maturity Model for Software Acquisition) para processos de aquisio de software; o SE-CMM (Capability Maturity Model for System Engineering) para processos de engenharia de sistemas; o IPD-CMM (Capability Maturity Model for Integrated Product
PUC-Rio - Certificao Digital N 0421051/CA

Development) para processos de suporte ao produto e o P-CMM (Capability Maturity Model for People) para processos de administrao de recursos humanos necessrios para o desenvolvimento de software. Com o objetivo de eliminar as inconsistncias e diminuir as redundncias existentes, alm de criar uma terminologia comum, entre todos os modelos, a SEI, em 2000 os unificou lanando o CMMI (Capability Maturity Model Integration). O CMMI oferece uma avaliao mais efetiva e consequente melhoria dos processos da organizao atravs de uma viso integrada. Alm disto, os custos desta avaliao so reduzidos e oferece um novo meio de representao da informao de disciplinas especficas, atravs do uso de modelos de melhoria testados (Gusmo e Moura, 2004). Existem duas formas de representao dos modelos CMMI: a contnua (continuous) e a por estgios (staged), esta segunda derivada do SW-CMM. A representao contnua permite que a organizao escolha a ordem das melhorias de acordo com os objetivos de negcio ou ainda pelas suas reas de risco e deve ser utilizada quando a organizao conhece os processos que devem ser melhorados. A representao por estgios prov uma reconhecida seqncia de melhorias, iniciando pelas prticas gerenciais bsicas e avana gradativamente por um caminho predefinido de sucessveis nveis, onde cada nvel serve de base para

55 o prximo. Esta representao deve ser utilizada quando a organizao no sabe quais so os processos que devem ser melhorados (SEI, 2006). A representao por estgios, que trata do nvel de maturidade da organizao como um todo, possui cinco nveis de maturidade (Inicial, Gerenciado, Definido, Gerenciado Quantitativamente e Aprimorando). Cada nvel possui diversas reas de processo. A representao contnua, que trata do nvel de maturidade da organizao como um todo, possui seis nveis de maturidade para dimenso da capacitao (Incompleto, Executado, Gerenciado, Definido, Gerenciado Quantitativamente e Aprimorando).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 12 Estrutura do CMMI

Conforme descrito na figura 12, cada nvel de maturidade composto por diversas reas de processos (process area PA) que so agrupamentos de prticas em uma rea especfica. No CMMI, existem 25 reas de processos que so comuns tanto para a representao por estgio como para a representao contnua. As reas de processos so compostas por objetivos especficos (specific goals, SGs) que identificam caractersticas nicas que descrevem o que precisa ser

56 implementado para satisfazer uma rea de processo; e objetivos genricos (generic goals, GGs) que so objetivos que aparecem em vrias reas de processo. Os objetivos especficos possuem prticas especficas (specific practice, SPs) que so atividades consideradas essenciais para que um objetivo especfico seja alcanado. Por sua vez, os objetivos genricos possuem prticas genricas (generic practice, GPs) relativas a compromissos, habilidades, diretrizes para implementao e verificaes que so necessrias para o atingimento de um objetivo genrico. O gerenciamento de riscos em projetos tratado inicialmente pelo CMMI no segundo nvel de maturidade (Gerenciado) atravs de duas reas de processo: Project Planning (planejamento do projeto) atravs do SP Identificar os Riscos do Projeto dentro da SG Desenvolvimento do Plano do Projeto; e Project Monitoring and Control (monitorao e controle do projeto) atravs da SP Monitorar os Riscos do Projeto dentro da SG Monitorar o Projeto de Acordo
PUC-Rio - Certificao Digital N 0421051/CA

com o Plano. Entretanto, esta atuao feita de de uma forma reativa, ou seja, colocando o seu foco apenas na identificao dos riscos para conscientizao e reao medida que eles ocorram. O gerenciamento de riscos efetivamente tratado no terceiro nvel de maturidade (Definido) atravs da rea de processo Risk Management (gerncia de riscos). Esta rea de processo atua de uma forma proativa no sentido de minimizar os impactos dos riscos nos objetivos do projeto.
SG 1 Preparar-se para a Gerncia de Riscos SP 1.1 SP 1.2 SP 1.3 SG 2 SP 2.1 SP 2.2 SG 3 SP 3.1 Determinar Fontes e Categorias de Riscos Definir Parmetros de Riscos Estabelecer uma Estratgia para a Gerncia de Risco Identificar Riscos Avaliar, Categorizar e Priorizar Riscos Desenvolver Planos de Mitigao de Riscos

Identificar e Analisar Riscos

Mitigar Riscos

SP 3.2 Implementar Planos de Mitigao de Riscos Tabela 3 Objetivos Especficos da rea de Processo Risk Management do CMMI (fonte: SEI, 2006)

57 O objetivo especfico Preparar-se para a Gerncia de Riscos, atravs das suas trs prticas especficas descritas na tabela 3, tem a funo de estabelecer uma estratgia para identificar, analisar e mitigar riscos, que devero ficar documentadas num plano de gerenciamento de riscos. O objetivo especfico Identificar e Analisar Riscos, atravs das suas duas prticas especficas descritas na tabela 3, tem a funo de identificar os riscos e categoriz-los alm de fazer a sua anlise para obter o seu nvel de probabilidade e impacto com o objetivo de prioriz-los quanto ao seu grau de criticidade. O objetivo especfico Mitigar Riscos, atravs das suas duas prticas especficas descritas na tabela 3, tem a funo de atuar nos riscos no sentido de minimizar a sua probabilidade de ocorrncia e o seu impacto aos objetivos do projeto. Alm destes trs objetivos especficos, a rea de processo Risk
PUC-Rio - Certificao Digital N 0421051/CA

Management possui tambm um objetivo genrico: GG3 Institucionalizar um Processo Definido composto de 12 prticas genricas. Este objetivo genrico foi considerado desnecessrio para o escopo do presente trabalho e no ser comentado. 3.6. O gerenciamento de riscos na abordagem do PMI Estabelecido em 1969 e sediado na Filadlfia, Pensilvnia EUA, o Project Management Institute (PMI) a principal associao mundial sem fins lucrativos em Gerenciamento de Projetos, atualmente com mais de 170.000 associados em todo o mundo, que praticam e estudam o Gerenciamento de Projeto nas mais diversas reas. O seu principal documento o A Guide to the Project Management Body of Knowledge PMBOK, considerado um padro global para o Gerenciamento de Projetos nos mercados de hoje. O PMBOK prope quarenta e quatro processos divididos em nove reas de conhecimentos necessrias, segundo o PMI, para se gerenciar um projeto com sucesso: Gerncia da Integrao, Gerncia de Escopo, Gerncia de Tempo, Gerncia de Custos, Gerncia de Qualidade, Gerncia de Recursos Humanos,

58 Gerncia de Comunicaes, Gerncia de Riscos e Gerncia de Aquisies, que podem ser vistos na figura 13 (PMI, 2004).

PUC-Rio - Certificao Digital N 0421051/CA

Figura 13 Viso Geral das reas de Conhecimento e Processos de Gerenciamento de Projetos (fonte: PMI, 2004)

Estes processos esto agrupados em cinco grupos de processos, conforme mostrado na figura 14: Iniciao, onde o projeto definido e autorizado; Planejamento, onde so planejadas as aes necessrias para o alcance dos objetivos do projeto; Execuo, onde feita a realizao das aes planejadas na fase anterior; Monitoramento e Controle, onde o progresso do projeto controlado e medido com o intuito de identificar eventuais variaes e, neste caso, tomar aes corretivas para que os objetivos do projeto voltem a ser atendidos; e Encerramento, onde a entrega do produto formalizada e o projeto finalizado.

59

PUC-Rio - Certificao Digital N 0421051/CA

Figura 14 Grupo de Processos do Ciclo de Vida de um Projeto segundo o PMI (fonte: PMI, 2004)

A gerncia de integrao engloba os processos necessrios para identificar, definir, combinar, unificar e coordenar os diversos processos de gerenciamento de projetos dentro dos grupos de processos. A gerncia de escopo, os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio para ser completado com sucesso. A gerncia de tempo, os processos necessrios para garantir que o projeto termine dentro do prazo previsto. A gerncia de custos, os processos necessrios para garantir que o projeto termine dentro do oramento aprovado. A gerncia de qualidade, os processos necessrios para garantir que o projeto satisfaa as necessidades para o qual foi empreendido. A gerncia de recursos humanos, os processos necessrios para garantir o uso mais efetivo das pessoas envolvidas no projeto. A gerncia de comunicao, os processos necessrios para garantir a correta gerao, distribuio, armazenamento, coleta, e disposio final das informaes relativas ao projeto. A gerncia de aquisies, os processos necessrios para compra de produtos e servios de fora da organizao executora do projeto.

60 E, finalmente, a gerncia de riscos inclui os processos referentes ao planejamento da gerncia de riscos, identificao, anlise, ao planejamento das respostas e ao controle e monitorao dos riscos em um projeto. Esses processos interagem entre si e com os processos das outras reas do conhecimento. Os objetivos da gerncia de riscos so aumentar a probabilidade de ocorrncia e os impactos de eventos positivos e diminuir a probabilidade e os impactos dos eventos adversos aos objetivos do projeto. A gerncia de riscos composta por seis processos que acontecem sequencialmente, cinco deles no fase de planejamento e o sexto na fase de monitoramento e controle. So eles: Planejamento do Gerenciamento de Riscos, Identificao de Riscos, Anlise Qualitativa de Riscos, Anlise Quantitativa de Riscos, Planejamento de Respostas a Riscos e Monitoramento e Controle de Riscos.
PUC-Rio - Certificao Digital N 0421051/CA

Figura 15 Os processos da gerncia de riscos segundo o PMI (criado pelo autor)

O processo de Planejamento de Gerenciamento de Riscos, executado na fase de planejamento, determina como abordar e planejar as gerncia de riscos do projeto. atividades de

61 O processo de Identificao de Riscos, que acontece na fase de planejamento, identifica, atravs de uma abordagem organizada, eventos de risco relevantes que possam impactar o atendimento dos objetivos do projeto. O processo de Anlise Qualitativa de Riscos, que acontece na fase de planejamento, avalia e classifica os riscos identificados em relao aos seus impactos e probabilidades de ocorrncia e os prioriza de acordo com seus potenciais efeitos sobre o desempenho do projeto. O processo de Anlise Quantitativa de Riscos, que acontece na fase de planejamento, analisa numericamente os riscos mais significantes estabelecidos durante a anlise qualitativa, e a interao entre eles, com o objetivos de estimar um range de possveis resultados para o projeto como um todo. O processo de Planejamento de Respostas a Riscos, que acontece na fase de planejamento, desenvolve procedimentos e tcnicas para ampliar as oportunidades e reduzir as ameaas aos objetivos do projeto, assegurando que os
PUC-Rio - Certificao Digital N 0421051/CA

riscos identificados sero tratados adequadamente. O processo de Monitoramento e Controle de Riscos, que acontece na fase de monitoramento e controle, rastreia sistematicamente os riscos identificados, monitora os riscos residuais e identifica novos riscos. Ele tambm assegura a execuo dos planos de respostas aos riscos e avalia a sua efetividade. 3.7. Comparao entre as metodologias apresentadas A tabela 4 toma como base os tens que compem as metodologias de riscos apresentadas e faz uma comparao entre elas, agrupando-as de uma maneira lgica e sequencial quanto sua atuao. O objetivo desta comparao a de investigar similaridades e divergncias entre elas com o intuito de identificar uma sequncia nica para gerenciar riscos em projetos de software.

62 Boehm RUP CMMI

Preparar-se para a Gerncia dos Riscos (SG 1): Determinar Fontes e Categorias de Riscos (SP 1.1) Definir Parmetros de Riscos (SP 1.2) Estabelecer uma Estratgia para Gerncia de Risco (SP 1.3)

PMI

Desenvolver o Plano de Gerenciamento de Riscos

Planejamento da Gerncia de Riscos

Identificao de Riscos

Identificao dos Riscos Anlise Qualitativa dos Riscos Anlise Quantitativa dos Riscos Planejamento das Respostas aos Riscos Planejamento das Respostas aos Riscos Monitorao e Controle de Riscos

Anlise de Riscos Identificar e Avaliar os Riscos

Identificar e Analisar Risco (SG 2): Identificar Riscos (SP 2.1)

Priorizao de Riscos
PUC-Rio - Certificao Digital N 0421051/CA

Planejamento da Gerncia de Riscos

Mitigar Riscos (SG 3): Desenvolver Planos de Mitigao deRiscos (SP 3.1)

Resoluo de Riscos Monitorar o Status do Projeto Monitorao de Riscos

Mitigar Riscos (SG 3): Implementar os Planos de Mitigao de Riscos (SP 3.2)

Tabela 4 Processos da gerncia de riscos Boehm x RUP x CMMI x PMI

A partir da anlise da tabela, inegvel afirmar que as abordagens apresentadas, embora tenham suas caractersticas prprias, possuem alguns princpios e atividades em comum, mostrando uma consonncia em seus aspectos essenciais. Um outro aspecto levantado neste estudo foi a incluso do gerenciamento de oportunidades, ou seja, a explorao de eventos positivos, em conjunto com os processos de gerenciamento de riscos. Da mesma forma que identificamos os riscos que possam gerar impactos negativos ao projeto e, em seguida, nos preocupamos em criar estratgias para eliminar a probabilidade deles

63 acontecerem, devemos tambm buscar as oportunidades, tambm chamadas de riscos positivos que, caso aconteam, traro impactos positivos ao projeto. Neste caso, as estratgias devem ser elaboradas no sentido de aumentar a probabilidade do acontecimento destas oportunidades. Podemos verificar que todas as metodologias, dentro do seu tipo de estrutura, possuem processos de identificao, anlise, planejamento de respostas e monitorao e controle de riscos. A dinmica vista em todas as metodologias segue a mesma linha. partir da identificao dos riscos e de sua anlise, elaboram-se opes de aes com vistas a proteger o projeto contra os riscos e, em seguida, decide-se qual destas opes ser a melhor para ser utilizada para que se coloque em prtica esta proteo. Isto comprova a importncia da gerncia de riscos para os projetos de um
PUC-Rio - Certificao Digital N 0421051/CA

modo geral, em especial em projetos de alto risco como o da implantao de sistemas ERP. Os altos custos oriundos de impactos negativos causados por riscos inerentes a estes tipos de projetos, poderiam ser minimizados se existisse uma preocupao da equipe do projeto em, no mnimo, buscar a identificao de riscos e a criao de estratgias de ao para os mesmos.