02 - ESTUDO DE CASO SOBRE GERÊNCIA RISCOS

UNIVERSIDADE LUTERANA DO BRASIL FACULDADE DE INFORMÁTICA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CAMPUS CANOAS

ESTUDO DE CASO SOBRE GERÊNCIA DE PROJETOS COM FOCO EM GERÊNCIA DE RISCOS Werner Seibert

Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso em Informática II e apresentada ao Curso de Ciência da Computação da Universidade Luterana do Brasil, campus Canoas, como pré-requisito para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Msc. Roberto Petry

Canoas, Junho de 2004.

DEDICATÓRIA

Este trabalho é dedicado aos meus pais e minha esposa, pois só eles sabem por tudo o que eu e eles passaram para que esse momento chegasse.

AGRADECIMENTOS

Quando comecei este trabalho eu juntei minhas mãos e me dirigi a Deus em oração solicitando força e sabedoria para poder concluir este trabalho. Assim sendo, quero fazer das palavras de Davi a minha gratidão agora que o trabalho foi concluído. “Bendito és tu, Senhor, Deus de nosso pai Israel, de eternidade em eternidade. Tua, Senhor, é a grandeza, o poder, a honra, a vitória e a majestade; porque teu é tudo quanto há nos céus e na terra; teu, Senhor, é o reino. Contigo está o engrandecer e a tudo dar força”. Louvado sejas, ó bom Deus. Obrigado, Roberto Petry, pelo apoio, conselhos e orientações que recebi de ti neste trabalho.

SUMÁRIO DEDICATÓRIA ....................................................................................................................... 2 AGRADECIMENTOS ............................................................................................................. 3 LISTA DE FIGURAS............................................................................................................... 6 LISTA DE QUADROS............................................................................................................. 8 RESUMO................................................................................................................................... 9 ABSTRACT ............................................................................................................................ 10 1 INTRODUÇÃO.................................................................................................................. 11 1.1 OBJETIVOS .................................................................................................................. 13 2 GERENCIAMENTO DE PROJETOS ............................................................................ 15 3 RISCO SOB A ÓTICA DE ALGUMAS METODOLOGIAS ....................................... 18 3.1 A ABORDAGEM DA NBR ISO/IEC 12207. ................................................................... 19 3.2 A ABORDAGEM DO SW-CMM..................................................................................... 20 3.2.1 SRE...................................................................................................................... 22 3.2.1.1 O Método SRE........................................................................................... 23 3.2.1.1.1 Contratação ......................................................................................... 23 3.2.1.1.2 RI&A (Identificação e Análise de Risco) ........................................... 24 3.2.1.1.3 Relatório Provisório............................................................................ 26 3.2.1.1.4 MSP (Plano para a Estratégia de Mitigação)...................................... 26 3.2.1.1.5 Relatório Final .................................................................................... 27 3.2.2 Considerações finais sobre o CMM .................................................................... 27 3.3 A ABORDAGEM DO PMBOK........................................................................................ 28 3.3.1 Planejamento da Gerência de Risco .................................................................... 30 3.3.2 Identificação dos Riscos...................................................................................... 34 3.3.3 Análise Qualitativa dos Riscos............................................................................ 36 3.3.4 Análise Quantitativa dos Riscos.......................................................................... 38 3.3.5 Planejamento de Resposta a Riscos .................................................................... 39 3.3.6 Controle e Monitoração de Riscos ...................................................................... 41 4 FERRAMENTAS DE GERENCIAMENTO DE RISCO .............................................. 44 4.1 PERTMASTER ............................................................................................................... 44 4.2 RISKTRAK.................................................................................................................... 47

4.3

RISK+ .......................................................................................................................... 49

5 PROPOSTA DE GERENCIAMENTO DE RISCOS ..................................................... 52 5.1 MODELAGEM DO PROTÓTIPO....................................................................................... 53 5.2 DESENVOLVIMENTO DO PROTÓTIPO ............................................................................ 63 5.3 RESULTADOS OBTIDOS ................................................................................................ 75 6 CONCLUSÃO .................................................................................................................... 78 REFERÊNCIAS E OBRAS CONSULTADAS.................................................................... 80 GLOSSÁRIO .......................................................................................................................... 83

LISTA DE FIGURAS Figura 1 – Organização da norma NBR ISO/IEC 12207 ......................................................... 20 Figura 2 – Áreas do SRE .......................................................................................................... 23 Figura 3 – Ciclo da Entrevista .................................................................................................. 25 Figura 4 – Áreas de Conhecimento do PMBOK. ..................................................................... 29 Figura 5 – Visão do processo de Planejamento da Gerência de Risco..................................... 31 Figura 6 – Visão do processo de Identificação dos Riscos....................................................... 34 Figura 7 – Visão do processo de Análise Qualitativa dos Riscos ............................................ 36 Figura 8 – Visão do processo de Análise Quantitativa dos Riscos .......................................... 38 Figura 9 – Visão do processo de Planejamento de Resposta a Riscos ..................................... 40 Figura 10 – Visão do processo de Controle e Monitoração de Riscos ..................................... 42 Figura 11 – Gerenciamento de Projetos no Pertmaster ............................................................ 45 Figura 12 – Gráfico de tempo por riscos .................................................................................. 46 Figura 13 – Gráfico de tempo para o projeto............................................................................ 46 Figura 14 – Exemplo de uma Lista de Riscos no RiskTrak ..................................................... 48 Figura 15 – Query no banco de dados ...................................................................................... 48 Figura 16 – Exemplo de definição de risco no RiskTrak ......................................................... 49 Figura 17 – Integração do Risk+ com o MS Project ................................................................ 50 Figura 18 – Entrada de dados para análise de tempo e custo no Risk+.................................... 51 Figura 19 – Resultado da análise de tempo no Risk+............................................................... 51 Figura 20 – UML Use Case – Visão Macro ............................................................................. 54 Figura 21 – UML Use Case – Visão “Definir Usuários” ......................................................... 56 Figura 22 – UML Use Case – Visão “Manter Projeto”............................................................ 59 Figura 23 – UML Use Case – Visão “Manter Riscos”............................................................. 60 Figura 24 – UML Diagrama de Classes ................................................................................... 62

Figura 25 – Protótipo – Login .................................................................................................. 63 Figura 26 – Protótipo – Administração de Contas de Acesso .................................................. 64 Figura 27 – Protótipo – Seleção do Projeto.............................................................................. 65 Figura 28 – Protótipo – Lista de Riscos do Projeto Selecionado ............................................. 66 Figura 29 – Protótipo – Planejamento do Projeto .................................................................... 67 Figura 30 – Protótipo – Definição de Membros ....................................................................... 68 Figura 31 – Protótipo – Atribuição de Permissões ................................................................... 68 Figura 32 – Protótipo – Definição da Metodologia e Documentos de Apoio .......................... 69 Figura 33 – Protótipo – Definição da Matriz de Impacto......................................................... 70 Figura 34 – Protótipo – Especificação do Orçamento da Gerência de Riscos ......................... 70 Figura 35 – Protótipo – Definição de Responsabilidades no Projeto ....................................... 71 Figura 36 – Protótipo – Administração de um Risco ............................................................... 74 Figura 37 – Protótipo – Histórico de Mudanças de um Risco.................................................. 75

LISTA DE QUADROS Quadro 1 – Exposição de Riscos .............................................................................................. 24 Quadro 2 – Exemplo de Relatório de Riscos............................................................................ 33 Quadro 3 – Método de pontuação de impacto com abordagem ordinal................................... 37 Quadro 4 – Classificação do risco com abordagem cardinal de probabilidade x impacto....... 37

RESUMO Na área de informática um dos maiores fatores de sucesso ou não nos projetos está diretamente relacionado ao uso de metodologias de gerenciamento de projetos e não necessariamente na tecnologia das ferramentas utilizadas. Levando em conta este cenário, o trabalho tem como principais objetivos o de estudar as metodologias padrões de mercado para a Gerência de Projetos com foco em Gerência de Riscos e propor um modelo de Gerenciamento de Riscos que seja aplicável comercialmente e desenvolver um protótipo que atenda os princípios básicos desta metodologia.

ABSTRACT One of the biggest factors of success or not in projects from the area of computer science is directly related to the use of project management methodologies and not necessarily to the technology of the used tools. Taking in account this scene, this work has as main objectives to study the standard market methodologies for Project Management with focus on Risk Management and to propose a Risk Management model that is commercially applicable and to develop an archetype that takes care of the basic principles of this methodology.

11

1 INTRODUÇÃO A Gerência de Projetos é muito importante para o sucesso de qualquer atividade que se caracterize como um projeto, isto é, que tenha um início, meio e fim. Um exemplo disso é a famosa “crise de software” que tem sido bastante estudada pela comunidade de software e outras instituições como o DOD (Departamento de Defesa dos Estados Unidos) e do Standish Group. O estudo conduzido pelo DOD indicou que 75% de todos os grandes sistemas intensivos de software adaptados falham e que a causa principal é o pobre gerenciamento por parte do desenvolvedor e adquirente e o problema não é de desempenho técnico. O estudo desenvolvido pelo Standish Group chamado de relatório do “Chaos” tem como foco a indústria de software comercial. Resumidamente, todas essas análises levaram as mesmas conclusões que são: •

Desenvolvimento de software é ainda imprevisível;

•

Somente 10% dos projetos de software são entregues com sucesso dentro das estimativas de orçamento e custo;

12

•

A disciplina de gerência é mais um discriminador de sucesso ou falha do que são os avanços tecnológicos;

•

O nível de software jogado fora e que tem necessidade de retrabalho é um indicativo de processo imaturo.

