Investigação para uma proposta de um método

Transcrição

FACULDADE ALVES FARIA (ALFA)
COORDENAÇÃO DE PÓS-GRADUAÇÃO E PESQUISA
MESTRADO PROFISSIONAL EM DESENVOLVIMENTO
REGIONAL
Marcelo Caixeta
INVESTIGAÇÃO PARA UMA PROPOSTA DE UM
MÉTODO ÁGIL PARA IDENTIFICAÇÃO DE RISCOS EM
PROJETOS DE TI
GOIÂNIA
2011
FACULDADE ALVES FARIA (ALFA)
COORDENAÇÃO DE PÓS-GRADUAÇÃO E PESQUISA
MESTRADO PROFISSIONAL EM DESENVOLVIMENTO
REGIONAL
Marcelo Caixeta
PROJETOS DE TI
Dissertação apresentada ao Programa de Pós-Graduação
do Mestrado Profissional em Desenvolvimento Regional
das Faculdades Alves Faria como requisito para obtenção
do Título de Mestre, sob a orientação do Prof. Dr. Bento
A. Costa Filho.
Linha de pesquisa:
Gestão Estratégica de Empreendimentos
GOIÂNIA
2011
FACULDADE ALVES FARIA
MESTRADO EM DESENVOLVIMENTO REGIONAL
Marcelo Caixeta
PROJETOS DE TI
AVALIADORES:
__________________________________________________________
Prof. Dr. Bento A. Costa Filho
(Orientador)
__________________________________________________________
Prof. Dr. Fernando de Rosa
__________________________________________________________
Prof. Dr. Ricardo Antônio Gonçalves Teixeira
GOIÂNIA
2011
PARADOXO DE COBB
We know why projects fail,
we know how to prevent their failure –
so why do they still fail?
(Martin Cobb - Treasury Board of Canada Secretariat)
“Nós sabemos por que os projetos falham,
Sabemos como prevenir seu fracasso,
Então por que eles continuam falhando?”
AGRADECIMENTOS
Em primeiro lugar, agradeço a Deus por ter me concedido a oportunidade e as
condições de desenvolver esse trabalho.
A minha família, esposa e filhos que foram mais que companheiros, foram um exemplo
de compreensão e paciência, agradeço pelos finais de semana que ficaram comigo, ou melhor,
sem a minha companhia, à minha esposa, pela leitura do trabalho, pelo seu amor e apoio que,
sem dúvida, foram essenciais para a conclusão desse trabalho.
Ao meu orientador, Dr. Bento Alves da Costa Filho, agradeço a credibilidade, a atenção,
a paciência e os ensinamentos que me passou durante o decorrer deste estudo e que foram
decisivos para o sucesso deste trabalho.
Aos amigos do mestrado e em especial aos amigos da Comdata, também colegas do
mestrado, pelo companheirismo, pela receptividade e pelas dicas sempre bem vindas.
Aos professores do mestrado que contribuíram de forma significativa com seus
conhecimentos para que este trabalho se concretizasse. Em especial gostaria de agradecer ao
Prof. Ricardo Teixeira, pela atenção e pelos ensinamentos preciosos, que contribuíram
significativamente para a conclusão deste.
Às empresas que permitiram a realização da pesquisa de campo, fornecendo
informações de suas experiências práticas, necessárias para a para a conclusão deste trabalho.
Enfim, agradeço a todas as pessoas que comigo contribuíram, de forma direta e indireta,
e que torceram pelo meu sucesso nesta jornada.
Muito obrigado !
RESUMO
O gerenciamento de riscos é considerado por alguns autores como um processo-chave e que
faz a diferença em gerenciamento de projetos, além de ser atualmente de grande importância
para governos, economias e empresas. A presente dissertação partiu do estudo de diversos
padrões de conhecimento e metodologias de gerenciamento de projetos, tanto de métodos
“tradicionais” quanto de métodos ágeis. Foram estudados também os processos de
gerenciamento de riscos destes métodos. Durante os estudos foi possível conhecer e
apresentar alguns modelos de gestão de riscos em projetos de desenvolvimento de software já
estudados por outros autores. A partir daí passou-se à análise de alguns métodos utilizados
para a identificação de riscos em projetos. Ao concluir os estudos citados e, após a pesquisa
de campo, foi possível conhecer a realidade de algumas empresas consideradas como
referência / líderes em sua área de atuação, observando-se na prática de que forma elas
utilizam tanto métodos “tradicionais” como métodos ágeis para gerenciamento de projetos e
de riscos. Por fim, a partir da investigação realizada, foi elaborada a proposta de um método
ágil para a identificação de riscos em projetos de desenvolvimento de software, alinhando os
conhecimentos dos métodos “tradicionais” e dos métodos ágeis.
Palavras-chave: Risco, Gerência de Risco, Gerência de Projetos, Desenvolvimento de
Software, Tecnologia da Informação e Comunicação.
ABSTRACT
Risk management is considered by some authors as a key process that makes the difference
and project management, and is currently of great importance to governments, businesses and
economies. This work was based on the study of patterns of knowledge and methodologies of
project management, both "traditional" and of "agile." We also studied the processes of risk
management of these "methods". During the studies was possible to meet and present some
models of risk management in software development projects already studied by other
authors. From there it moved to present some methods used to identify risks in projects. By
completing the studies mentioned above and after the fieldwork it was possible to know the
reality of some companies, taken as a reference / leaders in their field and that allowed us to
observe in practice how they use both "traditional" as "methods agile "project management
and risk. And finally, from the investigation, is a proposal for an agile method to identify risks
in software development projects, aligning the knowledge of "traditional" and "agile."
Keywords: Risk, Risk Management, Project Management, Software Development,
Information Technology and Communication.
LISTA DE FIGURAS
Figura 1: Ciclo de Vida. Fonte: PMI (2008, p.40) ........................................................................ 31
Figura 2: Visão geral das áreas de conhecimento em gerenciamento de projetos e os seus
processos. Fonte: PMI (2008) ..................................................................................... 33
Figura 3: Ciclo de Vida – PRINCE2. Fonte: SIEGELAUB (2004, p.3). ...................................... 35
Figura 4: Processos e Componentes “Áreas de conhecimento” – PRINCE2. ............................... 37
Figura 5: Ciclo de Vida – P2M. Fonte: PMAJ (2005, p.27).......................................................... 39
Figura 6: Torre de gerenciamento de projetos – P2M. Fonte: PMAJ (2005, p.11) ....................... 40
Figura 7: Ciclo de Vida do Scrum. Fonte: adaptado de VICENTE (2010, p.25) .......................... 47
Figura 8: Fases do APM. Fonte: HIGHSMITH, 2004 apud CONFORTO (2009, p.47) .............. 52
Figura 9: Ciclo de vida de um projeto. Fonte: DSDM (GIUFFRA; VILAIN (2010, p.4) ............ 55
Figura 10: Resumo dos processos de gerenciamento dos riscos do projeto – PMBOK (4ª
edição). Fonte: PMI (2008, p. 227)............................................................................. 64
Figura 11: Procedimento de gerência de Risco. Fonte: PRINCE2 (2010, p.7) ............................. 66
Figura 12: Visão geral do gerenciamento de riscos. Fonte: PMAJ (2005, p.138)......................... 67
Figura 13: Processo de gerenciamento de riscos. Fonte: PMAJ (2005, p.144) ............................. 68
Figura 14: Processos de gerenciamento de riscos. Fonte: DSDM Version (4.2) .......................... 73
Figura 15: Identificação de Riscos. Fonte: KOSCHO; RIES (2009, p.2) ..................................... 85
Figura 16: Processo de Identificação de Riscos. Fonte: CARR et al. (1993, p.13) ....................... 85
Figura 17: Fontes clássicas de problemas a considerar. Fonte: PMI (2008, p.176) ...................... 97
Figura 18: Segmento sobre o ambiente expandido por brainstorming. Fonte: PMI (2008,
p.176) .......................................................................................................................... 98
Figura 19: Processo de definição de projeto. Fonte: CHAPMAN & WARD (1997) apud
MACHADO (2002, p.42) ........................................................................................... 99
Figura 20: Padrões de conhecimento, normas e métodos de gerenciamento de projetos. Fonte:
Elaboração do autor. ................................................................................................. 100
Figura 21: Processos de gestão de riscos. Fonte: Elaboração do autor. ...................................... 101
Figura 22: Métodos de identificação de riscos. Fonte: Elaboração do autor. .............................. 102
Figura 23: Método adotado para identificação e classificação dos fatores de riscos. Fonte:
Elaboração do autor. ................................................................................................. 103
Figura 24: Abordagem adotada para propor um método ágil para a identificação de riscos em
projetos de TI. Fonte: Elaboração do autor. ............................................................. 103
Figura 25: Abordagem do trabalho em relação à metodologia de pesquisa. Fonte: Elaboração
do autor. .................................................................................................................... 104
Figura 26: Empresas participantes do estudo. Fonte: Elaboração do autor. ................................ 108
Figura 27: Esquema de um método ágil de identificação de riscos. Fonte: Elaboração do autor.130
LISTA DE GRÁFICOS
Gráfico 1: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação, segundo as
faixas de pessoal ocupado – Brasil – 2006 ................................................................. 18
faixas de faturamento - Brasil – 2006 ......................................................................... 18
grandes regiões - Brasil – 2006 .................................................................................. 19
Gráfico 4: Distribuição percentual das empresas nas atividades do setor de Tecnologia da
Informação e Comunicação – Brasil – 2003-2006 ..................................................... 20
Gráfico 5: Distribuição percentual do pessoal ocupado nas atividades do setor de Tecnologia
da Informação e Comunicação – Brasil – 2003-2006 ................................................ 21
Gráfico 6: Participação dos produtos e serviços de informática no total da receita de serviços
de informática – Brasil – 2003-2006 .......................................................................... 22
Gráfico 7: Participação dos produtos e serviços de desenvolvimento de softwares sob
encomenda no total da receita de serviços de desenvolvimento de softwares sob
encomenda - Brasil – 2003-2006 ................................................................................ 22
Gráfico 8: Avaliação do sucesso de projetos de Tecnologia da Informação - 1994-2009 ............ 26
Gráfico 9: Avaliação do sucesso de projetos de Tecnologia da Informação no Exterior de
1994-2009, comparado com avaliação de sucesso de projetos de Tecnologia da
Informação no Brasil-2006 e 2008 ............................................................................. 26
Gráfico 10: Principais causas de fracasso em projetos de TI - Brasil-2006 .................................. 27
Gráfico 11: Principais causas de fracasso em projetos de TI - Brasil-2008 .................................. 27
Gráfico 12: Quociente Locacional por Região da abordagem para gerenciamento de riscos ..... 151
Gráfico 13: Quociente Locacional por Estado das regiões que apresentaram QLRegião ≥ 1 e que
utilizam abordagem para gerenciamento de riscos baseada em uma metodologia
formal, estruturada por políticas, procedimentos e formulários ............................... 154
LISTA DE TABELAS
Tabela 1: População e Produto Interno Bruto a preços correntes e Produto Interno Bruto per
capita segundo as Grandes Regiões, Unidades da Federação e municípios – 2007 ... 23
Tabela 2: Comparativo dos métodos “tradicionais” de gerência de projetos ................................ 43
Tabela 3: Atores e responsabilidades do SCRUM. ....................................................................... 46
Tabela 4: Valores centrais do APM............................................................................................... 51
Tabela 5 – Princípios mestres do APM ......................................................................................... 51
Tabela 6: Comparativo dos métodos ágeis de gerência de projetos .............................................. 58
Tabela 7: Correspondência entre as abordagens tradicional e ágil de GP ..................................... 60
Tabela 8: Principais características entre GP de software, tradicional e ágil. ............................... 60
Tabela 9: Diferenças de abordagens de GP tradicional e ágil. ...................................................... 61
Tabela 10: Comparativo entre gerenciamento de projetos tradicional e gerenciamento de
projetos ágil. ............................................................................................................... 62
Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil ...................... 75
Tabela 12: Modelos/Abordagem de gestão de riscos em projetos de desenvolvimento de
software....................................................................................................................... 78
Tabela 13: Comparativo das abordagens de Gerenciamento de riscos para desenvolvimento de
software por Gusmão e Moura (2004) ........................................................................ 79
software por Oliveira G. (2006) ................................................................................. 80
software por Oliveira G. (2006) ................................................................................. 80
Tabela 16: Taxonomia de riscos em desenvolvimento de software do SEI. ................................. 86
Tabela 17: Modelo da Lista de riscos para sistemas de informação ............................................. 89
Tabela 18: Fatores de risco de desenvolvimento de software integrados...................................... 90
Tabela 19: Pontuação atribuída ao item probabilidade do roteiro de análise de riscos ............... 108
Tabela 20: Pontuação atribuída ao item impacto do roteiro de análise de risco ......................... 109
Tabela 21: Codificação das empresas pesquisadas...................................................................... 112
Tabela 22: Perfil dos entrevistados .............................................................................................. 113
Tabela 23: Perfil das empresas pesquisadas ................................................................................ 114
Tabela 24: Processos/Abordagens adotadas para gerenciamento de riscos pelas empresas
pesquisadas ............................................................................................................... 116
Tabela 25: Principais problemas/dificuldades para gerenciar riscos citados pelas empresas
pesquisadas ............................................................................................................... 118
Tabela 26: Classificação dos Fatores de Riscos integrados para desenvolvimento de software,
quanto às categorias propostas pelo SEI................................................................... 120
Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas ............................... 123
Tabela 28: Matriz de Informações obtidas a partir do Estudo de Benchmarking em
Gerenciamento de Projetos no Brasil – 2008. .......................................................... 146
Tabela 29: Identificação das variáveis utilizadas no QL dentro da Matriz de Informações
obtidas a partir do Estudo de Benchmarking em Gerenciamento de Projetos no
Brasil – 2008 ............................................................................................................. 147
Tabela 30: Abordagem adotada pelas empresas brasileiras para gerenciamento de riscos - por
região ........................................................................................................................ 149
Tabela 31: Quociente Locacional por Região da abordagem para gerenciamento de riscos ...... 150
estado ........................................................................................................................ 152
Tabela 33: Quociente Locacional da abordagem para gerenciamento de riscos por Estado ....... 153
Tabela 34: Lista de riscos para sistemas de informação .............................................................. 156
Tabela 35: Lista de riscos para sistemas de informação eliminados citados por Mulcahy
(2010)........................................................................................................................ 165
Tabela 36: Fatores de Riscos de desenvolvimento de software citados por Mulcahy (2010) ..... 172
Tabela 37: Fatores de Riscos considerados duplicados ............................................................... 173
Tabela 38: Fatores de Riscos integrados para desenvolvimento de software.............................. 176
Tabela 39: Análise dos fatores de riscos segundo a empresa “A”............................................... 178
Tabela 40: Análise dos fatores de riscos segundo a empresa “B” ............................................... 182
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” ............................................... 185
Tabela 42: Análise dos fatores de riscos segundo a empresa “D”............................................... 189
Tabela 43: Análise dos fatores de riscos segundo a empresa “E” ............................................... 193
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” ............................................... 196
Tabela 45: Fatores de Riscos integrados para desenvolvimento de software, quanto à Fase de
Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas ................ 201
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas ......... 204
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas ............... 206
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas
pesquisadas ............................................................................................................... 209
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas ........ 212
Avaliação Pós-Encerramento do ciclo de vida do projeto, segundo as empresas
pesquisadas ............................................................................................................... 215
SUMÁRIO
LISTA DE FIGURAS ....................................................................................................................................17
LISTA DE GRÁFICOS .................................................................................................................................18
LISTA DE TABELAS ...................................................................................................................................19
INTRODUÇÃO .............................................................................................................................................11
JUSTIFICATIVA................................................................................................................................................... 11
PROBLEMATIZAÇÃO .......................................................................................................................................... 13
PRESSUPOSTOS E QUESTÕES DA PESQUISA ......................................................................................................... 14
OBJETIVOS ........................................................................................................................................................ 14
Geral ............................................................................................................................................................ 14
Específicos ................................................................................................................................................... 14
ORGANIZAÇÃO DA DISSERTAÇÃO / ESTRUTURA DO TRABALHO ......................................................................... 15
1 ANÁLISE DO CONTEXTO DO GERENCIAMENTO DE RISCOS EM PROJETOS DE
TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO (TIC) .........................................................16
1.1
1.2
1.3
1.4
A ANÁLISE ............................................................................................................................................... 16
ELEMENTOS SOCIOECONÔMICOS DO SETOR DE TIC NO BRASIL ............................................................... 17
ANÁLISE DE PROJETOS DESENVOLVIDOS NO BRASIL E NO EXTERIOR ...................................................... 24
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
2.1.1.2
2.1.1.3
2.1.1.4
2.1.2
Project Management Book of Knowledge (PMBOK) ................................................................................30
Project in a Controlled Environment (PRINCE2) .....................................................................................34
A Guidebook for Project and Program Management for Enterprise Innovation (P2M) ...........................38
Comparativo dos métodos ―tradicionais‖ .................................................................................................43
Métodos ágeis ................................................................................................................................ 44
2.1.2.1
2.1.2.2
2.1.2.3
2.1.2.4
Scrum.........................................................................................................................................................44
Agile Project Management (APM) ............................................................................................................50
Dynamic Systems Development Method (DSDM) .....................................................................................54
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
2.2.1.2
2.2.1.3
2.2.2
Abordagem do Project Management Book of Knowledge (PMBOK) ........................................................63
Abordagem do Project In a Controlled Environment (PRINCE2).............................................................64
Abordagem do Guidebook for Project and Program Management for Enterprise Innovation (P2M) ......66
Métodos ágeis ................................................................................................................................ 69
2.2.2.1
2.2.2.2
2.2.2.3
Abordagem do Scrum ................................................................................................................................69
Abordagem do Agile Project Management (APM) ....................................................................................71
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
3.2
3.3
3.4
INSTRUMENTO DE COLETA DE DADOS PARA PESQUISA DE CAMPO .......................................................... 105
EMPRESAS PARTICIPANTES E COLETA DE DADOS E INFORMAÇÕES ......................................................... 107
FORMA DE TABULAÇÃO E ANÁLISE DOS RESULTADOS ............................................................................ 110
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?
1
Benchmarking “envolve a comparação de práticas de projetos reais ou planejados com as de projetos
comparáveis para identificar as melhores práticas, gerar idéias para melhorias e fornecer uma base para medir o
desempenho. Esses outros projetos podem estar na organização executora ou fora dela, e podem estar dentro da
mesma área de aplicação ou em outra área” (PMI, 2008, p. 167).
14
 Se houver um método ágil de gerenciamento de riscos, isso facilitará sua
adoção pelas empresas ?
Pressupostos e questões da pesquisa
Com base na pesquisa anunciada, parte-se do princípio de que as empresas de TIC
negligenciam riscos em seus projetos, por alguns motivos, abaixo anunciados:
 desconhecimento dos benefícios que o gerenciamento de risco proporciona;
 falta de planejamento dos riscos em projetos;
 inadequação de metodologia de gerenciamento de projetos;
 falhas na identificação de riscos corretamente;
 falta de estrutura (de pessoal, de recursos financeiros e materiais) que atenda às
exigências básicas de sua utilização.
Objetivos
Geral
Realizar um estudo na região metropolitana de Goiânia e Brasília a respeito de
gerenciamento de riscos por meio de uma investigação e avaliação sobre riscos em projetos
de TI, e propor reflexões para apresentação de um método ágil para identificação de riscos.
Específicos
a. Identificar métodos “tradicionais” de gerenciamento de projetos.
b. Identificar métodos ágeis de gerenciamento de projetos.
c. Identificar padrões de conhecimento, metodologias ou normas para a área de TI,
sobre gerenciamento de riscos em projetos.
d. Verificar como os padrões de conhecimento, metodologias ou normas tratam o
gerenciamento de riscos.
e. Levantamento e atualização de uma taxonomia de riscos, atualizada, para projetos de
TI.
f. Avaliar como as empresas de TI, pesquisadas, identificam e tratam os riscos em seus
projetos.
15
g. Propor uma priorização de riscos para projetos de TI nas empresas pesquisadas.
h. A partir da investigação realizada fazer uma proposta de um método ágil de
identificação de riscos para projetos de TI.
Organização da dissertação / Estrutura do trabalho
Esta dissertação está organizada em cinco capítulos.
No Capítulo 1 é mostrada uma visão geral do contexto regional sobre gerência de
projetos em empresas de tecnologia da informação e comunicação (TIC). Essa visão geral
será exposta a partir do levantamento de alguns elementos socioeconômicos sobre o setor de
TIC no Brasil e o potencial de desenvolvimento da região Centro-Oeste, com destaque para as
cidades de Brasília, no Distrito Federal, Goiânia e Aparecida de Goiânia ambas no Estado de
Goiás. Será mostrada uma análise de projetos de TIC desenvolvidos no Brasil e no exterior.
O Capítulo 2 apresenta a fundamentação teórica da dissertação, em que serão mostrados
padrões de conhecimento e metodologias de gerência de projetos divididos em “métodos
tradicionais”2 e métodos ágeis, logo após é feita uma comparação entre os mesmos. São
apresentados, ainda, os processos de gerenciamento de riscos para os métodos “tradicionais” e
métodos ágeis, bem como uma comparação entre os mesmos. São abordados alguns modelos
de gestão de riscos em projetos de desenvolvimento de software e também uma comparação
entre eles. Após isso são mostrados os métodos para identificação de riscos.
No Capítulo 3 são definidos os detalhamentos da metodologia da pesquisa adotada para
este trabalho.
O Capítulo 4 apresenta a análise das informações da pesquisa, apresentando o perfil dos
entrevistados, o perfil das empresas, um levantamento sobre o gerenciamento de riscos em
projetos nessas empresas, e sua abordagem a diversos fatores de riscos apresentados.
O Capítulo 5 apresenta uma proposta de um método ágil para identificação de riscos em
projetos de desenvolvimento de software a partir da pesquisa de campo e do levantamento
bibliográfico realizado.
Finalmente, na conclusão, são apresentas as contribuições deste trabalho, as limitações
encontradas e a perspectiva de trabalhos futuros.
2
A expressão “métodos tradicionais” foi utilizada aqui para diferenciar alguns padrões de conhecimento e
metodologias de gerência de projetos dos métodos ágeis, já conhecidos com este nome.
16
1
ANÁLISE DO CONTEXTO DO GERENCIAMENTO DE RISCOS EM
PROJETOS DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO (TIC)
1.1
A Análise
Este capítulo discute os resultados de pesquisas recentes sobre projetos de Tecnologia
da Informação e Comunicação (TIC), onde pretende-se apresentar uma análise do contexto
regional em projetos de TIC, que pode mostrar aos profissionais da área a importância do
setor e o cenário de sucessos e fracassos de projetos.
Para realizar a análise do contexto regional em projetos de TIC, foram utilizados
elementos socioeconômicos. Os elementos sociais são aqueles que determinam as condições
de vida dos setores da sociedade: emprego, renda, serviços, etc. Já os elementos econômicos
são aqueles referentes à estrutura setorial econômica: setor primário, secundário e terciário.
Neste sentido focaremos os estudos no setor terciário.
A análise regional foi realizada a partir de estudo dos elementos socioeconômicos e da
avaliação de projetos desenvolvidos no Brasil e no exterior. Para Simões (2003), o
desenvolvimento econômico deve ser analisado, levando-se em conta duas variáveis
fundamentais que são espaço e tempo, pois não existe nada que não se localize muito concreta
e precisamente no tempo e no espaço. A análise dos elementos socioeconômicos é
apresentada por meio de uma visão geral sobre o setor de TIC no Brasil e o potencial da
região Centro-Oeste a partir de dados da população e do PIB, procurando caracterizar a região
compreendida por Brasília, Goiânia e Aparecida de Goiânia. Na análise da avaliação de
projetos desenvolvidos no Brasil e no exterior são apresentadas pesquisas comparando
projetos desenvolvidos nestes universos.
No contexto do presente trabalho, os termos (a) tecnologia da informação e
comunicação e (b) gerenciamento de riscos terão significados, conforme abaixo:
 Tecnologia da Informação e Comunicação (TIC): é um conjunto de recursos
tecnológicos que, se estiverem integrados entre si, podem proporcionar a
automação e/ou a comunicação de vários tipos de processos existentes nos
negócios, no ensino e na pesquisa científica, na área bancária e financeira etc,
ou seja, são tecnologias usadas para reunir, distribuir e compartilhar
informações, como por exemplo, sites da Web, equipamentos de informática
(hardware e software), telefonia, quiosques de informação e balcões de
serviços automatizados (GLOSSÁRIO DE TI, 2009);
17
 Gerenciamento de Riscos: o gerenciamento de riscos do projeto inclui os
processos relacionados com o planejamento, identificação, análise, elaboração
de respostas, monitoramento e controle dos riscos em um projeto (PMI, 2008).
1.2
Elementos socioeconômicos do setor de TIC no Brasil
O setor de TIC no Brasil, principal interesse deste estudo, vem assumindo maior
relevância em função do progresso tecnológico que se observa em níveis nacional e global
(IBGE, 2009). Aqui será mostrado em destaque o potencial da região Centro-Oeste a partir de
dados da população e do PIB, procurando caracterizar a região compreendida por Brasília,
Goiânia e Aparecida de Goiânia.
Estudo publicado pelo IBGE sobre o setor de TIC no Brasil nos anos de 2003 a 2006
(IBGE, 2009), apresenta um panorama em nível nacional e busca destacar as especificidades
desse setor e suas características estruturais e econômicas, com ênfase no número de
empresas, empregos gerados, custos, receitas, geração de valor adicionado, produtividade e
comércio exterior.
Com relação ao mencionado estudo do IBGE, foram abordados os assuntos referentes à
quantidade de empresas, quantidade de pessoal ocupado, pessoal ocupado por porte de
empresas, produtividade do setor por porte de empresas, pessoal ocupado por grandes regiões
do Brasil, número de empresas dos setores econômicos (indústria, comércio e serviço) de
TIC, distribuição das empresas nas atividades dos setores de TIC, distribuição do pessoal
ocupado nestas atividades, salário médio mensal dos setores econômicos de TIC, participação
dos produtos e serviços de informática no total da receita de serviços de informática e
participação dos produtos e serviços de desenvolvimento de softwares sob encomenda no total
da receita desse serviço no período de 2003-2006.
Em relação às dimensões do setor no Brasil, o número de empresas do setor de TIC, no
ano de 2006, era formado por 65.754 empresas, apresentando um crescimento de 18,3% em
relação a 2003 quando existiam 55.597 empresas. Neste mesmo período 2003-2006 a
quantidade de pessoal ocupado também cresceu em torno de 40,7% passando de 478.446, em
2003, para 673.024 pessoas ocupadas, em 2006. Comparando as dimensões do setor de TIC
com o universo empresarial brasileiro verifica-se uma estabilidade no total de empresas
passando de 2,4%, em 2003, para 2,5%, em 2006, e um ligeiro crescimento com relação ao
pessoal ocupado passando de 2,6%, em 2003, para 3,0%, em 2006.
18
Gráfico 1: Pessoal ocupado do setor de Tecnologia da Informação e Comunicação,
segundo as faixas de pessoal ocupado – Brasil – 2006
Fonte: IBGE, 2009. O Setor de Tecnologia da Informação e Comunicação no Brasil 2003-2006
segundo as faixas de faturamento - Brasil – 2006
Tanto no Gráfico 1 como no Gráfico 2, percebe-se que a grande maioria do pessoal
ocupado está concentrado em empresas grandes, com 250 ou mais pessoas e com faturamento
acima de 60 milhões de reais. Um fato interessante é que o segundo lugar em percentual de
pessoal ocupado vem exatamente do outro extremo, ou seja, em empresas pequenas, de 0 a 9
pessoas ocupadas e com faturamento de até 2,4 milhões de reais.
19
Conforme Gráfico 3, em 2006, o setor de TIC estava concentrado na região Sudeste,
aparecendo em segundo lugar a região Sul, sendo que as outras três regiões, Norte, Nordeste e
Centro-Oeste apresentam participação relativamente próximas.
segundo as grandes regiões - Brasil – 2006
Enquanto o número de empresas dos setores econômicos do Brasil (indústria, comércio
e serviços) cresceu 14,2%, de 2003-2006, saindo de 2.297.425 empresas em 2003, para
2.624.385 empresas, em 2006, o número de empresas do setor de tecnologia da informação e
comunicação cresceu 18,3%, de 55.597, em 2003, para 65.754, em 2006, ou seja, o setor de
TIC apresentou um crescimento de 4,1% pontos percentuais acima dos demais setores
econômicos do Brasil. De todos os grupos de atividades que compreendem este setor,
percebe-se que a grande maioria das empresas, aproximadamente 90%, está situada no grupo
de atividades de informática (Gráfico 4).
Mais de 55% do pessoal ocupado no setor de TIC estão nas empresas pertencentes ao
grupo de atividades de informática: em segundo lugar, com aproximadamente 26% estão as
empresas que exercem atividades industriais do setor de TIC e em terceiro lugar, com
aproximadamente 14% do pessoal ocupado, estão as empresas de telecomunicações (Gráfico
5).
20
Gráfico 4: Distribuição percentual das empresas nas atividades do setor de Tecnologia
da Informação e Comunicação – Brasil – 2003-2006
O salário médio mensal dos setores econômicos do Brasil (indústria, comércio e
serviços) cresceu 7,1%, no período 2003-2006, saindo de R$ 875,07 para R$ 937,48. No setor
de TIC aconteceu uma redução de 1,54%, no mesmo período, de R$ 2.056,85 para R$
2.025,18, mesmo assim os salários do setor de TIC são 116% superiores, conforme mostra
estudo do IBGE sobre o Setor de Tecnologia da Informação e Comunicação no Brasil 20032006.
Quanto aos produtos relacionados ao grupo de desenvolvimento de softwares sob
encomenda, estes representam aproximadamente um terço do total das receitas do setor; em
segundo lugar aparecem os produtos relacionados ao grupo de desenvolvimento, edição e
licenciamento de softwares prontos para uso, com aproximadamente 18% do total das
receitas. Conclui-se que os produtos relacionados a estes dois grupos participam com mais de
50% no total da receita de serviços de informática (Gráfico 6).
21
Gráfico 5: Distribuição percentual do pessoal ocupado nas atividades do setor de
Tecnologia da Informação e Comunicação – Brasil – 2003-2006
Do total da receita do grupo de serviços de desenvolvimento de softwares sob
encomenda, aproximadamente 64% são produtos relacionados ao desenvolvimento de
softwares específicos para o cliente, e em segundo lugar aparecem os produtos relacionados a
outsourcing3 com aproximadamente 29,6%. Assim, conclui-se que os produtos relacionados a
estes dois itens participam com mais de 90% no total da receita de serviços de
desenvolvimento de softwares sob encomenda (Gráfico 7).
Os resultados apresentados neste estudo do IBGE (2009) permitem obter uma visão
geral da dimensão do setor de TIC, seu peso relativo no conjunto de atividades industrial,
comercial e de serviços, bem como sua contribuição para a geração de renda e emprego. É
importante ressaltar que esses resultados referem-se à parte visível da economia, integrada
pelas empresas formalmente constituídas.
3
Outsourcing é a passagem de processos e serviços de TI das companhias para outras empresas, especialistas na
oferta. Com isto procura-se reduzir custos e a melhoria da qualidade do serviço prestado. É um processo através
do qual uma organização (contratante) contrata outra (subcontratado), na perspectiva de manter com ela um
relacionamento mutuamente benéfico, de médio ou longo prazo, com vista ao desempenho de uma ou várias
atividades, que a primeira não pode ou não lhe convém desempenhar e que a segunda é tida como especialista.
Também é chamada de terceirização. (GLOSSÁRIO DE TI, 2009)
22
Gráfico 6: Participação dos produtos e serviços de informática no total da receita de
serviços de informática – Brasil – 2003-2006
Gráfico 7: Participação dos produtos e serviços de desenvolvimento de softwares sob
encomenda no total da receita de serviços de desenvolvimento de softwares sob
encomenda - Brasil – 2003-2006
23
Após esta visão geral sobre o setor de TIC serão apresentados dados sobre o tamanho do
mercado, com relação à população e ao PIB da região Centro-Oeste e, mais especificamente,
das cidades de Brasília, Goiânia e Aparecida de Goiânia.
Conforme descrito na Tabela 1, a população da região Centro-Oeste representa 7,2%
(13.222.854 habitantes) da população do Brasil (183.987.291 habitantes) enquanto as cidades
de Brasília, Goiânia e Aparecida de Goiânia possuem juntas 4.175.851 habitantes,
representando 31,6% da população do Centro-Oeste, aproximadamente 1/3 (IBGE, 2007).
Dentre as cinco regiões do Brasil, o Centro-Oeste ocupa o quarto lugar em relação ao
PIB Brasileiro e o segundo lugar em relação ao PIB per capita, perdendo apenas para a região
Sudeste (Tabela 1). Em relação às cidades de Brasília, Goiânia e Aparecida de Goiânia, juntas
possuem um PIB de R$ 120.895.039.000, representando 51,2% do PIB da região CentroOeste 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
População
Grandes Regiões, Unidades da
recenseada e
Federação e Municípios
estimada
(2007)
PIB 2007
A preços
correntes
(R$ 1.000)
(R$)
Brasil
183.987.291
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
475.303
3.082.081
6.484
1.244.645
17.867.338
14.355
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
Aparecida de Goiânia
Goiânia
Outros municípios de Goiás
Fonte: IBGE, Contagem da População 2007.
2.661.344.525
Per capita
14.465
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 CentroOeste. 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 PradoMMGP (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
5
Site: www.standishgroup.com/chaos
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
120%
100%
80%
31%
40%
60%
40%
53% 33%
51% 53% 46%
44%
46% 49%
26% 31%
Fracasso
Sucesso Parcial
53% 54%
20%
0%
15% 18% 19%
15%
24% 21%
28% 23%
16%
27% 26% 28% 34% 29% 35% 32%
Sucesso
Fontes: Pesquisa Archibald & Prado 2008
De acordo com a pesquisa da Módulo (Módulo, 2006), 78% das empresas brasileiras
investem na análise de riscos em TI. Pelo exposto, fica evidente que se houver uma melhora
27
no gerenciamento de riscos (identificação e tratamento adequado de riscos do início ao fim de
um projeto) pode haver uma chance de minimizar as causas de fracasso e aumentar o sucesso
dos projetos, conforme citado também pela pesquisa do Standish Group, 2002.
Gráfico 10: Principais causas de fracasso em projetos de TI - Brasil-2006
Gráfico 11: Principais causas de fracasso em projetos de TI - Brasil-2008
Machado (2002) descreve que a falha nos projetos é discutida em algumas pesquisas,
como a apresentada por Curtis e Statz (CURTIS & STATZ, 1996) em que, em 1992 e 1993,
mais de 60% dos projetos pesquisados nos Estados Unidos da América (EUA) estavam
28
atrasados e mais da metade ultrapassava em 50% o prazo planejado. O estudo conduzido por
Gordon (1999, citado por Machado, 2002) indicou que somente 37% dos Sistemas de
Informação foram finalizados no prazo estipulado. Adicionalmente, dos 63% dos projetos que
atrasaram, 42% seriam finalizados acima do orçamento.
Os projetos de software lidam com um alto nível de incertezas, oriundas das mais
diversas fontes, dentre elas, a mudança de tecnologia, a imaturidade nos processos, a
adequação do perfil técnico para exercer uma atividade e a mudança contínua de requisitos
(MACHADO, 2002). Portanto, apresentam-se as incertezas como uma fonte de risco em
potencial.
1.4
Síntese da Gestão de riscos no Brasil
Conforme mencionado, este capítulo se propôs a realizar a análise regional sobre o
contexto do gerenciamento de riscos em projetos de TIC, procurando mostrar a dimensão e
importância do setor de TIC no Brasil, que vem assumindo maior relevância na nossa
economia, em função do progresso tecnológico que se observa em níveis nacional e global; o
potencial da região Centro-Oeste; a incidência de sucesso e fracasso de nossos projetos em
relação ao de outros países e as causas mais freqüentes de fracassos em projetos de TIC no
Brasil.
Discute ainda os resultados de pesquisas realizadas nos últimos anos em projetos de
TIC, em que foi apresentada análise do contexto regional em projetos de TIC, e que podem
mostrar, aos profissionais de projeto, a importância do setor e o cenário de sucessos e
fracassos.
Analisando-se os dados referentes a “Pessoal Ocupado”, as grandes empresas são as que
mais possuem pessoal ocupado e, em segundo lugar, estão as pequenas empresas. O CentroOeste é 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
Gerenciamento do Escopo do
Projeto
Gerenciamento do Tempo do
Projeto
1. Desenvolver o termo de abertura
do projeto
1. Coletar os requisitos
1. Definir as atividades
2. Definir o escopo
2. Seqüenciar as atividades
2. Desenvolver o plano de
gerenciamento do projeto
3. Criar a EAP
3. Estimar os recursos da atividade
3. Orientar e gerenciar a execução do
projeto
4. Verificar o escopo
4. Estimar as durações da atividade
5. Controlar o escopo
5. Desenvolver o cronograma
6. Controlar o cronograma
4. Monitorar e controlar o trabalho do
projeto
5. Realizar o controle integrado de
mudanças
6. Encerrar o projeto ou fase
Gerenciamento dos Custos do
Projeto
Gerenciamento da Qualidade do
Projeto
Gerenciamento dos Recursos
Humanos do Projeto
1. Estimar os custos
1. Planejar a qualidade
2. Determinar o orçamento
2. Realizar a garantia da qualidade
1. Desenvolver o plano de recursos
humanos
3. Controlar os custos
3. Realizar o controle da qualidade
2. Mobilizar a equipe do projeto
3. Desenvolver a equipe do projeto
4. Gerenciar a equipe do projeto
Gerenciamento das
Comunicações do Projeto
Gerenciamento dos Riscos do
Projeto
Gerenciamento das Aquisições
do Projeto
1. Planejar o gerenciamento dos
riscos
1. Planejar as aquisições
2. Planejar as comunicações
3. Distribuir informações
2. Identificar os riscos
3. Administrar as aquisições
4. Gerenciar as expectativas das
partes interessadas
3. Realizar a análise qualitativa dos
riscos
4. Encerrar as aquisiçòes
5. Reportar o desempenho
4. Realizar a análise quantitativa dos
riscos
1. Identificar as partes interessadas
2. Realizar as aquisições
5. Planejar as respostas aos riscos
6. Monitorar e controlar os riscos
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
Controlando um
estágio
Iniciando
um projeto
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).
Entrega
Concepçã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
I. Entrada
Entrada
II. Gerenciamento
de Projeto
III. Gerenciamento
de Programa
1.
2.
3.
4.
5.
Gerenciamento de Projeto
Atributo, definição de base, quadro
Gerenciamento de projetos visão comum
Gestão da integração
Gestão do segmento
Competências a gestão da integração
1.
2.
3.
4.
5.
6.
7.
8.
Gerenciamento de Programa
Atributo, definição de base, quadro
Plataforma de programa
Perfil de gestão
Estratégia de gestão do programa
Gerenciamento de arquitetura
Plataforma de gestão
Gerenciamento ciclo do programa
Gestão de valor
IV. Gestão do Segmento
Gestão do Segmento
Estratégia de Gestão de Projeto
Gestão Financeira do Projeto
Sistemas de Gestão de Projeto
Gestão de Organização do Projeto
Gestão de Objetivo do Projeto
Gestão dos 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
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.
Definição de
projeto
Ciclo de vida
Método de gestão de projetos.
Um Guia para a Gestão de
Projetos e Programa de Inovação
Empresarial.
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.
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,
implementação,
entrega.
Fonte: PMI (2008); Ângelo (2008) e Siegelaub (2004); PMAJ (2005) adaptado pelo autor.
planejamento,
coordenação e
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;
Scrum
Master:
Líder
 Gerencia o processo do Scrum, ensinando o Scrum a todos os envolvidos no projeto e
 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.
 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 “autoorganizada”. 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
Valor ao cliente
PRINCÍPIO
Entregar valor ao cliente
Gerar entregas iterativas e baseadas em funcionalidades
Buscar a excelência técnica
Estilo
baseado
de
na
colaboração
gerenciamento
liderança
e
Encorajar a exploração
Construir times adaptativos (auto-organizados e autodisciplinados)
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
O que é
SCRUM
(1)
 É 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 autoorganização.
Agile Project
Management (APM)
(2)
 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.
 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 (autoorganizados e autodisciplinados).
 Simplifica .
Dynamic Systems Development Method
(DSDM)
(3)
 É 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.
 Pequenas equipes de
 O ponto fundamental desta metodologia
trabalho são organizadas de
prende-se à entrega de um sistema que se
modo a “maximizar a
aproxime das atuais necessidades de negócio.
comunicação, minimizar a
 Nenhum sistema é completamente
supervisão e maximizar o
construído na primeira tentativa.
compartilhamento de
 A entrega do projeto deve ser feita na data
conhecimento tácito
estipulada, dentro do orçamento previsto e
informal”.
com boa qualidade.
 O processo precisa ser
 Testes ao longo de cada iteração.
adaptável tanto às
 Entregas freqüentes.
modificações técnicas quanto
 As exigências para o Sistema de
de negócios “para garantir
Informação têm que ser flexíveis.
que o melhor produto
 Requer que cada etapa do desenvolvimento
possível seja produzido”.
seja completada até que seja possível iniciar
 O processo produz
o passo seguinte. Isto faz com que cada fase
freqüentes incrementos de
do projeto possa começar sem ter que esperar
software “que podem ser
que as fases que começaram anteriormente
inspecionados, ajustados,
sejam totalmente terminadas.
testados, documentados e
 A comunicação entre todas as partes
expandidos”.
envolvidas (stakeholders) é também um pré O trabalho de
requisito bastante importante para que o
desenvolvimento e o pessoal
projeto corra com a eficiência desejada.
que o realiza é dividido “em
 O envolvimento dos utilizadores é a chave
partições claras, de baixo
para esta eficiência.
acoplamento, ou em pacotes”.
 As equipes responsáveis têm que ser
 Testes e documentação
dotadas de um sentido de decisão, sendo este
constantes são realizados à
também um ponto fulcral na progressão do
medida que o produto é
projeto.
construído.
 As equipes de gestão do projeto estão
 O processo Scrum fornece
incorporadas na DSDM.
a “habilidade de declarar o
 Após o desenvolvimento do Sistema de
produto „pronto‟ sempre que
Informação, a DSDM pode também ser usada
necessário (porque a
para expandir o Sistema obtido.
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 ...)”.
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).
Princípios /
Características
59
Tabela 6: Comparativo dos métodos ágeis de gerência de projetos (Cont.)
ITEM
SCRUM
(1)
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:
Agile Project
Management (APM)
(2)
 Visão;
 Especulação;
 Exploração;
 Adaptação;
 Encerramento.
