DCC/SEGRAC
UMA AVALIAÇÃO DA ABORDAGEM DA MICROSOFT PARA
GERENCIAMENTO DE RISCOS EM PROJETOS DE
DESENVOLVIMENTO DE SOFTWARE
Luthiano Sande Lima Vasconcelos
GERENCIAMENTO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
Luthiano Sande Lima Vasconcelos
M o n o g r a f i a a p r e s e n t a d a n o C u r s o d e P ó s - G r a d u a ç ã o e m G e r e n c i a m e n t o d e P r o j e t o s , d a E s c o l a P o l i t é c n i c a , d a U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o . Orientadores:
Eduardo Linhares Qualharini Eliseu Castelo Branco Júnior
Ceará Dezembro, 2006
ii
UMA AVALIAÇÃO DA ABORDAGEM DA MICROSOFT PARA
GERENCIAMENTO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
Luthiano Sande Lima Vasconcelos
Orientadores:
Eduardo Linhares Qualharini Eliseu Castelo Branco Júnior
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
__________________________________________ Prof. Eduardo Linhares Qualharini
Orientador
__________________________________________ Eliseu Castelo Branco Júnior
Orientador
__________________________________________
Profª. Fernanda Veras
Ceará Dezembro, 2006
iii
VASCONCELOS, Luthiano Sande de Lima.
Uma Avaliação da Abordagem da Microsoft para Gerenciamento de Riscos em Projetos de Desenvolvimento de Software / VASCONCELOS, L. S. de L. Rio de Janeiro: UFRJ/EP, 2006.
xi, 64f. il.; 29,7cm.
Orientadores: Eduardo Linhares Qualharini, Eliseu Castelo Branco Júnior.
Monografia (especialização) – UFRJ / Escola Politécnica/ Curso de Especialização em Gerenciamento de Projetos, SEGRAC, 2006.
Referências Bibliográficas: f. 63-64.
1. Gerenciamento de Riscos. 2. Desenvolvimento de Software. 3. Gerenciamento de Projetos. Monografia. I. QUALHARINI, E. L., BRANCO JR, E. C. de. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Pós-graduação III. Especialista.
iv
“Se existem três sapos numa folha, e um deles pensa em pular da folha para a água. Quantos sapos restam na folha? A resposta certa é: restam três sapos. Porque o sapo apenas pensa em pular. Ele não fez isso. Nós não somos como o sapo, muitas vezes? Decidimos fazer isso, fazer aquilo, mas que ao final acabamos não fazendo nada?”.
Na vida, temos que tomar muitas decisões. Algumas fáceis, algumas difíceis. A maior parte dos erros que cometemos não se deve a decisões erradas. A maior parte dos nossos erros se deve a indecisões. Temos que viver com a conseqüência de nossas decisões. Isto é arriscar. Tudo é arriscar.
Rir é correr o risco de parecer um tolo. Chorar é correr o risco de parecer sentimental. Abrir-se para alguém é arriscar envolvimento. Expor os sentimentos é arriscar a expor-se a si mesmo. Expor suas idéias e sonhos é arriscar-se a perdê-los. Amar é correr o risco de não ser amado.
Viver é correr o risco de morrer. Ter esperanças é correr o risco de se decepcionar. Tentar é correr o risco de falhar. Os riscos precisam ser enfrentados, porque o maior fracasso da vida é não arriscar nada. A pessoa que não arrisca nada, não faz nada, não tem nada, é nada. Ela pode evitar o sofrimento e a dor, mas não aprende, não sente, não muda, não cresce, não vive. Presa à sua servidão, ela é uma escrava que teme a liberdade. Apenas quem arrisca é livre.”
v
Dedicatória
À minha companheira de todos os momentos, Valesca
vi
Agradecimentos
Diversas pessoas contribuíram direta ou indiretamente para a realização desse trabalho, contudo é importante destacar meus sinceros agradecimentos:
Ao professor e amigo Eliseu Castelo Branco Júnior, pela estimulante orientação e pelo bom humor característico.
Ao colega Cláudio Bezerra Leopoldino, pelas valiosas sugestões. Aos colegas do Curso de Pós-graduação em Gerenciamento de Projetos da UFRJ, pela inestimável companhia nos vários sábados e domingos.
Aos professores do Curso de Pós-graduação em Gerenciamento de Projetos da UFRJ, pelo profissionalismo e dedicação.
À coordenação da Bolsa de Valores Regional, pela viabilização do Curso.
vii
RESUMO
UMA AVALIAÇÃO DA ABORDAGEM DA MICROSOFT PARA
GERENCIAMENTO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
Luthiano Sande Lima Vasconcelos
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
A disciplina de Gerenciamento de Riscos do Microsoft Solutions Framework (MSF) defende o uso de uma abordagem proativa e estruturada para gerenciamento de riscos em projetos de desenvolvimento de software, que consiste em um processo de seis passos lógicos (identificação, análise, planejamento, acompanhamento, controle e aprendizagem) através do qual a equipe do projeto irá continuamente tratar as incertezas durante todo o ciclo de vida do projeto. Esse trabalho avalia o nível de aderência dos processos para Gerenciamento de Riscos do MSF em relação a abordagem do Project Management Institute, definida no Guia PMBoK, tida como uma das principais referências a respeito de Gerenciamento de Projetos.
Palavras-chave: Gerenciamento de Riscos, Gerenciamento de Projetos e Desenvolvimento de Software.
Ceará Dezembro, 2006
viii SUMÁRIO
1 MNTRODUÇÃO...01
1.1 Motivação e Justificativa...01
1.2 Objetivo...03
1.3 Apresentação da Estrutura da Monografia...04
2 MICROSOFT SOLUTIONS FRAMEWORK...05
2.1 Origem e histórico...05 2.2 Conceitos elementares...06 2.3 Princípios fundamentais...07 2.4 Modelos...08 2.4.1 O Modelo de Equipe...08 2.4.2 O Modelo de processo...10 2.5 Disciplinas...11
2.5.1 A Disciplina de Gerenciamento de Projetos... 12
2.5.2 A Disciplina de Gerenciamento de Riscos ... 12
2.5.3 A Disciplina de Gerenciamento de Aprendizagem ... 13
3 GERENCIAMENTO DE RISCOS...15
3.1 Conceitos fundamentais...15
3.2 Planejamento do Gerenciamento de Riscos...20
3.3 Processos de Gerenciamento de Riscos...25
3.3.1 Identificação de Risco... 27
3.3.2 Análise e Priorização de Riscos ... 34
3.3.3 Planejamento e Agendamento de Riscos ... 42
3.3.4 Acompanhamento e Relatório de Riscos ... 48
3.3.5 Controle de Riscos ... 51
3.3.6 Aprendizagem dos Riscos ... 52
4 AVALIAÇÃO DE PROCESSOS DE GERENCIAMENTO DE RISCOS...57 5 CONCLUSÕES...62 REFERÊNCIAS BIBLIOGRÁFICAS... 64
ix
LISTA DE FIGURAS
Figura 1 - Histórico de avaliação de projetos de TI (Fonte: Standish Group) ... 02
Figura 2 - Exemplos de componentes MSF ... 07
Figura 3 - O Modelo de Equipe ... 09
Figura 4 - Processo de gerenciamento de riscos do MSF 3.0 ... 13
Figura 5 - Práticas de gestão de portfolio de projetos mais utilizadas ... 15
Figura 6 - Aspectos mais considerados no planejamento de projetos ... 16
Figura 7 - Característica da metodologia de gerenciamento de riscos dos projetos... 16
Figura 8 - Processos de gerenciamento de riscos do MSF 3.0 ... 26
Figura 9 - Identificação de riscos do MSF 3.0...28
Figura 10 - Descrição do risco ... 32
Figura 11 - Análise e priorização de riscos ... 36
Figura 12 - Planejamento e programação de riscos do MSF 3.0... 42
Figura 13 - Acompanhamento e relatório de riscos no MSF 3.0... 48
Figura 14 – Controle de Riscos no MSF 3.0 ... 51
Figura 15 – Aprendizagem de Riscos no MSF 3.0 ... 53
Figura 16 – Processos de gerenciamento de riscos do PMBoK ... 57
Figura 17 - Análise de Aderência do MSF em relação ao PMBoK ... 61
LISTA DE TABELAS Tabela 1 - Fatores de sucesso em projetos de TI ... 05
Tabela 2 - Modelo de Equipe e suas metas principais ... 10
Tabela 3 - Mapeamento de processos de gerenciamento de riscos... 58
x
SIGLAS E ABREVIATURAS
ABNT Associação Brasileira de Normas Técnicas CMMI Capability Maturity Model Integration
CMU Carnegie Mellon University
CRM Continuous Risk Management
EPM Enterprise Project Management
EAP Estrutura Analítica do Projeto EAR Estrutura Analítica dos Riscos EDI Electronic Data Interchange
ERP Enterprise Resource Planning
IEEE Institute of Electrical and Electronics Engineers
IBM International Business Machine
IPD CMM - Integrated Product Development Capability Maturity Model IPMA International Project Management Association
ITIL Information Technology Infrastructure Library
MCS Microsoft Consulting Services
MOF Microsoft Operations Framework
MSF Microsoft Solutions Framework
PMBoK Project Management Body of Knowledge
PMI Project Management Institute
PMP Project Management Professional
Prince2 Projects in Controlled Environment
RBS Risk Breakdown Structure
ROI Return of Investment
RUP Rational Unified Process
SECM Systems Engineering Capability Model
SEI Software Engineering Institute
SEIR Software Engineering Information Repository
SPICE Software Process Improvement and Capability dEtermination
SRE Software Risk Evaluation
SWOT Strengths/Weaknesses Opportunities/Threats
SW CMM – Capability Maturity Model for Software TRM Team Risk Management
TI Tecnologia da Informação WBS Work Breakdown Structure
(MURTHI, 2002)
1.1 Motivação e Justificativa
O tema abordado pelo presente trabalho é significativo, especialmente para os profissionais de empresas de Tecnologia da Informação (TI) que atuam em projetos de desenvolvimento de software, pois os índices de desempenho registrados em seus projetos ainda são muito deficitários, e o entendimento e absorção de técnicas de gerenciamento de riscos formuladas, comprovadas e documentadas pelos líderes do segmento, pode efetivamente melhorar as taxas de sucesso dos projetos de TI.
Desde 1994, a empresa de consultoria norte-americana Standish Group tem publicado periodicamente o relatório CHAOS, que apresenta um panorama dos resultados alcançados em milhares de projetos de Tecnologia da Informação (TI). A análise desse relatório traz informações preocupantes como, por exemplo, que no ano 2000, apenas 28% de todos os projetos de TI cumpriram fielmente os cronogramas, orçamentos e especificações, ou seja, 72% dos projetos falharam ou não alcançaram as metas planejadas inicialmente. Essa avaliação torna-se mais assustadora devido à importância econômica dos sistemas de informação para as organizações (MURTHI, 2002). Nesse contexto, observa-se que quanto mais complexo o projeto, mais atividades de gerenciamento de projetos são necessárias, e, portanto mais atividades de gerenciamento de riscos (PINHO et al, 2005).
A maioria dos levantamentos realizados após projetos de software mal sucedidos tem indicado que seus problemas poderiam ser evitados ou fortemente minimizados se houvesse uma preocupação inicial em identificar e resolver questões de alto risco (BOEHM, 1991).
O fato é que os projetos de desenvolvimento de software estão expostos a incertezas das mais variadas origens, que podem implicar em perdas ou ganhos para o projeto. Contudo é possível, através do gerenciamento adequado das incertezas, potencializar os resultados positivos e amenizar os danos (PINHO et al, 2005).
É comum haver entusiasmo durante as fases iniciais dos projetos de desenvolvimento de software, que apesar de ter um aspecto positivo, deve ser tratado com cautela, de forma que haja uma preocupação pela identificação e resolução dos elementos de alto risco do projeto. Só então o entusiasmo e energia da equipe devem ser direcionados para a execução do projeto (BOEHM, 1991).
Nos últimos anos, muitas empresas têm investido na implantação de metodologias de desenvolvimento orientadas a processos, como o Rational Unified
Process (RUP) ou o Microsoft Solutions Framework (MSF), que estimulam o uso de
práticas estruturadas de gerenciamento de projetos, esperando reduzir os atrasos e o número de falhas em projetos de desenvolvimento de software (MURTHI, 2002) e melhorar a qualidade de seus produtos (PRIKLADNICK et al, 2004). Apesar dessas iniciativas, em muitos projetos de TI, o gerenciamento de riscos é ignorado completamente ou é visto apenas como um ritual burocrático.
Através da Figura 1, que mostra os resultados coletados pelo Standish Group até o ano 2000, já é possível observar uma melhoria nos resultados obtidos em virtude do emprego de técnicas estruturadas de gerenciamento de projetos. Contudo, observa-se que o gerenciamento de riscos não é uma área de estudo dominada plenamente por muitos gerentes de projetos de software (PINHO et al), portanto espera-se que o aprofundamento de técnicas estruturadas de gerenciamento de riscos implique na realização de projetos mais eficientes.
16 31 53 27 40 33 26 28 46 28 23 49 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1994 1996 1998 2000 Sucesso Falha Ajustes
Figura 1 - Histórico de avaliação de projetos de TI
Fonte: Standish Group
O Microsoft Solutions Framework é uma abordagem disciplinada para condução de projetos de desenvolvimento de software baseada em um conjunto de princípios, modelos, disciplinas, conceitos e práticas comprovadas pela Microsoft, a empresa de maior sucesso mundial na área de desenvolvimento de software. O MSF foi estruturado para auxiliar as equipes de desenvolvimento a atacar diretamente as causas mais comuns de falhas em projetos de tecnologia, com o intuito de aumentar
as taxas de sucesso, a qualidade da solução e o impacto positivo nos negócios. Criado especificamente para acomodar a natureza dinâmica dos projetos de Tecnologia da Informação, o MSF incorpora a capacidade de adaptar o projeto às mudanças contínuas (MICROSOFT, 2003).
Boehm (1991) observou que os gerentes de projetos bem sucedidos eram bons gerentes de riscos, que apesar de não usarem abordagens estruturadas e formais, eles usavam o conceito geral de “exposição a risco” para orientar as prioridades e ações no projeto, evitando erros e gerando produtos bons (BOEHM, 1991).
O MSF reconhece que mudanças e a incerteza resultante são aspectos inerentes do ciclo de vida de projetos de TI. Dessa forma, Gerenciamento de Riscos é uma disciplina fundamental no MSF, que promove uma abordagem proativa para tratar com a incerteza, avaliando os riscos do projeto continuamente e usando-os para influenciar a tomada de decisões. A idéia central dessa abordagem é identificar riscos potenciais que podem atrasar ou comprometer o projeto, e traçar estratégias que irão tratar adequadamente cada risco caso ele se materialize. Essa abordagem difere da reativa, na qual a equipe só identifica o risco quando ele ocorre e tenta tratá-lo somente depois do fato.
1.2 Objetivo
O objetivo do trabalho é descrever e avaliar a abordagem elaborada pela
Microsoft para o gerenciamento de riscos em projetos de desenvolvimento de software
no Microsoft Solutions Framework (MSF), usando como referência o Guia PMBoK (Project Management Body of Knowledge) do Project Management Institute (PMI), identificando as potencialidades e as oportunidades de melhoria, além de identificar o nível de aderência e compatibilidade entre as duas abordagens quanto a disciplina de gerenciamento de riscos.
Para auxiliar o trabalho de análise, esse trabalho traça um paralelo entre os processos de gerenciamento de riscos descritos no MSF e no PMBoK para definir as competências e características importantes desses processos e avaliar o nível de adequação da disciplina de Gerenciamento de Riscos do Microsoft Solutions
Framework em relação às práticas preconizadas pelo PMI, identificando
oportunidades de melhoria e propondo ações para melhorar o nível de maturidade do processo.
1.3 Apresentação da Estrutura da Monografia
O início do trabalho apresentará o Microsoft Solutions Framework, com o intuito de contextualizar o leitor para os aspectos fundamentais da metodologia de desenvolvimento de software proposta pela Microsoft. Depois dessa contextualização, o trabalho direcionará o foco para os princípios, conceitos e processos essenciais da disciplina de Gerenciamento de Riscos, sempre traçando um paralelo com as práticas sugeridas pelo Project Management Institute. Finalmente, será realizada uma avaliação crítica da abordagem adotada pela Microsoft, usando como referência o Guia PMBoK, para identificar as virtudes e deficiências dessa abordagem.
2 MICROSOFT SOLUTIONS FRAMEWORK
“Se você não está gerenciando riscos, você está gerenciando a coisa errada.” (Bill Carlson)
2.1 Origem e histórico
Atualmente, o ambiente globalizado e competitivo, no qual as organizações estão envolvidas, é caracterizado pela complexidade, pela interconectividade e pela celeridade das mudanças. As soluções de Tecnologia da Informação são tidas como os catalisadores dessas mudanças, logo conhecer e aproveitar as oportunidades surgidas a cada evolução tecnológica tem sido a causa principal para o investimento de tempo e recursos nas organizações. Nesse contexto, o desenvolvimento de soluções de tecnologia usualmente demanda um grande esforço das organizações, desde que envolve fatores como complexidade, escassez de recursos (financeiros e humanos) e cronogramas desafiadores, além de outros empecilhos.
A busca pela sobrevivência em um mercado cada vez mais globalizado e competitivo faz da qualidade do produtos de software um necessidade evidente (PRIKLADNICK et al, 2004). Nesse cenário acelerado de mudanças tecnológicas, as empresas de TI têm tido dificuldades em empregar corretamente os esforços para criar soluções de qualidade, devido à complexidade dos projetos. Tecnologia, isoladamente, pode ser um fator de falha ou sucesso em projetos, porém, raramente é a causa principal (MICROSOFT, 2003). O relatório CHAOS, do Standish Group, apresenta os principais fatores que influenciam no sucesso dos projetos de TI que estão expostos na. Curiosamente, observa-se que o sucesso de um projeto está mais relacionado a pessoas e processos que a complexidade da tecnologia.
Tabela 1 - Fatores de sucesso em projetos de TI
Fator Peso
Suporte executivo 18
Envolvimento do usuário 16
Experiência do gerente de projetos 14
Clareza dos objetivos de negócio 12
Escopo minimizado 10
Infra-estrutura de software padronizada 8
Estabilidade dos requisitos básicos 6
Metodologia formal 6
Estimativas confiáveis 5
Outros 5
Fonte: o autor
O fracasso em projetos de desenvolvimento de software é conseqüência de falhas na identificação e no gerenciamento dos riscos que os envolvem
(PRIKLADNICK et al, 2004). Organizações que tratam esses fatores alcançam melhores resultados, como maior qualidade dos produtos, aumento da satisfação dos usuários, melhoramento do ambiente de trabalho, o que atrai os melhores profissionais da área. Mudar o comportamento na condução de projetos de TI para tratar efetivamente esses fatores requer uma abordagem estruturada, que permita otimizar o uso dos recursos organizacionais. O MSF agrega as técnicas necessárias para gerenciar pessoas e processos, além dos elementos de tecnologia (MICROSOFT, 2003).
O Microsoft Solutions Framework surgiu em 1994 como uma coletânea das melhores práticas identificadas nos esforços de desenvolvimento de produtos da
Microsoft e nos projetos de consultoria da Microsoft Consulting Services (MCS),
divisão de serviços consultivos em tecnologia da informação e negócios. Desde então, o MSF tem evoluído consolidando as melhores práticas observadas nas equipes internas da Microsoft, responsável pelos produtos da empresa, além de parceiros e clientes. Os elementos do MSF são baseados nas melhores práticas do mercado e incorporam os mais de 30 anos de experiência da Microsoft em grandes projetos de
software. O MSF é mantido por uma equipe dedicada na Microsoft, que é responsável
por consolidar e distribuir para fora da empresa as melhores práticas identificadas internamente.
Atualmente a Microsoft está trabalhando no desenvolvimento da versão 4.0 do MSF, portanto este trabalho baseia-se na versão 3.0, que é a versão estável e vigente nesse momento.
2.2 Conceitos elementares
A Microsoft classifica o MSF como um framework, ao invés de uma metodologia, devido a flexibilidade que permite que as técnicas possam ser adaptadas para atender as especificidades de qualquer projeto, independentemente do seu tamanho ou complexidade, para planejar, construir e implantar soluções de TI. A filosofia do MSF prega que nenhuma estrutura ou processo aplica-se invariavelmente a todos os projetos, portanto os componentes descritos no MSF podem ser aplicados individualmente, ou coletivamente, para melhorar as taxas de sucesso dos projetos de TI. A lista a seguir define esses componentes:
- Princípios fundamentais são os princípios básicos sobre os quais o framework é estruturado. Eles expressam valores e padrões que são comuns a
- Modelos são descrições esquemáticas, ou “mapas mentais” para
organização das equipes de projeto e dos processos.
- Disciplinas são áreas de atuação prática definindo um conjunto
específico de métodos, termos e abordagens.
- Conceitos-chave são idéias que sustentam os princípios e as
disciplinas e são mostrados, explicitamente, através de práticas comprovadas.
- Práticas comprovadas são aquelas avaliadas em situações práticas,
com sucesso efetivo, em projetos de TI sob condições variadas.
- Recomendações são opcionais, mas sugerem práticas e orientações
para aplicação de modelos e disciplinas. A
Figura 2 apresenta um exemplo das interconexões entre esses componentes:
Figura 2 - Exemplos de componentes MSF
Fonte: O autor
2.3 Princípios fundamentais
O MSF define oito princípios fundamentais: - Incentivar comunicações abertas
- Trabalhar em busca de uma visão compartilhada - Dar poder os membros da equipe
- Estabelecer comprometimento claro e responsabilidade compartilhada - Permanecer ágil, esperando mudanças
- Aprender a partir de todas as experiências
Juntos, esses princípios expressam a filosofia do MSF, estabelecendo a base de uma abordagem coerente para organizar pessoas e processos para projetos empreendidos para construir soluções de TI (MICROSOFT, 2003).
2.4 Modelos
Os modelos MSF representam a aplicação dos princípios fundamentais aos aspectos de pessoas e processos em projetos de TI. O Modelo de Equipe e o Modelo de Processo são descrições esquemáticas que visualmente apresentam a organização lógica da equipe do projeto em conjuntos de funções e atividades do projeto através do ciclo de vida do projeto. Esses modelos incorporam os princípios fundamentais e as disciplinas, seus detalhes são refinados através de conceitos-chave e seus processos são aplicados através de práticas comprovadas e recomendações.
2.4.1 O Modelo de Equipe
O Modelo de Equipe define as funções e as responsabilidades das equipes trabalhando em projetos de TI em funções multidisciplinares, mas interdependentes (MICROSOFT, 2003). O diagrama a seguir é a representação lógica do modelo:
Figura 3 - O Modelo de Equipe
O Modelo de Equipe é baseado na premissa de que todos os projetos de TI devem alcançar certas metas de qualidade para serem considerados de sucesso. Alcançar cada meta requer a aplicação de diferentes conjuntos de conhecimentos relacionados e áreas de conhecimento, cada um deles é incorporado por uma função. Os conhecimentos relacionados e as áreas de conhecimento são chamadas áreas funcionais e definem os domínios de cada função. A função Gerenciamento de Programa, por exemplo, contém as áreas funcionais de gerenciamento de projetos, arquitetura da solução, garantia de processo e serviços administrativos. Coletivamente, essas funções têm a amplitude que abrange todos os critérios de sucesso do projeto, portanto, cada função é considerada igualmente importante na equipe, e as principais decisões são tomadas conjuntamente, com cada função contribuindo com sua perspectiva única (MICROSOFT, 2003). As metas associadas com cada função são representadas na tabela 2
Tabela 2 - Modelo de Equipe e suas metas principais
Meta principal de qualidade Função
Entrega da solução dentro das restrições do projeto Gerenciamento de Programa
Entrega da solução de acordo com as especificações do
produto Desenvolvimento
Liberação depois de resolver todas as pendências Teste
Implantação tranqüila e gerenciamento efetivo Gerenciamento de Liberação
Melhoria do desempenho do usuário Experiência de Usuário
Satisfação dos clientes Gerenciamento de Produto
Fonte: O autor
O Modelo de Equipe representa a compilação das melhores práticas para atribuir a autonomia necessária para equipe alcançar as metas definidas para o projeto, e é complementado pelo Modelo de Processo, que define atividades e entregas que são produzidas pela equipe.
É fundamental observar que uma função não é o mesmo que uma pessoa, já que várias pessoas podem ocupar uma mesma função ou o mesmo indivíduo pode assumir mais de uma função. O importante no Modelo de Equipe é que todas as metas de qualidade sejam representadas na equipe e que os vários envolvidos no projeto saibam quem na equipe é responsável por elas.
O Modelo de Equipe é o mais distinto aspecto do MSF, já que na sua essência está o fato que projetos de TI devem tratar perspectivas de qualidade diferentes, e geralmente antagônicas, para os vários envolvidos, incluindo patrocinadores e usuários. O Modelo de Equipe promove um confronto positivo de diversas idéias, pois reconhece que projetos de tecnologia não são exclusivamente um esforço técnico.
2.4.2 O Modelo de Processo
Cada projeto possui um ciclo de vida, um processo que inclui todas as atividades que deverão ser realizadas até o seu término. A principal função de um modelo de ciclo de vida é estabelecer a ordem em que as atividades do projeto serão realizadas. O modelo de ciclo de vida apropriado pode acelerar um projeto e ajudar a garantir que cada ação move o projeto na direção de um término bem sucedido (MICROSOFT, 2003). O Modelo de Processo combina conceitos dos tradicionais modelos em cascata e espiral, captando os pontos fortes de cada um. O Modelo de Processo combina os benefícios do planejamento baseado em marcos, do modelo em cascata, com a abordagem iterativa e incremental das entregas, do modelo em espiral. O gerenciamento de riscos fornece uma orientação para tratar e organizar o ciclo de vida do projeto. Abordagens orientadas ao risco, como o modelo espiral do processo de desenvolvimento de software evitam muitas dificuldades encontradas em modelos clássico como o modelo em cascata (BOEHM, 1991).
O Modelo de Processo é baseado em fases e marcos. Em uma primeira análise, fases podem ser vistas como períodos de tempo com uma ênfase em certas atividades direcionadas a produzir as entregas relevantes da fase. Porém, as fases MSF são mais que isso, cada uma delas tem sua própria característica distinta, e o fim de cada fase representa uma mudança no ritmo e no foco do projeto. Marcos são pontos de validação e sincronização para determinar quando os objetivos da fase foram alcançados, ele fornecem oportunidades explícitas para a equipe adequar o projeto aos riscos que podem se materializar durante seu curso. Além disso, marcos definem o encerramento para cada fase, permitindo uma redistribuição de responsabilidades entre as atividades, e encoraja a equipe a montar uma nova perspectiva mais apropriada para a conclusão da fase seguinte. O encerramento da fase é demonstrado pela entrega de resultados tangíveis que a equipe produziu durante cada fase e pelo estabelecimento de um nível de consenso, entre a equipe e o cliente, em torno dessa entrega. Esse encerramento, e os resultados associados, tornam-se o ponto de início da próxima fase.
O Modelo de Processo permite que a equipe responda às requisições do cliente e trate as mudanças, quando forem necessárias, durante todo seu trajeto. Ele também permite que a equipe entregue partes importantes da solução mais rápido, através da priorização de funcionalidades, na qual as funcionalidades menos críticas são movidas para as liberações subseqüentes. O Modelo de Processo é um componente flexível do MSF que pode ser utilizado para melhorar o controle do
projeto, minimizar riscos, melhorar a qualidade do produto e aumentar a velocidade de desenvolvimento.
A integração do Modelo de Processo com o Modelo de Equipe é uma importante combinação para o sucesso do projeto, pois, coletivamente, esses modelos oferecem flexibilidade, mas definem roteiros para a realização dos projetos, levando em conta a unicidade da cultura organizacional, dos tipos de projetos e das qualificações pessoais.
2.5 Disciplinas
As três disciplinas do MSF (Gerenciamento de Projetos, Gerenciamento de Riscos e Gerenciamento de Aprendizagem) são áreas de aplicação prática que empregam um conjunto específico de métodos, termos e abordagens. Essas disciplinas são importantes para o funcionamento otimizado dos Modelos de Equipe e de Processo. Essas disciplinas têm suas origens fora do MSF e estão bem documentadas em diversos padrões de mercado, como o PMBoK. O MSF incorporou essas disciplinas devido ao alinhamento com seus princípios fundamentais e seus modelos. A intenção do MSF não é recriar essas disciplinas, mas apenas destacar como elas podem ser adaptadas quando aplicadas no contexto de projetos de TI (MICROSOFT, 2003).
2.5.1 A Disciplina de Gerenciamento de Projetos
O MSF tem uma abordagem descentralizada para o gerenciamento de projetos que está relacionada aos seus princípios fundamentais e seus modelos. A disciplina Gerenciamento de Projetos é largamente alinhada com os principais guias de gerenciamento de projetos, como o PMBoK. O Guia PMBoK é mantido pelo Project
Management Institute (PMI), que é uma organização mundial reconhecida por divulgar
amplamente as melhores práticas para gerenciamento de projetos.
O MSF, como um framework para projetos de TI, reconhece que o gerenciamento de projetos é alcançado através de responsabilidades e atividades que estendem-se além de um indivíduo. Quanto mais difundida a realização dessas atividades e responsabilidades através da equipe, maior a habilidade de criar uma equipe auto-gerenciável altamente colaborativa. Porém, a maioria das atividades e responsabilidades de gerenciamento de projetos são mantidas na função Gerenciamento de Programa. Essa função concentra-se nos processos e nas
restrições do projeto e nas atividades principais na disciplina de Gerenciamento de Projetos.
2.5.2 A Disciplina de Gerenciamento de Riscos
O MSF enxerga o gerenciamento de riscos como uma disciplina que precisa ser integrada ao ciclo de vida do projeto e incorporada ao trabalho de cada membro da equipe através de uma abordagem sistemática e proativa. Gerenciamento de riscos proativo significa que a equipe do projeto tem um processo definido e contínuo para gerenciar riscos. A equipe do projeto faz uma avaliação inicial do que pode dar errado, determina os riscos que devem ser tratados e implementa as estratégias (planos de ação) para tratá-los. A atividade de avaliação de riscos é constante durante todo o projeto, e alimenta o processo de tomada de decisão em todas as fases. Os riscos identificados são acompanhados até que eles sejam resolvidos ou transformados em questões, e tratados como tal. A Figura 4 descreve os processos de gerenciamento de riscos proativo do MSF.
Figura 4 - Processos de gerenciamento de riscos do MSF 3.0
Fonte: O autor
O processo de seis etapas de gerenciamento de riscos do MSF é integrado com o Modelo de Equipe através de definições de funções e responsabilidades,
criando uma abordagem completa para gerenciamento de riscos. O processo finaliza com a etapa de aprendizagem, que captura e armazena os riscos do projeto, estratégias de mitigação e contingência, e ações realizadas para futuras análises ou revisões. Esse banco de dados de conhecimento de informações relacionadas a riscos é uma parte necessária para instituição do aprendizado organizacional, que pode utilizar o conhecimento de projetos passados para melhorar o desempenho em projetos futuros. O Guia PMBoK descreve que o gerenciamento desse banco de dados de riscos pode ser uma das competências do Escritório de Gerenciamento de Projetos da organização.
2.5.3 A Disciplina de Gerenciamento de Aprendizagem
A disciplina Gerenciamento de Aprendizagem define o aprendizado como a diferença entre os estados de conhecimento atual e desejado dos indivíduos da organização. Essa medida avalia as capacidades reais ou percebidas desses indivíduos em qualquer ponto durante os processos de planejamento, construção e gerenciamento de soluções.
A aprendizagem pode ser medida em vários níveis: organizacional, equipe ou individual. No nível organizacional, aprendizado refere-se ao estado atual das medidas coletivas das capacidades individuais. Essa informação é usada tanto no planejamento estratégico, quanto na avaliação de capacidade para alcançar adoção e realização de investimentos em tecnologia. O Gerenciamento de Aprendizagem aplica-se em áreas como melhoria de processos e gerenciamento de mudanças organizacional.
A disciplina Gerenciamento de Aprendizagem no MSF, porém, limita seu foco ao aprendizado em equipes de projeto. Ela fornece orientação e processos para definir, avaliar, mudar e avaliar o conhecimento e as habilidades necessárias para execução adequada do projeto.
Cada pessoa realizando um papel específico na equipe do projeto deve ser capaz de preencher todas as funções principais que são inerentes a esse papel. O aprendizado individual é a medida do estado de conhecimento atual de cada membro da equipe com o estado considerado para atender às responsabilidades requeridas pelo seu papel. A intenção do Gerenciamento de Aprendizagem é garantir que os membros da equipe sejam totalmente qualificados para o trabalho que eles precisam realizar.
A disciplina Gerenciamento de Aprendizagem reflete os princípios de comunicação aberta, investimento em qualidade e aprendizagem contínua. Essa
disciplina reconhece que projetos inerentemente mudam o ambiente no qual eles são desenvolvidos, como também o ambiente no qual eles são entregues. Através de uma preparação proativa para o estado futuro, a organização coloca-se numa posição para agregar valor ao negócio mais rapidamente, que é o propósito último do projeto.
3 GERENCIAMENTO DE RISCOS
“Gerenciamento de riscos é gerenciamento de projetos para adultos.” (Tom DeMarco)
3.1 Conceitos fundamentais
Riscos em projetos de desenvolvimento de software não foram tratados em detalhes até o final dos anos 1980s, quando Boehm propôs e sintetizou uma abordagem para gerenciamento de riscos de software. Seu trabalho foi complementado por Charette, e sobre esses fundamentos os recentes avanços em gerenciamento de riscos de software têm sido produzidos através de bem documentadas abordagens para gerenciamento de riscos. Entre elas está a abordagem proposta pela Microsoft incorporada ao Microsoft Solutions Framework (MSF).
Apesar desses esforços e do óbvio interesse das organizações em gerenciamento de riscos, parece que poucas organizações aplicam métodos específicos de gerenciamento de riscos efetivamente. De acordo com o benchmaking publicado pelo PMI-RIO apenas 22% dos projetos “têm seus riscos formalmente identificados e calculados” (Figura 5), isso reforça a informação que o gerenciamento de risco é o aspecto menos considerado no planejamento de projetos (Figura 6).
Figura 5 - Práticas de gestão de portfólio de projetos mais utilizadas
Fonte: PMI-RIO, 2005
Os projetos têm seus riscos formalmente identificados e
Figura 6 - Aspectos mais considerados no planejamento de projetos
Fonte: PMI-RIO, 2005
Outro dado que importante extraído do benchmarking do PMI-RIO é apenas 31% das organizações adotam uma metodologia formal para gerenciamento de riscos em projetos (Figura 7). Dessa forma, percebe-se claramente que a prática dos métodos de gerenciamento de riscos não alcançou ainda seu potencial completo.
Figura 7 - Característica da metodologia de gerenciamento de riscos dos projetos Fonte: PMI-RIO, 2005
Um aspecto essencial do gerenciamento de projetos é controlar os riscos inerentes ao projeto. Riscos surgem das incertezas que envolvem as decisões e os resultados do projeto. Maioria dos indivíduos associam o conceito de risco com uma potencial perda de valor, controle, funcionalidade ou qualidade no projeto. Porém, no MSF, um risco de projeto é amplamente definido como qualquer evento ou condição que pode ter impacto positivo ou negativo sobre os resultados do projeto. Esse conceito mais amplo de risco especulativo é totalmente compatível com a visão do PMI, e também é utilizado no mercado financeiro onde decisões envolvendo
incertezas podem ser associadas tanto com potencial de ganho, como de perda. Isso é o oposto do conceito de risco puro usado na indústria de seguros onde incertezas estão associadas somente a potenciais perdas futuras.
As organizações percebem os riscos quando eles estão vinculados a ameaças ou oportunidades no projeto (PMI, 2004). Riscos diferem de problemas porque referem-se a um futuro potencial de resultado adverso ou perda. Problemas, porém, são condições ou situações que existem no projeto no tempo presente. Riscos podem, se tornar problemas se não tratados adequadamente. Segundo Boehm, “a coisa mais importante para um projeto é manter-se focado em seus fatores críticos de sucesso” (BOEHM, 1991).
O gerenciamento de riscos é o conjunto de processos de identificar, analisar, responder, monitorar, controlar e planejar os riscos do projeto (PMI, 2004) proativamente (MICROSOFT, 2003). A meta do gerenciamento de riscos é maximizar os impactos positivos (oportunidades) e minimizar os impactos negativos (perdas) associados aos eventos do projeto (PMI, 2004).
Projetos de TI têm características que fazem o efetivo gerenciamento de riscos essencial para seu sucesso. Pressões competitivas de negócio, mudanças regulatórias e legais, além da evolução dos padrões técnicos, podem algumas vezes forçar as equipes de projetos de TI a modificar os planos e os direcionamentos durante o ciclo de vida do projeto. Alterações em requisitos do usuário, novas ferramentas e tecnologias, identificação de ameaças de segurança, e mudanças de pessoal, todos esses fatores agregam incertezas (ou riscos) ao projeto.
O gerenciamento de riscos surgiu como uma tentativa de formalizar princípios e práticas, com o objetivo de identificar, tratar e eliminar riscos antes que eles tornem-se ameaças ao sucesso do projeto (BOEHM, 1991). Para Boehm a execução de processos de gerenciamento de riscos pode reduzir as falhas em projetos de software (MACHADO, 2002).
A disciplina de Gerenciamento de Riscos é baseada na crença de que os riscos devem ser tratados proativamente, ela é parte de um processo formal e sistemático que aborda o gerenciamento de riscos como um esforço positivo. Essa disciplina é baseada nos princípios fundamentais, conceitos e práticas que são o centro da filosofia do MSF.
Apesar de diferentes projetos poderem ter mais ou menos riscos do que outros, nenhum projeto está completamente livre do risco. Projetos são iniciados para que uma organização possa alcançar uma meta que agregue valor ao seu propósito. Sempre há incertezas envolvendo o projeto e o ambiente que podem afetar seu
sucesso. O MSF adota uma abordagem proativa para identificar, analisar e tratar riscos com o seguinte foco:
- Antecipar problemas ao invés de apenas reagir quando eles ocorrerem. - Tratar causas raiz, ao invés de apenas agir nos sintomas
- Ter planos prontos para resolução de problemas antes que eles ocorram.
- Usar um processo conhecido, estruturado e repetível para resolução de problemas.
- Usar medidas preventivas sempre que possível.
O gerenciamento de riscos eficaz não é alcançado apenas reagindo a problemas. A equipe deverá trabalhar para identificar riscos antecipadamente e desenvolver estratégias para gerenciá-los. É importante manter planos que irão responder a problemas, se eles ocorrerem. Logo, é fundamental antecipar problemas potenciais e elaborar planos adequados, encurtando o tempo de resposta em um momento de crise, e podendo limitar ou até mesmo reverter o dano causado pela ocorrência de um problema.
Segundo o MSF, os planos devem seguir um formato padronizado que respondam as questões como “por quê”, “o quê”, “quando”, “quem”, “onde”, “como” e “quanto”. Essa organização permite que os planos sejam concisos, orientados a ações, fáceis de entender e fáceis de monitorar.
As características definidas do gerenciamento de riscos proativo são: mitigação do risco e a redução de impacto. Mitigação de um risco pode ocorrer no nível mais específico na causa imediata, ou por intervenção no nível da causa raiz, ou em qualquer lugar na cadeia de causas. Medidas de mitigação são melhor empreendidas nos estágios iniciais do projeto, onde a equipe ainda tem a habilidade para intervir nos resultados do projeto.
Identificação e correção de causas raízes tem um alto valor para a organização porque as medidas corretivas podem repercutir em efeitos positivos além das fronteiras do projeto individual. Por exemplo, a ausência de padrões de codificação ou convenções para nomenclatura de máquinas podem claramente resultar em conseqüências adversas em um único projeto de desenvolvimento, logo essa é uma fonte de riscos ao projeto. Porém, a criação de padrões corporativos podem ter um impacto positivo em todos os projetos empreendidos na organização.
Um gerenciamento de riscos efetivo depende de um correto e abrangente entendimento dos riscos que permeiam uma equipe de projeto. Pela variedade de
desafios e a magnitude das perdas potenciais, as atividades de gerenciamento de riscos são atividades desencorajadas para a equipe. Algumas pessoas podem interpretar que identificar riscos é procurar razões para justificar o insucesso de um projeto. Em contraste, MSF adota a perspectiva de que vários processos de identificação dos riscos permitem a equipe gerenciar riscos mais eficientemente.
A equipe (e especialmente os líderes) devem sempre considerar a identificação de riscos de uma forma positiva para garantir a contribuição de quanto mais informação for possível sobre os riscos. Um percepção negativa de riscos faz que os membros da equipe fiquem relutantes em comunicar riscos. O ambiente deve favorecer para que os indivíduos que estão identificando riscos possam fazê-lo sem medo de retaliações. Exemplos de ambientes negativos são fáceis de encontrar. Por exemplo, em alguns ambientes, relatar novos riscos é visto como uma forma de queixar-se. Nesse caso a pessoa que está relatando o risco é vista como um causador de problemas e a reação ao risco é direcionada a pessoa, ao invés de ao risco. Pessoas geralmente tornam-se receosas de livremente comunicar os riscos sob essas circunstâncias e então começam a apresentar seletivamente as informações de riscos para evitar conflitos com outros membros da equipe. Equipes criam um ambiente positivo para gerenciamento de riscos quando recompensam os membros que revelam riscos.
Para alcançar a meta de maximizar os ganhos positivos para um projeto, a equipe deve querer tomar riscos. Isso significa enxergar os riscos e as incertezas como os meios para criar oportunidades para que a equipe alcance sucesso no projeto. Muitos profissionais de TI não percebem o gerenciamento de riscos com uma atividade necessária, mas uma atividade burocrática que deve ser feita no início do projeto ou somente quando um novo processo é introduzido no ambiente do projeto.
As contínuas mudanças no projeto e nos ambientes operacionais exigem que as equipes regularmente reavaliem a situação dos riscos conhecidos e atualizem os planos para prevenir ou responder a problemas associados com esses riscos. Equipes devem também constantemente procurar pelo surgimento de novos riscos no projeto. As atividades de gerenciamento de riscos devem ser integradas em todo o ciclo de vida de gerenciamento do projeto, de forma a fornecer atualizações apropriadas aos planos e atividades de controle de riscos, sem criar uma separada infra-estrutura de relatório e acompanhamento.
Apesar dos riscos serem geralmente conhecidos por alguns membros da equipe, essa informação é geralmente pouco divulgada. É muito fácil comunicar informações sobre riscos para baixo na hierarquia da organização, mas é difícil passar essas informações para cima. Em cada nível, as pessoas querem conhecer sobre os
riscos dos níveis inferiores, mas são resistentes a repassar essa informação. Restringir o fluxo de informações sobre riscos é um potencial risco ao projeto porque ele força tomadas de decisão com menos informação. Na hierarquia da organização, gerentes precisam encorajar e mostrar que os canais de comunicação estão abertos, e garantir que os riscos e os respectivos planos sejam compreendidos por todos os envolvidos.
O gerenciamento de riscos é importante para a tomada de decisões em frente a incerteza, portanto é fundamental que as descrições de riscos sejam suficientemente claras para todos os envolvidos no projeto. Descrições de risco abrangentes preservam muito da incerteza e estimulam diferentes interpretações do risco. Descrições claras sobre um risco auxiliam a equipe a:
- Garantir que todos os membros da equipe tenham o mesmo entendimento do risco.
- Entender a causa ou as causas do risco e o relacionamento com os problemas que podem acontecer.
- Fornecer uma base para a análise formal e quantitativa e para o planejamento de esforços.
- Estabelecer confiança dos envolvidos e patrocinadores na habilidade da equipe de gerenciar o risco
O MSF defende que o planejamento do gerenciamento de riscos deve ser empreendido com atenção a informações específicas para minimizar os erros de execução no plano de riscos que resulte em esforços preventivos ineficientes ou esforços corretivos. Apesar dos membros da equipe e dos principais envolvidos no projeto, geralmente, perceberem os riscos como negativos, é importante não julgar um projeto ou processo operacional simplesmente pelo número de riscos comunicados. Risco é uma possibilidade, não uma certeza de perda ou resultado insatisfatório. O processo de Gerenciamento de Riscos defende o uso de uma identificação de riscos estruturada e um processo de análise para fornecer aos tomadores de decisão não apenas informação da presença de riscos, mas também a importância desses riscos perante o projeto.
3.2 Planejamento do Gerenciamento de Riscos
Sendo o PMBoK, o Planejamento do Gerenciamento de Riscos é o processo de decidir qual a abordagem adequada para as atividades de gerenciamento de riscos
do projeto. Esse processo garante que o nível, o tipo e a visibilidade do gerenciamento de riscos sejam coerentes com o risco e a importância do projeto para a organização, para alocar os recursos necessários para as atividades de gerenciamento de riscos e para estabelecer uma base acertada de avaliação de riscos (PMI, 2004).
Durante as fases de Visão e Planejamento do Modelo de Processo, a equipe deverá desenvolver e documentar como eles planejam implementar o processo de gerenciamento de riscos no contexto do projeto (MICROSOFT, 2003). As seguintes questões deverão ser respondidas nesse plano:
- Quais são as premissas e restrições para o gerenciamento de riscos? - Como irá o processo de gerenciamento de riscos ser implementado? - Quais são os passos desse processo?
- Quais são as atividades, papéis, responsabilidades, e entregas para cada passo?
- Quem irá realizar as atividades de gerenciamento de risco? - Quais são as habilidades necessárias?
- Há algum treinamento adicional?
- Como o gerenciamento de riscos no projeto relaciona os esforços no nível corporativo?
- Que tipos de ferramentas ou métodos serão usados?
- Que definições são usadas para classificar e estimar os riscos? - Como os riscos serão priorizados?
- Como os planos de riscos e de contingência serão criados e executados?
- Como as atividades de controle de risco irão ser integradas ao plano geral do projeto?
- Que atividades os membros da equipe irão fazer para gerenciar riscos? - Como o status será comunicado entre a equipe e os interessados no projeto?
- Que tipo de infra-estrutura será usada (bancos de dados, ferramentas, repositórios) para suportar o processo de gerenciamento de riscos?
- Quais são os riscos do gerenciamento de riscos?
- Quais são as datas críticas do cronograma para implementar o gerenciamento de riscos?
- Quem é o patrocinador e quem são os envolvidos no projeto?
As atividades de planejamento do gerenciamento de riscos não deverão ser mostradas isoladamente do planejamento padronizado do projeto e das atividades agendadas, pois essas atividades não devem ser percebidas apenas como “uma adição” as tarefas que a equipe deve realizar para completar o projeto. Como os riscos são inerentes a todas as fases de todos os projetos do início ao fim, os recursos devem ser alocados e para ativamente gerenciar riscos. O planejamento do gerenciamento de riscos deve ser realizado durante as fases de Visão e Planejamento do Modelo de Processo, resultando na elaboração do plano de gerenciamento de riscos, considerando os fatores ambientais da empresa, os ativos de processos organizacionais, a declaração de escopo do projeto, como também o plano de gerenciamento do projeto. que documenta esses planos deverá contribuir definindo ações atribuídas a membros específicos da equipe na Estrutura Analítica do Projeto (EAP). Essas ações deverão aparecer no plano do projeto e no cronograma respectivo (MICROSOFT, 2003).
Um planejamento cuidadoso e explícito aumenta a possibilidade de sucesso dos demais processos de gerenciamento de riscos (PMI, 2004). No Capability Maturity
Model Integration, definido pelo Software Engineering Institute, a preparação para o
gerenciamento de riscos possui três práticas:
- Determinar fontes e categorias de riscos - Definir parâmetros de riscos
- Estabelecer uma estratégia de gerenciamento de riscos
A preparação é conduzida pelo estabelecimento e manutenção de uma estratégia para a identificação, análise e mitigação de riscos. Isto é normalmente documentado como um plano de gerenciamento de riscos. A estratégia de gerenciamento de riscos trata as ações específicas e a abordagem de gerenciamento utilizadas para aplicar e controlar o programa de gerenciamento de riscos. Isto inclui identificar as fontes de riscos, o esquema utilizado para categorizar os riscos e os
parâmetros utilizados para avaliar, conectar e controlar riscos para um tratamento efetivo.
A determinação de fontes e categorias de riscos consiste na identificação de fontes de riscos oferece uma base para sistematicamente examinar as mudanças para descobrir circunstâncias que impactam a habilidade do projeto para atender aos seus objetivos. Fontes de riscos podem ser internas ou externas ao projeto. Conforme o progresso do projeto, fontes adicionais podem ser identificadas. O estabelecimento de categorias para riscos fornece um mecanismo para coletar e organizar riscos, como também garantir a atenção adequada para aqueles riscos que podem ter conseqüências mais sérias no atendimento aos objetivos do projeto.
Fontes de riscos são os direcionadores fundamentais que causam riscos dentro de um projeto ou organização. Existem muitas fontes de riscos, tanto internas quanto externas ao projeto. As fontes de riscos identificam áreas comuns onde os riscos podem se originar. As fontes, internas e externas, mais comuns de riscos incluem:
- Requisitos incertos
- Esforços sem precedentes – não há estimativas disponíveis - Design impossível de ser implementado
- Tecnologia não disponível
- Estimativas ou alocações de cronograma irreais - Equipe e habilitações inadequadas
- Questões de custos ou recursos financeiros
- Capacitação incerta ou inadequada do subcontratado - Capacitação incerta ou inadequada do fornecedor
Muitas destas fontes de riscos são freqüentemente aceitas sem o planejamento adequado. A identificação antecipada de fontes de riscos internas e externas pode levar a uma identificação antecipada dos riscos. Planos de mitigação de riscos podem, então, ser implementados antecipadamente no projeto para impedir a ocorrência dos riscos ou reduzir as conseqüências de sua ocorrência.
As categorias de riscos refletem as “latas” para a coleta e organização de riscos. Um motivo para identificar as categorias de riscos é ajudar na futura consolidação das atividades nos planos de mitigação de riscos.
Os seguintes fatores podem ser considerados quando se determina as categorias de riscos:
- As fases do modelo de ciclo de vida do projeto (por exemplo, requisitos,
design, fabricação, teste e avaliação, entrega, descarte)
- Os tipos de processos utilizados - Os tipos de produtos utilizados
- Riscos de programas de gerenciamento (por exemplo, riscos do contrato, riscos de orçamento/custos, riscos de cronograma, riscos de recursos, riscos de desempenho, riscos de suporte)
Durante o planejamento do gerenciamento de riscos, Os parâmetros para a avaliação, categorização e priorização de riscos incluem:
- Probabilidade de riscos (probabilidade de ocorrência do risco)
- Conseqüência dos riscos (impacto e gravidade da ocorrência do risco) - Limites para disparar as atividades de gerenciamento
Os parâmetros de riscos são utilizados para fornecer critérios comuns e consistentes para comparar os diversos riscos a serem gerenciados. Sem estes parâmetros, seria muito difícil medir a gravidade de mudanças não desejadas causadas pelo risco e priorizar as ações necessárias exigidas pelo planejamento de mitigação de riscos.
Critérios utilizados de forma consistente (por exemplo, as ligações entre a probabilidade e os níveis de gravidade) permitem que os impactos de diferentes riscos possam ter um entendimento comum e receber o nível apropriado de atenção. Para cada categoria de riscos, podem ser estabelecidos limites para determinar a aceitabilidade ou não dos riscos, a priorização dos riscos ou gatilhos para disparar uma ação de gerenciamento. Exemplos de limites incluem:
- Limites no âmbito do projeto poderiam ser estabelecidos para envolver a gerência sênior quando os custos dos produtos excederem 10% do custo determinado ou quando os Índices de Desempenho de Custos (Cost Performance
Indexes - CPIs) caírem abaixo de 0,95.
- Limites de cronograma poderiam ser estabelecidos para envolver a gerência sênior quando os Índices de Desempenho do Cronograma (Schedule
- Limites de desempenho poderiam ser configurados para envolver a gerência sênior quando itens chave de design especificados (por exemplo, utilização do processador) excederem 125% do design pretendido.
Isto pode ser refinado mais tarde, para cada risco identificado, para estabelecer pontos nos quais um monitoramento de riscos mais agressivo é empregado ou para sinalizar a implementação de planos de mitigação de riscos.
Existem poucos limites nos quais os riscos podem ser avaliados de uma forma quantitativa ou qualitativa. A definição de limitações (ou condições de fronteiras) pode ser utilizada para ajudar a definir o escopo do esforço de gerenciamento de riscos e evitar um gasto excessivo de recursos. As limitações podem incluir a exclusão de uma fonte de risco de uma categoria. Estas limitações podem também excluir uma condição que ocorre com uma freqüência menor que uma dada freqüência.
A estratégia de gerenciamento de riscos deverá ser guiada por uma visão comum do sucesso que descreve os resultados futuros desejados para o projeto, em termos do produto que será entregue, seu custo e sua adequação à tarefa. A estratégia de gerenciamento de riscos é, muitas vezes, documentada em um plano de gerenciamento de riscos do projeto ou organizacional. A estratégia de gerenciamento de riscos é revisada com os stakeholders relevantes para promover o compromisso e o entendimento.
3.3 Processos de Gerenciamento de Riscos
A disciplina de Gerenciamento de Riscos defende o gerenciamento de riscos proativo, a contínua avaliação de riscos e a integração com os processos de tomada de decisão através de todo o ciclo de vida do projeto. Riscos são continuamente avaliados, monitorados e ativamente gerenciados até que eles tenha sido resolvidos ou tenham se transformado em problemas para serem tratados (MICROSOFT, 2003). Uma abordagem contínua de gerenciamento de riscos é aplicada para efetivamente antecipar e mitigar riscos que tem impactos críticos sobre o projeto (CMMI, 2001). O processo de gerenciamento de riscos do MSF define seis passos lógicos através dos quais a equipe gerencia os riscos atuais, planeja e executa as estratégias de gerenciamento de riscos, e captura conhecimento para a organização.
Os seis passos que constituem o processo de gerenciamento de riscos no MSF são( Figura 8):
1. Identificar 2. Analisar e Priorizar 3. Planejar e Agendar 4. Acompanhar e Relatar 5. Controlar 6. Aprender
Figura 8 - Processos de gerenciamento de riscos do MSF 3.0 Fonte: O autor
A identificação de riscos permite aos indivíduos trazer à tona riscos que a equipe entende como um potencial problema. Como a entrada do processo de gerenciamento de riscos, a identificação de riscos deverá ser realizada tão breve quanto possível e repetida freqüentemente através do ciclo de vida do projeto.
A análise de riscos transforma as estimativas ou dados sobre os riscos registrados na identificação de riscos em uma forma em que a equipe possa usar para tomar decisões quanto a prioridade. A priorização de riscos permite ao time do projeto alocar recursos para gerenciar os riscos mais importantes.
O planejamento de riscos recebe as informações obtidas da análise de riscos, usando-as para formular estratégias, planos e ações. A programação das atividades de riscos garante que esses planos são aprovados e então incorporados ao processo cotidiano de gerenciamento de projetos, explicitamente conectando o planejamento de riscos com o planejamento geral do projeto.
O planejamento do gerenciamento de riscos ajuda a preparar o tratamento para cada risco, incluindo a coordenação dos planos de cada risco ao plano geral do projeto (BOEHM, 1991).
O acompanhamento de riscos monitora o status de riscos específicos e o progresso em seus respectivos planos de ação. O acompanhamento de riscos inclui o monitoramento de probabilidade, impacto, exposição e outras medidas de risco para mudanças que poderão alterar as prioridades ou planos de riscos. O acompanhamento de riscos habilita a visibilidade dos processos de gerenciamento de
riscos no projeto da perspectiva de níveis de risco em oposição a perspectiva de completude de tarefas do processo de gerenciamento de projetos padronizado. O relatório de riscos garante a equipe, ao patrocinador, e outros interessados, que eles serão avisados quando o status dos riscos do projeto e os planos para gerenciá-los mudarem (MICROSOFT, 2003).
O controle de riscos é o processo de execução de planos de ação e seus relatórios de status associados. O controle de riscos também inclui a iniciação das requisições de mudanças quando alterações no status de um risco ou de um plano pode resultar em mudanças nas funcionalidades, nos recursos ou no cronograma do projeto.
Aprendizagem de risco formaliza as lições aprendidas e artefatos relevantes do projeto, e captura esse conhecimento em uma forma reusável para reutilização pela equipe ou pela organização.
É importante observar que esses passos são passos lógicos e não precisam ser seguidos estritamente na ordem cronológica para um dado risco. A disciplina de Gerenciamento de Riscos defende que cada projeto deve definir na sua fase de planejamento quando e como o processo de gerenciamento de riscos deve ser iniciado e sob que circunstâncias as transições entre os passos deverá ocorrer.
3.3.1 Identificação de Riscos
A identificação de riscos é o passo inicial no processo de Gerenciamento de Riscos. Riscos devem ser identificados claramente e inequivocamente para que a equipe possa chegar a um consenso e prosseguir para análise e planejamento. Durante a identificação de riscos, o foco da equipe deve ser deliberadamente expansivo. Atenção deve ser dada à atividade de aprendizagem e direcionada para a busca de lacunas de conhecimento sobre o projeto e seu ambiente que pode advertidamente afetar o projeto ou limitar seus sucesso. A Figura 9 representa graficamente as entradas, saídas e atividades para o passo de identificação de riscos.
Experiência da equipe Conhecimento do projeto - geral - negócio - técnico - ambiental Risco organizacional (políticas e procedimentos) Especificação do projeto, histórico, estado atual ou
contexto Outros Identificação de riscos Base de conhecimento de riscos Declarações de riscos Declarações de riscos Declarações de riscos
Figura 9 - Identificação de riscos do MSF 3.0 Fonte: O autor
A identificação de potenciais questões, perigos, ameaças e vulnerabilidades que poderiam afetar negativamente os esforços ou planos de trabalho é a base para um sonoro e bem sucedido gerenciamento de riscos. Os riscos devem ser identificados e descritos de uma forma fácil de entender, antes que possam ser analisados e gerenciados de forma apropriada. Os riscos são documentados em uma declaração concisa que inclui o contexto, as condições e as conseqüências da ocorrência do risco.
A identificação dos riscos deverá usar uma abordagem organizada e abrangente para pesquisar riscos prováveis ou reais ao atendimento dos objetivos. Para ser eficaz, a identificação dos riscos não deverá ser uma tentativa de tratar todos os eventos possíveis, não importando que sejam improváveis. O uso de categorias e parâmetros desenvolvidos na estratégia de gerenciamento de riscos, junto com as fontes identificadas de riscos, podem fornecer a disciplina e o fluxo de trabalho apropriados para a identificação dos riscos. Os riscos identificados formam uma linha de base para iniciar as atividades de gerenciamento de riscos. A lista de riscos deverá ser revisada periodicamente para reexaminar possíveis fontes de riscos e condições
que mudaram, para descobrir fontes e riscos não percebidos ou inexistentes na última atualização da estratégia de gerenciamento de riscos.
As atividades de identificação de riscos se concentram na busca de riscos, não na busca de culpados. Os resultados das atividades de identificação de riscos não são utilizados pela gerência para avaliar o desempenho de indivíduos.
Existem diversos métodos para a identificação de riscos. Os métodos comuns de identificação incluem:
- Examinar cada elemento da Estrutura Analítica do Projeto (EAP) do projeto para descobrir riscos.
- Conduzir uma análise de riscos utilizando uma taxonomia de riscos. - Entrevistar especialistas no assunto.
- Revisar os esforços de gerenciamento de riscos em produtos semelhantes.
- Examinar documentos ou bancos de dados de lições aprendidas. - Examinar especificações técnicas e requisitos de projeto.
A meta do passo identificação de riscos é que a equipe crie uma lista de riscos que eles percebem. Essa lista deve ser abrangente, cobrindo todas as áreas do projeto. A detecção agressiva e antecipada de riscos é importante porque é tipicamente mais fácil, mais barato, e menos traumático para fazer mudanças e corrigir os esforços durante as fases iniciais ao invés das fases posteriores do projeto.
A identificação de riscos produz listas de riscos específicos que podem comprometer o sucesso do projeto (BOEHM, 1991). As entradas para o passo identificação de riscos são constituídos pelo conhecimento disponível dos riscos gerais e específicos em áreas relevantes como negócio, técnico, ambiental e organizacional. Considerações adicionais são a experiência da equipe, a abordagem vigente na organização para riscos na forma de políticas, orientações, modelos ou procedimentos, e a informação disponível sobre o projeto até o momento, incluindo o histórico do projeto e o estado atual. A equipe pode escolher considerar outras entradas, desde que sejam relevantes para a identificação de riscos. No início do projeto, é recomendado utilizar brainstorming de grupo, sessões facilitadas, ou até mesmo workshops formais para coletar informações sobre as percepções de riscos e oportunidades da equipe do projeto e dos envolvidos no projeto. Esquemas de classificação de mercado como a taxonomia de risco do Software Engineering Institute (SEI), listas de verificação (checklists) de projeto, relatórios de sumários de projetos