Segundo o PMI (Project Management Institute), no mundo estima-se que US$ 10 trilhões são gastos anualmente no mundo em projetos, o que equivale a 25% do PIB mundial. O “Chaos Report” divulgado pelo Standish Group em 2001 nos dá outros números ainda mais impressionantes sobre os projetos: •

Somente 16% são bem sucedidos;

•

Somente 28% foram entregues no prazo e no orçamento previsto;

•

23% são cancelados;

•

94% vão reiniciar pelo menos uma vez;

•

Somente 61% vão manter o escopo original.

Alguns problemas típicos em projetos são [SOTSD]: •

Atrasos no cronograma;

•

Custos acima do previsto;

•

Falta de recursos de pessoal;

13

•

Mudanças de requisitos e especificações;

•

Qualidade abaixo da esperada;

•

Complexidade acima da capacidade;

•

Produtos mal projetados;

•

Produtos que não funcionam;

•

Projetos que são cancelados;

Com a disponibilização desses estudos ficou evidente que as práticas de gerência de projetos devem ser melhoradas para que se tenha sucesso nos projetos de tecnologia da informação [MAC01]. Visto a importância do tema, faz-se necessário uma análise dos principais modelos de Gerenciamento de Projetos com foco em Gerência de Riscos para que desta forma possamos propor um modelo de Gerência de Riscos que seja útil e aplicável em um ambiente comercial.

1.1 OBJETIVOS Este trabalho tem alguns objetivos. Os principais são o de estudar as metodologias padrões de mercado para a Gerência de Projetos com foco em Gerência de Riscos, adotar como modelo uma destas metodologias e desenvolver um protótipo que atenda os princípios básicos desta metodologia.

14

Além destes, o trabalho apresenta como objetivos específicos: •

Estudar o modelo de Gerenciamento de Riscos do PMBOK e outros modelos equivalentes;

•

Analisar as Ferramentas para Gerência de Risco disponíveis no mercado;

•

Modelar um protótipo que atenda os princípios básicos da metodologia definida;

•

Desenvolver o protótipo.

15

2 GERENCIAMENTO DE PROJETOS Segundo a definição do PMBOK (Project Management Body of Knowledge), um projeto é um empreendimento com características próprias, tendo princípio e fim, conduzido por pessoas, para atingir metas estabelecidas dentro de parâmetros de prazo, custo e qualidade [PMI00]. Gerenciamento

de

projeto

é

a

aplicação

de

conhecimentos,

habilidades, ferramentas e técnicas em projetos com o objetivo de atingir ou até mesmo exceder às necessidades e expectativas dos clientes e demais partes interessadas do projeto. Outra característica do gerenciamento de projetos é que ele é acompanhado de processos tais como: iniciação, planejamento, execução, controle e encerramento. Assim sendo, a Gerência de Projetos é distribuída em nove áreas de conhecimento onde cada uma delas descreve seus respectivos processos a fim de garantir que os objetivos planejados sejam atingidos. Segue, de forma bem sucinta, uma explicação sobre cada uma destas áreas: Gerência de integração: O objetivo principal é realizar as negociações dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execução do plano do projeto, e o controle geral de mudanças.

16

Gerência de Escopo: O objetivo principal é definir e controlar o que deve e o que não deve estar incluído no projeto. Consiste da iniciação, planejamento, definição, verificação e controle de mudanças do escopo. Gerência de Tempo do Projeto: O objetivo principal é garantir o término do projeto no tempo certo. Consiste da definição, ordenação e estimativa de duração das atividades, e de elaboração e controle de cronogramas. Gerência de Custo: O objetivo principal é garantir que o projeto seja executado dentro do orçamento aprovado. Consiste de planejamento de recursos, e estimativa, orçamento e controle de custos. Gerência de Qualidade do Projeto: O objetivo principal é garantir que o projeto satisfará as exigências para as quais foi contratado. Consiste de planejamento, garantia e controle de qualidade. Gerência de Recursos Humanos: O objetivo principal é garantir o melhor

aproveitamento

das

pessoas

envolvidas

no

projeto.

Consiste

de

planejamento organizacional, alocação de pessoal e desenvolvimento de equipe. Gerência de Comunicação: O objetivo principal é garantir a geração adequada e apropriada, coleta, disseminação, armazenamento e disposição final das informações do projeto. Consiste do planejamento da comunicação, distribuição da informação, relatório de acompanhamento e encerramento administrativo. Gerência de Risco: O objetivo principal é maximizar os resultados de ocorrências positivas e minimizar as conseqüências de ocorrências negativas.

17

Consiste de identificação, quantificação, tratamento e controle de tratamento de riscos. Gerência de Aquisição: O objetivo principal é obter bens e serviços externos à organização executora. Consiste do planejamento de aquisição, planejamento de solicitação, solicitação de propostas, seleção de fornecedores, e administração e encerramento de contratos [PMI00]. Conforme já indicado, entre estas áreas de conhecimento está o Gerenciamento de Riscos, que é a área da Gerência de Projetos responsável pelos processos de identificação, análise e resposta aos riscos envolvidos num projeto. O risco possui três componentes: o evento; a probabilidade de ocorrência deste evento e o impacto que ele pode ter no projeto. O risco também possui algumas características que os diferem uns dos outros. Existem os riscos puros e os riscos de negócios. Risco puro é o risco que só traz perdas enquanto que o risco de negócio pode trazer perdas, mas também existe a chance dele trazer oportunidades de ganhos. Além destas características também se dividem os riscos em conhecidos e desconhecidos. Os conhecidos são os que nos permitem serem trabalhados, onde podemos estudá-los e nos antecipar aos seus eventos, podendo desta forma minimizar ou até mesmo evitar algum evento. Dessa forma podemos ver que a Gerência de Riscos nos traz um grande benefício que é o de maximizar os resultados dos eventos positivos e minimizar a conseqüência dos eventos adversos podendo inclusive eliminar a ocorrência de eventos desta natureza [PER99].

18

3

RISCO SOB A ÓTICA DE ALGUMAS METODOLOGIAS Cada modelo de Gerência de Projetos possui um objetivo específico e

é voltado para um determinado público. Assim sendo, mesmo que alguns modelos possuam objetivos e características semelhantes, a abordagem utilizada em alguns assuntos que são idênticos entre esses modelos pode ter um tratamento completamente diferente. Talvez por possuírem papéis e prioridades diferente, os riscos do projeto são tratados de forma bem singular em alguns modelos de gerenciamento de projetos. Em alguns, o assunto é tratado com muita atenção e análise e em outros é tratado superficialmente, não explicando exatamente o que deve ser feito, citando apenas o resultado final. Seja qual for o modelo utilizado, é sempre útil conhecer a abordagem de outros métodos, pois por mais que algumas pessoas e/ou instituições tenham trabalhado para desenvolver um padrão, ainda existe a possibilidade de algum assunto relevante para o seu projeto não estar sendo devidamente tratado. Segue uma análise sobre os riscos de um projeto de algumas metodologias bem conhecidas.

19

3.1 A ABORDAGEM DA NBR ISO/IEC 12207. A NBR ISO/IEC 12207 é uma norma brasileira que tem como objetivo estabelecer processos, atividades e tarefas a serem executadas durante os processos de aquisição, fornecimento, operação, desenvolvimento e manutenção de software e o seu público alvo são os compradores, fornecedores, operadores, desenvolvedores, mantenedores, gerentes, profissionais de qualidade e os usuários [ABN97]. Apesar da norma ser muito útil no que se refere à definição de processos e definição de estrutura e linguagem comum entre o seu público alvo, a norma deixa a desejar no que se refere ao gerenciamento de riscos. Não há nenhuma conceituação sobre o que são riscos ou os seus impactos no gerenciamento de um projeto. Para os compradores, a norma faz duas recomendações sobre riscos: Que antes de se escolher entre a aquisição de um novo software, ou o desenvolvimento interno de um novo software, ou a melhoria de um software já existente, ou até mesmo uma mescla entre estas opções, que se avalie os riscos envolvidos em cada uma destas escolhas; Que se faça e execute um plano de aquisição onde, além de outros itens, deve conter os riscos considerados assim como os métodos para gerenciá-los.

20

Para os fornecedores, ela faz apenas uma referência a riscos, a mesma destacada no primeiro item de recomendações feita aos compradores. As demais recomendações são para os processos organizacionais e apoio ao ciclo de vida, onde se alerta para possíveis riscos quanto à parte técnica, referentes à tecnologia de software utilizada, a complexidade do produto a ser desenvolvido ou a itens críticos de proteção e segurança.

Figura 1 – Organização da norma NBR ISO/IEC 12207 Fonte: [PROSD]

3.2 A ABORDAGEM DO SW-CMM O SW-CMM (Capability Maturity Model) é um modelo para medição da maturidade de uma organização de desenvolvimento de softwares que foi criado pelo SEI (Software Engineering Institute). O SW-CMM é baseado em cinco estágios de maturidade que vai do nível 1 (processo inicial), que é apenas um ponto de

21

referência e que teoricamente é onde o caos impera, até ao nível 5, que é o processo com melhoria contínua, também conhecida como Otimizado. Estes estágios são caracterizados pela existência (definição, documentação e execução) de determinados processos dentro da organização que são chamados de KPA's (Key Process Areas) [PAU93]. O CMM trata os riscos de um projeto com muito cuidado e atenção. Ele começa definindo os riscos de acordo com o dicionário americano Webster, que diz o seguinte: “Risk is the possibility of suffering loss”. Traduzindo, Risco é a possibilidade de sofrer perdas. Em um ambiente de projeto, uma perda significa um impacto direto na qualidade do produto final, no atraso do cronograma, num aumento de custos ou até mesmo na falha do projeto. O SW-CMM faz inúmeras referências a riscos em um projeto de desenvolvimento de software ao longo de sua metodologia, mas não trata de forma isolada o assunto. Contudo, ela faz referência a outros documentos específicos para gerenciamento de risco em projetos de desenvolvimento de software. Um destes documentos é o SRE (Software Risk Evaluation) que foi desenvolvido pelo SEI, mesma instituição que criou o SW-CMM.