Dynamic Systems Development Method
(DSDM)
(3)
 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
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.
Cascata, espiral e iterativo.
Iterativo e incremental.
Modelo
desenvolvimento
de
Fonte: Ribeiro; Arakaki (2006) apud LOPES (2008)
em
todas
as
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
objetivo planejado (tempo, orçamento, escopo).
Objetivo: simplificar processo de desenvolvimento,
minimizando e dinamizando tarefas e artefatos.
Fonte: Magalhães (2004)
o
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
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
refatoração.
em
Riscos
Análise de riscos durante todo o ciclo de vida do
projeto.
Aplica-se o
tradicional.
mesmo
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.
PROCESSO
Comunicação
Fonte: Costa (2008)
9
Gold plating: impedir a realização de trabalho extra que não faça parte do projeto.
pares,
testes
conceito
incrementais
do
e
gerenciamento
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
Identificar os riscos
1. Entradas
 Plano de gerenciamento dos riscos
Realizar a análise qualitativa dos
riscos
1. Entradas
 Registro dos riscos
 Plano de gerenciamento dos custos
 Estimativa de custos das atividades
 Plano de gerenciamento do cronograma
 Estimativa de duração das atividades
 Declaração do escopo do projetos
 Plano de gerenciamento das
comunicações
 Fatores ambientais da empresa
 Linha de base do escopo
 Ativos de processos organizacionais
2. Ferramentas e técnicas
 Reuniões e análises de planejamento
3. Saídas
Realizar a análise quantitativa dos
riscos
1. Entradas
 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
 Registro de partes interessadas
 Plano de gerenciamento da qualidade
 Documentos do projeto
 Fatores ambientais da empresa
 Revisões de documentação
 Técnicas de coleta de informações
 Análise de listas de verificação
 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
3. Saídas
 Análise de premissas
 Técnicas de diagramas
 Análise das forças, fraquezas,
oportunidades e ameaças
3. Saídas
Planejar as respostas aos riscos
1. Entradas
 Estratégias para riscos negativos ou
ameaças
 Estratégias para riscos positivos ou
oportunidades
 Estratégias de respostas de
contingência
3. Saídas
 Decisões contratuais relacionadas a
riscos
 Atualizações do plano de gerenciamento
do projeto
 Atualizações dos documentos do projeto
Monitorar e controlar os riscos
1. Entradas
 Plano de gerenciamento do projeto
 Informações sobre o desempenho do
trabalho
 Relatórios de desempenho
 Reavaliação de riscos
 Auditorias de riscos
 Análise da variação e tendências
 Medição de desempenho técnico
 Análise das reservas
 Reuniões de andamento
3. Saídas
 Atualizações dos ativos de processos
organizacionais
 Solicitações de mudanças
 Atualizações do plano de gerenciamento
do projeto
 Atualizações dos documentos do projeto
