FACULDADE ALVES FARIA (ALFA) COORDENAÇÃO DE PÓS … Figura 7: Ciclo de Vida do Scrum. Fonte:...

FACULDADE ALVES FARIA (ALFA)

COORDENAÇÃO DE PÓS-GRADUAÇÃO E PESQUISA

MESTRADO PROFISSIONAL EM DESENVOLVIMENTO

REGIONAL

Marcelo Caixeta

INVESTIGAÇÃO PARA UMA PROPOSTA DE UM

MÉTODO ÁGIL PARA IDENTIFICAÇÃO DE RISCOS EM

PROJETOS DE TI

GOIÂNIA

2011

FACULDADE ALVES FARIA (ALFA)

COORDENAÇÃO DE PÓS-GRADUAÇÃO E PESQUISA

MESTRADO PROFISSIONAL EM DESENVOLVIMENTO

REGIONAL

Marcelo Caixeta



PROJETOS DE TI

Dissertação apresentada ao Programa de Pós-Graduação

do Mestrado Profissional em Desenvolvimento Regional

das Faculdades Alves Faria como requisito para obtenção

do Título de Mestre, sob a orientação do Prof. Dr. Bento

A. Costa Filho.

Linha de pesquisa:

Gestão Estratégica de Empreendimentos

GOIÂNIA

2011

FACULDADE ALVES FARIA

MESTRADO EM DESENVOLVIMENTO REGIONAL

Marcelo Caixeta



PROJETOS DE TI

AVALIADORES:

__________________________________________________________ Prof. Dr. Bento A. Costa Filho

(Orientador)

__________________________________________________________ Prof. Dr. Fernando de Rosa

__________________________________________________________ Prof. Dr. Ricardo Antônio Gonçalves Teixeira

GOIÂNIA

2011

PARADOXO DE COBB

We know why projects fail,

we know how to prevent their failure –

so why do they still fail?

(Martin Cobb - Treasury Board of Canada Secretariat)

“Nós sabemos por que os projetos falham,

Sabemos como prevenir seu fracasso,

Então por que eles continuam falhando?”

AGRADECIMENTOS

Em primeiro lugar, agradeço a Deus por ter me concedido a oportunidade e as

condições de desenvolver esse trabalho.

A minha família, esposa e filhos que foram mais que companheiros, foram um exemplo

de compreensão e paciência, agradeço pelos finais de semana que ficaram comigo, ou melhor,

sem a minha companhia, à minha esposa, pela leitura do trabalho, pelo seu amor e apoio que,

sem dúvida, foram essenciais para a conclusão desse trabalho.

Ao meu orientador, Dr. Bento Alves da Costa Filho, agradeço a credibilidade, a atenção,

a paciência e os ensinamentos que me passou durante o decorrer deste estudo e que foram

decisivos para o sucesso deste trabalho.

Aos amigos do mestrado e em especial aos amigos da Comdata, também colegas do

mestrado, pelo companheirismo, pela receptividade e pelas dicas sempre bem vindas.

Aos professores do mestrado que contribuíram de forma significativa com seus

conhecimentos para que este trabalho se concretizasse. Em especial gostaria de agradecer ao

Prof. Ricardo Teixeira, pela atenção e pelos ensinamentos preciosos, que contribuíram

significativamente para a conclusão deste.

Às empresas que permitiram a realização da pesquisa de campo, fornecendo

informações de suas experiências práticas, necessárias para a para a conclusão deste trabalho.

Enfim, agradeço a todas as pessoas que comigo contribuíram, de forma direta e indireta,

e que torceram pelo meu sucesso nesta jornada.

Muito obrigado !

RESUMO

O gerenciamento de riscos é considerado por alguns autores como um processo-chave e que

faz a diferença em gerenciamento de projetos, além de ser atualmente de grande importância

para governos, economias e empresas. A presente dissertação partiu do estudo de diversos

padrões de conhecimento e metodologias de gerenciamento de projetos, tanto de métodos

“tradicionais” quanto de métodos ágeis. Foram estudados também os processos de

gerenciamento de riscos destes métodos. Durante os estudos foi possível conhecer e

apresentar alguns modelos de gestão de riscos em projetos de desenvolvimento de software já

estudados por outros autores. A partir daí passou-se à análise de alguns métodos utilizados

para a identificação de riscos em projetos. Ao concluir os estudos citados e, após a pesquisa

de campo, foi possível conhecer a realidade de algumas empresas consideradas como

referência / líderes em sua área de atuação, observando-se na prática de que forma elas

utilizam tanto métodos “tradicionais” como métodos ágeis para gerenciamento de projetos e

de riscos. Por fim, a partir da investigação realizada, foi elaborada a proposta de um método

ágil para a identificação de riscos em projetos de desenvolvimento de software, alinhando os

conhecimentos dos métodos “tradicionais” e dos métodos ágeis.

Palavras-chave: Risco, Gerência de Risco, Gerência de Projetos, Desenvolvimento de

Software, Tecnologia da Informação e Comunicação.

ABSTRACT

Risk management is considered by some authors as a key process that makes the difference

and project management, and is currently of great importance to governments, businesses and

economies. This work was based on the study of patterns of knowledge and methodologies of

project management, both "traditional" and of "agile." We also studied the processes of risk

management of these "methods". During the studies was possible to meet and present some

models of risk management in software development projects already studied by other

authors. From there it moved to present some methods used to identify risks in projects. By

completing the studies mentioned above and after the fieldwork it was possible to know the

reality of some companies, taken as a reference / leaders in their field and that allowed us to

observe in practice how they use both "traditional" as "methods agile "project management

and risk. And finally, from the investigation, is a proposal for an agile method to identify risks

in software development projects, aligning the knowledge of "traditional" and "agile."

Keywords: Risk, Risk Management, Project Management, Software Development,

Information Technology and Communication.

LISTA DE FIGURAS

Figura 1: Ciclo de Vida. Fonte: PMI (2008, p.40) ........................................................................ 31

Figura 2: Visão geral das áreas de conhecimento em gerenciamento de projetos e os seus

processos. Fonte: PMI (2008) ..................................................................................... 33

Figura 3: Ciclo de Vida – PRINCE2. Fonte: SIEGELAUB (2004, p.3). ...................................... 35

Figura 4: Processos e Componentes “Áreas de conhecimento” – PRINCE2. ............................... 37

Figura 5: Ciclo de Vida – P2M. Fonte: PMAJ (2005, p.27).......................................................... 39

Figura 6: Torre de gerenciamento de projetos – P2M. Fonte: PMAJ (2005, p.11) ....................... 40

Figura 7: Ciclo de Vida do Scrum. Fonte: adaptado de VICENTE (2010, p.25) .......................... 47

Figura 8: Fases do APM. Fonte: HIGHSMITH, 2004 apud CONFORTO (2009, p.47) .............. 52

Figura 9: Ciclo de vida de um projeto. Fonte: DSDM (GIUFFRA; VILAIN (2010, p.4) ............ 55

Figura 10: Resumo dos processos de gerenciamento dos riscos do projeto – PMBOK (4ª

edição). Fonte: PMI (2008, p. 227)............................................................................. 64

Figura 11: Procedimento de gerência de Risco. Fonte: PRINCE2 (2010, p.7) ............................. 66

Figura 12: Visão geral do gerenciamento de riscos. Fonte: PMAJ (2005, p.138)......................... 67

Figura 13: Processo de gerenciamento de riscos. Fonte: PMAJ (2005, p.144) ............................. 68

Figura 14: Processos de gerenciamento de riscos. Fonte: DSDM Version (4.2) .......................... 73

Figura 15: Identificação de Riscos. Fonte: KOSCHO; RIES (2009, p.2) ..................................... 85

Figura 16: Processo de Identificação de Riscos. Fonte: CARR et al. (1993, p.13) ....................... 85

Figura 17: Fontes clássicas de problemas a considerar. Fonte: PMI (2008, p.176) ...................... 97

Figura 18: Segmento sobre o ambiente expandido por brainstorming. Fonte: PMI (2008,

p.176) .......................................................................................................................... 98

Figura 19: Processo de definição de projeto. Fonte: CHAPMAN & WARD (1997) apud

MACHADO (2002, p.42) ........................................................................................... 99

Figura 20: Padrões de conhecimento, normas e métodos de gerenciamento de projetos. Fonte:

Elaboração do autor. ................................................................................................. 100

Figura 21: Processos de gestão de riscos. Fonte: Elaboração do autor. ...................................... 101

Figura 22: Métodos de identificação de riscos. Fonte: Elaboração do autor. .............................. 102

Figura 23: Método adotado para identificação e classificação dos fatores de riscos. Fonte:

Elaboração do autor. ................................................................................................. 103

Figura 24: Abordagem adotada para propor um método ágil para a identificação de riscos em

projetos de TI. Fonte: Elaboração do autor. ............................................................. 103

Figura 25: Abordagem do trabalho em relação à metodologia de pesquisa. Fonte: Elaboração

do autor. .................................................................................................................... 104

Figura 26: Empresas participantes do estudo. Fonte: Elaboração do autor. ................................ 108

Figura 27: Esquema de um método ágil de identificação de riscos. Fonte: Elaboração do autor.130

LISTA DE GRÁFICOS

Gráfico 1: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação, segundo as

faixas de pessoal ocupado – Brasil – 2006 ................................................................. 18


faixas de faturamento - Brasil – 2006 ......................................................................... 18


grandes regiões - Brasil – 2006 .................................................................................. 19

Gráfico 4: Distribuição percentual das empresas nas atividades do setor de Tecnologia da

Informação e Comunicação – Brasil – 2003-2006 ..................................................... 20

Gráfico 5: Distribuição percentual do pessoal ocupado nas atividades do setor de Tecnologia

da Informação e Comunicação – Brasil – 2003-2006 ................................................ 21

Gráfico 6: Participação dos produtos e serviços de informática no total da receita de serviços

de informática – Brasil – 2003-2006 .......................................................................... 22

Gráfico 7: Participação dos produtos e serviços de desenvolvimento de softwares sob

encomenda no total da receita de serviços de desenvolvimento de softwares sob

encomenda - Brasil – 2003-2006 ................................................................................ 22

Gráfico 8: Avaliação do sucesso de projetos de Tecnologia da Informação - 1994-2009 ............ 26

Gráfico 9: Avaliação do sucesso de projetos de Tecnologia da Informação no Exterior de

1994-2009, comparado com avaliação de sucesso de projetos de Tecnologia da

Informação no Brasil-2006 e 2008 ............................................................................. 26

Gráfico 10: Principais causas de fracasso em projetos de TI - Brasil-2006 .................................. 27

Gráfico 11: Principais causas de fracasso em projetos de TI - Brasil-2008 .................................. 27

Gráfico 12: Quociente Locacional por Região da abordagem para gerenciamento de riscos ..... 151

Gráfico 13: Quociente Locacional por Estado das regiões que apresentaram QLRegião ≥ 1 e que

utilizam abordagem para gerenciamento de riscos baseada em uma metodologia

formal, estruturada por políticas, procedimentos e formulários ............................... 154

LISTA DE TABELAS

Tabela 1: População e Produto Interno Bruto a preços correntes e Produto Interno Bruto per

capita segundo as Grandes Regiões, Unidades da Federação e municípios – 2007 ... 23

Tabela 2: Comparativo dos métodos “tradicionais” de gerência de projetos ................................ 43

Tabela 3: Atores e responsabilidades do SCRUM. ....................................................................... 46

Tabela 4: Valores centrais do APM ............................................................................................... 51

Tabela 5 – Princípios mestres do APM ......................................................................................... 51

Tabela 6: Comparativo dos métodos ágeis de gerência de projetos .............................................. 58

Tabela 7: Correspondência entre as abordagens tradicional e ágil de GP ..................................... 60

Tabela 8: Principais características entre GP de software, tradicional e ágil. ............................... 60

Tabela 9: Diferenças de abordagens de GP tradicional e ágil. ...................................................... 61

Tabela 10: Comparativo entre gerenciamento de projetos tradicional e gerenciamento de

projetos ágil. ............................................................................................................... 62

Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil ...................... 75

Tabela 12: Modelos/Abordagem de gestão de riscos em projetos de desenvolvimento de

software....................................................................................................................... 78

Tabela 13: Comparativo das abordagens de Gerenciamento de riscos para desenvolvimento de

software por Gusmão e Moura (2004) ........................................................................ 79


software por Oliveira G. (2006) ................................................................................. 80


software por Oliveira G. (2006) ................................................................................. 80

Tabela 16: Taxonomia de riscos em desenvolvimento de software do SEI. ................................. 86

Tabela 17: Modelo da Lista de riscos para sistemas de informação ............................................. 89

Tabela 18: Fatores de risco de desenvolvimento de software integrados...................................... 90

Tabela 19: Pontuação atribuída ao item probabilidade do roteiro de análise de riscos ............... 108

Tabela 20: Pontuação atribuída ao item impacto do roteiro de análise de risco ......................... 109

Tabela 21: Codificação das empresas pesquisadas...................................................................... 112

Tabela 22: Perfil dos entrevistados .............................................................................................. 113

Tabela 23: Perfil das empresas pesquisadas ................................................................................ 114

Tabela 24: Processos/Abordagens adotadas para gerenciamento de riscos pelas empresas

pesquisadas ............................................................................................................... 116

Tabela 25: Principais problemas/dificuldades para gerenciar riscos citados pelas empresas

pesquisadas ............................................................................................................... 118

Tabela 26: Classificação dos Fatores de Riscos integrados para desenvolvimento de software,

quanto às categorias propostas pelo SEI ................................................................... 120

Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas ............................... 123

Tabela 28: Matriz de Informações obtidas a partir do Estudo de Benchmarking em

Gerenciamento de Projetos no Brasil – 2008. .......................................................... 146

Tabela 29: Identificação das variáveis utilizadas no QL dentro da Matriz de Informações

obtidas a partir do Estudo de Benchmarking em Gerenciamento de Projetos no

Brasil – 2008 ............................................................................................................. 147

Tabela 30: Abordagem adotada pelas empresas brasileiras para gerenciamento de riscos - por

região ........................................................................................................................ 149

Tabela 31: Quociente Locacional por Região da abordagem para gerenciamento de riscos ...... 150


estado ........................................................................................................................ 152

Tabela 33: Quociente Locacional da abordagem para gerenciamento de riscos por Estado ....... 153

Tabela 34: Lista de riscos para sistemas de informação .............................................................. 156

Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy

(2010) ........................................................................................................................ 165

Tabela 36: Fatores de Riscos de desenvolvimento de software citados por Mulcahy (2010) ..... 172

Tabela 37: Fatores de Riscos considerados duplicados ............................................................... 173

Tabela 38: Fatores de Riscos integrados para desenvolvimento de software.............................. 176

Tabela 39: Análise dos fatores de riscos segundo a empresa “A”............................................... 178

Tabela 40: Análise dos fatores de riscos segundo a empresa “B” ............................................... 182

Tabela 41: Análise dos fatores de riscos segundo a empresa “C” ............................................... 185

Tabela 42: Análise dos fatores de riscos segundo a empresa “D”............................................... 189

Tabela 43: Análise dos fatores de riscos segundo a empresa “E” ............................................... 193

Tabela 44: Análise dos fatores de riscos segundo a empresa “F” ............................................... 196

Tabela 45: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de

Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas ................ 201


Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas ......... 204


Execução do ciclo de vida do projeto, segundo as empresas pesquisadas ............... 206


Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas

pesquisadas ............................................................................................................... 209


Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas ........ 212


Avaliação Pós-Encerramento do ciclo de vida do projeto, segundo as empresas

pesquisadas ............................................................................................................... 215

SUMÁRIO

LISTA DE FIGURAS .................................................................................................................................... 17

LISTA DE GRÁFICOS ................................................................................................................................. 18

LISTA DE TABELAS ................................................................................................................................... 19

INTRODUÇÃO ............................................................................................................................................. 11

JUSTIFICATIVA ................................................................................................................................................... 11 PROBLEMATIZAÇÃO .......................................................................................................................................... 13 PRESSUPOSTOS E QUESTÕES DA PESQUISA ......................................................................................................... 14 OBJETIVOS ........................................................................................................................................................ 14

Geral ............................................................................................................................................................ 14 Específicos ................................................................................................................................................... 14

ORGANIZAÇÃO DA DISSERTAÇÃO / ESTRUTURA DO TRABALHO ......................................................................... 15

1 ANÁLISE DO CONTEXTO DO GERENCIAMENTO DE RISCOS EM PROJETOS DE

TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO (TIC) ......................................................... 16

1.1 A ANÁLISE ............................................................................................................................................... 16 1.2 ELEMENTOS SOCIOECONÔMICOS DO SETOR DE TIC NO BRASIL ............................................................... 17 1.3 ANÁLISE DE PROJETOS DESENVOLVIDOS NO BRASIL E NO EXTERIOR ...................................................... 24 1.4 SÍNTESE DA GESTÃO DE RISCOS NO BRASIL ............................................................................................. 28

2 FUNDAMENTAÇÃO TEÓRICA............................................................................................................ 30

2.1 PADRÕES DE CONHECIMENTO E METODOLOGIAS DE GERÊNCIA DE PROJETOS ........................................... 30 2.1.1 Métodos tradicionais ..................................................................................................................... 30

2.1.1.1 Project Management Book of Knowledge (PMBOK) ................................................................................ 30 2.1.1.2 Project in a Controlled Environment (PRINCE2) ..................................................................................... 34 2.1.1.3 A Guidebook for Project and Program Management for Enterprise Innovation (P2M) ........................... 38 2.1.1.4 Comparativo dos métodos ―tradicionais‖ ................................................................................................. 43

2.1.2 Métodos ágeis ................................................................................................................................ 44 2.1.2.1 Scrum......................................................................................................................................................... 44 2.1.2.2 Agile Project Management (APM) ............................................................................................................ 50 2.1.2.3 Dynamic Systems Development Method (DSDM) ..................................................................................... 54 2.1.2.4 Comparativo dos métodos ágeis ................................................................................................................ 57

2.1.3 Comparativo dos métodos ―tradicional‖ e ágeis .......................................................................... 59 2.2 PROCESSOS DE GERENCIAMENTO DE RISCOS ............................................................................................ 63

2.2.1 Métodos ―tradicionais‖ ................................................................................................................. 63 2.2.1.1 Abordagem do Project Management Book of Knowledge (PMBOK) ........................................................ 63 2.2.1.2 Abordagem do Project In a Controlled Environment (PRINCE2)............................................................. 64 2.2.1.3 Abordagem do Guidebook for Project and Program Management for Enterprise Innovation (P2M) ...... 66

2.2.2 Métodos ágeis ................................................................................................................................ 69 2.2.2.1 Abordagem do Scrum ................................................................................................................................ 69 2.2.2.2 Abordagem do Agile Project Management (APM) .................................................................................... 71 2.2.2.3 Abordagem do Dynamic Systems Development Method (DSDM) ............................................................. 72

2.2.3 Comparativo dos métodos ............................................................................................................. 74 2.3 MODELOS DE GESTÃO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE ........................... 78 2.4 MÉTODOS PARA IDENTIFICAÇÃO DE RISCOS ............................................................................................. 83

2.4.1 Taxonomia de Riscos ..................................................................................................................... 85 2.4.2 Lista de Verificação / Check-list .................................................................................................... 87 2.4.3 Fatores de risco ............................................................................................................................. 90 2.4.4 Brainstorming ................................................................................................................................ 94 2.4.5 Análise de Informações históricas ................................................................................................. 94 2.4.6 Comparação análoga .................................................................................................................... 95 2.4.7 Análise de premissas ..................................................................................................................... 95 2.4.8 Entrevista com especialistas .......................................................................................................... 96 2.4.9 Análise da causa-raiz .................................................................................................................... 97

2.4.10 Técnica Delphi .......................................................................................................................... 99

3 METODOLOGIA DA PESQUISA ........................................................................................................ 100

3.1 INSTRUMENTO DE COLETA DE DADOS PARA PESQUISA DE CAMPO .......................................................... 105 3.2 EMPRESAS PARTICIPANTES E COLETA DE DADOS E INFORMAÇÕES ......................................................... 107 3.3 FORMA DE TABULAÇÃO E ANÁLISE DOS RESULTADOS ............................................................................ 110 3.4 ROTEIRO DE ANÁLISE DE RISCOS ............................................................................................................ 111

4 ANÁLISE DAS INFORMAÇÕES ......................................................................................................... 112

4.1 PERFIL DOS ENTREVISTADOS .................................................................................................................. 112 4.2 PERFIL DAS EMPRESAS PESQUISADAS ..................................................................................................... 113 4.3 PROCESSOS/ABORDAGENS ADOTADAS PARA GERENCIAMENTO DE RISCOS ............................................ 115 4.4 PRINCIPAIS PROBLEMAS / DIFICULDADES PARA GERENCIAR RISCOS ....................................................... 117 4.5 ANÁLISE DOS FATORES DE RISCOS ......................................................................................................... 118

4.5.1 Quanto às fases do ciclo de vida do projeto ................................................................................ 119 4.5.2 Quanto às categorias de riscos .................................................................................................... 119 4.5.3 Quanto ao grau de exposição dos fatores de riscos .................................................................... 122

4.6 QUALIDADE DAS INFORMAÇÕES OBTIDAS .............................................................................................. 127 4.7 SÍNTESE DOS RESULTADOS .................................................................................................................... 128

5 PROPOSTA DE UM MÉTODO ÁGIL DE IDENTIFICAÇÃO DE RISCOS ..................................... 130

CONCLUSÃO ............................................................................................................................................. 133

CONTRIBUIÇÕES .............................................................................................................................................. 134 LIMITAÇÕES DA PESQUISA ............................................................................................................................... 134 TRABALHOS FUTUROS ..................................................................................................................................... 135

REFERÊNCIAS .......................................................................................................................................... 136

APÊNDICE I- UTILIZAÇÃO DO QUOCIENTE LOCACIONAL PARA DETERMINAÇÃO DA

REGIÃO DE ANÁLISE DA DISSERTAÇÃO. ..................................................................................... 143

APÊNDICE II – LISTA DE RISCOS PARA SISTEMAS DE INFORMAÇÃO........................................ 156

APÊNDICE III – ANÁLISE SEMÂNTICA DOS FATORES DE RISCOS ............................................... 165

APÊNDICE IV - ANÁLISE DOS FATORES DE RISCOS SEGUNDO AS EMPRESAS PESQUISADAS.

................................................................................................................................................................ 178

APÊNDICE V- CLASSIFICAÇÃO DOS FATORES DE RISCOS SEGUNDO AS FASES DO CICLO DE

VIDA DO PROJETO, DE ACORDO COM AS EMPRESAS PESQUISADAS. .................................. 201

APÊNDICE VI - ROTEIRO DE ANÁLISE DE RISCO ............................................................................ 216

11

INTRODUÇÃO

Justificativa

O tema abordado no presente trabalho surgiu quando do desenvolvimento de um

projeto denominado “Tele-Matrícula” que consistia na realização de matrículas dos alunos da

rede municipal de ensino da cidade de Goiânia, por telefone. Apesar de ter mais de vinte

anos de experiência na área de Tecnologia da Informação, com mais de quinze mil horas em

projetos em diversas áreas e de um livro publicado sobre gerência de projetos, foi a primeira

vez que o autor teve a oportunidade de ver na prática a grande diferença que o gerenciamento

de riscos pode fazer para um projeto. Nesse projeto a equipe tinha quarenta e cinco dias,

exatos, para montar um Call Center completo, incluindo mobiliário, atendentes, sistemas,

softwares, equipamentos, redes de comunicação de voz e dados dentre vários outros itens.

Esse desafio permitiu comprovar que o gerenciamento de riscos é fundamental para o

sucesso do projeto.

A gestão de riscos, de acordo com Mulcahy (2010), é a chave para fazer grande

diferença em projetos. Conforme Adams (2009), o gerenciamento de riscos é, atualmente, de

grande importância para governos, economias e empresas.

Vargas (2009), ao considerar o gerenciamento de riscos como um dos aspectos mais

complexos dentro do gerenciamento de projetos, relatou que “em um mercado onde não

existe mais rotina, simplesmente tudo é projeto”.

Todo projeto, seja de pequeno, médio ou de grande porte, geralmente envolve algum

tipo de incerteza ou risco, podendo estar relacionado a diversos fatores, tais como a perda de

pessoal qualificado da equipe do projeto, utilização de novas tecnologias, mudanças

inesperadas (como por exemplo, escopo) seja por parte do cliente, do mercado ou do governo

(como por exemplo, legislação) ou até mudanças organizacionais, entre outros. Para Hunter e

Westerman (2008), a área de Tecnologia da Informação (TI) é fundamental para o sucesso

dos negócios de muitas empresas; no entanto, incidentes de risco nesta área envolvem custos

elevados, podendo prejudicar as partes envolvidas e até mesmo a reputação da empresa.

Geralmente os projetos relacionados a TI diferenciam-se de outros por apresentarem

características intrínsecas a esta área, tais como a complexidade dos projetos, a dificuldade de

visualização clara do produto final que está sendo desenvolvido, a necessidade de

envolvimento e participação do usuário (cliente), o levantamento preciso dos requisitos dos

usuários, a resistência a mudanças, a escolha da tecnologia a ser utilizada etc. Analisando

12

esses aspectos, é possível vislumbrar a ocorrência de riscos específicos tais como: sistemas

implantados com atraso ou a um custo acima do orçado, sistemas cujas funcionalidades não

atendem às reais necessidades de seus usuários, tornando-se desnecessários ou gerando

retrabalho.

Hunter e Westerman (2008) definiram os riscos relacionados à área de TI em quatro

tipos: (1) disponibilidade, (2) acesso, (3) precisão e (4) agilidade. Analisando esse aspecto da

classificação dos riscos é possível, também, descrever um método para facilitar a

identificação sistemática e recorrente dos riscos associados ao desenvolvimento de um

projeto de software (CARR et al., 1993) e riscos relacionados à operação de software

(GALLAGHER et al. 2005).

Não se deve confundir gerenciamento de riscos com restrição. Segundo o Project

Management Institute - PMI (2008, p. 323) o gerenciamento de riscos do projeto inclui os

processos relacionados com o planejamento, identificação, análise, elaboração de respostas,

monitoramento e controle dos riscos em um projeto enquanto que restrição é o estado, a

qualidade ou o sentido de estar restrito a uma determinada ação ou inatividade. Uma

restrição ou limitação aplicável, interna ou externamente, afetará o desempenho do projeto

ou de um processo. Por exemplo, uma restrição do cronograma é qualquer limitação ou

condição que afeta o momento em que uma atividade do cronograma pode ser agendada e

geralmente está na forma de datas fixas impostas.

Todo projeto visa algum tipo de retorno, seja ele financeiro ou um ganho social no qual

os riscos estarão presentes. Com base nisso as partes envolvidas devem saber quantificar o

balanceamento entre risco e retorno (CROUHY et al., 2008), ou seja, os interessados devem

avaliar se vale a pena correr altos riscos para um retorno pequeno ou investir muito tempo e

dinheiro num risco que, na ocorrência, causaria um impacto de pequena monta no projeto.

Mesmo sendo quase impossível prever tudo o que pode vir a prejudicar um projeto

(CAIXETA, 2006), alguns métodos podem ser adotados para melhorar o gerenciamento de

riscos, sendo a identificação um dos fatores críticos dos riscos envolvidos nos projetos. Esta

compreende uma das ações que contribuem para um gerenciamento de riscos eficaz.

Além de um estudo que busque abordar os diferentes métodos de gerenciamento de

projetos, pretende-se, com este trabalho, realizar uma investigação para uma proposta de um

método ágil de identificação de riscos em projetos de Tecnologia da Informação e

Comunicação (TIC) e verificar se a utilização efetiva desta pode ser considerada como um

dos fatores chave para se alcançar a conclusão satisfatória de um projeto em termos de

custos, prazos e qualidade.

13

O gerenciamento de riscos como será demonstrado pode trazer algumas contribuições

para a melhoria de projetos, tais como: redução de custos, aumento da qualidade do(s)

produtos(s), aumento das chances de sucesso, melhoraria da qualificação da mão-de-obra e

aumento da satisfação do cliente.

Este estudo, que se baseia nos pressupostos dos métodos ágeis, apresenta alternativas de

métodos eficazes de combate aos riscos, sem que se tenha que percorrer um processo

completo de gerenciamento de projetos.

Problematização

A Gerência de Projetos e sua evolução, na área de Engenharia de Software, está

associada com o tratamento dos riscos nos ambientes de desenvolvimento de software.

Muitos modelos e abordagens foram apresentados e utilizados nos últimos 20 anos. Contudo,

uma das grandes fraquezas dessas abordagens, até o momento, foi ter negligenciado os riscos

em projetos (GUSMÃO, 2007).

De acordo com a Pesquisa de Benchmarking1 sobre Gerenciamento de Projetos no

Brasil – 2008 realizada pelo PMI-CHAPTERS BRASILEIROS (2008), quando perguntado às

empresas sobre qual a abordagem adotada para gerenciamento de riscos em projetos, 69%

(mais de 2/3) disseram que não tratavam riscos em seus projetos ou o faziam informalmente

conforme interesse ou necessidade do responsável pelo projeto e apenas 31%

(aproximadamente 1/3) tratavam riscos baseados em uma metodologia formal.

Esta dissertação, portanto, parte do pressuposto de que há negligenciamento de riscos

nos projetos pelas empresas de TI e, como tal, apresenta algumas questões que se colocam

abaixo:

Qual o motivo que leva as empresas a não adotarem formalmente o

gerenciamento de riscos ?

Quais são os principais problemas / riscos / categorias de riscos existentes nos

projetos em empresas de TI ?

Como os riscos são identificados, planejados e gerenciados nas empresas e

como as metodologias atuais propõem isto?

1Benchmarking “envolve a comparação de práticas de projetos reais ou planejados com as de projetos

comparáveis para identificar as melhores práticas, gerar idéias para melhorias e fornecer uma base para medir o

desempenho. Esses outros projetos podem estar na organização executora ou fora dela, e podem estar dentro da

mesma área de aplicação ou em outra área” (PMI, 2008, p. 167).

14

Se houver um método ágil de gerenciamento de riscos, isso facilitará sua

adoção pelas empresas ?

Pressupostos e questões da pesquisa

Com base na pesquisa anunciada, parte-se do princípio de que as empresas de TIC

negligenciam riscos em seus projetos, por alguns motivos, abaixo anunciados:

desconhecimento dos benefícios que o gerenciamento de risco proporciona;

falta de planejamento dos riscos em projetos;

inadequação de metodologia de gerenciamento de projetos;

falhas na identificação de riscos corretamente;

falta de estrutura (de pessoal, de recursos financeiros e materiais) que atenda às

exigências básicas de sua utilização.

Objetivos

Geral

Realizar um estudo na região metropolitana de Goiânia e Brasília a respeito de

gerenciamento de riscos por meio de uma investigação e avaliação sobre riscos em projetos

de TI, e propor reflexões para apresentação de um método ágil para identificação de riscos.

Específicos

a. Identificar métodos “tradicionais” de gerenciamento de projetos.

b. Identificar métodos ágeis de gerenciamento de projetos.

c. Identificar padrões de conhecimento, metodologias ou normas para a área de TI,

sobre gerenciamento de riscos em projetos.

d. Verificar como os padrões de conhecimento, metodologias ou normas tratam o

gerenciamento de riscos.

e. Levantamento e atualização de uma taxonomia de riscos, atualizada, para projetos de

TI.

f. Avaliar como as empresas de TI, pesquisadas, identificam e tratam os riscos em seus

projetos.

15

g. Propor uma priorização de riscos para projetos de TI nas empresas pesquisadas.

h. A partir da investigação realizada fazer uma proposta de um método ágil de

identificação de riscos para projetos de TI.

Organização da dissertação / Estrutura do trabalho

Esta dissertação está organizada em cinco capítulos.

No Capítulo 1 é mostrada uma visão geral do contexto regional sobre gerência de

projetos em empresas de tecnologia da informação e comunicação (TIC). Essa visão geral

será exposta a partir do levantamento de alguns elementos socioeconômicos sobre o setor de

TIC no Brasil e o potencial de desenvolvimento da região Centro-Oeste, com destaque para as

cidades de Brasília, no Distrito Federal, Goiânia e Aparecida de Goiânia ambas no Estado de

Goiás. Será mostrada uma análise de projetos de TIC desenvolvidos no Brasil e no exterior.

O Capítulo 2 apresenta a fundamentação teórica da dissertação, em que serão mostrados

padrões de conhecimento e metodologias de gerência de projetos divididos em “métodos

tradicionais”2 e métodos ágeis, logo após é feita uma comparação entre os mesmos. São

apresentados, ainda, os processos de gerenciamento de riscos para os métodos “tradicionais” e

métodos ágeis, bem como uma comparação entre os mesmos. São abordados alguns modelos

de gestão de riscos em projetos de desenvolvimento de software e também uma comparação

entre eles. Após isso são mostrados os métodos para identificação de riscos.

No Capítulo 3 são definidos os detalhamentos da metodologia da pesquisa adotada para

este trabalho.

O Capítulo 4 apresenta a análise das informações da pesquisa, apresentando o perfil dos

entrevistados, o perfil das empresas, um levantamento sobre o gerenciamento de riscos em

projetos nessas empresas, e sua abordagem a diversos fatores de riscos apresentados.

O Capítulo 5 apresenta uma proposta de um método ágil para identificação de riscos em

projetos de desenvolvimento de software a partir da pesquisa de campo e do levantamento

bibliográfico realizado.

Finalmente, na conclusão, são apresentas as contribuições deste trabalho, as limitações

encontradas e a perspectiva de trabalhos futuros.

2 A expressão “métodos tradicionais” foi utilizada aqui para diferenciar alguns padrões de conhecimento e

metodologias de gerência de projetos dos métodos ágeis, já conhecidos com este nome.

16

1 ANÁLISE DO CONTEXTO DO GERENCIAMENTO DE RISCOS EM

PROJETOS DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO (TIC)

1.1 A Análise

Este capítulo discute os resultados de pesquisas recentes sobre projetos de Tecnologia

da Informação e Comunicação (TIC), onde pretende-se apresentar uma análise do contexto

regional em projetos de TIC, que pode mostrar aos profissionais da área a importância do

setor e o cenário de sucessos e fracassos de projetos.

Para realizar a análise do contexto regional em projetos de TIC, foram utilizados

elementos socioeconômicos. Os elementos sociais são aqueles que determinam as condições

de vida dos setores da sociedade: emprego, renda, serviços, etc. Já os elementos econômicos

são aqueles referentes à estrutura setorial econômica: setor primário, secundário e terciário.

Neste sentido focaremos os estudos no setor terciário.

A análise regional foi realizada a partir de estudo dos elementos socioeconômicos e da

avaliação de projetos desenvolvidos no Brasil e no exterior. Para Simões (2003), o

desenvolvimento econômico deve ser analisado, levando-se em conta duas variáveis

fundamentais que são espaço e tempo, pois não existe nada que não se localize muito concreta

e precisamente no tempo e no espaço. A análise dos elementos socioeconômicos é

apresentada por meio de uma visão geral sobre o setor de TIC no Brasil e o potencial da

região Centro-Oeste a partir de dados da população e do PIB, procurando caracterizar a região

compreendida por Brasília, Goiânia e Aparecida de Goiânia. Na análise da avaliação de

projetos desenvolvidos no Brasil e no exterior são apresentadas pesquisas comparando

projetos desenvolvidos nestes universos.

No contexto do presente trabalho, os termos (a) tecnologia da informação e

comunicação e (b) gerenciamento de riscos terão significados, conforme abaixo:

Tecnologia da Informação e Comunicação (TIC): é um conjunto de recursos

tecnológicos que, se estiverem integrados entre si, podem proporcionar a

automação e/ou a comunicação de vários tipos de processos existentes nos

negócios, no ensino e na pesquisa científica, na área bancária e financeira etc,

ou seja, são tecnologias usadas para reunir, distribuir e compartilhar

informações, como por exemplo, sites da Web, equipamentos de informática

(hardware e software), telefonia, quiosques de informação e balcões de

serviços automatizados (GLOSSÁRIO DE TI, 2009);

17

Gerenciamento de Riscos: o gerenciamento de riscos do projeto inclui os

processos relacionados com o planejamento, identificação, análise, elaboração

de respostas, monitoramento e controle dos riscos em um projeto (PMI, 2008).

1.2 Elementos socioeconômicos do setor de TIC no Brasil

O setor de TIC no Brasil, principal interesse deste estudo, vem assumindo maior

relevância em função do progresso tecnológico que se observa em níveis nacional e global

(IBGE, 2009). Aqui será mostrado em destaque o potencial da região Centro-Oeste a partir de

dados da população e do PIB, procurando caracterizar a região compreendida por Brasília,

Goiânia e Aparecida de Goiânia.

Estudo publicado pelo IBGE sobre o setor de TIC no Brasil nos anos de 2003 a 2006

(IBGE, 2009), apresenta um panorama em nível nacional e busca destacar as especificidades

desse setor e suas características estruturais e econômicas, com ênfase no número de

empresas, empregos gerados, custos, receitas, geração de valor adicionado, produtividade e

comércio exterior.

Com relação ao mencionado estudo do IBGE, foram abordados os assuntos referentes à

quantidade de empresas, quantidade de pessoal ocupado, pessoal ocupado por porte de

empresas, produtividade do setor por porte de empresas, pessoal ocupado por grandes regiões

do Brasil, número de empresas dos setores econômicos (indústria, comércio e serviço) de

TIC, distribuição das empresas nas atividades dos setores de TIC, distribuição do pessoal

ocupado nestas atividades, salário médio mensal dos setores econômicos de TIC, participação

dos produtos e serviços de informática no total da receita de serviços de informática e

participação dos produtos e serviços de desenvolvimento de softwares sob encomenda no total

da receita desse serviço no período de 2003-2006.

Em relação às dimensões do setor no Brasil, o número de empresas do setor de TIC, no

ano de 2006, era formado por 65.754 empresas, apresentando um crescimento de 18,3% em

relação a 2003 quando existiam 55.597 empresas. Neste mesmo período 2003-2006 a

quantidade de pessoal ocupado também cresceu em torno de 40,7% passando de 478.446, em

2003, para 673.024 pessoas ocupadas, em 2006. Comparando as dimensões do setor de TIC

com o universo empresarial brasileiro verifica-se uma estabilidade no total de empresas

passando de 2,4%, em 2003, para 2,5%, em 2006, e um ligeiro crescimento com relação ao

pessoal ocupado passando de 2,6%, em 2003, para 3,0%, em 2006.

18

Gráfico 1: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação,

segundo as faixas de pessoal ocupado – Brasil – 2006

Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no Brasil 2003-2006


segundo as faixas de faturamento - Brasil – 2006


Tanto no Gráfico 1 como no Gráfico 2, percebe-se que a grande maioria do pessoal

ocupado está concentrado em empresas grandes, com 250 ou mais pessoas e com faturamento

acima de 60 milhões de reais. Um fato interessante é que o segundo lugar em percentual de

pessoal ocupado vem exatamente do outro extremo, ou seja, em empresas pequenas, de 0 a 9

pessoas ocupadas e com faturamento de até 2,4 milhões de reais.

19

Conforme Gráfico 3, em 2006, o setor de TIC estava concentrado na região Sudeste,

aparecendo em segundo lugar a região Sul, sendo que as outras três regiões, Norte, Nordeste e

Centro-Oeste apresentam participação relativamente próximas.


segundo as grandes regiões - Brasil – 2006


Enquanto o número de empresas dos setores econômicos do Brasil (indústria, comércio

e serviços) cresceu 14,2%, de 2003-2006, saindo de 2.297.425 empresas em 2003, para

2.624.385 empresas, em 2006, o número de empresas do setor de tecnologia da informação e

comunicação cresceu 18,3%, de 55.597, em 2003, para 65.754, em 2006, ou seja, o setor de

TIC apresentou um crescimento de 4,1% pontos percentuais acima dos demais setores

econômicos do Brasil. De todos os grupos de atividades que compreendem este setor,

percebe-se que a grande maioria das empresas, aproximadamente 90%, está situada no grupo

de atividades de informática (Gráfico 4).

Mais de 55% do pessoal ocupado no setor de TIC estão nas empresas pertencentes ao

grupo de atividades de informática: em segundo lugar, com aproximadamente 26% estão as

empresas que exercem atividades industriais do setor de TIC e em terceiro lugar, com

aproximadamente 14% do pessoal ocupado, estão as empresas de telecomunicações (Gráfico

5).

20

Gráfico 4: Distribuição percentual das empresas nas atividades do setor de Tecnologia

da Informação e Comunicação – Brasil – 2003-2006


O salário médio mensal dos setores econômicos do Brasil (indústria, comércio e

serviços) cresceu 7,1%, no período 2003-2006, saindo de R$ 875,07 para R$ 937,48. No setor

de TIC aconteceu uma redução de 1,54%, no mesmo período, de R$ 2.056,85 para R$

2.025,18, mesmo assim os salários do setor de TIC são 116% superiores, conforme mostra

estudo do IBGE sobre o Setor de Tecnologia da Informação e Comunicação no Brasil 2003-

2006.

Quanto aos produtos relacionados ao grupo de desenvolvimento de softwares sob

encomenda, estes representam aproximadamente um terço do total das receitas do setor; em

segundo lugar aparecem os produtos relacionados ao grupo de desenvolvimento, edição e

licenciamento de softwares prontos para uso, com aproximadamente 18% do total das

receitas. Conclui-se que os produtos relacionados a estes dois grupos participam com mais de

50% no total da receita de serviços de informática (Gráfico 6).

21

Gráfico 5: Distribuição percentual do pessoal ocupado nas atividades do setor de

Tecnologia da Informação e Comunicação – Brasil – 2003-2006


Do total da receita do grupo de serviços de desenvolvimento de softwares sob

encomenda, aproximadamente 64% são produtos relacionados ao desenvolvimento de

softwares específicos para o cliente, e em segundo lugar aparecem os produtos relacionados a

outsourcing3 com aproximadamente 29,6%. Assim, conclui-se que os produtos relacionados a

estes dois itens participam com mais de 90% no total da receita de serviços de

desenvolvimento de softwares sob encomenda (Gráfico 7).

Os resultados apresentados neste estudo do IBGE (2009) permitem obter uma visão

geral da dimensão do setor de TIC, seu peso relativo no conjunto de atividades industrial,

comercial e de serviços, bem como sua contribuição para a geração de renda e emprego. É

importante ressaltar que esses resultados referem-se à parte visível da economia, integrada

pelas empresas formalmente constituídas.

3 Outsourcing é a passagem de processos e serviços de TI das companhias para outras empresas, especialistas na

oferta. Com isto procura-se reduzir custos e a melhoria da qualidade do serviço prestado. É um processo através

do qual uma organização (contratante) contrata outra (subcontratado), na perspectiva de manter com ela um

relacionamento mutuamente benéfico, de médio ou longo prazo, com vista ao desempenho de uma ou várias

atividades, que a primeira não pode ou não lhe convém desempenhar e que a segunda é tida como especialista.

Também é chamada de terceirização. (GLOSSÁRIO DE TI, 2009)

22

Gráfico 6: Participação dos produtos e serviços de informática no total da receita de

serviços de informática – Brasil – 2003-2006


Gráfico 7: Participação dos produtos e serviços de desenvolvimento de softwares sob

encomenda no total da receita de serviços de desenvolvimento de softwares sob

encomenda - Brasil – 2003-2006


23

Após esta visão geral sobre o setor de TIC serão apresentados dados sobre o tamanho do

mercado, com relação à população e ao PIB da região Centro-Oeste e, mais especificamente,

das cidades de Brasília, Goiânia e Aparecida de Goiânia.

Conforme descrito na Tabela 1, a população da região Centro-Oeste representa 7,2%

(13.222.854 habitantes) da população do Brasil (183.987.291 habitantes) enquanto as cidades

de Brasília, Goiânia e Aparecida de Goiânia possuem juntas 4.175.851 habitantes,

representando 31,6% da população do Centro-Oeste, aproximadamente 1/3 (IBGE, 2007).

Dentre as cinco regiões do Brasil, o Centro-Oeste ocupa o quarto lugar em relação ao

PIB Brasileiro e o segundo lugar em relação ao PIB per capita, perdendo apenas para a região

Sudeste (Tabela 1). Em relação às cidades de Brasília, Goiânia e Aparecida de Goiânia, juntas

possuem um PIB de R$ 120.895.039.000, representando 51,2% do PIB da região Centro-

Oeste e 4,5% do PIB do Brasil. (Tabela 1).

Tabela 1: População e Produto Interno Bruto a preços correntes e Produto Interno Bruto

per capita segundo as Grandes Regiões, Unidades da Federação e municípios – 2007

Grandes Regiões, Unidades da

Federação e Municípios

População

recenseada e

estimada

(2007)

PIB 2007

A preços

correntes

(R$ 1.000)

Per capita

(R$)

Brasil 183.987.291 2.661.344.525 14.465

Norte 14.623.316 133.578.391 9.135

Nordeste 51.534.406 347.797.041 6.759

Sudeste 77.873.120 1.501.184.922 19.277

Sul 26.733.595 442.819.864 16.564

Centro-Oeste 13.222.854 235.964.307 17.844

Mato Grosso do Sul 2.265.274 28.121.420 12.411

Mato Grosso 2.854.642 42.687.119 14.954

Goiás 5.647.035 65.210.147 11.548

Aparecida de Goiânia 475.303 3.082.081 6.484

Goiânia 1.244.645 17.867.338 14.355

Outros municípios de Goiás 3.927.087 44.260.728 11.270

Distrito Federal 2.455.903 99.945.620 40.696

Brasília 2.455.903 99.945.620 40.696

Fonte: IBGE, Contagem da População 2007.

24

Conti (2006) cita dados do IBGE e pesquisa da PriceWaterhouseCoppers apresentando

que o Centro-Oeste é uma das regiões de maior crescimento do País em várias áreas, como

investimentos, indústria, serviços, agricultura, educação, mão-de-obra, empregos etc e está

entre as prioridades para investidores. Das 300 empresas ouvidas pela consultoria

PriceWaterhouseCoppers, 65,1% disseram que vão concentrar seus investimentos no Centro-

Oeste. A pesquisa revela ainda que os setores mais atraentes, na visão dos empresários, são

agronegócio (76,7%), serviços (44,2%), indústria farmacêutica (32,6%), turismo/hotelaria

(32,6%) e telecomunicações (30,2%). Os percentuais mencionados referem-se ao total de

empresas ouvidas, portanto, a soma dos mesmos não totaliza 100%.

Ainda segundo Conti (2006), esse crescimento acelerado gera oportunidade para todos

os setores da economia e, em particular, para a de Tecnologia da Informação e Comunicação,

uma vez que os setores mais atraentes requererem uso intensivo de TIC para sua operação e

para o relacionamento com clientes.

1.3 Análise de Projetos desenvolvidos no Brasil e no Exterior

A análise de projetos desenvolvidos no Brasil tomou como base as pesquisas elaboradas

por Archibald & Prado (PRADO; ARCHIBALD, 2008), nos anos de 2006 e 2008 e teve

como objetivo verificar o nível de sucesso das organizações brasileiras que praticam projetos

de T.I; verificar se existe uma correlação entre sucesso e maturidade conforme modelo Prado-

MMGP (modelo de maturidade em gerenciamento de projetos); comparar os resultados com o

relatório Chaos Report do Standish Group4; e, ainda, identificar as principais causas de

fracasso e verificar se existe uma correlação entre maturidade, sucesso e fatores adicionais

(cenários, tamanho da organização etc). A análise de projetos desenvolvidos no Exterior

baseou-se nas pesquisas realizada pelo Standish Group (2009), nos anos de 1994 a 2009.

Um dos itens elencados na pesquisa publicada pelo Standish Group através de seu

relatório denominado “Chaos Report”, nos anos de 1994 a 2009, apresenta uma visão geral do

percentual de projetos que obtiveram sucesso, sucesso parcial5 e fracasso (Gráfico 8). O

Standish Group realiza pesquisas de mercado para utilizadores e fornecedores de softwares.

Por outro lado o "Chaos Report" é um dos relatórios mais publicados por este grupo que visa

avaliar a maturidade no desenvolvimento de projetos e de soluções em TI.

4 Site: www.standishgroup.com/chaos

5 São projetos que atingiram seus objetivos, porém com estouro de tempo, custo etc.

http://www.standishgroup.com/chaos

25

A pesquisa realizada pelo Standish Group (2009), em projetos no exterior, mostra que

em 2009 apenas 32% deles atingiram 100% os objetivos e 68% não atingiram ou os atingiram

parcialmente enquanto que pesquisas realizadas no Brasil em 2008, com aproximadamente

1.000 projetos constatou que, apenas 54% atingiram 100% de seus objetivos e 46% não os

atingiram ou os atingiram parcialmente.

Tanto as pesquisas realizadas com projetos no exterior como as realizadas no Brasil

mostram um baixo índice de sucesso e conseqüentemente um alto índice de projetos que

tiveram fracasso ou atingiram parcialmente seus objetivos.

Das diversas causas de fracasso em projetos o “Não Gerenciamento de Riscos” apareceu

como uma de suas principais causas, no Brasil e, se analisadas as demais causas de fracasso

relacionadas aos projetos, pode-se verificar que elas envolvem algum tipo de risco e, portanto,

possuem alguma relação com o gerenciamento de riscos (Gráfico 10 e 11).

Analisando a pesquisa realizada pelo Standish Group (Gráfico 8) e comparando com a

pesquisa realizada no Brasil (Gráfico 9) percebe-se que os índices brasileiros estão melhores

em termos do percentual de projetos que obtiveram sucesso, sucesso parcial e fracasso.

Segundo Archibald & Prado (PRADO; ARCHIBALD, 2008) esta diferença ocorre por

diversos fatores:

O universo pesquisado: na pesquisa do Standish Group a amostra pesquisada

foi de, aproximadamente, de 40.000 projetos, enquanto que na Pesquisa

Archibald & Prado (no Brasil) foi de, aproximadamente, 1.000 projetos;

Os cenários dos projetos investigados são desconhecidos;

É possível que exista alguma influência no fato de ser uma das primeiras

pesquisas do gênero no Brasil e o público participante pode ainda não ter

entendido corretamente os conceitos, de modo a avaliar corretamente o sucesso

de seus projetos (PRADO; ARCHIBALD, 2008). Observa-se que na pesquisa

do Standish Group também houve uma significativa flutuação nos primeiros

anos;

Um fato curioso é que os valores dos índices de sucesso em ambas as pesquisas

brasileiras em 2006 e 2008 foram bastante semelhantes, lembrando que as

pesquisas foram realizadas com dois anos de intervalo.

26

Gráfico 8: Avaliação do sucesso de projetos de Tecnologia da Informação - 1994-2009

Fonte: Standish Group. Chaos Report 2009

Nas pesquisas realizadas no Brasil em 2006 e 2008 por Archibald & Prado (Gráfico 9),

foram levantadas as principais causas de fracasso (Gráfico 10 e 11). Do total das dez

principais causas de fracasso em projetos de TIC, o gerenciamento de riscos apareceu nas

duas pesquisas mostrando que se for negligenciado ou não gerenciado pode se tornar uma das

causas de fracasso dos projetos. Ao analisar as demais causas verificou-se que, a maioria

envolve, também, algum tipo de risco em projetos.

Gráfico 9: Avaliação do sucesso de projetos de Tecnologia da Informação no Exterior

de 1994-2009, comparado com avaliação de sucesso de projetos de Tecnologia da

Informação no Brasil-2006 e 2008

16%27% 26% 28% 34% 29% 35% 32%

53% 54%

53% 33%46% 49%

51% 53% 46% 44%

26% 31%

31%40%

28% 23% 15% 18% 19% 24% 21% 15%

0%

20%

40%

60%

80%

100%

120%

Fracasso

Sucesso Parcial

Sucesso

Fontes: Pesquisa Archibald & Prado 2008

De acordo com a pesquisa da Módulo (Módulo, 2006), 78% das empresas brasileiras

investem na análise de riscos em TI. Pelo exposto, fica evidente que se houver uma melhora

27

no gerenciamento de riscos (identificação e tratamento adequado de riscos do início ao fim de

um projeto) pode haver uma chance de minimizar as causas de fracasso e aumentar o sucesso

dos projetos, conforme citado também pela pesquisa do Standish Group, 2002.

Gráfico 10: Principais causas de fracasso em projetos de TI - Brasil-2006


Gráfico 11: Principais causas de fracasso em projetos de TI - Brasil-2008


Machado (2002) descreve que a falha nos projetos é discutida em algumas pesquisas,

como a apresentada por Curtis e Statz (CURTIS & STATZ, 1996) em que, em 1992 e 1993,

mais de 60% dos projetos pesquisados nos Estados Unidos da América (EUA) estavam

28

atrasados e mais da metade ultrapassava em 50% o prazo planejado. O estudo conduzido por

Gordon (1999, citado por Machado, 2002) indicou que somente 37% dos Sistemas de

Informação foram finalizados no prazo estipulado. Adicionalmente, dos 63% dos projetos que

atrasaram, 42% seriam finalizados acima do orçamento.

Os projetos de software lidam com um alto nível de incertezas, oriundas das mais

diversas fontes, dentre elas, a mudança de tecnologia, a imaturidade nos processos, a

adequação do perfil técnico para exercer uma atividade e a mudança contínua de requisitos

(MACHADO, 2002). Portanto, apresentam-se as incertezas como uma fonte de risco em

potencial.

1.4 Síntese da Gestão de riscos no Brasil

Conforme mencionado, este capítulo se propôs a realizar a análise regional sobre o

contexto do gerenciamento de riscos em projetos de TIC, procurando mostrar a dimensão e

importância do setor de TIC no Brasil, que vem assumindo maior relevância na nossa

economia, em função do progresso tecnológico que se observa em níveis nacional e global; o

potencial da região Centro-Oeste; a incidência de sucesso e fracasso de nossos projetos em

relação ao de outros países e as causas mais freqüentes de fracassos em projetos de TIC no

Brasil.

Discute ainda os resultados de pesquisas realizadas nos últimos anos em projetos de

TIC, em que foi apresentada análise do contexto regional em projetos de TIC, e que podem

mostrar, aos profissionais de projeto, a importância do setor e o cenário de sucessos e

fracassos.

Analisando-se os dados referentes a “Pessoal Ocupado”, as grandes empresas são as que

mais possuem pessoal ocupado e, em segundo lugar, estão as pequenas empresas. O Centro-

Oeste é a terceira região que mais possui pessoal ocupado no setor de TIC. A região Sudeste é

a que apresentou, no período de 2003-2006, a maior concentração de pessoal ocupado no

setor de TIC, com mais de 65%.

Segundo pesquisa do IBGE, das diversas atividades da Classificação Nacional de

Atividades Econômicas (CNAE), no setor de TIC, aproximadamente 90% das empresas estão

em “Atividades de Informática” e são também as que mais possuem pessoal ocupado. Dos

diversos serviços em “Atividades de Informática” o desenvolvimento de software representa

29

aproximadamente 1/3. O número de empresas do setor de TIC, no período de 2003-2006,

cresceu 4,1% a mais que os demais setores econômicos (indústria, comércio e serviços).

A população das cidades de Brasília, Goiânia e Aparecida de Goiânia possuem

aproximadamente 1/3 população do Centro-Oeste e na somatória do PIB representam mais da

metade (51,2%) do PIB desta região e 4,5% do PIB do Brasil. A região Centro-Oeste é uma

das que apresentam maior crescimento do País, em várias áreas. Esse crescimento acelerado

gera oportunidade para todos os setores da economia e, em particular para o de Tecnologia da

Informação e Comunicação. Os setores mais atraentes na região Centro-Oeste são:

agronegócio, serviços, indústria farmacêutica, turismo/hotelaria e telecomunicações. Estes

setores requererem uso intensivo de serviços e projetos de TIC para sua operação.

De um total de aproximadamente 1.000 projetos pesquisados no Brasil em 2008, apenas

54% atingiram 100% dos objetivos e 46% não os atingiram ou os atingiram parcialmente. O

“Não Gerenciamento de Riscos” se constitui como uma relevante causa de fracasso dos

projetos no Brasil e se analisadas as demais causas de fracasso relacionadas aos projetos,

pode-se verificar que envolvem algum tipo de risco e, portanto, possuem alguma relação com

o gerenciamento de riscos.

Todo projeto envolve algum tipo de risco, sabe-se que com a expansão do mercado

haverá consequentemente aumento dos projetos relacionados à TIC. Se os riscos inerentes aos

projetos forem negligenciados, não tratados adequadamente e nem gerenciados, eles poderão

afetar o resultado do projeto em termos de prazo e custo, por exemplo. Por outro lado se

houver um “melhor” gerenciamento / tratamento destes riscos, a chance de sucesso pode

aumentar.

30

2 FUNDAMENTAÇÃO TEÓRICA

2.1 Padrões de conhecimento e metodologias de gerência de projetos

A compreensão do contexto de um projeto contribui para garantir que o trabalho possa

ser conduzido de acordo com os objetivos e estratégias das organizações. É nesse sentido que

os padrões de conhecimento e metodologias de gerência de projetos vêm para contribuir.

Nosso objetivo aqui é apresentar uma visão geral de alguns desses padrões e métodos e

para isso dividimos este item do trabalho em duas partes onde serão abordados primeiro os

métodos considerados “tradicionais”. São eles: PMBOK (Project Management Book of

Knowledge), PRINCE2 (Project In a Controlled Environment) e P2M (A Guidebook for

Project and Program Management for Enterprise Innovation). Em seguida serão apresentados

alguns métodos ágeis de gerenciamento de projetos como, por exemplo, SCRUM, APM

(Agile Project Management) e DSDM (Dynamic Systems Development Method).

2.1.1 Métodos tradicionais

2.1.1.1 Project Management Book of Knowledge (PMBOK)

É um Guia de conhecimentos em gerenciamento de projetos elaborado pelo PMI

(Project Management Institute), com sede nos EUA, cuja elaboração contou com a

participação de profissionais de diversas nacionalidades.

De acordo com o PMI (2008) “O Conjunto de conhecimentos em

gerenciamento de projetos é a soma dos conhecimentos intrínsecos à profissão de

gerenciamento de projetos. (...) O Conjunto de conhecimentos em gerenciamento de

projetos completo inclui práticas tradicionais comprovadas e amplamente aplicadas,

além de práticas inovadoras que estão surgindo na profissão, inclusive materiais

publicados e não publicados. Como resultado disso, o Conjunto de conhecimentos

em gerenciamento de projetos está em constante evolução”.

O principal objetivo do Guia PMBOK® (PMI, 2008) é identificar o subconjunto do

conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido

como boa prática.

Identificar significa fornecer uma visão geral, e não uma descrição completa.

31

Amplamente reconhecido, significa que o conhecimento e as práticas descritas são

aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em

relação ao seu valor e sua utilidade.

Boa prática significa que existe acordo geral de que a aplicação correta dessas

habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla

série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito

deverá ser sempre aplicado uniformemente em todos os projetos. A equipe de gerenciamento

de projetos é responsável por determinar o que é adequado para um projeto específico.

Todo projeto possui uma estrutura para o seu gerenciamento formal. Através de um

método ou padrão subdivide-se o seu gerenciamento em fases, etapas ou partes. Essa

subdivisão se faz necessária para “quebrar” o projeto em partes menores e possibilitar um

melhor gerenciamento, planejamento e controle do mesmo. Ao conjunto destas fases, etapas

ou partes dá-se o nome de ciclo de vida do projeto. A Figura 1 apresenta este ciclo de vida

(PMI, 2008).

Figura 1: Ciclo de Vida. Fonte: PMI (2008, p.40)

O ciclo de vida geralmente é seqüencial, podendo acontecer em algumas situações, de

ocorrer sobreposição entre ciclos. As necessidades da organização é que irão determinar isso.

No ciclo de vida apresentado (Figura 1) observa-se que ele pode ocorrer uma única vez

através do início do projeto, passando pelos processos de iniciação, planejamento, execução,

monitoramento e controle, e de conclusão, e terminando com o fim do projeto. Outra

possibilidade é que este ciclo de vida pode se repetir para cada fase do projeto, conforme

definição de cada organização em particular.

O processo de iniciação define e autoriza o projeto ou uma fase do projeto.

32

O processo de planejamento define e refina os objetivos e planeja a ação necessária

para alcançar os objetivos e o escopo para os quais o projeto foi criado.

O processo de execução integra pessoas e outros recursos para realizar o plano de

gerenciamento do projeto.

O processo de monitoramento e controle mede e monitora regularmente o progresso

para identificar variações em relação ao plano de gerenciamento, de forma que possam ser

tomadas ações corretivas, quando necessário, para atender aos objetivos do projeto. Este

processo ocorre durante todo o ciclo de vida do projeto.

E por fim o processo de encerramento que formaliza a aceitação do produto, serviço

ou resultado final, conduz o projeto ou uma de suas fases a um final ordenado.

Os processos apresentados no ciclo de vida do projeto são definidos pelo PMI (2008)

em seu Guia de conhecimento (PMBOK) por grupos de processos. Esses grupos de processos

possuem em sua estrutura um conjunto de processos, conhecidos também como áreas de

conhecimento, e que formam a estrutura deste Guia (Figura 2).

As nove áreas de conhecimento presentes na Figura 2 se encontram interligadas e

descrevem o que deve ser gerenciado. Segue abaixo uma breve descrição de cada área de

conhecimento segundo PMI (2008).

O gerenciamento de integração do projeto descreve os processos e as atividades que

integram os diversos elementos do gerenciamento de projetos, que são identificados,

definidos, combinados, unificados e coordenados dentro dos grupos de processos de

gerenciamento. Ele consiste, nos processos de gerenciamento de projetos, em desenvolver o

termo de abertura do projeto, desenvolver o plano de gerenciamento, orientar e gerenciar a

execução do projeto, monitorar e controlar o trabalho, realizar o controle integrado das

mudanças e encerrar o projeto ou fase.

O gerenciamento do escopo do projeto descreve os processos envolvidos na

verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário,

para que seja concluído com sucesso. Ele consiste, nos processos de gerenciamento de

projetos, em coletar requisitos, definir o escopo, criar a EAP6, verificar e controlar o escopo.

6 EAP (Estrutura Analítica do Projeto) – é uma decomposição hierárquica orientada à entrega do trabalho a ser

executado pela equipe do projeto para atingir os seus objetivos e criar as entregas necessárias. Ela organiza e

define o escopo total do projeto (PMI, 2008).

33

GERENCIAMENTO DE

PROJETOS

Gerenciamento da Integração do

Projeto

1. Desenvolver o termo de abertura

do projeto

2. Desenvolver o plano de

gerenciamento do projeto

3. Orientar e gerenciar a execução do

projeto

4. Monitorar e controlar o trabalho do

projeto

5. Realizar o controle integrado de

mudanças

6. Encerrar o projeto ou fase

Gerenciamento dos Recursos

Humanos do Projeto

1. Desenvolver o plano de recursos

humanos

2. Mobilizar a equipe do projeto

3. Desenvolver a equipe do projeto

4. Gerenciar a equipe do projeto

Gerenciamento do Tempo do

Projeto

1. Definir as atividades

2. Seqüenciar as atividades

3. Estimar os recursos da atividade

4. Estimar as durações da atividade

5. Desenvolver o cronograma

6. Controlar o cronograma

Gerenciamento dos Custos do

Projeto

1. Estimar os custos

2. Determinar o orçamento

3. Controlar os custos

Gerenciamento da Qualidade do

Projeto

1. Planejar a qualidade

2. Realizar a garantia da qualidade

3. Realizar o controle da qualidade

Gerenciamento das

Comunicações do Projeto

1. Identificar as partes interessadas

2. Planejar as comunicações

3. Distribuir informações

4. Gerenciar as expectativas das

partes interessadas

5. Reportar o desempenho

Gerenciamento dos Riscos do

Projeto

1. Planejar o gerenciamento dos

riscos

2. Identificar os riscos

3. Realizar a análise qualitativa dos

riscos

4. Realizar a análise quantitativa dos

riscos

5. Planejar as respostas aos riscos

6. Monitorar e controlar os riscos

Gerenciamento das Aquisições

do Projeto

1. Planejar as aquisições

2. Realizar as aquisições

3. Administrar as aquisições

4. Encerrar as aquisiçòes

Gerenciamento do Escopo do

Projeto

1. Coletar os requisitos

2. Definir o escopo

3. Criar a EAP

4. Verificar o escopo

5. Controlar o escopo

Figura 2: Visão geral das áreas de conhecimento em gerenciamento de projetos e os

seus processos. Fonte: PMI (2008)

O gerenciamento de tempo do projeto descreve os processos relativos ao término do

projeto no prazo correto. Ele consiste, nos processos de gerenciamento de projetos, em definir

as atividades, seqüenciar as atividades, estimar recursos da atividade, estimar as durações da

atividade, desenvolver e controlar o cronograma.

O gerenciamento de custos do projeto descreve os processos envolvidos em

estimativas, orçamentos e controle dos custos, de modo que o projeto termine dentro do

orçamento aprovado. Ele consiste, nos processos de gerenciamento de projetos, em estimar os

custos, determinar o orçamento e controlar os custos.

O gerenciamento da qualidade do projeto descreve os processos envolvidos na

garantia de que o projeto irá satisfazer os objetivos para os quais foi criado. Ele consiste, nos

processos de gerenciamento de projetos, em planejar a qualidade, realizar a garantia da

qualidade e realizar o controle da qualidade.

34

O gerenciamento de recursos humanos do projeto descreve os processos que

organizam e gerenciam a equipe. Ele consiste, nos processos de gerenciamento de projetos,

em desenvolver o plano de recursos humanos, mobilizar a equipe, desenvolver a equipe do

projeto e gerenciar a equipe do projeto.

O gerenciamento das comunicações do projeto descreve os processos relativos à

geração, coleta, disseminação, armazenamento e destinação final das informações do projeto

de forma oportuna e adequada. Ele consiste, nos processos de gerenciamento de projetos, em

identificar as partes interessadas, planejar as comunicações, distribuir as informações,

gerenciar as expectativas das partes interessadas e reportar o desempenho.

O gerenciamento de riscos do projeto descreve os processos relativos à realização do

gerenciamento de riscos em um projeto. Ele consiste, nos processos de gerenciamento de

projetos, em planejar o gerenciamento dos riscos, identificá-los, realizar a análise qualitativa e

quantitativa dos riscos, planejar respostas e monitorar e controle os riscos.

O gerenciamento de aquisições do projeto descreve os processos que compram ou

adquirem produtos, serviços ou resultados, além dos processos de gerenciamento de contratos.

Ele consiste, nos processos de gerenciamento de projetos, em planejar as aquisições, realizar

as aquisições, administrar as aquisições e encerrar as aquisições.

Portanto, o PMBOK apresenta em sua estrutura um ciclo de vida do projeto composto

por cinco fases, e um conjunto de processos distribuídos em nove áreas de conhecimento.

2.1.1.2 Project in a Controlled Environment (PRINCE2)

É um método de gestão de projetos elaborado pelo governo britânico em 1996 e a partir

de 1997 foi adotado como padrão de gerenciamento de projetos por organizações públicas e

privadas.

Segundo Ângelo (2008) o PRINCE2, ou Project In a Controlled Environment, é um

método não proprietário para gerenciamento de projetos. É adaptável a qualquer tipo ou

tamanho de projeto e cobre seu gerenciamento, controle e organização. Um projeto PRINCE2

possui as seguintes características: controle e organização do início ao fim, revisão regular de

progressos baseada nos planos e no business case, pontos de decisão flexíveis, gerenciamento

efetivo de qualquer desvio do plano, envolvimento da gerência e das partes interessadas em

momentos-chave durante toda a execução do projeto e um bom canal de comunicação entre o

time do projeto e o restante da organização.

35

Todo projeto possui uma estrutura para o seu gerenciamento formal, que, através de um

método ou padrão o subdivide em fases, etapas ou partes. Essa subdivisão se faz necessária

para “quebrar” o projeto em partes menores e possibilitar um melhor gerenciamento,

planejamento e controle do mesmo. Ao conjunto destas fases, etapas ou partes dá-se o nome

de ciclo de vida do projeto. A Figura 3 apresenta o ciclo de vida de um projeto no PRINCE2.

Direção do Projeto

Partida do

projeto

Iniciando

um projeto

Controlando um

estágio

Gerenciando

entrega de produtos

Gerenciando

limites de estágios

Encerrando um

projeto

Planejamento

Figura 3: Ciclo de Vida – PRINCE2. Fonte: SIEGELAUB (2004, p.3).

Segue abaixo uma breve descrição de cada item do ciclo de vida do PRINCE2, segundo

SIEGELAUB (2004).

O processo de partida (início) do projeto possibilita um início controlado. Ocorre uma

vez no ciclo de vida do projeto, fornecendo as bases para a sua gestão, fiscalização e

avaliação de viabilidade. Este processo cria o Conselho de Projeto e assegura que os

requisitos de recursos sejam entendidos e comprometidos com a primeira fase, "Iniciando um

projeto".

O processo de direção do projeto opera em todo o projeto, e define as

responsabilidades do Conselho de Projeto. Este conselho se constitui de um grupo com

responsabilidade para dar direcionamento para todo o projeto. Ele fornece os mecanismos

para autorização e aprovação de continuidade após a conclusão de cada etapa até o

encerramento do projeto.

O processo iniciando um projeto ocorre uma vez no ciclo de vida do mesmo. Ele

estabelece a visão de como o projeto será gerido, e define um "contrato" chamado Documento

de Iniciação do Projeto (Project Initiating Document - PID). A intenção do PID é fornecer um

36

entendimento comum dos elementos críticos do projeto (semelhante aos resultados do

processo de Planejamento do PMBOK).

O processo de planejamento visa auxiliar o desenvolvimento dos planos necessários

ao projeto. Os planos são produzidos através da identificação dos resultados necessários ao

projeto, das atividades e dos recursos necessários para executá-las, e dos requisitos de

qualidade – tudo isso compatível com os requisitos definidos no PID. O uso de um processo

único de planejamento destaca o conceito de uma abordagem consistente e coerente para todo

o planejamento do projeto.

No processo controlando um estágio são descritas as atividades de controle e

monitoramento, fornecendo uma orientação para o gerente do projeto. Esse processo inclui a

autorização do trabalho; a gestão de mudança; a coleta, análise e produção de relatórios de

status; a análise de riscos; ação corretiva. Este processo é interativo, e é repetido para cada

estágio de desenvolvimento do projeto.

O processo gerenciando entrega de produtos serve para assegurar que os as entregas

correspondam aos produtos planejados. O PRINCE2, assim como o PMBOK, separa o

gerenciamento do projeto do desenvolvimento do produto. Este processo ocorre

freqüentemente quanto os pacotes de trabalho são autorizadas.

O processo gerenciando limites de estágios gerencia a transição a partir da conclusão

de um estágio (etapa/fase de trabalho) para o início do próximo estágio (etapa/fase de

trabalho). Ele inclui a garantia de que o trabalho definido no estágio foi concluído, conforme

definido, fornece informações para o Conselho do Projeto para avaliar a viabilidade em curso

do projeto (feito em "Direção do Projeto"), desenvolve planos para obtenção de autorização

para a próxima fase e registra as lições aprendidas.

O processo encerrando um projeto realiza o registro das lições aprendidas e

experiências vivenciadas. O objetivo deste processo é assegurar que o trabalho foi concluído

para a satisfação do cliente e da Administração, que todos os produtos esperados foram

entregues e aceitos pelo cliente. Se por algum motivo o projeto se tornar inviável, este

processo também será executado.

Além dos processos apresentados no ciclo de vida (Figura 3), o PRINCE2 possui em

sua estrutura um conjunto de processos, conhecido também como “Componentes” (Figura 4)

que equivalem às áreas de conhecimento do PMBOK (Figura 2).

37

Figura 4: Processos e Componentes “Áreas de conhecimento” – PRINCE2.

Segundo Ângelo (2008) os oito componentes (plano de negócios, organização, planos,

controles, gerenciamento de riscos, gerenciamento da qualidade, gerenciamento de

configuração e controle de mudanças) têm as seguintes funções, conforme descrição a seguir:

O plano de negócios justifica a existência do projeto. A filosofia-chave por trás do

PRINCE2 é a concepção de que o plano de negócios deve direcionar o projeto. Ao longo do

ciclo de vida, ele é revisado e validado para garantir que o projeto se mantenha relevante. Um

sólido plano de negócios irá auxiliar no alinhamento do progresso do projeto aos objetivos do

negócio, mantendo-o relevante para a organização. Se não existir um plano de negócios

satisfatório, o projeto não deve ser iniciado. Ele é a ferramenta pela qual o Conselho do

Projeto irá monitorar sua viabilidade.

A organização provê uma estrutura para o projeto com a definição de papéis e

responsabilidades e o relacionamento entre os diversos papéis atuantes.

Os planos disponibilizam um conjunto de planos que podem ser adaptados às

características do projeto. O planejamento é vital para o sucesso, e o plano deve conter

informações detalhadas o suficiente para deixar claros os resultados que se quer alcançar.

Os controles oferecem uma série de mecanismos que ajudam na previsão e nas decisões

para a resolução de problemas. Nenhum projeto é conduzido 100% de acordo com o plano,

sendo comuns desvios em custo, prazo, ou em algum outro indicador. Aqui é aplicado o

conceito de tolerância, onde se definem os níveis de tolerância que o projeto pode aceitar. Isso

significa que, se a cada verificação de status o projeto estiver dentro da faixa de tolerância,

38

não será preciso nenhuma ação do Conselho do Projeto, que será acionado somente se houver

alguma previsão de que as referidas faixas serão excedidas. Isso é conhecido como

gerenciamento por exceção, uma forte característica dos projetos PRINCE2.

O gerenciamento de riscos define os momentos-chave onde os riscos devem ser

avaliados e revisados, além da abordagem a ser aplicada em sua manutenção.

O gerenciamento da qualidade apresenta uma abordagem para o controle de qualidade

dos aspectos técnicos e de gerenciamento do projeto durante todo seu ciclo de vida e define

como será abordado o gerenciamento da qualidade.

O gerenciamento de configuração define as funções essenciais e informações

necessárias para a gerência de configuração do projeto, garantindo o correto versionamento7

dos produtos a serem entregues. Constitui uma proteção para os produtos.

O controle de mudanças é uma técnica cujo objetivo é controlar as mudanças do

projeto, verificando e validando seus impactos.

Portanto, o PRINCE2 apresenta em sua estrutura um ciclo de vida do projeto composto

por oito fases, e um conjunto de oito processos que equivalem às áreas de conhecimento do

PMBOK (Figura 2).

2.1.1.3 A Guidebook for Project and Program Management for Enterprise Innovation (P2M)

O P2M é “Um Guia para a Gestão de Projetos e Programa de Inovação Empresarial",

produzido pela Project Management Association of Japan (PMAJ), uma organização sem fins

lucrativos, responsável pela promoção do gerenciamento de projetos e sistema de qualificação

e certificação para gestão de projetos, com base no P2M, a fim de promover o

desenvolvimento do pessoal de gerenciamento de projetos capaz de criar e entregar valor em

um ambiente complexo e em mudança, é também o responsável pela manutenção e

atualização de P2M.

Este Guia tem por finalidade apresentar uma visão geral do guia de gerenciamento,

proporcionando orientações para a inovação empresarial através da gestão de programas e

projetos.

De acordo com o PMAJ (2005), o P2M é destinado não só para beneficiar organizações

japonesas, mas de forma rentável, pode-se aplicar a todas as organizações globais que buscam

um guia completo para gestão de programas e projetos.

7 Versionamento, significa fazer um controle de versões dos produtos. Ex: versão 1, versão 2 etc.

39

Todo projeto possui uma estrutura para o seu gerenciamento formal, cujo método ou

padrão constitui-se de fases, etapas ou partes. Isto se faz necessário para “quebrar” o projeto

em partes menores e possibilitar um melhor gerenciamento, planejamento e controle do

mesmo. Ao conjunto destas fases, etapas ou partes dá-se o nome de ciclo de vida. A Figura 5

apresenta o ciclo de vida de um projeto (PMAJ, 2005).

EntregaConcepção

Coordenação

Planejamento

Implementação

Figura 5: Ciclo de Vida – P2M. Fonte: PMAJ (2005, p.27)

O ciclo de vida é um procedimento utilizado para o aprimoramento da resolução de

problemas no projeto como um todo, em suas fases e fluxos de trabalho, bem como a

melhoria na eficiência e eficácia.

A ação é tomada com base em cinco elementos do processo: concepção, planejamento,

implementação, coordenação e entrega. Este conjunto de elementos do ciclo de vida também

corresponde aos padrões de ação para a tomada de decisão para todo o projeto.

O processo de concepção deve envolver originalidade, idéia e otimização para fornecer

uma base adequada para o lançamento e planejamento de um projeto.

O processo de coordenação visa uma solução por meio de consulta entre as partes

interessadas quanto à ocorrência de problemas e identificação de suas causas. A coordenação

envolve o monitoramento de fatores ambientais, como mudanças conjunturais, fatores

acidentais, a interferência entre os objetivos, os obstáculos à colaboração e avarias.

Os processos apresentados no ciclo de vida do projeto são definidos pelo PMAJ (2005)

em seu Guia para gestão de projetos (P2M). Possui uma estrutura de processos (Figura 6) que

lembra a do PMBOK (PMI, 2008).

40

IV. Gestão do Segmento

Gerenciamento de Projeto

1. Atributo, definição de base, quadro

2. Gerenciamento de projetos visão comum

3. Gestão da integração

4. Gestão do segmento

5. Competências a gestão da integração

Gerenciamento de Programa

1. Atributo, definição de base, quadro

2. Plataforma de programa

3. Perfil de gestão

4. Estratégia de gestão do programa

5. Gerenciamento de arquitetura

6. Plataforma de gestão

7. Gerenciamento ciclo do programa

8. Gestão de valor

Gestão do Segmento

Sistemas de Gestão de Projeto

Gestão de Objetivo do Projeto

Gestão de Riscos

Gestão de Relacionamento

Estratégia de Gestão de Projeto

Gestão de Organização do Projeto

Gestão dos Recursos do Projeto

Gestão da Informação

Gestão de Valor

Gestão Financeira do Projeto

Gestão da Comunicação

I. Entrada

II. Gerenciamento

de Projeto

III. Gerenciamento

de Programa

Entrada

Figura 6: Torre de gerenciamento de projetos – P2M. Fonte: PMAJ (2005, p.11)

A partir da Figura 6 será feita uma breve descrição dos processos do modelo P2M,

contidos no item IV.Gestão do Segmento.

A estratégia de gestão de projeto aborda a relação entre as estratégias corporativas

(incluindo empresas públicas e sem fins lucrativos) e incorpora as atividades do projeto para

criação de valor corporativo. Ela consiste, nos processos de gerenciamento de projetos, na

utilização de sistemas estratégicos de avaliação, melhoria na plataforma de sistemas de

projetos e constituição de parcerias.

A gestão da financeira do projeto refere-se a um método de controle destinado a

construir uma estrutura para angariar investimentos de implementação do projeto. Ela

consiste, nos processos de gerenciamento de projetos, na criação e seleção de planos básicos,

seleção de fatores e sua especificação, criação de uma estrutura alternativa viável e avaliação

de elegibilidade e eficiência econômica do negócio.

No sistema de gestão do projeto, deve-se examinar as atividades, esclarecimento de

atribuição, alcance, planejamento de atividades e gestão de resultados, incluindo mecanismo

de serviço que o projeto proporciona. Ele consiste, nos processos de gerenciamento de

41

projetos, na gestão de sistemas, engenharia de sistemas e abordagem de sistemas soft (ex:

pensamento sistêmico, resolução de problemas de método, método de modelagem).

A gestão de organização do projeto é um processo que possibilita a sua organização

de forma rápida, respondendo de forma flexível e circunstanciais as alterações em um

ambiente estritamente em torno de projetos. Ela consiste, nos processos de gerenciamento de

projetos, no reconhecimento do ambiente de organização, constituição da equipe, garantia de

recursos humanos, planejamento e gerenciamento da organização e avaliação da organização

do projeto.

A gestão de objetivos do projeto pode ser comparada a um navegador de carro. Este

identifica um roteiro a partir de várias opções, o que leva a um custo menor e exigindo menor

tempo possível para atender a finalidade da unidade e de destino. Além disso, ele tem uma

função para escolher uma circulação ideal e avisar caso haja qualquer restrição do tráfego no

caminho. Ou seja, a gestão de objetivos do projeto fornece um mapa de rota para que os

gerentes de projeto e membros da equipe possam visualizar os processos em cada ponto, no

tempo que resta até a sua conclusão, incluindo as restrições de cláusulas contratuais, recursos

e outros. Ela consiste, nos processos de gerenciamento de projetos, na gestão de ciclo de vida,

de escopo, de custos, de tempo, da qualidade, de valor agregado, da mudança e de entregáveis

(produtos/serviços).

A gestão de recursos do projeto deve fornecer e assegurar recursos necessários ao

projeto que consistem em seis tipos: material, fundamental, humano, intelectual,

informacional e financeiro (PMAJ, 2005). Um projeto só pode ser concluído quando os

recursos estão garantidos no momento oportuno, no âmbito de sua gestão como um todo. A

gestão de recursos refere-se, portanto à gestão precisa e adequada, assegurando os recursos

necessários para o projeto. Ela consiste, nos processos de gerenciamento de projetos, de

identificação dos recursos, planejamento de utilização dos recursos, acompanhamento da

implementação, plano de melhoria e otimização de recursos.

Na gestão de riscos os projetos são acompanhados de incerteza quanto ao seu atributo

básico que contém sempre o risco e, se não forem tomadas medidas para lidar com riscos,

bons resultados não podem ser obtidos. Ela consiste, nos processos de gerenciamento de

projetos, de plano básico, identificação de risco, análise e avaliação de risco, planejamento de

medidas contra o risco (planejamento de respostas aos riscos), medição dos riscos e avaliação

da gestão de risco (lições aprendidas).

A gestão da informação detalha como a informação e tecnologia da informação (TI)

devem ser utilizadas no trabalho de implementação do projeto. Apesar de muitas organizações

42

possuírem tecnologia, conhecimento e know-how próprios, estas devem também procurar no

mercado outras tecnologias, conhecimentos e know-how mais avançados para serem utilizados

no projeto, sempre que possível, permitindo assim decisões rápidas e adequadas. Neste ponto

a tecnologia da informação irá exercer um grande poder, para criar um ambiente para atender

a esses requisitos. Ela consiste, nos processos de gerenciamento de projetos, de determinação

dos métodos de gerenciamento de sistemas, determinação dos processos de gerenciamento do

trabalho para os quais se aplicam os sistemas de gerenciamento e metodologia de

compartilhamento de informações e comunicação no projeto.

A gestão de relacionamento refere-se a uma série de processos operacionais que

definem o tipo de relacionamento entre as partes interessadas que estão envolvidas com um

projeto, e mantém boas condições para orientá-lo com sucesso. Seu objetivo é conseguir a

satisfação dos clientes / atores e outro objetivo para a manutenção e desenvolvimento do

projeto em um relacionamento contínuo com as partes interessadas. Ela consiste, nos

processos de gerenciamento de projetos, de planejamento do relacionamento, manutenção do

relacionamento (proposta, contrato e termos de ajuste) e reestruturação do relacionamento.

A gestão de valor representa um compromisso de criação de valor com uma missão

específica. As missões específicas de projetos podem ser definidas como a provisão de

valores específicos para as partes interessadas específicas. A conclusão com sucesso de um

projeto significa que o valor almejado foi alcançado. A gestão do valor se refere a um

processo de circulação de valor onde conhecimentos e experiências decorrentes das referidas

atividades típicas de projetos de empresas são acumulados como fontes de valor e são usadas

como feedback (ou seja, a criação de novo valor). A gestão de valor consiste, nos processos

de gerenciamento de projetos, de identificação e avaliação de valor, gestão de conhecimento,

manutenção, Kaizen (melhoria), Total Quality Manegement (TQM), transferência de

tecnologia, contrato de garantia, obtenção de investimento, ambiente e criação de serviço de

negócios.

A gestão da comunicação visa promover um melhor entendimento entre os membros

do projeto e é um dos principais fatores que influenciam no seu sucesso. Além disso, é

importante manter o controle de situações reais e resolver vários problemas decorrentes de um

projeto através da comunicação. Assim, a gestão bem sucedida, de uma forma pró-ativa, é

largamente atribuível à gestão da comunicação. Ao respeitar as diferenças culturais, e aceitar

uns aos outros, podemos desenvolver um modelo híbrido de comunicação que tem

características de ambas as culturas (PMAJ, 2005). Ela consiste. nos processos de

gerenciamento de projetos, de idéia alternativa, habilidade para lidar com diferentes culturas,

43

definição dos papéis, compreensão da própria cultura e de diferentes culturas e a utilização de

tecnologia da informação.

Portanto, o P2M apresenta em sua estrutura um ciclo de vida do projeto composto por

cinco fases, que equivalem às cinco fases do ciclo de vida do PMBOK (Figura 1), e uma

estrutura de onze processos que lembra a do PMBOK (Figura 2).

2.1.1.4 Comparativo dos métodos ―tradicionais‖

Na Tabela 2 será apresentado um resumo comparativo, contendo origem, definição de

projeto, ciclo de vida, processos e sub-processos da gerência de risco, entre os métodos

“tradicionais”: PMBOK, PRINCE2 e P2M.

O ciclo de vida do PMBOK e P2M possuem cinco fases semelhantes entre si, enquanto

no PRINCE2 este apresenta oito fases com conteúdo semelhante aos dois, porém mais

detalhadas.

Apesar de os métodos apresentarem processos distintos em sua estrutura, todos tratam

da gestão de riscos, reforçando a relevância do assunto na gerência de projetos.

Os três métodos “tradicionais“, possuem um conjunto de processos, relacionados à

gerência de riscos, com nomes diferentes, no entanto apresentam abordagens semelhantes

com relação a gestão de riscos.

Tabela 2: Comparativo dos métodos “tradicionais” de gerência de projetos

ITENS PMBOK PRINCE2 P2M

Origem PMI – USA Reino Unido PMAJ - Japão

O que é? Guia de conhecimentos em

gerenciamento de projetos. Método de gestão de projetos.

Um Guia para a Gestão de

Projetos e Programa de Inovação

Empresarial.

Definição de

projeto

Um esforço temporário

empreendido para criar um

produto, serviço ou

resultado exclusivo.

PRINCE2 diz simplesmente "não

tentar reinventar a roda"

Uma base de criação de valor

específico para a empresa, que é

completado em um período

determinado ou acordado e sob

restrições, incluindo os recursos e

as circunstâncias externas.

Ciclo de vida

Iniciação, planejamento,

execução, controle e

monitoramento e

encerramento.

Partida (início) do projeto,

direção do projeto, iniciando um

projeto, planejamento,

controlando um estágio,

gerenciando entrega,

gerenciando limites de estágios e

encerrando um projeto.

Concepção, planejamento,

implementação, coordenação e

entrega.

Fonte: PMI (2008); Ângelo (2008) e Siegelaub (2004); PMAJ (2005) adaptado pelo autor.

44

Tabela 2: Comparativo dos métodos “tradicionais” de gerência de projetos (Cont.)

ITENS PMBOK PRINCE2 P2M

Processos

Escopo, tempo, custo,

qualidade, risco,

comunicação, RH, aquisição

e integração.

Plano de negócios, organização,

planos, controles, gerenciamento

de riscos, gerenciamento da

qualidade, gerenciamento de

configuração e controle de

mudanças.

Estratégia de gestão de projeto,

Gestão financeira do projeto,

Sistema de gestão do projeto,

Gestão de organização do projeto,

Gestão de objetivos do projeto,

Gestão de recursos do projeto,

Gestão de riscos, Gestão da

informação, Gestão de

relacionamento, Gestão de valor,

Gestão da comunicação.

Processos da

Gerência de

Riscos

O Gerenciamento de riscos

do projeto inclui os

processos relacionados com

o planejamento,

identificação, análise,

elaboração de respostas,

monitoramento e controle

dos riscos em um projeto.

O gerenciamento de riscos do

projeto inclui os processos

relacionados com: identificar os

riscos, avaliar os riscos,

identificar as respostas

adequadas ao risco, selecionar,

planejar os recursos e monitorar

e controlar os riscos.

O gerenciamento de riscos do

projeto inclui os processos

relacionados com o plano básico,

identificação de risco, análise e

avaliação de risco, planejamento

de medidas contra o risco

(planejamento de respostas aos

riscos), medição dos riscos e

avaliação da gestão de risco

(lições aprendidas).

Fonte: PMI (2008); Ângelo (2008) e Siegelaub (2004); PMAJ (2005) adaptado pelo autor.

2.1.2 Métodos ágeis

Em fevereiro de 2001, foi lançado o Manifesto Agile for Software Development (BECK

et al., 2001 apud ARAUJO, 2008), onde se enfatizou o uso de métodos ágeis para

desenvolvimento de software, voltados para colaboração com o cliente, com os indivíduos e

que pudesse responder rapidamente às mudanças. Alguns desses métodos ágeis utilizados

para gerenciamento de projetos são: Scrum, Agile Project Management (APM) e Dynamic

Systems Development (DSDM). A seguir será apresentada uma visão geral sobre cada um

desses métodos.

2.1.2.1 Scrum

A palavra Scrum ou SCRUM, não é uma sigla como parece a princípio, onde cada letra

teria um significado. O nome Scrum foi utilizado pela primeira vez pelos japoneses Hirotaka

Takeuchi e Ikujiro Nonaka e descrevia um tipo de processo de desenvolvimento de produto

utilizado no Japão. Além disso, o nome Scrum foi escolhido pela similaridade entre o jogo de

45

Rugby8 e o tipo de desenvolvimento de produto, ou seja, ambos são adaptativos, flexíveis,

rápidos e promovem a auto-organização (CAMARA, 2008).

O Scrum é um modelo ágil para gerenciamento de projetos que foi desenvolvido por

Jeff Sutherland e por sua equipe, sendo que posteriormente foi feito um desenvolvimento

adicional por Scwaber e Beedle (PRESSMAN, 2006).

O método Scrum segue alguns princípios (PRESSMAN, 2006, p. 69) que são

consistentes com o manifesto ágil:

Pequenas equipes de trabalho são organizadas de modo a “maximizar a

comunicação, minimizar a supervisão e maximizar o compartilhamento de

conhecimento tácito informal”.

O processo precisa ser adaptável tanto quanto às modificações técnicas quanto

às de negócios “para garantir que o melhor produto possível seja produzido”.

O processo produz freqüentes incrementos de software “que podem ser

inspecionados, ajustados, testados, documentados e expandidos”.

O trabalho de desenvolvimento e o pessoal que o realiza é dividido “em

partições claras, de baixo acoplamento, ou em pacotes”.

Testes e documentação constantes são realizados à medida que o produto é

construído.

O processo Scrum fornece a “habilidade de declarar o produto „pronto‟ sempre

que necessário (porque a concorrência acabou de entregar, porque a empresa

precisa de dinheiro, porque o usuário/cliente precisa das funções, porque foi

para essa data que foi prometido ...)”.

O Scrum está se tornando cada vez mais popular, e vem sendo adotado por grandes

empresas de software como a Yahoo!, Microsoft, Intel, Google e Nokia. E em uma recente

pesquisa feita com mais de três mil entrevistados de oitenta países, pela empresa Version One

em conjunto com diversas organizações da área de métodos ágeis, constatou que quase 50%

dos entrevistados utilizam Scrum em suas empresas (VICENTE, 2010).

O Scrum dá ênfase ao uso de um conjunto de “padrões de processo de software”

(NOYES, 2002) que se mostram eficazes para projetos com prazos apertados, requisitos que

sofrem mudanças constantes e que possuem atividades críticas de negócio (PRESSMAN,

2006), ou seja, é uma metodologia que, na prática, possui um processo iterativo e incremental

8 “Um grupo de jogadores se forma ao redor da bola e os companheiros de equipe trabalham juntos (algumas

vezes violentamente!) para mover a bola pelo campo” (PRESSMAN, 2006).

46

(Figura 7). “Assume-se que os projetos no qual o Scrum se insere são complexos e

imprevisíveis, onde não é possível prever tudo que irá acontecer. Por esta razão, ele oferece

um conjunto de práticas que torna tudo isso visível” (SCHWABER, 2004 apud RIBEIRO;

GUSMÃO, 2008, p.68).

O Scrum, assim como outras metodologias, possui a figura de atores e estes, por sua

vez, possuem responsabilidades/papéis no processo. São esses atores que conduzem as

atividades/processos no Scrum, e são denominados por Product Owner, ScrumMaster e

Equipe Scrum (Tabela 3).

Tabela 3: Atores e responsabilidades do SCRUM.

ATORES RESPONSABILIDADES

Product

Owner:

Proprietário

do produto

/ Cliente

Representa os interesses de todos no projeto;

Define os fundamentos do projeto criando requisitos iniciais e gerais (Product Backlog),

retorno do investimento (ROI), objetivos e planos de entregas;

Prioriza o Product Backlog a cada Sprint, garantindo que as funcionalidades de maior

valor sejam construídas prioritariamente.

Scrum

Master:

Líder

Gerencia o processo do Scrum, ensinando o Scrum a todos os envolvidos no projeto e

implementando o Scrum de modo que esteja adequado a cultura da organização;

Deve garantir que todos sigam as regras e práticas do Scrum;

É responsável por remover os impedimentos do projeto.

Time

(Team):

Equipe

Desenvolve as funcionalidades do produto;

Define como transformar o Product Backlog em incremento de funcionalidades numa

iteração, gerenciando seu próprio trabalho, sendo responsáveis coletivamente pelo sucesso

da iteração e conseqüentemente pelo projeto como um todo.

Fonte: MARÇAL et al, (2007, p.3)

As atividades/processos do Scrum conduzidas pelos atores (Tabela 3) são apresentadas

na Figura 7.

47

Figura 7: Ciclo de Vida do Scrum. Fonte: adaptado de VICENTE (2010, p.25)

A seguir será feita uma breve descrição das atividades constantes da Figura 7, conforme

descritas por Vicente (2010). São elas: (1) visão do produto e definição do backlog do

produto, (2) planejamento do sprint (backlog selecionados e backlog do sprint), (3) sprint de

desenvolvimento e (4) reunião de revisão do sprint e retrospectiva.

1. Visão do produto e definição do backlog do produto:

O trabalho a ser feito em um projeto Scrum, inicia-se com a elaboração da visão do

produto a ser desenvolvido, incluindo suas características, premissas e restrições. Em

seguida são listadas as pendências (product backlog), que compreendem uma lista de

todos os requisitos ou características do projeto que geram valor de negócio para o

cliente. Esse documento será a entrada para o processo iterativo e incremental de

desenvolvimento.

2. Planejamento do sprint (backlog selecionados e backlog do sprint):

O planejamento do sprint é dividido em duas reuniões do sprint (Sprint Planning 1 e

2). A Reunião de Planejamento 1 (Sprint Planning 1 – Seleção do Backlog) é onde o

cliente (Product Owner) apresenta os itens de backlog com maior prioridade para o

time (equipe). É nessa reunião que são definidos os objetivos do Sprint, e quantos

itens serão escolhidos (selecionados) para que seja possível entregar um produto

48

funcionando no fim do próximo Sprint. Essa seleção é feita pelo time de acordo com

sua capacidade até o próximo Sprint. A Reunião de Planejamento 2 (Sprint Planning

2 – Seleção do Backlog do Sprint) é onde o time define as tarefas a serem feitas

durante o Sprint. Essas tarefas são estimadas em termos de tempo para seu

desenvolvimento. Essa estimativa é feita conforme o desempenho dos Sprints

anteriores, a capacidade e a complexidade das tarefas necessárias para alcançar o

objetivo do Sprint. No caso de a equipe verificar que o tempo das tarefas (estimado

no planejamento do Sprint) não corresponda à realidade (tempo efetivamente gasto

para realização da tarefa), isso poderá ser discutido na retrospectiva do Sprint (passo

4) após o fim do Sprint.

3. Sprint de desenvolvimento:

Após concluídas as reuniões de planejamento, o time inicia a fase 3 que é o

desenvolvimento do produto que pode levar de uma a quatro semanas (Sprint).

Durante o Sprint não é permitida interferência no Backlog do Sprint por parte do

Product Owner ou por qualquer stakeholder do projeto. As alterações (mudanças,

adições e priorização de requisitos) só poderão ser feitas durante a reunião de

planejamento pelo Product Owner. No caso em que mudanças no ambiente de

negócios provoquem mudanças de requisitos, o Product Owner em conjunto com o

ScrumMaster, tem autoridade para cancelar imediatamente o sprint atual e realizar

uma nova reunião de planejamento. Dessa forma, o Scrum, mantém o controle e

visibilidade da produtividade do time. Causaria enorme prejuízo caso os requisitos

pudessem ser modificados e adicionados a qualquer momento durante um Sprint, no

mesmo tempo em que fornece um mecanismo de adaptação e correção para os

requisitos do produto colocado pelo Product Owner. Todos os dias durante o Sprint

são realizadas breves reuniões (aproximadamente de 15 minutos) chamadas de daily

scrum que permitem ao time verificar o andamento do projeto. Durante essa reunião

o time (membros da equipe) respondem a três perguntas básicas: (a) o que você fez

desde a ultima reunião? (b) você teve algum obstáculo? e (c) o que você vai fazer

antes da próxima reunião?. O ScrumMaster coordena a reunião e avalia as respostas

de cada um. Essas reuniões diárias permitem à equipe encontrar problemas

potenciais o mais cedo possível. Elas possibilitam uma socialização do conhecimento

sobre o andamento do projeto, produzindo uma estrutura de equipe “auto-

organizada”. Os impedimentos são registrados no impediments backlog, que é um

documento onde se registram todos os problemas encontrados pela equipe. A

49

resolução desses problemas é de responsabilidade do ScrumMaster bem como

atentar-se para que o time consiga produzir com a máxima eficiência.

4. Reunião de revisão do sprint e retrospectiva:

Ao final de cada Sprint o time apresenta o resultado produzido, referente ao Sprint

em questão, em uma reunião chamada de “Reunião de Revisão do Sprint” (Sprint

Review Meeting). O objetivo dessa reunião é melhorar o processo, as capacidades e

competências do time bem como o desenvolvimento do produto para o próximo

sprint. Durante essa reunião de revisão os stakeholders podem identificar requisitos

que não foram entregues ou que não estão conforme o esperado e solicitar que estes

sejam incluídos no backlog do produto para ser priorizado para o próximo sprint. Os

stakeholders podem também identificar e solicitar novos requisitos. O

acompanhamento e monitoramento do andamento do projeto são realizados por meio

de dois gráficos (product burndown e sprint burndown). Esses gráficos mostram a

quantidade de trabalho que ainda falta ser feito (em qualquer ponto do cronograma) e

o progresso da equipe do projeto em relação ao cronograma. O SCRUM prevê ainda

uma reunião de retrospectiva (sprint retrospective). Essa reunião é conduzida pelo

ScrumMaster e tem por objetivo que a equipe se avalie continuamente e discuta o

Sprint que foi concluído recentemente, determinando o que pode ser feito para

melhorar e tornar mais produtivo o próximo sprint. Durante essa reunião é colocado

(abordado) tudo aquilo que pode afetar a equipe e o bom andamento do projeto e

deve incluir processos, práticas, comunicação e o ambiente. Enquanto que a revisão

do Sprint preocupa-se com “o que” a equipe vem produzindo, a retrospectiva

preocupa-se em definir o “como” vem sendo produzido.

Portanto, o Scrum é um método ágil para gerenciamento de projetos, que se caracteriza

por ser um método adaptativo, flexível, rápido e por promover a auto-organização, que segue

um conjunto de seis princípios e apresenta em sua estrutura um ciclo de vida do projeto

composto por quatro fases (Figura 7).

50

2.1.2.2 Agile Project Management (APM)

O APM surgiu em 2001, quando do movimento iniciado pela comunidade internacional

de desenvolvimento de software, a partir da publicação do Manifesto Agile Software

Development (BECK et al, 2001 apud DIAS; SOLER, 2005).

Diante da necessidade de reduzir os ciclos de desenvolvimento de novos softwares e da

adaptação a ambientes de negócios cada vez mais dinâmicos, verificou-se que o

gerenciamento de projetos tradicional não se mostrou completamente efetivo. Foi aí que

surgiu o movimento da comunidade internacional de desenvolvimento de software, em reação

a essas situações. Esse movimento ampliou sua abrangência, passando a ser adotado por

outros segmentos além da área de TI, como por exemplo, pela indústria de construção civil e

aeroespacial, que possuem premissas semelhantes relacionadas às complexidades e incertezas

em seus projetos. À medida que esse movimento foi crescendo, ele passou a ser percebido por

qualquer segmento de negócio e denominado Agile Project Management (HIGHSMITH, 2004

apud DIAS; SOLER, 2005).

Chin (2004) defende a criação de um novo modelo de gerenciamento de projetos e não

de uma simples expansão dos métodos clássicos. Trabalhando segundo uma visão de

plataformas, menciona, nesse sentido, que os modelos tradicionais não se mostram efetivos

pela simples razão de terem atingido seu limite máximo de abrangência. Continuar o

desenvolvimento desta plataforma tradicional seria, segundo o autor, em alguns momentos,

mais difícil do que estruturar uma nova idéia. E, é neste contexto que o Agile Project

Management se insere, como uma nova plataforma de gerenciamento de projetos, aplicável a

ambientes instáveis e desafiadores, sujeitos a mudanças freqüentes, nos quais o processo

prescritivo e padronizado não mais se adéqua (CHIN, 2004, p.2; HIGHSMITH, 2004, p. 5

apud DIAS; SOLER, 2005).

...tão importante quanto definir o APM, é apresentar o conceito de agilidade.

Muitas pessoas assumem que a agilidade traz consigo uma conotação de falta de

estrutura. Entretanto, Highsmith (2004, p. 16) afirma que a ausência de estrutura ou

estabilidade pode levar ao caos enquanto, estrutura em demasia, gera rigidez. A

definição utilizada pelos defensores do APM não segue a primeira linha. Por

agilidade entende-se “a habilidade de criar e responder a mudanças, buscando a

obtenção de lucro, em um ambiente de negócio turbulento” (HIGHSMITH, op. cit.);

ou ainda, “a capacidade de balancear flexibilidade e estabilidade” (HIGHSMITH,

2002). A agilidade está também diretamente relacionada à capacidade de adaptação

a situações diversas e inesperadas. (DIAS; SOLER, 2005).

51

O APM possui alguns valores centrais estruturados a partir do Manifesto Agile Software

Development (Tabela 4) que direcionam a necessidade de criação e entrega de produtos que

agreguem valor ao cliente, de forma ágil e adaptável. Este conceito aplica-se também à equipe

de projeto.

Tabela 4: Valores centrais do APM

# VALORES

1 As respostas às mudanças são mais importantes que a perseguição de um plano

previamente definido

2 A entrega de produtos é prioritária em relação à entrega da documentação

3 Enfatiza-se a colaboração do cliente em detrimento da negociação de contratos

4 Os indivíduos e suas interações são mais importantes que os processos e

ferramentas

Fonte: BECK et al. 2001 apud DIAS; SOLER (2005, p.3)

Além dos valores centrais, o APM possui um conjunto de princípios mestres, que estão

divididos em duas categorias (Tabela 5), que auxiliam as equipes de projeto a definir em quais

práticas são mais apropriadas e implementá-las com agilidade.

Tabela 5 – Princípios mestres do APM

CATEGORIA PRINCÍPIO

Valor ao cliente Entregar valor ao cliente

Gerar entregas iterativas e baseadas em funcionalidades

Buscar a excelência técnica

Estilo de gerenciamento

baseado na liderança e

colaboração

Encorajar a exploração

Construir times adaptativos (auto-organizados e auto-

disciplinados)

Simplificar

Fonte: HIGHSMITH, 2004 apud DIAS; SOLER (2005, p.3)

Com relação às fases, o APM está estruturado em cinco fases, conforme Figura 8.

52

Figura 8: Fases do APM. Fonte: HIGHSMITH, 2004 apud CONFORTO (2009, p.47)

A seguir será feita uma breve descrição de cada uma das cinco fases do APM de acordo

com Conforto (2009):

1. Visão: o objetivo dessa fase é determinar a visão do produto e o escopo do

projeto, a identificação da comunidade participante (clientes, gerente de

projeto, equipe e outros stakeholders), além de definir como a equipe irá

trabalhar em conjunto. Nessa fase busca-se descrever o produto, simplificando

a documentação gerada, que deve fornecer uma descrição de alto nível do

produto para a equipe do projeto, para facilitar a execução das próximas fases

(2) especulação e (3) exploração.

2. Especulação: nesta fase é elaborado um planejamento inicial do projeto, com

base na visão definida. O planejamento inicial será seguido por planejamentos

específicos detalhados a cada iteração, sobre o que precisa ser entregue, quem

são as pessoas envolvidas e qual será a estratégia adotada. A “visão” do

produto será refinada, a partir da identificação de seus requisitos do produto,

desenvolvimento do plano de projeto, plano de entregas, pontos de avaliação,

avaliação de riscos, alocação de recursos, estimativas de custos, e plano de

iterações versus entregas do projeto. Essa fase é repetida no processo quantas

vezes for preciso para atingir os resultados esperados.

3. Exploração: essa fase abrange a execução e entrega dos produtos planejados na

fase anterior (fase de especulação). Essas entregas são feitas sob a forma de

incrementos de funcionalidades e são divididas entre os ciclos do projeto

(iterações). A fase de exploração é composta de três partes críticas: (a) executar

53

as entregas com o adequado gerenciamento da carga de trabalho e o dia-a-dia

da equipe de projetos através de reuniões de feedback constante; (b) promover

a auto-organização e autodisciplina da equipe de projetos, ou seja, prover

condições para que cada um dos membros da equipe seja co-responsável pelos

resultados e se comprometam com as metas; e (c) gestão das interações da

equipe de projeto com o cliente, gerente do projeto, e todos os envolvidos

direta e indiretamente no projeto.

4. Adaptação: compreende a revisão dos resultados da fase anterior (fase de

exploração), analise do progresso do projeto e o desempenho da equipe. Os

itens de revisão considerados são o que foi entregue versus o que foi planejado,

considerando novos requisitos ou entregas, para atingir os objetivos do projeto.

Esta fase finaliza o ciclo de uma iteração (especular, explorar e adaptar) que

pode ocorrer várias vezes durante o ciclo de vida do projeto. A cada iteração, a

equipe está mais treinada e apta a absorver mudanças, o aprendizado sobre o

projeto é evolutivo o que contribui para melhores resultados.

5. Encerramento: finalização das atividades do projeto, transferência dos

conhecimentos-chave adquiridos e celebração dos resultados obtidos.

Highsmith (2004), citado por Conforto (2009), advoga a importância de ter

“mini-fechamentos” ao final de cada iteração (especular, explorar e adaptar) do

projeto para melhor absorção do aprendizado e busca pelo nível de

flexibilidade no processo adequado ao projeto e seu contexto.

Algumas vezes, no entanto, o retorno à fase de Visão pode ser necessário, em especial

quando se têm modificações muito significativas no escopo do projeto. Uma vez obtido o

produto final, segue-se o encerramento do projeto.

Benassi (2009) cita algumas limitações do APM, como as práticas propostas pelos

autores ainda não estarem consolidadas para o desenvolvimento de produtos manufaturados e

os autores não explicarem com detalhes a utilização das práticas, o que dificulta o emprego e

verificação de sua eficiência.

54

2.1.2.3 Dynamic Systems Development Method (DSDM)

O DSDM foi desenvolvido na Inglaterra, na década de 1990 e é um framework para o

desenvolvimento ágil em projetos de software. O DSM é uma extensão do RAD (Rapid

Application Development) e tem como objetivo principal gerenciar as ações dentro dos limites

desejados a respeito de tempo reduzido e de orçamento apertado (GIUFFRA; VILAIN, 2010).

O DSDM segue alguns princípios chave, conforme descritos por Teixeira et al (2006):

O ponto fundamental desta metodologia prende-se à entrega de um sistema que

se aproxime das atuais necessidades de negócio;

Nenhum sistema é completamente construído na primeira tentativa;

A entrega do projeto deve ser feita na data estipulada, dentro do orçamento

previsto e com boa qualidade;

Testes ao longo de cada iteração;

Entregas freqüentes;

Exigências flexíveis para o Sistema de Informação;

Possibilidade de que cada etapa do desenvolvimento seja completada até que

seja possível iniciar o passo seguinte. Isto faz com que cada fase do projeto

possa começar sem ter que esperar que as fases que começaram anteriormente

sejam totalmente terminadas;

Comunicação entre todas as partes envolvidas (stakeholders) como um pré-

requisito bastante importante para que o projeto corra com a eficiência

desejada;

Envolvimento dos utilizadores como chave para esta eficiência;

Equipes responsáveis dotadas de um sentido de decisão, sendo este também um

ponto fulcral na progressão do projeto;

Equipes de gestão incorporadas no DSDM;

Após o desenvolvimento do Sistema de Informação, possibilidade de uso do

DSDM para expandir o Sistema obtido.

Com relação às fases, o DSDM está estruturado em três fases (pré-projeto, projeto e

pós-projeto), conforme Figura 9.

55

Figura 9: Ciclo de vida de um projeto. Fonte: DSDM (GIUFFRA; VILAIN (2010, p.4)

A seguir será feita uma breve descrição de cada uma das três fases do DSDM conforme

descritas por Teixeira et al (2006):

Fase 1: Pré-Projeto - Na fase do pré-projeto, o projeto candidato é identificado,

tratando-se depois do seu plano de financiamento e sendo assegurado um

compromisso de realização. Tratar destas questões numa fase inicial evita

problemas futuros em fases mais avançadas do desenvolvimento do projeto.

Fase 2: Ciclo de Vida do Projeto - A visão geral de um processo DSDM,

presente na Figura 9, representa o Ciclo de Vida do Projeto nesta segunda fase da

metodologia. Ela mostra os cinco níveis que a equipe de desenvolvimento terá de

percorrer para criar um sistema. Os dois primeiros níveis, o Estudo de Viabilidade

e o Estudo de Negócio, são fases seqüenciais que se complementam. Depois

destas fases estarem concluídas, o sistema é desenvolvido iterativamente e de

forma incremental nos níveis de Análise Funcional, Desenho e Implementação.

o Nível 1: Durante este nível do projeto, a viabilidade de utilização do DSDM é

examinada. Os pré-requisitos para o uso do DSDM são encontrados

respondendo a questões como: “Pode este projeto ir de encontro às

necessidades de negócio apontadas?”, “É, este projeto, adequado ao uso do

DSDM?” e “Quais são os riscos mais importantes envolvidos?”. As técnicas

mais importantes utilizadas nesta fase são os workshops. Para entrega ao

cliente, são preparados neste nível o Relatório e o Protótipo de Viabilidade

que dizem respeito à viabilidade do projeto em mãos. A estes, adicionam-se

um esboço global do plano para o resto do projeto e um Registro de Risco que

identifica os riscos mais importantes.

56

o Nível 2: O Estudo do Negócio - O Estudo do Negócio incrementa todo o

trabalho realizado no Estudo de Viabilidade. Depois do projeto ser declarado

viável para o uso do DSDM, é que este nível examina o processo de

financiamento, os utilizadores envolvidos e as suas necessidades e desejos.

Utiliza técnicas de workshop, nos quais os diferentes stakeholders se reúnem

e discutem o sistema proposto. As informações retiradas dos workshops são

combinadas numa lista de requisitos.

o Nível 3: Análise Funcional - Os requisitos que foram identificados nos níveis

anteriores são convertidos para um Modelo Funcional. A Prototipagem é uma

das técnicas-chave dentro deste nível, que ajuda no bom envolvimento do

utilizador final com o projeto. O protótipo desenvolvido é revisto pelos

diferentes grupos de utilizadores. Para assegurar a qualidade do projeto, os

testes são implementados em cada iteração do DSDM. Uma importante parte

dos testes é realizada na Análise Funcional. O Modelo Funcional pode ser

subdividido em quatro sub-níveis:

Identificar Protótipo Funcional: determinar as funcionalidades a serem

implementadas no protótipo que resulta desta iteração.

Acordar Calendário de Tarefas: definir como e quando desenvolver

estas funcionalidades.

Criar Protótipo Funcional: desenvolver o protótipo.

Rever o Protótipo: procurar correções possíveis no protótipo

desenvolvido. Isto pode ser feito através de testes com utilizadores finais

e revendo a documentação.

o Nível 4: Desenho - O objetivo desta iteração é a integração dos componentes

funcionais do nível anterior num sistema que satisfaça as necessidades do

utilizador. Mais uma vez, os testes são uma das atividades mais importantes.

O Desenho pode ser dividido em quatro subníveis:

Identificar Protótipo de Desenho: identificar requisições funcionais e

não-funcionais que são necessárias no sistema testado.

Acordar Calendário de Tarefas: definir como e quando desenvolver

estes requisitos.

Criar Protótipo de Desenho: criar um sistema que possa, com

segurança, ser fornecido aos utilizadores finais para um uso diário.

57

Rever Protótipo de Desenho: verificar a exatidão do sistema desenhado.

Mais uma vez, os testes e revisões são peças fundamentais.

o Nível 5: Implementação - No nível de Implementação, o sistema testado e a

sua documentação são entregues aos utilizadores finais que deverão começar

a ser treinados para a futura utilização do novo sistema. O sistema a ser

entregue deve ter sido revisto para incluir todos os requisitos definidos nos

primeiros níveis do projeto. O nível de implementação pode ser dividido em

quatro sub-níveis:

Aprovação do utilizador.

Treinamento dos utilizadores.

Implementação do sistema no local de trabalho dos utilizadores.

O impacto do sistema implementado no negócio.

Fase 3: Pós-Projeto - A fase de pós-projeto assegura um sistema de atuação

eficiente. Isto é implementado através da manutenção e melhoramentos de acordo

com os princípios do DSDM. Até mesmo a iniciação de novos projetos, para

atualizar o sistema existente ou desenvolver um novo sistema, é possível.

Portanto, o DSDM é um framework para o desenvolvimento ágil em projetos de

software, que segue um conjunto de onze princípios, segundo Teixeira et al (2006) e apresenta

em sua estrutura um ciclo de vida do projeto composto por três fases.

2.1.2.4 Comparativo dos métodos ágeis

Na Tabela 6 será apresentado um resumo comparativo, contendo

princípios/características e ciclo de vida, fases ou processos entre os métodos ágeis: Scrum,

APM e DSDM.

Os princípios/características destes três métodos ágeis se caracterizam por serem

adaptativos, flexíveis, rápidos e por procurarem promover a auto-organização.

Com relação ao ciclo de vida, fases ou processos apesar de serem distintos, entre os

métodos, eles estão alinhados aos seus princípios/características.

58

Tabela 6: Comparativo dos métodos ágeis de gerência de projetos

ITEM SCRUM

(1)

Agile Project

Management (APM)

(2)

Dynamic Systems Development Method

(DSDM)

(3)

O que é

É um método ágil para

gerenciamento de projetos,

que se caracteriza por ser um

método adaptativo, flexível,

rápido e por promover a auto-

organização.

Surge como uma

nova plataforma de

gerenciamento de

projetos, aplicável a

ambientes instáveis e

desafiadores, sujeitos a

mudanças freqüentes,

nos quais o processo

prescritivo e

padronizado não mais

se adéqua.

É um framework para o desenvolvimento

ágil em projetos de software e tem como

objetivo principal gerenciar as ações dentro

dos limites desejados a respeito de tempo

reduzido e de orçamento apertado.

Princípios /

Características Pequenas equipes de

trabalho são organizadas de

modo a “maximizar a

comunicação, minimizar a

supervisão e maximizar o

compartilhamento de

conhecimento tácito

informal”.

O processo precisa ser

adaptável tanto às

modificações técnicas quanto

de negócios “para garantir

que o melhor produto

possível seja produzido”.

O processo produz

freqüentes incrementos de

software “que podem ser

inspecionados, ajustados,

testados, documentados e

expandidos”.

O trabalho de

desenvolvimento e o pessoal

que o realiza é dividido “em

partições claras, de baixo

acoplamento, ou em pacotes”.

Testes e documentação

constantes são realizados à

medida que o produto é

construído.

O processo Scrum fornece

a “habilidade de declarar o

produto „pronto‟ sempre que

necessário (porque a

concorrência acabou de

entregar, porque a empresa

precisa de dinheiro, porque o

usuário/cliente precisa das

funções, porque foi para essa

data que foi prometido ...)”.

Entrega valor ao

cliente.

Gera entregas

iterativas e baseadas

em funcionalidades.

Busca a excelência

técnica.

Encoraja a

exploração.

Constrói times

adaptativos (auto-

organizados e auto-

disciplinados).

Simplifica .

O ponto fundamental desta metodologia

prende-se à entrega de um sistema que se

aproxime das atuais necessidades de negócio.

Nenhum sistema é completamente

construído na primeira tentativa.

A entrega do projeto deve ser feita na data

estipulada, dentro do orçamento previsto e

com boa qualidade.

Testes ao longo de cada iteração.

Entregas freqüentes.

As exigências para o Sistema de

Informação têm que ser flexíveis.

Requer que cada etapa do desenvolvimento

seja completada até que seja possível iniciar

o passo seguinte. Isto faz com que cada fase

do projeto possa começar sem ter que esperar

que as fases que começaram anteriormente

sejam totalmente terminadas.

A comunicação entre todas as partes

envolvidas (stakeholders) é também um pré-

requisito bastante importante para que o

projeto corra com a eficiência desejada.

O envolvimento dos utilizadores é a chave

para esta eficiência.

As equipes responsáveis têm que ser

dotadas de um sentido de decisão, sendo este

também um ponto fulcral na progressão do

projeto.

As equipes de gestão do projeto estão

incorporadas na DSDM.

Após o desenvolvimento do Sistema de

Informação, a DSDM pode também ser usada

para expandir o Sistema obtido.

Fonte: (1) Pressman (2006) e Vicente (2010);

(2) Highsmith (2004) apud Dias e Soler (2005) e Highsmith (2004) apud Conforto (2009);

(3) Giuffra; Vilain (2010) e Teixeira et al. (2006).

59

Tabela 6: Comparativo dos métodos ágeis de gerência de projetos (Cont.)

ITEM SCRUM

(1)

Agile Project

Management (APM)

(2)

Dynamic Systems Development Method

(DSDM)

(3)

Ciclo de vida,

Fases ou

Processos

Visão do produto e definição

do backlog do produto

Planejamento do sprint

(backlog selecionados e

backlog do sprint):

Sprint de desenvolvimento:

Reunião de revisão do sprint

e retrospectiva:

Visão;

Especulação;

Exploração;

Adaptação;

Encerramento.

Fase 1: Pré-Projeto

Fase 2: Ciclo de Vida do Projeto.

o Nível 1: Viabilidade de utilização do

DSDM

o Nível 2: Estudo do Negócio

o Nível 3: Análise Funcional

o Identificação do Protótipo Funcional.

o Definição do Calendário de Tarefas.

o Criação do Protótipo Funcional.

o Revisão do Protótipo.

o Nível 4: Desenho -:

o Identificação do Protótipo de

Desenho.

o Definição do Calendário de Tarefas.

o Criação do Protótipo de Desenho.

o Revisão do Protótipo de Desenho.

o Nível 5: Implementação:

o Aprovação do utilizador.

o Treinamento dos utilizadores.

o Implementação do sistema no local

de trabalho dos utilizadores.

o Impacto do sistema implementado no

negócio.

Fase 3: Pós-Projeto.

Fonte: (1) Pressman (2006) e Vicente (2010);

(2) Highsmith (2004) apud Dias e Soler (2005) e Highsmith (2004) apud Conforto (2009);

(3) Giuffra; Vilain (2010) e Teixeira et al. (2006).

2.1.3 Comparativo dos métodos “tradicional” e ágeis

A seguir será apresentada uma comparação entre os métodos de gerenciamento de

projetos (GP) “tradicionais” e ágeis. Os métodos tradicionais são mais estruturados que os

métodos ágeis e podem ser utilizados / adaptados para o gerenciamento de projetos de

diversas áreas. Já os métodos ágeis sugiram da área de TI, mais especificamente da área de

desenvolvimento de software. Não se encontrou exemplo de aplicações dos métodos ágeis em

áreas que não fossem relacionadas ao desenvolvimento de software.

A comparação entre os métodos “tradicional” e ágeis é abordada de diferentes formas

dependendo do autor. Por exemplo, Dias (2005 apud ARAUJO, 2008) apresenta as diferenças

em termos de grupos de processos e fases (Tabela 7). Já Ribeiro; Arakaki (2006 apud

LOPES, 2008) abordam as diferenças sob diversos tópicos (objetivo principal, tipo de projeto,

tamanho, gerente de projeto, equipe do projeto, cliente, planejamento, arquitetura, modelo de

60

desenvolvimento, comunicação e controle de mudanças) (Tabela 8); Magalhães (2004)

apresenta as diferenças de abordagem também sob diversos aspectos (Tabela 9) e Costa

(2008) mostra uma comparação feita pela empresa Innovit, entre GP tradicional e GP ágil

através das áreas de conhecimento de GP (Tabela 10).

Tabela 7: Correspondência entre as abordagens tradicional e ágil de GP

GRUPO DE PROCESSOS DO GP

TRADICIONAL

FASES DO GP ÁGIL

Iniciação: autorização/definição de um escopo

preliminar.

Visão: do projeto e escopo inicial do projeto

Planejamento: detalhamento de todo o projeto. Especulação: plano inicial, planejamento a cada iteração.

Execução: execução do plano do projeto. Exploração: entrega funcionalidade/produto a cada ciclo.

Monitoramento e Controle: progresso do trabalho

e gerenciamento de mudanças.

Adaptação: revisão dos resultados, entregas e adaptações

do escopo.

Encerramento: formalização do aceite final do

projeto.

Encerramento: aceites do cliente a cada ciclo e

formalização final.

Fonte: Dias (2005) apud ARAUJO (2008).

Tabela 8: Principais características entre GP de software, tradicional e ágil.

TÓPICO PRINCIPAIS CARACTERÍSTICAS

MÉTODO TRADICIONAL MÉTODO ÁGIL

Objetivo principal Orientado por atividade e centrado em

processo.

Orientado por produto e centrado em

pessoas.

Tipo de projeto Estável e com baixo nível de

mudanças.

Projeto com mudanças constantes e que

necessita de respostas rápidas.

Tamanho Aplicável em projetos de todos os

tamanhos. Mais efetivo em projetos de

maior duração.

Mais efetivo em projetos pequenos (poucas

pessoas na equipe).

Gerente de projeto Controle total do projeto. Papel de facilitador ou coordenador.

Equipe do projeto Atuação com papéis claros e bem

definidos.

Atuação colaborativa em todas as

atividades do projeto.

Cliente Participa das fases iniciais de

requisitos e das validações dos

produtos.

Essencial. Deve ser parte integrante da

equipe do projeto.

Planejamento Detalhado e os envolvidos têm o papel

de validação, não participam da

elaboração do planejamento.

Curto e com participação de todos os

envolvidos na elaboração do planejamento.

Arquitetura Definida com foco em todo o projeto e

na reusabilidade.

Aplicação de design simples. Evolui junto

com o projeto e baseia-se na refatoração.

Modelo de

desenvolvimento

Cascata, espiral e iterativo. Iterativo e incremental.

Fonte: Ribeiro; Arakaki (2006) apud LOPES (2008)

61

Tabela 8: Principais características entre GP de software, tradicional e ágil (Cont.)

TÓPICO PRINCIPAIS CARACTERÍSTICAS

MÉTODO TRADICIONAL MÉTODO ÁGIL

Comunicação Formal. Informal.

Controle de mudanças Processo formal de identificação e

aprovação entre os envolvidos.

Incorporação de novos requisitos pode

ser lenta e cara.

Dinâmico e com rapidez de incorporação

nas iterações.

Fonte: Ribeiro; Arakaki (2006) apud LOPES (2008)

Tabela 9: Diferenças de abordagens de GP tradicional e ágil.

ABORDAGEM TRADICIONAL ABORDAGEM ÁGIL

Preditivo: detalhar o que ainda não é bem conhecido. Adaptativo: conhecer o problema e resolver o crítico

primeiro.

Rígido: seguir especificação predefinida, a qualquer

custo.

Flexível: adaptar-se a requisitos atuais, que podem

mudar.

Burocrático: controlar sempre, para alcançar objetivo

planejado.

Simplista: fazer algo simples de imediato e alterar, se

necessário.

Orientado a processos: segui-los possibilita garantir

a qualidade.

Orientado a pessoas: motivadas, comprometidas e

produtivas.

Documentação gera confiança. Comunicação gera confiança.

Sucesso: entregar o planejado. Sucesso: entregar o desejado.

Gerência: “comando-e-controle” voltado para

trabalho em massa; ênfase: papel do gerente, com

planejamento e disciplina fortes.

Gerência: liderança / orientação trabalhadores do

conhecimento; ênfase: criatividade,flexibilidade,

atenção às pessoas.

Desenvolvedor hábil (variedade). Desenvolvedor ágil (colaborador).

Cliente pouco envolvido. Cliente comprometido (autonomia).

Requisitos conhecidos, estáveis. Requisitos emergentes, mutáveis.

Retrabalho/reestruturação cara. Retrabalho/reestruturação barata.

Planejamento direciona os resultados (incentiva a

controlar).

Resultado direciona o planejamento (incentiva a

mudar).

Conjunto de processos, com metodologia definida.. Conjunto de valores, com atitudes e princípios

definidos.

Premia a garantia da qualidade. Premia o valor rápido obtido.

Foco: grandes projetos ou os com restrições de

confiabilidade, planej. estratégico / priorização

(exigem mais formalismo).

Foco: projetos de natureza exploratória e inovadores,

com equipes pequenas a médias (exigem maior

adaptação).

Objetivo: controlar, possibilitando alcançar o

objetivo planejado (tempo, orçamento, escopo).

Objetivo: simplificar processo de desenvolvimento,

minimizando e dinamizando tarefas e artefatos.

Fonte: Magalhães (2004)

62

Na Tabela 10 seguem as informações citadas pela empresa Innovit comparando a visão

de gestão de projetos, utilizando PMBOK (Gerenciamento Tradicional) e Scrum

(Gerenciamento Ágil), com relação às áreas dos processos (escopo, tempo, custo, qualidade,

riscos, comunicação, recursos humanos, aquisição e integração).

Em todas as áreas dos processos pode-se observar que as diferenças são muitas.

Poderíamos resumir essas diferenças sob o ponto de vista dos objetivos de cada método. O

gerenciamento tradicional possui um maior detalhamento e controle do projeto, sendo

orientado por atividades e centrado nos processos bem definidos, enquanto o gerenciamento

ágil trabalha com o conceito de plano de projeto evolutivo, com pouco detalhamento e com

equipes auto-gerenciáveis, sendo orientado por produto e centrado em pessoas. Veja a seguir

as principais diferenças em cada uma das áreas do processo.

Tabela 10: Comparativo entre gerenciamento de projetos tradicional e gerenciamento de

projetos ágil.

ÁREA DO

PROCESSO

GERENCIAMENTO TRADICIONAL GERENCIAMENTO ÁGIL

Escopo Bem definido nas fases iniciais do projeto e

formalizado através da WBS (Work Breakdown

Structure).

Escopo definido em alto nível e os requisitos são

priorizados e definidos de forma iterativa. Necessita de

maior controle de gold plating9.

Tempo Cronograma detalhado para a realização de todo o

projeto.

Cronograma articulado ao produto com entregas

incrementais de 2-4 semanas.

Custo Monitoração das alterações para que não afete o

custo planejado.

Maior controle em função da rapidez na incorporação

de alterações.

Qualidade Processos de verificação e validação e plano de

testes.

Programação em pares, testes incrementais e

refatoração.

Riscos Análise de riscos durante todo o ciclo de vida do

projeto.

Aplica-se o mesmo conceito do gerenciamento

tradicional.

Comunicação Documentado e formal. Implícita, interpessoal e colaborativa.

Recursos

Humanos

Papéis claros e bem definidos. Confiança nos membros da equipe e ambiente

colaborativo.

Aquisição Controle por contrato e escopo bem definido e

documentado.

Presença do cliente, volatilidade de requisitos e pouca

documentação tornam o processo um desafio.

Integração Plano do projeto detalhado e controle total do

projeto pelo gerente.

Plano do projeto evolutivo e gerente do projeto atuam

como facilitador.

Fonte: Costa (2008)

9 Gold plating: impedir a realização de trabalho extra que não faça parte do projeto.

63

2.2 Processos de gerenciamento de riscos

No item 2.1 desta dissertação foi apresentada uma visão geral de alguns padrões de

conhecimento, métodos ou normas de gerenciamento de projetos “tradicionais” (PMBOK,

PRINCE2 e P2M) e de métodos ágeis de gerenciamento de projetos (Scrum, APM e DSDM).

Neste item será apresentada uma visão geral de como cada um desses métodos abordam

o gerenciamento de riscos e um comparativo entre os mesmos.

2.2.1 Métodos “tradicionais”

2.2.1.1 Abordagem do Project Management Book of Knowledge (PMBOK)

O processo de gerenciamento dos riscos do projeto faz parte das nove áreas de

conhecimento da gerência de projetos do PMBOK (Figura 2) e seu objetivo é aumentar a

probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o impacto dos

eventos negativos no projeto (PMI, 2008).

A Figura 10 apresenta um resumo dos processos de gerenciamento dos riscos segundo o

PMBOK, 4ª edição (PMI, 2008).

Segue uma breve descrição dos seis processos de gerenciamento de riscos segundo PMI

(2008):

Planejar o gerenciamento dos riscos: definição de como conduzir as

atividades de gerenciamento dos riscos que serão executadas para o projeto.

Identificar os riscos: determinação dos riscos que podem afetar o projeto e

documentação de suas características.

Realizar a análise qualitativa dos riscos: priorização dos riscos para análise e

das condições para priorizar seus efeitos nos objetivos do projeto.

Realizar a análise quantitativa dos riscos: avaliação da probabilidade de

ocorrência e as conseqüências dos riscos e estimar as suas implicações nos

objetivos do projeto.

Planejar as respostas aos riscos: desenvolvimento de procedimentos e

técnicas para aumentar as oportunidades e reduzir as ameaças aos objetivos do

projeto.

64

Monitorar e controlar os riscos: implementação de planos de respostas aos

riscos, monitorar riscos residuais, identificar novos riscos, executar planos de

redução de riscos e avaliar seus efeitos através do ciclo de vida de projeto.

GERENCIAMENTO DOS

RISCOS DO PROJETO

Planejar o gerenciamento dos riscos

1. Entradas

declaração do escopo do projeto

Plano de gerenciamento dos custos

Plano de gerenciamento do cronograma

Plano de gerenciamento das

comunicações

Fatores ambientais da empresa

Ativos de processos organizacionais

2. Ferramentas e técnicas

Reuniões e análises de planejamento

3. Saídas

Plano de gerenciamento dos riscos

Realizar a análise qualitativa dos

riscos

1. Entradas

Registro dos riscos


Declaração do escopo do projetos



Avaliação de probabilidade e impacto

dos riscos

Matriz de probabilidade e impacto

Avaliação da qualidade dos dados

sobre riscos

Categorização de riscos

Avaliação da urgência dos riscos

Opinião especializada

3. Saídas

Atualizações do registro dos riscos

Identificar os riscos

1. Entradas


Estimativa de custos das atividades

Estimativa de duração das atividades

Linha de base do escopo

Registro de partes interessadas



Plano de gerenciamento da qualidade

Documentos do projeto

Fatores ambientais da empresa



Revisões de documentação

Técnicas de coleta de informações

Análise de listas de verificação

Análise de premissas

Técnicas de diagramas

Análise das forças, fraquezas,

oportunidades e ameaças


3. Saídas

Registro dos riscos

Realizar a análise quantitativa dos

riscos

1. Entradas

Registro dos riscos






Técnicas de coleta e apresentação de

dados

Técnicas de modelagem e análise

quantitativa de riscos


3. Saídas


Planejar as respostas aos riscos

1. Entradas

Registro dos riscos



Estratégias para riscos negativos ou

ameaças

Estratégias para riscos positivos ou

oportunidades

Estratégias de respostas de

contingência


3. Saídas


Decisões contratuais relacionadas a

riscos

Atualizações do plano de gerenciamento

do projeto

Atualizações dos documentos do projeto

Monitorar e controlar os riscos

1. Entradas

Registro dos riscos

Plano de gerenciamento do projeto

Informações sobre o desempenho do

trabalho

Relatórios de desempenho


Reavaliação de riscos

Auditorias de riscos

Análise da variação e tendências

Medição de desempenho técnico

Análise das reservas

Reuniões de andamento

3. Saídas


Atualizações dos ativos de processos

organizacionais

Solicitações de mudanças

Atualizações do plano de gerenciamento

do projeto

Atualizações dos documentos do projeto

Figura 10: Resumo dos processos de gerenciamento dos riscos do projeto – PMBOK (4ª

edição). Fonte: PMI (2008, p. 227)

2.2.1.2 Abordagem do Project In a Controlled Environment (PRINCE2)

O PRINCE2 define o gerenciamento de riscos em momentos-chave onde os riscos

devem ser avaliados e revisados, além da abordagem a ser aplicada em sua manutenção.

65

O gerenciamento de riscos do projeto inclui os processos relacionados com identificar

os riscos, avaliar os riscos, identificar as respostas adequadas ao risco, selecionar, planejar os

recursos e monitorar e controlar os riscos.

O objetivo do gerenciamento de riscos, segundo o PRINCE2, é identificar, avaliar e

controlar a incerteza (riscos) e, como conseqüência, ampliar a capacidade de sucesso do

projeto.

A ocorrência de riscos em projetos é inevitável, já que são geralmente portadores de

mudanças e as mudanças podem introduzir uma incerteza, ou seja, o risco.

O gerenciamento de riscos deve ser sistemático e não com base ao acaso. Trata-se da

proatividade na identificação, avaliação e controle dos riscos que podem afetar os objetivos

do projeto.

O projeto deve estimar um orçamento para o gerenciamento de riscos com o objetivo de

apoiar uma melhor tomada de decisão através de uma boa compreensão dos riscos: suas

causas, probabilidade, impacto, cronograma, e seleção de respostas aos riscos (PRINCE2,

2010).

O gerenciamento de risco é uma atividade contínua, realizada ao longo do ciclo de vida

do projeto. Sem um processo contínuo e eficaz de gerenciamento de riscos torna-se difícil

fazer com que o projeto seja capaz de atingir os seus objetivos.

Segundo PRINCE2 (2010) para que o gerenciamento de risco seja eficaz, os riscos

devem ser identificados, avaliados e controlados.

Identificar significa incluir os riscos que poderiam afetar a realização dos objetivos do

projeto e, em seguida deve-se descrevê-los para garantir um entendimento (compreensão)

comum desses riscos.

Avaliar significa assegurar que cada risco possa ser classificado em termos de

estimativa, probabilidade de ocorrência e impacto.

Controlar significa identificar respostas adequadas aos riscos e depois executar,

acompanhar e controlar estas respostas.

O PRINCE2 (2010) recomenda um procedimento de gerência de risco que compreende

cinco etapas (Figura 11).

66

Identificação

Estimar e Avaliar

Planejar respostas aos

riscos

Implementar Comunicar

Figura 11: Procedimento de gerência de Risco. Fonte: PRINCE2 (2010, p.7)

As quatro primeiras etapas são sequenciais 1-identificação do contexto do projeto e dos

riscos; 2-estimativa e avaliação dos riscos; 3-planejamento de respostas aos riscos e 4-

implementação de respostas aos riscos. A etapa “comunicar” acontece em paralelo às demais

etapas, porque os resultados de qualquer das outras etapas podem precisar ser comunicados

sempre que for necessário. Todas as etapas são iterativas, de forma que, quando informações

adicionais estiverem disponíveis, geralmente é necessário revisitar as etapas anteriores e

executá-las novamente para conseguir o resultado mais eficaz (PRINCE, 2010).

2.2.1.3 Abordagem do Guidebook for Project and Program Management for Enterprise

Innovation (P2M)

Os projetos são acompanhados de incertezas que contém sempre um risco e, se não

forem tomadas medidas para lidar com riscos, bons resultados não podem ser obtidos a partir

dos projetos.

As medidas para lidar com o risco não têm sido, conforme tal, (PMAJ, 2005)

valorizadas nas empresas e como conseqüência grandes riscos têm sido tolerados. No entanto,

atualmente, caracterizada pela rápida inovação técnica, pela crescente demanda por uma

reforma financeira em projetos estaduais e privados, pela redução dos prazos e orçamentos

dos projetos, e pela intensificação da concorrência, a exigência de prestação de contas deverá

tornar-se cada vez mais forte. Nesse sentido, a utilização mais ampla de gestão de risco é

considerada inevitável.

67

Orientações Práticas• Projetos sempre trazem incerteza e risco.

• Pense que o risco pode ser gerenciado.

Mudanças ambientais

Condições de restrição

• Políticas e ambiente gerencial das organizações que são colocados em uma

posição superior.

• Mudança no ambiente social, nas políticas estratégicas enquanto o projeto

está em andamento, nas técnicas e recursos humanos, prazos e restrição

econômica.

Objetivos Processos de Trabalho Resultados

• Reconhecimento de incerteza e

risco, e estabelecimento de

medidas.

• Desafio de incerteza e risco, e

decisão de aceitação.

• Minimizar o custo da perda.

• Assegurar a prestação de contas.

Base de conhecimentos

• Coleta de casos de projetos similares de risco (checklist / modelo).

• Uso de base histórica para melhorar a precisão das atividade do cronograma

(histórico).

• Base de dados para a coleta de casos de respostas a risco, dados, etc.

• Plano básico.

• Identificação de risco.

• Análise e avaliação de risco.

• Planejamento de medidas contra

o risco.

• Medição dos riscos.

• Avaliação da gestão de risco.

• Prevenir a despesa de exceder o

orçamento.

• Assegurar a segurança e a

cobertura de risco.

• Conclusão do projeto dentro do

orçamento.

• Conclusão do projeto dentro do

prazo.

• Satisfação do cliente.

• Melhoria do salário do negócio.

• Ampliação dos negócios.

Figura 12: Visão geral do gerenciamento de riscos. Fonte: PMAJ (2005, p.138)

A gestão de riscos começa com a elaboração de uma política própria, com base no

ambiente onde o projeto está inserido, nos planos e contratos. Em seguida, os eventos de risco

são identificados por meio da análise das condições de restrição e incertezas que estão

incluídos na política geral do projeto, nos documentos de contrato etc. Através da análise e

avaliação quantitativa, as respostas ao risco são planejadas, implementadas, avaliadas e

controladas durante todo o ciclo de vida do projeto.

Os processos de gerência de risco são realizados repetidamente, e não apenas uma vez

na fase inicial do projeto. Da mesma forma como podem ser observadas em outras áreas da

gestão de projetos, as lições aprendidas sobre o risco têm que ser organizadas e utilizadas

através da criação de um banco de dados. O conhecimento adquirido sobre gestão de risco,

assim, deve ser utilizado por meio da integração de habilidades práticas nas fases de

planejamento e implementação do projeto (PMAJ, 2005).

O processo de gestão de riscos começa com a elaboração de um plano básico, e o

processo acontece conforme Figura 13.

68

Plano básico

(formulação de política de riscos)

Identificação de riscos

Análise e avaliação de riscos

Planej. de medidas contra riscos

(planej. de resposta aos riscos)

Medição dos riscos (execução do

plano de resposta aos riscos)

Mo

nit

ora

men

to e

co

ntr

ole

do

s ri

sco

s

Figura 13: Processo de gerenciamento de riscos. Fonte: PMAJ (2005, p.144)

Segue uma breve descrição dos seis processos de gerenciamento de riscos segundo

PMAJ (2005):

Plano básico (formulação de política de riscos): processo para expor

políticas básicas sobre métodos e estratégias para gestão de riscos na

implementação do projeto.

Identificação de riscos: processo para analisar quais as fontes de risco ou

eventos que exercem influência sobre a implementação do projeto; descreve as

características dos riscos em documentos através de brainstorming e faz uma

revisão de requisitos dos contratos.

Análise e avaliação de risco: processo de avaliar e quantificar a probabilidade

e a influência dos eventos considerados causadores de risco a e interação entre

os riscos.

Planejamento de medidas contra riscos (planejamento de resposta aos

riscos): processo para elaborar medidas preventivas, incluindo a aversão ao

risco, mitigação, distribuição e transferência de riscos para terceiros a fim de

maximizar as oportunidades e minimizar as ameaças.

Medição dos riscos (execução do plano de resposta aos riscos): processo

para executar o plano de resposta aos riscos.

Monitoramento e controle dos riscos: processo de controle e

acompanhamento da implementação de identificação de riscos.

69

2.2.2 Métodos ágeis

2.2.2.1 Abordagem do Scrum

Para Marçal et al. (2007), um risco é um possível impedimento para o projeto e no

Scrum a identificação dos riscos é realizada de forma iterativa, durante as reuniões diárias do

time, sendo os mesmos documentados em quadro branco, flipcharts e na lista de

impedimentos (Impediment Backlog). No entanto não existem práticas explícitas para definir

fontes, parâmetros e categorias de riscos que devem ser usados para analisar, categorizar, bem

como, para controlar o esforço do gerenciamento dos riscos.

“Assim, as reuniões diárias buscam levantar impedimentos (problemas,

dependências, riscos etc.). Logo há uma identificação e monitoramento dos

impedimentos pelo ScrumMaster. Entende-se que no Scrum as ações corretivas para

os impedimentos levantados são tomadas. Entretanto não há registro de planos de

ações corretivas, nem de documentação relativa a isso, nem tampouco análise de

resultados para determinar a eficácia das ações corretivas tomadas. (...) Também não

há uma estratégia para o gerenciamento dos riscos, nem mesmo um plano de

mitigação para os riscos mais importantes e uso de bases históricas. Assim sendo, a

avaliação, categorização e priorização dos riscos ficam comprometidas.” (MARÇAL

et al., 2007)

Marçal et al. (2007) em seu estudo apresenta o que deve ser feito para que as práticas de

gerenciamento de riscos possam ser compatíveis com o Scrum, como por exemplo,

planejamento, monitoramento e controle do projeto relacionado a riscos. Para tanto deve-se

incluir as atividades para identificação, análise, priorização, criação de planos de ação para

tratar os riscos de maior prioridade, e realizar o monitoramento e controle dos riscos. Essas

atividades devem ser inseridas no contexto das reuniões do Scrum, conforme descritas a

seguir por Marçal et al. (2007):

1. Identificar Riscos: a identificação dos riscos deve acontecer: durante a Sprint

Planning 1, (etapa 1 da Figura 7) com foco nos itens do Product Backlog com

maior valor de negócio durante as reuniões diárias (Daily Scrum), (etapa 3 da

Figura 7) como possíveis impedimentos para o projeto. A identificação dos

riscos pode ser realizada através do método de brainstorming (PRESTON;

PICHLER, 2005). Um checklist contendo fontes e categorias de riscos pode ser

introduzido, visando facilitar esta tarefa. Os riscos identificados devem ser

adicionados ao Impediment Backlog.

2. Analisar Riscos: a análise de riscos deve ser realizada durante a Sprint

Planning 1 (etapa 1 da Figura 7) e compreende etapas para determinar: (a)

70

impacto (alto, médio e baixo); (b) probabilidade (alta, média e baixa); e (c) o

fator de exposição do risco, obtido a partir do produto entre o seu impacto e a

sua probabilidade (ver também CAIXETA, 2006). Alguns ajustes no fator de

exposição ao risco podem ser aplicados para tratar aspectos específicos do

projeto e de qualidade como definidos por Chin (2004) apud Marçal et

al.(2007). A análise dos riscos nos ajuda a estabelecer uma importância relativa

entre os mesmos e é útil na priorização dos riscos.

3. Priorizar os Riscos: seguindo um princípio ágil, Preston e Pichler (2005)

sugerem que os riscos sejam priorizados. Após a priorização, os riscos

considerados mais urgentes devem ser gerenciados e mitigados na próxima

Sprint (etapa 3 da Figura 7). Os demais riscos ficam “guardados”, devendo ser

reavaliados na próxima reunião de Sprint Planning (etapa 2 da Figura 7). A

priorização dos riscos deve ocorrer na reunião de Sprint Planning 1 (etapa 3 da

Figura 7), auxiliando na priorização e seleção dos itens de backlog que serão

desenvolvidos na próxima Sprint.

4. Criar planos de ações: os planos de ação correspondem às ações que devem

ser tomadas para responder aos riscos, visando reduzir o fator de exposição do

risco (probabilidade e/ou impacto). Este plano deve ser criado durante a Sprint

Planning 2 (etapa 2 da Figura 7), em conjunto com identificação das tarefas

que serão executadas para implementar os itens do Selected Product Backlog.

Assim sendo, as ações entram no Sprint Backlog e devem ser realizadas e

monitoradas continuamente pela equipe durante as reuniões diárias do Scrum

(etapa 3 da Figura 7). Durante a execução da Sprint, riscos podem se

transformar em problemas, e nestes casos, o risco passa a ser tratado como

impedimentos no Scrum. Planos de ações de contingência, seguindo uma

abordagem ágil, são elaborados (na Sprint Planning 2 – etapa 2 da Figura 7)

apenas para os riscos priorizados e com fator de exposição alto. Estes riscos

devem ser reavaliados à medida que transformam-se em problemas, sendo

tratados pelo ScrumMaster que é o responsável pela resolução dos

impedimentos.

5. Monitorar continuamente os riscos: os riscos são monitorados diariamente,

nas reuniões diárias (Daily Scrum Meetings – etapa 3 da Figura 7), e também

durante os planejamentos da Sprint (Sprint Plannings etapa 2 da Figura 7),

quando devem ser reavaliados em conjunto com os demais riscos identificados.

71

É importante observar que para garantirmos a agilidade, apenas um

subconjunto dos riscos está sendo monitorado a cada Sprint. Este subconjunto é

representado pelos riscos que foram priorizados e que estão diretamente

relacionados com os itens do Selected Product Backlog.

2.2.2.2 Abordagem do Agile Project Management (APM)

De acordo com Ribeiro e Gusmão (2008), o gerenciamento de riscos no APM é

abordado nas fases (Figura 8) de Especulação e de Exploração. A fase de Especulação é onde

são feitas a definição dos requisitos, estimativas e estratégias de mitigação de riscos; é nesta

fase que se cria também um plano baseado em release, milestones e iterações. A fase de

Exploração engloba a entrega dos recursos planejados, através do gerenciamento das

atividades e do emprego de práticas e estratégias de mitigação de riscos planejadas.

Para Marçal et al. (2007), o gerenciamento ágil de processos tem práticas que visam

atender a dois desafios: “o primeiro é que elas devem integrar as atividades de gerenciamento

de riscos dentro das atividades de planejamento da iteração” (Figura 8); “o segundo é que elas

devem adaptar as práticas de gerenciamento de riscos de forma que todo o time possa realizá-

las rapidamente”.

Segundo Hazrati (2008), o tratamento da gestão de risco se dá com a redução da

probabilidade e impacto de eventos adversos em um projeto. O desenvolvimento ágil de

software, devido à sua natureza iterativa, implicitamente torna o gerenciamento de risco uma

parte do ciclo de vida do projeto.

Michele Sliger10

, citada por Hazrati (2008) sugeriu que o gerenciamento de risco no

desenvolvimento de software ágil se dê o tempo todo como uma parte das reuniões diárias

(stand-ups), nas reuniões de planejamento de iteração, nas reuniões de planejamento de

lançamento, nas reuniões de revisão e retrospectiva. Entretanto, a autora sugere uma

abordagem estruturada para gerenciar o risco. As etapas incluídas seriam identificação,

análise, planejamento de resposta e monitoramento e controle de riscos.

10

Michele Sliger trabalha no desenvolvimento de software há mais de quinze anos. Ela atualmente trabalha

como Agile Coach para o Rally de Desenvolvimento de Software, onde treina as equipes de desenvolvimento de

software em metodologias ágeis. Sliger é gerente de projetos da Qwest Communications, uma consultoria de

empresas da Fortune 500, e foi membro fundador das equipes de engenharia de duas pequenas empresas de

biotecnologia. Ela possui certificação Project Management Professional e Certified Scrum Master. Além de seu

serviço no Rally, Sliger também é membro adjunto do corpo docente da Universidade do Colorado, onde leciona

Software de Gerenciamento de Projetos para os alunos de graduação de engenharia.

72

Na identificação de riscos, toda a equipe participa de forma iterativa e os resultados

são anotados em quadro branco ou no flipchart.

A análise de risco é feita através de uma análise qualitativa de risco, usando

julgamento, intuição e experiência na determinação de riscos e perdas potenciais. Nas

iterações dos processos ágeis, ou seja, durante os ciclos curtos de desenvolvimento e revisões

constantes, isso se torna possível e eficaz. Isto é, diferente de projetos tradicionais, onde a

análise quantitativa é feita e os números são atribuídos aos danos que podem ocorrer.

No planejamento de resposta aos riscos, a equipe inteira participa no desenvolvimento

de planos de respostas e ações para reduzir as ameaças.

No monitoramento e controle de riscos, os riscos são monitorados e as estratégias de

controle são discutidas no final de cada iteração do ciclo de vida (Figura 8). Os riscos são

monitorados diariamente através das reuniões diárias.

2.2.2.3 Abordagem do Dynamic Systems Development Method (DSDM)

O objetivo da gestão de risco é controlar os riscos de um projeto e isto inclui:

Identificação de todos os riscos que podem ameaçar o projeto.

Avaliação do impacto destes riscos sobre os objetivos do projeto. Esta

avaliação consiste em decidir sobre a probabilidade de ocorrência do risco e

sobre a gravidade do seu impacto sobre o projeto, caso o risco aconteça.

Gestão dos riscos através da definição de respostas aos riscos específicas e que

visem tanto evitar os riscos identificados, aceitá-los e minimizar seus efeitos

negativos sobre o projeto.

Aplicar as respostas aos riscos, adequadas, quando da ocorrência do risco.

Esta seção aborda como e quando acontece a gestão de risco dentro de um projeto e

inclui possíveis respostas aos riscos que surgem em projetos DSDM.

A Figura 14 fornece uma visão geral do processo de gestão de riscos no DSDM. O

processo começa com uma lista de riscos que é considerado o ponto de entrada para avaliar o

risco de qualquer problema potencial. Posteriormente, o ciclo de gestão de risco progride

através da identificação e documentação dos riscos e do posterior acompanhamento e

avaliação.

73

Lista de Risco

Identificar os

Riscos

Documentar

os Riscos

Monitorar os

Riscos

Responder aos

Riscos

Avaliar e Atualizar

o Documento de

Riscos

Figura 14: Processos de gerenciamento de riscos. Fonte: DSDM Version (4.2)

A seguir será apresentada uma breve descrição das atividades do processo de

gerenciamento de riscos no DSDM.

A identificação dos riscos é parte integrante do processo de avaliação de risco para o

início e o fim de um projeto DSDM. É importante que a identificação do risco seja realizada

na primeira oportunidade, iniciando-se com a análise formal da Lista de Riscos. Ela deve

verificar também se os requisitos que têm uma prioridade elevada no projeto.

O DSDM sugere a classificação dos riscos no processo de identificação de riscos. E

depende do tamanho do projeto. Para projetos pequenos a classificação pode ser limitada a

negócios, sistemas e técnicas, enquanto que para projetos maiores pode ser expandida em

subcategorias, conforme a lista abaixo:

Risco de Negócio:

o Missão e Objetivos.

o Requisitos.

o Incentivo a decisão.

o Gestão da Organização.

o Orçamento / Custo.

Sistemas:

o Usuários-chave.

o Características do Projeto.

o Início de operação do sistema.

74

o Processos.

Técnico:

o Tecnologia.

o Ambiente operacional.

o Ambiente de desenvolvimento.

o Ferramentas de projeto.

o Experiência do pessoal.

No DSDM a documentação dos riscos é feita a partir da identificação e classificação

dos riscos.

O monitoramento dos riscos acontece após estes estarem devidamente documentados,

incluindo aí o responsável pelo monitoramento / acompanhamento de cada risco. Para garantir

que todas as ações de combate ao risco sejam executadas conforme o planejado, o responsável

pelo risco acompanha o seu status até o seu encerramento.

A atividade de respostas aos riscos está preocupada em planejar e implementar

respostas conforme o programado. Estas são avaliadas periodicamente para verificar sua

eficácia e, se houver necessidade, implementar ações adicionais.

Ao avaliar e atualizar o documento de riscos, os seguintes passos devem ser tomados:

Revisão das respostas aos riscos implementadas até a data de avaliação e da

eventual necessidade de novas medidas;

Identificação dos principais riscos documentados até o momento da avaliação e

verificação de mudanças ou de respostas aos riscos que devem ser modificadas;

Desenvolvimento de novas respostas aos riscos ou modificação das já

existentes;

Encerramento de todos os riscos que não tenham ocorrido;

Encerramento de todos os riscos que ocorreram e foram gerenciados

satisfatoriamente.

2.2.3 Comparativo dos métodos

Na Tabela 11 será apresentado um resumo comparativo, contendo as atividades da

gerência de riscos relacionadas a planejamento, identificação, análise qualitativa, análise

75

quantitativa, planejamento de respostas, monitoração e controle, e comunicação de riscos

entre os métodos “tradicionais” (PMBOK, PRINCE2 e P2M) e os métodos ágeis (Scrum,

APM e DSDM).

Conforme pode ser observado na Tabela 11 os métodos tradicionais iniciam o

gerenciamento dos riscos pela atividade de planejamento e em seguida passam à identificação

dos riscos, enquanto que os métodos ágeis já iniciam pela identificação dos riscos.

Com relação à análise qualitativa e quantitativa de riscos, alguns métodos realizam estas

atividades em separado enquanto outros as fazem juntas. O PRINCE 2 não contempla a

atividade de análise qualitativa em seu método, enquanto o APM e o DSDM não contemplam

a análise quantitativa.

Um ponto interessante entre os métodos é que todos eles identificam os riscos de

alguma forma, realizam uma análise qualitativa e/ou quantitativa, mas de maneira geral são

diferentes, fazem um planejamento de respostas aos riscos e fazem uma monitoração e

controle dos riscos no projeto e somente o PRINCE2 possui uma atividade formal de

comunicação de riscos.

Veja a seguir o comparativo entre os métodos. Os campos hachurados, na Tabela 11,

indicam que a atividade não é contemplada para o modelo de gestão de riscos.

Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil

ATIVIDADES

DA

GERÊNCIA

DE RISCO

ABORDAGENS DE GERÊNCIA DE RISCO

PMI PRINCE2 P2M SCRUM APM DSDM

Planejamento Define como

conduzir as

atividades de

gerenciamento

dos riscos que

serão

executadas para

o projeto.

Pressupõe que a

mesma

abordagem para

o gerenciamento

de risco será

usada em todos

os projetos.

Possui um “Plano

Básico” de

formulação de

política de riscos. É

um processo para

expor políticas

básicas sobre métodos

e estratégias para

gestão de riscos na

implementação do

projeto.

Fonte: PMI (2008); PRINCE (2010), Scribd (2010), PMAJ (2005), (MARÇAL et al., 2007), Hazrati (2008) e

DSDM Version 4.2.

76

Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil (Cont.)

ATIVIDADES

DA

GERÊNCIA

DE RISCO



Identificação

de Riscos

Determina os

riscos que

podem afetar o

projeto e

documenta suas

características.

Identificado pela

Gerência de

componente de

risco.

Analisa quais as

fontes de risco ou

eventos que

exercem

influência sobre a

implementação do

projeto e descreve

as características

dos riscos em

documentos

através de

brainstorming e

revisão de

requisitos dos

contratos.

A identificação dos

riscos deve

acontecer: a) durante

a Sprint Planning 1,

com foco nos itens

com maior valor de

negócio; b) durante

as reuniões diárias

como possíveis

impedimentos para o

projeto.

Toda a equipe

participa deste

exercício de forma

iterativa e os

resultados são

anotados em post-it

ou no flip chart.

Os riscos são

identificados,

classificados e

documentados a

partir do início do

projeto e com o

apoio de uma lista

formal de riscos,

verificando

também os

requisitos que têm

uma prioridade

elevada no projeto.

Análise

Qualitativa de

Riscos

Prioriza os

riscos para

análise e define

as condições

para priorizar

seus efeitos nos

objetivos do

projeto.

Coberto como

acima. Oferece o

registro de riscos

para ajudar no

controle dos

riscos.

A análise de riscos

deve ser realizada

durante a Sprint

Planning 1 e

compreende etapas

para determinar: o

impacto, a

probabilidade e o

fator de exposição

do risco.Sugere-se

que os riscos sejam

priorizados. Após a

priorização, os riscos

considerados mais

urgentes devem ser

gerenciados e

mitigados na

próxima Sprint. Os

demais riscos ficam

“guardados” sendo

reavaliados na

próxima reunião de

Sprint Planning. A

priorização dos

riscos deve ocorrer

na reunião de Sprint

Planning 1,

auxiliando na

priorização e seleção

dos itens de backlog

que serão

desenvolvidos na

próxima Sprint.

É feita através de

uma análise

qualitativa de risco

usando julgamento,

intuição e experiência

na determinação de

riscos e perdas

potenciais. Nas

iterações dos

processos ágeis, ou

seja, durante os ciclos

curtos de

desenvolvimento e

revisões constantes,

isso se torna possível

e eficaz. Isso é

diferente de projetos

tradicionais, onde a

análise quantitativa é

feita e os números

são atribuídos aos

danos que podem

ocorrer.

É feita uma

classificação dos

riscos durante o

processo de

identificação dos

riscos.

Análise

Quantitativa

de Riscos

Mede a

probabilidade

de ocorrência e

as

conseqüências

dos riscos e

estima as suas

implicações nos

objetivos do

projeto.

Sugere

pontuação alta,

média e baixa.

Nenhuma técnica

de análise é

discutida.

O processo de

análise e avaliação

de risco avalia e

quantifica a

probabilidade e a

influência dos

eventos

considerados

causadores de

risco e a interação

entre os riscos.


DSDM Version 4.2.

77

Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil (Cont.)

ATIVIDADES

DA

GERÊNCIA

DE RISCO



Planejamento

de Resposta a

Riscos

Desenvolve

procedimentos

e técnicas para

aumentar as

oportunidades e

reduzir as

ameaças aos

objetivos do

projeto.

Discute o

balanço do

impacto do risco

de ocorrência

contra o impacto

da adoção das

medidas de risco

possível.

Abrange a cessão

de ações de risco

como parte da

gestão de riscos.

Planejamento de

medidas contra

riscos que inclui

ainda a medição

dos riscos e a

execução do plano

de resposta a eles.

Os planos de ação

correspondem às

ações que devem ser

tomadas para

responder aos riscos,

visando reduzir o

fator de exposição

(probabilidade e/ou

impactos).

A equipe inteira

participa no

desenvolvimento de

planos de respostas e

ações para reduzir as

ameaças.

Está preocupada

em planejar e

implementar

respostas aos

riscos

documentados.

Monitoração

e Controle de

Riscos

Implementa

planos de

respostas aos

riscos, monitora

riscos residuais,

identifica novos

riscos, executa

planos de

redução de

riscos e avalia

seus efeitos

através do ciclo

de vida de

projeto.

Coberto nas

etapas do

gerenciamento de

riscos,

planejamento,

recursos,

monitoramento e

controle.

Controla e

acompanha desde

a implementação

de identificação de

riscos à execução

de medidas

preventivas que

devem ser feitas

repetidamente.

Os riscos são

monitorados

diariamente, nas

reuniões diárias e

também durante os

planejamentos da

Sprint, quando

devem ser

reavaliados em

conjunto com os

demais riscos

identificados. É

importante observar

que para garantirmos

a agilidade, apenas

um subconjunto dos

riscos estaria sendo

monitorado a cada

Sprint. Este

subconjunto é

representado pelos

riscos que foram

priorizados e que

estão diretamente

relacionados com os

itens do Selected

Product Backlog.

Os riscos são

monitorados e as

estratégias de

controle são

discutidas no final de

cada iteração do ciclo

de vida (Figura 7). Os

riscos são

monitorados

diariamente através

das reuniões diárias.

É realizado um

acompanhamento

periódico da

implementação das

respostas aos

riscos e verificado

o status do risco

até o seu

encerramento pelo

responsável de

cada risco.

Comunicação

de Riscos

É tratada na

área de

conhecimento

de

gerenciamento

das

comunicações

do projeto.

Acontece em

paralelo às

demais

atividades e serve

para estabelecer

uma

comunicação

formal durante o

gerenciamento de

riscos do projeto.


DSDM Version 4.2.

78

2.3 Modelos de gestão de riscos em projetos de desenvolvimento de software

Existem diversos modelos que abordam a gestão de riscos em projetos de

desenvolvimento de software. Esses modelos já foram estudados por diversos autores e,

portanto não iremos repetir estudos exaustivos já realizados. O objetivo aqui é mostrar, doze

destes modelos e, como cada um deles aborda o gerenciamento de riscos através de uma

comparação entre os mesmos (Tabela 12).

Tabela 12: Modelos/Abordagem de gestão de riscos em projetos de desenvolvimento de

software

MODELO /

ABORDAGEM

AUTOR

SEI SEI (2004), Oliveira G. (2006)

MSF Microsoft Solutions Framework (2004), Oliveira G.

(2006)

BOEHM Boehm (1991), Oliveira G. (2006)

RISKIT Kontio (1996), Oliveira G. (2006)

ODYSSEY Braga (1999), Oliveira G. (2006)

A-RISK Machado (2002), Oliveira G. (2006)

GERIS Oliveira S. (2005), Oliveira G. (2006)

CMM Paulk (1993), Gusmão; Moura (2004)

CMMI SEI (2001), Gusmão; Moura (2004)

ISO 9000-3 NBR ISO 9001 (2000), Gusmão; Moura (2004)

ISO 12207 / ISO 15504 ISO/IEC 15504 (1999), NBR ISO 12207(1998),

Gusmão; Moura (2004)

Fonte: Oliveira (2006) e Gusmão; Moura (2004)

Será apresentado aqui o resultado de estudos realizados por estes autores através da

comparação entre os modelos citados tendo como referência as atividades/formato descritas

pelo PMI (2008). Verificou-se que existem diferenças entre as abordagens dos modelos em

relação à nomenclatura utilizada na descrição das atividades, em relação à subdivisão dessas

atividades em tarefas e na definição do escopo de algumas atividades (OLIVEIRA G., 2006).

Percebe-se, segundo Oliveira G. (2006), que a aplicação da gestão de riscos, possui

diversos formatos, e em grande parte da bibliografia pesquisada, verifica-se que existe um

79

eixo central, na qual estão incluídas as atividades de planejamento, identificação, análise

quantitativa e qualitativa, planejamento de resposta a riscos, monitoração e controle.

Será apresentado, a seguir, o comparativo dos modelos/abordagens de gestão de riscos

elaborados por Gusmão e Moura (2004) (Tabela 13) e Oliveira G. (2006) (Tabela 14 e 15).

Ressalta-se que os campos hachurados, nessas tabelas, indicam que a atividade não é

contemplada para o modelo de gestão de riscos para desenvolvimento de software em

questão.

Tabela 13: Comparativo das abordagens de Gerenciamento de riscos para

desenvolvimento de software por Gusmão e Moura (2004)

ATIVIDADES DA

GERÊNCIA DE

RISCO


CMM CMMI ISO 9000-3 ISO 12207 /

ISO 15504

Planejamento Não existe menção a

esta atividade.

Determinar as origens e

as categorias de riscos.

Definir parâmetros.

Estabelecer estratégia.

Planejar o

desenvolvimento do

projeto.

Definição do escopo da

gerência de risco.

Identificação de

Riscos

Identificação dos riscos. Identificar riscos. Identificar riscos. Identificar riscos.

Análise Qualitativa

de Riscos

Análise dos riscos com

a priorização dos

mesmos de acordo com

o impacto.

Priorizar, estimar e

classificar riscos.

Avaliar e classificar

cada risco.

Analisar problemas

potenciais.

Analisar e priorizar riscos.

Análise

Quantitativa de

Riscos

Planejamento de

Resposta a Riscos

Definição dos planos de

contingências para os

riscos identificados que

não tenham condições

de serem eliminados.

Desenvolver planos

para reduzir riscos.

Definir planos de

contingência.

Definir a estratégia para a

gerência de risco.

Monitoração e

Controle de Riscos

Implementar planos

para reduzir riscos.

Verificar a execução

dos procedimentos do

plano de

desenvolvimento do

projeto. Controlar a

execução do projeto.

Definir métricas para riscos.

Implementar a estratégia da

gerência de risco. Avaliar os

resultados da estratégia da

gerência de risco. Executar

ações corretivas.

Comunicação de

Riscos

Comunicação implícita. Comunicação implícita. Comunicação implícita. Comunicação implícita.

Aprendizagem de

Riscos

80


desenvolvimento de software por Oliveira G. (2006)

ATIVIDADES DA

GERÊNCIA DE

RISCO


SEI MSF BOEHM

Planejamento Identifica, analisa e planeja resposta a riscos.

Identificação de

Riscos

Localiza riscos antes que eles se tornem problemas.

Identifica riscos que possam afetar o projeto ou limitar seu sucesso.

Identifica riscos de acordo com a sua classificação.

Análise Qualitativa de Riscos

Classifica riscos através de categorias e parâmetros definidos.

Determina prioridades para a

ação, gerando uma ordem na lista mestre de riscos.

Analisa riscos com utilização de

intervalos de prioridade.

Análise Quantitativa de Riscos

Analisa a probabilidade de ocorrência de cada risco e suas implicações para os objetivos do projeto.

Planejamento de Resposta a Riscos

Converte as informações de risco

para decisões e ações.

Traduz a lista de prioridade de

riscos em planos de ação.

Define objetivo, ações, cronograma, responsabilidades, como as ações devem ser desenvolvidas e recursos alocados.

Monitoração e

Controle de Riscos

Monitora estado de riscos para tomar devidas ações e corrige desvios das ações de risco.

Monitora métricas de risco e executa as atividades relacionadas aos planos de contingência.

Utiliza plano de riscos e realiza uma adequação do mesmo em função de novas percepções.

Comunicação de Riscos

Fornece um feedback das atividades de risco ativas.

Aprendizagem de Riscos

Aprende as lições obtidas.


desenvolvimento de software por Oliveira G. (2006)

ATIVIDADES DA

GERÊNCIA DE

RISCO


RISKIT ODYSSEY A-RISK GERIS

Planejamento Revisar e definir os

objetivos, expectativas e diretrizes.

Determinar o método

para a identificação e

cálculo de riscos e os

impactos para os fatores

de risco. Definir quando

o processo A-Risk

deverá ser utilizado.

Definir qual processo será adotado para a GRPS (padrão ou normal). Projetos de pequeno porte podem adotar um processo padrão composto apenas pelas etapas de identificação, análise e monitoração de riscos.

81


desenvolvimento de software por Oliveira G. (2006) (Cont.)

ATIVIDADES DA

GERÊNCIA DE

RISCO


RISKIT ODYSSEY A-RISK GERIS

Identificação de

Riscos

Identificar riscos

potenciais do projeto.

Identificar os riscos mais

comuns que ocorrem nos projetos desenvolvidos.

Identificar os riscos, através da influência dos fatores de risco. Para cada fator de influência “razoável ou muita”.

Utilizar informações históricas de projetos anteriores para facilitar a identificação de riscos e gerar checklist.

Análise Qualitativa de Riscos

Priorizar e quantificar os riscos através de um formalismo gráfico. Agrupar riscos similares, que geram o mesmo evento, através do uso de cenários.

Documentar padrões de risco a fim de conduzir a informação para a identificação qualitativa de risco e para as estratégias da resolução do impacto.

Analisar e priorizar riscos identificados perante a probabilidade de ocorrerem e o impacto que exercem sobre o processo de desenvolvimento de software, conforme (PMI, 2000).

Análise Quantitativa de Riscos

Utilizar modelos dinâmicos agregados do processo de desenvolvimento, permitindo que o gerente de projeto avalie quantitativamente os riscos identificados. Agrupar riscos similares através do uso de um padrão de risco.

Analisar os riscos

através de um conjunto

de fatores de riscos

relacionado ao tempo

em que eles são

identificados. Agrupar

todos os fatores de risco

que possuem o mesmo

grau de influência ou

peso dentro de um único

cenário.

Planejamento de Resposta a Riscos

Desenvolver um plano de ações selecionadas.

Descrever textualmente o plano de contenção e seus efeitos, pelas condições de sua aplicação, e por um modelo dinâmico de seu impacto.

Desenvolver um conjunto de ações necessárias para minimizar as conseqüências do risco.

Monitoração e Controle de Riscos

Controlar riscos com o objetivo de avaliar os resultados esperados.

Monitorar a evolução do projeto após a execução do plano de contenção.

Manter a rastreabilidade dos riscos identificados e priorizados, monitorar riscos residuais e identificar novos riscos.

Comunicação de Riscos

Comunicar o status dos riscos às pessoas interessadas, identificadas na etapa de planejamento.

Aprendizagem de Riscos

Realizar a atividade de aprendizagem através do uso do formalismo gráfico de riscos.

Permitir a reutilização de riscos identificados em processos de gerência de risco para projetos específicos de software.

Gerar base de conhecimento a respeito do projeto, permitindo um reuso por outros projetos.

82

Cada abordagem de gerência de risco apresentada (Tabela 13, Tabela 14 e Tabela 15)

possui suas particularidades. Das oito atividades analisadas nestas tabelas para as doze

abordagens de gerência de riscos, a atividade de identificação de riscos, objeto deste trabalho,

foi a única que apareceu em todas elas.

Na atividade de planejamento de riscos, das doze abordagens apresentadas, oito fazem

menção a esta atividade (CMMI, ISO 9000-3, ISO 12207/ISO 12504, SEI, PMI, RISKIT, A-

RISK e GERIS), porém ela não está presente nas abordagens do CMM, MSF, BOEHM e

ODYSSEY. Segundo Oliveira G. (2006) as abordagens adotadas por BOEHM são

consequências da época em que foram definidas, final da década de 80, quando não era

evidenciada a importância da adaptação de processos na engenharia de software. Já o MSF

tem conceitos pré-definidos e institucionalizados, e, portanto, não existe a adaptação do

processo de gerência de riscos. As normas ISO 12207 e ISO 15504 definem esta atividade,

mas não determinam o método a ser utilizado na execução da mesma.

Conforme já mencionado a atividade de identificação de riscos aparece em todas as

doze abordagens apresentadas.

A atividade de análise quantitativa e/ou qualitativa de riscos é tratada, de forma geral,

porém é realizada de forma diferente pelas diferentes abordagens apresentadas. Dependendo

da abordagem estas análises são realizadas separadamente ou em conjunto. Metade delas faz a

análise qualitativa separada da análise quantitativa (PMI, BOEHM, RISKIT, ODYSSEY, A-

RISK e GERIS) e a outra metade faz as duas análises em conjunto (CMM, CMMI, ISO 9000-

3, ISO 12207 / ISO 15504, SEI e MSF). A abordagem A-Risk não faz menção à atividade de

análise qualitativa de riscos e às abordagens RISKIT e GERIS não fazem menção à atividade

de análise quantitativa de riscos. Já BOEHM, MSF, ISSO 1207 / ISO 15504 enfatizam a

importância de priorizar os riscos (OLIVEIRA, G., 2006; GUSMÃO e MOURA, 2004).

Na atividade de planejamento de respostas a riscos, somente a abordagem A-RISK, não

faz menção a esta atividade, porém, ela aparece nas demais abordagens com variações de

nomenclatura. Depois da atividade de identificação de riscos, a atividade de planejamento de

respostas a riscos é a mais importante, pois é a partir dela que os planos de ação e

contingência são traçados.

Quanto à atividade de monitoração e controle de riscos, as abordagens CMM e A-RISK

não fazem menção a esta atividade. As demais abordagens a tratam com nível de

detalhamento diferenciado. Segundo Gusmão e Moura (2004) esta é a atividade que mais se

diferencia entre as abordagens, como por exemplo: o PMI e BOEHM deixam implícitas a

necessidade de ações corretivas (como replanejamento) e as normas ISO 12207 / ISO 15504 e

83

MSF deixam explícitas essas questões. As normas ISO 12207 / ISO 15504 adotam uma

abordagem de melhoria contínua no seu processo de gerência de risco, permitindo que a

organização promova correção tanto do seu processo de gerência de riscos como do projeto.

Com relação à atividade de comunicação de riscos somente as abordagens SEI e GERIS

tratam esta atividade de forma explícita. Quando a estrutura de comunicação é falha, riscos,

problemas e crises podem aparecer durante o projeto. O fato da atividade de comunicação não

estar explícita nas demais abordagens (CMM, CMMI, ISO 9000-3, ISO 12207 / ISO 15504,

PMI, MSF, BOEHM, RISKIT, ODYSSEY e A-RISK), não que dizer que ela não seja

realizada, porque esta atividade está implícita em todo o projeto, independente da abordagem

ou modelo utilizado (GUSMÃO; MOURA, 2004).

A atividade aprendizagem de riscos é utilizada de forma explícita pelas abordagens

MSF, RISKIT, ODYSSEY e GERIS. Oliveira G. (2006) faz um destaque no caso da

abordagem do MSF:

“No caso da abordagem do MSF existe ainda uma etapa descrita como

“aprendizagem de risco”. Esta etapa está focada no fornecimento da garantia de

qualidade nas atividades atuais da gerência de risco de modo que a equipe possa

receber um feedback regular, na aprendizagem das lições obtidas, especialmente

com relação à identificação de riscos e das estratégias bem sucedidas de mitigação,

para o benefício de outras equipes; isto contribuirá à base de conhecimento de risco,

e na melhoria do processo da gerência de risco obtendo um feedback da equipe.”

(OLIVEIRA G., 2006).

2.4 Métodos para identificação de riscos

Existem diversos métodos para identificação de riscos em projetos, dentre eles serão

apresentados aqui os seguintes: taxonomia de riscos, lista de verificação (check-list), fatores

de risco, brainstorming, análise de informações históricas, comparação análoga, análise de

premissas, entrevista com especialistas, análise da causa-raiz e técnica Delphi.

PMI (2008) apresenta alguns destes métodos, como por exemplo: listas de verificação

(checklist), comparação análoga, análise de premissas, decomposição, técnicas de

diagramação, técnica Delphi, avaliação de documentação (plano e modelo de projeto) e

fatores de riscos.

PMAJ (2005) também apresenta alguns destes métodos, como por exemplo: lista de

verificação (checklist), método dos 6W1H (Who, Why, What, Whichway, Wherewithal, When

84

and How) incluído no método de análise de causa-raiz, brainstorming, entrevista com

especialistas e técnica Delphi.

Na etapa de identificação de riscos é onde são levantados, identificados e descritos quais

os eventos que podem causar um impacto tanto negativo como positivo no projeto. Essa etapa

deve contar com a participação de todos os envolvidos no projeto (MULCAHY, 2010).

“A documentação do risco deve obedecer a uma formatação padronizada,

adequada a cada projeto, contendo dois elementos básicos: o núcleo e o contexto

(ROSENBERG et al., 1999). O núcleo da identificação segue o formato “dado um

<evento> há possibilidade de uma <conseqüência> ocorrer”, onde o <evento>

significa um acontecimento incerto que, ocorrendo, irá provocar a <conseqüência>,

causando perda ou prejuízo ao projeto. O <evento> deve prover informações úteis

para o tratamento do risco. A <conseqüência> deve focalizar os impactos, uma vez

que a profundidade e a amplitude do impacto são úteis para a estimativa de tempo,

recursos e esforços que devem ser alocados para tratar o risco. Um <evento> pode

trazer mais de uma <conseqüência>. O contexto traz informações adicionais sobre o

risco, visando garantir o entendimento por parte de outras pessoas, principalmente

após certo tempo de sua identificação. Ele deve descrever circunstâncias, fatores de

contribuição e assuntos relacionados ao risco, normalmente secundários, e que não

estão documentados no núcleo (ROSENBERG et al., 1999; PATTERSON e

NEAILEY, 2002). A identificação de riscos é contínua, acompanhando todo o ciclo

de vida do projeto, visto que novos riscos podem surgir em virtude de mudanças no

ambiente onde o projeto se desenvolve.” (JUNIOR, CHAMON e CAMARINI,

2006)

Koscho e Ries (2009) apresentam um modelo de gestão de risco que considera que os

riscos podem tomar a forma de qualquer evento potencialmente negativo que possa ocorrer no

projeto, e podem ser identificados em qualquer ponto do ciclo de vida do mesmo.

Como mostrado na Figura 15, as partes envolvidas têm preocupações e uma delas é um

risco em potencial, portanto, um risco candidato. Algumas preocupações podem tornar-se

riscos e outras não. Estes são articulados em cenários atributos de qualidade, restrições ou

requisitos/exigências sendo que um subconjunto desses riscos é atenuado com uma variedade

de técnicas.

85

Figura 15: Identificação de Riscos. Fonte: KOSCHO; RIES (2009, p.2)

O SEI - Software Engineering Institute (CARR et al., 1993) propõe um processo de

identificação de riscos (Figura 16), onde se estabelece primeiro o compromisso da

administração com a definição do coordenador do processo; depois são feitos a seleção e o

treinamento da equipe, que consiste em uma série de entrevistas e reuniões para levantamento

de riscos e clarificação de questões relacionadas aos mesmos e por fim a elaboração de uma

lista de riscos.

Figura 16: Processo de Identificação de Riscos. Fonte: CARR et al. (1993, p.13)

2.4.1 Taxonomia de Riscos

Em seu trabalho “Riscos para Manutenção de Software: Taxonomia e Priorização”

Webster (2005) considera a taxonomia de riscos a ferramenta de identificação de riscos mais

86

citada pelas referências por ela pesquisadas. Das 18 referências investigadas 11 delas a

citaram.

A utilização da ferramenta de taxonomia de risco conforme Houston et al. (2001 apud

Webster, 2005), apresenta vantagem com relação às demais, pois sua utilização torna o

processo de identificação mais rápido e simples

Taxonomia de riscos para Sommerville (2003 apud MACHADO, 2002) é uma

categorização dos tipos possíveis de risco já o SEI (Software Engineering Institute) sugere

classificar os riscos em classes que por sua vez são divididas em elementos e cada elemento

caracterizado por seus atributos, conforme apresentado na Tabela 16 (CARR et al.,1993;

MACHADO, 2002).

Na taxonomia sugerida pelo SEI podem acontecer casos de alguns de seus atributos não

serem aplicáveis a um determinado sistema, podendo ser adaptável às necessidades

específicas de um determinado sistema, por se tratar de uma ferramenta genérica.

Tabela 16: Taxonomia de riscos em desenvolvimento de software do SEI.

CLASSE ENGENHARIA DE PRODUTO11

AMBIENTE DE

DESENVOLVIMENTO12

RESTRIÇÕES DE

PROGRAMA13

Elemento I. Requisitos I. Processo de desenvolvimento I. Recursos

Atributo a. Estabilidade

b. Completeza

c. Clareza

d. Validade

e. Viabilidade

f. Precedente

g. Escala

a. Formalidade

b. Adequação

c. Controle do processo

d. Familiaridade

e. Controle do produto

a. Cronograma

b. Equipe

c. Orçamento

d. Facilidade

Elemento II. Projeto II. Desenvolvimento de sistema II. Contrato

Atributo a. Funcionalidade

b. Dificuldade

c. Interface

d. Desempenho

e. Testabilidade

f. Restrições de hardware

g. Software não desenvolvido

a. Capacidade

b. Adequação

c. Usabilidade

d. Familiaridade

e. Confiabilidade

f. Suporte ao sistema

g. Entregabilidade

a. Tipo de Contrato

b. Restrições

c. Dependências

Fonte: adaptado de CARR et al. (1993); MACHADO (2002, p.46)

11

Engenharia do produto (CARR et al.,1993): compreende os fatores técnicos relacionados ao produto, ou seja,

poderíamos chamar de riscos técnicos.

12 Ambiente de desenvolvimento (CARR et al.,1993): compreende o processo de desenvolvimento de sistemas,

métodos de gestão e ambiente de trabalho, ou seja, poderíamos chamar de riscos metodológicos, por se tratar dos

métodos relacionados ao ambiente de desenvolvimento de sistemas. 13

Restrições de programa (CARR et al.,1993): compreende os fatores contratuais, organizacionais e operacionais

no qual o software é desenvolvido, ou seja, poderíamos chamar de riscos organizacionais.

87

Tabela 16: Taxonomia de riscos em desenvolvimento de software do SEI (Cont.)

CLASSE ENGENHARIA DE PRODUTO14

AMBIENTE DE

DESENVOLVIMENTO15

RESTRIÇÕES DE

PROGRAMA16

Elemento III. Codificação e Teste Unitário III. Processo de Gerência III. Interfaces de Projeto

Atributo a. Viabilidade

b. Teste Unitário

c. Codificação e

Implementação

a. Planejamento

b. Organização do Projeto

c. Experiência Gerencial

d. Interface de Projeto

a. Cliente

b. Contratos Associados

c. Subcontratados

d. Principal Contratador

e. Gerente Corporativo

f. Vendedores

g. Políticos

Elemento IV. Teste e Integração IV. Métodos Gerenciais

Atributo a. Ambiente

b. Produto

c. Sistema

a. Monitoramento

b. Gerência de Pessoal

c. Garantia da Qualidade

d. Gerência de Configuração

Elemento V. Especialidade de Engenharia V. Ambiente de Trabalho

a. Manutenibilidade

b. Confiabilidade

c. Segurança

d. Proteção

e. Fatores Humanos

f. Especificações

a. Atitude para a qualidade

b. Cooperação

c. Comunicação

d. Moral

Fonte: adaptado de CARR et al. (1993); MACHADO (2002, p.46)

2.4.2 Lista de Verificação / Check-list

Uma lista de verificação é uma ferramenta estruturada, geralmente específica do

componente, usada para verificar se um conjunto de etapas necessárias foi executado (PMI,

2008).

As listas de verificação podem ser criadas pela equipe do projeto para identificar os

riscos associados ao projeto e para servir como uma ferramenta de auxílio no gerenciamento

dos riscos que poderá contribuir para o atingimento do objetivo almejado.

Muitas organizações, de acordo com PMI (2008), têm listas de verificação padronizadas

disponíveis para garantir a consistência em tarefas realizadas com frequência. Em algumas

áreas de aplicação, também existem listas de verificação disponibilizadas por associações de

profissionais ou fornecedores de serviços comerciais. É possível desenvolver listas de

14

Engenharia do produto (CARR et al.,1993): compreende os fatores técnicos relacionados ao produto, ou seja,

poderíamos chamar de riscos técnicos.

15 Ambiente de desenvolvimento (CARR et al.,1993): compreende o processo de desenvolvimento de sistemas,

métodos de gestão e ambiente de trabalho, ou seja, poderíamos chamar de riscos metodológicos, por se tratar dos

métodos relacionados ao ambiente de desenvolvimento de sistemas. 16

Restrições de programa (CARR et al.,1993): compreende os fatores contratuais, organizacionais e operacionais

no qual o software é desenvolvido, ou seja, poderíamos chamar de riscos organizacionais.

88

verificação para identificação de riscos com base nas informações históricas e no

conhecimento que foi acumulado a partir de projetos anteriores semelhantes e outras fontes de

informações.

Embora em alguns casos ou projetos seja possível elaborar uma lista de verificação de

forma rápida e simples, é quase impossível criar uma lista completa de todos os riscos que

envolvem um projeto.

A equipe deve se certificar de explorar os itens que não aparecem na lista de

verificação. Essa lista deve ser revisada durante o encerramento do projeto para incorporar as

novas lições aprendidas e ser aprimorada para uso em projetos futuros (PMI, 2008).

Segundo Webster (2005), em sua dissertação sobre “Riscos para manutenção de

software: taxonomia e priorização”, a utilização da ferramenta lista de verificação para a

identificação de riscos foi citada por oito das dezesseis referências pesquisadas, logo, essa

ferramenta foi a segunda mais citada nessa pesquisa.

“No que se refere à utilização da ferramenta lista de verificação, ela apresenta uma

vantagem com relação às demais, pois, sua aplicação torna o processo de

identificação mais rápido e simples (PMI, 2002; e JALOTE, 2000, 2002). Uma

desvantagem é que os usuários podem ficar limitados às fontes de riscos definidas

(PMI, 2002 e HOUSTON et al., 2001)” (WEBSTER, 2005).

Mulcahy (2010) desenvolveu um estudo de risco internacional com a contribuição de

mais de 141 profissionais e companhias. Com o resultado dessa pesquisa, propôs uma lista de

riscos para 12 áreas diferentes de gerenciamento de projetos. Segue, abaixo, a lista de riscos

para a área de sistemas de informação, objeto de estudo do presente trabalho.

Essa lista de verificação, segundo a autora, deve ser usada para auxiliar na identificação

dos riscos do projeto e para cada atividade usada nos processos de gerência do projeto,

devendo contar com ajuda de toda a equipe. O objetivo da lista de riscos é auxiliar o gerente

do projeto na identificação e resolução dos riscos mais acentuados.

Mulcahy (2010) classificou sua lista de riscos, para sistemas de informação, em 10

categorias (contrato, cliente, internacional, gerenciamento de projeto, qualidade, recursos,

escopo, segurança, riscos com fornecedor e tecnologia), conforme Tabela 17. Na primeira

coluna temos a identificação do fator de riscos, exemplo 1-01, onde o primeiro número “1”

representa o autor do fator de risco, ou seja, “Mulcahy (2010) e o segundo número “01”

representa o número do fator de risco. A segunda coluna contém a causa do risco, exemplo:

“Fornecedor selecionado fará o tempo de trabalho/materiais X a oferta fixa usual”. A terceira

coluna apresenta o nome do risco, exemplo: “Portanto, temos a falta de experiência em

89

registros precisos para este tipo de contrato” e a quarta coluna descreve o efeito do risco.

Exemplo: “Isso pode levar a custos sendo cobrados incorretamente”.

A tabela contendo a lista completa de riscos para sistemas de informação, segundo

Mulcahy (2010) encontra-se no Apêndice II.

Tabela 17: Modelo da Lista de riscos para sistemas de informação

ID17

CAUSA RISCO EFEITO

Contrato

Contém a lista de riscos relacionados a contratos, veja exemplo 1-01.

1-01 Fornecedor selecionado fará o tempo

de trabalho/materiais X a oferta fixa

usual.

Portanto, temos a falta de

experiência em registros precisos

para este tipo de contrato.

Isso pode levar a custos sendo

cobrados incorretamente.

Cliente

Contém a lista de riscos relacionados a cliente.

Internacional

Contém a lista de riscos relacionados ao ambiente internacional.

Gerenciamento do Projeto

Contém a lista de riscos relacionados ao gerenciamento do projeto.

Qualidade

Contém a lista de riscos relacionados à qualidade do projeto.

Recursos

Contém a lista de riscos relacionados aos recursos envolvidos no projeto.

Escopo

Contém a lista de riscos relacionados ao escopo do projeto.

Segurança

Contém a lista de riscos relacionados à segurança do projeto.

Riscos com Fornecedor

Contém a lista de riscos relacionados aos fornecedores do projeto.

Tecnologia

Contém a lista de riscos relacionados à tecnologia envolvida no projeto.

Fonte: Mulcahy (2010, p.389)

17

ID – Identificador do risco. O identificador do risco será utilizado durante a dissertação para representar as

referências bibliográficas de cada fator de risco.

90

2.4.3 Fatores de risco

Os fatores de riscos aqui apresentados são o resultado do estudo realizado por Webster

(2005) onde ela propôs uma lista deles a partir de pesquisa realizada com vários autores.

A integração dos fatores de riscos desses diversos autores foi baseada em uma análise

de semelhança semântica.

Segue abaixo (Tabela 18) a relação dos fatores de riscos de desenvolvimento de

software integrados (WEBSTER, 2005). Na primeira coluna temos a identificação. Exemplo:

2-03, onde o primeiro numeral “2” representa o autor que integrou o fator de risco, ou seja,

“Webster (2005) e o segundo numeral “03” representa a ordem do fator de risco. A segunda

coluna contém o nome do fator de risco integrado e a terceira coluna, os autores que citaram o

referido fator.

Tabela 18: Fatores de risco de desenvolvimento de software integrados

ID FATOR DE RISCO INTEGRADO AUTORES

2-01 Requisitos instáveis (BOEHM, 1991); (KWAK; STODDARD, 2003);

(ADLER et al., 1998); (SOEIRO, 1999); (HOUSTON et

al., 2001); (MACHADO, 2002); (ADDISON;

VALLABH, 2002); (SOMERVILLE, 2003, p.74);

(MCMANUS, 2004, p.18-19); (DEMARCO; LISTER,

2003); (CARR et al., 1993); (JALOTE 2000, p.167-169);

(PRESSMAN, 2002, p.139-156); (FONTOURA; PRICE,

2004); (LEOPOLDINO, 2004); (FARIAS, 2002)

2-02 Requisitos incompletos. (KEIL et al., 1998); (CARR et al., 1993)

2-03 Requisitos não claros (ambíguos / imprecisos). (MACHADO, 2002); (MIZUNO; KIKUNO, 2000);

(CARR et al., 1993); (JALOTE 2000, p.167-169)

2-04 Requisitos mal entendidos (não refletem as

expectativas do cliente).

(KEIL et al., 1998); (MACHADO, 2002); (ADDISON;

VALLABH, 2002); (MIZUNO; KIKUNO, 2000);

(CARR et al., 1993); (FONTOURA; PRICE, 2004)

2-05 Adição de mais funcionalidades que o

especificado / dar extras ao cliente.

(BOEHM, 1991); (KWAK; STODDARD, 2003);

(ADLER et al., 1998); (ADDISON; VALLABH, 2002);

(MCMANUS, 2004, p.18-19); (FONTOURA; PRICE,

2004)

2-06 Requisitos de desempenho não atendidos.

Ex. Baixo desempenho.

(SOEIRO, 1999); (DEMARCO; LISTER, 2003);

(JALOTE 2000, p.167-169)

2-07 Alto nível de complexibilidade técnica. (HOUSTON et al., 2001); (MACHADO, 2002); (CARR

et al., 1993)

2-08 Desenvolvimento de interface do usuário

inadequada.


(ADLER et al., 1998); (SOEIRO, 1999); (MCMANUS,

2004, p.18-19)

Fonte: Webster (2005, p. 118).

91

Tabela 18: Fatores de risco de desenvolvimento de software integrados (Cont.)


2-09 Problemas de desempenho de tempo real (há

tempos de respostas restritos).


(ADLER et al., 1998); (MCMANUS, 2004, p.18-19);

(CARR et al., 1993)

2-10 Restrições referentes ao hardware designado.

Ex.: capacidade de memória e tempo de

resposta real, acesso à base de dados e

insuficiência de hardware.


(ADLER et al., 1998); (MCMANUS, 2004, p.18-19);

(CARR et al., 1993)

2-11 Tecnologia nova / imatura (uso de novas

tecnologias).

(SOEIRO, 1999); (KEIL et al., 1998); (MACHADO,

2002); (ADDISON; VALLABH, 2002); (JALOTE 2000,

p.167-169); (FONTOURA; PRICE, 2004);

(LEOPOLDINO, 2004)

2-12 Inadequada preparação e realização dos testes.

Ex.: instalações inadequadas, e tempo

insuficiente para realização dos testes, falta de

dados precisos para testar as mudanças e

utilização de método de teste inadequado.

(MCMANUS, 2004, p.18-19); (CARR et al., 1993)

2-13 Falta de um acordo interativo entre os clientes

e os desenvolvedores relativo às especificações

dos requisitos.

(MIZUNO; KIKUNO, 2000); (CARR et al., 1993)

2-14 Inadequadas especificações. Ex.:

especificações de sistema, hardware, software,

interface, requisitos de teste a qualquer nível

com respeito à viabilidade de implementação e

à estabilidade dos atributos de qualidade,

completude e clareza.

(MIZUNO; KIKUNO, 2000); (DEMARCO; LISTER,

2003); (CARR et al., 1993);

(FARIAS, 2002)

2-15 Modelos, processos, métodos e ferramentas de

apoio selecionados inadequados para o

processo de desenvolvimento.

(MACHADO, 2002); (CARR et al., 1993)

2-16 Falta / insuficiência de controle do processo de

desenvolvimento. Ex.: uso do recurso, medição

do progresso referente à qualidade e metas de

produtividade.

(MIZUNO; KIKUNO, 2000); (CARR et al., 1993);

(LEOPOLDINO, 2004)

2-17 Controle do produto inadequado. Ex.: o

produto final não corresponde às expectativas

do cliente.

(CARR et al., 1993); (FARIAS, 2002)

2-18 Documentação / papelada excessiva. (SOEIRO, 1999); (HOUSTON et al., 2001)

2-19 Capacidade insuficiente do sistema

desenvolvido. Ex.: Falta de estações de

trabalho, espaço de armazenamento no banco

de dados insuficiente.

(SOMERVILLE, 2003, p.74); (CARR et al., 1993)

2-20 Pouca confiança no desenvolvimento do

sistema devido à indisponibilidade / erro / mal

funcionamento dos componentes.


(ADLER et al., 1998); (HOUSTON et al., 2001);

(MCMANUS, 2004, p.18-19); (CARR et al., 1993)

2-21 Pobre suporte ao sistema. Ex.: treinamento

para utilização do sistema, acesso para

usuários especialistas ou consultores, conserto

ou resolução de problemas por parte dos

vendedores.



92



2-22 Planejamento inapropriado, incluindo

construção e atualização do plano de

contingência.

(SOEIRO, 1999); (MACHADO, 2002); (MIZUNO;

KIKUNO, 2000); (SCHWALBE, 2002, p.311); (CARR

et al., 1993)

2-23 Papéis e responsabilidades de relacionamentos

mal definidos ou mal entendidos.

(MIZUNO; KIKUNO, 2000); (SCHWALBE, 2002,

p.311); (CARR et al., 1993)

2-24 Gerentes do desenvolvimento do software

inexperientes ou ineficientes.

(MACHADO, 2002); (CARR et al., 1993);

(LEOPOLDINO, 2004)

2-25 Fraca interação (comunicação) do gerente com

todos os envolvidos do projeto.


2-26 Falhas em gerenciar as expectativas do usuário

final.

(KEIL et al., 1998); (ADDISON; VALLABH, 2002);

(LEOPOLDINO, 2004)

2-27 Ausência de um líder. (MACHADO, 2002); (SCHWALBE, 2002, p.311)

2-28 Falta de metodologia efetiva de gerenciamento

de projetos.

(MACHADO, 2002); (ADDISON; VALLABH, 2002);

(FONTOURA; PRICE, 2004); (LEOPOLDINO, 2004)

2-29 Fraco monitoramento do progresso das

atividades relacionadas ao projeto. Ex.:

acompanhamento do relatório de status e

manutenção de métricas progressivas.

(MACHADO, 2002); (MIZUNO; KIKUNO, 2000);

(CARR et al., 1993)

2-30 Treinamento inadequado ou indisponível. (SOEIRO, 1999); (MACHADO, 2002); (SOMERVILLE,

2003, p.74); (CARR et al., 1993); (PRESSMAN, 2002,

p.139-156)

2-31 Falta de procedimentos, programas adequados

e recursos para assegurar a garantia da

qualidade.

(SCHWALBE, 2002, p.311); (CARR et al., 1993)

2-32 Gerência de Configuração inadequada. (SOEIRO, 1999); (HOUSTON et al., 2001);


2-33 Mudanças contínuas no objetivo e escopo do

projeto.

(KEIL et al., 1998); (MACHADO, 2002);

(LEOPOLDINO, 2004)

2-34 Erro ao estimar (tempo, custo e esforço). (SOEIRO, 1999); (HOUSTON et al., 2001); (MIZUNO;

KIKUNO, 2000); (SOMERVILLE, 2003, p.74);

(SCHWALBE, 2002, p.311); (PRESSMAN, 2002, p.139-

156); (LEOPOLDINO, 2004)

2-35 Métricas inadequadas / inexatas. (SOEIRO, 1999); (HOUSTON et al., 2001)

2-36 Falta espírito de equipe. Os conflitos requerem

intervenção da gerência.

(MACHADO, 2002); (CARR et al., 1993); (JALOTE

2000, p.167-169); (FARIAS, 2002)

2-37 Pobre comunicação devido à falta de

conhecimento da missão, metas do projeto e

informações técnicas entre pares e gerentes.

(MACHADO, 2002); (MCMANUS, 2004, p.18-19);

(CARR et al., 1993)

2-38 Baixa moral/ falta de compromisso devido ao

baixo nível de entusiasmo afetando assim a

produtividade e criatividade. As pessoas não se

sentem reconhecidas e recompensadas pelos

superiores.

(HOUSTON et al., 2001); (MACHADO, 2002);

(MIZUNO; KIKUNO, 2000); (CARR et al., 1993);

(LEOPOLDINO, 2004); (FARIAS, 2002)

2-39 Falta de maturidade / instabilidade

organizacional.

(HOUSTON et al., 2001); (MACHADO, 2002)

2-40 Baixa produtividade da equipe. (HOUSTON et al., 2001); (MACHADO, 2002);

(SCHWALBE, 2002, p.311); (FARIAS, 2002)


93



2-41 Cronograma irreal ou inadequado baseado nos

eventos internos e externos do sistema.


(ADLER et al., 1998); (SOEIRO, 1999); (MACHADO,

2002); (ADDISON; VALLABH, 2002); (MCMANUS,

2004, p.18-19); (DEMARCO; LISTER, 2003); (CARR et

al., 1993); (JALOTE 2000, p.167-169); (PRESSMAN,

2002, p.139-156); (FONTOURA; PRICE, 2004);

(FARIAS, 2002)

2-42 Pressão excessiva de prazo. (HOUSTON et al., 2001); (MACHADO, 2002)

2-43 Problemas de pessoal. Ex.: falta experiência,

pouco conhecimento, falta de habilidade, falta

de pessoal e indisponibilidade de pessoas

chaves.


(ADLER et al., 1998); (HOUSTON et al., 2001); (KEIL

et al., 1998); (MACHADO, 2002); (ADDISON;

VALLABH, 2002); (MIZUNO; KIKUNO, 2000);

(SOMERVILLE, 2003, p.74); (MCMANUS, 2004, p.18-

19); (CARR et al., 1993); (JALOTE 2000, p.167-169);

(PRESSMAN, 2002, p.139-156); (FONTOURA; PRICE,

2004); (LEOPOLDINO, 2004)

2-44 Orçamento insuficiente ou instável baseado

nos eventos internos e externos do sistema.


(ADLER et al., 1998); (SOEIRO, 1999); (MACHADO,

2002); (ADDISON; VALLABH, 2002); (MCMANUS,

2004, p.18-19); (CARR et al., 1993); (FONTOURA;

PRICE, 2004); (FARIAS, 2002)

2-45 Instabilidade (rotatividade) e falta de

continuidade das pessoas nos projetos.


(DEMARCO; LISTER, 2003); (PRESSMAN, 2002,

p.139-156); (LEOPOLDINO, 2004); (FARIAS, 2002)

2-46 Qualquer problema com o cliente, tais como:

demora na aprovação de documentos,

comunicação pobre, resistência à mudança,

falta de comprometimento, falta de

cooperação, conflitos entre clientes e

departamentos.


(SOMERVILLE, 2003, p.74); (CARR et al., 1993);

(LEOPOLDINO, 2004); (FARIAS, 2002)

2-47 Problemas relacionados aos contratos

associados.

(SOEIRO, 1999); (SCHWALBE, 2002, p.311); (CARR

et al., 1993)

2-48 Qualquer problema associado a

subcontratação.

(SOEIRO, 1999); (ADDISON; VALLABH, 2002);

(CARR et al., 1993); (FONTOURA; PRICE, 2004)

2-49 Fatores políticos (companhia, clientes,

contratantes associados e subcontratantes) que

causam problemas para o desenvolvimento do

projeto.

(MACHADO, 2002); (CARR et al., 1993); (JALOTE

2000, p.167-169); (FARIAS, 2002)

2-50 Qualquer problema com o usuário, tais como:

falta de envolvimento / comprometimento,

conflito entre usuários e departamentos, falta

de entendimento com relação ao

funcionamento do sistema, resistência a

mudanças e falha em obter o

comprometimento do usuário.

(SOEIRO, 1999); (KEIL et al., 1998); (ADDISON;

VALLABH, 2002); (PRESSMAN, 2002, p.139-156);


2-51 Falta de comprometimento da gerência sênior (KEIL et al., 1998); (HOUSTON et al., 2001);

(ADDISON; VALLABH, 2002); (CARR et al., 1993);



94

2.4.4 Brainstorming

Muitas atividades em grupo podem ser organizadas para identificar os riscos do projeto..

O brainstorming é uma técnica usada para gerar e coletar múltiplas idéias, neste contexto. O

objetivo do brainstorming é obter uma lista dos riscos do projeto. A equipe do projeto

normalmente realiza um brainstorming, em geral com um conjunto multidisciplinar de

especialistas externos à equipe. As idéias sobre o risco do projeto são geradas sob a liderança

de um facilitador, seja em uma sessão tradicional de brainstorming, de forma livre (com

idéias fornecidas pelos participantes), ou estruturada (usando técnicas de entrevista em grupo,

como a técnica de grupos nominais). Os riscos são, então, identificados e categorizados e suas

definições detalhadas. (PMI, 2008).

Segundo Webster (2005) a ferramenta brainstorming é a terceira ferramenta mais citada

pelos autores pesquisados em sua dissertação, para o processo de identificação de riscos. O

brainstorming consiste em realizar uma reunião com a equipe de projeto e/ou especialistas,

onde os envolvidos geram idéias sobre os riscos do projeto, sendo coordenados por um

facilitador. As fontes de riscos são identificadas de maneira geral e apresentadas para análise

de todos, durante a sessão. Os riscos são, então, classificados de acordo com o seu tipo e suas

definições são refinadas (MCMANUS, 2004 e PMI, 2002 apud WEBSTER, 2005).

2.4.5 Análise de Informações históricas

A análise de informações históricas de projetos anteriores pode ser utilizada como

ferramenta para identificação de riscos. Na pesquisa realizada por Webster (2005) essa

ferramenta foi citada por cinco autores como ferramenta para tal processo.

Segundo PMI (2008) as informações históricas e as lições aprendidas são transferidas à

base de conhecimento para o uso em projetos ou fases futuras, fornecendo um depósito de

informações sobre os resultados de projetos anteriores. Isso pode incluir informações a

respeito de questões e riscos, assim como técnicas que funcionaram bem e que podem ser

aplicadas em projetos futuros.

Webster (2005) cita, ainda, outras fontes de informações históricas que devem ser

analisadas: (a) arquivos de projeto: uma ou mais organizações envolvidas no projeto podem

manter registros dos resultados dos projetos anteriores que podem ser utilizados na

identificação de riscos. Esses registros podem incluir os relatórios de acompanhamento do

95

projeto ou os planos de respostas aos riscos. Eles podem também incluir lições aprendidas que

descrevem os problemas e sua resolução ou podem estar disponíveis através da experiência

dos interessados no projeto ou de outras pessoas da organização; (b) informações publicadas:

em banco de dados comerciais, estudos acadêmicos, benchmarking e outros estudos

publicados podem estar disponíveis para as várias áreas de aplicação.

2.4.6 Comparação análoga

É um método de identificação de riscos que tem como premissa a idéia de que nenhum

projeto de sistema representa um projeto totalmente novo, independente do quão avançado ou

único ele seja. O método parte do pressuposto da identificação de projetos similares,

permitindo que os dados dos mesmos possam ser utilizados pelo projeto em desenvolvimento

para sua revisão ou para sua própria elaboração (GUSMÃO; MOURA, 2005; MACHADO,

2002).

A identificação de projetos similares envolve a determinação de características comuns

aos projetos, por exemplo, tecnologia, funcionalidade, estratégia de contrato e processo de

desenvolvimento (MACHADO, 2002 apud PRITCHARD, 1997).

A comparação análoga é mais simplificada de ser utilizada. Uma preocupação na

utilização da comparação análoga é a que ela depende da análise de dados históricos, da sua

interpretação, da precisão e do nível de detalhamento descrito.

O método que trabalha com essa abordagem é o do MITRE, através da ferramenta

RAMP - Risk Assessment and Management Program (GARVEY et al., 1997 apud GUSMÃO;

MOURA, 2005 e GARVEY et al., 1997 apud MACHADO, 2002), como também a

ferramenta mPRIME através do reuso baseado em repositório de projetos passados

(GUSMÃO et al 2005).

2.4.7 Análise de premissas

As premissas são fatores considerados como verdadeiros, sem prova ou demonstração,

para fins de planejamento. Uma das causas potenciais de risco do projeto e que devem ser

avaliadas são as incertezas nas premissas do projeto. Todos os projetos e todos os riscos

identificados no projeto são concebidos e desenvolvidos com base em um conjunto de

premissas, hipóteses ou cenários.

96

A análise das premissas é uma técnica que explora a validade e completude das

premissas em relação ao projeto. Esta técnica identifica riscos decorrentes do caráter

incompleto, inconsistente, inexato ou instável das premissas (PMI, 2008).

Na análise de premissas cada projeto é concebido e desenvolvido com base em um

conjunto de hipóteses ou premissas. Esta é uma técnica que explora as incertezas do projeto

pela existência de algumas premissas que foram assumidas e podem não ser verdadeiras.

Essas premissas imprecisas, inconsistentes ou incompletas deverão ser identificadas e

descritas para que posteriormente possam ser avaliadas (PMI, 2000 apud MACHADO, 2002).

2.4.8 Entrevista com especialistas

A entrevista com especialistas é mais um método de coleta de informações utilizado

para o levantamento e identificação de riscos. Primeiramente, identificam-se os especialistas,

cria-se uma agenda de reunião e desenvolve-se o roteiro de análise de riscos.

A aplicação do roteiro de análise de riscos pode ser desenvolvida através de entrevistas

individuais ou da formação de grupos focais (GUSMÃO; MOURA, 2005 apud Victoria et al.

2000). A vantagem deste método é a obtenção de diversas visões de riscos, dentro do contexto

escolhido, uma vez que estão tratando com profissionais de perfis e experiências distintas.

As vantagens desse método é a obtenção de diversas visões sobre os riscos do projeto,

pois os entrevistados podem ter perfis e experiências diferentes, contribuindo na identificação

de diversos aspectos relacionados aos riscos, e à facilidade para a sua aplicação (GUSMÃO;

MOURA, 2005, MACHADO, 2002).

Gusmão, Moura (2005) e Machado (2002) apresentam como desvantagens a criação do

roteiro de análise de riscos, não limitando as respostas dos entrevistados, e a forte

dependência existente entre entrevistado e entrevistador.

Segundo Webster (2005) em seu estudo, a utilização de entrevistas como ferramenta

para a identificação de riscos foi citada em seis referências dos dezesseis autores pesquisados.

Esse método consiste em entrevistar experientes gerentes de projetos ou especialistas no

assunto. O responsável pela identificação de riscos no projeto escolhe as pessoas apropriadas,

explica-lhes o projeto e fornece as informações, tais como: documentação do projeto e lista de

premissas. Os entrevistados identificam os riscos possíveis, com base em sua experiência, nas

informações sobre o projeto e em outras fontes que julgarem úteis (PMI, 2002 e

SOMMERVILLE, 2003 apud WEBSTER, 2005).

97

2.4.9 Análise da causa-raiz

A análise da causa-raiz é uma técnica específica para identificar um problema, descobrir

as causas subjacentes que levaram a ele e desenvolver ações preventivas. É usada para

determinar a razão subjacente básica que causa uma variação, um defeito ou um risco. Uma

causa-raiz pode provocar mais de uma variação, defeito ou risco no projeto (PMI, 2008).

Entre os métodos que empregam a análise da causa-raiz estão o Diagrama de Causa e

Efeito, também conhecido como Ishikawa ou Espinha de Peixe, e a técnica dos 6 W´s (Who,

Why, What, Whichway, Wherewithal, When) (GUSMÃO; MOURA 2005).

O Diagrama de Causa e Efeito foi desenvolvido por Kaoru Ishikawa, da Universidade

de Tóquio, em 1943, onde a utilizou para explicar para o grupo de engenheiros da Kawasaki

Steel Works como vários fatores podem ser ordenados e relacionados. Porém, somente em

1962, J. M. Juran o "batizou" como sendo diagrama de Ishikawa (PORTAL O GERENTE,

2006, 2010).

Os diagramas de causa e efeito ilustram como diversos fatores podem estar ligados a

problemas ou efeitos potenciais. As Figura 17 e Figura 18 são exemplos de diagramas de

causa e efeito. Uma possível causa-raiz pode ser revelada ao continuar a perguntar “por quê?”

ou “como?” seguindo uma das linhas. Os diagramas “Por quê-Por quê” e “Como-Como”

podem ser usados na análise de causa e efeito (PMI, 2008).

Tempo Máquina Método Material

Energia Medição Pessoal Ambiente

Maior

Defeito

Causas Potenciais Efeito

Figura 17: Fontes clássicas de problemas a considerar. Fonte: PMI (2008, p.176)

98

Tempo Máquina Método Material

Energia Medição Pessoal Ambiente

Erro na reserva

do Hotel

Causas Potenciais Efeito

Requisição formal necessária

Política

Sem filtro nas janelas Sobrecarga

de brilho

Iluminação Layout do

LobbySonorização insuficiente

Ruídos e distrações

Figura 18: Segmento sobre o ambiente expandido por brainstorming. Fonte: PMI (2008,

p.176)

A filosofia da análise da causal-raiz é que se um erro ocorrer, ele irá acontecer

novamente, ao menos que se faça algo para evitá-lo (HALL, 1995 apud MACHADO, 2002).

A técnica de 6 W´s envolve analisar a origem das incertezas do projeto, pois elas estão

associadas a 6 questões básicas, que necessitam ser endereçadas (CHAPMAN & WARD,

1997 apud MACHADO, 2002):

1. WHO (Quem): Quem são as partes envolvidas (os stakeholders)?

2. WHY (Por que): O que as partes (stakeholders) querem alcançar?

3. WHAT (O que): No que os participantes estão interessados?

4. WHICHWAY (De que maneira): Como será feito?

5. WHEREWITHAL (Com que recursos): Quais recursos serão necessários?

6. WHEN (Quando): Quando terá que ser feito?

Um ou mais dos stakeholders do projeto identificam os seus propósitos básicos ou os

seus benefícios, o porquê (WHY) ou os motivos do projeto. Esses motivos geralmente

envolvem lucros (vantagens), rendimentos e custo, dentre outros (MACHADO, 2002).

Uma breve descrição do processo de definição de projeto em termos dos 6 Ws está

representado na Figura 19 (MACHADO, 2002).

99

Figura 19: Processo de definição de projeto. Fonte: CHAPMAN & WARD (1997) apud

MACHADO (2002, p.42)

2.4.10 Técnica Delphi

A Técnica Delphi de acordo com o PMI (2008) é uma técnica de coleta de informações

utilizada para obter um consenso de especialistas em um assunto. No casso de risco em

projetos, os especialistas em riscos participam anonimamente nessa técnica. Um facilitador

usa um roteiro de análise de riscos para solicitar idéias sobre riscos importantes para o projeto

em questão. As respostas são apresentadas e redistribuídas para os especialistas para

comentários adicionais, caso desejem. Para manter o anonimato, as respostas só ficam

disponíveis ao facilitador. O consenso pode ser atingido após algumas rodadas desse

processo. A técnica Delphi ajuda a reduzir a parcialidade nos dados e evita que alguém possa

influenciar indevidamente o resultado.

Essa técnica é uma variação dos grupos focais, onde especialistas são identificados, mas

participam anonimamente (VICTORIA et al. 2000 apud GUSMÃO; MOURA, 2005).

Como vantagem desta técnica, tem-se a redução dos desvios nos dados e o equilíbrio

mantido entre as influências dos especialistas (PMI, 2000 apud MACHADO, 2002). Como

desvantagem, igualmente a entrevista com especialistas, há uma dependência em relação ao

roteiro de análise de riscos formulado pelo facilitador, que pode limitar a troca de idéias

(MACHADO, 2002).

100

3 METODOLOGIA DA PESQUISA

Iniciou-se o estudo por meio da fundamentação teórica de modo a apresentar uma visão

geral dos padrões de conhecimento, normas e métodos de gerenciamento de projetos divididos

em “tradicionais” e ágeis, conforme descritos por vários autores.

O estudo inicial apresentou ainda uma revisão bibliográfica quando foram separados os

processos de gestão de riscos entre os métodos “tradicionais” e ágeis e também algumas

normas e métodos específicos da área de TI que abordam a gestão de riscos em projetos de

desenvolvimento de software.

Logo após foram mostrados alguns métodos utilizados para a identificação de riscos em

projetos.

Para alcançar o objetivo geral, foram definidos oito objetivos específicos, conforme

mencionado, e, a seguir, será descrito o método adotado para atingi-los.

Para os objetivos específicos, (a) identificar métodos “tradicionais” de gerenciamento

de projetos e (b) identificar métodos ágeis de gerenciamento de projetos, foi realizado um

estudo dos padrões de conhecimento, normas e métodos de gerência de projetos, apresentando

uma visão geral destes (Figura 20).

Gerência de Projetos

“Tradicional”

Método Ágil de Gerenciamento

de Projetos

GERÊNCIA DE PROJETOS( Padrões de Conhecimento, Normas e Métodos )

Figura 20: Padrões de conhecimento, normas e métodos de gerenciamento de projetos.

Fonte: Elaboração do autor.

Com relação aos objetivos específicos, (c) identificar padrões de conhecimento,

metodologias ou normas para a área de TI, sobre gerenciamento de riscos em projetos e

101

(d) verificar como os itens acima (padrões de conhecimento, metodologias ou normas) tratam

o gerenciamento de riscos, foi realizado um estudo, por meio de revisão bibliográfica, e foram

apresentados os processos de gestão de riscos para os mesmos, incluindo a gestão de riscos

em projetos de desenvolvimento de software identificados em diversos padrões de

conhecimento, metodologias e normas da área de TI (Figura 21).

GERÊNCIA DE PROJETOS( Processos de Gestão de Riscos )

Processos de Gestão

de Riscos

Processos de Gestão

de Riscos

Gestão de Riscos em

Proj. Desenvolv. de

Software

Figura 21: Processos de gestão de riscos. Fonte: Elaboração do autor.

Na busca de alcançar os objetivos específicos, (e) levantamento e atualização de uma

taxonomia de riscos para projetos de TI e (f) propor uma priorização de riscos para projetos

de TI, primeiramente foi realizado um estudo de alguns métodos utilizados para identificação

de riscos (Figura 22) e a partir deste, foi adotada uma metodologia (Figura 23) partindo do

estudo realizado por Webster (2005) onde ela propôs uma lista de riscos a partir de pesquisa

realizada com dezessete autores. Posteriormente foi realizada uma integração semântica com

a lista de riscos proposta por Mulcahy (2010), onde o resultado final é uma relação de fatores

de riscos para desenvolvimento de software.

102

IDENTIFICAÇÃO DE RISCOSMétodos

Figura 22: Métodos de identificação de riscos. Fonte: Elaboração do autor.

Após identificar os fatores de riscos para o desenvolvimento de software, a partir de

pesquisa de campo, estes foram assim classificados: por fases do projeto em que o fator de

risco aparece, por categorias; e, ainda, a priorização dos fatores de riscos, alcançada a partir

do cálculo do grau de exposição.

Já o objetivo específico, (g) avaliar como as empresas de TI identificam e tratam os

riscos em seus projetos, foi desenvolvido, devido à natureza, por meio de pesquisa de campo.

E, por fim, o último objetivo específico, (h) a partir da investigação realizada fazer uma

proposta de um método ágil de identificação de riscos para projetos de TI, isto foi realizado

após as investigações e a obtenção dos resultados da pesquisa de campo, já apresentadas

(Figura 24).

103

Fatores de risco de

desenvolvimento de software

integrados

(17 autores) (Webster, 2005)

Riscos propostos por

Rita Mulcahy (2010)

Pela influência

interna e externa

Por Fases do

ProjetoPor Categorias

Pelo Grau de

Exposição

(Priorização)

Integração semântica

Fatores de Riscos Identificados e Classificados

Fatores de risco para

desenvolvimento de

software

Figura 23: Método adotado para identificação e classificação dos fatores de riscos.

Fonte: Elaboração do autor.

Proposta de um Método Ágil para Identificação de

Riscos em Projetos de TI

INVESTIGAÇÃO – GERÊNCIA DE PROJETOS

Ger. de Projetos

“Tradicional”

Metod

A. . .

Metod

N

Gerência de Riscos

“Tradicional”

Modelos de

Gestão de

Riscos em

Projetos de

Desenvolvi-

mento de

Software

Ger. de Projetos

“Método Ágil”

Metod

. A. . .

Metod

. N

Métodos

para

Identificação

de Riscos

Gerência de Riscos

“Ágil”

Figura 24: Abordagem adotada para propor um método ágil para a identificação de riscos em

projetos de TI. Fonte: Elaboração do autor.

A abordagem adotada para o trabalho em relação ao procedimento de coleta de dados da

pesquisa de campo se deu conforme figura abaixo.

104

Análise das Informações

Figura 25: Abordagem do trabalho em relação à metodologia de pesquisa. Fonte:

Elaboração do autor.

Para a pesquisa de campo, foi adotado o método de estudo de caso múltiplo. Segundo

Yin (2005) a investigação de estudo de caso aborda a situação em que haverá mais variáveis

de interesse do que pontos de dados e beneficia-se do desenvolvimento prévio de proposições

teóricas para conduzir a coleta e a análise de dados.

De acordo com Yin (2001, p.29), o estudo de casos levanta a preocupação em relação à

pouca base fornecida para se fazer uma generalização científica. Embora os resultados deste

estudo não possam ser generalizados para todas as empresas do setor pesquisado, espera-se

que tal estudo de casos múltiplos, por sua natureza exploratória, permita aprofundar o

conhecimento sobre o fenômeno estudado, levantando, também, questões para futuras

investigações.

Biagi (2010) diz que nos estudos de casos o que interessa é o potencial para produzir

informação sobre singularidades, particularidades, ações e situações. Conforme já

Instrumento de Coleta de Dados

- Definição do questionário

- Aplicação do questionário piloto

- Ajuste do questionário

Caracterização da Amostra e

Procedimento de Coleta de Dados

- Seleção das empresas e pessoas chaves

a serem pesquisadas

- Entrevista com apoio do questionário

Forma de Tabulação

- Tabulação e análise dos dados

- Avaliação dos resultados

Proposta de um método ágil de identificação de riscos

- Identificação de fatores de riscos em projetos de TI

- Adaptar o processo do ciclo de vida dos métodos ágeis de gerência de projetos

- Aplicação dos fatores de riscos para agilizar a identificação de riscos nos projetos de TI

- Identificação dos processos/abordagens

adotados para gerenciamento de riscos

- Identificação dos principais

problemas/dificuldades para gerenciar

riscos

- Análise dos fatores de riscos quanto às

fases do projeto, categorias de riscos e

grau de exposição dos riscos

- Análise da qualidade das informações

obtidas

105

mencionado este trabalho aborda como as empresas selecionadas lidam com os riscos em seus

projetos.

Trata-se de um estudo de caso múltiplo em seis empresas, sendo que o roteiro está

descrito nos itens abaixo e o tipo de empresa está descrito na Figura 26. Para realizar o estudo

de caso foi utilizada a abordagem descrita na Figura 25.

3.1 Instrumento de coleta de dados para pesquisa de campo

A pesquisa adotada, quanto à finalidade, é classificada como pesquisa aplicada

(MENDONÇA, 2008), por buscar conhecimentos para aproveitamento prático na solução de

problemas sobre gerenciamento de riscos em empresas de TI.

Inicialmente para a realização desta pesquisa foi feita, (a) uma fundamentação teórica,

(b) uma análise semântica dos fatores de riscos identificados na fundamentação teórica, e (c)

elaboração do roteiro de análise de riscos a ser utilizado na pesquisa, através de dados obtidos

através dos itens “a” e “b”.

A seguir serão descritos os itens (a), (b) e (c):

(a) Fundamentação teórica: para ver a descrição deste item consultar item 2-

Fundamentação Teórica, nesta dissertação;

(b) Análise semântica dos fatores de riscos: esta análise foi feita a partir do

levantamento, identificação e seleção de fatores de riscos descritos por diversos

autores sobre projetos de desenvolvimento de software (Tabela 17 e Tabela

18). O método para identificação e classificação dos fatores de riscos está

representado na Figura 23.

Para selecionar os fatores de riscos foram utilizados os 51 fatores de

riscos integrados (Tabela 18) por Webster (2005) a partir da investigação de

382 fatores de riscos de diversos autores e de 96 fatores de riscos (Tabela 17)

sugeridos por Mulcahy (2010).

A análise semântica foi feita através da verificação dos riscos

semelhantes, embora em alguns casos possam estar descritos de forma

diferente, entre os autores citados em Webster (2005) e Mulcahy (2010), são

semanticamente semelhantes. O resultado dessa análise é um conjunto de

riscos integrados. Estes foram obtidos a partir de quatro etapas:

106

o A primeira etapa foi eliminar os fatores de riscos citados por

Mulcahy (2010) que sejam específicos para sistema de

informação18

e não para desenvolvimento de software19

. Esta etapa

é apresentada no Apêndice II deste trabalho.

o A segunda etapa foi realizar a análise de semelhança semântica

entre os fatores de riscos selecionados para identificar possíveis

duplicações, sendo os 51 fatores de riscos integrados por Webster

(2005) e os fatores de riscos de Mulcahy (2010) selecionados após

a primeira etapa. Esta etapa é apresentada no Apêndice II deste

trabalho.

o A terceira etapa foi a integração dos fatores de riscos dos autores,

agrupando os fatores de risco considerados semelhantes

semanticamente. Um desafio nessa etapa foi a descrição do fator de

risco, levando-se em conta que os autores escrevem de forma

diferente. Diante disso e para manter uma mesma lógica ou linha de

raciocínio, procedeu-se a utilização dos fatores de risco do SEI

(Tabela 16), seguindo o mesmo critério adotado por Webster

(2005). Esta etapa é apresentada no Apêndice II deste trabalho.

o A quarta etapa foi organizar os fatores de riscos, da terceira etapa,

em categorias, para isso foram utilizadas as categorias da

taxonomia do SEI (CARR et al., 1993) (Tabela 16) que é a

taxonomia mais referenciada na literatura segundo Webster (2005).

Esta etapa é apresentada no Capítulo 4 deste trabalho.

(c) Pesquisa de campo: este item foi feito por meio de estudo de caso múltiplo,

utilizando-se entrevistas, em empresas de TI, na área de desenvolvimento de

software (Figura 26), com o apoio de roteiro estruturado de avaliação de riscos

(modelo de análise construído para esta dissertação), que possibilitou traduzir

18

Conjunto de componentes inter relacionados que coleta, recupera, processa, armazena e distribui informações

destinadas a apoiar a tomada de decisões, a coordenação e o controle de uma organização (Sistema Glossários,

2010). 19

Área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de

sistemas e/ou software aplicando tecnologias e melhores práticas consagradas de desenvolvimento de software e

de gerência de projetos, objetivando controle, produtividade e qualidade do produto a ser entregue (Sistema

Glossários, 2010).

107

as opiniões e informações coletadas. Esta etapa é apresentada no Capítulo 4

deste trabalho.

Com relação à pesquisa de campo, esta é classificada como exploratória e

descritiva (MENDONÇA, 2008). Exploratória porque se utiliza da pesquisa

bibliográfica, com base em material publicado em livros, artigos, revistas

especializadas e na internet como subsídio para alcançar o objetivo deste

trabalho. Descritiva por descrever fatos observados, expondo dentre outros

itens os fatores de riscos para desenvolvimento de software. A pesquisa usa

uma técnica padronizada de coleta de dados realizada pelo uso de roteiro de

análise de riscos estruturados e que possibilita a classificação e priorização dos

fatores de riscos20

.

Após a definição e elaboração do roteiro de análise de riscos, foi

realizado um pré-teste (piloto) com o objetivo de verificar o entendimento das

questões e a duração da entrevista.

Realizado o pré-teste procedeu-se aos ajustes necessários para melhorar o

entendimento das questões e definir uma estimativa de duração da entrevista.

3.2 Empresas participantes e coleta de dados e informações

Com a fase de elaboração do roteiro de análise concluída passou-se à fase de

caracterização da amostra e definição dos procedimentos de coleta de dados.

O roteiro de análise de riscos foi submetido aos profissionais de gerência de projetos,

mais especificamente, gerentes de projetos de diferentes empresas (Figura 26) com

experiência prática no gerenciamento de projetos de desenvolvimento de software.

20

A priorização de riscos é feita pelo cálculo da probabilidade de ocorrência do fator de risco multiplicado pelo

somatório dos impactos em custo, prazo e qualidade que o mesmo pode causar ao projeto. Classificando-se, em

ordem decrescente, o resultado deste cálculo, teremos a priorização dos fatores de riscos do mais importante para

ao menos importante, segundo a pesquisa de campo (CAIXETA, 2006).

108

Empresa c/

abrangência

no território

Nacional

Empresa

Líder de

produto

Nacional

Empresa

referência no

Governo

Estadual

Empresa

referência no

Governo

Municipal

Empresa c/

atuação

Internacional

Empresas do Setor PRIVADO Empresas do Setor PÚBLICO

Empresa

Líder de

produto no

Centro-Oeste

Figura 26: Empresas participantes do estudo. Fonte: Elaboração do autor.

Por meio de pesquisa de campo chegou-se aos resultados deste trabalho, levando-se em

consideração a forma como a empresa gerencia e trata os fatores de riscos em seus projetos,

conforme apresentados no roteiro de análise de riscos.

Estes fatores foram abordados, na pesquisa de campo, para identificar se são

considerados como sendo internos ou externos ao projeto, em quais fases do projeto o fator de

risco está inserido, qual a probabilidade de ocorrência e quais os impactos em relação a

custos, prazos e qualidade.

Os valores atribuídos à probabilidade e os impactos em custo, prazo e qualidade, foram

utilizados como subsídios para cálculo do grau de exposição do fator de risco e,

conseqüentemente, para definir sua priorização (CAIXETA, 2006). Este cálculo foi realizado

através do produto da probabilidade (Tabela 19), pelo somatório dos impactos em custo, prazo

e qualidade (Tabela 20). O grau de exposição do fator de risco (GE) = (P) Probabilidade x (I)

∑ impactos(custo, prazo e qualidade).

Para a atribuição de valores para a probabilidade do fator de risco foram adotados os

parâmetros abaixo:

Tabela 19: Pontuação atribuída ao item probabilidade do roteiro de análise de riscos

PROBABILIDADE

(Alternativas de resposta no roteiro de

análise de riscos)

FAIXA

(Probabilidade de ocorrência)

PONTUAÇÃO

atribuída a cada faixa

Muito Alta > 70% 0,9

Alta 50% a 70% 0,7

Moderada 30% a 49,9% 0,5

Baixa 10% a 29,9% 0,3

Muito Baixa < 10% 0,1

Fonte: Caixeta (2006, p.90)

109

Para a atribuição de valores para os impactos em custo, prazo e qualidade foram

adotados os parâmetros abaixo:

Tabela 20: Pontuação atribuída ao item impacto do roteiro de análise de risco

IMPACTO

Muito Baixo

0,05

Baixo

0,1

Moderado

0,2

Alto

0,4

Muito Alto

0,8

ÁR

EA

S D

O P

RO

JE

TO

Custo

Aumento

insignificante

do custo

Aumento

do custo <

5%

Aumento

do custo

entre 5% e

10%

Aumento

do custo

entre 10% e

20%

Aumento

do custo

acima de

20%

Prazo

Desvio

insignificante

no prazo

Aumento

do prazo <

5%

Aumento

do prazo

entre 5% e

10%

Aumento

do prazo

entre 10% e

20%

Aumento

do prazo

acima de

20%

Qualidade

Degradação

quase

imperceptível

da qualidade

Reflexo

apenas em

aplicações

mais

exigentes

Redução da

qualidade

requer

aprovação

do cliente

Redução da

qualidade

inaceitável

para o

cliente

Produto

final do

projeto

inutilizável

Fonte: Caixeta (2006, p.90)

Para a definição dos locais da investigação, adotou-se o método do quociente

locacional21

. Para a determinação do quociente locacional foi realizado estudo com o objetivo

de identificar qual estado brasileiro apresentava maior concentração locacional para a

utilização de uma metodologia formal de gerenciamento de riscos e escolha de qual(is)

estado(s) de uma região seria(m) selecionado(s) para a elaboração da dissertação.

Após os estudos realizados (Apêndice I) os estados que apresentaram maior

concentração locacional foram os estados do Mato Grosso, Goiás e Distrito Federal (Região

Centro-Oeste), Ceará e Bahia (Região Nordeste) e Santa Catarina e Rio Grande do Sul

(Região Sul).

Pelo estudo (Apêndice I) pode-se observar que três regiões brasileiras se enquadravam

no objetivo proposto, ou seja, poderiam ser selecionadas para a aplicação da pesquisa de

campo.

21

Quociente locacional é uma medida de localização que possibilitou identificar em quais regiões e estados

brasileiros incide maior concentração de empresas que gerenciam riscos, baseando-se em uma metodologia

formal, estruturada por políticas, procedimentos e formulários.

110

Por questões de tempo, custo e facilidade operacional optou-se por realizar a pesquisa

na região Centro-Oeste, mais especificamente nas cidades de Goiânia, Aparecida de Goiânia e

Brasília.

A pesquisa de campo foi realizada em seis empresas da área de TI, mais

especificamente em empresas públicas e/ou privadas de desenvolvimento de software.

Foram realizadas, nessas empresas, entrevistas com os profissionais que lidam com

projetos (gerente de projetos), acreditando-se serem os mais adequados para fornecer as

informações sobre o assunto proposto neste trabalho.

O tipo da amostra delimitada para a pesquisa de campo é a intencional e de facilidade

operacional. Intencional, uma vez que seria pesquisada uma empresa de cada classificação

conforme apresentado na Figura 26; de facilidade operacional, já que a escolha das empresas

pesquisadas, conforme a classificação (Figura 26) dar-se-ia pela facilidade de acesso, custo e

tempo.

A pesquisa de campo está delimitada conforme abaixo:

Ramo de atividade: Empresas de TI de desenvolvimento de software

Localização geográfica: Empresas de Goiânia, Aparecida de Goiânia e

Brasília

Setor: Empresas Públicas e Privadas

Público a ser entrevistado nas empresas: Gerente de projetos

Tipo da amostra: Intencional e de facilidade operacional

Tipo de pesquisa: mista (quanti/qualitativa)

3.3 Forma de tabulação e análise dos resultados

Os dados foram tabulados conforme as divisões do roteiro de análise de riscos em suas

partes (Figura 26):

Na parte I: dados referentes aos entrevistados.

Na parte II: dados referentes às Empresas.

Na parte III: dados referentes ao gerenciamento de riscos pelas empresas.

Na parte IV: dados referentes aos fatores de riscos para desenvolvimento de

software, identificados conforme Figura 23. Essa tabulação permitiu a

classificação desses fatores de riscos, pelas fases do projeto, pelas categorias de

111

riscos e, ainda, a priorização dos fatores de riscos, alcançada a partir do cálculo

do grau de exposição, conforme já apresentado.

3.4 Roteiro de análise de riscos

O roteiro de análise de riscos para a pesquisa de campo foi desenvolvido com a

utilização do software Sphinx Léxica 2000, v.3.0b. Este foi divido em quatro partes, a saber:

Parte I – Dados do Entrevistado;

Parte II – Dados da Empresa;

Parte III – Gerência de Riscos e

Parte IV – Fatores de Riscos.

O roteiro de análise de risco encontra-se no apêndice VI desse trabalho.

112

4 ANÁLISE DAS INFORMAÇÕES

A análise das informações foi feita a partir da pesquisa de campo em seis empresas

(Figura 26), conforme citado no item 3.2 do Capítulo 3 deste trabalho.

Neste capítulo analisaram-se os seguintes itens: o perfil dos entrevistados, o perfil das

empresas pesquisadas, o processo/abordagem adotado pelas empresas para gerenciamento de

riscos em seus projetos (PMI, 2008) e os principais problemas/dificuldades que as empresas

enfrentam para gerenciar riscos. Foi feita ainda uma análise dos fatores de riscos quanto às

fases do ciclo de vida do projeto, quanto às categorias de riscos segundo o SEI (CARR et al.,

1993) e quanto ao grau de exposição dos fatores de riscos. É apresentado ainda um breve

comentário sobre a qualidade das informações obtidas durante as entrevistas.

Para manter sigilo com relação à identidade das empresas pesquisadas utilizaram-se as

seguintes codificações apresentadas na Figura 21.

Tabela 21: Codificação das empresas pesquisadas

EMPRESA EMPRESAS PARTICIPANTES DA PESQUISA

A Empresa referência no Governo Municipal

B Empresa com atuação internacional

C Empresa referência no Governo Estadual

D Empresa com abrangência no território nacional

E Empresa líder de produto no Centro-Oeste

F Empresa líder de produto nacional

Fonte: Elaboração do autor

4.1 Perfil dos entrevistados

Conforme matriz de casos (respostas das empresas pesquisadas) e atributos (questões)

das empresas pesquisadas (Tabela 22), observa-se que os entrevistados apresentam perfil de

profissionais experientes, a maioria possui mais de dez anos de atuação na área. Todos

possuem formação em gerência de projetos, e têm mais de 30 anos de idade.

113

Tabela 22: Perfil dos entrevistados

QUESTÕES

RESPOSTAS DAS EMPRESAS PESQUISADAS

A B C D E F

Nome do Entrevistado - - - - - -

E-mail - - - - - -

Sexo F M M M M M

Faixa Etária (em anos) Acima de 40 Acima de 40 30 a 35 30 a 35 30 a 35 Acima de 40

Cargo Atual Analista Gerente Analista Gerente Gerente Coordenador

do PMO

Formação/Certificações

em gerência de projetos

Pós-

Graduação

em GP

Certificação

em gerência

de projetos

(PMP)

Certificação

em gerência

de projetos

(PMP)

Certificação

em gerência

de projetos

(PMP)

Pós-

Graduação

em GP

Ciências da

computação e

mestrado em

gestão do

conhecimento

Expectativa quanto a

receber resultados da

pesquisa

Sim Sim Sim Sim Sim Sim

Tempo de experiência

profissional no ramo da

indústria de software (em

anos)

Mais de 10 Mais de 10 Mais de 10 Mais de 10 3 a 5 Mais de 10

Tempo de experiência

profissional como gerente

de projetos (em anos)

Mais de 10 5 a 10 5 a 10 5 a 10 5 a 10 5 a 10

Tempo médio de duração

dos projetos que gerenciou

(em meses)

6 a 12 12 a 18 12 a 18 12 a 18 12 a 18 6 a 12

Tamanho médio das

equipes de projeto

gerenciadas pelo

entrevistado (qtde de

pessoas)

10 a 15 10 a 15 5 a 10 5 a 10 15 a 20 Menos de 5

Fonte: Elaborado pelo autor, a partir da pesquisa de campo

4.2 Perfil das empresas pesquisadas

Conforme matriz de casos e atributos das empresas pesquisadas (Tabela 23), observa-se

que apenas as empresas B, D, E e F possuem abrangência nacional, sendo que a empresa “B”

é uma multinacional com atuação em cinco países. A empresa “E” é líder de produto no

Centro-Oeste e a “F” líder de produto a nível nacional. Um fato interessante é que, com

exceção da empresa “A”, todas as demais possuem uma metodologia de gerência de projetos

implantada (atributo 11 da Tabela 23), porém as empresas “C e E” não possuem uma

metodologia para gerenciamento de riscos (atributo 1 da Tabela 24), tal fato é abordado pelo

Estudo de Benchmarking em Gerenciamento de Projetos no Brasil (PMI-Chapters Brasileiros,

2008), conforme citado no Apêndice I, Tabela 30, onde uma parcela significativa das

114

empresas no Brasil realiza o gerenciamento de riscos informalmente. Acerca desses elementos

alguns dos entrevistados que utilizam o gerenciamento de riscos informalmente percebem a

sua importância em seus projetos, e tal fato pode ser observado no atributo 05 da Tabela 24.

Tabela 23: Perfil das empresas pesquisadas

QUESTÕES RESPOSTAS DAS EMPRESAS PESQUISADAS

A B C D E F

Razão Social - - - - - -

Ramo de Atividade Tecnologia da

informação

Desenvolvimento

de software

Tecnologia

da

informação e

Comunicação

Tecnologia

da

informação

Desenvolvimento

de Softwares

Contábeis e

Administrativos

Software

para

soluções de

RH

Estados de atuação da

empresa

Goiás AL, AP, BA, CE,

DF, GO, RJ, SC

e SP

Goiás DF, GO,

MG, MS,

MT, RS, SC

e SP

BA, DF, GO,

MA, MG, MS,

MT, PA, PR, SP

e TO

GO, MG,

PR, PE, RJ

e SP

Países de atuação da

empresa

Brasil Brasil,

Argentina, EUA,

Japão e China

Brasil Brasil Brasil Brasil

Faturamento médio

anual (em milhões de

reais)

10,0 a 50,0 Acima de 50,0 10,0 a 50,0 10,0 a 50,0 10,0 a 50,0 10,0 a 50,0

Número de

funcionários

De 100 a 249 Acima de 249 De 100 a 249 De 100 a

249

De 100 a 249 Acima de

249

Número de gerente

de projetos existente

na empresa

Acima de 10 Acima de 10 Acima de 10 Acima de

10

De 1 a 4 Acima de

10

Número de

desenvolvedores de

software

De 20 a 50 Acima de 50 Acima de 50 Acima de

50

De 20 a 50 Acima de

50

Número de projetos

de software que

contaram com a

participação do

entrevistado em 2010

04 02 04 Mais de 05 05 04

Número de projetos

de software que

contaram com a

participação do

entrevistado em

andamento em 2011

05 Mais de 05 01 (mudança

de governo)

Mais de 05 04 02

Abordagem adotada

pela empresa para

gerenciamento de

projetos

Realiza

gerenciamento

de projetos

informalmente

Baseado em uma

metodologia

Baseado em

uma

metodologia

Baseado em

uma

metodologia

Baseado em uma

metodologia

Baseado em

uma

metodologia


115

4.3 Processos/Abordagens adotadas para gerenciamento de riscos

Os representantes das empresas “A”, “C”, “D” e “E”, quando perguntados sobre a

utilização de métodos para identificação de riscos, responderam que não os utilizavam. Porém

quando foi mostrado a eles uma relação de vários métodos existentes, para identificação de

riscos, conforme apresentado no Capítulo 2, item 2.4 deste trabalho, onde estes métodos

foram citados por diversos autores, reconheceram que utilizavam vários deles.

Isso pode ter acontecido em decorrência do fato de que a maioria dessas empresas faz o

gerenciamento de riscos de seus projetos informalmente, ou seja, a empresa não possui um

método formal para gerenciamento de riscos. Isso vem ao encontro do Estudo de

Benchmarking em Gerenciamento de Projetos no Brasil, promovido pelo PMI-CHAPTERS

BRASILEIROS (2008), (ver Apêndice I, Tabela 30), onde se identifica apenas uma pequena

parcela das empresas no Brasil que realizam o gerenciamento de riscos baseado em uma

metodologia formal.

No atributo 3 (Tabela 24), todos os processos para gerenciamento de riscos informados

pelas empresas pesquisadas estão de acordo com os processos já citados no Capítulo 2, mais

especificamente no item 2.2-processos de gerenciamento de riscos e no item 2.3-modelos de

gestão de riscos em projetos de desenvolvimento de software. Acerca desses elementos

observa-se que algumas empresas utilizam mais processos de gerenciamento de riscos e

outras menos, mas sempre dentro dos processos já estudados. Tal fato pode ser decorrente da

metodologia adotada pela empresa/entrevistado, do tipo de projeto a ser desenvolvido, da

cultura da empresa etc.

No atributo 8 (Tabela 24), todas as empresas pesquisadas informaram que quando da

identificação/avaliação de riscos o fazem tanto para os riscos internos ao projeto quanto para

os riscos externos (ex: variação cambial). Webster (2005) já havia previsto estes tipos de

riscos (interno/externo) com relação a cronograma e orçamento, como pode ser verificado no

item 2.41 e 2.44 da Tabela 18.

Das empresas que possuem uma metodologia para gerenciamento de riscos, conforme

atributo 2 (Tabela 24), citado pelas empresas “B”, “D” e “F”, apenas a empresa “D” informou

que não identifica benefícios obtidos com o gerenciamento de riscos, conforme atributo

quatro (Tabela 24). Algumas respostas da empresa “D” apresentam uma contradição quando

ela informa que possui uma metodologia para gerenciamento de riscos (atributos 1 e 2 da

Tabela 24) porém, no atributo 6 desta mesma tabela o entrevistado informa que não utiliza

nenhum método para tal fim. Informa que apesar de possuir uma metodologia de

116

gerenciamento de riscos ela não é utilizada, conforme pode ser observado pela sua resposta

(ver Tabela 25).


pesquisadas


A B C D E F

Abordagem

adotada pela

empresa para

gerenciamento

de riscos

Realiza

informalmente

Baseado em

uma

metodologia

Realiza

informalmente

Baseado em

uma

metodologia

Realiza

informalmente

Baseado em uma

metodologia

Metodologia

utilizada para

gerenciamento

de riscos

-

Metodologia

desenvolvida

pelo escritório

de projetos da

empresa

-

Baseada no

CMMI nível

2 e PMBOK

-

PMBOK e

conceitos/estratégia

s da Rita Mulcahy e

taxonomia de risco

da SEI.

Processos

adotados para

gerenciar

riscos

Planejamento,

identificação e

planejamento

de resposta a

riscos

Planejamento,

identificação,

planejamento

de resposta a

riscos,

monitoração e

controle,

comunicação

de riscos e

lições

aprendidas

Lições

aprendidas

Identificação,

análise

quantitativa,

análise

qualitativa e

planejamento

de resposta a

riscos

Planejamento,

identificação e

lições

aprendidas

Planejamento,

identificação,

análise qualitativa,

planejamento de

resposta a riscos,

monitoração e

controle,

comunicação de

riscos, lições

aprendidas e outro

(aplicação de

ferramenta de BI

para coleta de

indicadores de

problema/risco (em

desenvolvimento))

A empresa

identifica

benefícios

obtidos com o

gerenciamento

de riscos?

Sim Sim Não Não Sim Sim

Se sim, quais? O sucesso na

implantação

do projeto;

recursos

necessários

para resolver

problemas.

Melhor

gerenciamento

do projeto em

relação a

custos, prazo,

escopo e

qualidade.

-

-

Contingencia-

mento de

situações e

lições

aprendidas que

podem ser

evitadas em

novos projetos

Redução de

problemas (prazo,

custo, qualidade e

escopo) ; redução

da insatisfação de

clientes.

A empresa

utiliza algum

método para

identificar

riscos?

Não Sim Não Não Não Sim


117


pesquisadas (Cont.)


A B C D E F

Se sim, quais? Brainstorming,

lista de

verificação,

entrevista,

análise de

premissa e

comparação

análoga.

Brainstorming,

análise de

premissas,

comparação

análoga e

análise de

informações

históricas.

Brainstorming,

lista de

verificação, e

análise de

informações

históricas.

Brainstorming,

lista de

verificação,

comparação

análoga, técnica

Delphi e

entrevista.

Brainstorming,

Comparação

análoga e

análise de

premissas.

Brainstorming,

taxonomia de

riscos,

comparação

análoga, análise

de premissas e

técnica Delphi.

Qual a

abrangência

de

identificação

/avaliação de

riscos que a

empresa

adota?

Riscos internos

e riscos externos

ao projeto

Riscos internos

e riscos externos

ao projeto

Riscos internos

e riscos externos

ao projeto

Riscos internos

e riscos externos

ao projeto

Riscos internos

e riscos externos

ao projeto

Riscos internos

e riscos externos

ao projeto


4.4 Principais problemas / dificuldades para gerenciar riscos

Conforme matriz de casos e atributos das empresas pesquisadas (Tabela 25), observa-se

que os problemas e dificuldades citados para gerenciamento de riscos pelas empresas “A, C,

D e E” são decorrentes, em sua maioria, da falta de gerenciamento de riscos com base em uma

metodologia. Tal fato pode ser minimizado com a utilização do método apresentado pelo

autor neste trabalho, citado no Capítulo 5, onde é apresentada a proposta de um método ágil

para identificação de riscos em projetos de desenvolvimento de software. O método proposto

pelo autor é fruto do estudo de diversos métodos e padrões de conhecimento, conforme

apresentado no capitulo 2.

118

Tabela 25: Principais problemas/dificuldades para gerenciar riscos citados pelas empresas

pesquisadas

EMPRESAS RESPOSTAS DAS EMPRESAS PESQUISADAS

(Qual(is) o(s) principal(is) problema(s) / dificuldade(s) para gerenciar riscos?)

A Identificação clara dos riscos que terão mais impacto no sucesso do projeto.

Os projetos podem estar funcionalmente bem elaborados, mas se os riscos não estiverem

claros previamente, a implantação do projeto pode estar comprometida.

B Monitoramento dos riscos em equipes remotas (em várias cidades).

C Ausência de um processo formal definido e de capacitação para os profissionais.

D Gerenciamento e atualização das informações de riscos.

E Falta de conhecimento ou uma metodologia adequada para o gerenciamento.

Dificuldade em identificar os riscos potenciais.

F Institucionalização do processo de risco definido.

Falta de maturidade/cultura interna de análise de risco.

Falta de priorização de tempo no decorrer do projeto para gerenciar os riscos.

Lidar com a falta de cultura do cliente em investir em gerenciamento de riscos.


4.5 Análise dos fatores de riscos

A análise dos fatores de riscos foi feita quanto às fases do ciclo de vida do projeto,

quanto às categorias segundo o SEI (CARR et al., 1993) e quanto ao grau de exposição

(CAIXETA, 2006) de cada fator de risco.

Antes de iniciar a análise deste item, faz-se necessária uma breve explicação sobre ela,

como segue:

Com relação aos fatores de riscos, foram utilizados os 52 fatores definidos no

Apêndice III, Tabela 38.

Com relação às fases do ciclo de vida do projeto foram definidas conforme as

fases adotadas pelo PMBoK (PMI, 2008) e apresentadas no Capítulo 2. São elas:

iniciação, planejamento, execução, monitoramento e controle, encerramento e

avaliação pós-encerramento. Esta última fase “avaliação pós-encerramento” foi

incluída pela empresa “F”, sendo citada somente por ela, durante a pesquisa.

119

Com relação às categorias de riscos, foi adotada a taxonomia proposta pelo SEI

(CARR et al, 1993), conforme apresentado na Tabela 16 do item 2.4.1 do

Capítulo 2 deste trabalho.

Com relação ao grau de exposição de cada fator de risco, este foi feito pelo

cálculo da probabilidade de ocorrência do mesmo multiplicado pelo somatório

dos impactos em custo, prazo e qualidade. Classificando-se, em ordem

decrescente, o resultado deste cálculo, obtêm-se a priorização dos fatores de

riscos do mais importante para o menos importante, segundo a pesquisa de

campo e conforme apresentado item 3.2 do Capítulo 3 deste trabalho.

4.5.1 Quanto às fases do ciclo de vida do projeto

A análise dos fatores de riscos quanto às fases do ciclo de vida do projeto foi realizada

através de uma classificação destes fatores, segundo as respostas dadas pelas empresas

pesquisadas.

Para isso, as empresas informaram, conforme Parte IV do roteiro de análise de riscos,

em qual(ais) fase(s) cada fator de risco pode ocorrer.

No Apêndice V são apresentadas as tabelas contendo as respostas de cada empresa para

cada fator de risco de acordo com as fases do ciclo de vida do projeto.

Neste mesmo apêndice observa-se, pelas análises das tabelas apresentadas, que não há

um consenso entre as empresas na relação entre fatores de riscos e fases do ciclo de vida do

projeto, ou seja, com relação em qual fase do ciclo de vida do projeto um fator de risco poderá

aparecer.

4.5.2 Quanto às categorias de riscos

A classificação dos fatores de riscos para desenvolvimento de software está organizada

em categorias, conforme a taxonomia proposta pelo SEI (CARR et al., 1993) e distribuídas

em três níveis, conforme Tabela 16. São eles: classes, elementos e atributos. As classes estão

organizadas em elementos e estes estão divididos em atributos.

Com a intenção de simplificar a classificação dos fatores de riscos para

desenvolvimento de software, em categorias, adotou-se o primeiro nível da classificação

120

proposta pelo SEI, ou seja, os fatores de riscos foram classificados pelas classes conforme

Tabela 16.

Com relação a estas classes definidas pelo SEI, foi feita uma adequação nos nomes das

mesmas, com a intenção de facilitar o entendimento do leitor. Cabe lembrar aqui que esta

adequação nos nomes não afeta o significado proposto, pois o novo nome foi extraído da

definição original apresentada pelo SEI, ficando assim:

Engenharia do produto (CARR, et al., 1993): compreende os fatores técnicos

relacionados ao produto e, portanto, passaremos a denominá-la de Riscos

Técnicos;

Ambiente de desenvolvimento (CARR et al.,1993): compreende o processo

de desenvolvimento de sistemas, métodos de gestão e ambiente de trabalho e,

portanto, passaremos a denominá-la de Riscos Metodológicos, por se tratar dos

métodos relacionados ao ambiente de desenvolvimento de sistemas;

Restrições de programa (CARR et al.,1993): compreende os fatores

contratuais, organizacionais e operacionais no qual o software é desenvolvido

e, portanto, passaremos a denominá-la de Riscos Organizacionais.

A seguir é apresentada, por meio da Tabela 26, a classificação dos fatores de riscos (ver

Tabela 38) quanto às categorias propostas pelo SEI (CARR et al.,1993).


quanto às categorias propostas pelo SEI

Categoria de

Risco

ID FATOR DE RISCO INTEGRADO

Técnico 01 Requisitos instáveis

Técnico 02 Requisitos incompletos.

Técnico 03 Requisitos não claros (ambíguos / imprecisos).

Técnico 04 Requisitos mal entendidos (não refletem as expectativas do cliente).

Técnico 05 Adição de maior funcionalidades que o especificado / dar extras ao cliente.

Técnico 06 Requisitos de desempenho não atendidos. Ex. Baixo desempenho.

Técnico 07 Alto nível de complexibilidade técnica.

Técnico 08 Desenvolvimento de interface do usuário inadequada.

Técnico 09 Problemas de desempenho de tempo real (há tempos de respostas restritos).

Técnico 10 Restrições referentes ao hardware designado. Ex.: capacidade de memória e

tempo de resposta real, acesso à base de dados e insuficiência de hardware.

Técnico 11 Tecnologia nova / imatura (uso de novas tecnologias).

Técnico 12 Inadequada preparação e realização dos testes. Ex.: instalações inadequadas,

e tempo insuficiente para realização dos testes, falta de dados precisos para

testar as mudanças e utilização de método de teste inadequado.

Fonte: Elaboração do autor a partir de SEI (CARR et al., 1993); Webster (2005) e Mulcahy (2010).

121


quanto às categorias de riscos propostas pelo SEI (Cont.)

Categoria de

Risco


Técnico 13 Falta de um acordo interativo entre os clientes e os desenvolvedores relativo

às especificações dos requisitos.

Técnico 14 Inadequadas especificações. Ex.: especificações de sistema, hardware,

software, interface, requisitos de teste a qualquer nível com respeito à

viabilidade de implementação e à estabilidade dos atributos de qualidade,

completude e clareza.

Metodológico 15 Modelos, processos, métodos e ferramentas de apoio selecionados

inadequados para o processo de desenvolvimento.

Metodológico 16 Falta / insuficiência de controle do processo de desenvolvimento. Ex.: uso

do recurso, medição do progresso referente à qualidade e metas de

produtividade.

Metodológico 17 Controle do produto inadequado. Ex.: o produto final não corresponde às

expectativas do cliente.

Metodológico 18 Documentação / papelada excessiva.

Metodológico 19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta de estações de

trabalho, espaço de armazenamento no banco de dados insuficiente.

Metodológico 20 Pouca confiança no desenvolvimento do sistema devido à indisponibilidade /

erro / mal funcionamento dos componentes.

Metodológico 21 Pobre suporte ao sistema. Ex.: treinamento para utilização do sistema,

acesso para usuários especialistas ou consultores, conserto ou resolução de

problemas por parte dos vendedores.

Metodológico 22 Planejamento inapropriado, incluindo construção e atualização do plano de

contingência.

Metodológico 23 Papéis e responsabilidades de relacionamentos mal definidos ou mal

entendidos.

Metodológico 24 Gerentes do desenvolvimento do software inexperientes ou ineficientes.

Metodológico 25 Fraca interação (comunicação) do gerente com todos os envolvidos do

projeto.

Metodológico 26 Falhas em gerenciar as expectativas do usuário final.

Metodológico 27 Ausência de um líder.

Metodológico 28 Falta de metodologia efetiva de gerenciamento de projetos.

Metodológico 29 Fraco monitoramento do progresso das atividades relacionadas ao projeto.

Ex.: acompanhamento do relatório de status e manutenção de métricas

progressivas.

Metodológico 30 Treinamento inadequado ou indisponível.

Metodológico 31 Falta de procedimentos, programas adequados e recursos para assegurar a

garantia da qualidade.

Metodológico 32 Gerência de Configuração inadequada.

Metodológico 33 Mudanças contínuas no objetivo e escopo do projeto.

Metodológico 34 Erro ao estimar (tempo, custo e esforço) .

Metodológico 35 Métricas inadequadas / inexatas.

Organizacional 36 Falta espírito de equipe. Os conflitos requerem intervenção da gerência.

Organizacional 37 Problema de comunicação devido à falta de conhecimento da missão, metas

do projeto, informações técnicas entre pares e gerentes e devido à distância

(membros da equipe espalhados por todo o pais).

Organizacional 38 Baixa moral/ falta de compromisso devido ao baixo nível de entusiasmo

afetando assim a produtividade e criatividade. As pessoas não se sentem

reconhecidas e recompensadas pelos superiores.

Organizacional 39 Falta de maturidade / instabilidade organizacional.

Organizacional 40 Baixa produtividade da equipe.


122


quanto às categorias de riscos propostas pelo SEI (Cont.)

Categoria de

Risco


Organizacional 41 Cronograma irreal ou inadequado baseado nos eventos internos e externos

do sistema.

Organizacional 42 Pressão excessiva de prazo.

Organizacional 43 Problemas de pessoal. Ex.: falta experiência, pouco conhecimento, falta de

habilidade, falta de pessoal e indisponibilidade de pessoas chaves.

Organizacional 44 Orçamento insuficiente ou instável baseado nos eventos internos e externos

do sistema.

Organizacional 45 Instabilidade (rotatividade) e falta de continuidade das pessoas nos projetos.

Organizacional 46 Qualquer problema com o cliente, tais como: demora na aprovação de

documentos, comunicação pobre, resistência à mudança, falta de

comprometimento, falta de cooperação, conflitos entre clientes e

departamentos, dependência técnica.

Organizacional 47 Problemas relacionados aos contratos associados.

Organizacional 48 Qualquer problema associado à subcontratação.

Organizacional 49 Fatores políticos (companhia, clientes, contratantes associados e

subcontratantes) que causam problemas para o desenvolvimento do projeto.

Organizacional 50 Qualquer problema com o usuário, tais como: falta de envolvimento /

comprometimento, conflito entre usuários e departamentos, falta de

entendimento com relação ao funcionamento do sistema, resistência a

mudanças e falha em obter o comprometimento do usuário.

Organizacional 51 Falta de comprometimento da gerência sênior

Organizacional 52 Qualquer problema de comunicação em nível internacional relativo a

diferenças de idiomas.


4.5.3 Quanto ao grau de exposição dos fatores de riscos

Os fatores de riscos foram analisados pelas empresas pesquisadas, quanto à sua

probabilidade de ocorrência e impacto nas dimensões de custo, qualidade e prazo (ver

resposta das empresas pesquisadas no Apêndice IV). Os valores atribuídos à probabilidade e

aos impactos em custo, prazo e qualidade foram utilizados como subsídios para cálculo do

grau de exposição do fator de risco e, conseqüentemente, para definir sua priorização

conforme definido no item 3.2 do Capítulo 3.

Considerando-se a matriz de fatores de riscos e a avaliação de probabilidade e impacto

(Tabela 27), observa-se que os resultados estão em sintonia com as principais causas de

fracasso em gerência de projetos apresentadas no referencial da pesquisa de Archibald &

Prado 2008 (ver Gráfico 11).

Das dez principais causas de fracasso citadas pela referida pesquisa, oito aparecem na

Tabela 27, sendo elas: mudança de escopo, falta de comprometimento das áreas, prazos

123

inexeqüíveis, riscos não gerenciados, capacidade gerencial dos GP‟s insuficiente, falta de

comprometimento da alta administração, precariedade de metodologia de GP e habilidade

técnica insuficiente.

Na Tabela 27 é apresentado um resumo das respostas dessas empresas com relação à

análise dos fatores de riscos. Esse resumo foi feito a partir da média das respostas dadas pelas

empresas pesquisadas.

Na primeira e segunda colunas da Tabela 27 são mostrados, respectivamente, o

identificador (ID) e o nome (Fator de Risco Integrado), conforme definido na Tabela 38, no

Apêndice III.

Na terceira coluna é apresentada a média das avaliações, feitas pelas empresas

pesquisadas, quanto à probabilidade (P) de ocorrência do fator de riscos. Para responder este

item as empresas utilizaram os seguintes valores: 1-Muito Baixa; 2-Baixa; 3-Moderada; 4-

Alta e 5-Muito Alta.

Na quarta, quinta e sexta colunas são apresentadas as médias das avaliações, quanto ao

impacto do fator de riscos, com relação ao custo, qualidade e prazo respectivamente. Para

responder este item as empresas utilizaram os seguintes valores: 1-Muito Baixo; 2-Baixo; 3-

Moderado; 4-Alto e 5-Muito Alto.

A sétima coluna representa o cálculo do impacto referente aos fatores de riscos

relacionados ao custo, a qualidade e ao prazo. Este cálculo é feito pela soma dos impactos (I)

no custo, na qualidade e no prazo.

A oitava coluna representa o cálculo do grau de exposição de cada risco. Este cálculo

foi feito através do produto da probabilidade (P) pelo impacto (I), ou seja, (P x I), conforme

apresentado pelo autor no item 3.2, do Capítulo 3. Ao calcular o grau de exposição de cada

risco estes foram organizados em ordem decrescente, apresentando assim uma classificação,

ou seja, a priorização dos fatores de riscos do maior para o menor grau de exposição.

Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas

ID FATOR DE RISCO INTEGRADO Probabilidade Impacto

Classificação Custo Qualidade Prazo Total

1 Requisitos instáveis. 3,7 4,2 3,7 4,0 11,8 43,4

33 Mudanças contínuas no objetivo e escopo do

projeto. 3,8 4,0 2,7 4,2 10,8 41,5

Fonte: Elaborado pelo autor a partir da pesquisa de campo

124

Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas (Cont.)



43 Problemas de pessoal. Ex.: falta experiência,

pouco conhecimento, falta de habilidade,

falta de pessoal e indisponibilidade de

pessoas chaves.

3,2 3,8 4,0 4,2 12,0 38,0

12 Inadequada preparação e realização dos

testes. Ex.: instalações inadequadas, e tempo

insuficiente para realização dos testes, falta

de dados precisos para testar as mudanças e


3,3 3,3 3,5 3,7 10,5 35,0

7 Alto nível de complexibilidade técnica. 3,0 3,8 3,8 3,7 11,3 34,0

42 Pressão excessiva de prazo. 3,2 3,3 3,5 3,7 10,5 33,3

34 Erro ao estimar (tempo, custo e esforço). 3,3 3,8 2,2 3,8 9,8 32,8

5 Adição de mais funcionalidades que o

especificado / dar extras ao cliente. 3,2 3,7 2,8 3,8 10,3 32,7

22 Planejamento inapropriado, incluindo

construção e atualização do plano de

contingência.

3,2 3,5 3,2 3,7 10,3 32,7

41 Cronograma irreal ou inadequado baseado

nos eventos internos e externos do sistema. 3,2 3,3 2,7 4,2 10,2 32,2

2 Requisitos incompletos. 3,5 3,2 3,0 3,0 9,2 32,1

3 Requisitos não claros (ambíguos /

imprecisos). 3,3 3,2 3,0 3,0 9,2 30,6

45 Instabilidade (rotatividade) e falta de

continuidade das pessoas nos projetos. 2,7 3,7 3,5 4,0 11,2 29,8

4 Requisitos mal entendidos (não refletem as

expectativas do cliente). 3,2 3,0 3,2 3,0 9,2 29,0

14 Inadequadas especificações. Ex.:

especificações de sistema, hardware,

software, interface, requisitos de teste a

qualquer nível com respeito à viabilidade de

implementação e à estabilidade dos atributos

de qualidade, completeza e clareza.

2,7 3,7 3,3 3,8 10,8 28,9

40 Baixa produtividade da equipe. 2,7 3,8 3,0 4,0 10,8 28,9

13 Falta de um acordo interativo entre os

clientes e os desenvolvedores relativo às

especificações dos requisitos. 2,7 3,3 3,3 3,8 10,5 28,0

17 Controle do produto inadequado. Ex.: o

produto final não corresponde às

expectativas do cliente.

2,7 3,3 3,7 3,3 10,3 27,6

50 Qualquer problema com o usuário, tais

como: falta de envolvimento /

comprometimento, conflito entre usuários e

departamentos, falta de entendimento com

relação ao funcionamento do sistema,

resistência a mudanças e falha em obter o


2,8 3,0 3,0 3,3 9,3 26,4

6 Requisitos de desempenho não atendidos.

Ex. Baixo desempenho. 2,7 3,3 3,5 3,0 9,8 26,2


125




31 Falta de procedimentos, programas

adequados e recursos para assegurar a

garantia da qualidade.

2,7 3,3 3,0 3,5 9,8 26,2

46 Qualquer problema com o cliente, tais como:


comunicação pobre, resistência à mudança,

falta de comprometimento, falta de

cooperação, conflitos entre clientes e

departamentos, dependência técnica.

2,8 2,8 2,8 3,2 8,8 25,0

11 Tecnologia nova / imatura (uso de novas

tecnologias) 2,7 3,3 2,8 3,2 9,3 24,9

24 Gerentes do desenvolvimento do software

inexperientes ou ineficientes. 2,3 3,5 3,2 4,0 10,7 24,9

29 Fraco monitoramento do progresso das

atividades relacionadas ao projeto. Ex.:

acompanhamento do relatório de status e


3,0 2,7 2,3 3,2 8,2 24,5

35 Métricas inadequadas / inexatas. 2,8 3,2 2,2 3,2 8,5 24,1

26 Falhas em gerenciar as expectativas do

usuário final. 2,7 2,8 3,0 3,0 8,8 23,6

32 Gerência de Configuração inadequada. 2,7 2,7 3,0 3,0 8,7 23,1

49 Fatores políticos (companhia, clientes,

contratantes associados e subcontratantes)

que causam problemas para o

desenvolvimento do projeto.

2,8 2,7 2,5 2,8 8,0 22,7

38 Baixa moral/ falta de compromisso devido

ao baixo nível de entusiasmo afetando assim

a produtividade e criatividade. As pessoas

não se sentem reconhecidas e

recompensadas pelos superiores.

2,5 2,5 3,2 3,0 8,7 21,7

39 Falta de maturidade / instabilidade

organizacional. 2,5 2,8 2,8 2,8 8,5 21,3

20 Pouca confiança no desenvolvimento do

sistema devido à indisponibilidade / erro /

mal funcionamento dos componentes. 2,2 3,2 3,5 3,0 9,7 20,9

9 Problemas de desempenho de tempo real (há

tempos de respostas restritos). 2,2 3,2 3,3 3,0 9,5 20,6

30 Treinamento inadequado ou indisponível. 2,5 2,8 2,5 2,8 8,2 20,4

44 Orçamento é insuficiente ou instável

baseado nos eventos internos e externos do

sistema.

2,5 2,8 2,7 2,7 8,2 20,4

15 Modelos, processos, métodos e ferramentas

de apoio selecionados são inadequados para

o processo de desenvolvimento. 2,3 2,7 2,8 3,2 8,7 20,2


126




28 Falta de metodologia efetiva de

gerenciamento de projetos. 2,5 2,5 2,5 3,0 8,0 20,0

27 Ausência de um líder. 2,0 3,2 3,5 3,0 9,7 19,3

16 Falta / insuficiência de controle do processo

de desenvolvimento. Ex.: uso do recurso,

medição do progresso referente à qualidade

e metas de produtividade.

2,5 2,7 2,5 2,5 7,7 19,2

47 Problemas relacionados aos contratos

associados. 2,3 2,7 2,0 2,7 7,3 17,1

8 Desenvolvimento de interface do usuário

inadequada. 2,0 2,7 3,3 2,5 8,5 17,0

18 Documentação / papelada excessiva. 2,2 2,5 2,3 2,8 7,7 16,6

19 Capacidade insuficiente do sistema

desenvolvido. Ex.: Falta de estações de

trabalho, espaço de armazenamento no

banco de dados insuficiente.

1,8 3,3 2,7 3,0 9,0 16,5

36 Falta espírito de equipe. Os conflitos

requerem intervenção da gerência. 2,3 2,2 2,2 2,7 7,0 16,3

10 Restrições referentes ao hardware

designado. Ex.: capacidade de memória e

tempo de resposta real, acesso à base de

dados e insuficiência de hardware.

2,0 2,7 2,5 2,7 7,8 15,7

25 Fraca interação (comunicação) do gerente

com todos os envolvidos do projeto. 1,8 2,8 2,7 2,8 8,3 15,3

23 Os papéis e as responsabilidades de

relacionamentos mal definidos ou mal

entendidos.

2,0 2,3 2,5 2,7 7,5 15,0

21 Pobre suporte ao sistema. Ex.: treinamento

para utilização do sistema, acesso para

usuários especialistas ou consultores,

conserto ou resolução de problemas por

parte dos vendedores.

1,8 2,7 2,8 2,3 7,8 14,4

37 Problema de comunicação devido à falta de

conhecimento da missão, metas do projeto,

informações técnicas entre pares e gerentes e

devido a distância (membros da equipe

espalhados por todo o pais).

1,8 2,3 2,3 2,5 7,2 13,1

51 Falta de comprometimento da gerência

sênior 1,3 2,3 2,2 2,5 7,0 9,3

48 Qualquer problema associado a

subcontratação. 1,7 2,0 1,3 2,0 5,3 8,9

52 Qualquer problema de comunicação em

nível internacional relativo a diferenças de

idiomas.

1,2 1,5 1,2 1,3 4,0 4,7


127

4.6 Qualidade das informações obtidas

Neste item serão abordados alguns fatos verificados durante as entrevistas relacionados

à qualidade das informações obtidas.

Nenhuma das empresas pesquisadas fornecem cópias de documentos referente às

questões abordadas durante as entrevistas. Isso já era esperado a partir do momento que as

mesmas solicitaram para não serem identificadas, ou seja, manter o sigilo de sua identidade.

Apesar de não ser possível identificar as empresas pesquisadas, tal fato teve como

vantagem a transparência e sinceridade nas respostas durante a entrevista. Isto foi verificado

através da solicitação de que as empresas mostrassem os documentos relacionados às questões

abordadas na pesquisa, como por exemplo: metodologia de gerenciamento de projetos,

metodologia de gerenciamento de riscos, softwares / ferramentas utilizadas etc. A partir daí

foi possível confirmar a transparência das repostas.

Durante a entrevista, a empresa “A” informou não possuir uma metodologia de riscos

implantada, porém o entrevistado informou que utiliza o gerenciamento de riscos

informalmente, em seus projetos.

Na entrevista com a empresa “B”, verificou-se que esta possui uma metodologia de

riscos implantada. O entrevistado informou que não poderia fornecer documentos, porém

apresentou a metodologia e as ferramentas (softwares) utilizados para acompanhar os

projetos, os indicadores de custo e prazo. Apresentou, também, todo o processo e seus

procedimentos para gerenciamento de riscos.

A empresa “C” conforme verificado, possui uma metodologia de gerenciamento de

projeto baseada nos métodos ágeis. Durante a entrevista foi apresentado o software utilizado

(Ice Scrum 2) para acompanhamento dos projetos, porém não possui uma equipe devidamente

capacitada para o uso pleno do mesmo.

A empresa “D” utiliza-se de uma metodologia de gerenciamento de projetos de

desenvolvimento de software baseada no CMMI e no PMBoK. Um fato importante é que,

apesar da necessidade, esta não gerencia riscos em seus próprios projetos. Tal ocorrência se

deve, segundo o entrevistado, à dificuldade para gerenciar, acompanhar e atualizar os dados

referentes aos riscos.

A empresa “E” apresentou uma metodologia de gerenciamento de projetos baseada no

PMBoK e no SCRUM. E, assim como a empresa “D”, também não gerencia riscos. Tal fato

se deve, segundo o entrevistado, à falta de conhecimento ou de uma metodologia adequada

para o gerenciamento de riscos e à dificuldade em identificar os riscos potenciais dos seus

128

projetos. Durante a entrevista com esta empresa foi sugerida uma alteração no roteiro de

análise de riscos relacionada à questão 07, para que a mesma passasse a ser de múltipla

escolha. Tal sugestão foi acatada, permitindo a resposta pelo entrevistado.

A empresa “F” também apresentou uma metodologia de gerenciamento de projetos. Das

empresas pesquisadas foi a que apresentou a maior maturidade/experiência em gerenciamento

de riscos. Nesta, inclusive, se encontra em desenvolvimento uma ferramenta própria de

Business Intelligence (BI)22

para coleta de indicadores de riscos em seus projetos. O

entrevistado informou que, embora não pudesse fornecer o projeto documentado, este

apresentou a metodologia e as ferramentas (softwares) utilizadas para o gerenciamento dos

projetos. Das empresas entrevistadas, foi a única que demonstrou utilizar uma fase a mais no

ciclo de vida dos projetos. Após o encerramento do projeto, faz-se, conforme apresentado, a

avaliação do mesmo, a partir daí, retiram-se aprendizados para os próximos projetos.

Com relação ao roteiro de análise de riscos foi proposital o que parece ser uma

“possível inconsistência” entre as questão 32 (a empresa utiliza algum método para identificar

riscos) e a questão 33 (qual método a empresa utiliza para identificar riscos), caso a empresa

respondesse “não” na questão 32 e passasse a responder a questão 33. Isto permitiria saber

quais métodos eram utilizados. Tal fato tornou possível constatar que apesar de algumas

empresas não utilizarem um método formal para identificar riscos em seus projetos elas

utilizavam algumas métodos, mesmo que intuitivamente, para a identificação de riscos. Isso

pode ser verificado também pelas respostas da questão 26 (abordagem da empresa para

gerenciamento de riscos) quando foram informados, por algumas empresas, que realizavam o

gerenciamento de riscos informalmente.

É importante ressaltar que, mesmo tratando de dados não generalizáveis, por questões

de amostra, é possível uma aplicação prática em outras empresas, o que exigirá, certamente,

adequações e adaptações.

4.7 Síntese dos Resultados

Neste Capítulo serão apresentados os resultados, relacionados à análise das informações

da pesquisa de campo, contendo o perfil dos entrevistados, o perfil das empresas pesquisadas,

22

É o nome que se dá a uma vasta categoria de programas aplicativos e tecnologias usadas para extrair,

armazenar, analisar e transformar grandes volumes de dados, produzindo conhecimento capaz de auxiliar a

empresa a tomar as melhores decisões nos negócios. É análise de dados presentes e passados (Glossário de TI,

2009).

129

os processos/abordagens adotados para gerenciamento de riscos, os principais

problemas/dificuldades para gerenciar riscos, a análise dos fatores de riscos (quanto às fases

do ciclo de vida do projeto, quanto às categorias de riscos e quanto ao grau de exposição dos

fatores de riscos) e à qualidade das informações obtidas na pesquisa.

Verificou-se que todas as empresas pesquisadas utilizam algum método para

identificação de riscos. Identificam tanto os riscos internos quanto os riscos externos ao

projeto. Todos os métodos adotados estão de acordo com os métodos citados no Capítulo 2

deste trabalho.

Os principais problemas/dificuldades, enfrentados pelas empresas pesquisadas, para

gerenciar riscos estão associados, em sua maioria, à falta de gerenciamento de riscos baseado

em uma metodologia. Mesmo as empresas que têm uma metodologia de riscos possuem

algumas dificuldades como monitorar riscos em projetos onde a equipe está distribuída em

diversas cidades, manter uma base de dados atualizada sobre os riscos do projeto, falta de

priorização de tempo no decorrer do projeto para gerenciar os riscos, falta de

maturidade/cultura interna de análise de riscos etc.

Com relação a análise dos fatores de riscos quanto às fases do ciclo de vida do projeto,

não há um consenso entre as empresas. Isso pode ter ocorrido em virtude de diversos fatores

como diversidade de projetos, cultura das empresas, além de outros.

Os fatores de riscos foram classificados quanto às categorias de riscos de

desenvolvimento de software proposta pelo SEI (CARR, et al., 1993) e divididos em riscos

técnicos, riscos metodológicos e riscos organizacionais.

Nos fatores de riscos que foram relacionados na pesquisa de campo, foi possível

constatar as mesmas causas de fracasso anunciadas por Archibald & Prado 2008 (Gráfico 11),

ou seja, mudança de escopo, falta de comprometimento das áreas, prazos inexeqüíveis, riscos

não gerenciados, capacidade gerencial dos GP‟s insuficiente, falta de comprometimento da

alta administração, precariedade de metodologia de GP e habilidade técnica insuficiente).

No quesito sobre a qualidade das informações obtidas durante as entrevistas, nenhuma

das empresas pesquisadas fornecem cópia de documentos abordados durante a entrevista. Tal

fato teve como vantagem a transparência e sinceridade nas respostas. Isto foi verificado

quando as empresas apresentaram a metodologia utilizada para gerenciamento de projetos, a

metodologia de gerenciamento de riscos e os softwares/ferramentas utilizados.

130

5 PROPOSTA DE UM MÉTODO ÁGIL DE IDENTIFICAÇÃO DE RISCOS

A presente proposta partiu do estudo de diversos padrões de conhecimento e

metodologias de gerenciamento de projetos, tanto de métodos “tradicionais” quanto de

métodos ágeis, conforme apresentado no item 2.1 deste trabalho.

Foram estudados também os processos de gerenciamento de riscos destes métodos, (ver

item 2.2), o que nos possibilitou conhecer alguns modelos de gestão de riscos em projetos de

desenvolvimento de software, apresentados no item 2.3 deste trabalho.

Após ter estudado os métodos de gerenciamento de projeto, os processos de

gerenciamento de riscos e modelos de gestão de riscos, passou-se ao estudo dos métodos

utilizados para a identificação de riscos, conforme apresentado aqui no item 2.4.

Ao concluir os estudos citados, após a pesquisa de campo, foi possível conhecer a

realidade de algumas empresas, segundo a amostra estabelecida, o que permitiu observar, na

prática, como estas empresas utilizam tanto métodos “tradicionais” como métodos ágeis para

gerenciamento de projetos e de riscos.

A partir de então, foi elaborada uma proposta de um método ágil para identificação de

riscos em projetos de desenvolvimento de software, alinhando os conhecimentos dos métodos

“tradicionais” e dos métodos ágeis, conforme apresentado na Figura 27.

Figura 27: Esquema de um método ágil de identificação de riscos. Fonte: Elaboração do autor.

A seguir será apresentada a descrição das etapas constantes da Figura 27, sendo elas: (1)

preparação inicial, (2) lista de fatores de riscos, (3) fatores de riscos selecionados, (4) novos

fatores de riscos, (5) atualização da lista de fatores de riscos e (6) lições aprendidas.

131

1. Preparação inicial: Nesta etapa é feito o levantamento das partes envolvidas no

projeto e a seleção daquelas que irão participar deste processo de identificação de

riscos; é onde se procura rever em qual fase o projeto se encontra; e, rever os

objetivos do projeto e/ou da fase em desenvolvimento. Se houver necessidade,

deverá ser realizado um treinamento/preparo da equipe para identificação de riscos

do projeto. Esse pode ser um curso, uma palestra ou apenas uma explicação sobre

o método a ser utilizado para identificar riscos. A escolha do tipo de treinamento

dependerá da experiência/conhecimento da equipe ou da natureza do projeto.

2. Lista de fatores de riscos: A proposta, nesta etapa, é utilizar uma lista de riscos

definida antecipadamente. Caso a empresa não possua tal lista em sua base

histórica de projeto, sugerimos começar pela lista de riscos elaborada nesta

dissertação. Esta lista de fatores de riscos integrados para desenvolvimento de

software, foi elaborada a partir do estudo de diversos autores (ver Apêndice III -

Tabela 38). Ela pode ser classificada por fases do ciclo de vida do projeto (PMI,

2008)23

ou por categorias de riscos propostas pelo SEI (Tabela 16) (Carr et al.,

1993). No Apêndice V é apresentada uma classificação dos fatores de riscos de

acordo com as fases do ciclo de vida de projetos, segundo as empresas

pesquisadas. A classificação desses fatores por categorias de riscos, pode ser vista

na Tabela 26. Caso a empresa utilize alguma metodologia de gerência de projetos

que não contemple as fases propostas aqui pelo PMI (2008), as tabelas contidas no

Apêndice V podem ser adaptada à realidade da empresa. Por exemplo a empresa

pode adaptar esta tabela por Sprint (se utilizar método ágil de gerenciamento de

projetos), por outras fases, ou ainda por categorias de riscos. O importante é a

utilização desta lista de fatores de riscos e que eles sejam sempre atualizados

conforme o uso nos projetos da empresa.

3. Fatores de riscos selecionados: É nessa etapa que é feita a seleção dos fatores de

riscos, conforme a fase do ciclo de vida em que o projeto se encontra. Estes serão

analisados pela equipe na fase seguinte.

4. Novos fatores de riscos: Nesta etapa é necessário reunir com a equipe para

verificar se os riscos selecionados na etapa anterior estão de acordo com a fase em

que o projeto se encontra atualmente, conforme definido na etapa 1 deste método.

23

Todas as empresas pesquisadas utilizavam as mesmas fases para gerenciamento de seus projetos, seguindo a

proposta contida no PMBoK (PMI, 2008).

132

Caso haja necessidade, a equipe identifica novos riscos, não para o projeto como

um todo, e sim para a fase do projeto em análise. Pode utilizar para isso os

diversos métodos para identificação de riscos apresentados no item 2.4 deste

trabalho.

5. Atualização da lista de fatores de riscos: Nesta etapa, caso ocorra alguma

modificação na lista de riscos proposta inicialmente (etapa 3) ou a identificação de

novos riscos para o projeto (etapa 4), deverá ser feita a atualização da lista (etapa

2) e, consequentemente, dos riscos selecionados para a etapa 3. Isso se torna

necessário para que a empresa tenha sempre uma lista de riscos atualizada.

6. Lições aprendidas: Nesta etapa realizam-se os registros de lições aprendidas nas

etapas anteriores. Tais lições consistem basicamente no registro de respostas a três

perguntas bem simples: (a) o que foi bom e deve-se continuar utilizando; (b) o que

não foi bom e não se deve utilizar mais; e, (c) o que deve ser melhorado.

Esta proposta de um método ágil para identificação de riscos em projetos de

desenvolvimento de software foi apresentada a três profissionais com larga experiência em

utilização das práticas de gerenciamento de projetos tanto do PMBoK quanto do SCRUM.

Esses profissionais são pertencentes às empresas “E e F” deste trabalho e o método proposto

foi apresentado após a realização da pesquisa. Em síntese estes profissionais experientes

apresentaram as seguintes considerações:

Acharam a proposta muito interessante e inovadora na forma apresentada24

;

Que esta abordagem pode ser utilizada para agilizar a identificação de riscos e,

dependendo da metodologia adotada pelas empresas, para o gerenciamento de

seus projetos (incluindo o gerenciamento de riscos); o método proposto pode ser

facilmente adaptado à realidade das empresas.

24

Todos estes profissionais solicitaram uma cópia do trabalho após a sua conclusão.

133

CONCLUSÃO

Este trabalho propôs realizar uma investigação sobre gerenciamento de riscos e

apresentar uma proposta de um método ágil para identificação deles em projetos de

desenvolvimento de software. Para isso foram definidos oito objetivos específicos. Os cinco

primeiros foram abordados por meio do levantamento teórico, o sexto e sétimo por uma

pesquisa de campo e, o último objetivo específico, utilizou-se tanto do levantamento teórico

quanto da pesquisa de campo para ser atendido.

No levantamento teórico foi apresentada uma visão geral dos padrões de conhecimento,

normas e métodos de gerenciamento de projetos divididos em “tradicionais” e ágeis. A partir

daí foram apresentados os processos de gestão de riscos para os métodos “tradicionais” e

ágeis como também algumas normas e métodos específicos da área de TI que abordam a

gestão de riscos em projetos de desenvolvimento de software. Logo após foram descritos

alguns métodos utilizados para a identificação de riscos em projetos, com levantamento e

identificação de 52 fatores de riscos para projetos de desenvolvimento de software, que

serviram como subsídio para o roteiro de análise de riscos.

Para a pesquisa de campo foi adotado o método de estudo de caso múltiplo realizado em

seis empresas. Este estudo de caso permitiu avaliar como as empresas participantes do estudo,

identificam e tratam os riscos em seus projetos e, a partir das respostas, propor uma

priorização de riscos para projetos de desenvolvimento de software.

O método ágil proposto para identificação de riscos em projetos de desenvolvimento de

software, apresentado neste trabalho, mostra que é possível adotar uma abordagem ágil para

tal fim.

Este estudo permitiu por meio de investigação teórica e de pesquisa de campo levar um

conjunto de contribuições a todos aqueles (profissionais liberais, empresas, comunidades do

terceiro setor, governo etc.) que desejem conhecer e melhorar seus processos de

gerenciamento de projetos e em especial o gerenciamento de riscos em projetos de


As principais contribuições deste trabalho, suas limitações de pesquisa e as sugestões

para trabalhos futuros estão descritas a seguir.

134

Contribuições

As principais contribuições desse estudo são:

Identificação, por meio de investigação teórica, de padrões de conhecimento e

métodos de gerenciamento de projetos “tradicionais” e ágeis, seus processos e

ciclos de vida. Essa identificação e caracterização podem ser utilizadas por

gerentes de projetos.

Apresentação de um conjunto de processos tanto dos métodos “tradicionais”

quanto dos métodos ágeis de gerenciamento de projetos e gerenciamento de

riscos. Esse conjunto de processos teve como finalidade fornecer informações

sobre os diversos processos para gerenciamento de projetos.

Identificação e apresentação de modelos de gestão de riscos em projetos de


Levantamento de diversos métodos para identificação de riscos. Esse

levantamento serve como orientação para quem desejar utilizar algum método já

conhecido para identificação de riscos em seus projetos.

Uma revisão, análise e compilação de fatores de riscos para desenvolvimento de

software, segundo diversos autores da área, relacionando-os em uma lista de 52

itens que poderá ser utilizada no processo de identificação de riscos.

Um questionário detalhado que permite coletar informações importantes sobre

as abordagens adotadas, por empresas de desenvolvimento de software, para

gerenciamento de riscos em projetos, em termos das práticas adotadas pelas

empresas pesquisadas. Apesar de ter se restringido a apenas seis casos, trata-se

de empresas de referência/líderes em seu campo de atuação.

Elaboração da proposta de um método ágil para identificação de riscos em

projetos de desenvolvimento de software.

Limitações da pesquisa

O presente trabalho apresentou algumas limitações descritas a seguir:

A pesquisa, restringiu-se a apenas seis casos, apesar de tratar-se de empresas de

referência/líderes em seu campo de atuação, não permite generalização para

outras empresas.

135

Houve dificuldade de conseguir autorização para a realização de pesquisa dentro

das empresas, por se tratar de relato da forma como as empresas gerenciam

riscos, podendo revelar seus problemas e fragilidades.

Trabalhos futuros

Para dar continuidade a este estudo, poderão ser realizados os seguintes trabalhos

futuros:

Ampliação da amostra pesquisada de tal forma que se consiga uma amostra

representativa, em termos quantitativos, e que permita a realização de cálculos

estatísticos e a generalização de seus resultados para outras empresas.

Aplicação do método proposto em projetos reais, durante o seu

desenvolvimento/gerenciamento, tanto em empresas que utilizam métodos

“tradicionais” quanto em empresas que utilizam métodos ágeis para

gerenciamento de seus projetos.

Avaliação após a aplicação do método em empresas reais dos aspectos positivos

e negativos.

Automação de um sistema de informação para dar feedback na base de dados de

risco para ser mais assertivo na fase de planejamento (melhoria contínua) de


Verificação no mercado da existência de ferramentas que auxiliem na

identificação de riscos em projetos de desenvolvimento de software.

136

REFERÊNCIAS

A Comparison of PRINCE2 Against PMBOK. Publicado em 24 jan. 2002. Disponível em:

<http://www.bligoo.com/media/users/1/50369/files/4363/A%20comparison%20of%20Prince

%202%20vs%20PMBOK.pdf>. Acesso em 07 dez. 2010. Disponível também em:

<http://www.scribd.com/doc/36166632/Pmbok-vs-Prince2-Detail>. Acesso em: 10 dez. 2010.

ADAMS, John. Risco. 1. ed. São Paulo: Senac, 2009.

ADDISON, Tom; VALLABH, Seema. Controlling Software Project Risks – an Empirical

Study of Methods used by Experienced Project Managers. Proceedings of SAICSIT, p.128-

140, Republic of South Africa, 2002. South African Institute for Computer Scientists and

Information Technologists. ISNM:1-58113-596-3.

ADLER, Terry. R.; LEONARD, John. G.; NORDGREN, Ric. K.. Improving Risk

Management: Moving from Risk Elimination to Risk Avoidance. Technovation, Elsevier

Science, 1998.

ANGELO, Adalcir da Silva. Artigo: Entendendo o PRINCE2. Revista Mundo PM, abr/mai.

2008. Disponível em: <http://www.mundopm.com.br/noticia.jsp?id=264>. Acesso em: 08 jul.

2010.

ARAUJO, Camila de. Softwares de apoio ao gerenciamento ágil de projetos colaborativos

de novos produtos: análise teórica e identificação de requisitos. Dissertação mestrado,

2008. Escola de engenharia de São Carlos, Universidade de São Paulo, Mestrado em

Engenharia de Produção, São Carlos: 2008.

BENASSI, João Luís Guilherme. Avaliação de modelos e proposta de método para

representação da visão do produto na gestão ágil de projetos. Dissertação de Mestrado,

2009. Escola de Engenharia de São Carlos, Universidade de São Paulo, Mestrado em

Engenharia de Produção. área de concentração: “Processos e Gestão de Operações”, São

Carlos: 2009.

BOEHM, B. W. “Software Risk Management Principles and Practices”. IEEE Software,

vol. 8, no. 1, Jan. 1991, pp. 32-41.

BRAGA, R. M.; WERNER, C. M. L.; MATTOSO, M. Odyssey: A Reuse Enviroment Based

on Domain Models. In: 2nd IEEE Symposium on Application Specific Systems and Software

Engineering Technology (ASSET’99), Richardson, USA, 1999, p. 49-57.

BRASIL. Ministério da Integração Nacional. Plano Estratégico de Desenvolvimento do

Centro-Oeste (2007-2020). [S.l: s.n.], [200?], 223p.

CAIXETA, Marcelo. Como gerenciar projetos de forma prática: Guia básico. 1. ed.

Goiania: Vieira, 2006.

CAMARA, Fábio. SCRUM: Uma metodologia ágil. Publicado em: 17 nov. 2008.

Disponível em:

137

<http://imasters.uol.com.br/artigo/10699/gerencia/scrum_uma_metodologia_agil>. Acesso

em: abr. 2010.

CARR, Marvin. J.; KONDA, Suresh. L., MONARCH, Ira.; ULRICH, F. Carol.; WALKER,

Clay. F. Taxonomy-Based Risk Identification. Pittsburgh, Pennsylvania: Software

Engineering Institute, Carnegie Mellon University, june 1993. Technical report CMU/SEI-

93-TR-6.

CONFORTO, Edivandro Carlos. Gerenciamento ágil de projetos: proposta e avaliação de

método para gestão de escopo e tempo. Dissertação de Mestrado, 2009. Escola de

Engenharia de São Carlos, Universidade de São Paulo, Mestrado em Engenharia de Produção,

área de concentração: “Processos e Gestão de Operações”, São Carlos: 2009

CONTI, Henrique César de. Análise da cadeia produtiva de serviços em tecnologia da

informação: oportunidades de negócios e inovação. 2006. p. 12-13. Dissertação - FGV

Management, Fundação Getúlio Vargas, Brasília, DF, 2006. Disponível em:

<http://ce.desenvolvimento.gov.br/software/paper>. Acesso em: 20 mai. 2010.

COSTA, Fernando. Agilidade: SCRUM e XP-eXtreme Programming. Publicado em: 29 nov.

2008. Disponível em: <http://www.fernandocosta.com.br/arquivos/Agilidade-Scrum-

XP.pdf>. Acesso em: 17 dez. 2010.

CROUHY, Michel; GALAI, Dan; GALAI, Robert. Fundamentos da Gestão de Risco. 1. ed.

[S.L.]: Qualitymark, 2008.

DEMARCO, Tom; LISTER, Timothy Waltzing with Bears: Magaging Risk on Software

Projects. New York, NY: Dorset House Publishing, Co., Inc., 2003.

DIAS, Marisa Villas Bôas; SOLER, Alonso Mazini. AGILE PROJECT MANAGEMENT:

Um Novo Enfoque para o Gerenciamento de Projetos de Desenvolvimento de Sistemas

de Tecnologia de Informação. Revista Mundo PM - ano 1 – n. 04. ago-set. 2005.

DSDM CONSORTIUM 2010. Introduction to DSDM. DSDM Public Version 4.2. Disponível

em: <http://www.dsdm.org/version4/2/public/site_map.asp>. Acesso em 16 dez. 2010.

FARIAS, Luciana. Planejamento de Riscos em Ambientes de Desenvolvimento de

Software Orientados à Organização. Dissertação. Programa de Pós-graduação em

Engenharia de Sistemas e Computação, Universidade Federal do Rio de Janeiro: 2002.

FONTOURA, Lizandra M.; PRICE, Roberto T.. Usando GQM para Gerenciar Riscos em

Projetos de Software. 18º Simpósio Brasileiro de Engenharia de Software. p-39-54, 2004.

GIUFFRA, C. E. ; VILAIN, P.. Modelagem da Interação do Usuário no Desenvolvimento

Ágil. In: V SULCOMP - V Congresso Sul Brasileiro de Computação, 2010, Criciúma. Anais

V SULCOMP, 2010. Criciúma: 2010.

GALLAGHER, Brian P.; CASE, Pamela J.; CREEL, Rita C.; KUSHNER, Susan;

WILLIAMS, Ray C. A Taxonomy of Operational Risks. Pittsburgh, Pennsylvania: Software

Engineering Institute, Carnegie Mellon University, September 2005. Technical report

CMU/SEI-2005-TN-036.

138

GLOSSÁRIO DE TI. Academia de Governança. Publicado em: junho 2009. Disponível em:

<http://www.academiadegovernanca.com.br/site/glossario.pdf> . Acesso em: 09 fev. 2010.

GUSMÃO, C. M. G. Um Modelo de Processo de Gestão de Riscos para Ambientes de

Múltiplos Projetos de Desenvolvimento de Software. Tese de Doutorado, Universidade

Federal de Pernambuco, Recife, 2007.

GUSMÃO, C. M. G. ; MOURA, H. P. . Gerência de Risco em Processos de Qualidade de

Software: uma Análise Comparativa. In: Simpósio Brasileiro de Qualidade de Software,

2004, Brasília - DF. III Simpósio Brasileiro de Qualidade de Software. Brasília - DF :

Universidade Católica de Brasília - UCB, 2004. p. 1-398.

GUSMÃO, C. M. G. ; MOURA, H. P. . Gestão de Riscos para Ambientes de Múltiplos

Projetos de Software: Teoria e Prática. In: IV Escola Regional de Informática de Minas

Gerais - IV ERI MG, 2005, Belo Horizonte. IV IERI MG - Escola Regional de Informática de

Minas Gerais. Belo Horizonte : PUC Minas, 2005.

HADDAD, P.R.;FERREIRA, C.M. de C.; ANDRADE, T.A. Economia regional: teorias e

métodos de análise. Fortaleza: BNB/ETENE, 1989. 649p.

HAZRATI, Vikas. Managing Risk with Scrum. Publicado em: 29 jun. 2008. Disponível em:

<http://www.infoq.com/news/2008/07/managing-risk-with-

scrum;jsessionid=E6CFBDBF1C0B4D9A6C22E505F5D45C4D>. Acesso em: 16 dez. 2010.

HOUSTON, Dan X.; MACKULAK, Gerald T.; COLLOFELLO, James. S. Stochastic

Simulation of Risk Factor Potencial Effects for Software Development Risk Management.

Elsevier Science, p. 247-257, 2001.

HUNTER, Richard; WESTERMAN, George. O Risco de TI: Convertendo Ameaças aos

Negócios em Vantagem Competitiva. 1. ed. . [S.L.]: M.Books, 2008.

IBGE. Contagem da População 2007. Rio de Janeiro: 2007. Disponível em:

<http://www.ibge.gov.br/home/estatistica/populacao/contagem2007/default.shtm.>. Acesso

em: 22 mai. 2010.

IBGE. O Setor de Tecnologia da Informação e Comunicação no Brasil - 2003-2006. 1. ed.

Rio de Janeiro: 2009.

ISO/IEC 15504, 1999. ISO 15504 Software Process, ISO/IEC JTC1 SC7. International

Standard Organization – ISO/IEC.

JALOTE, Pankaj. CMMI in Practice: Processes for Executing Software Projects at Infosys.

Boston: Addison-Wesley, 2000. cap.8, p.159-174.

JUNIOR, Luiz Carlos Fraga e Silva (1); CHAMON, Marco Antonio (1); CAMARINI, Gladis

(2). Artigo: Gerenciamento de Risco em Projetos de Tecnologia da Informação. (1)

Universidade de Taubaté – UNITAU - Economia, Contabilidade e Administração - CEP:

12030-320 Taubaté/SP Brasil. (2) Universidade de Campinas – UNICAMP - Faculdade de

Engenharia Civil, Arquitetura e Urbanismo - Campinas/SP Brasil. REAd – 52 ed., Vol. 12, N°

4, jul-ago 2006.

http://www.academiadegovernanca.com.br/site/glossario.pdf

http://lattes.cnpq.br/9906166020816798

http://www.ibge.gov.br/home/estatistica/populacao/contagem2007/default.shtm

139

KEIL, Mark.; CULE, Paul. E.; LYYTINEN, Kalle.; SCHMIDT, Roy. C. A Framework for

Identifying Software Project Risks. ACM, p. 76-83, 1998.

KONTIO, J. The Riskit Method for Software Risk Management. Versão 1.00. Computer

Science Technical Reports, University of Maryland. College Park, MD, 1996, 45p.

KOSCHO William J.; RIES, William. Identifying and Proactively Managing Architecture

Risk. Vancouver, Canadá - 978-1-4244-3717-7/09, LMSA 09, May 19, 2009, © 2009 IEEE.

KWAK, Y. H; STODDARD, J.. Project Risk Management: Lessons Learned from Software

Development Environment. Technovation, Elsevier Science, 2003.

LEOPOLDINO Claudio. B. Avaliação de Riscos em Desenvolvimento de Software.

Dissertação de Mestrado. Programa de Pós-graduação em Administração, Universidade

Federal do Rio Grande do Sul. 2004.

LOPES, Peterson Luis Soares. Gerenciamento de Projetos Integrado – Gpi: Uma

Integração Entre Métodos Clássicos e Métodos Ágeis para Gerenciamento de Projetos

de Software. Ciência da Computação, Universidade Federal de Pelotas, Pelotas: 2008.

MACHADO, Cristina Ângela Filipak. A-Risk: Um método para identificar e quantificar

risco de prazo em projetos de desenvolvimento de software. Dissertação de Mestrado,

2002. Programa de Pós-Graduação em Informática Aplicada, Pontifícia Universidade Católica

do Paraná, Curitiba: 2002.

MAGALHÃES, Ana Liddy C. C. O Gerenciamento de Projetos de Software

Desenvolvidos à Luz das Metodologias Ágeis. 2004. Disponível em:

<http://www.mct.gov.br/upd_blob/0002/2539.pdf>. Acesso em: 17 dez. 2010.

MARÇAL, Ana Sofia, FREITAS, Bruno Celso C., FURTADO, Felipe, MACIEL, Teresa,

BELCHIOR, Arnaldo Dias. Estendendo o SCRUM segundo as Áreas de Processo de

Gerenciamento de Projetos do CMMI. Publicado em: CLEI 2007 - XXXIII Conferência

Latino americana de Informática, San Jose, Costa Rica. Disponível em:

<http://www.cesar.org.br/estendendo-o-scrum-segundo-as-areas-de-processo-de-

gerenciamento-de-projetos-do-cmmi/>. Acesso em 10 nov. 2010.

MCMANUS, John. Risk Management in Software Development Projects. Burlington, MA:

Elsevier Butterworth-Heinemann, 2004.

MENDONÇA, A. F.; ROCHA, C. R. R.; NUNES, H. P. Trabalhos Acadêmicos:

planejamento, execução e avaliação. Goiânia: Faculdades Alves Faria, 2008.

MIZUNO, Osamu.; KIKUNO, Tohru. Characterization of Risky Projects based on Project

Manager´s Evaluation. ACM, p.387-395, 2000.

MSF - MICROSOFT SOLUTIONS FRAMEWORK. Risk Management Process. Disponível

em: <http://www.microsoft.com/msf>. Acesso em: out. 2004.

MULCAHY, Rita. Preparatório para o exame de PMP. 5 ed. [S.l.]: RMC Publicações, Inc.,

2007.

140

MULCAHY, Rita. Risk Management: Tricks of the trade for project managers. 2. ed. EUA:

RMC Publications Inc, 2010.

NBR ISO 12207, 1998. ISO 12207 – Tecnologia de Informação – Processos de ciclo de

vida de software. Associação Brasileira de Normas Técnicas – ABNT. Rio de Janeiro.

NBR ISO 9001, 2000. ISO 9001 - Sistema de Gestão de Qualidade Requisitos. Associação

Brasileira de Normas Técnicas – ABNT. Rio de Janeiro.

NOYES, Brian. Rugby, Anyone? Scrum tackles software development from a patterns

perspective to turn around a fast product. Publicado em 28 jun. 2002. Disponível em:

<http://www.fawcette.com/resources/managingdev/methodologies/scrum/default.asp> Acesso

em: 14 dez. 2010.

OLIVEIRA, Gustavo da Costa. No-Risk - Um Processo para Aplicação de Gerência de

Risco de Projetos de Software Focados em Sistemas de Informação. Dissertação de

Mestrado, 2006. Programa de Pós-Graduação em Ciência da Computação, Faculdade de

Informática, Pontifícia Universidade Católica do Rio Grande do Sul. Porto Alegre: 2006.

OLIVEIRA, S. C. GeRis - Um Processo para Gerência de Risco em Projetos de Software.

Dissertação de Mestrado. PUCRS, Programa de Pós-Graduação em Ciência da Computação,

2005, 115p.

PAULK, M.. CMM - Capability Maturity Model for Software, version 1.1. Pittsburgh, PA.

Software Engineering Institute, Carnegie Mellon University. USA

PMAJ - Project Management Association of Japan. 2005. A Guidebook of Project &

Program Management for Enterprise Innovation. Volume I, Revision 3. October 2005 e

Volume II, Revision 1. October 2005, Translation by Shigenobu Ohara.

PMI – PROJECT MANAGEMENT INSTITUTE. 2000. Um Guia do Conjunto de

Conhecimentos do Gerenciamento de Projetos (Guia PMBOK®). Project Management

Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 EUA: 2000.

PMI - PROJECT MANAGEMENT INSTITUTE. 2008. Guia do Conjunto de Conhecimentos

em Gerenciamento de Projetos (Guia PMBOK®) 4. ed. Project Management Institute, Four

Campus Boulevard, Newtown Square, PA 19073-3299 EUA: 2008.

PMI - PROJECT MANAGEMENT INSTITUTE - CHAPTERS BRASILEIROS. Estudo de

Benchmarking em Gerenciamento de Projetos Brasil 2008. Relatório principal, p. 29 e 79,

Anexo 4, p. 61, dez. 2008.

PORTAL O GERENTE. Diagrama de Causa e Efeito. 27/04/2006. Disponível em:

<http://www.ogerente.com.br/qual/dt/qualidade-dt-diagrama_causa_efeito.htm>. Acesso em:

05 ago. 2010. Disponível também em:

<http://ogerente.com.br/novo/artigos_ler.php?canal=15&canallocal=47&canalsub2=151&id=

206> . Acesso em: 11 nov. 2010.

PRADO, Darci; ARCHIBALD, Russell. Pesquisa 2008: Maturidade e Sucesso em Projetos

e T.I. Disponível em: <www.maturityresearch.com>. Acesso em: 14 abr. 2010.

http://www.ogerente.com.br/qual/dt/qualidade-dt-diagrama_causa_efeito.htm

http://www.maturityresearch.com/

141

PRESSMAN, Roger. S. Engenharia de Software. 5 ed. Rio de Janeiro: McGraw-Hill, 2002.

cap.6, p.139-156.

PRESSMAN, Roger. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.

cap.4.

Preston, G; Pichler, Roman. Agile Risks, Agile Rewards. Publicado em: 01 abr. 2005.

Disponível em: <http://www.drdobbs.com/architecture-and-design/184415308>. Acesso em:

21 dez. 2010.

PRINCE2 ® Training - Managing a Project. Published by Silicon Beach Training at

Smashwords. Copyright 2010 Silicon Beach Training. Smashwords Edition, License Notes.

Disponível em: <http://www.smashwords.com/books/view/30140>. Acesso em: 10 dez. 2010

RIBEIRO, Lucio; GUSMÃO, Cristine. Definição de um Processo Ágil de Gestão de Riscos

em Ambientes de Múltiplos Projetos. Hífen, Uruguaiana, v.32 – n.62 – II Semestre – Ano

2008.

SCHWALBE, Kath. Information Technology Project Management. 2. ed. Boston, MA:

Thomson Learning, Inc., Thomson Place, 2002. cap.10, p.302-326.

SEI - SOFTWARE ENGINEERING INSTITUTE. CMMI - Capability Maturity Model

Integration. version 1.1. Pittsburgh, PA. Software Engineering Institute, Carnegie Mellon

University. USA.

SEI - SOFTWARE ENGINEERING INSTITUTE. Software Performance Institute. Pittsburgh.

Disponível em: <http://www.sei.cmu.edu>. Acesso em: out. 2004.

SIEGELAUB, Jay M.. How PRINCE2 Can Complement PMBOK and Your PMP. In:

Originally published as a part of 2004 PMI Global Congress Proceedings — Anaheim,

California: 2004.

SIMÕES, A. Lopes. Desenvolvimento Regional: Problemática, Teoria e modelos.

Fundação Calouste Golbenkian. Lisboa: [S.n.] 2003.

Sistema GLOSSÁRIOS®. Todos os direitos reservados pela Technologica Informática.

Publicado em: 23 dez 2010. Disponível em:

http://www.technologica.inf.br/glossario/exibepn.asp?Palavra=tecnologia+da+informa%E7%

E3o . Acesso em: 09 fev. 2011.

SOEIRO, Luis F. MIGRES – Método Integrado de Gerência em Engenharia de Software.

Dissertação de Mestrado, 1999. Programa de Pós Graduação Ciência da Computação, UNB,

Brasília: 1999.

SOUZA, E.C. de; GOMES, M.F.M.; LÍRIO, V.S. Análise locacional da produção vegetal

nas Mesorregiões Geográficas Paranaenses. REDES, Santa Cruz do Sul, v.12, n.3, p.58 -

73, set./dez. 2007.

STANDISH GROUP. Chaos Report 2009. Disponível em: <www.projectsmar.co.uk>.

Acesso em: 15 mai. 2010.

http://www.technologica.inf.br/glossario/exibepn.asp?Palavra=tecnologia+da+informa%E7%E3o

http://www.technologica.inf.br/glossario/exibepn.asp?Palavra=tecnologia+da+informa%E7%E3o

142

TEIXEIRA, Daniel Dinis; PIRES, Fernando Jorge Afonso; PINTO, José Pedro Gaiolas de

Sousa; SANTOS, Tiago Alexandre Gonçalves Pereira. DSDM – Dynamic Systems

Development Methodology. Faculdade de Engenharia da Universidade do Porto, 2006.

Disponível em: <http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_14.pdf>.

Acesso em: 16 dez. 2010.

VARGAS, Ricardo Viana. Gerenciamento de Projetos. 7. ed, [S.l.]: Brasport, 2009.

VICENTE, André Abe. Definição e gerenciamento de métricas de teste no contexto de

métodos ágeis. Dissertação de Mestrado, 2010. Instituto de Ciências Matemáticas e de

Computação, ICMC/USP, São Carlos: 2010.

WEBSTER, Kênia Pereira Batista. Riscos para Manutenção de Software: Taxonomia e

Priorização. Dissertação de Mestrado, 2005. Programa de pós-graduação em gestão do

conhecimento e tecnologia da informação. Brasília: 2005.

YIN, Robert K. Estudo de Caso: Planejamento e Métodos. Porto Alegre: Bookman, 2001.

YIN, Robert K. Estudo de Caso: Planejamento e Métodos. Porto Alegre: Bookman, 2005.

143

APÊNDICE I- Utilização do Quociente Locacional para Determinação da Região de

Análise da Dissertação25

.

Marcelo Caixeta26

Alcido Elenor Wander27

Resumo.

Este artigo trata de um estudo sobre medidas de localização de atividades, através da

aplicação do método do Quociente Locacional. Este método foi aplicado a partir de dados

obtidos na Pesquisa de Benchmarking sobre Gerenciamento de Projetos no Brasil – 2008,

mais especificamente sobre as abordagens adotadas pelas empresas para gerenciamento de

riscos em projetos. A partir da aplicação do método do Quociente Locacional foram

identificadas as regiões brasileiras que apresentavam maior concentração locacional da

utilização de método formal de gerenciamento de risco e selecionados os estados, dentro das

regiões identificadas, que também apresentavam maior concentração locacional da utilização

de método formal de gerenciamento de riscos. Feito isso identificaram-se os estados objetos

de pesquisa de dissertação sobre gerenciamento de riscos em projetos.

Abstract

This article is a study of measures of location of activities, by applying the location

quotient method. This method was applied to data from the Survey on Benchmarking Project

Management in Brazil - 2008, specifically on the approaches adopted by companies to

manage risk in projects. From the method of location quotients were identified Brazilian

regions with higher concentration of locational use of formal method of risk management and

selected states, within regions identified, which also had a higher concentration of locational

25

Artigo apresentado como exigência da disciplina Métodos e Técnicas de Análise do Desenvolvimento

Regional. 26

Mestrando em Desenvolvimento Regional turma 2010/1 das Faculdades Alves Faria e bolsista da FAPEG. 27

Engenheiro Agrônomo, Doutor em Economia Rural pela Georg-August-Universitat Gottingen (Alemanha).

Pesquisador da Empresa Brasileira de Pesquisa Agropecuária (Embrapa) e Professor do Programa de Pós-

graduação em Desenvolvimento Regional das Faculdades Alves Faria (Alfa).

144

use of formal method risk management. Done that identified the states of objects dissertation

research on risk management projects..

Palavras chave: Medidas de Localização das Atividades, Quociente Locacional,

Métodos e Técnicas de Análise do Desenvolvimento Regional, Gerenciamento de Risco.

Introdução

A abordagem para gerenciamento de riscos adotada pelas empresas que participaram da

Pesquisa de Benchmarking em Gerenciamento de Projetos no Brasil em 2008, no que diz

respeito à utilização de uma metodologia formal, estrutura por políticas, procedimentos e

formulários, não se desenvolveu de forma uniforme entre os estados brasileiros. Daí

resultaram diferentes padrões de localização da utilização dessa abordagem para

gerenciamento de riscos. Nesse contexto, surgem as perguntas:

Como as empresas que utilizam essa abordagem para gerenciamento de riscos

se distribuem no espaço?

Onde essas empresas se localizam, em quais regiões e estados brasileiros?

Qual região e estado apresenta maior concentração da prática dessa abordagem

para gerenciamento de riscos?

Qual deve ser o território de análise em pesquisa sobre gerenciamento de riscos

em projetos?

Respostas para estas perguntas podem ser obtidas com indicadores de

localização/concentração.

Neste artigo será utilizado o quociente locacional, no intuito de verificar as regiões e os

estados, dentro dessas regiões, que apresentam maior concentração de empresas que utilizam

a abordagem de gerenciamento de riscos em projetos, além da justificativa pela escolha dos

estados que serão objetos desta pesquisa.

A aplicação do quociente locacional será utilizando-se como referência o Estudo de

Benchmarking em Gerenciamento de Projetos no Brasil, realizada em 2008. Este Estudo de

Benchmarking inclui diversos temas sobre gerenciamento de projetos, mas para este artigo

interessa o tema referente à abordagem adotada pelas empresas brasileiras, com relação ao

gerenciamento de riscos em projetos, mais especificamente com relação às empresas que

145

gerenciam riscos baseando-se em uma metodologia formal, estruturada por políticas,

procedimentos e formulários.

1. Metodologia

Para a realização deste artigo utiliza-se o Estudo de Benchmarking em Gerenciamento

de Projetos no Brasil, para o ano de 2008. Esse estudo conta com a participação de 373

empresas abrangendo todas as regiões brasileiras.

Apesar de o Estudo de Benchmarking conter empresas de todas as regiões brasileiras o

mesmo não aconteceu com relação aos estados, não houve a participação de todos os estados

brasileiros.

Para o estudo a ser apresentado neste artigo, tendo como referência, os dados do Estudo

de Benchmarking em Gerenciamento de Projetos no Brasil, para o ano de 2008, adotam-se

alguns critérios: a) não serão considerados os estados que não participam da pesquisa, sendo

eles: Acre, Amapá, Maranhão, Paraíba, Piauí, Rio Grande do Norte, Rondônia, Roraima e

Tocantins; b) não serão considerados os estados com um índice de participação, no Estudo de

Benchmarking, inferior a 1%: Alagoas, Mato Grosso do Sul, Pará e Sergipe.

Por meio do método do quociente locacional, e para os estados selecionados no Estudo

de Benchmarking28

, serão identificados os estados que possuem maior concentração da

utilização da abordagem de gerenciamento de riscos em projetos.

No Estudo de Benchmarking em Gerenciamento de Projetos no Brasil, referente à

pergunta sobre as abordagens adotadas pelas empresas brasileiras para gerenciamento de

riscos em seus projetos apresentam-se três alternativas de respostas. São elas: (a) Não

tratamos riscos em projetos na nossa organização; (b) Realizamos informalmente, conforme

interesse ou necessidade do responsável pelo projeto; (c) Baseado em uma metodologia

formal, estruturada por políticas, procedimentos e formulários.

Neste artigo iremos analisar o quociente locacional para a alternativa “(c)”, ou seja,

iremos identificar quais regiões e estados brasileiros incidem maior concentração de empresas

que gerenciam riscos baseado em uma metodologia formal, estruturada por políticas,


28

Os estados selecionados foram os que apresentaram índice de participação no Estudo de Benchmarking em

gerenciamento de projetos, superior a 1%. Portanto os estados que serão objetos de estudo deste artigo são:

Bahia, Distrito Federal, Ceará, Goiás, Rio Grande do Sul, Santa Catarina, Mato Grosso, São Paulo, Rio de

Janeiro, Pernambuco, Amazonas, Paraná, Minas Gerais e Espírito Santo.

146

A medida de localização utilizada neste artigo será o quociente locacional e é descrita a

seguir, conforme apresentada por (Haddad, 1989 e Souza. et al., 2007). Os cálculos

organizam-se em duas matrizes de informações, sendo uma por região e outra por estado,

onde cada linha “j”29

mostra a região ou estado, a quantidade de empresas que participam da

pesquisa e a quantidade de empresas relacionadas a cada uma das alternativas de resposta

“i”17

da pergunta sobre qual abordagem adotada pelas empresas brasileiras para

gerenciamento de riscos em seus projetos.

Tabela 28: Matriz de Informações obtidas a partir do Estudo de Benchmarking em

Gerenciamento de Projetos no Brasil – 2008.


Quando são comparadas as características da distribuição espacial da variável “Eij30

”

que representa a quantidade de empresas que gerenciam riscos baseando-se em uma

metodologia formal, estrutura por políticas, procedimentos e formulários “i” para cada região

ou estado “j”, com características de distribuição espacial de uma variável de referência,

obtêm-se indicadores relativos de localização.

O quociente locacional (QL) busca expressar a importância comparativa das regiões ou

estados que gerenciam riscos baseando-se em uma metodologia formal, estruturada por

políticas, procedimentos e formulários “i” para um estado ou região “j” na qual está inserida.

Mais especificamente, ele busca traduzir “quantas vezes mais“ (ou menos) um estado ou

região “j”se dedica a essa atividade “i”. O QL da região ou estado “j” na atividade “i”

compara a contribuição relativa da atividade “i” para o valor total da variável no estado ou

29

Os itens “i”e “j” referem-se às colunas e linhas da Figura 1. 30

Quantidade de respostas da abordagem para gerenciamento de riscos “i” na região ou estado “j” (ver Tabela

29).

Região

ou

Estado

Alternativas de respostas da pergunta

TOTAL Não tratamos riscos

em projetos na nossa

organização

Realizado informalmente,

conforme interesse ou

necessidade do responsável

pelo projeto

Baseado em uma metodologia

formal, estruturada por

políticas, procedimentos e

formulários

TOTAL

i

j

147

região “j”, com a contribuição dessa mesma atividade para um agregado de referência.

Permite avaliar o nível de concentração relativa do estado ou região “j” na atividade “i”.

Interpretação: toma-se como valor de referência a unidade, caso em que a importância relativa

da atividade “i” no estado ou região “j” é igual à que aquela atividade detém no agregado de

referência.

A seguir serão apresentados o indicador, a equação e a interpretação dos resultados da

medida de localização:

Tabela 29: Identificação das variáveis utilizadas no QL dentro da Matriz de Informações

obtidas a partir do Estudo de Benchmarking em Gerenciamento de Projetos no Brasil – 2008


Indicador:

Quociente Locacional (QLij), ou seja, é o quociente locacional da abordagem

para gerenciamento de riscos “i” no estado ou região “j”.

Equação:

Eij

Xij = ----------------

∑j Eij

onde:

Eij = Quantidade de respostas da abordagem para gerenciamento de

riscos “i” na região ou estado “j”;

∑j Eij = Total de respostas das abordagens para gerenciamento de riscos

“i” na região ou estado “j”;

portanto: Xij = Distribuição percentual da abordagem “i” na região ou estado “j”.

Região

ou

Estado

Alternativas de respostas da pergunta

TOTAL Não tratamos riscos

em projetos na

nossa organização



necessidade do responsável

pelo projeto


formal, estruturada por

políticas, procedimentos e

formulários

Eij ∑j Eij

TOTAL ∑i Eij ∑i ∑j Eij

148

∑i Eij

Yij = ----------------

∑i ∑j Eij

onde:

∑i Eij = Respostas das abordagens para gerenciamento de riscos “i” para

todas as regiões ou estados “j”;

∑i ∑j Eij = Resposta de todas as abordagens para gerenciamento de riscos

“i” para todas as regiões ou estados “j”.

portanto: Yij = Distribuição percentual das abordagens “i” para todas as regiões

ou estados “j”.

Sendo, portanto o Quociente Locacional (QL) por região ou estado representado por:

Xij

QLij = ---------------

Yij

Interpretação dos Resultados:

QLij ≥ 1: Localização significativa, ou seja, maior concentração locacional de

empresas, por região ou estado, que utilizam uma metodologia formal de

gerenciamento de riscos;

QLij < 1: Localização fraca, ou seja, menor concentração locacional de

empresas, por região ou estado, que utilizam uma metodologia formal de


Para chegar ao resultado da medida de localização será aplicado o método do quociente

locacional segundo Haddad (1989) e Souza (et al., 2007). Para identificar os estados dentro

das regiões que possuem maior concentração locacional, serão realizados cálculos do QL em

duas etapas:

1ª Etapa: aplicação do método (Quociente locacional) por região. Com isso

pretende-se encontrar as regiões brasileiras que apresentam maior concentração

da utilização de uma metodologia formal de gerenciamento de riscos.

2ª Etapa: identificar, para as regiões selecionadas31

na 1ª Etapa, quais estados

apresentam maior concentração locacional da utilização de uma metodologia

formal de gerenciamento de riscos.

31

Regiões selecionadas são aquelas que apresentaram a maior concentração locacional, ou seja, QL ≥ 1.

149

Os estados identificados na 2ª Etapa representarão os estados potenciais para a escolha

do mais indicado para desenvolvimento da pesquisa sobre gerenciamento de riscos.

Portanto este artigo tem como objetivo identificar qual estado brasileiro apresenta maior

concentração da utilização de uma metodologia formal de gerenciamento de riscos e, ainda,

escolher qual(is) estado(s) de uma região será(ão) selecionado(s) para a elaboração de uma

pesquisa sobre gerenciamento de riscos.

2. Resultados

A partir dos dados obtidos no Estudo de Benchmarking em Gerenciamento de Projetos

no Brasil – 2008 é apresentada, na Tabela 30, a abordagem adotada pelas empresas brasileiras

para gerenciamento de riscos, por região. Logo a seguir, na Tabela 31, apresenta-se o

Quociente Locacional (QLRegião) por região, tendo como referencia os dados da Tabela 30.


região

REGIÃO

QUANTIDADE DE RESPOSTAS

TOTAL

%

(a)

Não tratamos riscos

em projetos na

nossa organização

(b)

Realizado

informalmente,

conforme interesse

ou necessidade do

responsável pelo

projeto

(c)

Baseado em uma

metodologia

formal, estruturada

por políticas,

procedimentos e

formulários

SUDESTE 18 134 68 220 59%

SUL 5 38 20 63 17%

NORDESTE 3 25 13 41 11%

CENTRO-OESTE 3 25 13 41 11%

NORTE 1 4 2 7 2%

TOTAL 30 226 116 372 -

% 8% 61% 31% - 100%

Fonte: Estudo de Benchmarking em Gerenciamento de Projetos no Brasil – 2008.

150

A partir dos dados da Tabela 30 pôde-se calcular o Quociente Locacional por região

(QLRegião) (Tabela 31).

Tabela 31: Quociente Locacional por Região da abordagem para gerenciamento de riscos

REGIÃO

(a)

Não tratamos riscos em projetos

na nossa organização

(b)



necessidade do responsável pelo

projeto

(c)


formal, estruturada por políticas,

procedimentos e formulários

(Yij) (Xij) QLRegião

(Xij / Yij) (Yij) (Xij)

QLRegião


QLRegião

(Xij / Yij)

SUDESTE

8,065%

8,182% 1,015

60,753%

60,909% 1,003

31,183%

30,909% 0,991

SUL 7,937% 0,984 60,317% 0,993 31,746% 1,018

NORDESTE 7,317% 0,907 60,976% 1,004 31,707% 1,017

CENTRO-OESTE 7,317% 0,907 60,976% 1,004 31,707% 1,017

NORTE 14,286% 1,771 57,143% 0,941 28,571% 0,916


Quando o QLRegião < 1, significa que a região apresenta uma concentração locacional

fraca. Quando o QLRegião ≥ 1, significa que a região apresenta concentração locacional forte,

ou seja, nesta região existe uma maior concentração de empresas que utilizam a abordagem de

gerenciamento de riscos baseada em uma metodologia formal, estruturada por políticas,


Após o cálculo do QLRegião , estes foram alocados no mapa (Gráfico 12), onde é possível

ver graficamente as variações entre as regiões brasileiras para os três tipos de abordagens

(alternativas (a), (b) e (c) ) para o gerenciamento de riscos adotados pelas empresas, de acordo

com os dados do Estudo de Benchmarking em Gerenciamento de Projetos no Brasil – 2008.

151

Gráfico 12: Quociente Locacional por Região da abordagem para gerenciamento de riscos

(a) Não tratamos riscos em projetos


(b) Realizam informalmente,

conforme interesse ou necessidade

do responsável pelo projeto

(c) Baseado em uma metodologia formal,

estruturada por políticas,


Legenda de Cores:

Quociente Locacional ≥ 1

0 < Quociente Locacional < 1

Legenda de Regiões:

1-Centro-Oeste

2-Nordeste

3-Norte

4-Sudeste

5-Sul


Considerando que o objetivo deste artigo é a alternativa (c) (Gráfico 12), ou seja,

abordagens para gerenciamento de riscos baseadasem uma metodologia formal, estruturada

por políticas, procedimentos e formulário, pode-se observar que as regiões que apresentam

maior concentração locacional32

são as regiões Centro-Oeste, Nordeste e Sul.

Conforme já mencionado é calculado o Quociente Locacional por estado (QLUF)

(Tabela 32), somente para os estados das regiões que apresentaram maior concentração

locacional (Gráfico 12).

32

Regiões que apresentaram a maior concentração locacional, são as que possuem QLRegião ≥ 1.

152


estado33


A partir dos dados da Tabela 32 é calculado o Quociente Locacional por estado (QLUF)

(Tabela 33).

33

Os estados selecionados foram os que apresentaram índice de participação na pesquisa de Benchmarking em

gerenciamento de projetos no Brasil - 2008, superior a 1%.

UF

QUANTIDADE DE RESPOSTAS

TOTAL %

(a)

Não tratamos

riscos em projetos

na nossa

organização

(b)

Realizado

informalmente,

conforme interesse

ou necessidade do

responsável pelo

projeto

(c)

Baseado em uma

metodologia

formal, estruturada

por políticas,

procedimentos e

formulários

BA BAHIA 1 7 4 12 3,21%

DF DISTRITO FEDERAL 1 9 5 15 4,07%

CE CEARÁ 0 4 2 6 1,50%

GO GOIÁS 0 4 2 6 1,71%

RS RIO GRANDE DO SUL 2 17 9 28 7,49%

SC SANTA CATARINA 2 13 7 22 6,01%

MT MATO GROSSO 1 10 5 16 4,28%

SP SÃO PAULO 10 79 40 129 34,69%

RJ RIO DE JANEIRO 6 44 22 72 19,27%

PE PERNAMBUCO 2 12 6 20 5,14%

AM AMAZONAS 1 4 2 7 1,93%

PR PARANÁ 1 9 4 14 3,64%

MG MINAS GERAIS 1 7 3 11 3,00%

ES ESPÍRITO SANTO 1 5 2 8 2,14%

TOTAL 29 229 115 373 -

% 8% 61% 31% - 100%

153

Tabela 33: Quociente Locacional da abordagem para gerenciamento de riscos por Estado

UF

(a)

Não tratamos riscos em projetos


(b)


conforme interesse ou necessidade

do responsável pelo projeto

(c)


formal, estruturada por políticas,


(Yij) (Xij) QLUF


QLUF


QLUF

(Xij / Yij)

BAHIA

7,775%

8,333% 1,072

61,394%

58,333% 0,950

30,831%

33,333% 1,081

DISTRITO FEDERAL 6,667% 0,857 60,000% 0,977 33,333% 1,081

CEARÁ 0,000% 0,000 66,667% 1,086 33,333% 1,081

GOIÁS 0,000% 0,000 66,667% 1,086 33,333% 1,081

RIO GRANDE DO

SUL 7,143% 0,919

60,714% 0,989

32,143% 1,043

SANTA CATARINA 9,091% 1,169 59,091% 0,962 31,818% 1,032

MATO GROSSO 6,250% 0,804 62,500% 1,018 31,250% 1,014

SÃO PAULO 7,752% 0,997 61,240% 0,997 31,008% 1,006

RIO DE JANEIRO 8,333% 1,072 61,111% 0,995 30,556% 0,991

PERNAMBUCO 10,000% 1,286 60,000% 0,977 30,000% 0,973

AMAZONAS 14,286% 1,837 57,143% 0,931 28,571% 0,927

PARANÁ 7,143% 0,919 64,286% 1,047 28,571% 0,927

MINAS GERAIS 9,091% 1,169 63,636% 1,037 27,273% 0,885

ESPÍRITO SANTO 12,500% 1,608 62,500% 1,018 25,000% 0,811


O QLUF < 1 significa que o estado apresenta uma concentração locacional fraca. O QLUF

≥ 1 significa que o estado apresenta concentração locacional forte, ou seja, neste estado existe

uma maior concentração de empresas que utilizam a abordagem de gerenciamento de riscos

baseada em uma metodologia formal, estruturada por políticas, procedimentos e formulários.

Após o cálculo do QLUF, estes foram alocados no mapa (Gráfico 13), onde é possível

ver graficamente as variações entre os estados brasileiros dentro das regiões identificadas no

154

Gráfico 13 com QLRegião ≥ 1 e somente para a abordagem (c) (Tabela 33), conforme objetivo

deste artigo.

Gráfico 13: Quociente Locacional por Estado das regiões que apresentaram QLRegião ≥ 1 e que

utilizam abordagem para gerenciamento de riscos baseada em uma metodologia formal,

estruturada por políticas, procedimentos e formulários

Legenda de Cores:

Quociente Locacional ≥ 1 Estado não pesquisado

0 < Quociente Locacional < 1 Estado com menos de 1% de participantes na pesquisa


Conforme já mencionado o Estudo de Benchmarking em Gerenciamento de Projetos no

Brasil – 2008, inclui empresas de diversos estados brasileiros, porém alguns estados não

participaram do Estudo de Benchmarking e outros tiveram uma participação inferior a 1%. E

esse fato se repete também para as regiões objeto deste artigo e identificadas no Gráfico 12.

Das três regiões que apresentaram maior concentração locacional, alternativa (c)

(Gráfico 12), os estados do Maranhão, Piauí, Rio Grande do Norte e Paraíba não foram

contemplados no Estudo de Benchmarking sobre Gerenciamento de Projetos no Brasil – 2008.

Já os estados de Alagoas e Sergipe tiveram uma participação inferior a 1%, no referido Estudo

de Benchmarking.

Considerando que o objetivo deste artigo é a alternativa (c) (Tabela 33), ou seja,

abordagens para gerenciamento de riscos baseadas em uma metodologia formal, estruturada

por políticas, procedimentos e formulário, pode-se observar que os estados que apresentaram

155

maior concentração locacional34

foram os estados do Mato Grosso, Goiás e Distrito Federal

(Região Centro-Oeste), Ceará e Bahia (Região Nordeste) e Santa Catarina e Rio Grande do

Sul (Região Sul). E os estados, dentro das três regiões identificadas (Gráfico 12), que

apresentaram menor concentração locacional foram Pernambuco e Paraná.

3. Conclusões

Conforme já mencionado, este artigo teve como objetivo identificar quais estados

brasileiros apresentavam maior concentração locacional da utilização de uma metodologia

formal de gerenciamento de riscos e, escolher os estados de uma região para a elaboração de

uma pesquisa sobre gerenciamento de riscos.

Após os estudos realizados neste artigo, os estados que apresentaram maior

concentração locacional foram os estados do Mato Grosso, Goiás e Distrito Federal (Região

Centro-Oeste), Ceará e Bahia (Região Nordeste) e Santa Catarina e Rio Grande do Sul

(Região Sul).

Portanto, pode-se concluir que sete estados, em três regiões brasileiras, se enquadrariam

no objetivo deste artigo, ou seja, poderiam ser selecionados para a elaboração de pesquisa

sobre gerenciamento de riscos.

Dos sete estados foram escolhidos os estados de Goiás e Distrito Federal (pertencentes à

região Centro-Oeste). Esta escolha também se justifica pela redução de custo e facilidade

operacional.

34

Estados que apresentaram a maior concentração locacional, são as que possuem QLUF ≥ 1.

156

APÊNDICE II – Lista de Riscos para Sistemas de Informação

Conforme já mencionado, Mulcahy (2010) classificou sua lista de riscos, para sistemas

de informação, em 10 categorias (contrato, cliente, internacional, gerenciamento de projeto,

qualidade, recursos, escopo, segurança, riscos com fornecedor e tecnologia), conforme Tabela

17. Na primeira coluna temos a identificação do fator de riscos, exemplo 1-01, onde o

primeiro número “1” representa o autor do fator de risco, ou seja, “Mulcahy (2010) e o

segundo número “01” representa o número do fator de risco. A segunda coluna contém a

causa, a terceira o nome e a quarta descreve o efeito do risco.

Tabela 34: Lista de riscos para sistemas de informação

ID35

CAUSA RISCO EFEITO

Contrato



usual.






1-02 Por causa do tempo de contrato /

materiais são diferentes de versões

anteriores, as quais foram feitas sob

preços fixos de contrato, e o

fornecedor raramente é crítico sobre

um pedido de mudança do cliente.

Os objetivos podem se

desenvolver gradualmente.

O que poderia levar ao atraso

do projeto e à um custo mais

caro.

Cliente

1-03 Porque há resistência entre os usuários

ao substituir a sua aplicação de

software atual por um novo aplicativo

de software/ sistema.

Pode haver sabotagem. O que resultaria em um atraso

do projeto.

1-04 Porque um bom relacionamento com o

cliente não pode ser mantida.

Se existe falta de confiança. O que pode exigir mais

reuniões e uma extra e

constante garantia.

1-05 Porque o fornecedor é dependente do

cliente para dados de teste.

Os dados podem não estar

disponíveis logo que necessário.

Fazendo testes começarem

mais tarde do que deveriam

para atender à devida data

solicitada com qualidade

adequada.

Fonte: Mulcahy, 2010.

35



157

Tabela 34: Lista de riscos para sistemas de informação (Cont.)

ID36

CAUSA RISCO EFEITO

1-06 Devido ao pouco esforço por parte do

cliente para obter apoio para o projeto.

A equipe do cliente pode trabalhar

ativamente contra o projeto.

O que pode resultar em metas

do projeto não sendo atingidas

no prazo previsto, assim como,

informações importantes não

estando disponíveis.

1-07 Porque o cliente é completamente

dependente do fornecedor para

conhecimento técnico sobre a

aplicação de software e ferramentas de

software subjacente.

Oportunidades para uma solução

mais satisfatória poderia ser

perdida.

Fazendo com que o cliente e os

clientes deles aceitem a

funcionalidade reduzida

desnecessariamente

1-08 Porque o cliente pretende reescrever o

aplicativo e trazê-lo à tona dentro de

12 a 18 meses.

O cancelamento do projeto pode

ocorrer.

Causando um atraso no

cronograma de mais de dois

meses.

Internacional

1-09 Pessoas de oito países estão

trabalhando neste projeto e a maioria

não está acostumada a trabalhar com

culturas diferentes.

O que pode causar má

interpretação do idioma ou

problemas culturais.

Resultando em baixa moral e a

necessidade de aumentar o

treinamento e a construção de

equipe.

1-10 O clima econômico atual tem muitas

mudanças no valor das moedas em uso

no projeto.

O que pode causar uma grande

oscilação no valor do dólar.

Aparecendo riscos de custos

adicionais.

1-11 Pessoas de países conservadores estão


não está em sintonia com trabalhar

com culturas diferentes.

O que pode causar uma mudança

nas leis internas e estrangeiras ou

leis falhas.

Resultando em atividade ilegal

inadvertida

1-12 Devido a problemas com a imigração. Um ou mais membros da equipe

itinerante do projeto pode se

atrasar ou não ter permissão para

prosseguir.

O que pode causar um atraso

no projeto.

1-13 Devido às obrigações e restrições

aduaneiras.

Chave de software ou

equipamento pode ser atrasada no

transporte.

O que poderia causar um

atraso no projeto.

1-14 Devido às diferenças de horários de

férias e/ou feriados.

Toda a equipe do projeto pode não

estar disponível em determinadas

épocas.

Fazendo com o trabalho seja

refeito.

1-15 Devido às exigências linguísticas. O número de fornecedores

qualificados pode ser menor.

O que pode resultar em uma

equipe de projeto de qualidade

inferior.

1-16 Devido à diferentes práticas

comerciais.

O sistema escolhido para as

operações norte-americanas pode

não ser adequada para as unidades

de negócios internacionais.

O que pode resultar em um

sistema de baixa qualidade ou

um aumento na duração do

projeto e no custo para maiores

requisitos de programação.

1-17 Devido à baixa disponibilidade de

voos.

Os membros da equipe itinerante

do projeto podem não estar

disponíveis para uma semana

inteira de trabalho.


atraso para o projeto.


36



158


ID37

CAUSA RISCO EFEITO

1-18 Devido à aquisição/compra de

hardware a partir de várias fontes

internacionais.

Pode haver incompatibilidade. O que poderia causar um

atraso para o projeto quanto a

obtenção do componente(s)

corretos.

1-19 Devido à comunicação ruim por e-mail

ou voz (entrega lenta ou baixa

qualidade) a nível internacional.

As comunicações chaves pode ser

atrasadas.


declínio do projeto.

1-20 Devido às diferenças de idiomas. A definição de papéis e

responsabilidades para a equipe do

projeto não podem ser plenamente

compreendidas.

O que pode resultar em falhas

para selecionar os melhores

recursos.

1-21 Devido à incompreensão das leis

trabalhistas e regulamentos

internacionais.

Procedimentos inadequados

podem ser seguidos.

O que pode resultar em atraso

da disponibilidade de recursos.

1-22 Devido ao terrorismo. Instalações podem ser danificadas

ou membros da equipe podem ser

mortos ou seqüestrados.

Resultando em um atraso para

o projeto e/ou aumento do

custo.

1-23 Devido às diferenças de idiomas. O gerente de projeto pode não

comunicar adequadamente os

requisitos ou programações aos

membros da equipe.


atraso para o projeto ou

diminuição da qualidade do

sistema.

Gerenciamento do Projeto

1-24 A falta de financiamento tem

provocado uma semana obrigatória de

50 horas extras por mês com adicional

de 50 horas sendo muito comum.

O que pode causar uma exaustão

rápida na equipe para

desempenhar essa habilidade

industrial de alta demanda.

Causando a exaustão da equipe

e a saída do projeto.

1-25 Devido a nenhuma informação escrita

sobre projetos passados.

Coleta de dados em tempo

adicional pode ser necessária.

Resultando em menor tempo

gasto na conclusão dos

trabalhos.

1-26 Devido a uma reorganização. As pessoas podem gastar tempo

discutindo o efeito da

reorganização.

Resultando no atraso do

projeto.

1-27 Devido à gestão anunciando que a

entrega de um produto estará liberada

em uma determinada data.

Empregados podem adiar seu

trabalho atual e um outro projeto

pode ser iniciado para atender a

esse prazo.

Causando atrasos no projeto ou

insatisfação com a gestão ou a

perda de motivação e de

trabalho adicional refeito uma

vez que o prazo de entrega foi

cumprido.

1-28 Devido à existência de um projeto

separado e equipes de implementação.

Nem todas as áreas de negócio

estão envolvidos na determinação

dos objetivos de trabalho para o

projeto.

O que pode resultar no sistema

não ser capaz de abordar todos

os requisitos do negócio.


separado e equipes de implementação,

e porque a equipe de implementação

não tem sido capaz de se pronunciar

sobre o projeto.

Parte do projeto pode não ser

capaz de ser implementado no

mundo real.

Levando à uma mudança tardia

de objetivos no projeto.

1-30 Devido à existência de dois projetos

colaborativos.

Pode haver uma falta de

coordenação entre os projetos.

Causando desalinhamento de

requisitos e projeto.


37



159


ID38

CAUSA RISCO EFEITO

1-31 Porque não há nenhum plano

compreensivo de gerenciamento de

comunicações.

Problemas graves podem

permanecer em um nível inferior

da responsabilidade do projeto do

que deveriam.

Atrasando o projeto e aumento

do estresse em ambas as

equipes, do cliente e do

fornecedor.

1-32 Nem a administração nem as vendas

disseram ao cliente que algumas de

suas exigências podem não ser

cumpridas dentro do prazo.

O que pode significar que o cliente

pode não ajustar as exigências.

Resultando em menor lucro no

projeto enquanto a equipe

soma as exigências usando as

horas extras ou recursos

adicionais não incluídos na

proposta original.

1-33 Os membros da equipe estão

espalhados por todo o país.

O que pode causar um sofrimento

na comunicação.

Resultando em produtividade

sendo sacrificada.

1-34 O tempo de avaliação para

ferramentas/métodos é menor do que a

empresa já teve que lidar no passado.

Embora este calendário tenha sido

aprovado pela administração, a

realidade de prazos pode não ser

adequada.

Resultando em atrasos.

Qualidade

1-35 Porque não há um plano de

gerenciamento de qualidade.

Problemas são susceptíveis de

serem descobertos e resolvidos

depois do teste, ao invés de serem

resolvidos no início do ciclo de

desenvolvimento de vida.

Resultando em um potencial

para uma versão com vírus

significativos conhecidos.

1-36 Porque muitas das regras para reforçar

a integridade referencial no banco de

dados são, na verdade, implementadas

no código do aplicativo.

Algumas linhas da tabela podem

ser mudadas ou deletadas

incorretamente.

Resultando (no melhor caso)

em trabalho refeito e (no pior

caso) na perda de dados do

cliente.

1-37 Porque o fornecedor confia totalmente

no cliente para muitas decisões do

projeto (por exemplo: navegação de

página na web).

A ligação pode não ser concebida

tão bem como deveria ser.

Redução da satisfação do

cliente.

1-38 Porque o documento do projeto se

refere a números específicos (exemplo:

0-120 dias), sem explicar as relações

entre os números.

Pelo menos uma regra de negócio

pode ser mal implementada ou

uma dependência inapropriada

pode ser criada.

De tal forma que o pedido

pode não se comportar como

deveria.

1-39 Porque o fornecedor não tem meios

para avaliar o impacto de desempenho

antes de o software ser implantado.

Recursos existentes que poderiam

compartilhar código com novos

recursos podem não fazê-lo.

Resultando em tempos de

resposta mais lentos do

usuário.

1-40 Porque esta relação fornecedor /

cliente e esta aplicação tem uma

história de programas de

desenvolvimento de ultrapassagem,

resultando em sistemas

significativamente encurtados e testes

de aceitação.

Este projeto pode encontrar a

mesma pressão para os ciclos de

testes reduzidos.

Resultando em um produto

implantado de qualidade

inferior à desejada.

1-41 Por motivo das versões anteriores

terem tido um número elevado de vírus

e recursos mal implementados.

O fornecedor pode concluir que

isso é aceitável para o cliente.

E falhar para melhorar os

processos que podem ser

mostrados para causar

resultados tão pobres.


38



160


ID39

CAUSA RISCO EFEITO

1-42 Devido às mudanças do mercado ou

outras prioridades.

O patrocinador/origem de fundos

pode esgotar-se de dinheiro ou se

recusar a continuar a financiar.

O que pode levar a um projeto

abandonado e/ou

impossibilidade de entregar

todas as funcionalidades.

1-43 Devido aos processos ruins ou outros

problemas.

Dados históricos podem ser

imprecisos ou poluídos.

O que levaria à saída do

sistema ruim e/ou diminuição

na qualidade dos prazos e uma

baixa aceitação do usuário.

1-44 Devido à má comunicação ou

treinamento ou gerenciamento.

O sistema pode funcionar como

necessário, mas as mudanças de

processos que precisam ocorrer

podem não acontecer.

Resultando em baixa aceitação

do usuário e impacto negativo

na percepção do sistema e

equipe de projeto.

1-45 Devido ao planejamento ruim. O volume de usuários/dados pode

ser maior do que as expectativas

iniciais.

O que pode levar à lentidão do

serviço, clientes insatisfeitos,

impacto na largura da banda de

rede e hardware (e, portanto,

em outras aplicações), falha no

sistema, etc.

1-46 Devido ao adiamento da garantia de

qualidade até o final do projeto.

Uma quantidade substancial de

trabalho refeito pode ser

descoberto no final.

O que poderia levar a um

deslize na data de entrega.

1-47 Houve três casos distintos em que o

backup/mecanismo de recuperação de

desastre falhou. Embora esse sistema

esteja sendo investigado, nenhuma

mudança ocorrerá antes que o projeto

atual será concluído.

O que pode levar à falha no

sistema de backup / mecanismo de

recuperação de desastres.

Causando uma perda de código

de programação ou estruturas

de dados e dados de testes

desenvolvidos até à data.

1-48 Padrões ainda não concordaram com

as tecnologias que estão sendo usadas.

Apesar do fato de que novos

padrões podem surgir após a

conclusão do projeto.

Levando ao trabalho adicional

de projeto aderir mais tarde

aos novos padrões técnicos ou

da indústria.

Recursos

1-49 Reuniões não frequentes da comissão

de aprovação do capital.

Podem causar atrasos nas

aprovações de despesas de capital.

Resultando em atrasos de

aquisição de hardware de

computador para teste e

instalação de produção,

resultando em atrasos no

projeto.

1-50 Devido à equipe não estar arranjada. Alguns trabalhos podem ser

duplicados.

Exigindo trabalho adicional

para determinar quais obras

deverão ser concluídas.

1-51 Porque o fornecedor tem a intenção de

usar os mesmos recursos em outros

projetos.

Esses recursos podem não estar

disponíveis quando antecipados.

E a data de entrega prevista

pode ser perdida.

1-52 Porque o fornecedor tem uma

rotatividade significativa de equipe.

Novos recursos podem ter de ser

procurados e trazidos rápido

durante o desenvolvimento.

O que poderia adicionar pelo

menos um mês para o projeto e

possivelmente muito mais.


39



161


ID40

CAUSA RISCO EFEITO

1-53 Porque o fornecedor tem sido reduzido

por muitos anos e continua a fazê-lo.

O fornecedor pode optar por

transferir recursos entre seus

projetos.

O que pode envolver um atraso

substancial no cronograma

como novos recursos

provenientes e preparados do

trajeto. (Nota: os recursos

podem incluir gerente ou o

espaço físico ou locais de

trabalho, etc, e não apenas os

membros da equipe).

1-54 Devido a ter uma equipe que não está

devidamente treinada nas ferramentas

de desenvolvimento.

Um progresso lento pode ocorrer. O que pode levar à falta de

uma data para lançamento.

1-55 Devido à sobrecarga de um recurso

crítico.

Divulgação de informações vitais

podem ser bloqueadas.

Conduzindo a decisões

erradas.

1-56 Devido a um recurso crítico de nível

mais antigo torna-se indisponível.

O treinamento cruzado dos

recursos de nível mais novo pode

não ocorrer.

O que pode levar a uma equipe

ineficaz.

1-57 Devido aos interessados em não

comprar.

Uma lacuna entre o que é crítico e

o que não pode ocorrer.

Poderia levar a uma não

decisão para o lançamento.

Escopo

1-58 Porque o fornecedor não criou, um

protótipo de muitas das mudanças nas

ligações do usuário.

Algumas funcionalidades

esperadas do cliente podem estar

completamente em falta e não

serem descobertas até o teste de

aceitação.

Resultando em horas extras de

última hora.

1-59 Porque o fornecedor tem planos de

substituir uma peça central da

aplicação por um pacote de software

não identificado, ao mesmo tempo em

que esta versão está sendo

desenvolvida.

Confiança e escalabilidade ou

outros problemas técnicos

imprevistos.

Podem afetar o cronograma

para esta versão.

1-60 Porque o fornecedor tem um bom

entendimento do software de

aplicação, mas uma má compreensão

do negócio do cliente.

O fornecedor poderá fazer

suposições irregulares sobre a

lógica do negócio que poderiam

revelar-se erradas.

E ter que ser reimplantado.

1-61 Porque a equipe de desenvolvimento

está em Maryland e o cliente está em

San Diego.

Problemas detectados durante a

codificação e testes da unidade.

Pode resultar em atrasos de

atividades como questões de

lógica de negócios que são

discutidas por telefone.

1-62 Critérios de aceitação do projeto não

são claros.

O que poderia levar à dificuldade

na obtenção de autorização em

marcos importantes.

Resultando em um trabalho

adicional que está além do

orçamento de custos.

Segurança

1-63 Devido à alta demanda de trabalho de

uma empresa, ela sofreu mais

violações de segurança que a maioria

das empresas.

O que pode conduzir a uma

violação de segurança em uma

seção da empresa.

Atrasando o projeto a fim de

garantir à gestão que não haja

quebras de segurança em seu

projeto.


40



162


ID41

CAUSA RISCO EFEITO

Riscos com Fornecedor

1-64 Um projeto requer a participação de

pequenos fornecedores de software em

uma economia em rápida mudança.

Podem estar em risco se o

fornecedor de software for

convencido pela empresa-mãe,

durante ou após as negociações da

compra de software.

Resultando na pausa do

projeto, ou outros, produtos

menos perfeitamente

adaptados a serem adquiridos,

ao invés, ou o projeto que está

sendo adiado devido às

mudanças nas negociações de

contrato.

1-65 Devido ao grande número de

fornecedores.

Rotatividade da equipe e

mudanças de pessoal podem

atrasar o projeto.

E fazer com que a conclusão

de prazos seja tardia.

1-66 Devido aos fornecedores arraigados. O projeto pode ter que usar

tecnologia mais antiga para o

desenvolvimento.

O que pode atrasar o projeto

e/ou reduzir a qualidade do

produto e o pedido adicional

de uma manuntenção não

planejada.

1-67 Desde que a segurança do fornecedor

do software não seja compatível com

as políticas da empresa.

Desenvolvimento personalizado

pode ser exigido e a complexidade

do desenvolvimento ainda

precisará ser especificada. Se a

personalização tornar-se

excessivamente complexa.

Pode ocorrer uma escapada nas

datas de entrega com custos de

customização aumentados ou

uma política de segurança

pode precisar ser

comprometida.

1-68 Porque um fornecedor pode se fundir

com outro fornecedor.

Produtos podem não estar

disponíveis.

Causando uma necessidade de

reformular o projeto..

1-69 Porque o fornecedor não tem uma

metodologia de projeto estabelecida.

Existe um risco elevado em que

vários ciclos de projeto podem ser

requeridos antes da codificação

começar.

O que poderia causar o

começo do desenvolvimento

tardio, levando a durações das

atividades excessivamente

otimistas, a fim de

proporcionar um destino final

aceitável ao cliente.

1-70 O software utilizado neste projeto já

existe há alguns anos em um mercado

onde há um grande número de novos

produtos sendo lançados.

O que pode fazer com que um

fornecedor deixe de apoiar o

software.

Levando a uma mudança na

arquitetura ou abordagem.

1-71 Porque o fornecedor se refere ao

projeto como um “documento vivo” e

não tem nenhum processo formal de

controle de mudança.

Características podem ser

adicionadas mesmo que o cliente

prefira não tê-las.

Resultando em diminuição da

satisfação do cliente.

1-72 Porque o fornecedor tem

experimentado enfraquecimento

financeiro há muitos anos.

O fornecedor, o qual é uma

divisão de uma empresa muito

maior, poderia ser vendido para

outra empresa.

Causando a interrupção

substancial da equipe e dos

problemas incluindo horários

atendidos e recursos perdidos.

1-73 Porque o fornecedor não conduz

revisões internas do projeto.

Elementos do projeto podem não

ser descobertos até que o

desenvolvimento seja

substancialmente completo.

Causando trabalho refeito e/ou

retestes e escapadas do

cronograma.


41



163


ID42

CAUSA RISCO EFEITO

1-74 Porque o fornecedor não tem

experiência com explicações passo-a-

passo de códigos ou de outras práticas

que reduzam os defeitos.

Vírus podem não ser detectados

até que a instalação ocorra.

Aumentando o tempo e o custo

necessários para corrigir

qualquer vírus encontrado.

1-75 Porque a equipe do fornecedor não tem

nenhuma experiência anterior com

gerenciamento de risco formal.

É altamente provável que soluções

poderiam ser utilizadas para os

problemas que poderiam ter sido

evitados ou mitigados ou

transferidos para outro fornecedor.

Resultando em baixa moral

e/ou perda de prazos e custos

mais elevados e baixa

qualidade.

1-76 Porque o fornecedor não tem processo

formal para relacionar as mudanças de

aplicação no projeto esquemático do

banco de dados.

Problemas no projeto do banco de

dados poderiam ser descobertos no

final do processo de

desenvolvimento.

Exigindo trabalho refeito para

corrigir as deficiências.

1-77 Porque o fornecedor utiliza apenas um

modelo em queda pura para o

desenvolvimento.

Oportunidades para a agilização

do projeto podem ser perdidas.

Assim sendo, não tendo

vantagens das economias de

tempo que poderiam advir para

o projeto.

Tecnologia

1-78 Porque o produto de software é

relativamente novo e a tecnologia de

projeto pode não ter sido comprovada.

Vários lançamentos podem ser

necessários antes que o produto

esteja estável.

O que pode levar a defeitos

funcionais ou técnicos.

1-79 Porque o produto de software nunca

foi implementado em uma plataforma

centralizada com o volume de dados

requeridos pelo cliente.

Não foi comprovado que o

produto pode ser escalado para o

tamanho necessário.

E recursos adicionais podem

ser necessários para ajustar o

desempenho do banco de

dados e do fornecedor de

software para otimizar o

código.

1-80 Porque o software a ser comprado está

na versão beta.

A data da versão de produção final

poderia não ser cumprida.

E o aumento do número de

erros e vírus encontrados no

produto lançado.

1-81 Devido a não ter um processo sólido

de gerenciamento objetivo.

Pode ocorrer desenvolvimento

gradual de objetivos.

Causando trabalho adicional

ou trabalho refeito e usuários

insatisfeitos.

1-82 Devido à extensão do projeto. Aplicativos atuais podem ser

funcionalmente obsoletos antes da

implementação se completar.

Diminuindo o impacto nos

negócios da implementação.

1-83 Devido à dificuldade das diversas

partes interessadas em chegar a um

consenso entre a padronização e a

variação local.

A eficácia da implementação pode

ser reduzida.

Causando atrasos no projeto.

1-84 O projeto está sendo implementado em

duas áreas de negócio que

compartilham dados para tomada de

decisão.

E conduzindo o sistema em uma

área de negócio pode causar uma

interrupção na outra área de

negócio.

Impactando a sua capacidade

de exercer funções

empresariais básicas.

1-85 O projeto de desenvolvimento do

software se baseia em dados

fornecidos por muitos sistemas de

legados. Qualquer área que não pode

fornecer os recursos (pessoas ou

regiões de teste) para apoiar este

projeto.

Poderia introduzir ameaças críticas

no decorrer do projeto.

E possíveis atrasos.


42



164


ID43

CAUSA RISCO EFEITO

1-86 Implementação de um novo produto de

software pode causar aumento da

procura no atendimento por telefone.

O que pode causar atrasos e

respostas inadequadas às questões

e possível utilização de uma

equipe de implementação para

responder às perguntas.

Causando um atraso possível

aos lançamentos adicionais.

1-87 A equipe de hardware está substituindo

os terminais por estações de trabalho.

Mas se o prazo para a

implementação de estação de

trabalho não for cumprido.

Equipamentos provisórios

podem precisar ser

implementados ou o atraso do

projeto.

1-88 Por causa da qualidade inconsistente

de dados do sistema que foi legado.

Dados impuros podem ser

convertidos para o novo sistema.

O que pode levar a uma clara

pós-conversão substancial ou

desconfiança do sistema pela

comunidade de usuários.

1-89 Devido ao treinamento insuficiente ou

aceitação do usuário.

O sistema pode não ser

adequadamente utilizado.

E pode resultar em falta de

dados acumulados para apoiar

os benefícios esperados.

1-90 Devido a um ambiente de

desenvolvimento instável.

Perda de código-fonte pode

ocorrer.

O que levaria a uma

duplicação do trabalho.

1-91 Devido a uma má compreensão dos

dados subjacentes.

Um projeto inconsistente das

aplicações pode ocorrer.

O que levaria a um fracasso

completo em atender os

requisitos do negócio.

1-92 Devido à pobre arquitetura do sistema. Pode ocorrer a falha em cumprir as

métricas de desempenho

requeridas.

O que pode levar a uma

mudança significativa no

projeto do sistema..

1-93 Devido a um lançamento longo de

servidores.

Avanços tecnológicos podem

tornar os servidores ultrapassados

pela conclusão do projeto.

O que pode levar à

necessidade de adquirir um

servidor alternativo antes da

conclusão do projeto. Além

disso, os testes podem ser

obrigados a certificar um

segundo servidor.

1-94 Porque alguns dos principais módulos

do aplicativo estão colidindo contra

um limite absoluto para o tamanho do

código fonte.

Alguns módulos não podem ser

modificados conforme previsto.

E pode ter que ser

reestruturados e/ou reescritos.

1-95 O cliente tem a garantia de que a nova

tecnologia irá atender às suas

necessidades.

Mas pode haver falha para

perceber os limites da tecnologia.

Isso pode causar custos

adicionais para aquisição de

novas tecnologias quando

ocorrer a primeira falha.

1-96 Um novo sistema foi criado na

demanda por usuários finais animados

por mais de um ano.

E devido à resposta positiva

esmagadora do usuário para o

sistema.

O aplicativo pode falhar

quando mais usuários fazerem

login no sistema do que o

inicialmente previsto.


43



165

APÊNDICE III – Análise Semântica dos Fatores de Riscos

Este apêndice apresenta a análise semântica dos fatores de riscos realizada em cinco

etapas, conforme já mencionado na metodologia. A primeira etapa seria eliminar os fatores de

riscos citados por Mulcahy (2010) que sejam específicos para sistema de informação e não

para desenvolvimento de software. Durante esta análise ocorreram duas novas situações que

levaram à eliminação de alguns fatores de riscos. Na primeira situação encontrada foram

eliminados os fatores de riscos referentes a situações específicas de desenvolvimento de

software e que não serviriam, ou não poderiam ser generalizados, para outros casos de

desenvolvimento de software. Na segunda, foram eliminados os fatores de riscos cujo

entendimento não ficou claro. A Tabela 35 apresenta os fatores de riscos eliminados.


(2010)

ID CAUSA RISCO EFEITO



usual.






1-02 Por causa do tempo de contrato /

materiais são diferentes de versões

anteriores, as quais foram feitas sob

preços fixos de contrato, e o

fornecedor raramente é crítico sobre

um pedido de mudança do cliente.

Os objetivos podem se

desenvolver gradualmente.

O que poderia levar ao atraso

do projeto e à um custo mais

caro.

1-04 Porque um bom relacionamento com o

cliente não pode ser mantida.

Se existe falta de confiança. O que pode exigir mais

reuniões e uma extra e

constante garantia.

1-06 Devido ao pouco esforço por parte do

cliente para obter apoio para o projeto.

A equipe do cliente pode trabalhar

ativamente contra o projeto.

O que pode resultar em metas

do projeto não sendo atingidas

no prazo previsto, assim como,

informações importantes não

estando disponíveis.

1-08 Porque o cliente pretende reescrever o

aplicativo e trazê-lo à tona dentro de

12 a 18 meses.

O cancelamento do projeto pode

ocorrer.

Causando um atraso no

cronograma de mais de dois

meses.

166


(2010) (Cont.)


1-09 Pessoas de oito países estão


não está acostumada a trabalhar com

culturas diferentes.

O que pode causar má

interpretação do idioma ou

problemas culturais

Resultando em baixa moral e a

necessidade de aumentar o

treinamento e a construção de

equipe.

1-10 O clima econômico atual tem muitas

mudanças no valor das moedas em uso

no projeto.

O que pode causar uma grande

oscilação no valor do dólar

Aparecendo riscos de custos

adicionais.

1-11 Pessoas de países conservadores estão


não está em sintonia com trabalhar

com culturas diferentes.

O que pode causar uma mudança

nas leis internas e estrangeiras ou

leis falhas.

Resultando em atividade ilegal

inadvertida

1-12 Devido a problemas com a imigração. Um ou mais membros da equipe

itinerante do projeto pode se

atrasar ou não ter permissão para

prosseguir.

O que pode causar um atraso

no projeto.

1-13 Devido às obrigações e restrições

aduaneiras.

Chave de software ou

equipamento pode ser atrasada no

transporte.

O que poderia causar um

atraso no projeto.

1-15 Devido às exigências linguísticas. O número de fornecedores

qualificados pode ser menor.

O que pode resultar em uma

equipe de projeto de qualidade

inferior.

1-16 Devido à diferentes práticas

comerciais.

O sistema escolhido para as

operações norte-americanas pode

não ser adequada para as unidades

de negócios internacionais.


sistema de baixa qualidade ou

um aumento na duração do

projeto e no custo para maiores

requisitos de programação.

1-17 Devido à baixa disponibilidade de

voos.

Os membros da equipe itinerante

do projeto podem não estar

disponíveis para uma semana

inteira de trabalho.


atraso para o projeto.

1-18 Devido à aquisição/compra de

hardware a partir de várias fontes

internacionais.

Pode haver incompatibilidade. O que poderia causar um

atraso para o projeto quanto a

obtenção do componente(s)

corretos.

1-20 Devido às diferenças de idiomas. A definição de papéis e

responsabilidades para a equipe do

projeto não podem ser plenamente

compreendidas.

O que pode resultar em falhas

para selecionar os melhores

recursos.

1-22 Devido ao terrorismo. Instalações podem ser danificadas

ou membros da equipe podem ser

mortos ou seqüestrados.

Resultando em um atraso para

o projeto e/ou aumento do

custo.

1-24 A falta de financiamento tem

provocado uma semana obrigatória de

50 horas extras por mês com adicional

de 50 horas sendo muito comum.

O que pode causar uma exaustão

rápida na equipe para

desempenhar essa habilidade

industrial de alta demanda.

Causando a exaustão da equipe

e a saída do projeto.

1-25 Devido a nenhuma informação escrita

sobre projetos passados.

Coleta de dados em tempo

adicional pode ser necessária.

Resultando em menor tempo

gasto na conclusão dos

trabalhos.

1-27 Devido à gestão anunciando que a

entrega de um produto estará liberada

em uma determinada data.

Empregados podem adiar seu

trabalho atual e um outro projeto

pode ser iniciado para atender a

esse prazo.

Causando atrasos no projeto ou

insatisfação com a gestão ou a

perda de motivação e de

trabalho adicional refeito uma

vez que o prazo de entrega foi

cumprido.

167


(2010) (Cont.)



separado e equipes de implementação.

Nem todas as áreas de negócio

estão envolvidos na determinação

dos objetivos de trabalho para o

projeto.

O que pode resultar no sistema

não ser capaz de abordar todos

os requisitos do negócio.


separado e equipes de implementação,

e porque a equipe de implementação

não tem sido capaz de se pronunciar

sobre o projeto.

Parte do projeto pode não ser

capaz de ser implementado no

mundo real.

Levando à uma mudança tardia

de objetivos no projeto.

1-31 Porque não há nenhum plano

compreensivo de gerenciamento de

comunicações.

Problemas graves podem

permanecer em um nível inferior

da responsabilidade do projeto do

que deveriam.

Atrasando o projeto e aumento

do estresse em ambas as

equipes, do cliente e do

fornecedor.

1-35 Porque não há um plano de

gerenciamento de qualidade.

Problemas são susceptíveis de

serem descobertos e resolvidos

depois do teste, ao invés de serem

resolvidos no início do ciclo de

desenvolvimento de vida.

Resultando em um potencial

para uma versão com vírus

significativos conhecidos.

1-36 Porque muitas das regras para reforçar

a integridade referencial no banco de

dados são, na verdade, implementadas

no código do aplicativo.

Algumas linhas da tabela podem

ser mudadas ou deletadas

incorretamente.

Resultando (no melhor caso)

em trabalho refeito e (no pior

caso) na perda de dados do

cliente.

1-37 Porque o fornecedor confia totalmente

no cliente para muitas decisões do

projeto (por exemplo: navegação de

página na web).

A ligação pode não ser concebida

tão bem como deveria ser.

Redução da satisfação do

cliente.

1-38 Porque o documento do projeto se

refere a números específicos (exemplo:

0-120 dias), sem explicar as relações

entre os números.

Pelo menos uma regra de negócio

pode ser mal implementada ou

uma dependência inapropriada

pode ser criada.

De tal forma que o pedido

pode não se comportar como

deveria.

1-39 Porque o fornecedor não tem meios

para avaliar o impacto de desempenho

antes de o software ser implantado.

Recursos existentes que poderiam

compartilhar código com novos

recursos podem não fazê-lo.

Resultando em tempos de

resposta mais lentos do

usuário.

1-40 Porque esta relação fornecedor /

cliente e esta aplicação tem uma

história de programas de

desenvolvimento de ultrapassagem,

resultando em sistemas

significativamente encurtados e testes

de aceitação.

Este projeto pode encontrar a

mesma pressão para os ciclos de

testes reduzidos.

Resultando em um produto

implantado de qualidade

inferior à desejada.

1-41 Por motivo das versões anteriores

terem tido um número elevado de vírus

e recursos mal implementados.

O fornecedor pode concluir que

isso é aceitável para o cliente.

E falhar para melhorar os

processos que podem ser

mostrados para causar

resultados tão pobres.

1-42 Devido às mudanças do mercado ou

outras prioridades.

O patrocinador/origem de fundos

pode esgotar-se de dinheiro ou se

recusar a continuar a financiar.

O que pode levar a um projeto

abandonado e/ou

impossibilidade de entregar

todas as funcionalidades.

1-43 Devido aos processos ruins ou outros

problemas.

Dados históricos podem ser

imprecisos ou poluídos.

O que levaria à saída do

sistema ruim e/ou diminuição

na qualidade dos prazos e uma

baixa aceitação do usuário.

168


(2010) (Cont.)


1-44 Devido à má comunicação ou

treinamento ou gerenciamento.

O sistema pode funcionar como

necessário, mas as mudanças de

processos que precisam ocorrer

podem não acontecer.

Resultando em baixa aceitação

do usuário e impacto negativo

na percepção do sistema e

equipe de projeto.

1-45 Devido ao planejamento ruim. O volume de usuários/dados pode

ser maior do que as expectativas

iniciais.

O que pode levar à lentidão do

serviço, clientes insatisfeitos,

impacto na largura da banda de

rede e hardware (e, portanto,

em outras aplicações), falha no

sistema, etc.

1-46 Devido ao adiamento da garantia de

qualidade até o final do projeto.

Uma quantidade substancial de

trabalho refeito pode ser

descoberto no final.

O que poderia levar a um

deslize na data de entrega.

1-47 Houve três casos distintos em que o

backup/mecanismo de recuperação de

desastre falhou. Embora esse sistema

esteja sendo investigado, nenhuma

mudança ocorrerá antes que o projeto

atual seja concluído.

O que pode levar à falha no

sistema de backup / mecanismo de

recuperação de desastres.

Causando uma perda de código

de programação ou estruturas

de dados e dados de testes

desenvolvidos até à data.

1-48 Padrões ainda não concordaram com

as tecnologias que estão sendo usadas.

Apesar do fato de que novos

padrões podem surgir após a

conclusão do projeto.

Levando ao trabalho adicional

de projeto aderir mais tarde

aos novos padrões técnicos ou

da indústria.

1-49 Reuniões não frequentes da comissão

de aprovação do capital.

Podem causar atrasos nas

aprovações de despesas de capital.

Resultando em atrasos de

aquisição de hardware de

computador para teste e

instalação de produção,

resultando em atrasos no

projeto.

1-50 Devido à equipe não estar arranjada. Alguns trabalhos podem ser

duplicados.

Exigindo trabalho adicional

para determinar quais obras

deverão ser concluídas.

1-51 Porque o fornecedor tem a intenção de

usar os mesmos recursos em outros

projetos.

Esses recursos podem não estar

disponíveis quando antecipados.

E a data de entrega prevista

pode ser perdida.

1-52 Porque o fornecedor tem uma

rotatividade significativa de equipe.

Novos recursos podem ter de ser

procurados e trazidos rápido

durante o desenvolvimento.

O que poderia adicionar pelo

menos um mês para o projeto e

possivelmente muito mais.

1-53 Porque o fornecedor tem sido reduzido

por muitos anos e continua a fazê-lo.

O fornecedor pode optar por

transferir recursos entre seus

projetos.

O que pode envolver um atraso

substancial no cronograma

como novos recursos

provenientes e preparados do

trajeto. (Nota: os recursos

podem incluir gerente ou o

espaço físico ou locais de

trabalho, etc, e não apenas os

membros da equipe).

1-55 Devido à sobrecarga de um recurso

crítico.

Divulgação de informações vitais

podem ser bloqueadas.

Conduzindo a decisões

erradas.

1-56 Devido a um recurso crítico de nível

mais antigo torna-se indisponível.

O treinamento cruzado dos

recursos de nível mais novo pode

não ocorrer.

O que pode levar a uma equipe

ineficaz.

169


(2010) (Cont.)


1-57 Devido aos interessados em não

comprar.

Uma lacuna entre o que é crítico e

o que não pode ocorrer.

Poderia levar a uma não

decisão para o lançamento.

1-59 Porque o fornecedor tem planos de

substituir uma peça central da

aplicação por um pacote de software

não identificado, ao mesmo tempo em

que esta versão está sendo

desenvolvida.

Confiança e escalabilidade ou

outros problemas técnicos

imprevistos.

Podem afetar o cronograma

para esta versão.

1-61 Porque a equipe de desenvolvimento

está em Maryland e o cliente está em

San Diego.

Problemas detectados durante a

codificação e testes da unidade.

Pode resultar em atrasos de

atividades como questões de

lógica de negócios que são

discutidas por telefone.

1-63 Devido à alta demanda de trabalho de

uma empresa, ela sofreu mais

violações de segurança que a maioria

das empresas.

O que pode conduzir a uma

violação de segurança em uma

seção da empresa.

Atrasando o projeto a fim de

garantir à gestão que não seja

quebras de segurança em seu

projeto.

1-64 Um projeto requer a participação de

pequenos fornecedores de software em

uma economia em rápida mudança.

Podem estar em risco se o

fornecedor de software for

convencido pela empresa-mãe,

durante ou após as negociações da

compra de software.

Resultando na pausa do

projeto, ou outros, produtos

menos perfeitamente

adaptados a serem adquiridos,

ao invés, ou o projeto que está

sendo adiado devido às

mudanças nas negociações de

contrato.

1-66 Devido aos fornecedores arraigados. O projeto pode ter que usar

tecnologia mais antiga para o

desenvolvimento.

O que pode atrasar o projeto

e/ou reduzir a qualidade do

produto e o pedido adicional

de uma manuntenção não

planejada.

1-67 Desde que a segurança do fornecedor

do software não é compatível com as

políticas da empresa.

Desenvolvimento personalizado

pode ser exigido e a complexidade

do desenvolvimento ainda

precisará ser especificada. Se a

personalização tornar-se

excessivamente complexa.

Pode ocorrer uma escapada nas

datas de entrega com custos de

customização aumentados ou

uma política de segurança

pode precisar ser

comprometida.

1-68 Porque um fornecedor pode se fundir

com outro fornecedor.

Produtos podem não estar

disponíveis.

Causando uma necessidade de

reformular o projeto..

1-69 Porque o fornecedor não tem uma

metodologia de projeto estabelecida.

Existe um risco elevado em que

vários ciclos de projeto podem ser

requeridos antes da codificação

começar.

O que poderia causar o

começo do desenvolvimento

tardio, levando a durações das

atividades excessivamente

otimistas, a fim de

proporcionar um destino final

aceitável ao cliente.

1-70 O software utilizado neste projeto já

existe há alguns anos em um mercado

onde há um grande número de novos

produtos sendo lançados.

O que pode fazer com que um

fornecedor deixe de apoiar o

software.

Levando a uma mudança na

arquitetura ou abordagem.

1-71 Porque o fornecedor se refere ao

projeto como um “documento vivo” e

não tem nenhum processo formal de

controle de mudança.

Características podem ser

adicionadas mesmo que o cliente

prefira não tê-las.

Resultando em diminuição da

satisfação do cliente.

170


(2010) (Cont.)


1-72 Porque o fornecedor tem

experimentado enfraquecimento

financeiro há muitos anos.

O fornecedor, o qual é uma

divisão de uma empresa muito

maior, poderia ser vendido para

outra empresa.

Causando a interrupção

substancial da equipe e dos

problemas incluindo horários

atendidos e recursos perdidos.

1-73 Porque o fornecedor não conduz

revisões internas do projeto.

Elementos do projeto podem não

ser descobertos até que o

desenvolvimento seja

substancialmente completo.

Causando trabalho refeito e/ou

retestes e escapadas do

cronograma.

1-74 Porque o fornecedor não tem

experiência com explicações passo-a-

passo de códigos ou de outras práticas

que reduzam os defeitos.

Vírus podem não ser detectados

até que a instalação ocorra.

Aumentando o tempo e o custo

necessários para corrigir

qualquer vírus encontrado.

1-75 Porque a equipe do fornecedor não tem

nenhuma experiência anterior com

gerenciamento de risco formal.

É altamente provável que soluções

poderiam ser utilizadas para os

problemas que poderiam ter sido

evitados ou mitigados ou

transferidos para outro fornecedor.

Resultando em baixa moral

e/ou perda de prazos e custos

mais elevados e baixa

qualidade.

1-77 Porque o fornecedor utiliza apenas um

modelo em queda pura para o

desenvolvimento.

Oportunidades para a agilização

do projeto podem ser perdidas.

Assim sendo, não tendo

vantagens das economias de

tempo que poderiam advir para

o projeto.

1-79 Porque o produto de software nunca

foi implementado em uma plataforma

centralizada com o volume de dados

requeridos pelo cliente.

Não foi comprovado que o

produto pode ser escalado para o

tamanho necessário.

E recursos adicionais podem

ser necessários para ajustar o

desempenho do banco de

dados e do fornecedor de

software para otimizar o

código.

1-80 Porque o software a ser comprado está

na versão beta.

A data da versão de produção final

poderia não ser cumprida.

E o aumento do número de

erros e vírus encontrados no

produto lançado.

1-81 Devido a não ter um processo sólido

de gerenciamento objetivo.

Pode ocorrer desenvolvimento

gradual de objetivos.

Causando trabalho adicional

ou trabalho refeito e usuários

insatisfeitos.

1-82 Devido à extensão do projeto. Aplicativos atuais podem ser

funcionalmente obsoletos antes da

implementação se completar.

Diminuindo o impacto nos

negócios da implementação.

1-83 Devido à dificuldade das diversas

partes interessadas em chegar a um

consenso entre a padronização e a

variação local.

A eficácia da implementação pode

ser reduzida.

Causando atrasos no projeto.

1-84 O projeto está sendo implementado em

duas áreas de negócio que

compartilham dados para tomada de

decisão.

E conduzindo o sistema em uma

área de negócio pode causar uma

interrupção na outra área de

negócio.

Impactando a sua capacidade

de exercer funções

empresariais básicas.

1-85 O projeto de desenvolvimento do

software se baseia em dados

fornecidos por muitos sistemas de

legados. Qualquer área que não pode

fornecer os recursos (pessoas ou

regiões de teste) para apoiar este

projeto.

Poderia introduzir ameaças críticas

no decorrer do projeto.

E possíveis atrasos.

171


(2010) (Cont.)


1-86 Implementação de um novo produto de

software pode causar aumento da

procura no atendimento por telefone.

O que pode causar atrasos e

respostas inadequadas às questões

e possível utilização de uma

equipe de implementação para

responder às perguntas.

Causando um atraso possível

aos lançamentos adicionais.

1-87 A equipe de hardware está substituindo

os terminais por estações de trabalho.

Mas se o prazo para a

implementação de estação de

trabalho não for cumprido.

Equipamentos provisórios

podem precisar ser

implementados ou o atraso do

projeto.

1-88 Por causa da qualidade inconsistente

de dados do sistema que foi legado.

Dados impuros pode ser

convertidos para o novo sistema.

O que pode levar à uma clara

pós-conversão substancial ou

desconfiança do sistema pela

comunidade de usuários.

1-89 Devido ao treinamento insuficiente ou

aceitação do usuário.

O sistema pode não ser

adequadamente utilizado.

E pode resultar em falta de

dados acumulados para apoiar

os benefícios esperados.

1-91 Devido a uma má compreensão dos

dados subjacentes.

Um projeto inconsistente das

aplicações pode ocorrer.

O que levaria a um fracasso

completo em atender os

requisitos do negócio.

1-92 Devido à pobre arquitetura do sistema. Pode ocorrer a falha em cumprir as

métricas de desempenho

requeridas.

O que pode levar a uma

mudança significativa no

projeto do sistema..

1-93 Devido a um lançamento longo de

servidores.

Avanços tecnológicos podem

tornar os servidores ultrapassados

pela conclusão do projeto.

O que pode levar à

necessidade de adquirir um

servidor alternativo antes da

conclusão do projeto. Além

disso, os testes podem ser

obrigados a certificar um

segundo servidor.

1-94 Porque alguns dos principais módulos

do aplicativo estão colidindo contra

um limite absoluto para o tamanho do

código fonte.

Alguns módulos não podem ser

modificados conforme previsto.

E pode ter que ser

reestruturados e/ou reescritos.

1-95 O cliente tem a garantia de que a nova

tecnologia irá atender às suas

necessidades.

Mas pode haver falha para

perceber os limites da tecnologia.

Isso pode causar custos

adicionais para aquisição de

novas tecnologias quando

ocorrer a primeira falha.

1-96 Um novo sistema foi criado na

demanda por usuários finais animados

por mais de um ano.

E devido à resposta positiva

esmagadora do usuário para o

sistema.

O aplicativo pode falhar

quando mais usuários fazerem

login no sistema do que o

inicialmente previsto.

A segunda etapa seria realizar a análise de semelhança semântica entre os fatores de

riscos selecionados para identificar possíveis duplicações, sendo os 51 fatores de riscos

integrados por Webster (2005) e os fatores de riscos de Mulcahy (2010) selecionados após a

primeira etapa (Tabela 36). O resultado desta segunda etapa encontra-se na Tabela 30.

172

Tabela 36: Fatores de Riscos de desenvolvimento de software citados por Mulcahy (2010)


1-03 Porque há resistência entre os usuários

ao substituir a sua aplicação de

software atual por um novo aplicativo

de software/ sistema.

Pode haver sabotagem. O que resultaria em um atraso

do projeto.

1-05 Porque o fornecedor é dependente do

cliente para dados de teste.


disponíveis logo que necessário.

Fazendo testes começarem

mais tarde do que deveriam

para atender a devida data

solicitada com qualidade

adequada.

1-07 Porque o cliente é completamente

dependente do fornecedor para

conhecimento técnico sobre a

aplicação de software e ferramentas de

software subjacente.

Oportunidades para uma solução

mais satisfatória poderia ser

perdida.

Fazendo com que o cliente e os

clientes deles aceitem a


desnecessariamente

1-14 Devido às diferenças de horários de

férias e/ou feriados.

Toda a equipe do projeto pode não

estar disponível em determinadas

épocas.

Fazendo com que o trabalho

seja refeito.

1-19 Devido à comunicação ruim por e-mail

ou voz (entrega lenta ou baixa

qualidade) a nível internacional.

As comunicações chaves pode ser

atrasadas.


declínio do projeto.

1-21 Devido à incompreensão das leis

trabalhistas e regulamentos

internacionais.


podem ser seguidos.

O que pode resultar em atraso

da disponibilidade de recursos.

1-23 Devido às diferenças de idiomas. O gerente de projeto pode não

comunicar adequadamente os

requisitos ou programações aos

membros da equipe.


atraso para o projeto ou

diminuição da qualidade do

sistema.

1-26 Devido à uma reorganização. As pessoas podem gastar tempo

discutindo o efeito da

reorganização.


projeto.

1-30 Devido à existência de dois projetos

colaborativos.


coordenação entre os projetos.

Causando desalinhamento de


1-32 Nem a administração nem as vendas

disseram ao cliente que algumas de

suas exigências podem não ser

cumpridas dentro do prazo.

O que pode significar que o cliente

pode não ajustar as exigências.

Resultando em menor lucro no

projeto enquanto a equipe

soma as exigências usando as


adicionais não incluídos na

proposta original.

1-33 Os membros da equipe estão

espalhados por todo o país.

O que pode causar um sofrimento

na comunicação.

Resultando em produtividade

sendo sacrificada.

1-34 O tempo de avaliação para

ferramentas/métodos é menor do que a

empresa já teve que lidar no passado.

Embora este calendário foi

aprovado pela administração, a

realidade de prazos pode não ser

adequada.

Resultando em atrasos.

1-54 Devido à ter uma equipe que não está

devidamente treinada nas ferramentas

de desenvolvimento.

Um progresso lento pode ocorrer. O que pode levar à falta de

uma data para lançamento.

1-58 Porque o fornecedor não criou um

protótipo de muitas das mudanças nas

ligações do usuário.

Algumas funcionalidades

esperadas do cliente podem estar

completamente em falta e não

serem descobertas até o teste de

aceitação.

Resultando em horas extras de

última hora.

173

Tabela 36: Fatores de Riscos de desenvolvimento de software citados por Mulcahy (2010)

(Cont.)


1-60 Porque o fornecedor tem um bom

entendimento do software de

aplicação, mas uma má compreensão

do negócio do cliente.


suposições irregulares sobre a

lógica do negócio que poderiam

revelar-se erradas.

E ter que ser reimplantado.

1-62 Critérios de aceitação do projeto não

são claros.

O que poderia levar à dificuldade

na obtenção de autorização em

marcos importantes.

Resultando em um trabalho

adicional que está além do

orçamento de custos.

1-65 Devido ao grande número de

fornecedores.



atrasar o projeto.

E fazer com que a conclusão

de prazos seja tardia.

1-76 Porque o fornecedor não tem processo

formal para relacionar as mudanças de

aplicação no projeto esquemático do

banco de dados.

Problemas no projeto do banco de

dados poderiam ser descobertos no

final do processo de

desenvolvimento.

Exigindo trabalho refeito para

corrigir as deficiências.

1-78 Porque o produto de software é

relativamente novo e a tecnologia de

projeto pode não ter sido comprovada.

Vários lançamentos podem ser

necessários antes que o produto

esteja estável.

O que pode levar a defeitos

funcionais ou técnicos.

1-90 Devido a um ambiente de

desenvolvimento instável.


ocorrer.

O que levaria a uma


Na Tabela 37 encontram-se os fatores de riscos considerados duplicados o que inclui os

fatores de riscos com sentidos semelhantes ou idênticos. Nas colunas 1 a 4 encontram-se os

fatores de riscos de Mulcahy selecionados a partir da primeira etapa. Na coluna 5 encontra-se

a identificação do fator de riscos de Webster (2005) considerado duplicado. Quando a coluna

5 estiver em branco significa que não foi identificada duplicação entre os fatores de riscos de

Mulcahy (2010) (Tabela 36) e Webster (2005) (Tabela 18).

Tabela 37: Fatores de Riscos considerados duplicados

Mulcahy (2010) Webster (2005)

ID CAUSA RISCO EFEITO ID

1-03 Porque há resistência

entre os usuários ao

substituir a sua

aplicação de software

atual por um novo

aplicativo de software/

sistema.

Pode haver sabotagem. O que resultaria em um

atraso do projeto.

2-50

1-05 Porque o fornecedor é

dependente do cliente

para dados de teste.


disponíveis logo que

necessário.

Fazendo testes

começarem mais tarde

do que deveriam para

atender a devida data

solicitada com

qualidade adequada.

2-12

Fonte: Mulcahy (2010) e Webster (2005) adaptado pelo autor

174

Tabela 37: Fatores de Riscos considerados duplicados (Cont.)



1-07 Porque o cliente é

completamente

dependente do

fornecedor para

conhecimento técnico

sobre a aplicação de

software e ferramentas

de software subjacente.

Oportunidades para uma

solução mais satisfatória

poderia ser perdida.

Fazendo com que o

cliente e os clientes

deles aceitem a


desnecessariamente

(REESCREVER: 2-46

incluindo problema de

dependência técnica)

1-14 Devido às diferenças de

horários de férias e/ou

feriados.

Toda a equipe do projeto

pode não estar disponível

em determinadas épocas.

Fazendo com que o

trabalho seja refeito.

2-22

1-19 Devido à comunicação

ruim por e-mail ou voz

(entrega lenta ou baixa

qualidade) a nível

internacional.

As comunicações chaves

pode ser atrasadas.

O que pode resultar em

um declínio do projeto.

1-21 Devido à

incompreensão das leis

trabalhistas e

regulamentos

internacionais.


podem ser seguidos.


atraso da

disponibilidade de

recursos.

2-48

1-23 Devido às diferenças de

idiomas.

O gerente de projeto pode

não comunicar

adequadamente os

requisitos ou programações

aos membros da equipe.


um atraso para o projeto

ou diminuição da

qualidade do sistema.

1-26 Devido à uma

reorganização.

As pessoas podem gastar

tempo discutindo o efeito

da reorganização.


projeto.

2-22

1-30 Devido à existência de

dois projetos

colaborativos.


coordenação entre os

projetos.

Causando

desalinhamento de


2-28

1-32 Nem a administração

nem as vendas disseram

ao cliente que algumas

de suas exigências

podem não ser

cumpridas dentro do

prazo.

O que pode significar que o

cliente pode não ajustar as

exigências.

Resultando em menor

lucro no projeto

enquanto a equipe soma

as exigências usando as


adicionais não incluídos

na proposta original.

2-46

1-33 Os membros da equipe

estão espalhados por

todo o país.

O que pode causar um

sofrimento na comunicação.

Resultando em

produtividade sendo

sacrificada.

(REESCREVER: 2-37

incluindo problema de

comunicação do item 1-

33)

1-34 O tempo de avaliação

para

ferramentas/métodos é

menor do que a

empresa já teve que

lidar no passado.

Embora este calendário foi

aprovado pela

administração, a realidade

de prazos pode não ser

adequada.

Resultando em atrasos. 2-42


175

Tabela 37: Fatores de Riscos considerados duplicados (Cont.)



1-54 Devido à ter uma

equipe que não está

devidamente treinada

nas ferramentas de

desenvolvimento.

Um progresso lento pode

ocorrer.

O que pode levar à falta

de uma data para

lançamento.

2-40

1-60 Porque o fornecedor

tem um bom

entendimento do

software de aplicação,

mas uma má

compreensão do

negócio do cliente.


suposições irregulares sobre

a lógica do negócio que

poderiam revelar-se erradas.

E ter que ser

reimplantado.

2-04

1-62 Critérios de aceitação

do projeto não são

claros.

O que poderia levar à

dificuldade na obtenção de

autorização em marcos

importantes.

Resultando em um

trabalho adicional que

está além do orçamento

de custos.

2-03

1-65 Devido ao grande

número de

fornecedores.



atrasar o projeto.

E fazer com que a

conclusão de prazos seja

tardia.

2-45

1-76 Porque o fornecedor não

tem processo formal

para relacionar as

mudanças de aplicação

no projeto esquemático

do banco de dados.

Problemas no projeto do

banco de dados poderiam

ser descobertos no final do

processo de

desenvolvimento.

Exigindo trabalho

refeito para corrigir as

deficiências.

2-32

1-78 Porque o produto de

software é relativamente

novo e a tecnologia de

projeto pode não ter

sido comprovada.

Vários lançamentos podem

ser necessários antes que o

produto esteja estável.

O que pode levar a

defeitos funcionais ou

técnicos.

2-11

1-90 Devido a um ambiente

de desenvolvimento

instável.


ocorrer.

O que levaria a uma


2-31


A terceira etapa seria a integração dos fatores de riscos dos autores, agrupando os

fatores de risco considerados semelhantes semanticamente. Um desafio nessa etapa seria a

descrição do fator de risco, levando-se em conta que os autores escreveram de forma

diferente. Diante disso e para manter uma mesma lógica ou linha de raciocínio, proceder-se-ia

a utilização dos fatores de risco do SEI (Tabela 16), seguindo o mesmo critério adotado por

Webster (2005).

Para os fatores de riscos considerados semelhantes semanticamente foi mantida a

redação sugerida por Webster (2005) por já ter sido realizado um estudo de diversos autores.

Conforme já citado anteriormente, quando a coluna 5 (Tabela 37) estiver em branco

significa que não foi identificada duplicação ou semelhança entre os fatores de riscos de

176

Mulcahy (2010) (Tabela 36) e Webster (2005) (Tabela 18). Para estes casos foi feita uma

redação unificando os textos das colunas 3, 4 e 5 (Tabela 37).

Os fatores de riscos 1-19 e 1-23 foram agrupados em um único fator de risco por tratar

de assuntos semelhantes. A nova redação é: Qualquer problema de comunicação em nível

internacional relativo a diferenças de idiomas.

O fator de risco 2-46 foi reescrito incluindo o fator de risco 1-07 em sua redação.

O fator de risco 2-37 foi reescrito incluindo o fator de risco 1-33 em sua redação.

A Tabela 38 apresenta a integração dos fatores de riscos para desenvolvimento de

software dos autores Webster (2005) e Mulcahy (2010), considerados semelhantes

semanticamente. Na primeira coluna ID aparece o identificador do fator de risco e na segunda

coluna a descrição do fator de risco integrado.

Tabela 38: Fatores de Riscos integrados para desenvolvimento de software


01 Requisitos instáveis

02 Requisitos incompletos.

03 Requisitos não claros (ambíguos / imprecisos).

04 Requisitos mal entendidos (não refletem as expectativas do cliente).

05 Adição de mais funcionalidades que o especificado / dar extras ao cliente.

06 Requisitos de desempenho não atendidos. Ex. Baixo desempenho.

07 Alto nível de complexibilidade técnica.

08 Desenvolvimento de interface do usuário inadequada.

09 Problemas de desempenho de tempo real (há tempos de respostas restritos).

10 Restrições referentes ao hardware designado. Ex.: capacidade de memória e tempo de

resposta real, acesso à base de dados e insuficiência de hardware.

11 Tecnologia nova / imatura (uso de novas tecnologias).

12 Inadequada preparação e realização dos testes. Ex.: instalações inadequadas, e tempo

insuficiente para realização dos testes, falta de dados precisos para testar as mudanças e


13 Falta de um acordo interativo entre os clientes e os desenvolvedores relativo às

especificações dos requisitos.

14 Inadequadas especificações. Ex.: especificações de sistema, hardware, software, interface,

requisitos de teste a qualquer nível com respeito à viabilidade de implementação e à

estabilidade dos atributos de qualidade, completude e clareza.

15 Modelos, processos, métodos e ferramentas de apoio selecionados inadequados para o

processo de desenvolvimento.

16 Falta / insuficiência de controle do processo de desenvolvimento. Ex.: uso do recurso,

medição do progresso referente à qualidade e metas de produtividade.

17 Controle do produto inadequado. Ex.: o produto final não corresponde às expectativas do

cliente.

18 Documentação / papelada excessiva.

19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta de estações de trabalho, espaço

de armazenamento no banco de dados insuficiente.

20 Pouca confiança no desenvolvimento do sistema devido à indisponibilidade / erro / mal

funcionamento dos componentes.

21 Pobre suporte ao sistema. Ex.: treinamento para utilização do sistema, acesso para usuários

especialistas ou consultores, conserto ou resolução de problemas por parte dos vendedores.

Fonte: Adaptado de Webster (2005) e Mulcahy (2010).

177

Tabela 38: Fatores de Riscos integrados para desenvolvimento de software (Cont.)


22 Planejamento inapropriado, incluindo construção e atualização do plano de contingência.

23 Papéis e responsabilidades de relacionamentos mal definidos ou mal entendidos.

24 Gerentes do desenvolvimento do software inexperientes ou ineficientes.

25 Fraca interação (comunicação) do gerente com todos os envolvidos do projeto.

26 Falhas em gerenciar as expectativas do usuário final.

27 Ausência de um líder.

28 Falta de metodologia efetiva de gerenciamento de projetos.

29 Fraco monitoramento do progresso das atividades relacionadas ao projeto. Ex.:

acompanhamento do relatório de status e manutenção de métricas progressivas.

30 Treinamento inadequado ou indisponível.

31 Falta de procedimentos, programas adequados e recursos para assegurar a garantia da

qualidade.

32 Gerência de Configuração inadequada.

33 Mudanças contínuas no objetivo e escopo do projeto.

34 Erro ao estimar (tempo, custo e esforço).

35 Métricas inadequadas / inexatas.

36 Falta espírito de equipe. Os conflitos requerem intervenção da gerência.

37 Problema de comunicação devido à falta de conhecimento da missão, metas do projeto,

informações técnicas entre pares e gerentes e devido a distância (membros da equipe


38 Baixa moral/ falta de compromisso devido ao baixo nível de entusiasmo afetando assim a

produtividade e criatividade. As pessoas não se sentem reconhecidas e recompensadas pelos

superiores.

39 Falta de maturidade / instabilidade organizacional.

40 Baixa produtividade da equipe.

41 Cronograma irreal ou inadequado baseado nos eventos internos e externos do sistema.

42 Pressão excessiva de prazo.

43 Problemas de pessoal. Ex.: falta experiência, pouco conhecimento, falta de habilidade, falta

de pessoal e indisponibilidade de pessoas chaves.

44 Orçamento insuficiente ou instável baseado nos eventos internos e externos do sistema.

45 Instabilidade (rotatividade) e falta de continuidade das pessoas nos projetos.

46 Qualquer problema com o cliente, tais como: demora na aprovação de documentos,

comunicação pobre, resistência à mudança, falta de comprometimento, falta de cooperação,

conflitos entre clientes e departamentos, dependência técnica.

47 Problemas relacionados aos contratos associados.

48 Qualquer problema associado a subcontratação.

49 Fatores políticos (companhia, clientes, contratantes associados e subcontratantes) que

causam problemas para o desenvolvimento do projeto.

50 Qualquer problema com o usuário, tais como: falta de envolvimento / comprometimento,

conflito entre usuários e departamentos, falta de entendimento com relação ao

funcionamento do sistema, resistência a mudanças e falha em obter o comprometimento do

usuário.

51 Falta de comprometimento da gerência sênior

52 Qualquer problema de comunicação em nível internacional relativo a diferenças de idiomas.

Fonte: Adaptado de Webster (2005) e Mulcahy (2010).

178

APÊNDICE IV - Análise dos fatores de riscos segundo as empresas pesquisadas.

Neste apêndice são apresentadas as respostas referentes à Parte IV do roteiro de análise

de riscos, segundo as empresas pesquisadas.

Para manter o sigilo das empresas pesquisadas, a pedido delas, estas serão identificadas

como empresas: A, B, C, D, E e F, conforme definido no Capítulo 4 deste trabalho.

Tabela 39: Análise dos fatores de riscos segundo a empresa “A”


FASES do Ciclo de Vida

PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

44

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


x x

3 4 4 3 11 33

2 Requisitos incompletos. x

5 1 1 1 3 15

3 Requisitos não claros (ambíguos / imprecisos). x

5 1 1 1 3 15


expectativas do cliente). x

5 1 2 1 4 20

5 Adição de mais funcionalidades que o especificado

/ dar extras ao cliente. x

x

3 3 4 3 10 30

6 Requisitos de desempenho não atendidos. Ex.

Baixo desempenho. x x

4 4 4 4 12 48


x

3 4 4 4 12 36


inadequada. x

1 1 4 1 6 6


tempos de respostas restritos). x

2 3 4 3 10 20

10 Restrições referentes ao hardware designado. Ex.:

capacidade de memória e tempo de resposta real,

acesso à base de dados e insuficiência de

hardware.

x x

2 3 4 3 10 20


tecnologias). x x

3 4 4 4 12 36


44

Outra: “Avaliação pós-encerramento”. Fase utilizada somente pela empresa “F”.

179

Tabela 39: Análise dos fatores de riscos segundo a empresa “A” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

45

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

12 Inadequada preparação e realização dos testes. Ex.:

instalações inadequadas, e tempo insuficiente para

realização dos testes, falta de dados precisos para

testar as mudanças e utilização de método de teste

inadequado.

x

3 1 3 2 6 18

13 Falta de um acordo interativo entre os clientes e os

desenvolvedores relativo às especificações dos

requisitos. x x

3 3 4 4 11 33

14 Inadequadas especificações. Ex.: especificações de

sistema, hardware, software, interface, requisitos

de teste a qualquer nível com respeito à viabilidade

de implementação e à estabilidade dos atributos de

qualidade, completude e clareza.

x x

3 4 4 3 11 33

15 Os modelos, processos, métodos e ferramentas de

apoio selecionados inadequados para o processo de

desenvolvimento. x x

2 1 4 4 9 18

16 Falta / insuficiência de controle do processo de

desenvolvimento. Ex.: uso do recurso, medição do

progresso referente à qualidade e metas de

produtividade.

x x

3 3 4 3 10 30

17 Controle do produto inadequado. Ex.: o produto

final não corresponde às expectativas do cliente. x

1 4 4 4 12 12

18 Documentação / papelada excessiva. x x x x

2 2 3 3 8 16

19 Capacidade insuficiente do sistema desenvolvido.

Ex.: Falta de estações de trabalho, espaço de

armazenamento no banco de dados insuficiente. x

x

1 5 5 4 14 14

20 Pouca confiança no desenvolvimento do sistema

devido à indisponibilidade / erro / mal

funcionamento dos componentes. x x x

2 5 5 4 14 28

21 Pobre suporte ao sistema. Ex.: treinamento para

utilização do sistema, acesso para usuários

especialistas ou consultores, conserto ou resolução

de problemas por parte dos vendedores.

x

1 5 5 3 13 13

22 Planejamento inapropriado, incluindo construção e

atualização do plano de contingência. x

x

3 3 4 3 10 30

23 Papéis e responsabilidades de relacionamentos mal

definidos ou mal entendidos. x x

1 3 3 5 11 11


inexperientes ou ineficientes. x

3 4 4 4 12 36


45


180




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

46

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

25 Fraca interação (comunicação) do gerente com

todos os envolvidos do projeto. x x x x

2 5 5 5 15 30

26 Falhas em gerenciar as expectativas do usuário

final. x

3 3 4 3 10 30

27 Ausência de um líder. x x

1 5 5 4 14 14

28 Falta de metodologia efetiva de gerenciamento de

projetos. x x x

4 3 3 5 11 44

29 Fraco monitoramento do progresso das atividades

relacionadas ao projeto. Ex.: acompanhamento do

relatório de status e manutenção de métricas

progressivas.

x x x x

2 3 2 3 8 16


x

1 1 3 1 5 5

31 Falta de procedimentos, programas adequados e

recursos para assegurar a garantia da qualidade. x

2 4 3 3 10 20

32 Gerência de Configuração inadequada. x x

2 4 4 4 12 24


projeto. x

x

3 4 2 3 9 27


x x x

4 4 3 5 12 48


x x 4 3 3 4 10 40

36 Falta espírito de equipe. Os conflitos requerem

intervenção da gerência. x x

4 2 2 4 8 32




devido a distância (membros da equipe espalhados

por todo o pais).

x x x

1 2 2 2 6 6

38 Baixa moral/ falta de compromisso devido ao




superiores.

x x x

4 3 5 4 12 48

39 Falta de maturidade / instabilidade organizacional. x x

2 4 5 5 14 28

40 Baixa produtividade da equipe. x x x x

3 3 3 5 11 33

41 Cronograma irreal ou inadequado baseado nos

eventos internos e externos do sistema. x x x

5 4 3 5 12 60


x x

2 3 3 4 10 20


46


181




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

47

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


pouco conhecimento, falta habilidade, falta de

pessoal e indisponibilidade de pessoas chaves. x x

5 4 5 5 14 70

44 Orçamento insuficiente ou instável baseado nos

eventos internos e externos do sistema. x x

5 4 4 4 12 60

45 Instabilidade (rotatividade) e falta de continuidade

das pessoas nos projetos. x x x

3 4 3 5 12 36



comunicação pobre, resistência à mudança, falta

de comprometimento, falta de cooperação,

conflitos entre clientes e departamentos,

dependência técnica.

x x x

3 3 4 5 12 36


x x

3 4 2 4 10 30


x x

3 3 2 4 9 27

49 Fatores políticos (companhia, clientes, contratantes

associados e subcontratantes) que causam

problemas para o desenvolvimento do projeto. x x x

4 4 3 4 11 44

50 Qualquer problema com o usuário, tais como: falta

de envolvimento / comprometimento, conflito

entre usuários e departamentos, falta de

entendimento com relação ao funcionamento do

sistema, resistência a mudanças e falha em obter o


x

x x

3 3 4 3 10 30

51 Falta de comprometimento da gerência sênior x x x x

1 4 3 4 11 11

52 Qualquer problema de comunicação em nível


0 0


47


182

Tabela 40: Análise dos fatores de riscos segundo a empresa “B”



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

41

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

1 Requisitos instáveis x x

4 4 4 4 12 48

2 Requisitos incompletos. x x

4 4 4 4 12 48

3 Requisitos não claros (ambíguos / imprecisos). x x

4 4 4 4 12 48


expectativas do cliente). x x

4 4 4 4 12 48


especificado / dar extras ao cliente. x

2 4 1 4 9 18


Baixo desempenho. x

2 2 2 2 6 12


x

3 4 4 4 12 36


inadequada. x

x

3 4 3 4 11 33



x

2 3 1 3 7 14

10 Restrições referentes ao hardware designado.

Ex.: capacidade de memória e tempo de resposta

real, acesso à base de dados e insuficiência de

hardware.

x

2 3 1 3 7 14


tecnologias). x x

3 4 3 4 11 33

12 Inadequada preparação e realização dos testes.





x x

3 4 3 4 11 33

13 Falta de um acordo interativo entre os clientes e

os desenvolvedores relativo às especificações dos

requisitos. x x

2 5 4 5 14 28

14 Inadequadas especificações. Ex.: especificações

de sistema, hardware, software, interface,

requisitos de teste a qualquer nível com respeito à

viabilidade de implementação e à estabilidade

dos atributos de qualidade, completude e clareza.

x

2 5 4 5 14 28


apoio selecionados inadequados para o processo

de desenvolvimento. x x x x x

2 3 3 3 9 18




produtividade.

x

2 2 2 2 6 12

Fonte: Elaborado pelo autor a partida da pesquisa de campo

183

Tabela 40: Análise dos fatores de riscos segundo a empresa “B” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

41

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L



3 3 3 3 9 27


x x

1 3 1 3 7 7




x

1 3 1 3 7 7



funcionamento dos componentes. x

x

2 3 3 3 9 18



especialistas ou consultores, conserto ou

resolução de problemas por parte dos

vendedores.

x

1 1 1 1 3 3

22 Planejamento inapropriado, incluindo construção

e atualização do plano de contingência. x x

2 3 3 3 9 18

23 Papéis e responsabilidades de relacionamentos

mal definidos ou mal entendidos. x x

x

1 1 3 1 5 5


inexperientes ou ineficientes. x x x x x

2 4 4 4 12 24


todos os envolvidos do projeto. x x

x

2 3 3 3 9 18


final. x x

3 3 3 3 9 27


x

2 3 4 3 10 20


projetos. x x x x x

2 4 4 4 12 24


relacionadas ao projeto. Ex.: acompanhamento

do relatório de status e manutenção de métricas

progressivas.

x

2 1 1 1 3 6


x x

2 4 4 4 12 24


recursos para assegurar a garantia da qualidade. x x

2 4 4 4 12 24


x x

2 2 3 2 7 14


projeto. x x x

3 4 1 4 9 27

34 Erro ao estimar (tempo, custo e esforço). x x

3 4 1 4 9 27


184




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

41

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

35 Métricas inadequadas / inexatas. x x

2 3 1 3 7 14


intervenção da gerência. x

1 1 1 1 3 3






x x

x

2 3 3 3 9 18





superiores.

x

2 2 3 2 7 14


organizacional. x x

2 2 3 2 7 14


x x

2 4 2 4 10 20


eventos internos e externos do sistema. x

3 4 3 4 11 33


x

4 4 4 4 12 48




2 4 4 4 12 24



2 1 4 1 6 12


continuidade das pessoas nos projetos. x

2 3 3 3 9 18







x

x

3 3 3 3 9 27

47 Problemas relacionados aos contratos associados. x x

2 1 1 1 3 6


0 0


185




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a:

41

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L




projeto.

x x

2 1 1 1 3 6

50 Qualquer problema com o usuário, tais como:


conflito entre usuários e departamentos, falta de


sistema, resistência a mudanças e falha em obter

o comprometimento do usuário.

x x x

3 3 3 3 9 27


0 0


internacional relativo a diferenças de idiomas. x x x x x

3 4 4 4 12 36


Tabela 41: Análise dos fatores de riscos segundo a empresa “C”



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


x

3 4 4 4 12 36

2 Requisitos incompletos. x x

x

3 3 3 3 9 27

3 Requisitos não claros (ambíguos / imprecisos). x x

x

2 3 3 3 9 18



x

2 3 3 3 9 18


especificado / dar extras ao cliente. x x

x

2 2 2 2 6 12


Baixo desempenho. x x x

3 4 4 4 12 36


x x x

2 5 5 5 15 30


186

Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


inadequada. x x x

2 3 3 3 9 18


tempos de respostas restritos). x x x

2 4 4 4 12 24




hardware.

x x x

2 3 3 3 9 18


tecnologias). x x x x

3 4 4 4 12 36






x x x

4 4 4 4 12 48



requisitos. x x x x

4 3 3 3 9 36






x x x

2 2 2 2 6 12



de desenvolvimento. x x

3 3 3 3 9 27




produtividade.

x x

x

3 3 3 3 9 27



x

3 3 3 3 9 27


x

x

4 2 2 2 6 24



armazenamento no banco de dados insuficiente. x x

3 3 3 3 9 27


187




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L



funcionamento dos componentes. x x x

2 3 3 3 9 18





vendedores.

x x

2 2 2 2 6 12



x

4 3 3 3 9 36


mal definidos ou mal entendidos. x x

x

4 3 3 3 9 36


inexperientes ou ineficientes. x x

x

2 4 4 4 12 24


todos os envolvidos do projeto. x x x x x

3 3 3 3 9 27


final. x x x x x

3 3 3 3 9 27

27 Ausência de um líder. x x x x x 3 3 3 3 9 27


projetos. x x x x x

4 2 3 3 8 32




progressivas.

x

4 2 3 3 8 32


x x

4 2 3 3 8 32


recursos para assegurar a garantia da qualidade. x x x

4 2 3 3 8 32


x x x

5 2 4 3 9 45


projeto. x x x x x

3 4 3 4 11 33


x

x

4 4 2 4 10 40


x

x

4 4 2 4 10 40


intervenção da gerência. x x x

3 2 4 4 10 30


188




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L






x x

3 2 4 4 10 30





superiores.

x x x

3 3 4 4 11 33


organizacional. x x x x x

3 3 3 3 9 27


x

3 4 4 4 12 36



x

4 4 3 4 11 44


x x

3 3 5 3 11 33




3 3 4 4 11 33



x

2 4 2 3 9 18


continuidade das pessoas nos projetos. x x

3 4 4 4 12 36







x x x x x

4 3 2 4 9 36


x

x x 3 4 3 4 11 33


x

x x 3 4 3 4 11 33




projeto.

x x x

3 3 3 3 9 27


189




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L







x x

3 3 3 3 9 27

51 Falta de comprometimento da gerência sênior x x

x

2 3 3 3 9 18



0 0


Tabela 42: Análise dos fatores de riscos segundo a empresa “D”


FASES do Ciclo de Vida P

RO

BA

BIL

IDA

DE

IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.i

nic

iaçã

o

2.p

lan

ejam

ento

3.e

xec

uçã

o

4.m

on

itor.

/ c

on

tro

le

5.e

nce

rram

ento

6.o

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


4 5 3 4 12 48


3 4 2 3 9 27


x

3 4 2 3 9 27



3 4 2 3 9 27



4 5 3 4 12 48



3 4 2 3 9 27


x

3 4 2 3 9 27


inadequada. x

2 3 1 2 6 12


190

Tabela 42: Análise dos fatores de riscos segundo a empresa “D” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.i

nic

iaçã

o

2.p

lan

ejam

ento

3.e

xec

uçã

o

4.m

on

itor.

/ c

on

tro

le

5.e

nce

rram

ento

6.o

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L



x

3 4 2 3 9 27




hardware.

x

x

3 4 2 3 9 27


tecnologias). x x

4 5 3 4 12 48






x x

x

3 4 2 3 9 27



requisitos. x x

3 4 2 3 9 27






x

4 5 3 4 12 48




3 4 2 3 9 27




produtividade.

x x x x x

3 4 2 3 9 27


final não corresponde às expectativas do cliente. x x x x x

4 5 3 4 12 48


x x x

3 4 2 3 9 27




x

3 4 2 3 9 27




3 4 2 3 9 27


191




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.i

nic

iaçã

o

2.p

lan

ejam

ento

3.e

xec

uçã

o

4.m

on

itor.

/ c

on

tro

le

5.e

nce

rram

ento

6.o

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L





vendedores.

x

4 5 3 4 12 48


e atualização do plano de contingência. x

4 5 3 4 12 48


mal definidos ou mal entendidos. x

3 4 2 3 9 27


inexperientes ou ineficientes. x

x

3 4 2 3 9 27


todos os envolvidos do projeto. x

2 3 1 2 6 12


final. x x x

5 5 4 5 14 70



projetos. x x x x x

3 4 2 3 9 27




progressivas.

x

4 5 3 4 12 48


x x

2 3 1 2 6 12


recursos para assegurar a garantia da qualidade. x x

3 4 2 3 9 27

32 Gerência de Configuração inadequada. x x x x x 4 4 3 4 11 44


projeto. x x x

5 5 4 5 14 70

34 Erro ao estimar (tempo, custo e esforço). x x

4 5 3 4 12 48

35 Métricas inadequadas / inexatas. x x

4 5 3 4 12 48


intervenção da gerência. x x

3 4 2 3 9 27






x

3 4 2 3 9 27


192




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.i

nic

iaçã

o

2.p

lan

ejam

ento

3.e

xec

uçã

o

4.m

on

itor.

/ c

on

tro

le

5.e

nce

rram

ento

6.o

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L





superiores.

x

3 4 2 3 9 27



3 4 2 3 9 27


x

3 4 2 3 9 27



3 4 2 3 9 27


x x

2 3 1 2 6 12



pessoal e indisponibilidade de pessoas chaves. x x x x x

3 4 2 3 9 27



3 4 2 3 9 27


continuidade das pessoas nos projetos. x

4 5 3 4 12 48







x x

3 4 2 3 9 27


x x x x 4 5 3 4 12 48


x x x x 4 5 3 4 12 48




projeto.

x x x x x

3 4 2 3 9 27







x x x

3 4 2 3 9 27


x x

3 4 2 3 9 27


internacional relativo a diferenças de idiomas. x x x x x

4 5 3 4 12 48


193

Tabela 43: Análise dos fatores de riscos segundo a empresa “E”



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

1 Requisitos instáveis x x x

4 4 4 5 13 52

2 Requisitos incompletos. x x x

4 4 4 5 13 52

3 Requisitos não claros (ambíguos / imprecisos). x x x

3 4 4 5 13 39


expectativas do cliente). x x x

3 4 4 5 13 39



4 4 4 5 13 52



2 3 4 3 10 20

7 Alto nível de complexibilidade técnica. x x x

3 3 3 3 9 27


inadequada. x x

2 3 5 3 11 22


tempos de respostas restritos). x x

2 3 5 3 11 22




hardware.

x x

2 2 4 3 9 18


tecnologias). x x x

3 3 3 3 9 27






x x x

3 3 4 4 11 33



requisitos. x x x

3 3 4 4 11 33






x x x

4 4 4 5 13 52




3 3 3 3 9 27


194

Tabela 43: Análise dos fatores de riscos segundo a empresa “E” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L




produtividade.

x x x x x

3 3 3 3 9 27


final não corresponde às expectativas do cliente. x x

2 3 5 5 13 26

18 Documentação / papelada excessiva. x x

2 2 3 3 8 16




x

2 2 4 4 10 20




x

2 2 4 4 10 20





vendedores.

x

x

2 2 3 3 8 16



x

3 3 4 4 11 33


mal definidos ou mal entendidos. x x x x x

3 3 4 4 11 33


inexperientes ou ineficientes. x x x x x

2 3 4 4 11 22


todos os envolvidos do projeto. x x x x x

1 2 3 3 8 8


final. x x x x x

1 2 3 3 8 8



projetos. x x x x x

2 2 3 3 8 16




progressivas.

x x x x x

2 2 3 3 8 16


x 2 4 2 2 8 16


recursos para assegurar a garantia da qualidade. x x x x x

2 4 4 3 11 22


x x x 2 3 3 3 9 18


195




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


projeto. x x x x

4 3 4 4 11 44

34 Erro ao estimar (tempo, custo e esforço). x x x x x 3 4 3 4 11 33


x x

2 3 3 3 9 18


intervenção da gerência. x x x x

2 3 3 3 9 18






x x x x x

2 3 3 3 9 18





superiores.

x x x x x

1 2 2 2 6 6



2 2 2 2 6 12

40 Baixa produtividade da equipe. x x x x x 2 3 3 3 9 18


eventos internos e externos do sistema. x x x x x

2 3 4 4 11 22

42 Pressão excessiva de prazo. x x x x x 4 3 4 4 11 44



pessoal e indisponibilidade de pessoas chaves. x x x x x

2 4 4 4 12 24


eventos internos e externos do sistema.

0 0


continuidade das pessoas nos projetos. x x x x x

2 3 3 3 9 18







x x x x x

3 3 3 3 9 27


196




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L


x 2 2 3 3 8 16


0 0




projeto.

x x x x x

2 3 3 3 9 18







x x x x x

2 3 3 3 9 18

51 Falta de comprometimento da gerência sênior x x x x x 1 2 2 2 6 6



0 0


Tabela 44: Análise dos fatores de riscos segundo a empresa “F”



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

1 Requisitos instáveis x x 4 4 3 4 11 44

2 Requisitos incompletos. x x 2 3 4 2 9 18

3 Requisitos não claros (ambíguos / imprecisos). x x 3 3 4 2 9 27


expectativas do cliente). x x 2 2 4 2 8 16


especificado / dar extras ao cliente. x x 4 4 3 5 12 48


Baixo desempenho. x x 2 3 5 2 10 20


197

Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)



PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

7 Alto nível de complexibilidade técnica. x x x x 4 3 5 3 11 44


inadequada. x 2 2 4 2 8 16


tempos de respostas restritos). x 2 2 4 2 8 16




hardware.

x 1 1 1 1 3 3


tecnologias). 0 0






x x 4 4 5 5 14 56



requisitos. x x 1 2 3 4 9 9






x x 1 2 3 4 9 9



de desenvolvimento. x x x x x x 1 2 2 3 7 7




produtividade.

x x x x x x 1 1 1 1 3 3


final não corresponde às expectativas do cliente. x x 3 2 4 1 7 21

18 Documentação / papelada excessiva. x x x x 1 2 3 3 8 8



armazenamento no banco de dados insuficiente. x x 1 3 1 1 5 5


198




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L



funcionamento dos componentes. x x x 2 2 4 1 7 14





vendedores.

x 1 1 3 1 5 5


e atualização do plano de contingência. x x 3 4 2 5 11 33


mal definidos ou mal entendidos. 0 0


inexperientes ou ineficientes. x x x 2 2 1 5 8 16


todos os envolvidos do projeto. x x 1 1 1 1 3 3


final. x x 1 1 1 1 3 3

27 Ausência de um líder. x x x x x x 2 2 4 2 8 16


projetos. 0 0




progressivas.

x 4 3 2 5 10 40

30 Treinamento inadequado ou indisponível. x x x x x x 4 3 2 5 10 40


recursos para assegurar a garantia da qualidade. x x x x x x 3 2 2 5 9 27

32 Gerência de Configuração inadequada. x x x x x x 1 1 1 2 4 4


projeto. x x 5 4 2 5 11 55

34 Erro ao estimar (tempo, custo e esforço). x x 2 2 1 2 5 10


199




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

35 Métricas inadequadas / inexatas. x 1 1 1 1 3 3


intervenção da gerência. x x 1 1 1 1 3 3






0 0





superiores.

x x 2 1 3 3 7 14


organizacional. x x x x x x 3 2 2 2 6 18

40 Baixa produtividade da equipe. x x 3 5 4 5 14 42


eventos internos e externos do sistema. x 2 1 1 5 7 14


x x x 4 4 4 5 13 52



pessoal e indisponibilidade de pessoas chaves.

x 4 4 5 5 14 56


eventos internos e externos do sistema. x x x 3 4 4 5 13 39


continuidade das pessoas nos projetos. x x 2 3 5 5 13 26







x x x 1 1 3 1 5 5

47 Problemas relacionados aos contratos associados. 0 0


200




PR

OB

AB

ILID

AD

E IMPACTO

CL

AS

SIF

ICA

ÇÃ

O

1.I

nic

iaçã

o

2.P

lan

ejam

ento

3.E

xec

uçã

o

4.M

on

ito

r. /

Co

ntr

ole

5.E

nce

rram

ento

6.O

utr

a: 4

1

Cu

sto

Qu

alid

ade

Pra

zo

TO

TA

L

48 Qualquer problema associado a subcontratação. 0 0




projeto.

x x 3 1 3 3 7 21







x x 3 2 3 5 10 30

51 Falta de comprometimento da gerência sênior x x x x x x 1 1 3 3 7 7


internacional relativo a diferenças de idiomas. x 0 0


201

APÊNDICE V- Classificação dos fatores de riscos segundo as fases do ciclo de vida do

projeto, de acordo com as empresas pesquisadas.

Aqui é apresentada a classificação dos fatores de riscos segundo as empresas

pesquisadas, desde que citados por pelo menos uma empresa.

Alguns fatores de riscos não foram citados pelas empresas em algumas fases do ciclo de

vida dos projetos. Neste caso eles foram retirados das tabelas abaixo, porém foi mantida a

identificação (ID) original deles.

Na Tabela 45 os fatores de riscos 12, 20 e 48 não foram citados pelas empresas

pesquisadas. Para saber quais são estes fatores de riscos ver os mesmos na Tabela 38.


Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE DE INICIAÇÃO

EMPRESAS

A B C D E F


x x x x x

2 Requisitos incompletos. x x x x x x

3 Requisitos não claros (ambíguos / imprecisos). x x x

x x

4 Requisitos mal entendidos (não refletem as expectativas do

cliente). x x x

x x

5 Adição de mais funcionalidades que o especificado / dar

extras ao cliente. x

6 Requisitos de desempenho não atendidos. Ex. Baixo

desempenho. x


x x


x

9 Problemas de desempenho de tempo real (há tempos de

respostas restritos). x

10 Restrições referentes ao hardware designado. Ex.: capacidade

de memória e tempo de resposta real, acesso à base de dados

e insuficiência de hardware. x

11 Tecnologia nova / imatura (uso de novas tecnologias). x

x


desenvolvedores relativo às especificações dos requisitos. x

x

x x

14 Inadequadas especificações. Ex.: especificações de sistema,

hardware, software, interface, requisitos de teste a qualquer

nível com respeito à viabilidade de implementação e à


x x


202


Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)


FASE DE INICIAÇÃO

EMPRESAS

A B C D E F

15 Os modelos, processos, métodos e ferramentas de apoio

selecionados inadequados para o processo de

desenvolvimento. x x x x x x


desenvolvimento. Ex.: uso do recurso, medição do progresso

referente à qualidade e metas de produtividade. x x x x

17 Controle do produto inadequado. Ex.: o produto final não

corresponde às expectativas do cliente. x

x

18 Documentação / papelada excessiva. x

x x

19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta

de estações de trabalho, espaço de armazenamento no banco

de dados insuficiente. x

21 Pobre suporte ao sistema. Ex.: treinamento para utilização do

sistema, acesso para usuários especialistas ou consultores,

conserto ou resolução de problemas por parte dos vendedores. x


atualização do plano de contingência. x x

23 Papéis e responsabilidades de relacionamentos mal definidos

ou mal entendidos. x x x

x

24 Gerentes do desenvolvimento do software inexperientes ou

ineficientes. x x x

x x

25 Fraca interação (comunicação) do gerente com todos os

envolvidos do projeto. x x x

x


x x

x x

27 Ausência de um líder. x

x x x x

28 Falta de metodologia efetiva de gerenciamento de projetos.

x x x x


relacionadas ao projeto. Ex.: acompanhamento do relatório de

status e manutenção de métricas progressivas.

x


x

31 Falta de procedimentos, programas adequados e recursos para

assegurar a garantia da qualidade. x x

32 Gerência de Configuração inadequada. x

x

x


x x

x


x

x x


x

x

36 Falta espírito de equipe. Os conflitos requerem intervenção da

gerência. x


203


Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)


FASE DE INICIAÇÃO

EMPRESAS

A B C D E F

37 Problema de comunicação devido à falta de conhecimento da

missão, metas do projeto, informações técnicas entre pares e

gerentes e devido a distância (membros da equipe espalhados

por todo o pais).

x

x

38 Baixa moral/ falta de compromisso devido ao baixo nível de

entusiasmo afetando assim a produtividade e criatividade. As

pessoas não se sentem reconhecidas e recompensadas pelos

superiores.

x

39 Falta de maturidade / instabilidade organizacional. x

x x x x

40 Baixa produtividade da equipe. x

x

41 Cronograma irreal ou inadequado baseado nos eventos

internos e externos do sistema. x

x


x

43 Problemas de pessoal. Ex.: falta experiência, pouco

conhecimento, falta habilidade, falta de pessoal e

indisponibilidade de pessoas chaves. x x

44 Orçamento insuficiente ou instável baseado nos eventos


x

45 Instabilidade (rotatividade) e falta de continuidade das

pessoas nos projetos. x

46 Qualquer problema com o cliente, tais como: demora na

aprovação de documentos, comunicação pobre, resistência à

mudança, falta de comprometimento, falta de cooperação,


x

x


x


associados e subcontratantes) que causam problemas para o

desenvolvimento do projeto. x x x x

50 Qualquer problema com o usuário, tais como: falta de

envolvimento / comprometimento, conflito entre usuários e

departamentos, falta de entendimento com relação ao

funcionamento do sistema, resistência a mudanças e falha em

obter o comprometimento do usuário.

x x

x

51 Falta de comprometimento da gerência sênior x

x

x x

52 Qualquer problema de comunicação em nível internacional

relativo a diferenças de idiomas. x

x


204

Na Tabela 46 todos fatores de riscos foram citados pelas empresas pesquisadas.


Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE DE PLANEJAMENTO

EMPRESAS

A B C D E F


x x x x


x x

x


x x x x


cliente). x x x x

5 Adição de mais funcionalidades que o especificado / dar

extras ao cliente. x

x x x


desempenho. x x

7 Alto nível de complexibilidade técnica. x

x

x x


x

x


respostas restritos). x

x


de memória e tempo de resposta real, acesso à base de dados e

insuficiência de hardware.

x

x

11 Tecnologia nova / imatura (uso de novas tecnologias). x x x x

12 Inadequada preparação e realização dos testes. Ex.:

instalações inadequadas, e tempo insuficiente para realização

dos testes, falta de dados precisos para testar as mudanças e


x x x x x


desenvolvedores relativo às especificações dos requisitos. x x x x x





x

x

x



desenvolvimento. x x x x x x



referente à qualidade e metas de produtividade. x x x x


corresponde às expectativas do cliente. x x

18 Documentação / papelada excessiva. x x x x x x

19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta

de estações de trabalho, espaço de armazenamento no banco

de dados insuficiente. x

x x

x

20 Pouca confiança no desenvolvimento do sistema devido à

indisponibilidade / erro / mal funcionamento dos

componentes. x

x

x


205


Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)



EMPRESAS

A B C D E F



conserto ou resolução de problemas por parte dos vendedores.

x


atualização do plano de contingência. x x x x x x


ou mal entendidos. x x x x x


ineficientes. x x x x x


envolvidos do projeto. x x x

x x


x x x x


x x x x

28 Falta de metodologia efetiva de gerenciamento de projetos. x x x x x


relacionadas ao projeto. Ex.: acompanhamento do relatório de

status e manutenção de métricas progressivas.

x

x


x x

x


assegurar a garantia da qualidade. x x x

x x

32 Gerência de Configuração inadequada. x x x x

x

33 Mudanças contínuas no objetivo e escopo do projeto. x x x x x

34 Erro ao estimar (tempo, custo e esforço). x x x x x x


x x x x


gerência. x x x




por todo o pais).

x x

x x




superiores.

x

x

x

39 Falta de maturidade / instabilidade organizacional. x x x x x x

40 Baixa produtividade da equipe. x x

x x


internos e externos do sistema. x x x x x x


x

x x x




x x


206


Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)



EMPRESAS

A B C D E F


internos e externos do sistema. x x x x

x

45 Instabilidade (rotatividade) e falta de continuidade das

pessoas nos projetos. x

x





x x x

x x

47 Problemas relacionados aos contratos associados. x x x x


x x


associados e subcontratantes) que causam problemas para o

desenvolvimento do projeto. x x x x x x






x x x x x


x x x x



x


Na Tabela 47 o fator de riscos 21 não foi citado pelas empresas pesquisadas. Para saber

qual é este fator de riscos ver o mesmo na Tabela 38.


Execução do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE DE EXECUÇÃO

EMPRESAS

A B C D E F

1 Requisitos instáveis x

x x


x x


x x


cliente). x x x

5 Adição de mais funcionalidades que o especificado / dar extras

ao cliente. x

x x x


207


Execução do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)


FASE DE EXECUÇÃO

EMPRESAS

A B C D E F


desempenho. x

x x

x


x x x x x


x x x x


respostas restritos). x x x x



insuficiência de hardware. x x x x x

11 Tecnologia nova / imatura (uso de novas tecnologias).

x x x x

12 Inadequada preparação e realização dos testes. Ex.: instalações

inadequadas, e tempo insuficiente para realização dos testes,

falta de dados precisos para testar as mudanças e utilização de

método de teste inadequado.

x x x x x


desenvolvedores relativo às especificações dos requisitos. x x x x





x x x x x


selecionados inadequados para o processo de desenvolvimento.

x

x x x



referente à qualidade e metas de produtividade. x x

x x x


corresponde às expectativas do cliente. x

18 Documentação / papelada excessiva. x x

x

x

19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta de

estações de trabalho, espaço de armazenamento no banco de

dados insuficiente. x

x x


indisponibilidade / erro / mal funcionamento dos componentes. x x x x x x

22 Planejamento inapropriado, incluindo construção e atualização

do plano de contingência. x


ou mal entendidos. x


ineficientes. x

x


envolvidos do projeto. x

x

x


208




FASE DE EXECUÇÃO

EMPRESAS

A B C D E F


x x x


x x x x x


29 Fraco monitoramento do progresso das atividades relacionadas

ao projeto. Ex.: acompanhamento do relatório de status e

manutenção de métricas progressivas. x x

x


x x x

x


assegurar a garantia da qualidade. x x x x x


x x x x x


x x x x x

34 Erro ao estimar (tempo, custo e esforço). x

x


x


gerência. x x x x x x




por todo o pais).

x

x

x




superiores.

x x x x x x

39 Falta de maturidade / instabilidade organizacional.

x x x x x

40 Baixa produtividade da equipe. x x x x x x

41 Cronograma irreal ou inadequado baseado nos eventos internos

e externos do sistema. x

x

42 Pressão excessiva de prazo. x

x x x x



indisponibilidade de pessoas chaves. x x x x x x



x

45 Instabilidade (rotatividade) e falta de continuidade das pessoas

nos projetos. x x x x x x





x

x x x x

47 Problemas relacionados aos contratos associados. x

x

48 Qualquer problema associado a subcontratação. x

x


209




FASE DE EXECUÇÃO

EMPRESAS

A B C D E F

49 Fatores políticos (companhia, clientes, contratantes associados

e subcontratantes) que causam problemas para o

desenvolvimento do projeto. x

x x x






x

x x x


x x x



x


Na Tabela 48 todos os fatores de riscos foram citados pelas empresas pesquisadas.


Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE DE MONITORAMENTO /

CONTROLE

EMPRESAS

A B C D E F



3 Requisitos não claros (ambíguos / imprecisos). x


cliente). x

5 Adição de mais funcionalidades que o especificado / dar extras

ao cliente. x x x


desempenho. x x x

7 Alto nível de complexibilidade técnica. x x

8 Desenvolvimento de interface do usuário inadequada. x x


respostas restritos). x x


210



(Cont.)



CONTROLE

EMPRESAS

A B C D E F



insuficiência de hardware. x x

11 Tecnologia nova / imatura (uso de novas tecnologias). x x





x x x


desenvolvedores relativo às especificações dos requisitos. x x





x x


selecionados inadequados para o processo de desenvolvimento. x x x x



referente à qualidade e metas de produtividade. x x x x x


corresponde às expectativas do cliente. x x x x

18 Documentação / papelada excessiva. x x x x



dados insuficiente. x


indisponibilidade / erro / mal funcionamento dos componentes. x x x



conserto ou resolução de problemas por parte dos vendedores. x x


do plano de contingência. x x x


ou mal entendidos. x x x


ineficientes. x x x x x


envolvidos do projeto. x x x x x x

26 Falhas em gerenciar as expectativas do usuário final. x x x x x


211



(Cont.)



CONTROLE

EMPRESAS

A B C D E F

27 Ausência de um líder. x x x x





x x x x x

30 Treinamento inadequado ou indisponível. x x x


assegurar a garantia da qualidade. x x x x

32 Gerência de Configuração inadequada. x x x x

33 Mudanças contínuas no objetivo e escopo do projeto. x x x x x

34 Erro ao estimar (tempo, custo e esforço). x x x x

35 Métricas inadequadas / inexatas. x x x


gerência. x x x




por todo o pais).

x x x x




superiores.

x x x x

39 Falta de maturidade / instabilidade organizacional. x x x x

40 Baixa produtividade da equipe. x x

41 Cronograma irreal ou inadequado baseado nos eventos internos

e externos do sistema. x x x

42 Pressão excessiva de prazo. x x x x



indisponibilidade de pessoas chaves. x x x


internos e externos do sistema. x x


nos projetos. x x x x





x x x x x


212



(Cont.)



CONTROLE

EMPRESAS

A B C D E F

47 Problemas relacionados aos contratos associados. x x

48 Qualquer problema associado a subcontratação. x x x



desenvolvimento do projeto. x x x x






x x x x

51 Falta de comprometimento da gerência sênior x x x x


relativo a diferenças de idiomas. x x


Na Tabela 49 os fatores de riscos 01, 02, 03, 04, 05, 07, 13, 14 e 18 não foram citados

pelas empresas pesquisadas. Para saber quais são estes fatores de riscos ver os mesmos na

Tabela 38.


Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE DE ENCERRAMENTO

EMPRESAS

A B C D E F


desempenho. x x

8 Desenvolvimento de interface do usuário inadequada. x


respostas restritos). x x



insuficiência de hardware. x

11 Tecnologia nova / imatura (uso de novas tecnologias). x


213


Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)



EMPRESAS

A B C D E F





x



desenvolvimento. x x x x



referente à qualidade e metas de produtividade. x x x


corresponde às expectativas do cliente. x x x x



dados insuficiente. x x x


indisponibilidade / erro / mal funcionamento dos componentes. x x



conserto ou resolução de problemas por parte dos vendedores. x x x


do plano de contingência. x


ou mal entendidos. x


ineficientes. x x


envolvidos do projeto. x x

26 Falhas em gerenciar as expectativas do usuário final. x x

27 Ausência de um líder. x x x x

28 Falta de metodologia efetiva de gerenciamento de projetos. x x x x




x x

30 Treinamento inadequado ou indisponível. x x


assegurar a garantia da qualidade. x x

32 Gerência de Configuração inadequada. x x x

33 Mudanças contínuas no objetivo e escopo do projeto. x

34 Erro ao estimar (tempo, custo e esforço). x

35 Métricas inadequadas / inexatas. x


214


Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)



EMPRESAS

A B C D E F


gerência. x




por todo o pais).

x




superiores.

x

39 Falta de maturidade / instabilidade organizacional. x x x x

40 Baixa produtividade da equipe. x



42 Pressão excessiva de prazo. x





internos e externos do sistema.


nos projetos. x





x x x

47 Problemas relacionados aos contratos associados. x x x

48 Qualquer problema associado a subcontratação. x x



desenvolvimento do projeto. x x






x x

51 Falta de comprometimento da gerência sênior x x


relativo a diferenças de idiomas. x x


215

Na Tabela 50 aparecem os fatores de riscos citados apenas pela empresa “F”.


Avaliação Pós-Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas


FASE de Análise Pós-Encerramento

EMPRESAS

A B C D E F


selecionados inadequados para o processo de desenvolvimento. x



referente à qualidade e metas de produtividade. x


30 Treinamento inadequado ou indisponível. x


assegurar a garantia da qualidade. x

32 Gerência de Configuração inadequada. x

39 Falta de maturidade / instabilidade organizacional. x





216

APÊNDICE VI - Roteiro de análise de risco

Neste apêndice é apresentado o roteiro de análise de risco, que está dividido em quarto

partes: dados do entrevistado, dados da empresa, gerência de risco e fatores de riscos.

Parte I – Dados do Entrevistado

217

Parte II – Dados da Empresa

218

Parte III – Gerência de Riscos

219

Parte IV – Fatores de Riscos

Nesta parte do roteiro de análise de riscos (Parte IV) as questões 36 a 40 foram repetidas

para cada fator de risco identificado (Figura 23), totalizando 52 fatores de riscos (Tabela 38).

Essa variação na quantidade de fatores de risco se deu de acordo com a análise semântica

realizada, conforme descrito no item 3.1 desta dissertação e apresentada no Apêndice III.

FACULDADE ALVES FARIA (ALFA) COORDENAÇÃO DE PÓS … Figura 7: Ciclo de Vida do Scrum. Fonte:...

Documents

Transcript of FACULDADE ALVES FARIA (ALFA) COORDENAÇÃO DE PÓS … Figura 7: Ciclo de Vida do Scrum. Fonte:...