22

3.2.1

SRE O SRE é uma metodologia para identificar, analisar e desenvolver

estratégias de mitigação para os riscos num ambiente de desenvolvimento de software [WPB99]. Além da definição de risco que o SW-CMM utiliza, o SEI define ainda um paradigma para gerenciamento de risco calcado nas seguintes áreas: Identificação; Análise; Planejamento; Acompanhamento/Monitoração; Controle; Comunicação. O SRE trabalha com as áreas de identificação, análise, planejamento e comunicação com o objetivo de criar uma visão dos riscos que podem afetar o projeto. Entre tantos benefícios, podemos destacar alguns: Cria uma visão compartilhada dos riscos entre as pessoas envolvidas com o projeto; Cria uma estrutura comum para falar sobre riscos e a mitigação dos riscos;

23

Cria uma “foto” de cada risco, isto é, tem uma visão com todas as informações para cada risco.

3.2.1.1

O Método SRE O SRE é implementado em cinco áreas conforme o esquema da Figura

2 que segue abaixo:

Figura 2 – Áreas do SRE Fonte: [WPB99]

Essas cinco áreas possuem uma compatibilidade muito grande com as áreas de gerenciamento de riscos do PMBOK, que é tratado no capítulo 3.3. De forma bem sucinta, segue uma descrição de cada área.

3.2.1.1.1

Contratação

Definido pelo próprio SEI como uma das áreas mais importantes, esta área tem como principais funções à de definir as expectativas do próprio gerente de projetos bem como as dos stakeholders1; deixar explícito o que será entregue no

1

Stakeholders são todos os interessados e envolvidos no projeto.

24

final do projeto, garantindo um acordo comum entre os stakeholders; garantir o patrocínio do gerenciamento do projeto e uma participação ativa e um suporte visível para as atividades de gerência de riscos; elaborar um acordo de trabalho entre o líder do time de SRE e o patrocinador que visa assegurar que o trabalho feito por ambas às partes sejam beneficiados e compartilhado da mesma forma; padronizar as medidas que serão utilizadas para as análises de exposição ao risco de acordo com o seu impacto e probabilidade. A Quadro 1 é um exemplo de uma tabela de referência para exposição de riscos.

Impacto 4 - Catástrofe 3 - Crítico 2 - Médio 1 - Negligenciável

Muito Provável Alto/6 Alto/5 Médio/4 Médio/3

Probabilidade Provavelmente Improvável Alto/5 Médio/4 Médio/4 Médio/3 Médio/3 Baixo/2 Baixo/2 Baixo/1

Quadro 1 – Exposição de Riscos Fonte: Adaptado de [WPB99]

3.2.1.1.2

RI&A (Identificação e Análise de Risco)

Nessa fase o time de SRE visita o ambiente de desenvolvimento para poder extrair informações relacionadas a riscos através de entrevistas estruturadas com os membros da equipe. As informações de risco são analisadas, priorizadas de acordo com o impacto no projeto, e agrupadas em áreas de risco e por fim, o time de SRE apresenta os resultados de todo esse trabalho para a equipe do projeto e gerentes envolvidos. As entrevistas são feitas obedecendo a um critério, formando assim um ciclo de entrevista de acordo com a Figura 3.

25

Figura 3 – Ciclo da Entrevista Fonte: [WPB99]

Passo 1: O entrevistador fará as perguntas exatamente como foram escritas (para assegurar consistência e manter um suspense intencional com a pergunta). Se a resposta à pergunta indicar que existe uma preocupação naquela área, então o entrevistador passará direto para o passo3. Passo 2: Se a pergunta do passo 1 não gerou nenhum assunto ou preocupação e se existir uma pergunta de acompanhamento para futuras investigações da área, então o entrevistador fará a pergunta exatamente como está escrita. Se mesmo assim não existir nenhum assunto que cause alguma preocupação, então o entrevistador volta para o passo 1 com outra pergunta.

26

Passo 3: O entrevistado colocará num formulário de riscos em branco as suas preocupações, conselhos e outras informações que julgar que sejam importantes. Passo 4: A pessoa responsável por registrar os riscos irá escrever em um flipchart (por exemplo), num formato de Condição-Consequência, para que todos os entrevistados possam ler. O entrevistado deverá confirmar se o que está escrito (no flipchart) é exatamente o que ele quis dizer. E por fim, os demais entrevistados são questionados se entenderam o assunto que foi levantado. Não é necessário que os entrevistado concordem com o risco levantado, mas que entendam o que o colega entrevistado quis dizer. Após estas confirmações, volta-se ao passo um até que se completem todas as perguntas ou se esgote o tempo para a entrevista, que não deve ultrapassar duas horas e meia.

3.2.1.1.3

Relatório Provisório

Nessa fase ocorre uma análise dos dados de saída da fase anterior (RI&A) sob o ponto de vista do relacionamento interno dos riscos com as áreas de risco. É feita uma recomendação ao gerente de projeto sobre os riscos que devem ser considerados no plano para a estratégia de mitigação (próxima fase, MSP) e após um acordo quanto às áreas de risco, a fase de MSP é agendada.

3.2.1.1.4

MSP (Plano para a Estratégia de Mitigação)

A fase de MSP tem como principal objetivo o de iniciar a estratégia para o desenvolvimento do plano de mitigação dos principais riscos (mais

27

importantes) que foram identificados durante a fase de RI&A. Isso será feito através de um trabalho conjunto entre a equipe do projeto, gerentes e o time de SRE, onde estes criarão as metas, estratégias e atividades para o desenvolvimento do MSP.

3.2.1.1.5

Relatório Final

Essa última fase tem como saída o relatório final, onde é feita uma consolidação dos dados resultantes das fases de RI&A e MSP. Os membros da equipe de SRE ajudam a escrever o relatório final que é por sua vez entregue pelo líder de equipe do SRE para o gerente de projetos e encerram-se as atividades da equipe de SRE.

3.2.2

Considerações finais sobre o CMM Apesar do método SRE ser bem trabalhado e cumprir com o seu

objetivo, que é o de trabalhar com as áreas de identificação, análise, planejamento e comunicação, o CMM não deixa claro em sua metodologia ou documentos de apoio, como serão tratadas as outras duas áreas do gerenciamento de projetos (segundo o seu próprio paradigma) que são o de acompanhamento/monitoração e controle. Dessa forma, sem uma metodologia padrão que oriente o gerente de projetos a conduzir essas duas áreas, o trabalho final de gerência de riscos ainda dependerá única e exclusivamente das habilidades e experiência do próprio gerente de projetos, que poderá fazer ou não um acompanhamento e controle dos riscos de forma adequada.

28

Uma das grandes contribuições que o CMM trouxe foi a de consolidar a importância da gerência de projetos para a engenharia de software [SALSD]. Contudo, já existe uma nova versão do CMM, o CMMI (Capability Maturity Model Integrated) onde a gerência de riscos ganha ainda mais destaque. O modelo CMMI é uma evolução do SW-CMM. No CMMI está definida uma área de gerência de projeto composta por seis áreas de processo: planejamento de projeto, acompanhamento

e

controle

de

projeto,

gerenciamento

de

acordos

com

fornecedores, gerenciamento integrado do projeto, gerenciamento de risco, e gerenciamento quantitativo de projeto [SALSD].

3.3

A ABORDAGEM DO PMBOK O PMBOK é reconhecido hoje em dia como uns das melhores

referências para gerenciamento de projetos e foi desenvolvido pelo PMI (Project Management Institute). O PMI foi fundado em 1969 como uma instituição sem fins lucrativos e está sediada na Filadélfia, Estados Unidos da América [PMISD]. Por ser uma metodologia de gerência de projetos que foi desenvolvida para qualquer tipo de projeto e devido à natureza de sua instituição, o PMBOK é um modelo que cobre todas as disciplinas, métodos e técnicas que fazem parte do universo da gerência de projetos e as melhores práticas dentro da área.

29

Figura 4 – Áreas de Conhecimento do PMBOK. Fonte: Adaptado de [PMISD]

O seu reconhecimento se tornou tão grande que se tornou um padrão americano pela American National Standards Institute (ANSI) que por sinal é o padrão no qual está se baseia a norma brasileira. Além da ANSI, o IEEE (Institute of Eletrical and Eletronic Engineers) também o reconheceu como padrão de gerenciamento de projetos e a está sendo utilizado como referência pela ISO (International Standards Organization) e por empresas que desenvolvem sua própria metodologia de gerenciamento de projetos. Embora já se tenham notícias da nova versão do PMBOK, a edição 2004 ainda não se encontra disponível. O que se sabe, através de fontes não oficiais (afiliados do PMI) é que a edição 2000 possui o mesmo número de processos (seis) na área de gerenciamento de riscos que a edição 2004. Talvez seja um indício de que haja poucas mudanças nessa área. Assim sendo, este estudo foi baseado na edição de 2000, a versão oficial e atual [SOTSD].

30

Os seis processos na área de gerenciamento de riscos são: Planejamento da Gerência de Risco; Identificação dos Riscos; Análise Qualitativa dos Riscos; Análise Quantitativa dos Riscos; Planejamento de Resposta a Riscos; Controle e Monitoração de Riscos. Estes processos têm como finalidade à identificação, análise e resposta aos riscos de um projeto e estes processos interagem entre si e entre as demais áreas de gerenciamento de projetos, conforme explicado na introdução. Os conceitos sobre o que são riscos já foram abordados no capítulo 2 e assim sendo, não serão novamente discutidos nesta seção, pois se trata da mesma definição. Quanto aos processos de gerenciamento de riscos, segue uma descrição de seu funcionamento [PMI00].