Figura 10: Resumo dos processos de gerenciamento dos riscos do projeto – PMBOK (4ª
edição). Fonte: PMI (2008, p. 227)
2.2.1.2 Abordagem do Project In a Controlled Environment (PRINCE2)
O PRINCE2 define o gerenciamento de riscos em momentos-chave onde os riscos
devem ser avaliados e revisados, além da abordagem a ser aplicada em sua manutenção.
65
O gerenciamento de riscos do projeto inclui os processos relacionados com identificar
os riscos, avaliar os riscos, identificar as respostas adequadas ao risco, selecionar, planejar os
recursos e monitorar e controlar os riscos.
O objetivo do gerenciamento de riscos, segundo o PRINCE2, é identificar, avaliar e
controlar a incerteza (riscos) e, como conseqüência, ampliar a capacidade de sucesso do
projeto.
A ocorrência de riscos em projetos é inevitável, já que são geralmente portadores de
mudanças e as mudanças podem introduzir uma incerteza, ou seja, o risco.
O gerenciamento de riscos deve ser sistemático e não com base ao acaso. Trata-se da
proatividade na identificação, avaliação e controle dos riscos que podem afetar os objetivos
do projeto.
O projeto deve estimar um orçamento para o gerenciamento de riscos com o objetivo de
apoiar uma melhor tomada de decisão através de uma boa compreensão dos riscos: suas
causas, probabilidade, impacto, cronograma, e seleção de respostas aos riscos (PRINCE2,
2010).
O gerenciamento de risco é uma atividade contínua, realizada ao longo do ciclo de vida
do projeto. Sem um processo contínuo e eficaz de gerenciamento de riscos torna-se difícil
fazer com que o projeto seja capaz de atingir os seus objetivos.
Segundo PRINCE2 (2010) para que o gerenciamento de risco seja eficaz, os riscos
devem ser identificados, avaliados e controlados.
Identificar significa incluir os riscos que poderiam afetar a realização dos objetivos do
projeto e, em seguida deve-se descrevê-los para garantir um entendimento (compreensão)
comum desses riscos.
Avaliar significa assegurar que cada risco possa ser classificado em termos de
estimativa, probabilidade de ocorrência e impacto.
Controlar significa identificar respostas adequadas aos riscos e depois executar,
acompanhar e controlar estas respostas.
O PRINCE2 (2010) recomenda um procedimento de gerência de risco que compreende
cinco etapas (Figura 11).
66
Identificação
Implementar
Comunicar
Estimar e
Avaliar
Planejar
respostas aos
riscos
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 4implementaçã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
Mudanças ambientais
Condições de restrição
• Projetos sempre trazem incerteza e risco.
• Pense que o risco pode ser gerenciado.
• 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
• 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
Processos de Trabalho
• 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.
Resultados
• 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.
• 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.
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
Monitoramento e controle dos riscos
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)
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
acompanhamento da implementação de identificação de riscos.
controle
e
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
Avaliar e Atualizar
o Documento de
Riscos
Monitorar os
Riscos
Responder aos
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
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.
Planejamento Define como Pressupõe que a
conduzir as
mesma
atividades de abordagem para
gerenciamento o gerenciamento
dos riscos que de risco será
serão
usada em todos
executadas para os projetos.
o projeto.
76
Tabela 11: Comparativo dos métodos de gerência de projetos “tradicional” e ágil (Cont.)
ATIVIDADES
DA
GERÊNCIA
DE RISCO
PMI
PRINCE2
P2M
SCRUM
APM
DSDM
Analisa quais as A identificação dos Toda a equipe
Os riscos são
fontes de risco ou riscos deve
participa deste
identificados,
eventos que
acontecer: a) durante exercício de forma classificados e
exercem
a Sprint Planning 1, iterativa e os
documentados a
influência sobre a com foco nos itens resultados são
partir do início do
implementação do com maior valor de anotados em post-it projeto e com o
projeto e descreve negócio; b) durante ou no flip chart.
apoio de uma lista
as características as reuniões diárias
formal de riscos,
dos riscos em
como possíveis
verificando
documentos
impedimentos para o
também os
através de
projeto.
requisitos que têm
brainstorming e
uma prioridade
revisão de
elevada no projeto.
requisitos dos
contratos.
Prioriza os
Coberto como
A análise de riscos É feita através de
É feita uma
Análise
acima. Oferece o
deve ser realizada uma análise
classificação dos
Qualitativa de riscos para
análise e define registro de riscos
durante a Sprint
qualitativa de risco riscos durante o
Riscos
as condições para ajudar no
Planning 1 e
usando julgamento, processo de
para priorizar controle dos
compreende etapas intuição e experiência identificação dos
seus efeitos nos riscos.
para determinar: o na determinação de riscos.
objetivos do
impacto, a
riscos e perdas
projeto.
probabilidade e o
potenciais. Nas
fator de exposição iterações dos
do risco.Sugere-se processos ágeis, ou
que os riscos sejam seja, durante os ciclos
priorizados. Após a curtos de
priorização, os riscos desenvolvimento e
considerados mais revisões constantes,
urgentes devem ser isso se torna possível
gerenciados e
e eficaz. Isso é
mitigados na
diferente de projetos
próxima Sprint. Os tradicionais, onde a
demais riscos ficam análise quantitativa é
“guardados” sendo feita e os números
reavaliados na
são atribuídos aos
próxima reunião de danos que podem
Sprint Planning. A ocorrer.
priorização dos
Mede a
Sugere
O processo de
Análise
riscos deve ocorrer
Quantitativa probabilidade pontuação alta, análise e avaliação
na reunião de Sprint
de ocorrência e média e baixa. de risco avalia e
de Riscos
Planning 1,
as
Nenhuma técnica quantifica a
auxiliando na
conseqüências de análise é
probabilidade e a
priorização e seleção
dos riscos e
discutida.
influência dos
dos itens de backlog
estima as suas
eventos
que serão
implicações nos
considerados
desenvolvidos na
objetivos do
causadores de
próxima Sprint.
projeto.
risco e a interação
entre os riscos.
Identificação
de Riscos
Determina os Identificado pela
riscos que
Gerência de
podem afetar o componente de
projeto e
risco.
documenta suas
características.
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
PMI
PRINCE2
P2M
SCRUM
APM
Discute o
Planejamento de Os planos de ação A equipe inteira
Planejamento Desenvolve
medidas contra
correspondem às
participa no
de Resposta a procedimentos balanço do
e técnicas para impacto do risco riscos que inclui ações que devem ser desenvolvimento de
Riscos
aumentar as
de ocorrência
ainda a medição tomadas para
planos de respostas e
oportunidades e contra o impacto dos riscos e a
responder aos riscos, ações para reduzir as
reduzir as
da adoção das
execução do plano visando reduzir o
ameaças.
ameaças aos
medidas de risco de resposta a eles. fator de exposição
objetivos do
possível.
(probabilidade e/ou
projeto.
Abrange a cessão
impactos).
de ações de risco
como parte da
gestão de riscos.
DSDM
Está preocupada
em planejar e
implementar
respostas aos
riscos
documentados.
Coberto nas
Controla e
Os riscos são
Os riscos são
É realizado um
Monitoração Implementa
etapas do
acompanha desde monitorados
monitorados e as
acompanhamento
e Controle de planos de
respostas aos gerenciamento de a implementação diariamente, nas
estratégias de
periódico da
Riscos
riscos, monitora riscos,
de identificação de reuniões diárias e controle são
implementação das
riscos residuais, planejamento,
riscos à execução também durante os discutidas no final de respostas aos
identifica novos recursos,
de medidas
planejamentos da
cada iteração do ciclo riscos e verificado
riscos, executa monitoramento e preventivas que Sprint, quando
de vida (Figura 7). Os o status do risco
planos de
controle.
devem ser feitas devem ser
riscos são
até o seu
redução de
repetidamente.
reavaliados em
monitorados
encerramento pelo
riscos e avalia
conjunto com os
diariamente através responsável de
seus efeitos
demais riscos
das reuniões diárias. cada risco.
através do ciclo
identificados. É
de vida de
importante observar
projeto.
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.
Comunicação É tratada na
área de
de Riscos
conhecimento
de
gerenciamento
das
comunicações
do projeto.
Acontece em
paralelo às
demais
atividades e serve
para estabelecer
uma
comunicação
formal durante o
gerenciamento de
riscos do projeto.
DSDM Version 4.2.
78
2.3
Modelos de gestão de riscos em projetos de desenvolvimento de software
Existem diversos modelos que abordam a gestão de riscos em projetos de
desenvolvimento de software. Esses modelos já foram estudados por diversos autores e,
portanto não iremos repetir estudos exaustivos já realizados. O objetivo aqui é mostrar, doze
destes modelos e, como cada um deles aborda o gerenciamento de riscos através de uma
comparação entre os mesmos (Tabela 12).
Tabela 12: Modelos/Abordagem de gestão de riscos em projetos de desenvolvimento de
software
MODELO /
ABORDAGEM
AUTOR
SEI
SEI (2004), Oliveira G. (2006)
MSF
Microsoft Solutions Framework (2004), Oliveira G.
(2006)
BOEHM
Boehm (1991), Oliveira G. (2006)
RISKIT
Kontio (1996), Oliveira G. (2006)
ODYSSEY
Braga (1999), Oliveira G. (2006)
A-RISK
Machado (2002), Oliveira G. (2006)
GERIS
Oliveira S. (2005), Oliveira G. (2006)
CMM
Paulk (1993), Gusmão; Moura (2004)
CMMI
SEI (2001), Gusmão; Moura (2004)
ISO 9000-3
NBR ISO 9001 (2000), Gusmão; Moura (2004)
ISO 12207 / ISO 15504
ISO/IEC 15504 (1999), NBR ISO 12207(1998),
Gusmão; Moura (2004)
Fonte: Oliveira (2006) e Gusmão; Moura (2004)
Será apresentado aqui o resultado de estudos realizados por estes autores através da
comparação entre os modelos citados tendo como referência as atividades/formato descritas
pelo PMI (2008). Verificou-se que existem diferenças entre as abordagens dos modelos em
relação à nomenclatura utilizada na descrição das atividades, em relação à subdivisão dessas
atividades em tarefas e na definição do escopo de algumas atividades (OLIVEIRA G., 2006).
Percebe-se, segundo Oliveira G. (2006), que a aplicação da gestão de riscos, possui
diversos formatos, e em grande parte da bibliografia pesquisada, verifica-se que existe um
79
eixo central, na qual estão incluídas as atividades de planejamento, identificação, análise
quantitativa e qualitativa, planejamento de resposta a riscos, monitoração e controle.
Será apresentado, a seguir, o comparativo dos modelos/abordagens de gestão de riscos
elaborados por Gusmão e Moura (2004) (Tabela 13) e Oliveira G. (2006) (Tabela 14 e 15).
Ressalta-se que os campos hachurados, nessas tabelas, indicam que a atividade não é
contemplada para o modelo de gestão de riscos para desenvolvimento de software em
questão.
Tabela 13: Comparativo das abordagens de Gerenciamento de riscos para
desenvolvimento de software por Gusmão e Moura (2004)
ATIVIDADES DA
GERÊNCIA DE
RISCO
CMM
CMMI
Planejamento
Não existe menção a
esta atividade.
Identificação de
Riscos
Identificação dos riscos. Identificar riscos.
ISO 9000-3
Determinar as origens e Planejar o
as categorias de riscos. desenvolvimento do
Definir parâmetros.
projeto.
Estabelecer estratégia.
ISO 12207 /
ISO 15504
Definição do escopo da
gerência de risco.
Identificar riscos.
Identificar riscos.
Análise Qualitativa Análise dos riscos com
a priorização dos
de Riscos
mesmos de acordo com
Análise
o impacto.
Quantitativa de
Riscos
Planejamento
de Definição dos planos de
Resposta a Riscos contingências para os
riscos identificados que
não tenham condições
de serem eliminados.
Priorizar, estimar e
classificar riscos.
Avaliar e classificar
cada risco.
Analisar problemas
potenciais.
Analisar e priorizar riscos.
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
Aprendizagem de
Riscos
Comunicação implícita. Comunicação implícita. Comunicação implícita. Comunicação implícita.
80
desenvolvimento de software por Oliveira G. (2006)
ATIVIDADES DA
GERÊNCIA DE
RISCO
SEI
MSF
Planejamento
Identifica, analisa e planeja
resposta a riscos.
Identificação de
Riscos
Localiza riscos antes que eles se
tornem problemas.
Análise Qualitativa
de Riscos
Análise
Quantitativa de
Riscos
BOEHM
Identifica riscos que possam Identifica riscos de acordo com a
afetar o projeto ou limitar seu sua classificação.
sucesso.
Classifica riscos através de
Determina prioridades para a
categorias e parâmetros definidos. ação, gerando uma ordem na
lista mestre de riscos.
Analisa riscos com utilização de
intervalos de prioridade.
Analisa a probabilidade de
ocorrência de cada risco e suas
implicações para os objetivos do
projeto.
Planejamento
de Converte as informações de risco Traduz a lista de prioridade de Define objetivo, ações,
cronograma, responsabilidades,
Resposta a Riscos para decisões e ações.
riscos em planos de ação.
como as ações devem ser
desenvolvidas e recursos
alocados.
Monitora estado de riscos para
Monitoração e
Controle de Riscos tomar devidas ações e corrige
desvios das ações de risco.
Comunicação de
Riscos
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.
Fornece um feedback das
atividades de risco ativas.
Aprendizagem de
Riscos
Aprende as lições obtidas.
desenvolvimento de software por Oliveira G. (2006)
ATIVIDADES DA
GERÊNCIA DE
RISCO
Planejamento
RISKIT
Revisar e definir os
objetivos, expectativas e
diretrizes.
ODYSSEY
A-RISK
GERIS
Determinar o método Definir qual processo será
para a identificação e adotado para a GRPS
cálculo de riscos e os (padrão ou normal). Projetos
impactos para os fatores de pequeno porte podem
de risco. Definir quando adotar um processo padrão
composto apenas pelas
o processo A-Risk
etapas de identificação,
deverá ser utilizado.
análise e monitoração de
riscos.
81
desenvolvimento de software por Oliveira G. (2006) (Cont.)
ATIVIDADES DA
GERÊNCIA DE
RISCO
RISKIT
ODYSSEY
Identificação de
Riscos
Identificar riscos
potenciais do projeto.
Análise
Qualitativa de
Riscos
Priorizar e quantificar os Documentar padrões de
riscos através de um
risco a fim de conduzir a
formalismo gráfico.
informação para a
Agrupar riscos similares, identificação qualitativa de
que geram o mesmo
risco e para as estratégias da
evento, através do uso de resolução do impacto.
cenários.
Desenvolver um plano de Descrever textualmente o
ações selecionadas.
plano de contenção e seus
efeitos, pelas condições de
sua aplicação, e por um
modelo dinâmico de seu
impacto.
Controlar riscos com o
Monitoração e
Controle de Riscos objetivo de avaliar os
resultados esperados.
Monitorar a evolução do
projeto após a execução do
plano de contenção.
Identificar os riscos,
Utilizar informações
através da influência dos históricas de projetos
fatores de risco. Para
anteriores para facilitar a
cada fator de influência identificação de riscos e
“razoável ou muita”.
gerar checklist.
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).
Desenvolver um conjunto de
ações necessárias para
minimizar as conseqüências
do risco.
Manter a rastreabilidade dos
riscos identificados e
priorizados, monitorar riscos
residuais e identificar novos
riscos.
Comunicar o status dos riscos
às pessoas interessadas,
identificadas na etapa de
planejamento.
Comunicação de
Riscos
Aprendizagem de
Riscos
GERIS
Utilizar modelos dinâmicos Analisar os riscos
agregados do processo de através de um conjunto
desenvolvimento,
de fatores de riscos
permitindo que o gerente de relacionado ao tempo
projeto avalie
em que eles são
quantitativamente os riscos identificados. Agrupar
identificados. Agrupar
todos os fatores de risco
riscos similares através do
uso de um padrão de risco. que possuem o mesmo
grau de influência ou
peso dentro de um único
cenário.
Análise
Quantitativa de
Riscos
Planejamento de
Resposta a Riscos
Identificar os riscos mais
comuns que ocorrem nos
projetos desenvolvidos.
A-RISK
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, ARISK 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, ARISK e GERIS) e a outra metade faz as duas análises em conjunto (CMM, CMMI, ISO 90003, 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
Elemento I. Requisitos
Atributo a.
Estabilidade
b.
Completeza
c.
Clareza
d.
Validade
e.
Viabilidade
f.
Precedente
g.
Escala
I.
a.
b.
c.
d.
e.
AMBIENTE DE
DESENVOLVIMENTO12
Processo de desenvolvimento
Formalidade
Adequação
Controle do processo
Familiaridade
Controle do produto
Elemento II. Projeto
II. Desenvolvimento de sistema
Atributo a.
Funcionalidade
a.
Capacidade
b.
Dificuldade
b.
Adequação
c.
Interface
c.
Usabilidade
d.
Desempenho
d.
Familiaridade
e.
Testabilidade
e.
Confiabilidade
f.
Restrições de hardware
f.
Suporte ao sistema
g.
Software não desenvolvido g.
Entregabilidade
Fonte: adaptado de CARR et al. (1993); MACHADO (2002, p.46)
11
I.
a.
b.
c.
d.
RESTRIÇÕES DE
PROGRAMA13
Recursos
Cronograma
Equipe
Orçamento
Facilidade
II.
a.
b.
c.
Contrato
Tipo de Contrato
Restrições
Dependências
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
III. Processo de Gerência
a.
Planejamento
b.
Organização do Projeto
c.
Experiência Gerencial
d.
Interface de Projeto
Elemento III. Codificação e Teste Unitário
Atributo a.
Viabilidade
b.
Teste Unitário
c.
Codificação e
Implementação
Elemento IV. Teste e Integração
Atributo a.
Ambiente
b.
Produto
c.
Sistema
III.
a.
b.
c.
d.
e.
f.
g.
RESTRIÇÕES DE
PROGRAMA16
Interfaces de Projeto
Cliente
Contratos Associados
Subcontratados
Principal Contratador
Gerente Corporativo
Vendedores
Políticos
IV. Métodos Gerenciais
a.
Monitoramento
b.
Gerência de Pessoal
c.
Garantia da Qualidade
d.
Gerência de Configuração
V. Ambiente de Trabalho
a.
Atitude para a qualidade
b.
Cooperação
c.
Comunicação
d.
Moral
Elemento V. Especialidade de Engenharia
a.
Manutenibilidade
b.
Confiabilidade
c.
Segurança
d.
Proteção
e.
Fatores Humanos
f.
Especificações
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.
Fornecedor selecionado fará o tempo Portanto, temos a falta de Isso pode levar a custos sendo
de trabalho/materiais X a oferta fixa experiência em registros precisos cobrados incorretamente.
usual.
para este tipo de contrato.
Cliente
Contém a lista de riscos relacionados a cliente.
1-01
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
2-01
FATOR DE RISCO INTEGRADO
Requisitos instáveis
2-02
2-03
Requisitos incompletos.
Requisitos não claros (ambíguos / imprecisos).
2-04
Requisitos mal entendidos (não refletem as
expectativas do cliente).
2-05
Adição de mais funcionalidades
especificado / dar extras ao cliente.
2-06
Requisitos de desempenho não atendidos.
2-07
Ex. Baixo desempenho.
Alto nível de complexibilidade técnica.
2-08
que
o
Desenvolvimento de interface do usuário
inadequada.
Fonte: Webster (2005, p. 118).
AUTORES
(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)
(KEIL et al., 1998); (CARR et al., 1993)
(MACHADO, 2002); (MIZUNO; KIKUNO, 2000);
(CARR et al., 1993); (JALOTE 2000, p.167-169)
(KEIL et al., 1998); (MACHADO, 2002); (ADDISON;
VALLABH, 2002); (MIZUNO; KIKUNO, 2000);
(CARR et al., 1993); (FONTOURA; PRICE, 2004)
(ADLER et al., 1998); (ADDISON; VALLABH, 2002);
(MCMANUS, 2004, p.18-19); (FONTOURA; PRICE,
2004)
(SOEIRO, 1999); (DEMARCO; LISTER, 2003);
(JALOTE 2000, p.167-169)
(HOUSTON et al., 2001); (MACHADO, 2002); (CARR
et al., 1993)
(ADLER et al., 1998); (SOEIRO, 1999); (MCMANUS,
2004, p.18-19)
91
Tabela 18: Fatores de risco de desenvolvimento de software integrados (Cont.)
ID
2-09
Problemas de desempenho de tempo real (há
tempos de respostas restritos).
2-10
Restrições referentes ao hardware designado.
2-11
2-12
Ex.: capacidade de memória e tempo de
resposta real, acesso à base de dados e
insuficiência de hardware.
Tecnologia nova / imatura (uso de novas
tecnologias).
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.
2-13
Falta de um acordo interativo entre os clientes
e os desenvolvedores relativo às especificações
dos requisitos.
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.
2-15
Modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o
processo de desenvolvimento.
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.
2-17
Controle do produto inadequado. Ex.: o
produto final não corresponde às expectativas
do cliente.
2-18
Documentação / papelada excessiva.
2-19
Capacidade
insuficiente
do
sistema
desenvolvido. Ex.: Falta de estações de
trabalho, espaço de armazenamento no banco
de dados insuficiente.
2-20
Pouca confiança no desenvolvimento do
sistema devido à indisponibilidade / erro / mal
funcionamento dos componentes.
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.
AUTORES
(ADLER et al., 1998); (MCMANUS, 2004, p.18-19);
(CARR et al., 1993)
(ADLER et al., 1998); (MCMANUS, 2004, p.18-19);
(CARR et al., 1993)
(SOEIRO, 1999); (KEIL et al., 1998); (MACHADO,
2002); (ADDISON; VALLABH, 2002); (JALOTE 2000,
p.167-169); (FONTOURA; PRICE, 2004);
(LEOPOLDINO, 2004)
(MCMANUS, 2004, p.18-19); (CARR et al., 1993)
(MIZUNO; KIKUNO, 2000); (CARR et al., 1993)
(MIZUNO; KIKUNO, 2000); (DEMARCO; LISTER,
2003); (CARR et al., 1993);
(FARIAS, 2002)
(MACHADO, 2002); (CARR et al., 1993)
(MIZUNO; KIKUNO, 2000); (CARR et al., 1993);
(LEOPOLDINO, 2004)
(CARR et al., 1993); (FARIAS, 2002)
(SOEIRO, 1999); (HOUSTON et al., 2001)
(SOMERVILLE, 2003, p.74); (CARR et al., 1993)
(ADLER et al., 1998); (HOUSTON et al., 2001);
(MCMANUS, 2004, p.18-19); (CARR et al., 1993)
92
ID
2-22
2-23
2-24
2-25
2-26
2-27
2-28
2-29
2-30
2-31
2-32
2-33
2-34
2-35
2-36
2-37
2-38
2-39
2-40
Planejamento
inapropriado,
incluindo
construção e atualização do plano de
contingência.
Papéis e responsabilidades de relacionamentos
mal definidos ou mal entendidos.
Gerentes do desenvolvimento do software
inexperientes ou ineficientes.
Fraca interação (comunicação) do gerente com
todos os envolvidos do projeto.
Falhas em gerenciar as expectativas do usuário
final.
Ausência de um líder.
Falta de metodologia efetiva de gerenciamento
de projetos.
Fraco monitoramento do progresso das
atividades relacionadas ao projeto. Ex.:
acompanhamento do relatório de status e
manutenção de métricas progressivas.
Treinamento inadequado ou indisponível.
Falta de procedimentos, programas adequados
e recursos para assegurar a garantia da
qualidade.
Gerência de Configuração inadequada.
Mudanças contínuas no objetivo e escopo do
projeto.
Erro ao estimar (tempo, custo e esforço).
Métricas inadequadas / inexatas.
Falta espírito de equipe. Os conflitos requerem
intervenção da gerência.
Pobre comunicação devido à falta de
conhecimento da missão, metas do projeto e
informações técnicas entre pares e gerentes.
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.
Falta de maturidade / instabilidade
organizacional.
Baixa produtividade da equipe.
AUTORES
(SOEIRO, 1999); (MACHADO, 2002); (MIZUNO;
KIKUNO, 2000); (SCHWALBE, 2002, p.311); (CARR
et al., 1993)
(MIZUNO; KIKUNO, 2000); (SCHWALBE, 2002,
p.311); (CARR et al., 1993)
(MACHADO, 2002); (CARR et al., 1993);
(LEOPOLDINO, 2004)
(KEIL et al., 1998); (ADDISON; VALLABH, 2002);
(LEOPOLDINO, 2004)
(MACHADO, 2002); (SCHWALBE, 2002, p.311)
(MACHADO, 2002); (ADDISON; VALLABH, 2002);
(FONTOURA; PRICE, 2004); (LEOPOLDINO, 2004)
(MACHADO, 2002); (MIZUNO; KIKUNO, 2000);
(CARR et al., 1993)
(SOEIRO, 1999); (MACHADO, 2002); (SOMERVILLE,
2003, p.74); (CARR et al., 1993); (PRESSMAN, 2002,
p.139-156)
(SCHWALBE, 2002, p.311); (CARR et al., 1993)
(SOEIRO, 1999); (HOUSTON
et al., 2001);
(KEIL et al., 1998); (MACHADO, 2002);
(LEOPOLDINO, 2004)
(SOEIRO, 1999); (HOUSTON et al., 2001); (MIZUNO;
KIKUNO, 2000); (SOMERVILLE, 2003, p.74);
(SCHWALBE, 2002, p.311); (PRESSMAN, 2002, p.139156); (LEOPOLDINO, 2004)
(SOEIRO, 1999); (HOUSTON et al., 2001)
(MACHADO, 2002); (CARR et al., 1993); (JALOTE
2000, p.167-169); (FARIAS, 2002)
(MACHADO, 2002); (MCMANUS, 2004, p.18-19);
(CARR et al., 1993)
(HOUSTON et al., 2001); (MACHADO, 2002);
(MIZUNO; KIKUNO, 2000); (CARR et al., 1993);
(LEOPOLDINO, 2004); (FARIAS, 2002)
(HOUSTON et al., 2001); (MACHADO, 2002)
(SCHWALBE, 2002, p.311); (FARIAS, 2002)
93
ID
2-41
Cronograma irreal ou inadequado baseado nos
eventos internos e externos do sistema.
2-42
2-43
Pressão excessiva de prazo.
Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta de habilidade, falta
de pessoal e indisponibilidade de pessoas
chaves.
2-44
Orçamento insuficiente ou instável baseado
nos eventos internos e externos do sistema.
2-45
Instabilidade (rotatividade) e falta
continuidade das pessoas nos projetos.
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.
Problemas
relacionados
aos
contratos
associados.
Qualquer
problema
associado
a
subcontratação.
2-47
2-48
2-49
2-50
2-51
de
Fatores políticos (companhia, clientes,
contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do
projeto.
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.
Falta de comprometimento da gerência sênior
AUTORES
(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)
(HOUSTON et al., 2001); (MACHADO, 2002)
(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.1819); (CARR et al., 1993); (JALOTE 2000, p.167-169);
(PRESSMAN, 2002, p.139-156); (FONTOURA; PRICE,
2004); (LEOPOLDINO, 2004)
(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)
(DEMARCO; LISTER, 2003); (PRESSMAN, 2002,
p.139-156); (LEOPOLDINO, 2004); (FARIAS, 2002)
(HOUSTON
et al., 2001); (MACHADO, 2002);
(SOMERVILLE, 2003, p.74); (CARR et al., 1993);
(LEOPOLDINO, 2004); (FARIAS, 2002)
(SOEIRO, 1999); (SCHWALBE, 2002, p.311); (CARR
et al., 1993)
(SOEIRO, 1999); (ADDISON; VALLABH, 2002);
(CARR et al., 1993); (FONTOURA; PRICE, 2004)
(MACHADO, 2002); (CARR et al., 1993); (JALOTE
2000, p.167-169); (FARIAS, 2002)
(SOEIRO, 1999); (KEIL et al., 1998); (ADDISON;
VALLABH, 2002); (PRESSMAN, 2002, p.139-156);
(KEIL et al., 1998); (HOUSTON et al., 2001);
(ADDISON; VALLABH, 2002); (CARR et al., 1993);
94
2.4.4 Brainstorming
Muitas atividades em grupo podem ser organizadas para identificar os riscos do projeto..
O brainstorming é uma técnica usada para gerar e coletar múltiplas idéias, neste contexto. O
objetivo do brainstorming é obter uma lista dos riscos do projeto. A equipe do projeto
normalmente realiza um brainstorming, em geral com um conjunto multidisciplinar de
especialistas externos à equipe. As idéias sobre o risco do projeto são geradas sob a liderança
de um facilitador, seja em uma sessão tradicional de brainstorming, de forma livre (com
idéias fornecidas pelos participantes), ou estruturada (usando técnicas de entrevista em grupo,
como a técnica de grupos nominais). Os riscos são, então, identificados e categorizados e suas
definições detalhadas. (PMI, 2008).
Segundo Webster (2005) a ferramenta brainstorming é a terceira ferramenta mais citada
pelos autores pesquisados em sua dissertação, para o processo de identificação de riscos. O
brainstorming consiste em realizar uma reunião com a equipe de projeto e/ou especialistas,
onde os envolvidos geram idéias sobre os riscos do projeto, sendo coordenados por um
facilitador. As fontes de riscos são identificadas de maneira geral e apresentadas para análise
de todos, durante a sessão. Os riscos são, então, classificados de acordo com o seu tipo e suas
definições são refinadas (MCMANUS, 2004 e PMI, 2002 apud WEBSTER, 2005).
2.4.5 Análise de Informações históricas
A análise de informações históricas de projetos anteriores pode ser utilizada como
ferramenta para identificação de riscos. Na pesquisa realizada por Webster (2005) essa
ferramenta foi citada por cinco autores como ferramenta para tal processo.
Segundo PMI (2008) as informações históricas e as lições aprendidas são transferidas à
base de conhecimento para o uso em projetos ou fases futuras, fornecendo um depósito de
informações sobre os resultados de projetos anteriores. Isso pode incluir informações a
respeito de questões e riscos, assim como técnicas que funcionaram bem e que podem ser
aplicadas em projetos futuros.
Webster (2005) cita, ainda, outras fontes de informações históricas que devem ser
analisadas: (a) arquivos de projeto: uma ou mais organizações envolvidas no projeto podem
manter registros dos resultados dos projetos anteriores que podem ser utilizados na
identificação de riscos. Esses registros podem incluir os relatórios de acompanhamento do
95
projeto ou os planos de respostas aos riscos. Eles podem também incluir lições aprendidas que
descrevem os problemas e sua resolução ou podem estar disponíveis através da experiência
dos interessados no projeto ou de outras pessoas da organização; (b) informações publicadas:
em banco de dados comerciais, estudos acadêmicos, benchmarking e outros estudos
publicados podem estar disponíveis para as várias áreas de aplicação.
2.4.6 Comparação análoga
É um método de identificação de riscos que tem como premissa a idéia de que nenhum
projeto de sistema representa um projeto totalmente novo, independente do quão avançado ou
único ele seja. O método parte do pressuposto da identificação de projetos similares,
permitindo que os dados dos mesmos possam ser utilizados pelo projeto em desenvolvimento
para sua revisão ou para sua própria elaboração (GUSMÃO; MOURA, 2005; MACHADO,
2002).
A identificação de projetos similares envolve a determinação de características comuns
aos projetos, por exemplo, tecnologia, funcionalidade, estratégia de contrato e processo de
desenvolvimento (MACHADO, 2002 apud PRITCHARD, 1997).
A comparação análoga é mais simplificada de ser utilizada. Uma preocupação na
utilização da comparação análoga é a que ela depende da análise de dados históricos, da sua
interpretação, da precisão e do nível de detalhamento descrito.
O método que trabalha com essa abordagem é o do MITRE, através da ferramenta
RAMP - Risk Assessment and Management Program (GARVEY et al., 1997 apud GUSMÃO;
MOURA, 2005 e GARVEY et al., 1997 apud MACHADO, 2002), como também a
ferramenta mPRIME através do reuso baseado em repositório de projetos passados
(GUSMÃO et al 2005).
2.4.7 Análise de premissas
As premissas são fatores considerados como verdadeiros, sem prova ou demonstração,
para fins de planejamento. Uma das causas potenciais de risco do projeto e que devem ser
avaliadas são as incertezas nas premissas do projeto. Todos os projetos e todos os riscos
identificados no projeto são concebidos e desenvolvidos com base em um conjunto de
premissas, hipóteses ou cenários.
96
A análise das premissas é uma técnica que explora a validade e completude das
premissas em relação ao projeto. Esta técnica identifica riscos decorrentes do caráter
incompleto, inconsistente, inexato ou instável das premissas (PMI, 2008).
Na análise de premissas cada projeto é concebido e desenvolvido com base em um
conjunto de hipóteses ou premissas. Esta é uma técnica que explora as incertezas do projeto
pela existência de algumas premissas que foram assumidas e podem não ser verdadeiras.
Essas premissas imprecisas, inconsistentes ou incompletas deverão ser identificadas e
descritas para que posteriormente possam ser avaliadas (PMI, 2000 apud MACHADO, 2002).
2.4.8 Entrevista com especialistas
A entrevista com especialistas é mais um método de coleta de informações utilizado
para o levantamento e identificação de riscos. Primeiramente, identificam-se os especialistas,
cria-se uma agenda de reunião e desenvolve-se o roteiro de análise de riscos.
A aplicação do roteiro de análise de riscos pode ser desenvolvida através de entrevistas
individuais ou da formação de grupos focais (GUSMÃO; MOURA, 2005 apud Victoria et al.
2000). A vantagem deste método é a obtenção de diversas visões de riscos, dentro do contexto
escolhido, uma vez que estão tratando com profissionais de perfis e experiências distintas.
As vantagens desse método é a obtenção de diversas visões sobre os riscos do projeto,
pois os entrevistados podem ter perfis e experiências diferentes, contribuindo na identificação
de diversos aspectos relacionados aos riscos, e à facilidade para a sua aplicação (GUSMÃO;
MOURA, 2005, MACHADO, 2002).
Gusmão, Moura (2005) e Machado (2002) apresentam como desvantagens a criação do
roteiro de análise de riscos, não limitando as respostas dos entrevistados, e a forte
dependência existente entre entrevistado e entrevistador.
Segundo Webster (2005) em seu estudo, a utilização de entrevistas como ferramenta
para a identificação de riscos foi citada em seis referências dos dezesseis autores pesquisados.
Esse método consiste em entrevistar experientes gerentes de projetos ou especialistas no
assunto. O responsável pela identificação de riscos no projeto escolhe as pessoas apropriadas,
explica-lhes o projeto e fornece as informações, tais como: documentação do projeto e lista de
premissas. Os entrevistados identificam os riscos possíveis, com base em sua experiência, nas
informações sobre o projeto e em outras fontes que julgarem úteis (PMI, 2002 e
SOMMERVILLE, 2003 apud WEBSTER, 2005).
97
2.4.9 Análise da causa-raiz
A análise da causa-raiz é uma técnica específica para identificar um problema, descobrir
as causas subjacentes que levaram a ele e desenvolver ações preventivas. É usada para
determinar a razão subjacente básica que causa uma variação, um defeito ou um risco. Uma
causa-raiz pode provocar mais de uma variação, defeito ou risco no projeto (PMI, 2008).
Entre os métodos que empregam a análise da causa-raiz estão o Diagrama de Causa e
Efeito, também conhecido como Ishikawa ou Espinha de Peixe, e a técnica dos 6 W´s (Who,
Why, What, Whichway, Wherewithal, When) (GUSMÃO; MOURA 2005).
O Diagrama de Causa e Efeito foi desenvolvido por Kaoru Ishikawa, da Universidade
de Tóquio, em 1943, onde a utilizou para explicar para o grupo de engenheiros da Kawasaki
Steel Works como vários fatores podem ser ordenados e relacionados. Porém, somente em
1962, J. M. Juran o "batizou" como sendo diagrama de Ishikawa (PORTAL O GERENTE,
2006, 2010).
Os diagramas de causa e efeito ilustram como diversos fatores podem estar ligados a
problemas ou efeitos potenciais. As Figura 17 e Figura 18 são exemplos de diagramas de
causa e efeito. Uma possível causa-raiz pode ser revelada ao continuar a perguntar “por quê?”
ou “como?” seguindo uma das linhas. Os diagramas “Por quê-Por quê” e “Como-Como”
podem ser usados na análise de causa e efeito (PMI, 2008).
Tempo
Máquina
Método
Material
Maior
Def eito
Energia
Medição
Pessoal
Causas Potenciais
Ambiente
Ef eito
Figura 17: Fontes clássicas de problemas a considerar. Fonte: PMI (2008, p.176)
98
Tempo
Máquina
Método
Material
Erro na reserva
do Hotel
Sem filtro nas janelas
Ruídos e distrações
Sobrecarga
de brilho
Iluminação
Layout do
Lobby
Política
Sonorização insuficiente
Requisição formal necessária
Energia
Medição
Pessoal
Ambiente
Causas Potenciais
Ef eito
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
( Padrões de Conhecimento, Normas e Métodos )
Gerência de Projetos
“Tradicional”
Método Ágil de Gerenciamento
de Projetos
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 RISCOS
Mé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)
Integração semântica
Fatores de risco para
desenvolvimento de
software
Fatores de Riscos Identificados e Classificados
Pela influência
interna e externa
Por Fases do
Projeto
Por Categorias
Pelo Grau de
Exposição
(Priorização)
Figura 23: Método adotado para identificação e classificação dos fatores de riscos.
Fonte: Elaboração do autor.
INVESTIGAÇÃO – GERÊNCIA DE PROJETOS
Ger. de Projetos
“Tradicional”
Metod
A
...
Metod
N
Gerência de Riscos
“Tradicional”
Ger. de Projetos
“Método Ágil”
Metod
.A
...
Metod
.N
Gerência de Riscos
“Ágil”
Modelos de
Gestão de
Riscos em
Projetos de
Desenvolvimento de
Software
Métodos
para
Identificação
de Riscos
Proposta de um Método Ágil para Identificação de
Riscos em Projetos de TI
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
Instrumento de Coleta de Dados
- Aplicação do questionário piloto
Caracterização da Amostra e
Procedimento de Coleta de Dados
- Seleção das empresas e pessoas chaves
a serem pesquisadas
- Ajuste do questionário
- Entrevista com apoio do questionário
- Definição do questionário
Análise das Informações
- 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
Forma de Tabulação
- Tabulação e análise dos dados
- Avaliação dos resultados
- Análise da qualidade das informações
obtidas
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
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á
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 2Fundamentaçã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
18
sistema
de
19
informação e não para desenvolvimento de software . 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
Empresas do Setor PRIVADO
Empresa c/
atuação
Internacional
Empresa c/
abrangência
no território
Nacional
Empresa
Líder de
produto
Nacional
Empresas do Setor PÚBLICO
Empresa
Líder de
produto no
Centro-Oeste
Empresa
referência no
Governo
Estadual
Empresa
referência no
Governo
Municipal
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
FAIXA
PONTUAÇÃO
(Alternativas de resposta no roteiro de
análise de riscos)
(Probabilidade de ocorrência)
atribuída a cada faixa
> 70%
0,9
50% a 70%
0,7
Moderada
30% a 49,9%
0,5
Baixa
10% a 29,9%
0,3
< 10%
0,1
Muito Alta
Alta
Muito Baixa
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
ÁREAS DO PROJETO
Custo
Prazo
Qualidade
Muito Baixo
Baixo
Moderado
Alto
Muito Alto
0,05
0,1
0,2
0,4
0,8
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%
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%
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
RESPOSTAS DAS EMPRESAS PESQUISADAS
QUESTÕES
A
B
C
D
E
F
Nome do Entrevistado
E-mail
Sexo
Faixa Etária (em anos)
Cargo Atual
F
Acima de 40
Analista
M
Acima de 40
Gerente
M
30 a 35
Analista
M
30 a 35
Gerente
M
30 a 35
Gerente
Formação/Certificações
em gerência de projetos
PósGraduaçã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ósGraduação
em GP
Sim
Sim
M
Acima de 40
Coordenador
do PMO
Ciências da
computação e
mestrado em
gestão do
conhecimento
Sim
Mais de 10
3a5
Mais de 10
5 a 10
5 a 10
5 a 10
12 a 18
12 a 18
6 a 12
5 a 10
15 a 20
Menos de 5
Expectativa
quanto
a
Sim
Sim
Sim
receber
resultados
da
pesquisa
Tempo de experiência
Mais de 10
Mais de 10
Mais de 10
profissional no ramo da
indústria de software (em
anos)
Tempo de experiência
Mais de 10
5 a 10
5 a 10
profissional como gerente
de projetos (em anos)
Tempo médio de duração
6 a 12
12 a 18
12 a 18
dos projetos que gerenciou
(em meses)
Tamanho
médio
das
10 a 15
10 a 15
5 a 10
equipes
de
projeto
gerenciadas
pelo
entrevistado
(qtde
de
pessoas)
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
A
B
C
D
E
F
Tecnologia da
informação
Desenvolvimento
de software
Tecnologia
da
informação
Estados de atuação da
empresa
Goiás
AL, AP, BA, CE,
DF, GO, RJ, SC
e SP
Tecnologia
da
informação e
Comunicação
Goiás
Software
para
soluções de
RH
GO, MG,
PR, PE, RJ
e SP
Países de atuação da
empresa
Brasil
Brasil,
Argentina, EUA,
Japão e China
Acima de 50,0
DF, GO,
MG, MS,
MT, RS, SC
e SP
Brasil
Desenvolvimento
de Softwares
Contábeis e
Administrativos
BA, DF, GO,
MA, MG, MS,
MT, PA, PR, SP
e TO
Brasil
10,0 a 50,0
10,0 a 50,0
10,0 a 50,0
De 100 a
249
Acima de
10
De 100 a 249
Acima de
249
Acima de
10
Acima de
50
De 20 a 50
Acima de
50
Mais de 05
05
04
Mais de 05
04
02
Baseado em
uma
metodologia
Baseado em uma
metodologia
Baseado em
uma
metodologia
Razão Social
Ramo de Atividade
Brasil
Faturamento médio
10,0 a 50,0
10,0 a 50,0
anual (em milhões de
reais)
Número
de De 100 a 249
Acima de 249
De 100 a 249
funcionários
Número de gerente Acima de 10
Acima de 10
Acima de 10
de projetos existente
na empresa
Número
de
De 20 a 50
Acima de 50
Acima de 50
desenvolvedores de
software
Número de projetos
04
02
04
de
software
que
contaram com a
participação
do
entrevistado em 2010
Número de projetos
05
Mais de 05
01 (mudança
de
software
que
de governo)
contaram com a
participação
do
entrevistado
em
andamento em 2011
Abordagem adotada
Realiza
Baseado em uma
Baseado em
pela empresa para gerenciamento
metodologia
uma
gerenciamento
de
de projetos
metodologia
projetos
informalmente
De 1 a 4
Brasil
115
4.3
Processos/Abordagens adotadas para gerenciamento de riscos
Os representantes das empresas “A”, “C”, “D” e “E”, quando perguntados sobre a
utilização de métodos para identificação de riscos, responderam que não os utilizavam. Porém
quando foi mostrado a eles uma relação de vários métodos existentes, para identificação de
riscos, conforme apresentado no Capítulo 2, item 2.4 deste trabalho, onde estes métodos
foram citados por diversos autores, reconheceram que utilizavam vários deles.
Isso pode ter acontecido em decorrência do fato de que a maioria dessas empresas faz o
gerenciamento de riscos de seus projetos informalmente, ou seja, a empresa não possui um
método formal para gerenciamento de riscos. Isso vem ao encontro do Estudo de
Benchmarking em Gerenciamento de Projetos no Brasil, promovido pelo PMI-CHAPTERS
BRASILEIROS (2008), (ver Apêndice I, Tabela 30), onde se identifica apenas uma pequena
parcela das empresas no Brasil que realizam o gerenciamento de riscos baseado em uma
metodologia formal.
No atributo 3 (Tabela 24), todos os processos para gerenciamento de riscos informados
pelas empresas pesquisadas estão de acordo com os processos já citados no Capítulo 2, mais
especificamente no item 2.2-processos de gerenciamento de riscos e no item 2.3-modelos de
gestão de riscos em projetos de desenvolvimento de software. Acerca desses elementos
observa-se que algumas empresas utilizam mais processos de gerenciamento de riscos e
outras menos, mas sempre dentro dos processos já estudados. Tal fato pode ser decorrente da
metodologia adotada pela empresa/entrevistado, do tipo de projeto a ser desenvolvido, da
cultura da empresa etc.
No atributo 8 (Tabela 24), todas as empresas pesquisadas informaram que quando da
identificação/avaliação de riscos o fazem tanto para os riscos internos ao projeto quanto para
os riscos externos (ex: variação cambial). Webster (2005) já havia previsto estes tipos de
riscos (interno/externo) com relação a cronograma e orçamento, como pode ser verificado no
item 2.41 e 2.44 da Tabela 18.
Das empresas que possuem uma metodologia para gerenciamento de riscos, conforme
atributo 2 (Tabela 24), citado pelas empresas “B”, “D” e “F”, apenas a empresa “D” informou
que não identifica benefícios obtidos com o gerenciamento de riscos, conforme atributo
quatro (Tabela 24). Algumas respostas da empresa “D” apresentam uma contradição quando
ela informa que possui uma metodologia para gerenciamento de riscos (atributos 1 e 2 da
Tabela 24) porém, no atributo 6 desta mesma tabela o entrevistado informa que não utiliza
nenhum método para tal fim. Informa que apesar de possuir uma metodologia de
116
gerenciamento de riscos ela não é utilizada, conforme pode ser observado pela sua resposta
(ver Tabela 25).
pesquisadas
QUESTÕES
A
B
C
D
E
F
Abordagem
adotada pela
empresa para
gerenciamento
de riscos
Metodologia
utilizada para
gerenciamento
de riscos
Realiza
informalmente
Baseado em
uma
metodologia
Realiza
informalmente
Baseado em
uma
metodologia
Realiza
informalmente
Baseado em uma
metodologia
Processos
adotados para
gerenciar
riscos
Planejamento,
identificação e
planejamento
de resposta a
riscos
A
empresa
identifica
benefícios
obtidos com o
gerenciamento
de riscos?
Se sim, quais?
Sim
Sim
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.
-
Metodologia
desenvolvida
pelo escritório
de projetos da
empresa
Planejamento,
identificação,
planejamento
de resposta a
riscos,
monitoração e
controle,
comunicação
de riscos e
lições
aprendidas
-
Baseada no
CMMI nível
2 e PMBOK
-
Lições
aprendidas
Identificação,
análise
quantitativa,
análise
qualitativa e
planejamento
de resposta a
riscos
Planejamento,
identificação e
lições
aprendidas
Não
Não
Sim
-
-
A
empresa
Não
Sim
Não
Não
utiliza algum
método para
identificar
riscos?
Contingenciamento de
situações e
lições
aprendidas que
podem ser
evitadas em
novos projetos
Não
PMBOK e
conceitos/estratégia
s da Rita Mulcahy e
taxonomia de risco
da SEI.
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))
Sim
Redução de
problemas (prazo,
custo, qualidade e
escopo) ; redução
da insatisfação de
clientes.
Sim
117
pesquisadas (Cont.)
QUESTÕES
Se sim, quais?
Qual
a
abrangência
de
identificação
/avaliação de
riscos que a
empresa
adota?
A
B
C
D
E
F
Brainstorming,
lista de
verificação,
entrevista,
análise de
premissa e
comparação
análoga.
Riscos internos
e riscos externos
ao projeto
Brainstorming,
análise de
premissas,
comparação
análoga e
análise de
informações
históricas.
Riscos internos
e riscos externos
ao projeto
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.
Riscos internos
e riscos externos
ao projeto
Riscos internos
e riscos externos
ao projeto
Riscos internos
e riscos externos
ao projeto
Riscos internos
e riscos externos
ao projeto
4.4
Principais problemas / dificuldades para gerenciar riscos
Conforme matriz de casos e atributos das empresas pesquisadas (Tabela 25), observa-se
que os problemas e dificuldades citados para gerenciamento de riscos pelas empresas “A, C,
D e E” são decorrentes, em sua maioria, da falta de gerenciamento de riscos com base em uma
metodologia. Tal fato pode ser minimizado com a utilização do método apresentado pelo
autor neste trabalho, citado no Capítulo 5, onde é apresentada a proposta de um método ágil
para identificação de riscos em projetos de desenvolvimento de software. O método proposto
pelo autor é fruto do estudo de diversos métodos e padrões de conhecimento, conforme
apresentado no capitulo 2.
118
Tabela 25: Principais problemas/dificuldades para gerenciar riscos citados pelas empresas
pesquisadas
EMPRESAS
(Qual(is) o(s) principal(is) problema(s) / dificuldade(s) para gerenciar riscos?)
A
Identificação clara dos riscos que terão mais impacto no sucesso do projeto.
Os projetos podem estar funcionalmente bem elaborados, mas se os riscos não estiverem
claros previamente, a implantação do projeto pode estar comprometida.
B
Monitoramento dos riscos em equipes remotas (em várias cidades).
C
Ausência de um processo formal definido e de capacitação para os profissionais.
D
Gerenciamento e atualização das informações de riscos.
E
Falta de conhecimento ou uma metodologia adequada para o gerenciamento.
Dificuldade em identificar os riscos potenciais.
F
Institucionalização do processo de risco definido.
Falta de maturidade/cultura interna de análise de risco.
Falta de priorização de tempo no decorrer do projeto para gerenciar os riscos.
Lidar com a falta de cultura do cliente em investir em gerenciamento de riscos.
4.5
Análise dos fatores de riscos
A análise dos fatores de riscos foi feita quanto às fases do ciclo de vida do projeto,
quanto às categorias segundo o SEI (CARR et al., 1993) e quanto ao grau de exposição
(CAIXETA, 2006) de cada fator de risco.
Antes de iniciar a análise deste item, faz-se necessária uma breve explicação sobre ela,
como segue:

