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
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 ... 153 RISCO SOB A ÓTICA DE ALGUMAS METODOLOGIAS... 18
3.1 A ABORDAGEM DA NBRISO/IEC12207... 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.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
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 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
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
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.
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;
• 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 re-trabalho é 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;
• 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
O
BJETIVOS
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.
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;
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.
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.
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].
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.
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.
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
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.
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;
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
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.
Muito Provável Provavelmente Improvável
4 - Catástrofe Alto/6 Alto/5 Médio/4
3 - Crítico Alto/5 Médio/4 Médio/3
2 - Médio Médio/4 Médio/3 Baixo/2
1 - Negligenciável Médio/3 Baixo/2 Baixo/1
Probabilidade Impacto
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.
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.
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
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.
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.
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].
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.
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, chega-se 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:
• 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.
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 de falha de 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 --
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.
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.
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
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]
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.
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
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;
• 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
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.
• 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.
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
P
ERTMASTER
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.
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.
Figura 12 – Gráfico de tempo por riscos
4.2
R
ISKTRAK
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).
Figura 14 – Exemplo de uma Lista de Riscos no RiskTrak
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
R
ISK
+
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
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.
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+
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
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
M
ODELAGEM DO
P
ROTÓ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;
• 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.
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”.
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.
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.
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”.
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.
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.
5.2
D
ESENVOLVIMENTO DO
P
ROTÓ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.
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.
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.
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.
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).
Figura 30 – Protótipo – Definição de Membros
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).
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 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.