3.3.1

Planejamento da Gerência de Risco O processo de planejamento da gerência de risco é fundamental, pois

é nele que será decidido como serão abordados e tratados os riscos ao longo do projeto. Na figura abaixo são citadas algumas entradas para este processo. O Project Charter e o EAP (Estrutura Analítica do Projeto) são resultados de outra área de gerenciamento de projetos, a área de escopo.

31

Figura 5 – Visão do processo de Planejamento da Gerência de Risco Fonte: [PMI02]

Os demais itens de entrada são referentes a políticas e padrões da própria organização, as pessoas que são responsáveis por decidir cada assunto relacionado ao projeto e as definições de níveis de tolerâncias a risco que a organização tem. Após serem analisados os dados de entrada em reuniões com o gerente de projetos e os líderes de cada área de gerenciamento de projetos, chegase a um denominador comum, em forma de relatório, que é o plano de gerência de riscos, onde há descrição de como e com que pesos serão tratados cada um dos próximos processos da área de gerenciamento de risco. Este relatório não possui um formato pré-estabelecido, mas possui uma definição bem clara quanto aos dados que deve conter. Entre outras definições, o plano de gerenciamento de risco deve indicar: •

Qual a metodologia será utilizada;

32

•

As funções e responsabilidades de cada membro da equipe de gerenciamento de riscos;

•

O orçamento previsto para a equipe de gerenciamento de riscos;

•

Com que freqüência será executado o processo de gerenciamento de riscos;

•

As medidas que serão utilizadas para pontuação e interpretação, garantindo dessa forma a utilização das mesmas medidas durante todo o projeto;

•

Quais serão os níveis de tolerância a risco;

•

O formato e o conteúdo do plano de resposta a riscos (não é o plano em si, mas como será estruturado o plano);

•

A monitoração dos riscos.

Embora não exista uma definição quanto ao formato do relatório, o Quadro 2 é um exemplo de como seria um relatório, baseando-se nas recomendações do PMBOK. Onde: 1. Número que identifica o risco. Seqüencial iniciando em 1. 2. Descrição do risco.

33

3. Área do projeto que é afetado com esse risco. 4. Sintomas que possam indicar a possibilidade de ocorrência do risco. 5. A causa do risco e o impacto deste risco nos objetivos do projeto. 6. Pessoa ou departamento responsável pelo risco. 7. Quais as responsabilidades designadas e o prazo de conclusão para cada item relatado no campo 5. 8. Em qual data e qual foram às ações tomadas para cada risco. Isso inclui respostas acordadas, fuga, transferência, mitigação ou aceitação. 9. Quais

medidas

serão

tomadas

em

caso

responsabilidades e de ações. 1 - ID 2 - Descrição 3 - Área(s) 4 - Sintoma(s) 5 - Efeito e Impacto 6 - Responsável(eis) 7 - Responsabilidade e prazo 8 - Histórico (data e ação) 9 - Contingência Quadro 2 – Exemplo de Relatório de Riscos

de

falha

de

34

3.3.2

Identificação dos Riscos Esse processo, como o nome já diz, tem como função à identificação

de riscos que podem vir a afetar o projeto e documentar as principais características de cada risco.

Figura 6 – Visão do processo de Identificação dos Riscos Fonte: [PMI02]

Pode-se ver claramente através do diagrama acima a interação entre si dos processos e entre as áreas. O primeiro item de entrada para este processo é o item de saída do processo anterior. O segundo item é o resultado de saída das outras áreas de gerenciamento de projetos (conforme o modelo do PMBOK), como por exemplo, o Project Charter, a EAP, a descrição do produto, o cronograma e estimativa de custo, o plano de aquisição entre outros tantos planos. As categorias de riscos visam poder classificar os riscos por áreas, de acordo com o perfil de cada risco, como por exemplo, riscos técnicos, de qualidade, de desempenho, de gerência de projetos, organizacionais, externos e outros tantos quanto forem possíveis, desde que se aplique a área de negócio da organização e ao projeto em si.

35

Informações históricas são outros dados de entrada e que possuem um papel muito interessante. Baseado nas lições aprendidas de projetos passados pode-se ter novas identificações de riscos. Para que se possam identificar os riscos, existem técnicas de coleta de informações das mais variadas, que podem ser utilizadas em reuniões coletivas ou individuais. Técnicas amplamente utilizadas são as de brainstorming, Delphi, SWOT e entrevistas. Também podem ser desenvolvidos checklists para a identificação dos riscos com base em informações históricas. Além dos riscos envolvidos na execução do projeto, existem ainda os riscos envolvidos nas hipóteses e premissas utilizadas na definição do projeto. A análise de premissas é uma técnica que envolve a validação das premissas, evitando-se assim a execução de um projeto baseado em premissas irreais. Já as técnicas de diagramação podem incluir entre outros, o diagrama de fishbone, castas de fluxo de processo e diagrama de influência. O resultado de tanta análise é um documento com a relação de todos os riscos identificados com uma descrição do próprio risco e dos sintomas (gatilhos) que servem como sinais de advertência de que o risco aconteceu ou está preste a acontecer. Além da identificação dos riscos, pode ocorrer ainda a identificação de falha(s) em um ou mais planos de outras áreas, gerando então uma entrada para as outras áreas.

36

3.3.3

Análise Qualitativa dos Riscos O principal objetivo da análise qualitativa é o de avaliar o impacto e a

probabilidade dos riscos identificados e prioriza os riscos de acordo com o seu efeito potencial nos objetivos do projeto.

Figura 7 – Visão do processo de Análise Qualitativa dos Riscos Fonte: [PMI02]

Os dois primeiros itens de entrada são resultados dos processos anteriores e já foram abordados. Os itens de Situação do Projeto, Tipo do Projeto, Precisão de dados e Restrições são dados referentes ao momento em que se encontra o projeto e informações já utilizadas nos processos anteriores. Servem como apoio e base para a análise de probabilidade e impacto. Quanto ao item de Escala de Probabilidade e Impacto, essa escala será utilizada de acordo com as definições no plano de projeto, onde os dados de pesos e medidas foram definidos e servem justamente para garantir que os processos utilizem as mesmas unidades. Os dois primeiros itens da fase de Ferramentas e Técnicas são construídos baseados nas definições do plano de gerência de riscos de acordo com os pesos e medidas que foram previamente definidos. Exemplos de avaliação de

37

impactos nos objetivos do projeto e de uma matriz de probabilidade versus impactos do projeto são mostrados nos quadros Quadro 3 e Quadro 4 respectivamente. As saídas desse processo são listas de riscos prioritários e de riscos para análise, bem como a classificação do risco global para o projeto. Com a repetição dessas rotinas pode-se criar uma tendência nos resultados, provocando uma resposta aos riscos ou uma análise adicional.

Quadro 3 – Método de pontuação de impacto com abordagem ordinal Fonte: Adaptado de [PMI02]

Quadro 4 – Classificação do risco com abordagem cardinal de probabilidade x impacto. Fonte: Adaptado de [PMI02]

38

3.3.4

Análise Quantitativa dos Riscos O processo de análise quantitativa muitas vezes se confunde com o de

análise qualitativa. No entanto, enquanto que a análise qualitativa visa avaliar o impacto e a probabilidade dos riscos identificados, a análise quantitativa tem como objetivo analisar numericamente a probabilidade de cada risco e sua conseqüência nos objetivos do projeto. Mesmo assim, os processos de análise qualitativa e quantitativa podem ser utilizados em conjunto ou separadamente.

Figura 8 – Visão do processo de Análise Quantitativa dos Riscos Fonte: [PMI02]

Os primeiros cinco itens e o último item de entrada são resultados de saída de processos anteriores ou já foram discutidos, portanto não serão comentados novamente. O item de Avaliação Especializada é discutido em outra área da gerência de projetos, a de Escopo. Basicamente este tipo de avaliação é feito por pessoas que possuem elevado conhecimento em um determinado assunto e são consultados. Essas pessoas podem ou não fazer parte da equipe ou organização.

39

As técnicas utilizadas nesse processo são de entrevistas técnicas que visam quantificar a probabilidade e as conseqüências dos riscos nos objetivos do projeto, de análises de sensibilidade que tem como objetivo determinar quais são os riscos que possuem o maior potencial de impacto no projeto, de análise de árvore de decisão que permite uma visualização gráfica com valores para cada decisão tomada, facilitando o tomador de decisões, e de simulação, que normalmente utiliza a técnica de análise de Monte Carlo. Como saída temos um relatório com os riscos que possuem maior ameaça ou maior oportunidade para o projeto. Outra saída é um relatório com todas as previsões de cronogramas e resultados de custos prováveis do projeto e outro relatório com a probabilidade de se alcançar os objetivos do projeto.

3.3.5

Planejamento de Resposta a Riscos Esse processo tem como principal objetivo o de desenvolver opções e

determinar ações para ampliar as oportunidades e reduzir as ameaças aos objetivos do projeto. Todos os dados de entrada já foram tratados nos processos anteriores. Apesar de não haver nenhuma novidade quanto aos dados de entrada, esse processo consegue chegar a essa quantidade de informações de saída graças à análise conjunta de todas esses dados de entrada em conjunto com as técnicas de evitar o risco, onde o plano do projeto é modificado para garantir que o risco seja evitado, transferir o risco, quando a responsabilidade e as conseqüências do risco é transferida para uma terceira parte, a mitigação, que é a técnica de reduzir o máximo

40

possível à probabilidade do evento de risco ocorrer e se ocorrer, que a sua conseqüência seja a menor possível e a técnica de aceitação, que visa não fazer qualquer alteração no plano do projeto para lidar com um risco.