Com relação aos fatores de riscos, foram utilizados os 52 fatores definidos no
Apêndice III, Tabela 38.

Com relação às fases do ciclo de vida do projeto foram definidas conforme as
fases adotadas pelo PMBoK (PMI, 2008) e apresentadas no Capítulo 2. São elas:
iniciação, planejamento, execução, monitoramento e controle, encerramento e
avaliação pós-encerramento. Esta última fase “avaliação pós-encerramento” foi
incluída pela empresa “F”, sendo citada somente por ela, durante a pesquisa.
119

Com relação às categorias de riscos, foi adotada a taxonomia proposta pelo SEI
(CARR et al, 1993), conforme apresentado na Tabela 16 do item 2.4.1 do
Capítulo 2 deste trabalho.

Com relação ao grau de exposição de cada fator de risco, este foi feito pelo
cálculo da probabilidade de ocorrência do mesmo multiplicado pelo somatório
dos impactos em custo, prazo e qualidade. Classificando-se, em ordem
decrescente, o resultado deste cálculo, obtêm-se a priorização dos fatores de
riscos do mais importante para o menos importante, segundo a pesquisa de
campo e conforme apresentado item 3.2 do Capítulo 3 deste trabalho.
4.5.1 Quanto às fases do ciclo de vida do projeto
A análise dos fatores de riscos quanto às fases do ciclo de vida do projeto foi realizada
através de uma classificação destes fatores, segundo as respostas dadas pelas empresas
pesquisadas.
Para isso, as empresas informaram, conforme Parte IV do roteiro de análise de riscos,
em qual(ais) fase(s) cada fator de risco pode ocorrer.
No Apêndice V são apresentadas as tabelas contendo as respostas de cada empresa para
cada fator de risco de acordo com as fases do ciclo de vida do projeto.
Neste mesmo apêndice observa-se, pelas análises das tabelas apresentadas, que não há
um consenso entre as empresas na relação entre fatores de riscos e fases do ciclo de vida do
projeto, ou seja, com relação em qual fase do ciclo de vida do projeto um fator de risco poderá
aparecer.
4.5.2 Quanto às categorias de riscos
A classificação dos fatores de riscos para desenvolvimento de software está organizada
em categorias, conforme a taxonomia proposta pelo SEI (CARR et al., 1993) e distribuídas
em três níveis, conforme Tabela 16. São eles: classes, elementos e atributos. As classes estão
organizadas em elementos e estes estão divididos em atributos.
Com a intenção de simplificar a classificação dos fatores de riscos para
desenvolvimento de software, em categorias, adotou-se o primeiro nível da classificação
120
proposta pelo SEI, ou seja, os fatores de riscos foram classificados pelas classes conforme
Tabela 16.
Com relação a estas classes definidas pelo SEI, foi feita uma adequação nos nomes das
mesmas, com a intenção de facilitar o entendimento do leitor. Cabe lembrar aqui que esta
adequação nos nomes não afeta o significado proposto, pois o novo nome foi extraído da
definição original apresentada pelo SEI, ficando assim:
 Engenharia do produto (CARR, et al., 1993): compreende os fatores técnicos
relacionados ao produto e, portanto, passaremos a denominá-la de Riscos
Técnicos;
 Ambiente de desenvolvimento (CARR et al.,1993): compreende o processo
de desenvolvimento de sistemas, métodos de gestão e ambiente de trabalho e,
portanto, passaremos a denominá-la de Riscos Metodológicos, por se tratar dos
métodos relacionados ao ambiente de desenvolvimento de sistemas;
 Restrições de programa (CARR et al.,1993): compreende os fatores
contratuais, organizacionais e operacionais no qual o software é desenvolvido
e, portanto, passaremos a denominá-la de Riscos Organizacionais.
A seguir é apresentada, por meio da Tabela 26, a classificação dos fatores de riscos (ver
Tabela 38) quanto às categorias propostas pelo SEI (CARR et al.,1993).
quanto às categorias propostas pelo SEI
Categoria de
Risco
Técnico
Técnico
Técnico
Técnico
Técnico
Técnico
Técnico
Técnico
Técnico
Técnico
ID
01
02
03
04
05
06
07
08
09
10
Requisitos mal entendidos (não refletem as expectativas do cliente).
Adição de maior funcionalidades que o especificado / dar extras ao cliente.
Requisitos de desempenho não atendidos. Ex. Baixo desempenho.
Desenvolvimento de interface do usuário inadequada.
Problemas de desempenho de tempo real (há tempos de respostas restritos).
Restrições referentes ao hardware designado. Ex.: capacidade de memória e
tempo de resposta real, acesso à base de dados e insuficiência de hardware.
Técnico
11 Tecnologia nova / imatura (uso de novas tecnologias).
Técnico
12 Inadequada preparação e realização dos testes. Ex.: instalações inadequadas,
e tempo insuficiente para realização dos testes, falta de dados precisos para
testar as mudanças e utilização de método de teste inadequado.
Fonte: Elaboração do autor a partir de SEI (CARR et al., 1993); Webster (2005) e Mulcahy (2010).
121
quanto às categorias de riscos propostas pelo SEI (Cont.)
Categoria de
Risco
Técnico
ID
13
Falta de um acordo interativo entre os clientes e os desenvolvedores relativo
às especificações dos requisitos.
Técnico
14 Inadequadas especificações. Ex.: especificações de sistema, hardware,
software, interface, requisitos de teste a qualquer nível com respeito à
viabilidade de implementação e à estabilidade dos atributos de qualidade,
completude e clareza.
Metodológico
15 Modelos, processos, métodos e ferramentas de apoio selecionados
inadequados para o processo de desenvolvimento.
Metodológico
16 Falta / insuficiência de controle do processo de desenvolvimento. Ex.: uso
do recurso, medição do progresso referente à qualidade e metas de
produtividade.
Metodológico
17 Controle do produto inadequado. Ex.: o produto final não corresponde às
expectativas do cliente.
Metodológico
18 Documentação / papelada excessiva.
Metodológico
19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta de estações de
trabalho, espaço de armazenamento no banco de dados insuficiente.
Metodológico
20 Pouca confiança no desenvolvimento do sistema devido à indisponibilidade /
erro / mal funcionamento dos componentes.
Metodológico
21 Pobre suporte ao sistema. Ex.: treinamento para utilização do sistema,
acesso para usuários especialistas ou consultores, conserto ou resolução de
problemas por parte dos vendedores.
Metodológico
22 Planejamento inapropriado, incluindo construção e atualização do plano de
contingência.
Metodológico
23 Papéis e responsabilidades de relacionamentos mal definidos ou mal
entendidos.
Metodológico
24 Gerentes do desenvolvimento do software inexperientes ou ineficientes.
Metodológico
25 Fraca interação (comunicação) do gerente com todos os envolvidos do
projeto.
Metodológico
26 Falhas em gerenciar as expectativas do usuário final.
Metodológico
27 Ausência de um líder.
Metodológico
28 Falta de metodologia efetiva de gerenciamento de projetos.
Metodológico
29 Fraco monitoramento do progresso das atividades relacionadas ao projeto.
Ex.: acompanhamento do relatório de status e manutenção de métricas
progressivas.
Metodológico
30 Treinamento inadequado ou indisponível.
Metodológico
31 Falta de procedimentos, programas adequados e recursos para assegurar a
garantia da qualidade.
Metodológico
32 Gerência de Configuração inadequada.
Metodológico
33 Mudanças contínuas no objetivo e escopo do projeto.
Metodológico
34 Erro ao estimar (tempo, custo e esforço) .
Metodológico
35 Métricas inadequadas / inexatas.
Organizacional 36 Falta espírito de equipe. Os conflitos requerem intervenção da gerência.
Organizacional 37 Problema de comunicação devido à falta de conhecimento da missão, metas
do projeto, informações técnicas entre pares e gerentes e devido à distância
(membros da equipe espalhados por todo o pais).
Organizacional 38 Baixa moral/ falta de compromisso devido ao baixo nível de entusiasmo
afetando assim a produtividade e criatividade. As pessoas não se sentem
reconhecidas e recompensadas pelos superiores.
Organizacional 39 Falta de maturidade / instabilidade organizacional.
Organizacional 40 Baixa produtividade da equipe.
122
quanto às categorias de riscos propostas pelo SEI (Cont.)
Categoria de
Risco
Organizacional
ID
41
Cronograma irreal ou inadequado baseado nos eventos internos e externos
do sistema.
Organizacional 42 Pressão excessiva de prazo.
Organizacional 43 Problemas de pessoal. Ex.: falta experiência, pouco conhecimento, falta de
habilidade, falta de pessoal e indisponibilidade de pessoas chaves.
Organizacional 44 Orçamento insuficiente ou instável baseado nos eventos internos e externos
do sistema.
Organizacional 45 Instabilidade (rotatividade) e falta de continuidade das pessoas nos projetos.
Organizacional 46 Qualquer problema com o cliente, tais como: demora na aprovação de
documentos, comunicação pobre, resistência à mudança, falta de
comprometimento, falta de cooperação, conflitos entre clientes e
departamentos, dependência técnica.
Organizacional 47 Problemas relacionados aos contratos associados.
Organizacional 48 Qualquer problema associado à subcontratação.
Organizacional 49 Fatores políticos (companhia, clientes, contratantes associados e
subcontratantes) que causam problemas para o desenvolvimento do projeto.
Organizacional 50 Qualquer problema com o usuário, tais como: falta de envolvimento /
comprometimento, conflito entre usuários e departamentos, falta de
entendimento com relação ao funcionamento do sistema, resistência a
mudanças e falha em obter o comprometimento do usuário.
Organizacional 51 Falta de comprometimento da gerência sênior
Organizacional 52 Qualquer problema de comunicação em nível internacional relativo a
diferenças de idiomas.
4.5.3 Quanto ao grau de exposição dos fatores de riscos
Os fatores de riscos foram analisados pelas empresas pesquisadas, quanto à sua
probabilidade de ocorrência e impacto nas dimensões de custo, qualidade e prazo (ver
resposta das empresas pesquisadas no Apêndice IV). Os valores atribuídos à probabilidade e
aos impactos em custo, prazo e qualidade foram utilizados como subsídios para cálculo do
grau de exposição do fator de risco e, conseqüentemente, para definir sua priorização
conforme definido no item 3.2 do Capítulo 3.
Considerando-se a matriz de fatores de riscos e a avaliação de probabilidade e impacto
(Tabela 27), observa-se que os resultados estão em sintonia com as principais causas de
fracasso em gerência de projetos apresentadas no referencial da pesquisa de Archibald &
Prado 2008 (ver Gráfico 11).
Das dez principais causas de fracasso citadas pela referida pesquisa, oito aparecem na
Tabela 27, sendo elas: mudança de escopo, falta de comprometimento das áreas, prazos
123
inexeqüíveis, riscos não gerenciados, capacidade gerencial dos GP‟s insuficiente, falta de
comprometimento da alta administração, precariedade de metodologia de GP e habilidade
técnica insuficiente.
Na Tabela 27 é apresentado um resumo das respostas dessas empresas com relação à
análise dos fatores de riscos. Esse resumo foi feito a partir da média das respostas dadas pelas
empresas pesquisadas.
Na primeira e segunda colunas da Tabela 27 são mostrados, respectivamente, o
identificador (ID) e o nome (Fator de Risco Integrado), conforme definido na Tabela 38, no
Apêndice III.
Na terceira coluna é apresentada a média das avaliações, feitas pelas empresas
pesquisadas, quanto à probabilidade (P) de ocorrência do fator de riscos. Para responder este
item as empresas utilizaram os seguintes valores: 1-Muito Baixa; 2-Baixa; 3-Moderada; 4Alta 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; 3Moderado; 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
Impacto
Probabilidade
Custo
4,2
1 Requisitos instáveis.
3,7
33 Mudanças contínuas no objetivo e escopo do
3,8
4,0
projeto.
Fonte: Elaborado pelo autor a partir da pesquisa de campo
Classificação
Qualidade
3,7
Prazo
4,0
Total
11,8
43,4
2,7
4,2
10,8
41,5
124
Tabela 27: Análise dos fatores de riscos segundo as empresas pesquisadas (Cont.)
ID
43 Problemas de pessoal. Ex.: falta experiência,
pouco conhecimento, falta de habilidade,
falta de pessoal e indisponibilidade de
pessoas chaves.
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
7
Impacto
Probabilidade
Classificação
Custo
Qualidade
Prazo
Total
3,2
3,8
4,0
4,2
12,0
38,0
3,3
3,3
3,5
3,7
10,5
35,0
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
3,2
3,7
2,8
3,8
10,3
32,7
3,2
3,5
3,2
3,7
10,3
32,7
3,2
3,3
2,7
4,2
10,2
32,2
3,5
3,2
3,0
3,0
9,2
32,1
3,3
3,2
3,0
3,0
9,2
30,6
2,7
3,7
3,5
4,0
11,2
29,8
3,2
3,0
3,2
3,0
9,2
29,0
2,7
3,7
3,3
3,8
10,8
28,9
2,7
3,8
3,0
4,0
10,8
28,9
2,7
3,3
3,3
3,8
10,5
28,0
3,7
3,3
10,3
27,6
3,0
3,3
9,3
26,4
3,5
3,0
9,8
26,2
5
Adição de mais funcionalidades que o
22 Planejamento
inapropriado,
incluindo
construção e atualização do plano de
contingência.
41 Cronograma irreal ou inadequado baseado
nos eventos internos e externos do sistema.
2 Requisitos incompletos.
3
Requisitos não claros (ambíguos /
imprecisos).
45 Instabilidade (rotatividade) e falta de
4 Requisitos mal entendidos (não refletem as
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.
40 Baixa produtividade da equipe.
13 Falta de um acordo interativo entre os
clientes e os desenvolvedores relativo às
especificações dos requisitos.
17 Controle do produto inadequado. Ex.: o
produto final não corresponde às
2,7
3,3
expectativas do cliente.
50 Qualquer problema com o usuário, tais
como: falta de envolvimento /
comprometimento, conflito entre usuários e
departamentos, falta de entendimento com
2,8
3,0
relação ao funcionamento do sistema,
resistência a mudanças e falha em obter o
6 Requisitos de desempenho não atendidos.
2,7
3,3
Ex. Baixo desempenho.
125
ID
31 Falta
de
procedimentos,
programas
adequados e recursos para assegurar a
garantia da qualidade.
46 Qualquer problema com o cliente, tais como:
comunicação pobre, resistência à mudança,
falta de comprometimento, falta de
cooperação, conflitos entre clientes e
departamentos, dependência técnica.
11 Tecnologia nova / imatura (uso de novas
tecnologias)
24 Gerentes do desenvolvimento do software
29 Fraco monitoramento do progresso das
atividades relacionadas ao projeto. Ex.:
acompanhamento do relatório de status e
26 Falhas em gerenciar as expectativas do
usuário final.
Impacto
Probabilidade
Classificação
Custo
Qualidade
Prazo
Total
2,7
3,3
3,0
3,5
9,8
26,2
2,8
2,8
2,8
3,2
8,8
25,0
2,7
3,3
2,8
3,2
9,3
24,9
2,3
3,5
3,2
4,0
10,7
24,9
3,0
2,7
2,3
3,2
8,2
24,5
2,8
3,2
2,2
3,2
8,5
24,1
2,7
2,8
3,0
3,0
8,8
23,6
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
2,5
2,8
2,8
2,8
8,5
21,3
2,2
3,2
3,5
3,0
9,7
20,9
2,2
3,2
3,3
3,0
9,5
20,6
2,5
2,8
2,5
2,8
8,2
20,4
2,5
2,8
2,7
2,7
8,2
20,4
2,3
2,7
2,8
3,2
8,7
20,2
39 Falta de maturidade / instabilidade
organizacional.
20 Pouca confiança no desenvolvimento do
sistema devido à indisponibilidade / erro /
mal funcionamento dos componentes.
9
44 Orçamento é insuficiente ou instável
baseado nos eventos internos e externos do
sistema.
15 Modelos, processos, métodos e ferramentas
de apoio selecionados são inadequados para
o processo de desenvolvimento.
126
ID
28 Falta de metodologia efetiva de
gerenciamento de projetos.
16 Falta / insuficiência de controle do processo
de desenvolvimento. Ex.: uso do recurso,
medição do progresso referente à qualidade
e metas de produtividade.
47 Problemas relacionados aos contratos
associados.
8 Desenvolvimento de interface do usuário
inadequada.
19 Capacidade
insuficiente
do
sistema
desenvolvido. Ex.: Falta de estações de
trabalho, espaço de armazenamento no
banco de dados insuficiente.
36 Falta espírito de equipe. Os conflitos
requerem intervenção da gerência.
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.
25 Fraca interação (comunicação) do gerente
com todos os envolvidos do projeto.
23 Os papéis e as responsabilidades de
relacionamentos mal definidos ou mal
entendidos.
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.
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).
Impacto
Probabilidade
Classificação
Custo
Qualidade
Prazo
Total
2,5
2,5
2,5
3,0
8,0
20,0
2,0
3,2
3,5
3,0
9,7
19,3
2,5
2,7
2,5
2,5
7,7
19,2
2,3
2,7
2,0
2,7
7,3
17,1
2,0
2,7
3,3
2,5
8,5
17,0
2,2
2,5
2,3
2,8
7,7
16,6
1,8
3,3
2,7
3,0
9,0
16,5
2,3
2,2
2,2
2,7
7,0
16,3
2,0
2,7
2,5
2,7
7,8
15,7
1,8
2,8
2,7
2,8
8,3
15,3
2,0
2,3
2,5
2,7
7,5
15,0
1,8
2,7
2,8
2,3
7,8
14,4
1,8
2,3
2,3
2,5
7,2
13,1
2,2
2,5
7,0
9,3
1,3
2,0
5,3
8,9
1,2
1,3
4,0
4,7
51 Falta de comprometimento da gerência
1,3
2,3
sênior
48 Qualquer
problema
associado
a
1,7
2,0
subcontratação.
52 Qualquer problema de comunicação em
nível internacional relativo a diferenças de
1,2
1,5
idiomas.
127
4.6
Qualidade das informações obtidas
Neste item serão abordados alguns fatos verificados durante as entrevistas relacionados
à qualidade das informações obtidas.
Nenhuma das empresas pesquisadas fornecem cópias de documentos referente às
questões abordadas durante as entrevistas. Isso já era esperado a partir do momento que as
mesmas solicitaram para não serem identificadas, ou seja, manter o sigilo de sua identidade.
Apesar de não ser possível identificar as empresas pesquisadas, tal fato teve como
vantagem a transparência e sinceridade nas respostas durante a entrevista. Isto foi verificado
através da solicitação de que as empresas mostrassem os documentos relacionados às questões
abordadas na pesquisa, como por exemplo: metodologia de gerenciamento de projetos,
metodologia de gerenciamento de riscos, softwares / ferramentas utilizadas etc. A partir daí
foi possível confirmar a transparência das repostas.
Durante a entrevista, a empresa “A” informou não possuir uma metodologia de riscos
implantada, porém o entrevistado informou que utiliza o gerenciamento de riscos
informalmente, em seus projetos.
Na entrevista com a empresa “B”, verificou-se que esta possui uma metodologia de
riscos implantada. O entrevistado informou que não poderia fornecer documentos, porém
apresentou a metodologia e as ferramentas (softwares) utilizados para acompanhar os
projetos, os indicadores de custo e prazo. Apresentou, também, todo o processo e seus
procedimentos para gerenciamento de riscos.
A empresa “C” conforme verificado, possui uma metodologia de gerenciamento de
projeto baseada nos métodos ágeis. Durante a entrevista foi apresentado o software utilizado
(Ice Scrum 2) para acompanhamento dos projetos, porém não possui uma equipe devidamente
capacitada para o uso pleno do mesmo.
A empresa “D” utiliza-se de uma metodologia de gerenciamento de projetos de
desenvolvimento de software baseada no CMMI e no PMBoK. Um fato importante é que,
apesar da necessidade, esta não gerencia riscos em seus próprios projetos. Tal ocorrência se
deve, segundo o entrevistado, à dificuldade para gerenciar, acompanhar e atualizar os dados
referentes aos riscos.
A empresa “E” apresentou uma metodologia de gerenciamento de projetos baseada no
PMBoK e no SCRUM. E, assim como a empresa “D”, também não gerencia riscos. Tal fato
se deve, segundo o entrevistado, à falta de conhecimento ou de uma metodologia adequada
para o gerenciamento de riscos e à dificuldade em identificar os riscos potenciais dos seus
128
projetos. Durante a entrevista com esta empresa foi sugerida uma alteração no roteiro de
análise de riscos relacionada à questão 07, para que a mesma passasse a ser de múltipla
escolha. Tal sugestão foi acatada, permitindo a resposta pelo entrevistado.
A empresa “F” também apresentou uma metodologia de gerenciamento de projetos. Das
empresas pesquisadas foi a que apresentou a maior maturidade/experiência em gerenciamento
de riscos. Nesta, inclusive, se encontra em desenvolvimento uma ferramenta própria de
Business Intelligence (BI)22 para coleta de indicadores de riscos em seus projetos. O
entrevistado informou que, embora não pudesse fornecer o projeto documentado, este
apresentou a metodologia e as ferramentas (softwares) utilizadas para o gerenciamento dos
projetos. Das empresas entrevistadas, foi a única que demonstrou utilizar uma fase a mais no
ciclo de vida dos projetos. Após o encerramento do projeto, faz-se, conforme apresentado, a
avaliação do mesmo, a partir daí, retiram-se aprendizados para os próximos projetos.
Com relação ao roteiro de análise de riscos foi proposital o que parece ser uma
“possível inconsistência” entre as questão 32 (a empresa utiliza algum método para identificar
riscos) e a questão 33 (qual método a empresa utiliza para identificar riscos), caso a empresa
respondesse “não” na questão 32 e passasse a responder a questão 33. Isto permitiria saber
quais métodos eram utilizados. Tal fato tornou possível constatar que apesar de algumas
empresas não utilizarem um método formal para identificar riscos em seus projetos elas
utilizavam algumas métodos, mesmo que intuitivamente, para a identificação de riscos. Isso
pode ser verificado também pelas respostas da questão 26 (abordagem da empresa para
gerenciamento de riscos) quando foram informados, por algumas empresas, que realizavam o
gerenciamento de riscos informalmente.
É importante ressaltar que, mesmo tratando de dados não generalizáveis, por questões
de amostra, é possível uma aplicação prática em outras empresas, o que exigirá, certamente,
adequações e adaptações.
4.7
Síntese dos Resultados
Neste Capítulo serão apresentados os resultados, relacionados à análise das informações
da pesquisa de campo, contendo o perfil dos entrevistados, o perfil das empresas pesquisadas,
22
É o nome que se dá a uma vasta categoria de programas aplicativos e tecnologias usadas para extrair,
armazenar, analisar e transformar grandes volumes de dados, produzindo conhecimento capaz de auxiliar a
empresa a tomar as melhores decisões nos negócios. É análise de dados presentes e passados (Glossário de TI,
2009).
129
os
processos/abordagens
adotados
para
gerenciamento
de
riscos,
os
principais
problemas/dificuldades para gerenciar riscos, a análise dos fatores de riscos (quanto às fases
do ciclo de vida do projeto, quanto às categorias de riscos e quanto ao grau de exposição dos
fatores de riscos) e à qualidade das informações obtidas na pesquisa.
Verificou-se que todas as empresas pesquisadas utilizam algum método para
identificação de riscos. Identificam tanto os riscos internos quanto os riscos externos ao
projeto. Todos os métodos adotados estão de acordo com os métodos citados no Capítulo 2
deste trabalho.
Os principais problemas/dificuldades, enfrentados pelas empresas pesquisadas, para
gerenciar riscos estão associados, em sua maioria, à falta de gerenciamento de riscos baseado
em uma metodologia. Mesmo as empresas que têm uma metodologia de riscos possuem
algumas dificuldades como monitorar riscos em projetos onde a equipe está distribuída em
diversas cidades, manter uma base de dados atualizada sobre os riscos do projeto, falta de
priorização de tempo no decorrer do projeto para gerenciar os riscos, falta de
maturidade/cultura interna de análise de riscos etc.
Com relação a análise dos fatores de riscos quanto às fases do ciclo de vida do projeto,
não há um consenso entre as empresas. Isso pode ter ocorrido em virtude de diversos fatores
como diversidade de projetos, cultura das empresas, além de outros.
Os fatores de riscos foram classificados quanto às categorias de riscos de
desenvolvimento de software proposta pelo SEI (CARR, et al., 1993) e divididos em riscos
técnicos, riscos metodológicos e riscos organizacionais.
Nos fatores de riscos que foram relacionados na pesquisa de campo, foi possível
constatar as mesmas causas de fracasso anunciadas por Archibald & Prado 2008 (Gráfico 11),
ou seja, mudança de escopo, falta de comprometimento das áreas, prazos inexeqüíveis, riscos
não gerenciados, capacidade gerencial dos GP‟s insuficiente, falta de comprometimento da
alta administração, precariedade de metodologia de GP e habilidade técnica insuficiente).
No quesito sobre a qualidade das informações obtidas durante as entrevistas, nenhuma
das empresas pesquisadas fornecem cópia de documentos abordados durante a entrevista. Tal
fato teve como vantagem a transparência e sinceridade nas respostas. Isto foi verificado
quando as empresas apresentaram a metodologia utilizada para gerenciamento de projetos, a
metodologia de gerenciamento de riscos e os softwares/ferramentas utilizados.
130
5
PROPOSTA DE UM MÉTODO ÁGIL DE IDENTIFICAÇÃO DE RISCOS
A presente proposta partiu do estudo de diversos padrões de conhecimento e
metodologias de gerenciamento de projetos, tanto de métodos “tradicionais” quanto de
métodos ágeis, conforme apresentado no item 2.1 deste trabalho.
Foram estudados também os processos de gerenciamento de riscos destes métodos, (ver
item 2.2), o que nos possibilitou conhecer alguns modelos de gestão de riscos em projetos de
desenvolvimento de software, apresentados no item 2.3 deste trabalho.
Após ter estudado os métodos de gerenciamento de projeto, os processos de
gerenciamento de riscos e modelos de gestão de riscos, passou-se ao estudo dos métodos
utilizados para a identificação de riscos, conforme apresentado aqui no item 2.4.
Ao concluir os estudos citados, após a pesquisa de campo, foi possível conhecer a
realidade de algumas empresas, segundo a amostra estabelecida, o que permitiu observar, na
prática, como estas empresas utilizam tanto métodos “tradicionais” como métodos ágeis para
gerenciamento de projetos e de riscos.
A partir de então, foi elaborada uma proposta de um método ágil para identificação de
riscos em projetos de desenvolvimento de software, alinhando os conhecimentos dos métodos
“tradicionais” e dos métodos ágeis, conforme apresentado na Figura 27.
Figura 27: Esquema de um método ágil de identificação de riscos. Fonte: Elaboração do autor.
A seguir será apresentada a descrição das etapas constantes da Figura 27, sendo elas: (1)
preparação inicial, (2) lista de fatores de riscos, (3) fatores de riscos selecionados, (4) novos
fatores de riscos, (5) atualização da lista de fatores de riscos e (6) lições aprendidas.
131
1. Preparação inicial: Nesta etapa é feito o levantamento das partes envolvidas no
projeto e a seleção daquelas que irão participar deste processo de identificação de
riscos; é onde se procura rever em qual fase o projeto se encontra; e, rever os
objetivos do projeto e/ou da fase em desenvolvimento. Se houver necessidade,
deverá ser realizado um treinamento/preparo da equipe para identificação de riscos
do projeto. Esse pode ser um curso, uma palestra ou apenas uma explicação sobre
o método a ser utilizado para identificar riscos. A escolha do tipo de treinamento
dependerá da experiência/conhecimento da equipe ou da natureza do projeto.
2. Lista de fatores de riscos: A proposta, nesta etapa, é utilizar uma lista de riscos
definida antecipadamente. Caso a empresa não possua tal lista em sua base
histórica de projeto, sugerimos começar pela lista de riscos elaborada nesta
dissertação. Esta lista de fatores de riscos integrados para desenvolvimento de
software, foi elaborada a partir do estudo de diversos autores (ver Apêndice III Tabela 38). Ela pode ser classificada por fases do ciclo de vida do projeto (PMI,
2008)23 ou por categorias de riscos propostas pelo SEI (Tabela 16) (Carr et al.,
1993). No Apêndice V é apresentada uma classificação dos fatores de riscos de
acordo com as fases do ciclo de vida de projetos, segundo as empresas
pesquisadas. A classificação desses fatores por categorias de riscos, pode ser vista
na Tabela 26. Caso a empresa utilize alguma metodologia de gerência de projetos
que não contemple as fases propostas aqui pelo PMI (2008), as tabelas contidas no
Apêndice V podem ser adaptada à realidade da empresa. Por exemplo a empresa
pode adaptar esta tabela por Sprint (se utilizar método ágil de gerenciamento de
projetos), por outras fases, ou ainda por categorias de riscos. O importante é a
utilização desta lista de fatores de riscos e que eles sejam sempre atualizados
conforme o uso nos projetos da empresa.
3. Fatores de riscos selecionados: É nessa etapa que é feita a seleção dos fatores de
riscos, conforme a fase do ciclo de vida em que o projeto se encontra. Estes serão
analisados pela equipe na fase seguinte.
4. Novos fatores de riscos: Nesta etapa é necessário reunir com a equipe para
verificar se os riscos selecionados na etapa anterior estão de acordo com a fase em
que o projeto se encontra atualmente, conforme definido na etapa 1 deste método.
23
Todas as empresas pesquisadas utilizavam as mesmas fases para gerenciamento de seus projetos, seguindo a
proposta contida no PMBoK (PMI, 2008).
132
Caso haja necessidade, a equipe identifica novos riscos, não para o projeto como
um todo, e sim para a fase do projeto em análise. Pode utilizar para isso os
diversos métodos para identificação de riscos apresentados no item 2.4 deste
trabalho.
5. Atualização da lista de fatores de riscos: Nesta etapa, caso ocorra alguma
modificação na lista de riscos proposta inicialmente (etapa 3) ou a identificação de
novos riscos para o projeto (etapa 4), deverá ser feita a atualização da lista (etapa
2) e, consequentemente, dos riscos selecionados para a etapa 3. Isso se torna
necessário para que a empresa tenha sempre uma lista de riscos atualizada.
6. Lições aprendidas: Nesta etapa realizam-se os registros de lições aprendidas nas
etapas anteriores. Tais lições consistem basicamente no registro de respostas a três
perguntas bem simples: (a) o que foi bom e deve-se continuar utilizando; (b) o que
não foi bom e não se deve utilizar mais; e, (c) o que deve ser melhorado.
Esta proposta de um método ágil para identificação de riscos em projetos de
desenvolvimento de software foi apresentada a três profissionais com larga experiência em
utilização das práticas de gerenciamento de projetos tanto do PMBoK quanto do SCRUM.
Esses profissionais são pertencentes às empresas “E e F” deste trabalho e o método proposto
foi apresentado após a realização da pesquisa. Em síntese estes profissionais experientes
apresentaram as seguintes considerações:

