faculdade alves faria (alfa) coordenaÇÃo de pÓs … figura 7: ciclo de vida do scrum. fonte:...
TRANSCRIPT
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
INVESTIGAÇÃO PARA UMA PROPOSTA DE UM
MÉTODO ÁGIL PARA IDENTIFICAÇÃO DE RISCOS EM
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
INVESTIGAÇÃO PARA UMA PROPOSTA DE UM
MÉTODO ÁGIL PARA IDENTIFICAÇÃO DE RISCOS EM
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
Gráfico 2: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação, segundo as
faixas de faturamento - Brasil – 2006 ......................................................................... 18
Gráfico 3: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação, segundo as
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
Tabela 14: Comparativo das abordagens de Gerenciamento de riscos para desenvolvimento de
software por Oliveira G. (2006) ................................................................................. 80
Tabela 15: Comparativo das abordagens de Gerenciamento de riscos para desenvolvimento de
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
Tabela 32: Abordagem adotada pelas empresas brasileiras para gerenciamento de riscos - por
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
Tabela 46: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas ......... 204
Tabela 47: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas ............... 206
Tabela 48: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas
pesquisadas ............................................................................................................... 209
Tabela 49: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas ........ 212
Tabela 50: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
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
Gráfico 2: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação,
segundo as faixas de faturamento - Brasil – 2006
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no Brasil 2003-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.
Gráfico 3: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação,
segundo as grandes regiões - Brasil – 2006
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no Brasil 2003-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
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no 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
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no 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
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no 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
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no 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.
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
Fontes: Pesquisa Archibald & Prado 2006
Gráfico 11: Principais causas de fracasso em projetos de TI - Brasil-2008
Fontes: Pesquisa Archibald & Prado 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
Plano de gerenciamento dos riscos
Declaração do escopo do projetos
Ativos de processos organizacionais
2. Ferramentas e técnicas
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
Plano de gerenciamento dos riscos
Estimativa de custos das atividades
Estimativa de duração das atividades
Linha de base do escopo
Registro de partes interessadas
Plano de gerenciamento dos custos
Plano de gerenciamento do cronograma
Plano de gerenciamento da qualidade
Documentos do projeto
Fatores ambientais da empresa
Ativos de processos organizacionais
2. Ferramentas e técnicas
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
Opinião especializada
3. Saídas
Registro dos riscos
Realizar a análise quantitativa dos
riscos
1. Entradas
Registro dos riscos
Plano de gerenciamento dos riscos
Plano de gerenciamento dos custos
Plano de gerenciamento do cronograma
Ativos de processos organizacionais
2. Ferramentas e técnicas
Técnicas de coleta e apresentação de
dados
Técnicas de modelagem e análise
quantitativa de riscos
Opinião especializada
3. Saídas
Atualizações do registro dos riscos
Planejar as respostas aos riscos
1. Entradas
Registro dos riscos
Plano de gerenciamento dos riscos
2. Ferramentas e técnicas
Estratégias para riscos negativos ou
ameaças
Estratégias para riscos positivos ou
oportunidades
Estratégias de respostas de
contingência
Opinião especializada
3. Saídas
Atualizações do registro dos riscos
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
2. Ferramentas e técnicas
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 do registro dos riscos
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
ABORDAGENS DE GERÊNCIA DE RISCO
PMI PRINCE2 P2M SCRUM APM DSDM
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.
Fonte: PMI (2008); PRINCE (2010), Scribd (2010), PMAJ (2005), (MARÇAL et al., 2007), Hazrati (2008) e
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
ABORDAGENS DE GERÊNCIA DE RISCO
PMI PRINCE2 P2M SCRUM APM DSDM
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.
Fonte: PMI (2008); PRINCE (2010), Scribd (2010), PMAJ (2005), (MARÇAL et al., 2007), Hazrati (2008) e
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
ABORDAGENS DE 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
Tabela 14: Comparativo das abordagens de Gerenciamento de riscos para
desenvolvimento de software por Oliveira G. (2006)
ATIVIDADES DA
GERÊNCIA DE
RISCO
ABORDAGENS DE 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.
Tabela 15: Comparativo das abordagens de Gerenciamento de riscos para
desenvolvimento de software por Oliveira G. (2006)
ATIVIDADES DA
GERÊNCIA DE
RISCO
ABORDAGENS DE 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
Tabela 15: Comparativo das abordagens de Gerenciamento de riscos para
desenvolvimento de software por Oliveira G. (2006) (Cont.)
ATIVIDADES DA
GERÊNCIA DE
RISCO
ABORDAGENS DE 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.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.)
ID FATOR DE RISCO INTEGRADO AUTORES
2-09 Problemas de desempenho de tempo real (há
tempos de respostas restritos).
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(MACHADO, 2002); (CARR et al., 1993)
Fonte: Webster (2005, p. 118).
92
Tabela 18: Fatores de risco de desenvolvimento de software integrados (Cont.)
ID FATOR DE RISCO INTEGRADO AUTORES
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.
(MACHADO, 2002); (CARR et al., 1993)
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);
(MACHADO, 2002); (CARR et al., 1993)
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)
Fonte: Webster (2005, p. 118).
93
Tabela 18: Fatores de risco de desenvolvimento de software integrados (Cont.)
ID FATOR DE RISCO INTEGRADO AUTORES
2-41 Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(BOEHM, 1991); (KWAK; STODDARD, 2003);
(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.
(HOUSTON et al., 2001); (MACHADO, 2002);
(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.
(HOUSTON et al., 2001); (MACHADO, 2002);
(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);
(FONTOURA; PRICE, 2004); (LEOPOLDINO, 2004)
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);
(FONTOURA; PRICE, 2004); (LEOPOLDINO, 2004)
Fonte: Webster (2005, p. 118).
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
Fonte: Elaborado pelo autor, a partir da pesquisa de campo
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).
Tabela 24: Processos/Abordagens adotadas para gerenciamento de riscos pelas empresas
pesquisadas
QUESTÕES RESPOSTAS DAS EMPRESAS 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
Fonte: Elaborado pelo autor, a partir da pesquisa de campo
117
Tabela 24: Processos/Abordagens adotadas para gerenciamento de riscos pelas empresas
pesquisadas (Cont.)
QUESTÕES RESPOSTAS DAS EMPRESAS PESQUISADAS
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
Fonte: Elaborado pelo autor, a partir da pesquisa de campo
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.
Fonte: Elaborado pelo autor, a partir da pesquisa de campo
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).
Tabela 26: Classificação dos Fatores de Riscos integrados para desenvolvimento de software,
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
Tabela 26: Classificação dos Fatores de Riscos integrados para desenvolvimento de software,
quanto às categorias de riscos propostas pelo SEI (Cont.)
Categoria de
Risco
ID FATOR DE RISCO INTEGRADO
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.
Fonte: Elaboração do autor a partir de SEI (CARR et al., 1993); Webster (2005) e Mulcahy (2010).
122
Tabela 26: Classificação dos Fatores de Riscos integrados para desenvolvimento de software,
quanto às categorias de riscos propostas pelo SEI (Cont.)
Categoria de
Risco
ID FATOR DE RISCO INTEGRADO
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.
Fonte: Elaboração do autor a partir de SEI (CARR et al., 1993); Webster (2005) e Mulcahy (2010).
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.)
ID FATOR DE RISCO INTEGRADO Probabilidade Impacto
Classificação Custo Qualidade Prazo Total
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
utilização de método de teste inadequado.
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
comprometimento do usuário.
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
125
Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO Probabilidade Impacto
Classificação Custo Qualidade Prazo Total
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:
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.
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
manutenção de métricas progressivas.
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
126
Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO Probabilidade Impacto
Classificação Custo Qualidade Prazo Total
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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
desenvolvimento de software.
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
desenvolvimento de software.
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
gerenciamento de riscos.
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.
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.
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.
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,
procedimentos e formulários.
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.
Fonte: Elaboração do autor
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
Fonte: Elaboração do autor
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
Realizado informalmente,
conforme interesse ou
necessidade do responsável
pelo projeto
Baseado em uma metodologia
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
gerenciamento de riscos.
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.
Tabela 30: Abordagem adotada pelas empresas brasileiras para gerenciamento de riscos - por
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)
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
(Yij) (Xij) QLRegião
(Xij / Yij) (Yij) (Xij)
QLRegião
(Xij / Yij) (Yij) (Xij)
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
Fonte: Elaboração do autor
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,
procedimentos e formulários.
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
na nossa organização
(b) Realizam informalmente,
conforme interesse ou necessidade
do responsável pelo projeto
(c) Baseado em uma metodologia formal,
estruturada por políticas,
procedimentos e formulários
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
Fonte: Elaboração do autor
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
Tabela 32: Abordagem adotada pelas empresas brasileiras para gerenciamento de riscos - por
estado33
Fonte: Elaboração do autor
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
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
(Yij) (Xij) QLUF
(Xij / Yij) (Yij) (Xij)
QLUF
(Xij / Yij) (Yij) (Xij)
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
Fonte: Elaboração do autor
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
Fonte: Elaboração do autor
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
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.
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
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.
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
trabalhando neste projeto e a maioria
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.
O que pode resultar em um
atraso para o projeto.
Fonte: Mulcahy, 2010.
36
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.
158
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
O que pode resultar em um
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.
O que pode resultar em um
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.
1-29 Devido à existência de um projeto
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.
Fonte: Mulcahy, 2010.
37
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.
159
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
38
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.
160
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
39
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.
161
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
40
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.
162
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
41
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.
163
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
42
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.
164
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
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.
Fonte: Mulcahy, 2010.
43
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.
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.
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010)
ID CAUSA RISCO EFEITO
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.
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID CAUSA RISCO EFEITO
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
trabalhando neste projeto e a maioria
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.
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.
O que pode resultar em um
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID CAUSA RISCO EFEITO
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.
1-29 Devido à existência de um projeto
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID CAUSA RISCO EFEITO
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID CAUSA RISCO EFEITO
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID CAUSA RISCO EFEITO
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
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010) (Cont.)
ID 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 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)
ID CAUSA RISCO EFEITO
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.
Os dados podem não estar
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
funcionalidade reduzida
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.
O que pode resultar em um
declínio do projeto.
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-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.
O que pode resultar em 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.
Resultando no atraso do
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.
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 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.)
ID CAUSA RISCO EFEITO
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-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.
Rotatividade da equipe e
mudanças de pessoal podem
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.
Perda de código-fonte pode
ocorrer.
O que levaria a uma
duplicação do trabalho.
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.
Os dados podem não estar
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.)
Mulcahy (2010) Webster (2005)
ID CAUSA RISCO EFEITO ID
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
(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.
Procedimentos inadequados
podem ser seguidos.
O que pode resultar em
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.
O que pode resultar em
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.
Resultando no atraso do
projeto.
2-22
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.
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
horas extras ou recursos
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
Fonte: Mulcahy (2010) e Webster (2005) adaptado pelo autor
175
Tabela 37: Fatores de Riscos considerados duplicados (Cont.)
Mulcahy (2010) Webster (2005)
ID CAUSA RISCO EFEITO ID
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.
O fornecedor poderá fazer
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.
Rotatividade da equipe e
mudanças de pessoal podem
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.
Perda de código-fonte pode
ocorrer.
O que levaria a uma
duplicação do trabalho.
2-31
Fonte: Mulcahy (2010) e Webster (2005) adaptado pelo autor
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
ID FATOR DE RISCO INTEGRADO
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
utilização de método de teste inadequado.
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.)
ID FATOR DE RISCO INTEGRADO
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
espalhados por todo o pais).
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”
ID FATOR DE RISCO INTEGRADO
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
1 Requisitos instáveis
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
4 Requisitos mal entendidos (não refletem as
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
7 Alto nível de complexibilidade técnica.
x
3 4 4 4 12 36
8 Desenvolvimento de interface do usuário
inadequada. x
1 1 4 1 6 6
9 Problemas de desempenho de tempo real (há
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
11 Tecnologia nova / imatura (uso de novas
tecnologias). x x
3 4 4 4 12 36
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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.)
ID FATOR DE RISCO INTEGRADO
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:
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
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x
3 4 4 4 12 36
Fonte: Elaborado pelo autor a partir da pesquisa de campo
45
Outra: “Avaliação pós-encerramento”. Fase utilizada somente pela empresa “F”.
180
Tabela 39: Análise dos fatores de riscos segundo a empresa “A” (Cont.)
ID FATOR DE RISCO INTEGRADO
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:
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
30 Treinamento inadequado ou indisponível.
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
33 Mudanças contínuas no objetivo e escopo do
projeto. x
x
3 4 2 3 9 27
34 Erro ao estimar (tempo, custo e esforço).
x x x
4 4 3 5 12 48
35 Métricas inadequadas / inexatas.
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
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 x
1 2 2 2 6 6
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 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
42 Pressão excessiva de prazo.
x x
2 3 3 4 10 20
Fonte: Elaborado pelo autor a partir da pesquisa de campo
46
Outra: “Avaliação pós-encerramento”. Fase utilizada somente pela empresa “F”.
181
Tabela 39: Análise dos fatores de riscos segundo a empresa “A” (Cont.)
ID FATOR DE RISCO INTEGRADO
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:
47
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
43 Problemas de pessoal. Ex.: falta experiência,
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
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.
x x x
3 3 4 5 12 36
47 Problemas relacionados aos contratos associados.
x x
3 4 2 4 10 30
48 Qualquer problema associado a subcontratação.
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
comprometimento do usuário.
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
internacional relativo a diferenças de idiomas.
0 0
Fonte: Elaborado pelo autor a partir da pesquisa de campo
47
Outra: “Avaliação pós-encerramento”. Fase utilizada somente pela empresa “F”.
182
Tabela 40: Análise dos fatores de riscos segundo a empresa “B”
ID FATOR DE RISCO INTEGRADO
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:
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
4 Requisitos mal entendidos (não refletem as
expectativas do cliente). x x
4 4 4 4 12 48
5 Adição de mais funcionalidades que o
especificado / dar extras ao cliente. x
2 4 1 4 9 18
6 Requisitos de desempenho não atendidos. Ex.
Baixo desempenho. x
2 2 2 2 6 12
7 Alto nível de complexibilidade técnica.
x
3 4 4 4 12 36
8 Desenvolvimento de interface do usuário
inadequada. x
x
3 4 3 4 11 33
9 Problemas de desempenho de tempo real (há
tempos de respostas restritos). x
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
11 Tecnologia nova / imatura (uso de novas
tecnologias). x x
3 4 3 4 11 33
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
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
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo
de desenvolvimento. x x x x x
2 3 3 3 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
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.)
ID FATOR DE RISCO INTEGRADO
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:
41
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
17 Controle do produto inadequado. Ex.: o produto
final não corresponde às expectativas do cliente. x
3 3 3 3 9 27
18 Documentação / papelada excessiva.
x x
1 3 1 3 7 7
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 3 1 3 7 7
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
funcionamento dos componentes. x
x
2 3 3 3 9 18
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 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
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x x x x x
2 4 4 4 12 24
25 Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto. x x
x
2 3 3 3 9 18
26 Falhas em gerenciar as expectativas do usuário
final. x x
3 3 3 3 9 27
27 Ausência de um líder.
x
2 3 4 3 10 20
28 Falta de metodologia efetiva de gerenciamento de
projetos. x x x x x
2 4 4 4 12 24
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
2 1 1 1 3 6
30 Treinamento inadequado ou indisponível.
x x
2 4 4 4 12 24
31 Falta de procedimentos, programas adequados e
recursos para assegurar a garantia da qualidade. x x
2 4 4 4 12 24
32 Gerência de Configuração inadequada.
x x
2 2 3 2 7 14
33 Mudanças contínuas no objetivo e escopo do
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
Fonte: Elaborado pelo autor a partida da pesquisa de campo
184
Tabela 40: Análise dos fatores de riscos segundo a empresa “B” (Cont.)
ID FATOR DE RISCO INTEGRADO
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:
41
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
35 Métricas inadequadas / inexatas. x x
2 3 1 3 7 14
36 Falta espírito de equipe. Os conflitos requerem
intervenção da gerência. x
1 1 1 1 3 3
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
x
2 3 3 3 9 18
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
2 2 3 2 7 14
39 Falta de maturidade / instabilidade
organizacional. x x
2 2 3 2 7 14
40 Baixa produtividade da equipe.
x x
2 4 2 4 10 20
41 Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema. x
3 4 3 4 11 33
42 Pressão excessiva de prazo.
x
4 4 4 4 12 48
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves. x x
2 4 4 4 12 24
44 Orçamento insuficiente ou instável baseado nos
eventos internos e externos do sistema. x
2 1 4 1 6 12
45 Instabilidade (rotatividade) e falta de
continuidade das pessoas nos projetos. x
2 3 3 3 9 18
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.
x
x
3 3 3 3 9 27
47 Problemas relacionados aos contratos associados. x x
2 1 1 1 3 6
48 Qualquer problema associado a subcontratação.
0 0
Fonte: Elaborado pelo autor a partida da pesquisa de campo
185
Tabela 40: Análise dos fatores de riscos segundo a empresa “B” (Cont.)
ID FATOR DE RISCO INTEGRADO
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:
41
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
49 Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
x x
2 1 1 1 3 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 comprometimento do usuário.
x x x
3 3 3 3 9 27
51 Falta de comprometimento da gerência sênior
0 0
52 Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas. x x x x x
3 4 4 4 12 36
Fonte: Elaborado pelo autor a partir da pesquisa de campo
Tabela 41: Análise dos fatores de riscos segundo a empresa “C”
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
1 Requisitos instáveis x x
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
4 Requisitos mal entendidos (não refletem as
expectativas do cliente). x x
x
2 3 3 3 9 18
5 Adição de mais funcionalidades que o
especificado / dar extras ao cliente. x x
x
2 2 2 2 6 12
6 Requisitos de desempenho não atendidos. Ex.
Baixo desempenho. x x x
3 4 4 4 12 36
7 Alto nível de complexibilidade técnica.
x x x
2 5 5 5 15 30
Fonte: Elaborado pelo autor a partida da pesquisa de campo
186
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
8 Desenvolvimento de interface do usuário
inadequada. x x x
2 3 3 3 9 18
9 Problemas de desempenho de tempo real (há
tempos de respostas restritos). x x x
2 4 4 4 12 24
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 x
2 3 3 3 9 18
11 Tecnologia nova / imatura (uso de novas
tecnologias). x x x x
3 4 4 4 12 36
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
4 4 4 4 12 48
13 Falta de um acordo interativo entre os clientes e
os desenvolvedores relativo às especificações dos
requisitos. x x x x
4 3 3 3 9 36
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 x
2 2 2 2 6 12
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo
de desenvolvimento. x x
3 3 3 3 9 27
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
x
3 3 3 3 9 27
17 Controle do produto inadequado. Ex.: o produto
final não corresponde às expectativas do cliente. x
x
3 3 3 3 9 27
18 Documentação / papelada excessiva.
x
x
4 2 2 2 6 24
19 Capacidade insuficiente do sistema desenvolvido.
Ex.: Falta de estações de trabalho, espaço de
armazenamento no banco de dados insuficiente. x x
3 3 3 3 9 27
Fonte: Elaborado pelo autor a partida da pesquisa de campo
187
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
funcionamento dos componentes. x x x
2 3 3 3 9 18
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 x
2 2 2 2 6 12
22 Planejamento inapropriado, incluindo construção
e atualização do plano de contingência. x x
x
4 3 3 3 9 36
23 Papéis e responsabilidades de relacionamentos
mal definidos ou mal entendidos. x x
x
4 3 3 3 9 36
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x x
x
2 4 4 4 12 24
25 Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto. x x x x x
3 3 3 3 9 27
26 Falhas em gerenciar as expectativas do usuário
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
28 Falta de metodologia efetiva de gerenciamento de
projetos. x x x x x
4 2 3 3 8 32
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
4 2 3 3 8 32
30 Treinamento inadequado ou indisponível.
x x
4 2 3 3 8 32
31 Falta de procedimentos, programas adequados e
recursos para assegurar a garantia da qualidade. x x x
4 2 3 3 8 32
32 Gerência de Configuração inadequada.
x x x
5 2 4 3 9 45
33 Mudanças contínuas no objetivo e escopo do
projeto. x x x x x
3 4 3 4 11 33
34 Erro ao estimar (tempo, custo e esforço).
x
x
4 4 2 4 10 40
35 Métricas inadequadas / inexatas.
x
x
4 4 2 4 10 40
36 Falta espírito de equipe. Os conflitos requerem
intervenção da gerência. x x x
3 2 4 4 10 30
Fonte: Elaborado pelo autor a partir da pesquisa de campo
188
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
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
3 2 4 4 10 30
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 x x
3 3 4 4 11 33
39 Falta de maturidade / instabilidade
organizacional. x x x x x
3 3 3 3 9 27
40 Baixa produtividade da equipe.
x
3 4 4 4 12 36
41 Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema. x x
x
4 4 3 4 11 44
42 Pressão excessiva de prazo.
x x
3 3 5 3 11 33
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves. x x
3 3 4 4 11 33
44 Orçamento insuficiente ou instável baseado nos
eventos internos e externos do sistema. x x
x
2 4 2 3 9 18
45 Instabilidade (rotatividade) e falta de
continuidade das pessoas nos projetos. x x
3 4 4 4 12 36
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.
x x x x x
4 3 2 4 9 36
47 Problemas relacionados aos contratos associados.
x
x x 3 4 3 4 11 33
48 Qualquer problema associado a subcontratação.
x
x x 3 4 3 4 11 33
49 Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
x x x
3 3 3 3 9 27
Fonte: Elaborado pelo autor a partir da pesquisa de campo
189
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
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
3 3 3 3 9 27
51 Falta de comprometimento da gerência sênior x x
x
2 3 3 3 9 18
52 Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas.
0 0
Fonte: Elaborado pelo autor a partida da pesquisa de campo
Tabela 42: Análise dos fatores de riscos segundo a empresa “D”
ID FATOR DE RISCO INTEGRADO
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
1 Requisitos instáveis x x
4 5 3 4 12 48
2 Requisitos incompletos. x
3 4 2 3 9 27
3 Requisitos não claros (ambíguos / imprecisos).
x
3 4 2 3 9 27
4 Requisitos mal entendidos (não refletem as
expectativas do cliente). x x
3 4 2 3 9 27
5 Adição de mais funcionalidades que o
especificado / dar extras ao cliente. x x
4 5 3 4 12 48
6 Requisitos de desempenho não atendidos. Ex.
Baixo desempenho. x x
3 4 2 3 9 27
7 Alto nível de complexibilidade técnica.
x
3 4 2 3 9 27
8 Desenvolvimento de interface do usuário
inadequada. x
2 3 1 2 6 12
Fonte: Elaborado pelo autor a partida da pesquisa de campo
190
Tabela 42: Análise dos fatores de riscos segundo a empresa “D” (Cont.)
ID FATOR DE RISCO INTEGRADO
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
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
9 Problemas de desempenho de tempo real (há
tempos de respostas restritos). x
x
3 4 2 3 9 27
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
3 4 2 3 9 27
11 Tecnologia nova / imatura (uso de novas
tecnologias). x x
4 5 3 4 12 48
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
3 4 2 3 9 27
13 Falta de um acordo interativo entre os clientes e
os desenvolvedores relativo às especificações dos
requisitos. x x
3 4 2 3 9 27
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
4 5 3 4 12 48
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo
de desenvolvimento. x x x x x
3 4 2 3 9 27
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 x x x
3 4 2 3 9 27
17 Controle do produto inadequado. Ex.: o produto
final não corresponde às expectativas do cliente. x x x x x
4 5 3 4 12 48
18 Documentação / papelada excessiva.
x x x
3 4 2 3 9 27
19 Capacidade insuficiente do sistema desenvolvido.
Ex.: Falta de estações de trabalho, espaço de
armazenamento no banco de dados insuficiente. x
x
3 4 2 3 9 27
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
funcionamento dos componentes. x
3 4 2 3 9 27
Fonte: Elaborado pelo autor a partir da pesquisa de campo
191
Tabela 42: Análise dos fatores de riscos segundo a empresa “D” (Cont.)
ID FATOR DE RISCO INTEGRADO
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
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
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
4 5 3 4 12 48
22 Planejamento inapropriado, incluindo construção
e atualização do plano de contingência. x
4 5 3 4 12 48
23 Papéis e responsabilidades de relacionamentos
mal definidos ou mal entendidos. x
3 4 2 3 9 27
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x
x
3 4 2 3 9 27
25 Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto. x
2 3 1 2 6 12
26 Falhas em gerenciar as expectativas do usuário
final. x x x
5 5 4 5 14 70
27 Ausência de um líder. x x x x x 3 4 2 3 9 27
28 Falta de metodologia efetiva de gerenciamento de
projetos. x x x x x
3 4 2 3 9 27
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
4 5 3 4 12 48
30 Treinamento inadequado ou indisponível.
x x
2 3 1 2 6 12
31 Falta de procedimentos, programas adequados e
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
33 Mudanças contínuas no objetivo e escopo do
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
36 Falta espírito de equipe. Os conflitos requerem
intervenção da gerência. x x
3 4 2 3 9 27
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
3 4 2 3 9 27
Fonte: Elaborado pelo autor a partir da pesquisa de campo
192
Tabela 42: Análise dos fatores de riscos segundo a empresa “D” (Cont.)
ID FATOR DE RISCO INTEGRADO
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
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
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
3 4 2 3 9 27
39 Falta de maturidade / instabilidade
organizacional. x x x x x
3 4 2 3 9 27
40 Baixa produtividade da equipe.
x
3 4 2 3 9 27
41 Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema. x
3 4 2 3 9 27
42 Pressão excessiva de prazo.
x x
2 3 1 2 6 12
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves. x x x x x
3 4 2 3 9 27
44 Orçamento insuficiente ou instável baseado nos
eventos internos e externos do sistema. x x
3 4 2 3 9 27
45 Instabilidade (rotatividade) e falta de
continuidade das pessoas nos projetos. x
4 5 3 4 12 48
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.
x x
3 4 2 3 9 27
47 Problemas relacionados aos contratos associados.
x x x x 4 5 3 4 12 48
48 Qualquer problema associado a subcontratação.
x x x x 4 5 3 4 12 48
49 Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
x x x x x
3 4 2 3 9 27
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
3 4 2 3 9 27
51 Falta de comprometimento da gerência sênior
x x
3 4 2 3 9 27
52 Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas. x x x x x
4 5 3 4 12 48
Fonte: Elaborado pelo autor a partir da pesquisa de campo
193
Tabela 43: Análise dos fatores de riscos segundo a empresa “E”
ID FATOR DE RISCO INTEGRADO
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: 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
4 Requisitos mal entendidos (não refletem as
expectativas do cliente). x x x
3 4 4 5 13 39
5 Adição de mais funcionalidades que o
especificado / dar extras ao cliente. x x
4 4 4 5 13 52
6 Requisitos de desempenho não atendidos. Ex.
Baixo desempenho. x x
2 3 4 3 10 20
7 Alto nível de complexibilidade técnica. x x x
3 3 3 3 9 27
8 Desenvolvimento de interface do usuário
inadequada. x x
2 3 5 3 11 22
9 Problemas de desempenho de tempo real (há
tempos de respostas restritos). x x
2 3 5 3 11 22
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 2 4 3 9 18
11 Tecnologia nova / imatura (uso de novas
tecnologias). x x x
3 3 3 3 9 27
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
3 3 4 4 11 33
13 Falta de um acordo interativo entre os clientes e
os desenvolvedores relativo às especificações dos
requisitos. x 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 x
4 4 4 5 13 52
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo
de desenvolvimento. x x x x x
3 3 3 3 9 27
Fonte: Elaborado pelo autor a partir da pesquisa de campo
194
Tabela 43: Análise dos fatores de riscos segundo a empresa “E” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
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 x x x
3 3 3 3 9 27
17 Controle do produto inadequado. Ex.: o produto
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
19 Capacidade insuficiente do sistema desenvolvido.
Ex.: Falta de estações de trabalho, espaço de
armazenamento no banco de dados insuficiente. x
x
2 2 4 4 10 20
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
funcionamento dos componentes. x
x
2 2 4 4 10 20
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
x
2 2 3 3 8 16
22 Planejamento inapropriado, incluindo construção
e atualização do plano de contingência. x x
x
3 3 4 4 11 33
23 Papéis e responsabilidades de relacionamentos
mal definidos ou mal entendidos. x x x x x
3 3 4 4 11 33
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x x x x x
2 3 4 4 11 22
25 Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto. x x x x x
1 2 3 3 8 8
26 Falhas em gerenciar as expectativas do usuário
final. x x x x x
1 2 3 3 8 8
27 Ausência de um líder. x x x x x 1 2 3 3 8 8
28 Falta de metodologia efetiva de gerenciamento de
projetos. x x x x x
2 2 3 3 8 16
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
2 2 3 3 8 16
30 Treinamento inadequado ou indisponível.
x 2 4 2 2 8 16
31 Falta de procedimentos, programas adequados e
recursos para assegurar a garantia da qualidade. x x x x x
2 4 4 3 11 22
32 Gerência de Configuração inadequada.
x x x 2 3 3 3 9 18
Fonte: Elaborado pelo autor a partir da pesquisa de campo
195
Tabela 43: Análise dos fatores de riscos segundo a empresa “E” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
33 Mudanças contínuas no objetivo e escopo do
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
35 Métricas inadequadas / inexatas.
x x
2 3 3 3 9 18
36 Falta espírito de equipe. Os conflitos requerem
intervenção da gerência. x x x x
2 3 3 3 9 18
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 x x x
2 3 3 3 9 18
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 x x x x
1 2 2 2 6 6
39 Falta de maturidade / instabilidade
organizacional. x x x x x
2 2 2 2 6 12
40 Baixa produtividade da equipe. x x x x x 2 3 3 3 9 18
41 Cronograma irreal ou inadequado baseado nos
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
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves. x x x x x
2 4 4 4 12 24
44 Orçamento insuficiente ou instável baseado nos
eventos internos e externos do sistema.
0 0
45 Instabilidade (rotatividade) e falta de
continuidade das pessoas nos projetos. x x x x x
2 3 3 3 9 18
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.
x x x x x
3 3 3 3 9 27
Fonte: Elaborado pelo autor a partir da pesquisa de campo
196
Tabela 43: Análise dos fatores de riscos segundo a empresa “E” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
47 Problemas relacionados aos contratos associados.
x 2 2 3 3 8 16
48 Qualquer problema associado a subcontratação.
0 0
49 Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
x x x x x
2 3 3 3 9 18
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 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
52 Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas.
0 0
Fonte: Elaborado pelo autor a partir da pesquisa de campo
Tabela 44: Análise dos fatores de riscos segundo a empresa “F”
ID FATOR DE RISCO INTEGRADO
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: 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
4 Requisitos mal entendidos (não refletem as
expectativas do cliente). x x 2 2 4 2 8 16
5 Adição de mais funcionalidades que o
especificado / dar extras ao cliente. x x 4 4 3 5 12 48
6 Requisitos de desempenho não atendidos. Ex.
Baixo desempenho. x x 2 3 5 2 10 20
Fonte: Elaborado pelo autor a partir da pesquisa de campo
197
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 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
8 Desenvolvimento de interface do usuário
inadequada. x 2 2 4 2 8 16
9 Problemas de desempenho de tempo real (há
tempos de respostas restritos). x 2 2 4 2 8 16
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 1 1 1 1 3 3
11 Tecnologia nova / imatura (uso de novas
tecnologias). 0 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
utilização de método de teste inadequado.
x x 4 4 5 5 14 56
13 Falta de um acordo interativo entre os clientes e
os desenvolvedores relativo às especificações dos
requisitos. x x 1 2 3 4 9 9
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 1 2 3 4 9 9
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo
de desenvolvimento. x x x x x x 1 2 2 3 7 7
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 x x x x 1 1 1 1 3 3
17 Controle do produto inadequado. Ex.: o produto
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
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 3 1 1 5 5
Fonte: Elaborado pelo autor a partir da pesquisa de campo
198
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
funcionamento dos componentes. x x x 2 2 4 1 7 14
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 1 3 1 5 5
22 Planejamento inapropriado, incluindo construção
e atualização do plano de contingência. x x 3 4 2 5 11 33
23 Papéis e responsabilidades de relacionamentos
mal definidos ou mal entendidos. 0 0
24 Gerentes do desenvolvimento do software
inexperientes ou ineficientes. x x x 2 2 1 5 8 16
25 Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto. x x 1 1 1 1 3 3
26 Falhas em gerenciar as expectativas do usuário
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
28 Falta de metodologia efetiva de gerenciamento de
projetos. 0 0
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 4 3 2 5 10 40
30 Treinamento inadequado ou indisponível. x x x x x x 4 3 2 5 10 40
31 Falta de procedimentos, programas adequados e
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
33 Mudanças contínuas no objetivo e escopo do
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
199
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
35 Métricas inadequadas / inexatas. x 1 1 1 1 3 3
36 Falta espírito de equipe. Os conflitos requerem
intervenção da gerência. x x 1 1 1 1 3 3
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).
0 0
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 x 2 1 3 3 7 14
39 Falta de maturidade / instabilidade
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
41 Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema. x 2 1 1 5 7 14
42 Pressão excessiva de prazo.
x x x 4 4 4 5 13 52
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves.
x 4 4 5 5 14 56
44 Orçamento insuficiente ou instável baseado nos
eventos internos e externos do sistema. x x x 3 4 4 5 13 39
45 Instabilidade (rotatividade) e falta de
continuidade das pessoas nos projetos. x x 2 3 5 5 13 26
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.
x x x 1 1 3 1 5 5
47 Problemas relacionados aos contratos associados. 0 0
Fonte: Elaborado pelo autor a partir da pesquisa de campo
200
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)
ID FATOR DE RISCO INTEGRADO
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: 4
1
Cu
sto
Qu
alid
ade
Pra
zo
TO
TA
L
48 Qualquer problema associado a subcontratação. 0 0
49 Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
x x 3 1 3 3 7 21
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 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
52 Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas. x 0 0
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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.
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
ID FATOR DE RISCO INTEGRADO
FASE DE INICIAÇÃO
EMPRESAS
A B C D E F
1 Requisitos instáveis
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
7 Alto nível de complexibilidade técnica.
x x
8 Desenvolvimento de interface do usuário inadequada.
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
13 Falta de um acordo interativo entre os clientes e os
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 à
estabilidade dos atributos de qualidade, completude e clareza.
x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
202
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 (Cont.)
ID FATOR DE RISCO INTEGRADO
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
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 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
22 Planejamento inapropriado, incluindo construção e
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
26 Falhas em gerenciar as expectativas do usuário final.
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
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
30 Treinamento inadequado ou indisponível.
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
33 Mudanças contínuas no objetivo e escopo do projeto.
x x
x
34 Erro ao estimar (tempo, custo e esforço).
x
x x
35 Métricas inadequadas / inexatas.
x
x
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência. x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
203
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 (Cont.)
ID FATOR DE RISCO INTEGRADO
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
42 Pressão excessiva de prazo.
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
internos e externos do sistema. x
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,
conflitos entre clientes e departamentos, dependência técnica.
x
x
47 Problemas relacionados aos contratos associados.
x
49 Fatores políticos (companhia, clientes, contratantes
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
204
Na Tabela 46 todos fatores de riscos foram citados pelas empresas pesquisadas.
Tabela 46: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas
ID FATOR DE RISCO INTEGRADO
FASE DE PLANEJAMENTO
EMPRESAS
A B C D E F
1 Requisitos instáveis
x x x x
2 Requisitos incompletos.
x x
x
3 Requisitos não claros (ambíguos / imprecisos).
x x x x
4 Requisitos mal entendidos (não refletem as expectativas do
cliente). x x x x
5 Adição de mais funcionalidades que o especificado / dar
extras ao cliente. x
x x x
6 Requisitos de desempenho não atendidos. Ex. Baixo
desempenho. x x
7 Alto nível de complexibilidade técnica. x
x
x x
8 Desenvolvimento de interface do usuário inadequada.
x
x
9 Problemas de desempenho de tempo real (há tempos de
respostas restritos). x
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
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
13 Falta de um acordo interativo entre os clientes e os
desenvolvedores relativo às especificações dos requisitos. x 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 à
estabilidade dos atributos de qualidade, completude e clareza.
x
x
x
15 Os modelos, processos, métodos e ferramentas de apoio
selecionados inadequados para o processo de
desenvolvimento. x x x x x x
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 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 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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
205
Tabela 46: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE PLANEJAMENTO
EMPRESAS
A B C D E F
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
22 Planejamento inapropriado, incluindo construção e
atualização do plano de contingência. x x x x x x
23 Papéis e responsabilidades de relacionamentos mal definidos
ou mal entendidos. x 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
26 Falhas em gerenciar as expectativas do usuário final.
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 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
30 Treinamento inadequado ou indisponível.
x x
x
31 Falta de procedimentos, programas adequados e recursos para
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
35 Métricas inadequadas / inexatas.
x x x x
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência. x x x
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
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
x
x
39 Falta de maturidade / instabilidade organizacional. x x x x x x
40 Baixa produtividade da equipe. x x
x x
41 Cronograma irreal ou inadequado baseado nos eventos
internos e externos do sistema. x x x x x x
42 Pressão excessiva de prazo.
x
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
x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
206
Tabela 46: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE PLANEJAMENTO
EMPRESAS
A B C D E F
44 Orçamento insuficiente ou instável baseado nos eventos
internos e externos do sistema. x x x x
x
45 Instabilidade (rotatividade) e falta de continuidade das
pessoas nos projetos. x
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,
conflitos entre clientes e departamentos, dependência técnica.
x x x
x x
47 Problemas relacionados aos contratos associados. x x x x
48 Qualquer problema associado a subcontratação.
x x
49 Fatores políticos (companhia, clientes, contratantes
associados e subcontratantes) que causam problemas para o
desenvolvimento do projeto. x x 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 x x
51 Falta de comprometimento da gerência sênior x
x x x x
52 Qualquer problema de comunicação em nível internacional
relativo a diferenças de idiomas. x
x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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.
Tabela 47: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas
ID FATOR DE RISCO INTEGRADO
FASE DE EXECUÇÃO
EMPRESAS
A B C D E F
1 Requisitos instáveis x
x x
2 Requisitos incompletos.
x x
3 Requisitos não claros (ambíguos / imprecisos).
x x
4 Requisitos mal entendidos (não refletem as expectativas do
cliente). x x x
5 Adição de mais funcionalidades que o especificado / dar extras
ao cliente. x
x x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
207
Tabela 47: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE EXECUÇÃO
EMPRESAS
A B C D E F
6 Requisitos de desempenho não atendidos. Ex. Baixo
desempenho. x
x x
x
7 Alto nível de complexibilidade técnica.
x x x x x
8 Desenvolvimento de interface do usuário inadequada.
x x x x
9 Problemas de desempenho de tempo real (há tempos de
respostas restritos). x x x 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 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
13 Falta de um acordo interativo entre os clientes e os
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 à
estabilidade dos atributos de qualidade, completude e clareza.
x x x x x
15 Os modelos, processos, métodos e ferramentas de apoio
selecionados inadequados para o processo de desenvolvimento.
x
x x x
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
x x x
17 Controle do produto inadequado. Ex.: o produto final não
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
20 Pouca confiança no desenvolvimento do sistema devido à
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
23 Papéis e responsabilidades de relacionamentos mal definidos
ou mal entendidos. x
24 Gerentes do desenvolvimento do software inexperientes ou
ineficientes. x
x
25 Fraca interação (comunicação) do gerente com todos os
envolvidos do projeto. x
x
x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
208
Tabela 47: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE EXECUÇÃO
EMPRESAS
A B C D E F
26 Falhas em gerenciar as expectativas do usuário final.
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 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
30 Treinamento inadequado ou indisponível.
x x x
x
31 Falta de procedimentos, programas adequados e recursos para
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
35 Métricas inadequadas / inexatas.
x
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência. x x x x x x
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
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 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
43 Problemas de pessoal. Ex.: falta experiência, pouco
conhecimento, falta habilidade, falta de pessoal e
indisponibilidade de pessoas chaves. x x x x x x
44 Orçamento insuficiente ou instável baseado nos eventos
internos e externos do sistema. x
x
45 Instabilidade (rotatividade) e falta de continuidade das pessoas
nos projetos. x x x x x 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,
conflitos entre clientes e departamentos, dependência técnica.
x
x x x x
47 Problemas relacionados aos contratos associados. x
x
48 Qualquer problema associado a subcontratação. x
x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
209
Tabela 47: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
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
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 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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
Na Tabela 48 todos os fatores de riscos foram citados pelas empresas pesquisadas.
Tabela 48: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas
ID FATOR DE RISCO INTEGRADO
FASE DE MONITORAMENTO /
CONTROLE
EMPRESAS
A B C D E F
1 Requisitos instáveis x x
2 Requisitos incompletos. x
3 Requisitos não claros (ambíguos / imprecisos). x
4 Requisitos mal entendidos (não refletem as expectativas do
cliente). x
5 Adição de mais funcionalidades que o especificado / dar extras
ao cliente. x x x
6 Requisitos de desempenho não atendidos. Ex. Baixo
desempenho. x x x
7 Alto nível de complexibilidade técnica. x x
8 Desenvolvimento de interface do usuário inadequada. x x
9 Problemas de desempenho de tempo real (há tempos de
respostas restritos). x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
210
Tabela 48: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas
(Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE MONITORAMENTO /
CONTROLE
EMPRESAS
A B C D E F
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
11 Tecnologia nova / imatura (uso de novas tecnologias). 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
13 Falta de um acordo interativo entre os clientes e os
desenvolvedores relativo às especificações dos requisitos. 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 à
estabilidade dos atributos de qualidade, completude e clareza.
x x
15 Os modelos, processos, métodos e ferramentas de apoio
selecionados inadequados para o processo de desenvolvimento. x x x x
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 x x x
17 Controle do produto inadequado. Ex.: o produto final não
corresponde às expectativas do cliente. x x x 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
20 Pouca confiança no desenvolvimento do sistema devido à
indisponibilidade / erro / mal funcionamento dos componentes. x x 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 x
22 Planejamento inapropriado, incluindo construção e atualização
do plano de contingência. x x x
23 Papéis e responsabilidades de relacionamentos mal definidos
ou mal entendidos. 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
26 Falhas em gerenciar as expectativas do usuário final. x x x x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
211
Tabela 48: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas
(Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE MONITORAMENTO /
CONTROLE
EMPRESAS
A B C D E F
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
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
30 Treinamento inadequado ou indisponível. x x x
31 Falta de procedimentos, programas adequados e recursos para
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
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência. x x x
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 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 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
43 Problemas de pessoal. Ex.: falta experiência, pouco
conhecimento, falta habilidade, falta de pessoal e
indisponibilidade de pessoas chaves. x x x
44 Orçamento insuficiente ou instável baseado nos eventos
internos e externos do sistema. x x
45 Instabilidade (rotatividade) e falta de continuidade das pessoas
nos projetos. x x x 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,
conflitos entre clientes e departamentos, dependência técnica.
x x x x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
212
Tabela 48: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas
(Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE MONITORAMENTO /
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
49 Fatores políticos (companhia, clientes, contratantes 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 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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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.
Tabela 49: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas
ID FATOR DE RISCO INTEGRADO
FASE DE ENCERRAMENTO
EMPRESAS
A B C D E F
6 Requisitos de desempenho não atendidos. Ex. Baixo
desempenho. x x
8 Desenvolvimento de interface do usuário inadequada. x
9 Problemas de desempenho de tempo real (há tempos de
respostas restritos). x 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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
213
Tabela 49: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE ENCERRAMENTO
EMPRESAS
A B C D E F
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
15 Os modelos, processos, métodos e ferramentas de apoio
selecionados inadequados para o processo de
desenvolvimento. x x x x
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 x
17 Controle do produto inadequado. Ex.: o produto final não
corresponde às expectativas do cliente. 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
20 Pouca confiança no desenvolvimento do sistema devido à
indisponibilidade / erro / mal funcionamento dos componentes. x 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 x x
22 Planejamento inapropriado, incluindo construção e atualização
do plano de contingência. x
23 Papéis e responsabilidades de relacionamentos mal definidos
ou mal entendidos. x
24 Gerentes do desenvolvimento do software inexperientes ou
ineficientes. x x
25 Fraca interação (comunicação) do gerente com todos os
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
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
30 Treinamento inadequado ou indisponível. 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
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
Fonte: Elaborado pelo autor a partir da pesquisa de campo
214
Tabela 49: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID FATOR DE RISCO INTEGRADO
FASE DE ENCERRAMENTO
EMPRESAS
A B C D E F
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência. x
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
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
40 Baixa produtividade da equipe. x
41 Cronograma irreal ou inadequado baseado nos eventos
internos e externos do sistema. x
42 Pressão excessiva de prazo. 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
internos e externos do sistema.
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,
conflitos entre clientes e departamentos, dependência técnica.
x x x
47 Problemas relacionados aos contratos associados. x x x
48 Qualquer problema associado a subcontratação. x x
49 Fatores políticos (companhia, clientes, contratantes associados
e subcontratantes) que causam problemas para o
desenvolvimento do projeto. 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
51 Falta de comprometimento da gerência sênior x x
52 Qualquer problema de comunicação em nível internacional
relativo a diferenças de idiomas. x x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
215
Na Tabela 50 aparecem os fatores de riscos citados apenas pela empresa “F”.
Tabela 50: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Avaliação Pós-Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas
ID FATOR DE RISCO INTEGRADO
FASE de Análise Pós-Encerramento
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
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
27 Ausência de um líder. x
30 Treinamento inadequado ou indisponível. x
31 Falta de procedimentos, programas adequados e recursos para
assegurar a garantia da qualidade. x
32 Gerência de Configuração inadequada. x
39 Falta de maturidade / instabilidade organizacional. x
51 Falta de comprometimento da gerência sênior x
52 Qualquer problema de comunicação em nível internacional
relativo a diferenças de idiomas. x
Fonte: Elaborado pelo autor a partir da pesquisa de campo
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.