Figura 9 – Visão do processo de Planejamento de Resposta a Riscos Fonte: [PMI02]

Os resultados de tanta análise são diversas saídas. O plano de resposta aos riscos é um, onde entre outros, procura-se, sempre que possível, preencher com os seguintes dados: •

Riscos identificados, suas descrições a(s) área(s) do projeto afetado(s), suas causas e como eles podem afetar o objetivo do projeto;

•

Os responsáveis pelo risco e as responsabilidades designadas;

•

Resultados dos processos de análise qualitativa e quantitativa;

41

•

Respostas acordadas incluindo fuga, transferência, mitigação ou aceitação, para cada risco no plano de respostas a riscos;

•

Ações específicas para implementar a estratégia da resposta escolhida;

•

Orçamento e prazos para a resposta;

•

Planos de contingência e planos de reserva.

Outras saídas são os relatórios de riscos residuais e secundários onde respectivamente são tratados os riscos que permanecem depois das respostas de fuga, transferência ou mitigação ou os riscos que surgem como resultado direto de uma ação de resposta a um risco. Uma saída que também é muito utilizada, especialmente por departamentos comerciais, é a utilização de acordos comerciais, que visam préestabelecer a responsabilidade de cada parte mediante a ocorrência de algum risco específico. Quanto às saídas restantes, o próprio nome já indica o que são e já foram comentados nos processos anteriores.

3.3.6

Controle e Monitoração de Riscos É o processo que deve manter a rastreabilidade dos riscos

identificados, monitorar riscos residuais e identificar novos riscos, bem como

42

assegurar a execução dos planos de risco e avaliar a sua efetividade em redução dos riscos.

Figura 10 – Visão do processo de Controle e Monitoração de Riscos Fonte: [PMI02]

Os dois primeiros itens são resultados de processos anteriores e o terceiro e último item são resultados de processos de outras áreas de gerenciamento de projetos, a de comunicação e de escopo respectivamente. A Análise e Identificação de Riscos Adicionais ocorrem na medida em que o desempenho do projeto é medido e informado e potenciais riscos que previamente não foram identificados aparecem. Através da aplicação das técnicas relacionadas na Figura 10, teremos como resultado as seguintes saídas: •

Planos de workaround (contorno). É a documentação das respostas aos riscos que anteriormente foram aceitos ou que não foram identificados.

43

•

Ações corretivas. Consiste em executar o plano de contingência ou workaround.

•

Solicitações de Mudança no Projeto. Este tipo de documento visa solicitar a mudança no projeto em função da implementação dos planos de contingência ou workaround.

•

Atualizações no plano de resposta a riscos. Ao longo do projeto, os riscos previamente identificados podem vir a ocorrer, diminuir e até mesmo deixar de existir. Essas mudanças de probabilidade e ocorrência devem ser devidamente registradas.

•

Atualizações de checklist de identificação de risco e Banco de dados de risco são meios de proporcionar no futuro a consulta sobre dados históricos.

44

4 FERRAMENTAS DE GERENCIAMENTO DE RISCO São poucas as ferramentas disponíveis no mercado que auxiliam o gerenciamento de riscos. Esse capítulo tem como função fazer uma análise sobre algumas destas ferramentas.

4.1 PERTMASTER O pertmaster é uma ferramenta que pode importar os arquivos de gerenciamento de projetos do MS Project e do PRIMAVERA, que são as ferramentas mais conhecidas nessa área e fazer uma análise de risco do projeto ou até mesmo criar todo o projeto diretamente na própria ferramenta. A Figura 11 (pg.45) é uma amostra de um projeto sendo controlado através do Pertmaster. Através do registro de estimativas mínima, máxima e provável do tempo de cada tarefa, bem como a indicação da probabilidade da ocorrência de cada risco, podemos fazer o programa rodar uma análise dos riscos do projeto. A ferramenta procura dar a resposta para a pergunta de qual é a probabilidade de entregar o projeto no prazo.

45

Figura 11 – Gerenciamento de Projetos no Pertmaster

As figuras Figura 12 e Figura 13 (pg.46) são amostras de resultado de análise de risco em um projeto hipotético. Além da análise de risco relativa a tempo e probabilidade, há ainda a possibilidade de avaliar os riscos do projeto referentes ao custo do mesmo. A ferramenta é de fácil manuseio, intuitiva e conta com um bom tutorial para criação de novos projetos e criação e análise de riscos do projeto. A versão do produto analisado foi a 7.5.2.13, licença de avaliação.

46

Figura 12 – Gráfico de tempo por riscos

Figura 13 – Gráfico de tempo para o projeto

47

4.2 RISKTRAK O RiskTrak é uma ferramenta de Gerenciamento de riscos com suporte a múltiplos usuários que permite a todos que utilizam a ferramenta e que possuem as permissões de acesso, a visualização, análise, comunicação, criação de relatórios e gerenciar os riscos (custo, tempo e técnico) durante todo o projeto. O RiskTrak também pode importar o projeto de outras ferramentas. Ele importa os dados de projeto do MS Project e de qualquer outra ferramenta que tenha a possibilidade de exportar o projeto em um arquivo CSV. Este programa oferece algumas funcionalidades bem interessantes, como por exemplo, um questionário para medir os riscos do projeto atual. Ao criar o projeto, pode-se optar por criar um projeto novo, do zero, baseando-se apenas nas informações que o usuário da ferramenta possui ou pode-se criar projetos através de assistentes, que através de perguntas focadas em riscos, ajudam a definir a estrutura do projeto. Outra funcionalidade é a de poder gerar relatórios de status através de queries diretamente em sua base de dados, como pode ser visto na Figura 15 (pg.48) e a possibilidade de facilmente gerar diversos gráficos dos riscos do projeto no que se refere a tempo e custo. Um ponto muito forte da ferramenta é quanto à identificação, análise e mitigação do risco. A ferramenta oferece um editor de riscos que permite inúmeras atribuições ao risco, entre elas: custo, tempo, probabilidade, proporção, estratégia de mitigação, descrição completa do risco, fase do risco, classe, status, responsável, prazo para resolução e campo para comentário. Veja exemplo na Figura 16 (pg.49).

48

Figura 14 – Exemplo de uma Lista de Riscos no RiskTrak

Figura 15 – Query no banco de dados

49

Figura 16 – Exemplo de definição de risco no RiskTrak

A ferramenta é muito interessante e dá uma boa visibilidade dos conceitos e métodos de gerenciamento de risco. A versão utilizada para a análise da ferramenta foi a 4.50.03, versão de demonstração.

4.3 RISK+ O Risk+ é uma ferramenta que funciona de forma integrada com o MS Project. Visto que o gerenciamento de risco não é contemplado no MS Project, o Risk+ trabalha como uma ferramenta que visa suprir esta necessidade. Ao ser

50

instalado, o Risk+ inclui um menu no MS Project referente as suas ferramentas, conforme ilustrado na Figura 17.

Figura 17 – Integração do Risk+ com o MS Project

Contudo, o Risk+ é uma ferramenta focada apenas no controle de riscos envolvidos com o controle de tempo e de custos. As simulações que a ferramenta utiliza para quantificar o risco são baseadas na técnica de Monte Carlo. O Risk+ utiliza as informações de tempo e custo que foram definidas no MS Project para fazer as suas projeções, contudo, os campos são abertos para modificação de acordo com a percepção do usuário, como pode ser visto na Figura 18.

51

Figura 18 – Entrada de dados para análise de tempo e custo no Risk+

Após os ajustes (se necessário) para tempo e custo, pode-se rodar a ferramenta de análise. A Figura 19 é um exemplo do resultado desta análise.

Figura 19 – Resultado da análise de tempo no Risk+

A versão do Risk+ utilizado para esta análise foi a 2.0.

52

5 PROPOSTA DE GERENCIAMENTO DE RISCOS O modelo de gerenciamento de riscos propostos pelo PMBOK se destacou dos demais por ser um modelo que não é direcionado a um determinado público. Por ser uma metodologia de gerenciamento de projetos que se aplica a qualquer tipo de projeto, por ter sido criado baseando-se em práticas de mercado que tiveram sucesso comprovado, por ter sido definido como referência e, em alguns casos, como modelo padrão para gerenciamento de projetos por outros institutos de reconhecimento nacional e internacional, como, por exemplo, a ANSI, IEEE e a ISO, e por não ter motivos para se re-inventar a roda, é que o PMBOK foi escolhido como metodologia base para ser aplicada no estudo de caso. Para possibilitar a aplicação da metodologia do PMBOK num ambiente de infraestrutura de TI, fez-se necessário desenvolver um protótipo de ferramenta que atenda os requisitos e processos do gerenciamento de riscos desta metodologia. Assim sendo, algumas ferramentas de apoio foram escolhidas para auxiliar estas fases de desenvolvimento. Duas ferramentas da Borland foram

53

escolhidas, uma para criar a modelagem em UML do protótipo e a outra para o desenvolvimento do software. A ferramenta de modelagem da Microsoft também foi utilizada para dar apoio à fase de modelagem. Segue a relação das ferramentas utilizadas: •

Borland Delphi Enterprise Trial – Versão 7.0 (Build 4.453);

•

Borland Model Maker Demo – Versão 6.20 (Build 1402);

•

Microsoft Visio Professional 2002 SR-1.

5.1 MODELAGEM DO PROTÓTIPO A metodologia de gerenciamento de riscos do PMBOK é muito rica de informações e já foi bem referenciada no capítulo 3.3 e, portanto, não será novamente discutida aqui. No entanto, com o intuito de extrair os principais processos da metodologia, faz-se necessário entrar novamente na metodologia para tirar um “raio x” de sua estrutura principal. Para que o protótipo venha a ter condições de suportar a metodologia, é necessário que os principais processos da metodologia sejam corretamente representados dentro da ferramenta. São seis os processos e, o resultado de cada um serve de entrada para o próximo. São eles: •