Acharam a proposta muito interessante e inovadora na forma apresentada24;

Que esta abordagem pode ser utilizada para agilizar a identificação de riscos e,
dependendo da metodologia adotada pelas empresas, para o gerenciamento de
seus projetos (incluindo o gerenciamento de riscos); o método proposto pode ser
facilmente adaptado à realidade das empresas.
24
Todos estes profissionais solicitaram uma cópia do trabalho após a sua conclusão.
133
CONCLUSÃO
Este trabalho propôs realizar uma investigação sobre gerenciamento de riscos e
apresentar uma proposta de um método ágil para identificação deles em projetos de
desenvolvimento de software. Para isso foram definidos oito objetivos específicos. Os cinco
primeiros foram abordados por meio do levantamento teórico, o sexto e sétimo por uma
pesquisa de campo e, o último objetivo específico, utilizou-se tanto do levantamento teórico
quanto da pesquisa de campo para ser atendido.
No levantamento teórico foi apresentada uma visão geral dos padrões de conhecimento,
normas e métodos de gerenciamento de projetos divididos em “tradicionais” e ágeis. A partir
daí foram apresentados os processos de gestão de riscos para os métodos “tradicionais” e
ágeis como também algumas normas e métodos específicos da área de TI que abordam a
gestão de riscos em projetos de desenvolvimento de software. Logo após foram descritos
alguns métodos utilizados para a identificação de riscos em projetos, com levantamento e
identificação de 52 fatores de riscos para projetos de desenvolvimento de software, que
serviram como subsídio para o roteiro de análise de riscos.
Para a pesquisa de campo foi adotado o método de estudo de caso múltiplo realizado em
seis empresas. Este estudo de caso permitiu avaliar como as empresas participantes do estudo,
identificam e tratam os riscos em seus projetos e, a partir das respostas, propor uma
priorização de riscos para projetos de desenvolvimento de software.
O método ágil proposto para identificação de riscos em projetos de desenvolvimento de
software, apresentado neste trabalho, mostra que é possível adotar uma abordagem ágil para
tal fim.
Este estudo permitiu por meio de investigação teórica e de pesquisa de campo levar um
conjunto de contribuições a todos aqueles (profissionais liberais, empresas, comunidades do
terceiro setor, governo etc.) que desejem conhecer e melhorar seus processos de
gerenciamento de projetos e em especial o gerenciamento de riscos em projetos de
As principais contribuições deste trabalho, suas limitações de pesquisa e as sugestões
para trabalhos futuros estão descritas a seguir.
134
Contribuições
As principais contribuições desse estudo são:

Identificação, por meio de investigação teórica, de padrões de conhecimento e
métodos de gerenciamento de projetos “tradicionais” e ágeis, seus processos e
ciclos de vida. Essa identificação e caracterização podem ser utilizadas por
gerentes de projetos.

Apresentação de um conjunto de processos tanto dos métodos “tradicionais”
quanto dos métodos ágeis de gerenciamento de projetos e gerenciamento de
riscos. Esse conjunto de processos teve como finalidade fornecer informações
sobre os diversos processos para gerenciamento de projetos.

Identificação e apresentação de modelos de gestão de riscos em projetos de

Levantamento de diversos métodos para identificação de riscos. Esse
levantamento serve como orientação para quem desejar utilizar algum método já
conhecido para identificação de riscos em seus projetos.

Uma revisão, análise e compilação de fatores de riscos para desenvolvimento de
software, segundo diversos autores da área, relacionando-os em uma lista de 52
itens que poderá ser utilizada no processo de identificação de riscos.

Um questionário detalhado que permite coletar informações importantes sobre
as abordagens adotadas, por empresas de desenvolvimento de software, para
gerenciamento de riscos em projetos, em termos das práticas adotadas pelas
empresas pesquisadas. Apesar de ter se restringido a apenas seis casos, trata-se
de empresas de referência/líderes em seu campo de atuação.

Elaboração da proposta de um método ágil para identificação de riscos em
projetos de desenvolvimento de software.
Limitações da pesquisa
O presente trabalho apresentou algumas limitações descritas a seguir:

A pesquisa, restringiu-se a apenas seis casos, apesar de tratar-se de empresas de
referência/líderes em seu campo de atuação, não permite generalização para
outras empresas.
135

Houve dificuldade de conseguir autorização para a realização de pesquisa dentro
das empresas, por se tratar de relato da forma como as empresas gerenciam
riscos, podendo revelar seus problemas e fragilidades.
Trabalhos futuros
Para dar continuidade a este estudo, poderão ser realizados os seguintes trabalhos
futuros:

Ampliação da amostra pesquisada de tal forma que se consiga uma amostra
representativa, em termos quantitativos, e que permita a realização de cálculos
estatísticos e a generalização de seus resultados para outras empresas.

Aplicação
do
método
proposto
em
projetos
reais,
durante
o
seu
desenvolvimento/gerenciamento, tanto em empresas que utilizam métodos
“tradicionais” quanto em empresas que utilizam métodos ágeis para
gerenciamento de seus projetos.

Avaliação após a aplicação do método em empresas reais dos aspectos positivos
e negativos.

Automação de um sistema de informação para dar feedback na base de dados de
risco para ser mais assertivo na fase de planejamento (melhoria contínua) de

Verificação no mercado da existência de ferramentas que auxiliem na
identificação de riscos em projetos de desenvolvimento de software.
136
REFERÊNCIAS
A Comparison of PRINCE2 Against PMBOK. Publicado em 24 jan. 2002. Disponível em:
<http://www.bligoo.com/media/users/1/50369/files/4363/A%20comparison%20of%20Prince
%202%20vs%20PMBOK.pdf>. Acesso em 07 dez. 2010. Disponível também em:
<http://www.scribd.com/doc/36166632/Pmbok-vs-Prince2-Detail>. Acesso em: 10 dez. 2010.
ADAMS, John. Risco. 1. ed. São Paulo: Senac, 2009.
ADDISON, Tom; VALLABH, Seema. Controlling Software Project Risks – an Empirical
Study of Methods used by Experienced Project Managers. Proceedings of SAICSIT, p.128140, 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>.
em: abr. 2010.
Acesso
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/SEI93-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-ScrumXP.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-withscrum;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-degerenciamento-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ósgraduação em Desenvolvimento Regional das Faculdades Alves Faria (Alfa).
144
use of formal method risk management. Done that identified the states of objects dissertation
research on risk management projects..
Palavras chave: Medidas de Localização das Atividades, Quociente Locacional,
Métodos e Técnicas de Análise do Desenvolvimento Regional, Gerenciamento de Risco.
Introdução
A abordagem para gerenciamento de riscos adotada pelas empresas que participaram da
Pesquisa de Benchmarking em Gerenciamento de Projetos no Brasil em 2008, no que diz
respeito à utilização de uma metodologia formal, estrutura por políticas, procedimentos e
formulários, não se desenvolveu de forma uniforme entre os estados brasileiros. Daí
resultaram diferentes padrões de localização da utilização dessa abordagem para
gerenciamento de riscos. Nesse contexto, surgem as perguntas:
 Como as empresas que utilizam essa abordagem para gerenciamento de riscos
se distribuem no espaço?
 Onde essas empresas se localizam, em quais regiões e estados brasileiros?
 Qual região e estado apresenta maior concentração da prática dessa abordagem
para gerenciamento de riscos?
 Qual deve ser o território de análise em pesquisa sobre gerenciamento de riscos
em projetos?
Respostas
para
estas
perguntas
podem
ser
obtidas
com
indicadores
de
localização/concentração.
Neste artigo será utilizado o quociente locacional, no intuito de verificar as regiões e os
estados, dentro dessas regiões, que apresentam maior concentração de empresas que utilizam
a abordagem de gerenciamento de riscos em projetos, além da justificativa pela escolha dos
estados que serão objetos desta pesquisa.
A aplicação do quociente locacional será utilizando-se como referência o Estudo de
Benchmarking em Gerenciamento de Projetos no Brasil, realizada em 2008. Este Estudo de
Benchmarking inclui diversos temas sobre gerenciamento de projetos, mas para este artigo
interessa o tema referente à abordagem adotada pelas empresas brasileiras, com relação ao
gerenciamento de riscos em projetos, mais especificamente com relação às empresas que
145
gerenciam riscos baseando-se em uma metodologia formal, estruturada por políticas,
procedimentos e formulários.
1.
Metodologia
Para a realização deste artigo utiliza-se o Estudo de Benchmarking em Gerenciamento
de Projetos no Brasil, para o ano de 2008. Esse estudo conta com a participação de 373
empresas abrangendo todas as regiões brasileiras.
Apesar de o Estudo de Benchmarking conter empresas de todas as regiões brasileiras o
mesmo não aconteceu com relação aos estados, não houve a participação de todos os estados
brasileiros.
Para o estudo a ser apresentado neste artigo, tendo como referência, os dados do Estudo
de Benchmarking em Gerenciamento de Projetos no Brasil, para o ano de 2008, adotam-se
alguns critérios: a) não serão considerados os estados que não participam da pesquisa, sendo
eles: Acre, Amapá, Maranhão, Paraíba, Piauí, Rio Grande do Norte, Rondônia, Roraima e
Tocantins; b) não serão considerados os estados com um índice de participação, no Estudo de
Benchmarking, inferior a 1%: Alagoas, Mato Grosso do Sul, Pará e Sergipe.
Por meio do método do quociente locacional, e para os estados selecionados no Estudo
de Benchmarking28, serão identificados os estados que possuem maior concentração da
utilização da abordagem de gerenciamento de riscos em projetos.
No Estudo de Benchmarking em Gerenciamento de Projetos no Brasil, referente à
pergunta sobre as abordagens adotadas pelas empresas brasileiras para gerenciamento de
riscos em seus projetos apresentam-se três alternativas de respostas. São elas: (a) Não
tratamos riscos em projetos na nossa organização; (b) Realizamos informalmente, conforme
interesse ou necessidade do responsável pelo projeto; (c) Baseado em uma metodologia
formal, estruturada por políticas, procedimentos e formulários.
Neste artigo iremos analisar o quociente locacional para a alternativa “(c)”, ou seja,
iremos identificar quais regiões e estados brasileiros incidem maior concentração de empresas
que gerenciam riscos baseado em uma metodologia formal, estruturada por políticas,
28
Os estados selecionados foram os que apresentaram índice de participação no Estudo de Benchmarking em
gerenciamento de projetos, superior a 1%. Portanto os estados que serão objetos de estudo deste artigo são:
Bahia, Distrito Federal, Ceará, Goiás, Rio Grande do Sul, Santa Catarina, Mato Grosso, São Paulo, Rio de
Janeiro, Pernambuco, Amazonas, Paraná, Minas Gerais e Espírito Santo.
146
A medida de localização utilizada neste artigo será o quociente locacional e é descrita a
seguir, conforme apresentada por (Haddad, 1989 e Souza. et al., 2007). Os cálculos
organizam-se em duas matrizes de informações, sendo uma por região e outra por estado,
onde cada linha “j”29 mostra a região ou estado, a quantidade de empresas que participam da
pesquisa e a quantidade de empresas relacionadas a cada uma das alternativas de resposta
“i”17 da pergunta sobre qual abordagem adotada pelas empresas brasileiras para
gerenciamento de riscos em seus projetos.
Tabela 28: Matriz de Informações obtidas a partir do Estudo de Benchmarking em
Gerenciamento de Projetos no Brasil – 2008.
Alternativas de respostas da pergunta
Região
ou
Estado
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
j
TOTAL
i
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.
Quantidade de respostas da abordagem para gerenciamento de riscos “i” na região ou estado “j” (ver Tabela
29).
30
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
Alternativas de respostas da pergunta
Região
ou
Estado
em projetos na
nossa organização
necessidade do responsável
pelo projeto
formal, estruturada por
políticas, procedimentos e
formulários
Eij
TOTAL
∑i Eij
TOTAL
∑j Eij
∑i ∑j Eij
 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”.
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”.
Yij = Distribuição percentual das abordagens “i” para todas as regiões
ou estados “j”.
portanto:
Sendo, portanto o Quociente Locacional (QL) por região ou estado representado por:
Xij
QLij = --------------Yij
 Interpretação dos Resultados:
QLij ≥ 1: Localização significativa, ou seja, maior concentração locacional de
empresas, por região ou estado, que utilizam uma metodologia formal de
gerenciamento de riscos;
QLij < 1: Localização fraca, ou seja, menor concentração locacional de
empresas, por região ou estado, que utilizam uma metodologia formal de
Para chegar ao resultado da medida de localização será aplicado o método do quociente
locacional segundo Haddad (1989) e Souza (et al., 2007). Para identificar os estados dentro
das regiões que possuem maior concentração locacional, serão realizados cálculos do QL em
duas etapas:
1ª Etapa: aplicação do método (Quociente locacional) por região. Com isso
pretende-se encontrar as regiões brasileiras que apresentam maior concentração
da utilização de uma metodologia formal de gerenciamento de riscos.
2ª Etapa: identificar, para as regiões selecionadas31 na 1ª Etapa, quais estados
apresentam maior concentração locacional da utilização de uma metodologia
formal de gerenciamento de riscos.
31
Regiões selecionadas são aquelas que apresentaram a maior concentração locacional, ou seja, QL ≥ 1.
149
Os estados identificados na 2ª Etapa representarão os estados potenciais para a escolha
do mais indicado para desenvolvimento da pesquisa sobre gerenciamento de riscos.
Portanto este artigo tem como objetivo identificar qual estado brasileiro apresenta maior
concentração da utilização de uma metodologia formal de gerenciamento de riscos e, ainda,
escolher qual(is) estado(s) de uma região será(ão) selecionado(s) para a elaboração de uma
pesquisa sobre gerenciamento de riscos.
2.
Resultados
A partir dos dados obtidos no Estudo de Benchmarking em Gerenciamento de Projetos
no Brasil – 2008 é apresentada, na Tabela 30, a abordagem adotada pelas empresas brasileiras
para gerenciamento de riscos, por região. Logo a seguir, na Tabela 31, apresenta-se o
Quociente Locacional (QLRegião) por região, tendo como referencia os dados da Tabela 30.
região
QUANTIDADE DE RESPOSTAS
(b)
(a)
(c)
em projetos na
nossa organização
Realizado
informalmente,
conforme interesse
ou necessidade do
responsável pelo
projeto
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%
REGIÃO
Baseado em uma
TOTAL
metodologia
formal, estruturada
por políticas,
procedimentos e
formulários
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
(Xij)
QLRegião
(Xij / Yij)
SUDESTE
8,182%
1,015
SUL
7,937%
0,984
(Yij)
NORDESTE
7,317%
0,907
CENTRO-OESTE
7,317%
NORTE
14,286%
8,065%
(b)
necessidade do responsável pelo
projeto
(Yij)
60,753%
(Xij)
QLRegião
(Xij / Yij)
60,909%
1,003
60,317%
0,993
(c)
formal, estruturada por políticas,
procedimentos e formulários
(Yij)
31,183%
(Xij)
QLRegião
(Xij / Yij)
30,909%
0,991
31,746%
1,018
31,707%
1,017
60,976%
1,004
0,907
60,976%
1,004
31,707%
1,017
1,771
57,143%
0,941
28,571%
0,916
Quando o QLRegião < 1, significa que a região apresenta uma concentração locacional
fraca. Quando o QLRegião ≥ 1, significa que a região apresenta concentração locacional forte,
ou seja, nesta região existe uma maior concentração de empresas que utilizam a abordagem de
gerenciamento de riscos baseada em uma metodologia formal, estruturada por políticas,
Após o cálculo do QLRegião , estes foram alocados no mapa (Gráfico 12), onde é possível
ver graficamente as variações entre as regiões brasileiras para os três tipos de abordagens
(alternativas (a), (b) e (c) ) para o gerenciamento de riscos adotados pelas empresas, de acordo
com os dados do Estudo de Benchmarking em Gerenciamento de Projetos no Brasil – 2008.
151
Gráfico 12: Quociente Locacional por Região da abordagem para gerenciamento de riscos
(a) Não tratamos riscos em projetos
Legenda de Cores:
Quociente Locacional ≥ 1
0 < Quociente Locacional < 1
(b) Realizam
informalmente,
conforme interesse ou necessidade
do responsável pelo projeto
(c) Baseado em uma metodologia formal,
estruturada
por
políticas,
Legenda de Regiões:
1-Centro-Oeste
2-Nordeste
3-Norte
4-Sudeste
5-Sul
Considerando que o objetivo deste artigo é a alternativa (c) (Gráfico 12), ou seja,
abordagens para gerenciamento de riscos baseadasem uma metodologia formal, estruturada
por políticas, procedimentos e formulário, pode-se observar que as regiões que apresentam
maior concentração locacional32 são as regiões Centro-Oeste, Nordeste e Sul.
Conforme já mencionado é calculado o Quociente Locacional por estado (QLUF)
(Tabela 32), somente para os estados das regiões que apresentaram maior concentração
locacional (Gráfico 12).
32
Regiões que apresentaram a maior concentração locacional, são as que possuem QLRegião ≥ 1.
152
estado33
QUANTIDADE DE RESPOSTAS
(a)
Não tratamos
riscos em projetos
na nossa
organização
(b)
Realizado
informalmente,
conforme interesse
ou necessidade do
responsável pelo
projeto
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
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%
UF
PARANÁ
%
(c)
Baseado em uma
metodologia
TOTAL
formal, estruturada
por políticas,
procedimentos e
formulários
%
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%.
153
Tabela 33: Quociente Locacional da abordagem para gerenciamento de riscos por Estado
(b)
(a)
(c)
Não tratamos riscos em projetos
conforme interesse ou necessidade
do responsável pelo projeto
formal, estruturada por políticas,
UF
(Yij)
(Xij)
QLUF
(Xij / Yij)
(Yij)
(Xij)
QLUF
(Xij / Yij)
(Yij)
(Xij)
QLUF
(Xij / Yij)
BAHIA
8,333%
1,072
58,333%
0,950
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
7,775%
60,714%
0,989
61,394%
32,143%
1,043
30,831%
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
12,500%
1,608
62,500%
1,018
25,000%
0,811
ESPÍRITO SANTO
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
0 < Quociente Locacional < 1
Estado não pesquisado
Estado com menos de 1% de participantes na pesquisa
Conforme já mencionado o Estudo de Benchmarking em Gerenciamento de Projetos no
Brasil – 2008, inclui empresas de diversos estados brasileiros, porém alguns estados não
participaram do Estudo de Benchmarking e outros tiveram uma participação inferior a 1%. E
esse fato se repete também para as regiões objeto deste artigo e identificadas no Gráfico 12.
Das três regiões que apresentaram maior concentração locacional, alternativa (c)
(Gráfico 12), os estados do Maranhão, Piauí, Rio Grande do Norte e Paraíba não foram
contemplados no Estudo de Benchmarking sobre Gerenciamento de Projetos no Brasil – 2008.
Já os estados de Alagoas e Sergipe tiveram uma participação inferior a 1%, no referido Estudo
de Benchmarking.
Considerando que o objetivo deste artigo é a alternativa (c) (Tabela 33), ou seja,
abordagens para gerenciamento de riscos baseadas em uma metodologia formal, estruturada
por políticas, procedimentos e formulário, pode-se observar que os estados que apresentaram
155
maior concentração locacional34 foram os estados do Mato Grosso, Goiás e Distrito Federal
(Região Centro-Oeste), Ceará e Bahia (Região Nordeste) e Santa Catarina e Rio Grande do
Sul (Região Sul). E os estados, dentro das três regiões identificadas (Gráfico 12), que
apresentaram menor concentração locacional foram Pernambuco e Paraná.
3.
Conclusões
Conforme já mencionado, este artigo teve como objetivo identificar quais estados
brasileiros apresentavam maior concentração locacional da utilização de uma metodologia
formal de gerenciamento de riscos e, escolher os estados de uma região para a elaboração de
uma pesquisa sobre gerenciamento de riscos.
Após os estudos realizados neste artigo, os estados que apresentaram maior
concentração locacional foram os estados do Mato Grosso, Goiás e Distrito Federal (Região
Centro-Oeste), Ceará e Bahia (Região Nordeste) e Santa Catarina e Rio Grande do Sul
(Região Sul).
Portanto, pode-se concluir que sete estados, em três regiões brasileiras, se enquadrariam
no objetivo deste artigo, ou seja, poderiam ser selecionados para a elaboração de pesquisa
sobre gerenciamento de riscos.
Dos sete estados foram escolhidos os estados de Goiás e Distrito Federal (pertencentes à
região Centro-Oeste). Esta escolha também se justifica pela redução de custo e facilidade
operacional.
34
Estados que apresentaram a maior concentração locacional, são as que possuem QLUF ≥ 1.
156
APÊNDICE II – Lista de Riscos para Sistemas de Informação
Conforme já mencionado, Mulcahy (2010) classificou sua lista de riscos, para sistemas
de informação, em 10 categorias (contrato, cliente, internacional, gerenciamento de projeto,
qualidade, recursos, escopo, segurança, riscos com fornecedor e tecnologia), conforme Tabela
17. Na primeira coluna temos a identificação do fator de riscos, exemplo 1-01, onde o
primeiro número “1” representa o autor do fator de risco, ou seja, “Mulcahy (2010) e o
segundo número “01” representa o número do fator de risco. A segunda coluna contém a
causa, a terceira o nome e a quarta descreve o efeito do risco.
Tabela 34: Lista de riscos para sistemas de informação
ID35
CAUSA
Contrato
Fornecedor selecionado fará o tempo
de trabalho/materiais X a oferta fixa
usual.
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.
Cliente
Porque há resistência entre os usuários
ao substituir a sua aplicação de
software atual por um novo aplicativo
de software/ sistema.
Porque um bom relacionamento com o
cliente não pode ser mantida.
1-01
1-02
1-03
1-04
RISCO
EFEITO
Portanto, temos a falta de
experiência em registros precisos
Os
objetivos
podem
se
desenvolver gradualmente.
Isso pode levar a custos sendo
cobrados incorretamente.
Pode haver sabotagem.
O que resultaria em um atraso
do projeto.
O que poderia levar ao atraso
do projeto e à um custo mais
caro.
O que pode exigir mais
reuniões e uma extra e
constante garantia.
1-05
Porque o fornecedor é dependente do Os dados podem não estar Fazendo testes começarem
cliente para dados de teste.
disponíveis logo que necessário.
mais tarde do que deveriam
para atender à devida data
solicitada
com
qualidade
adequada.
Fonte: Mulcahy, 2010.
35
Se existe falta de confiança.
157
Tabela 34: Lista de riscos para sistemas de informação (Cont.)
ID36
1-06
CAUSA
RISCO
EFEITO
Devido ao pouco esforço por parte do A equipe do cliente pode trabalhar O que pode resultar em metas
cliente para obter apoio para o projeto. ativamente contra o projeto.
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 Oportunidades para uma solução Fazendo com que o cliente e os
dependente do fornecedor para mais satisfatória poderia ser clientes deles aceitem a
conhecimento
técnico
sobre
a perdida.
funcionalidade
reduzida
aplicação de software e ferramentas de
desnecessariamente
software subjacente.
1-08
Porque o cliente pretende reescrever o O cancelamento do projeto pode Causando um atraso no
aplicativo e trazê-lo à tona dentro de ocorrer.
cronograma de mais de dois
12 a 18 meses.
meses.
Internacional
1-09
Pessoas de oito países estão O
que
pode
causar
má Resultando em baixa moral e a
trabalhando neste projeto e a maioria interpretação do idioma ou necessidade de aumentar o
não está acostumada a trabalhar com problemas culturais.
treinamento e a construção de
culturas diferentes.
equipe.
1-10
O clima econômico atual tem muitas O que pode causar uma grande Aparecendo riscos de custos
mudanças no valor das moedas em uso oscilação no valor do dólar.
adicionais.
no projeto.
1-11
Pessoas de países conservadores estão O que pode causar uma mudança Resultando em atividade ilegal
trabalhando neste projeto e a maioria nas leis internas e estrangeiras ou inadvertida
não está em sintonia com trabalhar leis falhas.
com culturas diferentes.
1-12
Devido a problemas com a imigração. Um ou mais membros da equipe O que pode causar um atraso
itinerante do projeto pode se no projeto.
atrasar ou não ter permissão para
prosseguir.
1-13
Devido às obrigações e restrições Chave
de
software
ou O que poderia causar um
aduaneiras.
equipamento pode ser atrasada no atraso no projeto.
transporte.
1-14
Devido às diferenças de horários de Toda a equipe do projeto pode não Fazendo com o trabalho seja
férias e/ou feriados.
estar disponível em determinadas refeito.
épocas.
1-15
Devido às exigências linguísticas.
O número de fornecedores O que pode resultar em uma
qualificados pode ser menor.
equipe de projeto de qualidade
inferior.
1-16
Devido
à
diferentes
práticas O sistema escolhido para as O que pode resultar em um
comerciais.
operações norte-americanas pode sistema de baixa qualidade ou
não ser adequada para as unidades um aumento na duração do
de negócios internacionais.
projeto e no custo para maiores
requisitos de programação.
1-17
Devido à baixa disponibilidade de Os membros da equipe itinerante O que pode resultar em um
voos.
do projeto podem não estar atraso para o projeto.
disponíveis para uma semana
inteira de trabalho.
36
158
ID37
1-18
EFEITO
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 As comunicações chaves pode ser O que pode resultar em um
ou voz (entrega lenta ou baixa atrasadas.
declínio do projeto.
qualidade) a nível internacional.
1-20
Devido às diferenças de idiomas.
A definição de papéis e O que pode resultar em falhas
responsabilidades para a equipe do para selecionar os melhores
projeto não podem ser plenamente recursos.
compreendidas.
1-21
Devido à incompreensão das leis Procedimentos
inadequados O que pode resultar em atraso
trabalhistas
e
regulamentos podem ser seguidos.
da disponibilidade de recursos.
internacionais.
1-22
Devido ao terrorismo.
Instalações podem ser danificadas Resultando em um atraso para
ou membros da equipe podem ser o projeto e/ou aumento do
mortos ou seqüestrados.
custo.
1-23
O gerente de projeto pode não O que pode resultar em um
comunicar adequadamente os atraso para o projeto ou
requisitos ou programações aos diminuição da qualidade do
membros da equipe.
sistema.
Gerenciamento do Projeto
1-24
A falta de financiamento tem O que pode causar uma exaustão Causando a exaustão da equipe
provocado uma semana obrigatória de rápida
na
equipe
para e a saída do projeto.
50 horas extras por mês com adicional desempenhar essa
habilidade
de 50 horas sendo muito comum.
industrial de alta demanda.
1-25
Devido a nenhuma informação escrita Coleta de dados em tempo Resultando em menor tempo
sobre projetos passados.
adicional pode ser necessária.
gasto na
conclusão dos
trabalhos.
1-26
Devido a uma reorganização.
As pessoas podem gastar tempo Resultando no atraso do
discutindo
o
efeito
da projeto.
reorganização.
1-27
Devido à gestão anunciando que a Empregados podem adiar seu Causando atrasos no projeto ou
entrega de um produto estará liberada trabalho atual e um outro projeto insatisfação com a gestão ou a
em uma determinada data.
pode ser iniciado para atender a perda de motivação e de
esse prazo.
trabalho adicional refeito uma
vez que o prazo de entrega foi
cumprido.
1-28
Devido à existência de um projeto Nem todas as áreas de negócio O que pode resultar no sistema
separado e equipes de implementação. estão envolvidos na determinação não ser capaz de abordar todos
dos objetivos de trabalho para o os requisitos do negócio.
projeto.
1-29
Devido à existência de um projeto Parte do projeto pode não ser Levando à uma mudança tardia
separado e equipes de implementação, capaz de ser implementado no de objetivos no projeto.
e porque a equipe de implementação mundo real.
não tem sido capaz de se pronunciar
sobre o projeto.
1-30
Devido à existência de dois projetos Pode haver uma falta de Causando desalinhamento de
colaborativos.
coordenação entre os projetos.
requisitos e projeto.
37
CAUSA
RISCO
Devido à aquisição/compra de Pode haver incompatibilidade.
hardware a partir de várias fontes
internacionais.
159
ID38
1-31
EFEITO
Atrasando o projeto e aumento
do estresse em ambas as
equipes, do cliente e do
fornecedor.
1-32
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 O que pode causar um sofrimento Resultando em produtividade
espalhados por todo o país.
na comunicação.
sendo sacrificada.
1-34
O
tempo
de
avaliação
para Embora este calendário tenha sido Resultando em atrasos.
ferramentas/métodos é menor do que a aprovado pela administração, a
empresa já teve que lidar no passado.
realidade de prazos pode não ser
adequada.
Qualidade
1-35
Porque não há um plano de Problemas são susceptíveis de Resultando em um potencial
gerenciamento de qualidade.
serem descobertos e resolvidos para uma versão com vírus
depois do teste, ao invés de serem significativos conhecidos.
resolvidos no início do ciclo de
desenvolvimento de vida.
1-36
Porque muitas das regras para reforçar Algumas linhas da tabela podem Resultando (no melhor caso)
a integridade referencial no banco de ser
mudadas
ou
deletadas em trabalho refeito e (no pior
dados são, na verdade, implementadas incorretamente.
caso) na perda de dados do
no código do aplicativo.
cliente.
1-37
Porque o fornecedor confia totalmente A ligação pode não ser concebida Redução da satisfação do
no cliente para muitas decisões do tão bem como deveria ser.
cliente.
projeto (por exemplo: navegação de
página na web).
1-38
Porque o documento do projeto se Pelo menos uma regra de negócio De tal forma que o pedido
refere a números específicos (exemplo: pode ser mal implementada ou pode não se comportar como
0-120 dias), sem explicar as relações uma dependência inapropriada deveria.
entre os números.
pode ser criada.
1-39
Porque o fornecedor não tem meios Recursos existentes que poderiam Resultando em tempos de
para avaliar o impacto de desempenho compartilhar código com novos resposta mais lentos do
antes de o software ser implantado.
recursos podem não fazê-lo.
usuário.
1-40
Porque esta relação fornecedor / Este projeto pode encontrar a Resultando em um produto
cliente e esta aplicação tem uma mesma pressão para os ciclos de implantado
de
qualidade
história
de
programas
de testes reduzidos.
inferior à desejada.
desenvolvimento de ultrapassagem,
resultando
em
sistemas
significativamente encurtados e testes
de aceitação.
1-41
Por motivo das versões anteriores O fornecedor pode concluir que E falhar para melhorar os
terem tido um número elevado de vírus isso é aceitável para o cliente.
processos que podem ser
e recursos mal implementados.
mostrados
para
causar
resultados tão pobres.
38
CAUSA
RISCO
Porque não há nenhum plano Problemas
graves
podem
compreensivo de gerenciamento de permanecer em um nível inferior
comunicações.
da responsabilidade do projeto do
que deveriam.
Nem a administração nem as vendas O que pode significar que o cliente
disseram ao cliente que algumas de pode não ajustar as exigências.
suas exigências podem não ser
cumpridas dentro do prazo.
160
ID39
1-42
CAUSA
RISCO
EFEITO
Devido às mudanças do mercado ou O patrocinador/origem de fundos O que pode levar a um projeto
outras prioridades.
pode esgotar-se de dinheiro ou se abandonado e/ou
recusar a continuar a financiar.
impossibilidade de entregar
todas as funcionalidades.
1-43
Devido aos processos ruins ou outros Dados históricos podem ser O que levaria à saída do
problemas.
imprecisos ou poluídos.
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 O sistema pode funcionar como Resultando em baixa aceitação
treinamento ou gerenciamento.
necessário, mas as mudanças de do usuário e impacto negativo
processos que precisam ocorrer na percepção do sistema e
podem não acontecer.
equipe de projeto.
1-45
Devido ao planejamento ruim.
O volume de usuários/dados pode O que pode levar à lentidão do
ser maior do que as expectativas serviço, clientes insatisfeitos,
iniciais.
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 Uma quantidade substancial de O que poderia levar a um
qualidade até o final do projeto.
trabalho
refeito
pode
ser deslize na data de entrega.
descoberto no final.
1-47
Houve três casos distintos em que o O que pode levar à falha no Causando uma perda de código
backup/mecanismo de recuperação de sistema de backup / mecanismo de de programação ou estruturas
desastre falhou. Embora esse sistema recuperação de desastres.
de dados e dados de testes
esteja sendo investigado, nenhuma
desenvolvidos até à data.
mudança ocorrerá antes que o projeto
atual será concluído.
1-48
Padrões ainda não concordaram com Apesar do fato de que novos Levando ao trabalho adicional
as tecnologias que estão sendo usadas. padrões podem surgir após a de projeto aderir mais tarde
conclusão do projeto.
aos novos padrões técnicos ou
da indústria.
Recursos
1-49
Reuniões não frequentes da comissão Podem
causar
atrasos
nas Resultando em atrasos de
de aprovação do capital.
aprovações de despesas de capital. 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
Exigindo trabalho adicional
duplicados.
para determinar quais obras
deverão ser concluídas.
1-51
Porque o fornecedor tem a intenção de Esses recursos podem não estar E a data de entrega prevista
usar os mesmos recursos em outros disponíveis quando antecipados.
pode ser perdida.
projetos.
1-52
Porque o fornecedor tem uma Novos recursos podem ter de ser O que poderia adicionar pelo
rotatividade significativa de equipe.
procurados e trazidos rápido menos um mês para o projeto e
durante o desenvolvimento.
possivelmente muito mais.
39
161
ID40
1-53
CAUSA
RISCO
EFEITO
Porque o fornecedor tem sido reduzido O fornecedor pode optar por O que pode envolver um atraso
por muitos anos e continua a fazê-lo.
transferir recursos entre seus substancial no cronograma
projetos.
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á Um progresso lento pode ocorrer. O que pode levar à falta de
devidamente treinada nas ferramentas
uma data para lançamento.
de desenvolvimento.
1-55
Devido à sobrecarga de um recurso Divulgação de informações vitais Conduzindo
a
decisões
crítico.
podem ser bloqueadas.
erradas.
1-56
Devido a um recurso crítico de nível O treinamento cruzado dos O que pode levar a uma equipe
mais antigo torna-se indisponível.
recursos de nível mais novo pode ineficaz.
não ocorrer.
1-57
Devido aos interessados em não Uma lacuna entre o que é crítico e Poderia levar a uma não
comprar.
o que não pode ocorrer.
decisão para o lançamento.
Escopo
1-58
Porque o fornecedor não criou, um Algumas funcionalidades
Resultando em horas extras de
protótipo de muitas das mudanças nas esperadas do cliente podem estar
última hora.
ligações do usuário.
completamente em falta e não
serem descobertas até o teste de
aceitação.
1-59
Porque o fornecedor tem planos de Confiança e escalabilidade ou Podem afetar o cronograma
substituir uma peça central da outros
problemas
técnicos para esta versão.
aplicação por um pacote de software imprevistos.
não identificado, ao mesmo tempo em
que
esta
versão
está
sendo
desenvolvida.
1-60
Porque o fornecedor tem um bom O fornecedor poderá fazer E ter que ser reimplantado.
entendimento
do
software
de suposições irregulares sobre a
aplicação, mas uma má compreensão lógica do negócio que poderiam
do negócio do cliente.
revelar-se erradas.
1-61
Porque a equipe de desenvolvimento Problemas detectados durante a Pode resultar em atrasos de
está em Maryland e o cliente está em codificação e testes da unidade.
atividades como questões de
San Diego.
lógica de negócios que são
discutidas por telefone.
1-62
Critérios de aceitação do projeto não O que poderia levar à dificuldade Resultando em um trabalho
são claros.
na obtenção de autorização em adicional que está além do
marcos importantes.
orçamento de custos.
Segurança
1-63
Devido à alta demanda de trabalho de O que pode conduzir a uma Atrasando o projeto a fim de
uma empresa, ela sofreu mais violação de segurança em uma garantir à gestão que não haja
violações de segurança que a maioria seção da empresa.
quebras de segurança em seu
das empresas.
projeto.
40
162
ID41
CAUSA
RISCO
EFEITO
Riscos com Fornecedor
Um projeto requer a participação de
Podem estar em risco se o
pequenos fornecedores de software em fornecedor de software for
uma economia em rápida mudança.
convencido pela empresa-mãe,
durante ou após as negociações da
compra de software.
1-64
1-65
Devido ao
fornecedores.
1-66
Devido aos fornecedores arraigados.
1-67
Desde que a segurança do fornecedor
do software não seja compatível com
as políticas da empresa.
1-68
Porque um fornecedor pode se fundir
com outro fornecedor.
Porque o fornecedor não tem uma
metodologia de projeto estabelecida.
1-69
1-70
grande
número
de
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.
Porque o fornecedor se refere ao
projeto como um “documento vivo” e
não tem nenhum processo formal de
controle de mudança.
Porque
o
fornecedor
tem
experimentado
enfraquecimento
financeiro há muitos anos.
1-71
1-72
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.
Rotatividade
da
equipe
e E fazer com que a conclusão
mudanças de pessoal podem de prazos seja tardia.
atrasar o projeto.
O projeto pode ter que usar O que pode atrasar o projeto
tecnologia mais antiga para o e/ou reduzir a qualidade do
desenvolvimento.
produto e o pedido adicional
de uma manuntenção não
planejada.
Desenvolvimento personalizado Pode ocorrer uma escapada nas
pode ser exigido e a complexidade datas de entrega com custos de
do
desenvolvimento
ainda customização aumentados ou
precisará ser especificada. Se a uma política de segurança
personalização
tornar-se pode
precisar
ser
excessivamente complexa.
comprometida.
Produtos podem não
estar Causando uma necessidade de
disponíveis.
reformular o projeto..
Existe um risco elevado em que O que poderia causar o
vários ciclos de projeto podem ser começo do desenvolvimento
requeridos antes da codificação tardio, levando a durações das
começar.
atividades
excessivamente
otimistas,
a
fim
de
proporcionar um destino final
aceitável ao cliente.
O que pode fazer com que um Levando a uma mudança na
fornecedor deixe de apoiar o arquitetura ou abordagem.
software.
Características podem ser
adicionadas mesmo que o cliente
prefira não tê-las.
O fornecedor, o qual é uma
divisão de uma empresa muito
maior, poderia ser vendido para
outra empresa.
1-73
Porque o fornecedor não conduz Elementos do projeto podem não
revisões internas do projeto.
ser descobertos até que o
desenvolvimento
seja
substancialmente completo.
41
Resultando em diminuição da
satisfação do cliente.
Causando
a
interrupção
substancial da equipe e dos
problemas incluindo horários
atendidos e recursos perdidos.
Causando trabalho refeito e/ou
retestes e escapadas do
cronograma.
163
ID42
1-74
1-75
1-76
1-77
CAUSA
Porque o fornecedor não tem
experiência com explicações passo-apasso de códigos ou de outras práticas
que reduzam os defeitos.
Porque a equipe do fornecedor não tem
nenhuma experiência anterior com
gerenciamento de risco formal.
RISCO
EFEITO
Vírus podem não ser detectados Aumentando o tempo e o custo
até que a instalação ocorra.
necessários
para
corrigir
qualquer vírus encontrado.
Porque o fornecedor não tem processo
formal para relacionar as mudanças de
aplicação no projeto esquemático do
banco de dados.
Porque o fornecedor utiliza apenas um
modelo em queda pura para o
desenvolvimento.
Exigindo trabalho refeito para
corrigir as deficiências.
Tecnologia
Porque o produto de software é
relativamente novo e a tecnologia de
projeto pode não ter sido comprovada.
Porque o produto de software nunca
foi implementado em uma plataforma
centralizada com o volume de dados
requeridos pelo cliente.
1-78
1-79
1-80
Porque o software a ser comprado está
na versão beta.
1-81
Devido a não ter um processo sólido
de gerenciamento objetivo.
1-82
Devido à extensão do projeto.
1-83
Devido à dificuldade das diversas
partes interessadas em chegar a um
consenso entre a padronização e a
variação local.
1-84
O projeto está sendo implementado em
duas
áreas
de
negócio
que
compartilham dados para tomada de
decisão.
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.
42
É altamente provável que soluções
poderiam ser utilizadas para os
problemas que poderiam ter sido
evitados
ou
mitigados
ou
transferidos para outro fornecedor.
Problemas no projeto do banco de
dados poderiam ser descobertos no
final
do
processo
de
desenvolvimento.
Oportunidades para a agilização
do projeto podem ser perdidas.
Resultando em baixa moral
e/ou perda de prazos e custos
mais
elevados
e
baixa
qualidade.
Vários lançamentos podem ser
necessários antes que o produto
esteja estável.
Não foi comprovado que o
produto pode ser escalado para o
tamanho necessário.
O que pode levar a defeitos
funcionais ou técnicos.
E conduzindo o sistema em uma
área de negócio pode causar uma
interrupção na outra área de
negócio.
Poderia introduzir ameaças críticas
no decorrer do projeto.
Impactando a sua capacidade
de
exercer
funções
empresariais básicas.
Assim sendo, não tendo
vantagens das economias de
tempo que poderiam advir para
o projeto.
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.
A data da versão de produção final E o aumento do número de
poderia não ser cumprida.
erros e vírus encontrados no
produto lançado.
Pode ocorrer desenvolvimento Causando trabalho adicional
gradual de objetivos.
ou trabalho refeito e usuários
insatisfeitos.
Aplicativos atuais podem ser
Diminuindo o impacto nos
funcionalmente obsoletos antes da negócios da implementação.
implementação se completar.
A eficácia da implementação pode Causando atrasos no projeto.
ser reduzida.
E possíveis atrasos.
164
ID43
1-86
1-87
CAUSA
RISCO
Implementação de um novo produto de O que pode causar atrasos e
software pode causar aumento da respostas inadequadas às questões
procura no atendimento por telefone.
e possível utilização de uma
equipe de implementação para
responder às perguntas.
A equipe de hardware está substituindo Mas se o prazo para a
os terminais por estações de trabalho. implementação de estação de
trabalho não for cumprido.
1-88
Por causa da qualidade inconsistente Dados impuros podem ser
de dados do sistema que foi legado.
convertidos para o novo sistema.
1-89
Devido ao treinamento insuficiente ou O sistema pode não ser
aceitação do usuário.
adequadamente utilizado.
1-90
Devido
a
um
ambiente
de Perda de código-fonte pode
desenvolvimento instável.
ocorrer.
Devido a uma má compreensão dos Um projeto inconsistente das
dados subjacentes.
aplicações pode ocorrer.
1-91
1-92
Devido à pobre arquitetura do sistema. Pode ocorrer a falha em cumprir as
métricas
de
desempenho
requeridas.
Devido a um lançamento longo de Avanços tecnológicos podem
servidores.
tornar os servidores ultrapassados
pela conclusão do projeto.
1-93
1-94
Porque alguns dos principais módulos
do aplicativo estão colidindo contra
um limite absoluto para o tamanho do
código fonte.
O cliente tem a garantia de que a nova
tecnologia irá atender às suas
necessidades.
1-95
Alguns módulos não podem ser
modificados conforme previsto.
EFEITO
Causando um atraso possível
aos lançamentos adicionais.
Equipamentos
provisórios
podem
precisar
ser
implementados ou o atraso do
projeto.
O que pode levar a uma clara
pós-conversão substancial ou
desconfiança do sistema pela
comunidade de usuários.
E pode resultar em falta de
dados acumulados para apoiar
os benefícios esperados.
O que levaria a uma
duplicação do trabalho.
O que levaria a um fracasso
completo em atender os
requisitos do negócio.
O que pode levar a uma
mudança significativa no
projeto do sistema..
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.
E
pode
ter
que
ser
reestruturados e/ou reescritos.
Mas pode haver falha para Isso pode causar custos
perceber os limites da tecnologia. adicionais para aquisição de
novas tecnologias quando
ocorrer a primeira falha.
1-96
Um novo sistema foi criado na E devido à resposta positiva O aplicativo pode falhar
demanda por usuários finais animados esmagadora do usuário para o quando mais usuários fazerem
por mais de um ano.
sistema.
login no sistema do que o
inicialmente previsto.
43
165
APÊNDICE III – Análise Semântica dos Fatores de Riscos
Este apêndice apresenta a análise semântica dos fatores de riscos realizada em cinco
etapas, conforme já mencionado na metodologia. A primeira etapa seria eliminar os fatores de
riscos citados por Mulcahy (2010) que sejam específicos para sistema de informação e não
para desenvolvimento de software. Durante esta análise ocorreram duas novas situações que
levaram à eliminação de alguns fatores de riscos. Na primeira situação encontrada foram
eliminados os fatores de riscos referentes a situações específicas de desenvolvimento de
software e que não serviriam, ou não poderiam ser generalizados, para outros casos de
desenvolvimento de software. Na segunda, foram eliminados os fatores de riscos cujo
entendimento não ficou claro. A Tabela 35 apresenta os fatores de riscos eliminados.
(2010)
ID
1-01
1-02
1-04
1-06
1-08
CAUSA
Fornecedor selecionado fará o tempo
de trabalho/materiais X a oferta fixa
usual.
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.
Porque um bom relacionamento com o
cliente não pode ser mantida.
RISCO
Portanto, temos a falta de
experiência em registros precisos
Os
objetivos
podem
se
desenvolver gradualmente.
Se existe falta de confiança.
EFEITO
Isso pode levar a custos sendo
cobrados incorretamente.
O que poderia levar ao atraso
do projeto e à um custo mais
caro.
O que pode exigir mais
reuniões e uma extra e
constante garantia.
Devido ao pouco esforço por parte do A equipe do cliente pode trabalhar O que pode resultar em metas
cliente para obter apoio para o projeto. ativamente contra o projeto.
do projeto não sendo atingidas
no prazo previsto, assim como,
informações importantes não
estando disponíveis.
Porque o cliente pretende reescrever o O cancelamento do projeto pode Causando um atraso no
aplicativo e trazê-lo à tona dentro de ocorrer.
cronograma de mais de dois
12 a 18 meses.
meses.
166
(2010) (Cont.)
ID
1-09
1-10
1-11
1-12
1-13
1-15
CAUSA
Pessoas de oito países estão
trabalhando neste projeto e a maioria
não está acostumada a trabalhar com
culturas diferentes.
O clima econômico atual tem muitas
mudanças no valor das moedas em uso
no projeto.
Pessoas de países conservadores estão
trabalhando neste projeto e a maioria
não está em sintonia com trabalhar
com culturas diferentes.
Devido a problemas com a imigração.
RISCO
O
que
pode
causar
interpretação do idioma
problemas culturais
EFEITO
má Resultando em baixa moral e a
ou necessidade de aumentar o
treinamento e a construção de
equipe.
O que pode causar uma grande Aparecendo riscos de custos
oscilação no valor do dólar
adicionais.
O que pode causar uma mudança Resultando em atividade ilegal
nas leis internas e estrangeiras ou inadvertida
leis falhas.
Um ou mais membros da equipe
itinerante do projeto pode se
atrasar ou não ter permissão para
prosseguir.
Devido às obrigações e restrições Chave
de
software
ou
aduaneiras.
equipamento pode ser atrasada no
transporte.
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.
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.
atraso para o projeto.
Devido
à
comerciais.
1-17
Devido à baixa disponibilidade de Os membros da equipe itinerante
voos.
do projeto podem não estar
disponíveis para uma semana
inteira de trabalho.
Devido à aquisição/compra de Pode haver incompatibilidade.
hardware a partir de várias fontes
atraso para o projeto quanto a
internacionais.
obtenção do componente(s)
corretos.
A definição de papéis e O que pode resultar em falhas
responsabilidades para a equipe do para selecionar os melhores
projeto não podem ser plenamente recursos.
compreendidas.
Devido ao terrorismo.
Instalações podem ser danificadas Resultando em um atraso para
ou membros da equipe podem ser o projeto e/ou aumento do
mortos ou seqüestrados.
custo.
A falta de financiamento tem O que pode causar uma exaustão Causando a exaustão da equipe
provocado uma semana obrigatória de rápida
na
equipe
para e a saída do projeto.
50 horas extras por mês com adicional desempenhar essa
habilidade
de 50 horas sendo muito comum.
industrial de alta demanda.
Devido a nenhuma informação escrita Coleta de dados em tempo Resultando em menor tempo
sobre projetos passados.
adicional pode ser necessária.
gasto na
conclusão dos
trabalhos.
Devido à gestão anunciando que a Empregados podem adiar seu Causando atrasos no projeto ou
entrega de um produto estará liberada trabalho atual e um outro projeto insatisfação com a gestão ou a
em uma determinada data.
pode ser iniciado para atender a perda de motivação e de
esse prazo.
trabalho adicional refeito uma
vez que o prazo de entrega foi
cumprido.
1-20
1-22
1-24
1-25
1-27
práticas O sistema escolhido para as
operações norte-americanas pode
não ser adequada para as unidades
de negócios internacionais.
atraso no projeto.
1-16
1-18
diferentes
O que pode causar um atraso
no projeto.
167
(2010) (Cont.)
ID
1-28
1-29
1-31
1-35
1-36
1-37
1-38
1-39
1-40
1-41
1-42
1-43
CAUSA
RISCO
Devido à existência de um projeto Nem todas as áreas de negócio
separado e equipes de implementação. estão envolvidos na determinação
dos objetivos de trabalho para o
projeto.
Devido à existência de um projeto Parte do projeto pode não ser
separado e equipes de implementação, capaz de ser implementado no
e porque a equipe de implementação mundo real.
não tem sido capaz de se pronunciar
sobre o projeto.
Porque não há nenhum plano Problemas
graves
podem
compreensivo de gerenciamento de permanecer em um nível inferior
comunicações.
da responsabilidade do projeto do
que deveriam.
Porque não há um plano de Problemas são susceptíveis de
gerenciamento de qualidade.
serem descobertos e resolvidos
depois do teste, ao invés de serem
resolvidos no início do ciclo de
desenvolvimento de vida.
Porque muitas das regras para reforçar Algumas linhas da tabela podem
a integridade referencial no banco de ser
mudadas
ou
deletadas
dados são, na verdade, implementadas incorretamente.
no código do aplicativo.
Porque o fornecedor confia totalmente A ligação pode não ser concebida
no cliente para muitas decisões do tão bem como deveria ser.
projeto (por exemplo: navegação de
página na web).
Porque o documento do projeto se Pelo menos uma regra de negócio
refere a números específicos (exemplo: pode ser mal implementada ou
0-120 dias), sem explicar as relações uma dependência inapropriada
entre os números.
pode ser criada.
Porque o fornecedor não tem meios Recursos existentes que poderiam
para avaliar o impacto de desempenho compartilhar código com novos
antes de o software ser implantado.
recursos podem não fazê-lo.
Porque esta relação fornecedor / Este projeto pode encontrar a
cliente e esta aplicação tem uma mesma pressão para os ciclos de
história
de
programas
de testes reduzidos.
desenvolvimento de ultrapassagem,
resultando
em
sistemas
significativamente encurtados e testes
de aceitação.
Por motivo das versões anteriores O fornecedor pode concluir que
terem tido um número elevado de vírus isso é aceitável para o cliente.
e recursos mal implementados.
EFEITO
O que pode resultar no sistema
não ser capaz de abordar todos
os requisitos do negócio.
Levando à uma mudança tardia
de objetivos no projeto.
Atrasando o projeto e aumento
do estresse em ambas as
equipes, do cliente e do
fornecedor.
Resultando em um potencial
para uma versão com vírus
significativos conhecidos.
Resultando (no melhor caso)
em trabalho refeito e (no pior
caso) na perda de dados do
cliente.
Redução da satisfação do
cliente.
De tal forma que o pedido
pode não se comportar como
deveria.
Resultando em tempos de
resposta mais lentos do
usuário.
Resultando em um produto
implantado
de
qualidade
inferior à desejada.
E falhar para melhorar os
processos que podem ser
mostrados
para
causar
resultados tão pobres.
Devido às mudanças do mercado ou O patrocinador/origem de fundos O que pode levar a um projeto
outras prioridades.
pode esgotar-se de dinheiro ou se abandonado e/ou
recusar a continuar a financiar.
impossibilidade de entregar
todas as funcionalidades.
Devido aos processos ruins ou outros Dados históricos podem ser O que levaria à saída do
problemas.
imprecisos ou poluídos.
sistema ruim e/ou diminuição
na qualidade dos prazos e uma
baixa aceitação do usuário.
168
(2010) (Cont.)
1-44
ID
CAUSA
Devido à má comunicação
treinamento ou gerenciamento.
1-45
Devido ao planejamento ruim.
1-46
Devido ao adiamento da garantia de
qualidade até o final do projeto.
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.
Padrões ainda não concordaram com Apesar do fato de que novos Levando ao trabalho adicional
as tecnologias que estão sendo usadas. padrões podem surgir após a de projeto aderir mais tarde
conclusão do projeto.
aos novos padrões técnicos ou
da indústria.
Reuniões não frequentes da comissão Podem
causar
atrasos
nas Resultando em atrasos de
de aprovação do capital.
aprovações de despesas de capital. aquisição de hardware de
computador para teste e
instalação
de
produção,
resultando em atrasos no
projeto.
Devido à equipe não estar arranjada.
Alguns trabalhos podem ser
Exigindo trabalho adicional
duplicados.
para determinar quais obras
deverão ser concluídas.
Porque o fornecedor tem a intenção de Esses recursos podem não estar E a data de entrega prevista
usar os mesmos recursos em outros disponíveis quando antecipados.
pode ser perdida.
projetos.
Porque o fornecedor tem uma Novos recursos podem ter de ser O que poderia adicionar pelo
rotatividade significativa de equipe.
procurados e trazidos rápido menos um mês para o projeto e
durante o desenvolvimento.
possivelmente muito mais.
Porque o fornecedor tem sido reduzido O fornecedor pode optar por O que pode envolver um atraso
por muitos anos e continua a fazê-lo.
transferir recursos entre seus substancial no cronograma
projetos.
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).
Devido à sobrecarga de um recurso Divulgação de informações vitais Conduzindo
a
decisões
crítico.
podem ser bloqueadas.
erradas.
Devido a um recurso crítico de nível O treinamento cruzado dos O que pode levar a uma equipe
mais antigo torna-se indisponível.
recursos de nível mais novo pode ineficaz.
não ocorrer.
1-48
1-49
1-50
1-51
1-52
1-53
1-55
1-56
RISCO
ou O sistema pode funcionar como
necessário, mas as mudanças de
processos que precisam ocorrer
podem não acontecer.
O volume de usuários/dados pode
ser maior do que as expectativas
iniciais.
EFEITO
Resultando em baixa aceitação
do usuário e impacto negativo
na percepção do sistema e
equipe de projeto.
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.
Uma quantidade substancial de O que poderia levar a um
trabalho
refeito
pode
ser deslize na data de entrega.
descoberto no final.
O que pode levar à falha no Causando uma perda de código
sistema de backup / mecanismo de de programação ou estruturas
recuperação de desastres.
de dados e dados de testes
desenvolvidos até à data.
169
(2010) (Cont.)
ID
1-57
1-59
1-61
1-63
1-64
CAUSA
Devido aos interessados em não
comprar.
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.
Porque a equipe de desenvolvimento
está em Maryland e o cliente está em
San Diego.
Devido à alta demanda de trabalho de
uma empresa, ela sofreu mais
violações de segurança que a maioria
das empresas.
Um projeto requer a participação de
pequenos fornecedores de software em
uma economia em rápida mudança.
1-66
Devido aos fornecedores arraigados.
1-67
Desde que a segurança do fornecedor
do software não é compatível com as
políticas da empresa.
1-68
Porque um fornecedor pode se fundir
com outro fornecedor.
Porque o fornecedor não tem uma
metodologia de projeto estabelecida.
1-69
1-70
1-71
RISCO
Uma lacuna entre o que é crítico e
o que não pode ocorrer.
Confiança e escalabilidade ou
outros
problemas
técnicos
imprevistos.
EFEITO
Poderia levar a uma não
decisão para o lançamento.
Podem afetar o cronograma
para esta versão.
Problemas detectados durante a Pode resultar em atrasos de
codificação e testes da unidade.
atividades como questões de
lógica de negócios que são
discutidas por telefone.
O que pode conduzir a uma Atrasando o projeto a fim de
violação de segurança em uma garantir à gestão que não seja
seção da empresa.
quebras de segurança em seu
projeto.
Podem estar em risco se o Resultando na pausa do
fornecedor de software for projeto, ou outros, produtos
convencido pela empresa-mãe, menos
perfeitamente
durante ou após as negociações da adaptados a serem adquiridos,
compra de software.
ao invés, ou o projeto que está
sendo adiado devido às
mudanças nas negociações de
contrato.
O projeto pode ter que usar O que pode atrasar o projeto
tecnologia mais antiga para o e/ou reduzir a qualidade do
desenvolvimento.
produto e o pedido adicional
de uma manuntenção não
planejada.
Desenvolvimento personalizado Pode ocorrer uma escapada nas
pode ser exigido e a complexidade datas de entrega com custos de
do
desenvolvimento
ainda customização aumentados ou
precisará ser especificada. Se a uma política de segurança
personalização
tornar-se pode
precisar
ser
excessivamente complexa.
comprometida.
Produtos podem não
estar Causando uma necessidade de
disponíveis.
reformular o projeto..
Existe um risco elevado em que O que poderia causar o
vários ciclos de projeto podem ser começo do desenvolvimento
requeridos antes da codificação tardio, levando a durações das
começar.
atividades
excessivamente
otimistas,
a
fim
de
proporcionar um destino final
aceitável ao cliente.
O que pode fazer com que um Levando a uma mudança na
fornecedor deixe de apoiar o arquitetura ou abordagem.
software.
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.
Porque o fornecedor se refere ao Características podem ser
projeto como um “documento vivo” e adicionadas mesmo que o cliente
não tem nenhum processo formal de prefira não tê-las.
controle de mudança.
Resultando em diminuição da
satisfação do cliente.
170
(2010) (Cont.)
ID
1-72
1-73
1-74
1-75
1-77
CAUSA
RISCO
Porque
o
fornecedor
tem O fornecedor, o qual é uma
experimentado
enfraquecimento divisão de uma empresa muito
financeiro há muitos anos.
maior, poderia ser vendido para
outra empresa.
Porque o fornecedor não conduz Elementos do projeto podem não
revisões internas do projeto.
ser descobertos até que o
desenvolvimento
seja
substancialmente completo.
Porque o fornecedor não tem Vírus podem não ser detectados
experiência com explicações passo-a- até que a instalação ocorra.
passo de códigos ou de outras práticas
que reduzam os defeitos.
Porque a equipe do fornecedor não tem É altamente provável que soluções
nenhuma experiência anterior com poderiam ser utilizadas para os
gerenciamento de risco formal.
problemas que poderiam ter sido
evitados
ou
mitigados
ou
transferidos para outro fornecedor.
Porque o fornecedor utiliza apenas um Oportunidades para a agilização
modelo em queda pura para o do projeto podem ser perdidas.
desenvolvimento.
1-79
Porque o produto de software nunca Não foi comprovado que o
foi implementado em uma plataforma produto pode ser escalado para o
centralizada com o volume de dados tamanho necessário.
requeridos pelo cliente.
1-80
Porque o software a ser comprado está A data da versão de produção final
na versão beta.
poderia não ser cumprida.
1-81
Devido a não ter um processo sólido Pode ocorrer desenvolvimento
de gerenciamento objetivo.
gradual de objetivos.
1-82
Devido à extensão do projeto.
1-83
1-84
1-85
EFEITO
Causando
a
interrupção
substancial da equipe e dos
problemas incluindo horários
atendidos e recursos perdidos.
Causando trabalho refeito e/ou
retestes e escapadas do
cronograma.
Aumentando o tempo e o custo
necessários
para
corrigir
qualquer vírus encontrado.
Resultando em baixa moral
e/ou perda de prazos e custos
mais
elevados
e
baixa
qualidade.
Assim sendo, não tendo
vantagens das economias de
tempo que poderiam advir para
o projeto.
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.
E o aumento do número de
erros e vírus encontrados no
produto lançado.
Causando trabalho adicional
ou trabalho refeito e usuários
insatisfeitos.
Diminuindo o impacto nos
negócios da implementação.
Aplicativos atuais podem ser
funcionalmente obsoletos antes da
implementação se completar.
Devido à dificuldade das diversas A eficácia da implementação pode Causando atrasos no projeto.
partes interessadas em chegar a um ser reduzida.
consenso entre a padronização e a
variação local.
O projeto está sendo implementado em E conduzindo o sistema em uma Impactando a sua capacidade
duas
áreas
de
negócio
que área de negócio pode causar uma de
exercer
funções
compartilham dados para tomada de interrupção na outra área de empresariais básicas.
decisão.
negócio.
O projeto de desenvolvimento do Poderia introduzir ameaças críticas E possíveis atrasos.
software se baseia em dados no decorrer do projeto.
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.
171
(2010) (Cont.)
ID
1-86
1-87
CAUSA
RISCO
Implementação de um novo produto de O que pode causar atrasos e
software pode causar aumento da respostas inadequadas às questões
procura no atendimento por telefone.
e possível utilização de uma
equipe de implementação para
responder às perguntas.
A equipe de hardware está substituindo Mas se o prazo para a
os terminais por estações de trabalho. implementação de estação de
trabalho não for cumprido.
1-88
Por causa da qualidade inconsistente Dados
impuros
pode
ser
de dados do sistema que foi legado.
convertidos para o novo sistema.
1-89
Devido ao treinamento insuficiente ou O sistema pode não ser
aceitação do usuário.
adequadamente utilizado.
1-91
Devido a uma má compreensão dos Um projeto inconsistente
dados subjacentes.
aplicações pode ocorrer.
1-92
Devido à pobre arquitetura do sistema. Pode ocorrer a falha em cumprir as
métricas
de
desempenho
requeridas.
Devido a um lançamento longo de Avanços tecnológicos podem
servidores.
tornar os servidores ultrapassados
pela conclusão do projeto.
1-93
1-94
1-95
1-96
Porque alguns dos principais módulos
do aplicativo estão colidindo contra
um limite absoluto para o tamanho do
código fonte.
O cliente tem a garantia de que a nova
tecnologia irá atender às suas
necessidades.
das
Alguns módulos não podem ser
modificados conforme previsto.
EFEITO
Causando um atraso possível
aos lançamentos adicionais.
Equipamentos
provisórios
podem
precisar
ser
implementados ou o atraso do
projeto.
O que pode levar à uma clara
pós-conversão substancial ou
desconfiança do sistema pela
comunidade de usuários.
E pode resultar em falta de
dados acumulados para apoiar
os benefícios esperados.
O que levaria a um fracasso
completo em atender os
requisitos do negócio.
O que pode levar a uma
mudança significativa no
projeto do sistema..
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.
E
pode
ter
que
ser
reestruturados e/ou reescritos.
Mas pode haver falha para Isso pode causar custos
perceber os limites da tecnologia. adicionais para aquisição de
novas tecnologias quando
ocorrer a primeira falha.
Um novo sistema foi criado na E devido à resposta positiva O aplicativo pode falhar
demanda por usuários finais animados esmagadora do usuário para o quando mais usuários fazerem
por mais de um ano.
sistema.
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
1-03
1-05
1-07
1-14
1-19
1-21
1-23
1-26
1-30
1-32
1-33
1-34
1-54
1-58
CAUSA
RISCO
Porque há resistência entre os usuários Pode haver sabotagem.
ao substituir a sua aplicação de
software atual por um novo aplicativo
de software/ sistema.
Porque o fornecedor é dependente do Os dados podem não estar
cliente para dados de teste.
disponíveis logo que necessário.
EFEITO
O que resultaria em um atraso
do projeto.
Fazendo testes começarem
mais tarde do que deveriam
para atender a devida data
solicitada
com
qualidade
adequada.
Oportunidades para uma solução Fazendo com que o cliente e os
mais satisfatória poderia ser clientes deles aceitem a
perdida.
funcionalidade
reduzida
desnecessariamente
Porque o cliente é completamente
dependente do fornecedor para
conhecimento
técnico
sobre
a
aplicação de software e ferramentas de
software subjacente.
Devido às diferenças de horários de Toda a equipe do projeto pode não
férias e/ou feriados.
estar disponível em determinadas
épocas.
Devido à comunicação ruim por e-mail As comunicações chaves pode ser
ou voz (entrega lenta ou baixa atrasadas.
qualidade) a nível internacional.
Devido à incompreensão das leis Procedimentos
inadequados
trabalhistas
e
regulamentos podem ser seguidos.
internacionais.
O gerente de projeto pode não
comunicar adequadamente os
requisitos ou programações aos
membros da equipe.
Devido à uma reorganização.
As pessoas podem gastar tempo
discutindo
o
efeito
da
reorganização.
Devido à existência de dois projetos Pode haver uma falta de
colaborativos.
coordenação entre os projetos.
Nem a administração nem as vendas O que pode significar que o cliente
disseram ao cliente que algumas de pode não ajustar as exigências.
suas exigências podem não ser
cumpridas dentro do prazo.
Os membros da equipe estão
espalhados por todo o país.
O
tempo
de
avaliação
para
ferramentas/métodos é menor do que a
empresa já teve que lidar no passado.
Fazendo com que o trabalho
seja refeito.
declínio do projeto.
O que pode resultar em atraso
da disponibilidade de recursos.
O que pode resultar em
atraso para o projeto
diminuição da qualidade
sistema.
Resultando no atraso
projeto.
um
ou
do
do
Causando desalinhamento de
Resultando em menor lucro no
projeto enquanto a equipe
soma as exigências usando as
adicionais não incluídos na
proposta original.
O que pode causar um sofrimento Resultando em produtividade
na comunicação.
sendo sacrificada.
Embora este calendário foi Resultando em atrasos.
aprovado pela administração, a
realidade de prazos pode não ser
adequada.
Um progresso lento pode ocorrer. O que pode levar à falta de
uma data para lançamento.
Devido à ter uma equipe que não está
devidamente treinada nas ferramentas
de desenvolvimento.
Porque o fornecedor não criou um Algumas
funcionalidades Resultando em horas extras de
protótipo de muitas das mudanças nas esperadas do cliente podem estar última hora.
ligações do usuário.
completamente em falta e não
serem descobertas até o teste de
aceitação.
173
Tabela 36: Fatores de Riscos de desenvolvimento de software citados por Mulcahy (2010)
(Cont.)
ID
1-60
1-62
CAUSA
Porque o fornecedor tem um bom
entendimento
do
software
de
aplicação, mas uma má compreensão
do negócio do cliente.
Critérios de aceitação do projeto não
são claros.
1-65
Devido ao
fornecedores.
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.
Porque o produto de software é
relativamente novo e a tecnologia de
projeto pode não ter sido comprovada.
Devido
a
um
ambiente
de
desenvolvimento instável.
1-78
1-90
grande
número
de
RISCO
O fornecedor poderá fazer
suposições irregulares sobre a
lógica do negócio que poderiam
revelar-se erradas.
O que poderia levar à dificuldade
na obtenção de autorização em
marcos importantes.
Rotatividade
da
equipe
e
mudanças de pessoal podem
atrasar o projeto.
Problemas no projeto do banco de
dados poderiam ser descobertos no
final
do
processo
de
desenvolvimento.
Vários lançamentos podem ser
necessários antes que o produto
esteja estável.
Perda de código-fonte pode
ocorrer.
EFEITO
E ter que ser reimplantado.
Resultando em um trabalho
adicional que está além do
orçamento de custos.
E fazer com que a conclusão
de prazos seja tardia.
Exigindo trabalho refeito para
corrigir as deficiências.
O que pode levar a defeitos
funcionais ou técnicos.
O que levaria a
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)
ID
1-03
1-05
CAUSA
Porque há resistência
entre os usuários ao
substituir
a
sua
aplicação de software
atual por um novo
aplicativo de software/
sistema.
Porque o fornecedor é
dependente do cliente
para dados de teste.
RISCO
Pode haver sabotagem.
Webster (2005)
EFEITO
O que resultaria em um
atraso do projeto.
ID
2-50
Os dados podem não estar Fazendo
testes
disponíveis
logo
que começarem mais tarde
necessário.
do que deveriam para
atender a devida data
solicitada
com
qualidade adequada.
Fonte: Mulcahy (2010) e Webster (2005) adaptado pelo autor
2-12
uma
174
Tabela 37: Fatores de Riscos considerados duplicados (Cont.)
Mulcahy (2010)
ID
1-07
1-14
1-19
1-21
1-23
CAUSA
Porque o cliente é
completamente
dependente
do
fornecedor
para
conhecimento técnico
sobre a aplicação de
software e ferramentas
de software subjacente.
Devido às diferenças de
horários de férias e/ou
feriados.
Devido à comunicação
ruim por e-mail ou voz
(entrega lenta ou baixa
qualidade)
a
nível
internacional.
Devido
à
incompreensão das leis
trabalhistas
e
regulamentos
internacionais.
Devido às diferenças de
idiomas.
RISCO
EFEITO
Oportunidades para uma Fazendo com que o
solução mais satisfatória cliente e os clientes
poderia ser perdida.
deles
aceitem
a
funcionalidade reduzida
desnecessariamente
Toda a equipe do projeto
pode não estar disponível
em determinadas épocas.
As comunicações chaves
pode ser atrasadas.
O gerente de projeto pode
não
comunicar
adequadamente
os
requisitos ou programações
aos membros da equipe.
As pessoas podem gastar
tempo discutindo o efeito
da reorganização.
Pode haver uma falta de
coordenação
entre
os
projetos.
O que pode significar que o
cliente pode não ajustar as
exigências.
Devido
à
reorganização.
1-30
Devido à existência de
dois
projetos
colaborativos.
Nem a administração
nem as vendas disseram
ao cliente que algumas
de suas exigências
podem
não
ser
cumpridas dentro do
prazo.
Os membros da equipe O que pode causar um
estão espalhados por sofrimento na comunicação.
todo o país.
1-33
1-34
Fazendo com que o
trabalho seja refeito.
ID
(REESCREVER: 2-46
incluindo problema de
dependência técnica)
2-22
um declínio do projeto.
Procedimentos inadequados O que pode resultar em
podem ser seguidos.
atraso
da
disponibilidade
de
recursos.
1-26
1-32
uma
Webster (2005)
2-48
um atraso para o projeto
ou
diminuição
da
qualidade do sistema.
Resultando no atraso do
projeto.
2-22
Causando
2-28
desalinhamento
de
Resultando em menor
2-46
lucro
no
projeto
enquanto a equipe soma
as exigências usando as
adicionais não incluídos
na proposta original.
Resultando
em (REESCREVER: 2-37
produtividade
sendo incluindo problema de
sacrificada.
comunicação do item 133)
Embora este calendário foi Resultando em atrasos.
2-42
aprovado
pela
administração, a realidade
de prazos pode não ser
adequada.
O tempo de avaliação
para
ferramentas/métodos é
menor do que a
empresa já teve que
lidar no passado.
175
Tabela 37: Fatores de Riscos considerados duplicados (Cont.)
Mulcahy (2010)
ID
1-54
1-60
1-62
1-65
1-76
1-78
1-90
CAUSA
Devido à ter uma
equipe que não está
devidamente treinada
nas ferramentas de
desenvolvimento.
Porque o fornecedor
tem
um
bom
entendimento
do
software de aplicação,
mas
uma
má
compreensão
do
negócio do cliente.
Critérios de aceitação
do projeto não são
claros.
Webster (2005)
RISCO
EFEITO
Um progresso lento pode O que pode levar à falta
ocorrer.
de uma data para
lançamento.
ID
2-40
O fornecedor poderá fazer E
ter
que
suposições irregulares sobre reimplantado.
a lógica do negócio que
poderiam revelar-se erradas.
ser
2-04
Resultando em um
trabalho adicional que
está além do orçamento
de custos.
E fazer com que a
conclusão de prazos seja
tardia.
Exigindo
trabalho
refeito para corrigir as
deficiências.
2-03
O que poderia levar à
dificuldade na obtenção de
autorização em marcos
importantes.
Rotatividade da equipe e
mudanças de pessoal podem
atrasar o projeto.
Problemas no projeto do
banco de dados poderiam
ser descobertos no final do
processo
de
desenvolvimento.
Devido
ao
grande
número
de
fornecedores.
Porque o fornecedor não
tem processo formal
para
relacionar
as
mudanças de aplicação
no projeto esquemático
do banco de dados.
Porque o produto de Vários lançamentos podem O que pode levar a
software é relativamente ser necessários antes que o defeitos funcionais ou
novo e a tecnologia de produto esteja estável.
técnicos.
projeto pode não ter
sido comprovada.
Devido a um ambiente Perda de código-fonte pode O que levaria a uma
de
desenvolvimento ocorrer.
instável.
2-45
2-32
2-11
2-31
A terceira etapa seria a integração dos fatores de riscos dos autores, agrupando os
fatores de risco considerados semelhantes semanticamente. Um desafio nessa etapa seria a
descrição do fator de risco, levando-se em conta que os autores escreveram de forma
diferente. Diante disso e para manter uma mesma lógica ou linha de raciocínio, proceder-se-ia
a utilização dos fatores de risco do SEI (Tabela 16), seguindo o mesmo critério adotado por
Webster (2005).
Para os fatores de riscos considerados semelhantes semanticamente foi mantida a
redação sugerida por Webster (2005) por já ter sido realizado um estudo de diversos autores.
Conforme já citado anteriormente, quando a coluna 5 (Tabela 37) estiver em branco
significa que não foi identificada duplicação ou semelhança entre os fatores de riscos de
176
Mulcahy (2010) (Tabela 36) e Webster (2005) (Tabela 18). Para estes casos foi feita uma
redação unificando os textos das colunas 3, 4 e 5 (Tabela 37).
Os fatores de riscos 1-19 e 1-23 foram agrupados em um único fator de risco por tratar
de assuntos semelhantes. A nova redação é: Qualquer problema de comunicação em nível
internacional relativo a diferenças de idiomas.
O fator de risco 2-46 foi reescrito incluindo o fator de risco 1-07 em sua redação.
O fator de risco 2-37 foi reescrito incluindo o fator de risco 1-33 em sua redação.
A Tabela 38 apresenta a integração dos fatores de riscos para desenvolvimento de
software dos autores Webster (2005) e Mulcahy (2010), considerados semelhantes
semanticamente. Na primeira coluna ID aparece o identificador do fator de risco e na segunda
coluna a descrição do fator de risco integrado.
Tabela 38: Fatores de Riscos integrados para desenvolvimento de software
ID
01
02
03
04
05
06
07
08
09
10
Requisitos mal entendidos (não refletem as expectativas do cliente).
Adição de mais funcionalidades que o especificado / dar extras ao cliente.
Requisitos de desempenho não atendidos. Ex. Baixo desempenho.
Problemas de desempenho de tempo real (há tempos de respostas restritos).
Restrições referentes ao hardware designado. Ex.: capacidade de memória e tempo de
resposta real, acesso à base de dados e insuficiência de hardware.
11
Tecnologia nova / imatura (uso de novas tecnologias).
12
Inadequada preparação e realização dos testes. Ex.: instalações inadequadas, e tempo
insuficiente para realização dos testes, falta de dados precisos para testar as mudanças e
13
Falta de um acordo interativo entre os clientes e os desenvolvedores relativo às
especificações dos requisitos.
14
Inadequadas especificações. Ex.: especificações de sistema, hardware, software, interface,
requisitos de teste a qualquer nível com respeito à viabilidade de implementação e à
estabilidade dos atributos de qualidade, completude e clareza.
15
Modelos, processos, métodos e ferramentas de apoio selecionados inadequados para o
processo de desenvolvimento.
16
Falta / insuficiência de controle do processo de desenvolvimento. Ex.: uso do recurso,
medição do progresso referente à qualidade e metas de produtividade.
17
Controle do produto inadequado. Ex.: o produto final não corresponde às expectativas do
cliente.
18
Documentação / papelada excessiva.
19
Capacidade insuficiente do sistema desenvolvido. Ex.: Falta de estações de trabalho, espaço
de armazenamento no banco de dados insuficiente.
20
Pouca confiança no desenvolvimento do sistema devido à indisponibilidade / erro / mal
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
22
23
24
25
26
27
28
29
Planejamento inapropriado, incluindo construção e atualização do plano de contingência.
Papéis e responsabilidades de relacionamentos mal definidos ou mal entendidos.
Gerentes do desenvolvimento do software inexperientes ou ineficientes.
Fraca interação (comunicação) do gerente com todos os envolvidos do projeto.
Falhas em gerenciar as expectativas do usuário final.
Ausência de um líder.
Falta de metodologia efetiva de gerenciamento de projetos.
Fraco monitoramento do progresso das atividades relacionadas ao projeto. Ex.:
acompanhamento do relatório de status e manutenção de métricas progressivas.
30
Treinamento inadequado ou indisponível.
31
Falta de procedimentos, programas adequados e recursos para assegurar a garantia da
qualidade.
32
Gerência de Configuração inadequada.
33
Mudanças contínuas no objetivo e escopo do projeto.
34
Erro ao estimar (tempo, custo e esforço).
35
Métricas inadequadas / inexatas.
36
Falta espírito de equipe. Os conflitos requerem intervenção da gerência.
37
Problema de comunicação devido à falta de conhecimento da missão, metas do projeto,
informações técnicas entre pares e gerentes e devido a distância (membros da equipe
38
Baixa moral/ falta de compromisso devido ao baixo nível de entusiasmo afetando assim a
produtividade e criatividade. As pessoas não se sentem reconhecidas e recompensadas pelos
superiores.
39
Falta de maturidade / instabilidade organizacional.
40
Baixa produtividade da equipe.
41
Cronograma irreal ou inadequado baseado nos eventos internos e externos do sistema.
42
Pressão excessiva de prazo.
43
Problemas de pessoal. Ex.: falta experiência, pouco conhecimento, falta de habilidade, falta
de pessoal e indisponibilidade de pessoas chaves.
44
Orçamento insuficiente ou instável baseado nos eventos internos e externos do sistema.
45
Instabilidade (rotatividade) e falta de continuidade das pessoas nos projetos.
46
Qualquer problema com o cliente, tais como: demora na aprovação de documentos,
comunicação pobre, resistência à mudança, falta de comprometimento, falta de cooperação,
conflitos entre clientes e departamentos, dependência técnica.
47
Problemas relacionados aos contratos associados.
48
Qualquer problema associado a subcontratação.
49
Fatores políticos (companhia, clientes, contratantes associados e subcontratantes) que
causam problemas para o desenvolvimento do projeto.
50
Qualquer problema com o usuário, tais como: falta de envolvimento / comprometimento,
conflito entre usuários e departamentos, falta de entendimento com relação ao
funcionamento do sistema, resistência a mudanças e falha em obter o comprometimento do
usuário.
51
Falta de comprometimento da gerência sênior
52
Qualquer problema de comunicação em nível internacional relativo a diferenças de idiomas.
Fonte: Adaptado de Webster (2005) e Mulcahy (2010).
178
APÊNDICE IV - Análise dos fatores de riscos segundo as empresas pesquisadas.
Neste apêndice são apresentadas as respostas referentes à Parte IV do roteiro de análise
de riscos, segundo as empresas pesquisadas.
Para manter o sigilo das empresas pesquisadas, a pedido delas, estas serão identificadas
como empresas: A, B, C, D, E e F, conforme definido no Capítulo 4 deste trabalho.
4
Adição de mais funcionalidades que o especificado
/ dar extras ao cliente.
Requisitos de desempenho não atendidos. Ex.
Baixo desempenho.
5
6
7
11
33
x
5
1
1
1
3
15
x
5
1
1
1
3
15
x
5
1
2
1
4
20
x
3
3
4
3
10
30
x
4
4
4
4
12
48
3
4
4
4
12
36
x
1
1
4
1
6
6
x
2
3
4
3
10
20
x
2
3
4
3
10
20
3
4
4
4
12
36
x
x
x
8
inadequada.
9 Problemas de desempenho de tempo real (há
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
tecnologias).
44
CLASSIFICAÇÃO
TOTAL
3
x
x
Outra: “Avaliação pós-encerramento”. Fase utilizada somente pela empresa “F”.
6.Outra:
44
4
5.Encerramento
4
2.Planejamento
Prazo
3
x
Qualidade
x
Custo
2
4.Monitor. / Controle
1
IMPACTO
3
1.Iniciação
ID
3.Execução
FASES do Ciclo de Vida
PROBABILIDADE
Tabela 39: Análise dos fatores de riscos segundo a empresa “A”
179
x
x
6
18
3
3
4
4
11
33
3
4
4
3
11
33
2
1
4
4
9
18
3
3
4
3
10
30
1
4
4
4
12
12
x
2
2
3
3
8
16
x
1
5
5
4
14
14
x
2
5
5
4
14
28
x
1
5
5
3
13
13
x
3
3
4
3
10
30
1
3
3
5
11
11
3
4
4
4
12
36
x
x
x
x
x
x
x
x
20 Pouca confiança no desenvolvimento do sistema
devido à indisponibilidade / erro / mal
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.
22 Planejamento inapropriado, incluindo construção e
atualização do plano de contingência.
23 Papéis e responsabilidades de relacionamentos mal
x
definidos ou mal entendidos.
x
x
x
x
CLASSIFICAÇÃO
2
x
6.Outra:
45
3
5.Encerramento
TOTAL
1
x
19 Capacidade insuficiente do sistema desenvolvido.
Ex.: Falta de estações de trabalho, espaço de
armazenamento no banco de dados insuficiente.
45
Prazo
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.
17 Controle do produto inadequado. Ex.: o produto
final não corresponde às expectativas do cliente.
3
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.
15 Os modelos, processos, métodos e ferramentas de
apoio selecionados inadequados para o processo de
desenvolvimento.
Qualidade
13 Falta de um acordo interativo entre os clientes e os
desenvolvedores relativo às especificações dos
requisitos.
IMPACTO
Custo
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.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
Tabela 39: Análise dos fatores de riscos segundo a empresa “A” (Cont.)
180
x
x
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.
5
5
15
30
x
3
3
4
3
10
30
1
5
5
4
14
14
4
3
3
5
11
44
2
3
2
3
8
16
1
1
3
1
5
5
x
2
4
3
3
10
20
x
2
4
4
4
12
24
x
3
4
2
3
9
27
x
4
4
3
5
12
48
4
3
3
4
10
40
x
x
x
x
x
x
x
x
x
x
projeto.
x
x
x
x
36 Falta espírito de equipe. Os conflitos requerem
devido a distância (membros da equipe espalhados
por todo o pais).
38 Baixa moral/ falta de compromisso devido ao
superiores.
x
6.Outra:
46
5
5.Encerramento
2
31 Falta de procedimentos, programas adequados e
recursos para assegurar a garantia da qualidade.
CLASSIFICAÇÃO
x
TOTAL
x
Prazo
25 Fraca interação (comunicação) do gerente com
26 Falhas em gerenciar as expectativas do usuário
final.
Qualidade
3.Execução
x
IMPACTO
Custo
2.Planejamento
ID
1.Iniciação
PROBABILIDADE
x
x
4
2
2
4
8
32
x
x
x
1
2
2
2
6
6
x
x
x
4
3
5
4
12
48
2
4
5
5
14
28
39 Falta de maturidade / instabilidade organizacional.
x
x
x
x
x
x
3
3
3
5
11
33
x
x
x
5
4
3
5
12
60
x
x
2
3
3
4
10
20
41 Cronograma irreal ou inadequado baseado nos
46
181
47 Problemas relacionados aos contratos associados.
51 Falta de comprometimento da gerência sênior
CLASSIFICAÇÃO
TOTAL
47
6.Outra:
5.Encerramento
5
14
70
5
4
4
4
12
60
3
4
3
5
12
36
x
x
x
3
3
4
5
12
36
x
x
3
4
2
4
10
30
x
x
3
3
2
4
9
27
x
x
4
4
3
4
11
44
3
3
4
3
10
30
x
1
4
3
4
11
11
0
0
x
x
x
x
52 Qualquer problema de comunicação em nível
47
5
x
x
x
4
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
5
x
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.
x
Prazo
x
x
Qualidade
44 Orçamento insuficiente ou instável baseado nos
45 Instabilidade (rotatividade) e falta de continuidade
das pessoas nos projetos.
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
IMPACTO
Custo
pouco conhecimento, falta habilidade, falta de
pessoal e indisponibilidade de pessoas chaves.
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
182
Qualidade
Prazo
TOTAL
CLASSIFICAÇÃO
Custo
x
x
4
4
4
4
12
48
2
x
x
4
4
4
4
12
48
3
x
x
4
4
4
4
12
48
4
Baixo desempenho.
x
x
4
4
4
4
12
48
2
4
1
4
9
18
2
2
2
2
6
12
3
4
4
4
12
36
5
6
7
x
x
x
8
inadequada.
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.
tecnologias).
12 Inadequada preparação e realização dos testes.
13 Falta de um acordo interativo entre os clientes e
os desenvolvedores relativo às especificações dos
requisitos.
x
produtividade.
Fonte: Elaborado pelo autor a partida da pesquisa de campo
6.Outra:
x
x
3
4
3
4
11
33
x
x
2
3
1
3
7
14
x
2
3
1
3
7
14
x
x
3
4
3
4
11
33
x
x
3
4
3
4
11
33
x
x
2
5
4
5
14
28
x
2
5
4
5
14
28
2
3
3
3
9
18
2
2
2
2
6
12
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.
apoio selecionados inadequados para o processo
de desenvolvimento.
41
5.Encerramento
1
ID
3.Execução
2.Planejamento
IMPACTO
1.Iniciação
PROBABILIDADE
Tabela 40: Análise dos fatores de riscos segundo a empresa “B”
x
x
x
x
x
183
CLASSIFICAÇÃO
TOTAL
41
Prazo
x
Qualidade
x
6.Outra:
5.Encerramento
x
IMPACTO
Custo
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
Tabela 40: Análise dos fatores de riscos segundo a empresa “B” (Cont.)
3
3
3
3
9
27
1
3
1
3
7
7
x
x
1
3
1
3
7
7
x
x
2
3
3
3
9
18
x
1
1
1
1
3
3
2
3
3
3
9
18
1
1
3
1
5
5
2
4
4
4
12
24
2
3
3
3
9
18
3
3
3
3
9
27
2
3
4
3
10
20
2
4
4
4
12
24
x
2
1
1
1
3
6
x
x
2
4
4
4
12
24
x
x
2
4
4
4
12
24
x
x
2
2
3
2
7
14
x
x
x
3
4
1
4
9
27
x
x
3
4
1
4
9
27
especialistas ou consultores, conserto ou
resolução de problemas por parte dos
vendedores.
22 Planejamento inapropriado, incluindo construção
e atualização do plano de contingência.
23 Papéis e responsabilidades de relacionamentos
final.
projetos.
relacionadas ao projeto. Ex.: acompanhamento
do relatório de status e manutenção de métricas
progressivas.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
projeto.
x
x
x
x
x
184
Prazo
TOTAL
1
1
1
1
3
3
2
3
3
3
9
18
x
2
2
3
2
7
14
x
x
2
2
3
2
7
14
x
x
2
4
2
4
10
20
x
3
4
3
4
11
33
x
4
4
4
4
12
48
2
4
4
4
12
24
2
1
4
1
6
12
2
3
3
3
9
18
3
3
3
3
9
27
2
1
1
1
3
6
0
0
x
x
x
superiores.
organizacional.
x
45 Instabilidade
(rotatividade)
e
falta
de
x
x
x
x
x
x
CLASSIFICAÇÃO
Qualidade
14
x
x
6.Outra:
41
7
5.Encerramento
3
x
3.Execução
Custo
1
2.Planejamento
3
x
IMPACTO
2
1.Iniciação
ID
PROBABILIDADE
185
TOTAL
2
1
1
1
3
6
3
3
3
3
9
27
0
0
12
36
x
x
x
x
x
CLASSIFICAÇÃO
Prazo
x
Qualidade
x
IMPACTO
Custo
x
41
50 Qualquer problema com o usuário, tais como:
conflito entre usuários e departamentos, falta de
sistema, resistência a mudanças e falha em obter
o comprometimento do usuário.
6.Outra:
x
5.Encerramento
x
2.Planejamento
49 Fatores
políticos
(companhia,
clientes,
projeto.
ID
3.Execução
1.Iniciação
PROBABILIDADE
3
4
4
4
Qualidade
Prazo
TOTAL
CLASSIFICAÇÃO
Custo
x
x
x
3
4
4
4
12
36
2
x
x
x
3
3
3
3
9
27
3
x
x
x
2
3
3
3
9
18
4
Baixo desempenho.
x
x
x
2
3
3
3
9
18
x
x
x
2
2
2
2
6
12
5
6
7
6.Outra: 41
5.Encerramento
1
ID
3.Execução
2.Planejamento
IMPACTO
1.Iniciação
PROBABILIDADE
Tabela 41: Análise dos fatores de riscos segundo a empresa “C”
x
x
x
3
4
4
4
12
36
x
x
x
2
5
5
5
15
30
186
CLASSIFICAÇÃO
x
x
2
3
3
3
9
18
x
x
x
2
4
4
4
12
24
x
x
x
2
3
3
3
9
18
x
x
x
3
4
4
4
12
36
x
x
x
4
4
4
4
12
48
x
x
x
4
3
3
3
9
36
x
x
x
2
2
2
2
6
12
3
3
3
3
9
27
6.Outra: 41
x
5.Encerramento
TOTAL
x
Prazo
requisitos.
x
Qualidade
tecnologias).
Custo
inadequada.
hardware.
8
3.Execução
1.Iniciação
ID
IMPACTO
2.Planejamento
PROBABILIDADE
Tabela 41: Análise dos fatores de riscos segundo a empresa “C” (Cont.)
de desenvolvimento.
x
x
produtividade.
x
x
x
3
3
3
3
9
27
x
x
3
3
3
3
9
27
x
x
4
2
2
2
6
24
3
3
3
3
9
27
x
x
187
projetos.
progressivas.
Prazo
TOTAL
CLASSIFICAÇÃO
Qualidade
6.Outra: 41
x
5.Encerramento
x
2
3
3
3
9
18
2
2
2
2
6
12
x
x
x
x
x
4
3
3
3
9
36
x
x
x
4
3
3
3
9
36
x
x
x
2
4
4
4
12
24
x
x
x
x
x
3
3
3
3
9
27
x
x
x
x
x
3
3
3
3
9
27
x
x
x
x
x
3
3
3
3
9
27
x
x
x
x
x
4
2
3
3
8
32
4
2
3
3
8
32
4
2
3
3
8
32
x
projeto.
x
IMPACTO
Custo
vendedores.
final.
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
x
x
x
x
x
x
x
4
2
3
3
8
32
x
x
x
5
2
4
3
9
45
x
x
x
3
4
3
4
11
33
x
x
x
4
4
2
4
10
40
x
x
4
4
2
4
10
40
3
2
4
4
10
30
x
x
188
Qualidade
Prazo
TOTAL
superiores.
organizacional.
x
2
4
4
10
30
x
x
x
3
3
4
4
11
33
x
x
x
3
3
3
3
9
27
3
4
4
4
12
36
x
4
4
3
4
11
44
x
x
3
3
5
3
11
33
x
x
3
3
4
4
11
33
x
2
4
2
3
9
18
x
x
3
4
4
4
12
36
x
x
x
4
3
2
4
9
36
x
45 Instabilidade
(rotatividade)
e
falta
de
x
x
x
x
x
CLASSIFICAÇÃO
Custo
3
x
x
6.Outra: 41
x
5.Encerramento
x
2.Planejamento
1.Iniciação
ID
IMPACTO
3.Execução
PROBABILIDADE
x
x
x
3
4
3
4
11
33
x
x
x
3
4
3
4
11
33
3
3
3
3
9
27
49 Fatores
políticos
(companhia,
clientes,
projeto.
x
x
x
189
CLASSIFICAÇÃO
TOTAL
x
Prazo
x
Qualidade
x
IMPACTO
Custo
6.Outra: 41
x
5.Encerramento
x
2.Planejamento
ID
3.Execução
1.Iniciação
PROBABILIDADE
3
3
3
3
9
27
2
3
3
3
9
18
0
0
5
6
7
8
inadequada.
CLASSIFICAÇÃO
Baixo desempenho.
TOTAL
4
x
Prazo
Qualidade
x
3
IMPACTO
Custo
x
6.outra: 41
x
2
5.encerramento
4.monitor. / controle
2.planejamento
1
ID
3.execução
1.iniciação
PROBABILIDADE
Tabela 42: Análise dos fatores de riscos segundo a empresa “D”
4
5
3
4
12
48
3
4
2
3
9
27
3
4
2
3
9
27
x
x
3
4
2
3
9
27
x
x
4
5
3
4
12
48
x
x
3
4
2
3
9
27
x
3
4
2
3
9
27
x
2
3
1
2
6
12
190
requisitos.
CLASSIFICAÇÃO
x
3
4
2
3
9
27
x
x
3
4
2
3
9
27
4
5
3
4
12
48
3
4
2
3
9
27
6.outra: 41
x
5.encerramento
TOTAL
Prazo
tecnologias).
Qualidade
hardware.
IMPACTO
Custo
9
3.execução
1.iniciação
ID
2.planejamento
PROBABILIDADE
Tabela 42: Análise dos fatores de riscos segundo a empresa “D” (Cont.)
x
x
x
x
x
x
3
4
2
3
9
27
x
4
5
3
4
12
48
x
de desenvolvimento.
x
x
x
x
x
3
4
2
3
9
27
produtividade.
x
x
x
x
x
3
4
2
3
9
27
x
x
x
x
x
4
5
3
4
12
48
x
x
x
3
4
2
3
9
27
3
4
2
3
9
27
3
4
2
3
9
27
x
x
x
191
projetos.
progressivas.
Prazo
TOTAL
CLASSIFICAÇÃO
Qualidade
4
12
48
x
4
5
3
4
12
48
x
3
4
2
3
9
27
x
3
4
2
3
9
27
x
2
3
1
2
6
12
5
5
4
5
14
70
x
6.outra: 41
3
5.encerramento
5
3.execução
4
x
x
x
x
x
x
x
x
x
3
4
2
3
9
27
x
x
x
x
x
3
4
2
3
9
27
x
4
5
3
4
12
48
x
x
2
3
1
2
6
12
x
x
3
4
2
3
9
27
x
x
x
4
4
3
4
11
44
x
x
x
5
5
4
5
14
70
IMPACTO
Custo
vendedores.
final.
2.planejamento
1.iniciação
ID
PROBABILIDADE
x
x
projeto.
x
x
4
5
3
4
12
48
x
x
4
5
3
4
12
48
3
4
2
3
9
27
3
4
2
3
9
27
x
x
x
192
x
x
x
45 Instabilidade
(rotatividade)
e
falta
de
CLASSIFICAÇÃO
6.outra: 41
5.encerramento
x
TOTAL
x
x
x
Prazo
x
Qualidade
organizacional.
x
IMPACTO
Custo
superiores.
3.execução
1.iniciação
ID
2.planejamento
PROBABILIDADE
3
4
2
3
9
27
3
4
2
3
9
27
3
4
2
3
9
27
3
4
2
3
9
27
2
3
1
2
6
12
3
4
2
3
9
27
x
x
x
x
x
x
3
4
2
3
9
27
x
4
5
3
4
12
48
3
4
2
3
9
27
x
x
x
x
x
x
x
x
4
5
3
4
12
48
x
x
x
x
4
5
3
4
12
48
x
x
x
x
3
4
2
3
9
27
x
x
x
3
4
2
3
9
27
x
x
3
4
2
3
9
27
x
x
4
5
3
4
12
48
49 Fatores
políticos
(companhia,
clientes,
projeto.
x
x
x
x
193
Qualidade
Prazo
TOTAL
CLASSIFICAÇÃO
Custo
x
x
x
4
4
4
5
13
52
2
x
x
x
4
4
4
5
13
52
3
x
x
x
3
4
4
5
13
39
4
Baixo desempenho.
x
x
x
3
4
4
5
13
39
x
x
4
4
4
5
13
52
2
3
4
3
10
20
5
6
7
x
x
8
inadequada.
hardware.
tecnologias).
x
6.Outra: 41
3.Execução
1
ID
5.Encerramento
2.Planejamento
IMPACTO
1.Iniciação
PROBABILIDADE
Tabela 43: Análise dos fatores de riscos segundo a empresa “E”
x
x
3
3
3
3
9
27
x
x
2
3
5
3
11
22
x
x
2
3
5
3
11
22
x
x
2
2
4
3
9
18
3
3
3
3
9
27
3
3
4
4
11
33
x
x
x
x
x
x
requisitos.
x
x
x
3
3
4
4
11
33
x
x
x
4
4
4
5
13
52
de desenvolvimento.
x
x
x
3
3
3
3
9
27
x
x
194
x
x
x
CLASSIFICAÇÃO
x
3
3
3
3
9
27
x
x
2
3
5
5
13
26
2
2
3
3
8
16
6.Outra: 41
TOTAL
5.Encerramento
x
Prazo
produtividade.
Qualidade
3.Execução
x
IMPACTO
Custo
2.Planejamento
ID
1.Iniciação
PROBABILIDADE
Tabela 43: Análise dos fatores de riscos segundo a empresa “E” (Cont.)
x
x
x
2
2
4
4
10
20
x
x
2
2
4
4
10
20
x
2
2
3
3
8
16
x
3
3
4
4
11
33
vendedores.
final.
projetos.
progressivas.
x
x
x
x
x
x
x
x
3
3
4
4
11
33
x
x
x
x
x
2
3
4
4
11
22
x
x
x
x
x
1
2
3
3
8
8
x
x
x
x
x
1
2
3
3
8
8
x
x
x
x
x
1
2
3
3
8
8
x
x
x
x
x
2
2
3
3
8
16
x
x
x
x
x
2
2
3
3
8
16
x
2
4
2
2
8
16
x
x
x
x
x
2
4
4
3
11
22
x
x
x
2
3
3
3
9
18
195
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
4
4
11
44
3
4
3
4
11
33
2
3
3
3
9
18
x
2
3
3
3
9
18
x
x
2
3
3
3
9
18
superiores.
x
x
x
1
2
2
2
6
6
organizacional.
x
x
x
x
2
2
2
2
6
12
x
x
x
x
x
2
3
3
3
9
18
x
x
x
x
x
2
3
4
4
11
22
x
x
x
x
x
4
3
4
4
11
44
x
x
x
x
x
2
4
4
4
12
24
45 Instabilidade
(rotatividade)
e
falta
de
0
0
x
6.Outra: 41
3
5.Encerramento
4
CLASSIFICAÇÃO
x
TOTAL
x
Prazo
x
Qualidade
3.Execução
x
projeto.
IMPACTO
Custo
2.Planejamento
ID
1.Iniciação
PROBABILIDADE
x
x
x
x
x
2
3
3
3
9
18
x
x
x
x
x
3
3
3
3
9
27
196
TOTAL
2
3
3
8
CLASSIFICAÇÃO
Prazo
2
Qualidade
6.Outra: 41
x
IMPACTO
Custo
5.Encerramento
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
16
0
0
49 Fatores
políticos
(companhia,
clientes,
projeto.
x
x
x
x
x
2
3
3
3
9
18
x
x
x
x
x
2
3
3
3
9
18
x
x
x
x
x
1
2
2
2
6
6
0
0
TOTAL
CLASSIFICAÇÃO
Prazo
x
4
4
3
4
11
44
2
x
x
2
3
4
2
9
18
3
x
x
5 Adição de mais funcionalidades que o
6 Requisitos de desempenho não atendidos. Ex.
x
Baixo desempenho.
x
3
3
4
2
9
27
x
2
2
4
2
8
16
4
4
3
5
12
48
2
3
5
2
10
20
1.Iniciação
4
x
x
x
6.Outra: 41
x
5.Encerramento
3.Execução
1
ID
2.Planejamento
Qualidade
IMPACTO
Custo
PROBABILIDADE
Tabela 44: Análise dos fatores de riscos segundo a empresa “F”
197
8
inadequada.
hardware.
CLASSIFICAÇÃO
x
3
5
3
11
44
x
2
2
4
2
8
16
x
2
2
4
2
8
16
x
1
1
1
1
3
3
0
0
tecnologias).
x
6.Outra: 41
4
5.Encerramento
TOTAL
x
Prazo
x
Qualidade
x
IMPACTO
Custo
3.Execução
7
2.Planejamento
ID
1.Iniciação
PROBABILIDADE
Tabela 44: Análise dos fatores de riscos segundo a empresa “F” (Cont.)
x
4
4
5
5
14
56
requisitos.
x
x
1
2
3
4
9
9
x
x
1
2
3
4
9
9
de desenvolvimento.
x
x
x
x
x
x
1
2
2
3
7
7
produtividade.
x
x
x
x
x
x
1
1
1
1
3
3
x
3
2
4
1
7
21
x
1
2
3
3
8
8
1
3
1
1
5
5
x
x
x
x
x
x
198
x
x
1
7
14
x
1
1
3
1
5
5
x
3
4
2
5
11
33
0
0
x
2
2
1
5
8
16
x
x
1
1
1
1
3
3
x
1
1
1
1
3
3
2
2
4
2
8
16
0
0
x
x
x
x
x
projetos.
progressivas.
CLASSIFICAÇÃO
4
6.Outra: 41
2
5.Encerramento
2
x
x
x
TOTAL
x
Prazo
x
Qualidade
x
IMPACTO
Custo
vendedores.
final.
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
x
4
3
2
5
10
40
x
x
x
x
x
x
4
3
2
5
10
40
x
x
x
x
x
x
3
2
2
5
9
27
x
x
x
x
x
x
1
1
1
2
4
4
x
x
5
4
2
5
11
55
x
2
2
1
2
5
10
projeto.
x
199
1
1
1
3
3
x
1
1
1
1
3
3
0
0
superiores.
organizacional.
x
x
x
x
x
x
x
x
x
x
45 Instabilidade
(rotatividade)
e
falta
de
x
x
x
x
x
CLASSIFICAÇÃO
TOTAL
1
6.Outra: 41
x
5.Encerramento
Prazo
x
Qualidade
IMPACTO
Custo
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
x
x
2
1
3
3
7
14
3
2
2
2
6
18
3
5
4
5
14
42
2
1
1
5
7
14
4
4
4
5
13
52
4
4
5
5
14
56
x
x
3
4
4
5
13
39
x
x
2
3
5
5
13
26
x
x
1
1
3
1
5
5
0
0
200
49 Fatores
políticos
(companhia,
clientes,
projeto.
x
x
x
CLASSIFICAÇÃO
TOTAL
Prazo
Qualidade
IMPACTO
Custo
6.Outra: 41
5.Encerramento
3.Execução
1.Iniciação
ID
2.Planejamento
PROBABILIDADE
0
0
x
3
1
3
3
7
21
x
x
3
2
3
5
10
30
x
x
1
1
3
3
7
7
0
0
x
x
x
201
APÊNDICE V- Classificação dos fatores de riscos segundo as fases do ciclo de vida do
projeto, de acordo com as empresas pesquisadas.
Aqui é apresentada a classificação dos fatores de riscos segundo as empresas
pesquisadas, desde que citados por pelo menos uma empresa.
Alguns fatores de riscos não foram citados pelas empresas em algumas fases do ciclo de
vida dos projetos. Neste caso eles foram retirados das tabelas abaixo, porém foi mantida a
identificação (ID) original deles.
Na Tabela 45 os fatores de riscos 12, 20 e 48 não foram citados pelas empresas
pesquisadas. Para saber quais são estes fatores de riscos ver os mesmos na Tabela 38.
Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE DE INICIAÇÃO
ID
EMPRESAS
A
B
x
C
x
D
x
E
x
F
x
x
x
x
x
x
x
3
x
x
x
x
x
4
Requisitos mal entendidos (não refletem as expectativas do
cliente).
Adição de mais funcionalidades que o especificado / dar
extras ao cliente.
Requisitos de desempenho não atendidos. Ex. Baixo
desempenho.
x
x
x
x
x
1
2
5
6
7
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.
desenvolvedores relativo às especificações dos requisitos.
x
x
x
8
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 à
x
x
x
x
x
x
x
x
x
x
x
x
202
Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
FASE DE INICIAÇÃO
ID
15 Os modelos, processos, métodos e ferramentas de apoio
selecionados
inadequados
para
o
processo
de
desenvolvimento.
EMPRESAS
A
B
C
D
E
F
x
x
x
x
x
x
x
x
x
x
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.
x
x
x
19 Capacidade insuficiente do sistema desenvolvido. Ex.: Falta
de estações de trabalho, espaço de armazenamento no banco
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
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.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
relacionadas ao projeto. Ex.: acompanhamento do relatório de
status e manutenção de métricas progressivas.
x
x
x
x
x
x
x
x
x
36 Falta espírito de equipe. Os conflitos requerem intervenção da
gerência.
x
x
31 Falta de procedimentos, programas adequados e recursos para
assegurar a garantia da qualidade.
x
x
x
x
x
x
x
x
x
203
Iniciação do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
FASE DE INICIAÇÃO
ID
EMPRESAS
A
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).
B
C
D
x
x
x
x
x
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
x
x
associados e subcontratantes) que causam problemas para o
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
52 Qualquer problema de comunicação em nível internacional
relativo a diferenças de idiomas.
x
x
41 Cronograma irreal ou inadequado baseado nos eventos
internos e externos do sistema.
F
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.
44 Orçamento insuficiente ou instável baseado nos eventos
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,
E
x
x
x
x
x
x
204
Na Tabela 46 todos fatores de riscos foram citados pelas empresas pesquisadas.
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE DE PLANEJAMENTO
ID
EMPRESAS
A
1
B
x
2
x
x
3
x
x
x
x
4
x
x
x
x
x
x
x
x
x
7
cliente).
Adição de mais funcionalidades que o especificado / dar
extras ao cliente.
desempenho.
8
9
Restrições referentes ao hardware designado. Ex.: capacidade
de memória e tempo de resposta real, acesso à base de dados e
Tecnologia nova / imatura (uso de novas tecnologias).
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
Falta de um acordo interativo entre os clientes e os
Inadequadas especificações. Ex.: especificações de sistema,
5
6
10
11
12
13
14
selecionados
inadequados
para
o
processo
de
desenvolvimento.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
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
x
x
20 Pouca confiança no desenvolvimento do sistema devido à
indisponibilidade / erro / mal funcionamento dos
componentes.
x
x
E
x
x
D
x
x
x
x
C
x
x
x
205
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID
EMPRESAS
A
ou mal entendidos.
ineficientes.
relacionadas ao projeto. Ex.: acompanhamento do relatório de
status e manutenção de métricas progressivas.
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
E
x
x
D
x
C
x
gerência.
por todo o pais).
superiores.
B
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
206
Planejamento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID
45 Instabilidade (rotatividade) e falta de continuidade das
pessoas nos projetos.
EMPRESAS
A
B
C
D
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
F
x
associados e subcontratantes) que causam problemas para o
E
x
x
x
Na Tabela 47 o fator de riscos 21 não foi citado pelas empresas pesquisadas. Para saber
qual é este fator de riscos ver o mesmo na Tabela 38.
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE DE EXECUÇÃO
ID
EMPRESAS
E
x
F
x
x
x
x
x
x
x
x
x
x
x
1
2
3
cliente).
5 Adição de mais funcionalidades que o especificado / dar extras
ao cliente.
A
x
B
4
x
C
D
207
Execução do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
FASE DE EXECUÇÃO
ID
EMPRESAS
A
6
7
desempenho.
8
selecionados inadequados para o processo de desenvolvimento.
x
x
x
x
D
E
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
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.
indisponibilidade / erro / mal funcionamento dos componentes.
22 Planejamento inapropriado, incluindo construção e atualização
do plano de contingência.
ou mal entendidos.
ineficientes.
C
x
9
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.
B
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
208
FASE DE EXECUÇÃO
ID
EMPRESAS
A
B
C
x
D
x
E
x
F
x
x
x
x
x
x
x
x
x
x
x
x
29 Fraco monitoramento do progresso das atividades relacionadas
ao projeto. Ex.: acompanhamento do relatório de status e
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
gerência.
por todo o pais).
superiores.
x
x
41 Cronograma irreal ou inadequado baseado nos eventos internos
e externos do sistema.
45 Instabilidade (rotatividade) e falta de continuidade das pessoas
nos projetos.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
209
FASE DE EXECUÇÃO
ID
EMPRESAS
A
49 Fatores políticos (companhia, clientes, contratantes associados
e subcontratantes) que causam problemas para o
B
x
C
D
E
x
x
x
x
x
x
x
x
x
x
x
x
F
x
Na Tabela 48 todos os fatores de riscos foram citados pelas empresas pesquisadas.
Monitoramento / Controle do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE DE MONITORAMENTO /
CONTROLE
ID
EMPRESAS
A
x
B
C
x
1
2
x
3
x
4
cliente).
Adição de mais funcionalidades que o especificado / dar extras
ao cliente.
desempenho.
5
6
7
8
9
D
E
F
x
x
x
x
x
x
x
x
x
x
x
x
x
210
(Cont.)
CONTROLE
ID
EMPRESAS
A
B
x
x
x
x
x
ou mal entendidos.
ineficientes.
E
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
F
x
x
dados insuficiente.
D
x
C
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
211
(Cont.)
CONTROLE
ID
EMPRESAS
A
B
C
x
D
x
E
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
41 Cronograma irreal ou inadequado baseado nos eventos internos
e externos do sistema.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
nos projetos.
x
x
x
x
x
x
x
x
x
x
x
gerência.
por todo o pais).
superiores.
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
212
(Cont.)
CONTROLE
ID
EMPRESAS
A
B
x
C
x
D
x
x
x
E
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Na Tabela 49 os fatores de riscos 01, 02, 03, 04, 05, 07, 13, 14 e 18 não foram citados
pelas empresas pesquisadas. Para saber quais são estes fatores de riscos ver os mesmos na
Tabela 38.
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE DE ENCERRAMENTO
ID
EMPRESAS
A
6
desempenho.
8 Desenvolvimento de interface do usuário inadequada.
9 Problemas de desempenho de tempo real (há tempos de
B
C
D
x
E
x
x
x
x
x
x
F
213
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID
EMPRESAS
A
selecionados
inadequados
para
o
processo
de
desenvolvimento.
B
C
E
F
x
x
x
x
x
x
x
x
x
x
x
x
x
x
dados insuficiente.
x
x
x
ou mal entendidos.
ineficientes.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
D
214
Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas (Cont.)
ID
EMPRESAS
A
B
C
D
gerência.
por todo o pais).
x
x
x
x
x
x
x
x
x
x
nos projetos.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
F
x
superiores.
E
x
x
x
x
215
Na Tabela 50 aparecem os fatores de riscos citados apenas pela empresa “F”.
Avaliação Pós-Encerramento do ciclo de vida do projeto, segundo as empresas pesquisadas
FASE de Análise Pós-Encerramento
ID
EMPRESAS
A
B
C
D
E
F
x
x
x
x
x
x
x
x
x
216
APÊNDICE VI - Roteiro de análise de risco
Neste apêndice é apresentado o roteiro de análise de risco, que está dividido em quarto
partes: dados do entrevistado, dados da empresa, gerência de risco e fatores de riscos.
Parte I – Dados do Entrevistado
217
Parte II – Dados da Empresa
218
Parte III – Gerência de Riscos
219
Parte IV – Fatores de Riscos
Nesta parte do roteiro de análise de riscos (Parte IV) as questões 36 a 40 foram repetidas
para cada fator de risco identificado (Figura 23), totalizando 52 fatores de riscos (Tabela 38).
Essa variação na quantidade de fatores de risco se deu de acordo com a análise semântica
realizada, conforme descrito no item 3.1 desta dissertação e apresentada no Apêndice III.

Investigação para uma proposta de um método

Transcrição

Documentos relacionados

ORGANOGRAMA FUNDEP

Manual de Filiacao ao PMI - PMI-DF

Produtor de Água UNB

CG CML 4168 – Blusa branca de motivos rendada – Camila Fashion

Plano de Projeto Executivo

Exemplo 1 de Relatorio de Estágio de Administração

Elaboração e Análise de Projetos - dba3

Bolsa Brea – Receita Retirada da Berroco: http://www.berroco.com

Política de Privacidade Ao criar um perfil, estará fornecendo dados

Versão para impressão