Planejamento da Gerência de Risco;

•

Identificação dos Riscos;

54

•

Análise Qualitativa dos Riscos;

•

Análise Quantitativa dos Riscos;

•

Planejamento de Resposta a Riscos;

•

Controle e Monitoração de Riscos.

Esse é o “raio x” da metodologia de gerenciamento de riscos escolhida e que serviu de norte para o desenvolvimento do protótipo. Visto que existem diferentes papéis no que diz respeito a gerência de riscos, fez-se necessário distinguir os diferentes tipos de usuários do protótipo. Num primeiro nível estaria o gerente do projeto e em outros níveis os Stakeholders. Além desta distinção, existe ainda a distinção entre os membros do projeto, pois alguns podem estar apenas acompanhando o projeto e outros muito mais envolvidos, colaborando nas diversas fases do mesmo. Assim sendo, surgiu a necessidade de diferenciar os tipos de acessos de cada participante do projeto.

Figura 20 – UML Use Case – Visão Macro

55

Numa visão macro, o sistema deve possibilitar ao gerente de projetos a manutenção do(s) seu(s) projeto(s), riscos e usuários que fazem parte da sua equipe de trabalho. Os membros do projeto passam a ter acesso às informações do projeto e os riscos envolvidos no mesmo, de acordo com seu perfil (classe) de usuário. Surgiu também a visão de um administrador da ferramenta, que seria o responsável por criar as contas dos gerentes de Projetos. A Figura 20 (pg.54) exemplifica melhor esta visão. Para entender melhor a proposta, vamos expandir a visão para cada uma das funcionalidades do protótipo. Por ordem de funcionalidade, vamos analisar a visão “Definir Usuários”, como é ilustrado na Figura 21. Existem apenas dois perfis de usuários que teriam acesso a essa funcionalidade, o usuário administrador e o gerente. O usuário administrador pode criar usuários e suas principais funções seriam a de atribuir ao usuário o perfil de gerente de projeto e também excluir usuários da ferramenta. O usuário com perfil de gerente de projeto tem acesso completo em todas as atividades de seu projeto, diferente do que ocorre com um membro do projeto. Porém, o administrador não tem o poder de definir a qual projeto o usuário irá pertencer e tão pouco apontar o papel dele no projeto. Esse é um papel que só diz respeito ao perfil de gerente do projeto. Para a criação de usuários, são necessárias algumas informações básicas, como por exemplo, nome do usuário, telefone, e-mail entre outras. Isso está representado no diagrama através da função de “Incluir Informações do Usuário”.

56

Figura 21 – UML Use Case – Visão “Definir Usuários”

Outra função representada no diagrama é o de atribuir um login e senha para o usuário. Apesar da metodologia não fazer nenhuma menção a tipos de usuários, existe sim a distinção do Gerente do Projeto e dos demais membros do mesmo. Existe ainda uma referência aos papéis de cada membro da equipe no projeto. Portanto, para representar essa hierarquia e ao mesmo tempo para tornar os dados do projeto mais seguro, fez-se esta classificação. Essa distinção de usuários se torna ainda mais perceptível quando expandimos a visão “Manter Riscos”, conforme ilustrado na Figura 23 (pg.60). O membro do projeto terá o acesso às informações que o seu perfil de usuário permitir.

57

Os níveis de acesso foram classificados em “Simples”, “Colaborador” e “Avançado”. O perfil de acesso “Simples” é o mais básico de todos. Só permite a visualização dos riscos. O acesso de “Colaborador” só libera o acesso aos riscos, mas este por sua vez já possui a liberdade de fazer alterações, adicionar e remover riscos. Por fim, o perfil de usuário “Avançado” permite total liberdade de ação na área de riscos e ainda permite visualizar todas as informações referentes ao projeto. Na visão “Manter Projeto”, conforme ilustrada na Figura 22 (pg.59), temos toda a estrutura do projeto. É lá que serão inseridas as informações gerenciais do projeto. O primeiro (um dos mais trabalhosos para o gerente de projetos) dos seis processos, o Planejamento da Gerência de Riscos, está caracterizado de forma bem explícita nessa modelagem. Se olharmos a metodologia com atenção, veremos que este processo é um dos mais importantes e de maior volume de informações. Por se tratar do processo inicial e de planejamento de toda a gerência de riscos, ele teve um destaque especial no protótipo. Assim sendo, as seguintes funções do primeiro processo foram atribuídas ao protótipo: descrição do projeto; a forma com que os riscos serão lidados e conseqüentemente a tolerância aos riscos; a metodologia que será utilizada ao longo do projeto; a definição do orçamento para a gerência de riscos; escolha dos membros da equipe, seus papéis e permissões. A definição da matriz de impacto embora também seja ligado ao planejamento da gerência de riscos está totalmente relacionada a outros dois processos, o de “Análise Qualitativa” e “Análise Quantitativa”, servindo como base para os cálculos e análises realizados nestes processos.

58

Três dos seis processos principais da gerência de riscos já foram abordados na modelagem até aqui. Para entender como os outros três processos são suportados no protótipo, vamos focar as atenções na visão “Manter Riscos” que está representada na Figura 23 (pg.60). Embora muitas funções são utilizadas em mais de um processo, isto é, são utilizadas explicitamente num processo e servem como apoio e tomadas de decisão nos outros processos, vamos procurar separar as funções para que se possa ter uma visibilidade dos processos da metodologia. A função de descrever o risco faz parte do processo de “Identificação do Risco”. Embora as funções relacionadas ao risco, como por exemplo “Indicar a Área Afetada” e “Descrever os Sintomas dos Riscos” possam parecer que fazem parte do processo de “Identificação dos Riscos”, elas não fazem. Estão relacionadas com o processo de “Planejamento de Resposta a Riscos” que além destas funções ainda possui outras, como por exemplo, a função de “Atribuir Responsabilidades”.

59

Figura 22 – UML Use Case – Visão “Manter Projeto”

60

Figura 23 – UML Use Case – Visão “Manter Riscos”

61

Outras funções fazem parte desse processo, mas se fundem com os processos de “Análise Qualitativa” e “Análise Quantitiva” como por exemplo, as funções “Definir Ações de Mitigação ou Contingência”, “Determinar o Impacto no Projeto”, “Determinar a Probabilidade“ e “Determinar o Impacto no Objetivo do Projeto. Por fim, o processo de “Controle e Monitoração de Riscos” está caracterizado através da função de ”Acesso Histórico de Aç ões”, contudo, não fica restrito a apenas esta função, uma vez que a ferramenta permitirá alterações nas informações dos riscos ao longo do projeto como, por exemplo, a mudança de status do risco, de impacto e criticidade. Estas visões podem parecer um tanto quanto confusas. Existem funções servindo para mais de um processo e ações que são o resultado da saída de um ou mais processos e, todas, sendo exibidas em uma única modelagem. Embora a modelagem dê margem para tal interpretação (confusão), ela passa a ser muito clara no momento que os processos da metodologia de gerenciamento de riscos são bem conhecidos, pois a própria metodologia força uma interação entre os processos, criando um ciclo que só terminará quando o projeto for concluído. Levando em conta o resultado obtido com a modelagem de “Use Case” proposta, o próximo passo foi de modelar as classes do protótipo. A Figura 24 (pg.62) é o resultado final do diagrama de classes em UML. A classe “Projeto” se tornou a principal classe em virtude de todas as atividades estarem relacionadas ao projeto. Ou seja, não há riscos ou pessoas gerenciando riscos sem que estes estejam alocados a um projeto.

62

Existe ainda uma herança no diagrama, a classe “Membro” herda as propriedades da classe “Pessoa” e o relacionamento da classe “Membro” com a classe “Projeto” gera uma outra classe, que é a de “Permissões”. Nesse relacionamento estará definido que tipo de acesso cada usuário terá nas informações de cada projeto. Tendo em vista que o diagrama de classes é auto-explicativo e que o diagrama de “Use Case” já explicou os objetivos de funcionalidade do protótipo, o próximo passo é o de desenvolvimento do protótipo.

Figura 24 – UML Diagrama de Classes

63

5.2 DESENVOLVIMENTO DO PROTÓTIPO Tendo em vista que todo o planejamento do protótipo já foi feito e explicado nas sub-seções anteriores, vamos ver agora como foi desenvolvido o protótipo. Como um dos itens modelados estava relacionado diretamente aos perfis de usuários e suas permissões de acesso nos projetos, a primeira tela teria que ser a de login (veja Figura 25). Tendo em vista que é necessário ter pelo menos um usuário com permissões para criar outros usuários, o usuário padrão do protótipo é o administrador. O usuário administrador terá o poder de criar novos usuários e definir se o usuário terá o perfil de “Gerente”, ou seja, o responsável por gerenciar os riscos de cada projeto.

Figura 25 – Protótipo – Login

64

Após o logon, os menus de “Projetos” e “Usuários” se tornam disponíveis para os gerentes de projetos e no caso dos stakeholders, apenas o menu de “Projetos”.

Figura 26 – Protótipo – Administração de Contas de Acesso

Caso o gerente de projetos queira adicionar novos membros a sua equipe, ele terá que acessar o menu usuários. Nesta tela o gerente terá a possibilidade de adicionar, remover e até mesmo editar as informações de um membro do projeto (veja todas as informações na Figura 26). No menu de projetos existe a possibilidade de criar um novo projeto ou de selecionar um previamente cadastrado conforme ilustrado na Figura 27, pg.65. Nessa tela é possível ter uma visão macro do projeto.

65

Figura 27 – Protótipo – Seleção do Projeto

Uma nova tela com acesso as informações do projeto e a lista dos riscos será exibida após a seleção do projeto que se deseja trabalhar (veja Figura 28, pg.66). Essa tela é muito interessante para o gerente de projetos, pois o mesmo tem uma visão macro dos riscos envolvidos no projeto e, através dos campos de “probabilidade” (a probabilidade de o risco vir a ocorrer) e “criticidade” do risco, tem ainda informações gerenciais que servem de apoio para tomadas de decisão. A informação de “criticidade” não é uma informação imputada pelo gerente de projetos e tão pouco pelos stakeholders. Essa informação é gerada automaticamente pelo protótipo através do cruzamento de informações previamente imputadas. O cruzamento é feito com a probabilidade de ocorrência do risco versus o impacto que este mesmo risco tem nos objetivos principais do projeto.

66

Após este cruzamento o resultado é comparado com uma tabela, modelo do PMBOK, onde é definido o valor de criticidade do risco que pode ser baixo, moderado ou alto.

Figura 28 – Protótipo – Lista de Riscos do Projeto Selecionado

Se selecionarmos o botão de “Informações” que está na área “Projeto” da Figura 28, uma nova tela será exibida com informações relacionadas ao planejamento da gerência de riscos conforme ilustra a Figura 29, pg.67. Nesta tela o Gerente de Projetos terá o espaço para registrar todas as informações gerenciais do projeto. Fará a descrição detalhada do projeto, definirá qual será a linha para a tolerância aos riscos e terá acesso as demais funções gerenciais.

67

Se o gerente quiser definir os membros de sua equipe para o projeto em questão ele irá clicar no botão “Membros” e a tela ilustrada na Figura 30, pg.68, será exibida. Uma vez definidos os membros do projeto o gerente deverá atribuir as permissões de acordo com uma das classes de permissão disponíveis através do botão “Permissões” na tela de projetos. Na nova tela (Figura 31, pg.68) o gerente irá escolher o membro da sua equipe e irá atribuir um dos três níveis de acesso2 disponíveis para os stakeholders que são: simples, colaborador e avançado.

Figura 29 – Protótipo – Planejamento do Projeto

A descrição da metodologia que será utilizada para as reuniões com os stakeholders e demais atividades voltadas a levantar as informações de riscos está disponível através do botão “Metodologia” na tela de projetos. O gerente também poderá incluir referências a documentos de apoio ao projeto (Figura 32, pg.69).

2

A explicação detalhada encontra-se na seção 5.1 onde é explicado a Figura 21 – UML Use Case – Visão “Definir Usuários”

68

Figura 30 – Protótipo – Definição de Membros

Figura 31 – Protótipo – Atribuição de Permissões

69

Figura 32 – Protótipo – Definição da Metodologia e Documentos de Apoio

Ainda na tela de projetos (Figura 29, pg.67), o gerente terá a possibilidade de criar a sua matriz de impacto através do botão de mesmo nome. Conforme já explicado, será através do cruzamento das informações da matriz de impacto (Figura 33, pg.70) com a probabilidade que será gerada a informação de criticidade. As informações referentes ao orçamento do projeto são definidas a partir da tela de projetos, no botão “Orçamento”. O gerente terá o espaço para informar qual é o orçamento previsto para a gerência de riscos, a previsão real de gastos (sem margens) e o valor que realmente foi gasto até o momento (veja Figura 34, pg.70).

70

Finalizando a tela de projetos, o gerente poderá definir funções e responsabilidades em nível de projeto, como pode ser visto na Figura 35, pg.71.

Figura 33 – Protótipo – Definição da Matriz de Impacto

Figura 34 – Protótipo – Especificação do Orçamento da Gerência de Riscos

71

Figura 35 – Protótipo – Definição de Responsabilidades no Projeto

Ao fechar a tela de projetos, o protótipo volta para a tela inicial, exibindo o projeto que foi selecionado e a lista de riscos registrados para aquele projeto (Figura 28, pg.66). O usuário do sistema (de acordo com seu perfil de acesso) poderá acrescentar, editar ou remover um ou mais riscos do projeto. Para entender melhor como funciona o protótipo, vamos pegar o primeiro item da lista de riscos como exemplo (Figura 36, pg.74). Todas as informações relacionadas ao risco estão disponíveis na mesma tela e por se tratar de uma tela de suma importância para o correto funcionamento do protótipo, vamos explicar cada campo. A tela está dividida em duas áreas. A primeira, denominada de “Informações” contém a identificação do risco em si e a segunda, denominada de “Responsabilidades” está relacionada a todas as tarefas/ações que foram planejadas e/ou executadas para o risco em questão. A seguir, a descrição dos campos das duas áreas.

72

•

Descrição: É identificação do Risco. Uma situação que pode vir a prejudicar o projeto.

•

Área Afetada: São as áreas da empresa e/ou do projeto que serão afetadas caso o risco ocorra.

•

Sintoma: Este espaço é destinado aos eventos típicos que ocorrem antes do risco em questão se tornar realidade, auxiliando desta forma a prever a ocorrência do mesmo.

•

Efeito / Impacto: Para registrar os possíveis efeitos do risco no projeto e os principais impactos do mesmo caso o risco ocorra.

•

Probabilidade: A probabilidade é uma informação que depende muito da sensibilidade dos membros do projeto e do conhecimento histórico nas atividades envolvidas ao risco. Seus valores variam entre Muito Baixo, Baixo, Moderado, Alto e Muito Alto. Estes valores conceituais estão atrelados a uma tabela com valores numéricos (0.1, 0.3, 0.5, 0.7 e 0.9) que será utilizada para cruzar as informações com os valores selecionados da matriz de impacto.

•

Objetivo no Projeto / Impacto no Objetivo: Define qual é o objetivo do projeto e o tamanho do impacto que é causado caso o risco ocorra. Os valores que estão disponíveis para escolha são os valores atribuídos na matriz de impacto. A matriz de impacto possui valores conceituais, que variam de “Muito Baixo” até “Muito Alto”.

73

Contudo, cada valor conceitual possui um valor numérico atrelado de acordo com a coluna que ele está associado (0.05, 0.1, 0.2, 0.4 e 0.8). Dessa forma, é possível fazer o cálculo, cruzando os valores de probabilidade com os valores de impacto do risco. O sistema, através de um modelo proposto pelo PMBOK, atribui um conceito de criticidade ao risco que pode ser “Baixo”, “Moderado” e “Alto”. •

Responsável: É a pessoa (membro do projeto) que será responsável por uma ação relacionada ao risco.

•

Prazo de Conclusão: Serve para atribuir uma data limite para a execução da ação que foi atribuída ao membro do projeto.

•

Ação: É a descrição da tarefa que foi designada ao membro do projeto.

•

Tipo de Ação: Segundo o PMBOK, uma ação pode ser do tipo “Mitigação”, isto é, uma ação que é executada com o intuito de minimizar os impactos do risco nos objetivos do projeto ou pode ser de “Contingência”, isto é, uma espécie de plano B, se o risco vier a ocorrer essa ação será tomada para remediar o problema.

•

Status: Este campo é para dar o devido acompanhamento e monitoração as ações relacionadas ao risco. A ação pode estar engatilhada, atrasada, agendada ou já estar executada.

74

•

Histórico: O botão de histórico não permite qualquer tipo de edição. Serve tão somente para ter visibilidade de todas as mudanças que ocorreram com o risco. Seu papel é registrar os valores anteriores a mudança e os novos valores para cada campo da tela de Riscos, informando quem fez a alteração e a data de modificação (Figura 37, pg.75).

Figura 36 – Protótipo – Administração de um Risco

75

Figura 37 – Protótipo – Histórico de Mudanças de um Risco

5.3 RESULTADOS OBTIDOS Tendo em vista a metodologia de gerenciamento de riscos adotada (PMBOK) e que o que a proposta de desenvolvimento seria um protótipo e não um sistema de gerenciamento de riscos efetivamente, o protótipo contribuiu bastante para demonstrar as funcionalidades e as vantagens que uma ferramenta efetiva de gerenciamento de riscos pode trazer tanto para o projeto quanto para o gerente de projetos. Por se tratar de um protótipo e não de uma ferramenta, não foi possível testar o seu uso de forma real dentro de um projeto em alguma empresa. Apesar dos dados relacionados nas telas do protótipo não configurarem um ambiente de produção real, eles espelham informações pertinentes a projetos reais de infra-

76

estrutura de TI, permitindo dessa forma uma visão clara da aplicação do protótipo para este fim. Mesmo assim, o protótipo foi demonstrado para algumas pessoas da empresa Dell Computadores com o intuito de ter uma opinião sobre uma futura utilização de uma ferramenta que siga os moldes do protótipo. As opiniões foram unânimes em apontar que existe uma deficiência de ferramentas que apóiem a metodologia do PMBOK para gerenciamento de riscos. O protótipo, de maneira geral, foi bem recebido. Varias sugestões de melhorias foram relatadas, as quais poderiam configurar melhorias e extensões no trabalho desenvolvido, como por exemplo: o calculo automático do custo do risco para o projeto, a definição de uma área exclusiva para riscos de negócio, a substituição de alguns campos descritivos por valores previamente cadastrados que facilitariam o trabalho de levantamento de métricas. Segue abaixo o relato do Sr. Alexandre Lima, coordenador de InfraEstrutura de TI na unidade do GDC (Global Development Center) da Dell Computadores. E-mail para contato: [email protected] “Uma de minhas funções na Dell, seja suportando a infraestrutura do Centro de Desenvolvimento de Software da Dell (GDC) ou a fábrica no Brasil e escritórios no Chile e na Argentina, é o gerenciamento de projetos de infra-estrutura, ou seja, abrangendo as áreas de telecomunicações, cabeamento, redes, servidores, sistemas de segurança e estrutura física predial. Este conjunto tão grande de áreas gera uma quantidade muito grande de variáveis a serem

77

analisadas e consideradas quando estou na fase de planejamento de um projeto. O sucesso do projeto estará sempre diretamente ligado ao máximo de alternativas, contingências e projeções feitas em cima de todas as ações que antecedem a fase de implementação de um projeto. Assim sendo, um dos pontos principais e mais críticos no planejamento de meus projetos é a análise de riscos. Analisando o protótipo da farramenta, pude perceber alguns aspectos bastante relevantes para meu trabalho. Dentre estes aspectos, gostaria de salientar dois que no meu ponto de vista são de grande importância: 1) O Centro de Desenvolvimento de Software da Dell é uma organização CMM Nível 2 e a metodologia PMBOK de Gerenciamento de Riscos, nítidamente servindo de base ao protótipo, vêm de encontro a todos os padrões de trabalho já definidos pela organização. 2) A ferramenta auxilia na identificação de criticidade dos riscos. E é neste aspecto que visualizo a principal aplicação desta ferramenta no meu trabalho e como a mesma poderia ser útil no planejamento de meus projetos. Isto porquê, diferentemente de um projeto de software desenvolvido internamente, um projeto de infraestrutura está norteado por diversas variáveis, muitas vezes externas à organização, como fornecedores e prazos de entrega, desacordos comerciais, condições climáticas para execução de trabalhos externos, oscilações de preço e câmbio entre outros. Assim, com uma ferramenta nos moldes propostos, eu teria melhor visibilidade dos riscos do meu projeto e o quanto cada um pode impactar nos meus objetivos finais”.

78

6 CONCLUSÃO As estatísticas nos mostram que o grande culpado pelos maus resultados de um determinado trabalho, ao contrário do que normalmente se imagina, não é a tecnologia envolvida na criação do produto, mas sim na forma com que este produto foi projetado, constatando-se assim que o fator determinante para o sucesso do projeto é a utilização de uma metodologia para gerenciamento de projetos. Baseando-se em todos os conceitos de risco, de gerenciamento de risco e de ferramentas de gerenciamento de risco que foram aqui estudados, analisados e comentados, o PMBOK foi escolhido como a metodologia de gerenciamento de riscos mais completa, tendo ainda o mérito de não ter um público alvo, servindo a qualquer atividade que se caracterize como um projeto. Os riscos envolvidos nos projetos sempre são um fator de grande preocupação e de difícil análise. Os benefícios da prática do gerenciamento de riscos ficaram bem claros, pois além da possibilidade de evitar o risco através da identificação e da criação de um plano de resposta a todos os riscos que podem vir a prejudicar os objetivos do projeto, existe ainda a possibilidade de se identificar riscos

79

de negócio, ou seja, que se forem bem tratados, podem trazer benefícios para a organização. O objetivo do protótipo era o de instrumentalizar através de uma ferramenta de apoio os principais processos de gerenciamento de riscos propostos pelo PMBOK. Apesar de conceitualmente poder ser aplicado a qualquer área de projetos, o protótipo foi exemplificado com projetos específicos da área de infraestrutura de TI, visando apresentar um modelo de gerência de riscos aplicado a esta área. Algumas automatizações e melhorias devem ser conduzidas para a implementação do protótipo, porém o mesmo pode servir de base para validação do processo de gerência de riscos em qualquer área de aplicação. Deixo ainda a sugestão, para os colegas que por ventura queiram no futuro propor extensões deste trabalho ou que venham a atuar com trabalhos correlatos que uma boa oportunidade seria a implementação de algum mecanismo de integração com o Microsoft Project ou outras ferramentas de Gerenciamento de Projetos, integrando a base de dados de projetos e possibilitando o uso efetivo desta ferramenta proposta como uma ferramenta complementar no gerenciamento de projetos.

REFERÊNCIAS E OBRAS CONSULTADAS [ABN97] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207/1997: Processos de Ciclo de Vida de Software. Rio de Janeiro: ABNT, 1997. [CES03] - CESAR, Genilson. Engenharia do software em evolução. e-Manager, [s.l.], p. 12-3, Maio 2003. [DIN03] - DINSMORE, Paul C. Project Management in Action: Education Foundation Practices What It Preaches. PMI Today, News and Views of the Project Management Institute. Newtown Square, p. 2, Agosto 2003. [FIO98] - FIORINI Soeli et al. Engenharia de Software com CMM. São Paulo: Brasport, 1998. [ISO97] - Tecnologia de Informação – Processos de Ciclo de vida de software. Disponível em: http://www.abntdigital.com.br/ [MAC01] – MACHADO, Cristina A. F.; BURNETT, Robert C. Gerência de Projetos na Engenharia de Software em Relação às Práticas do PMBOK. [s.l.]: [s.ed.], 2001.

[PAU93] – PAULK, Mark C. et al. Key Practices of the Capability Maturity Model. Pittsburgh: SEI, 1993. Disponível em:

http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.025.html [PER99] – PEREIRA, Lauro Zanforlin Alves. I Encontro Mineiro de Gerenciamento de Projetos. [s.l.]: PMI-MG, 1999. Disponível em: http://ww.pmimg.org.br/ppt/RiscoSitePMIMG.ppt [PMI00] - PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge: PMBOD Guide 2000 Edition. Newtown Square: Project Management Institute Inc., 2000. [PMI02] - PMI-MG. Tradução livre do PMBOK 2000. Belo Horizonte: PMIMG, 2002. [PMISD] - PMI-RS. Metodologias e Práticas de Gerenciamento de Projetos. Apresentação em sala de aula disponibilizada através de arquivo PDF. [PRA99] - PRADO, Darci. Gerência de Projetos em Tecnologia da Informação. [s.l.]: DG, 1999. [PROSD] - PROCERGS. Qualidade de software: Visão Geral. Apresentação em sala de aula disponibilizada através de arquivo de MS Power Point. [QUA02] - QUADROS, Moacir. Gerência de Projetos de Software. [s.l.]: Visual Books, 2002.

[SALSD] - SALVIANO, Clenio F. Contribuições da Melhoria de Processo e Gerência de Projetos: Transformando

Boas Idéias em Resultados. [s.l.]: [s.ed.], [s.d.].

Disponível em: http://www.bfpug.com.br/islig-rio/Downloads/Contribuicoes_da_Melhoria_de_Processos.pdf

[SIL03] - SILVERSTEIN, Ken. Closing the Circuit. PM Network, Newtown Square, p. 40-4, Agosto 2003. [SOTSD] - SOTILLE, Mauro. Um novo paradigma em Gerenciamento de Projetos. PMI-RS. Apresentação em sala de aula disponibilizada através de arquivo de MS Power Point. [WPB99] – WILLIAMS, Ray C.; PANDELIOS, George J.; BEHRENS, Sandra G. Software Risk Evaluation (SRE) Method Description (Version 2.0). Pittsburgh: SEI, 1999.

GLOSSÁRIO Brainstorming – É uma técnica muito utilizada para a identificação de riscos que tem como objetivo obter uma lista de riscos compreensível, que pode ser endereçada mais tarde nos processos de análise qualitativa e quantitativa. Delphi – Esta técnica é uma maneira de encontrar um consenso entre os especialistas em um determinado assunto que participam anonimamente. Um facilitador usa um questionário para solicitar idéias sobre riscos importantes do projeto. As respostas são apresentadas e então circuladas entre os especialistas, para comentários adicionais. Benefícios desta técnica são de possibilitar a redução dos desvios nos dados e elimina o poder de influência das pessoas no grupo, visto que os especialistas participam de forma anônima. EAP – Estrutura Analítica do Projeto é um agrupamento de componentes de projeto que organiza e define o escopo total do projeto. É um dos resultados de saída de um processo da gerência de escopo, de acordo com a definição da metodologia do PMBOK. KPA – Key Process Areas. É uma definição dos processos mais importantes que devem ser executados em cada um dos níveis de maturidade do CMM.

Monte Carlo – É uma técnica de análise que executa várias vezes uma simulação do projeto com o intuito de calcular e apontar os valores mais prováveis de ocorrer. MSP – Mitigation Strategy Plan. É o processo que defini o plano para a estratégia de mitigação dos riscos das metodologias do SRE e SW-CMM. Planos de workaround – Workaround significa contorno. É a documentação das respostas aos riscos que anteriormente foram aceitos ou que não foram identificados. PMBOK – Project Management Body of Knowledge. É o método de gerenciamento de projetos desenvolvido pelo PMI e que se baseia em nove áreas de gerenciamento. PMI – Project Management Institute. Instituição que desenvolveu o PMBOK. Project Charter – É um documento que autoriza formalmente o projeto. É um dos resultados de saída de um processo da gerência de escopo, de acordo com a definição da metodologia do PMBOK. RI&A – Risk Identification & Analysis. É o processo de identificação e análise do Risco que faz parte das metodologias do SRE e SW-CMM. SEI – Software Engineer Institute. Instituto que desenvolveu a metodologia SWCMM.

SRE – Software Risk Evaluation. É uma metodologia utilizada pelo SW-CMM que visa a identificação, análise, planejamento e comunicação com o objetivo de criar uma visão dos riscos que podem afetar o projeto. Stakeholders – É um termo inglês que se refere a todos as pessoas que estão interessadas ou envolvidas no projeto. SW-CMM – Capability Maturity Model. Metodologia para gerenciamento de projetos voltada para os desenvolvedores de software. Foi desenvolvido pelo SEI. SWOT – É uma técnica de análise de riscos. A sigla vem da abreviação de um termo em inglês (strengths, weaknesses, opportunities and threats) e significa que é uma análise de forças, fraquezas, oportunidades e ameaças.