Embed Size (px)
Citation preview
UNIVERSIDADE NOVE DE JULHO
PROGRAMA DE MESTRADO E DOUTORADO EM ADMINISTRAÇÃO
MARCO ALEXANDRE TERLIZZI
MODELO DE GESTÃO DE RISCOS PARA
PROJETOS DE SOFTWARE NO SETOR BANCÁRIO
São Paulo
2014
Marco Alexandre Terlizzi
MODELO DE GESTÃO DE RISCOS PARA
PROJETOS DE SOFTWARE NO SETOR BANCÁRIO
RISK MANAGEMENT MODEL FOR
SOFTWARE PROJECTS IN THE BANKING SECTOR
Dissertação apresentada ao Programa de Pós-
Graduação em Administração da Universidade Nove
de Julho – UNINOVE, como requisito parcial para
obtenção do grau de Mestre em Administração.
ORIENTADOR: PROF. DR. CÉSAR AUGUSTO
BIANCOLINO
São Paulo
2014
FICHA CATALOGRÁFICA
Terlizzi, Marco Alexandre.
Modelo de gestão de riscos para projetos de software no setor bancário.
/ Marco Alexandre Terlizzi. 2014.
251 f.
Dissertação (mestrado) – Universidade Nove de Julho – UNINOVE, São
Paulo, 2014.
Orientador (a): Prof. Dr. César Augusto Biancolino.
1. Gestão de riscos. 2. Estrutura Analítica de Riscos. 3. Projetos de
software. 4. Setor bancário.
I. Biancolino, César Augusto. II. Titulo
CDU 658.012.2
MODELO DE GESTÃO DE RISCOS PARA
PROJETOS DE SOFTWARE NO SETOR BANCÁRIO
Por
Marco Alexandre Terlizzi
Dissertação apresentada ao Programa de Pós-
Graduação em Administração – PPGA da
Universidade Nove de Julho – UNINOVE, como
requisito parcial para obtenção do título de Mestre
em Administração, sendo a banca examinadora
formada por:
___________________________________________________________
Prof. Dr. Bruno Meirelles Salotti – Universidade de São Paulo – FEA/USP
___________________________________________________________
Prof. Dr. César Augusto Biancolino – Universidade Nove de Julho – UNINOVE
___________________________________________________________
Profa. Dra. Sonia Francisca Monken de Assis – Universidade Nove de Julho – UNINOVE
São Paulo, 04 de dezembro de 2014.
DEDICATÓRIA
Dedico esta dissertação a Cynthia Izumi
Yamauchi Terlizzi.
AGRADECIMENTO
Agradeço minha esposa Cynthia e minhas filhas Giovanna e Rafaela, pelo carinho,
apoio, estímulo e compreensão pela ausência durante o tempo desprendido para a realização
do curso de mestrado.
Aos meus pais, Vicente e Fátima, e meus irmãos Marco Antonio e Marco Aurelio
por serem exemplo de vida e fonte de amor incondicional. Ter uma família unida e com
valores sólidos ajudou a construir meu caráter e me tornou persistente em alcançar meus
objetivos.
Ao meu orientador, Prof. Dr. César Augusto Biancolino, por me aceitar como seu
orientando, por me acompanhar e incentivar durante o curso.
A Profa. Dra. Sonia Francisca Monken de Assis que participou da banca de
qualificação e defesa contribuindo com melhorias para a dissertação.
Ao Prof. Dr. Marcirio Silveira Chaves que participou da banca de qualificação e ao
Prof. Dr. Bruno Meireles Salotti que participou da banca de defesa, ambos dedicando seu
precioso tempo para avaliação do estudo.
Aos demais professores da Uninove do Mestrado em Gestão de Projetos, pelo
compartilhamento do conhecimento e por mostrarem os rumos da vida acadêmica.
Aos colegas da turma de mestrado pela amizade, companheirismo e momentos de
discussão e diversão. Em especial ao Heverton, Vagner, Airton e Irapuan.
E aos amigos, de longe e de perto, que compreenderam as ausências sem deixar de se
fazer presentes em minha vida.
Muito obrigado!
RESUMO
A gestão de risco operacional, de crédito, de imagem e de liquidez são áreas muito
desenvolvidas no setor bancário; entretanto, a gestão de riscos em projetos nesta área
necessita de constantes investimentos em pesquisas e treinamentos para proporcionar a sua
evolução. As ferramentas e técnicas de gestão de riscos foram desenvolvidas para melhorar o
sucesso dos projetos; porém, muitos projetos de desenvolvimento de software no setor
bancário brasileiro ainda são executados sem o uso de metodologias, podendo causar perdas
financeiras superiores ao seu orçamento. Em 2013 o setor bancário brasileiro investiu R$ 20,6
bilhões em projetos de tecnologia, mesmo assim, observa-se que o país ainda tem carência de
bases históricas sobre os riscos que afetam estes projetos. Esta pesquisa tem como objetivo
propor um modelo de gestão de riscos aplicável a projetos de software no setor bancário
brasileiro, permitindo identificar e priorizar os principais riscos do portfólio. Pode ser
classificada como exploratória-descritiva, de caráter qualitativo, abordada por meio do
método de estudo de caso único em um dos maiores banco privados do Brasil. Utilizou-se a
técnica de análise de proposições teóricas e os dados foram coletados por meio de entrevistas,
documentos internos e bases de dados. Como resultado, utilizando-se a base histórica de
riscos dos projetos da organização, foi possível agrupá-los em uma Estrutura Analítica de
Riscos conforme a taxonomia sugerida pelo Software Engineering Institute, além de
identificar que os principais riscos em projetos de software na organização são os mesmos
apresentados na literatura: escopo instável, premissas de prazo e custo irreais; e falta de
técnicas adequadas de gestão. Na conclusão propõe-se um modelo de gestão de riscos
aplicável ao portfólio de projetos de software no setor bancário. O modelo STOp permite
orientar a gestão de riscos a partir do inter-relacionamento entre os diversos níveis
hierárquicos: estratégico – executivos avaliam os principais riscos do portfólio e autorizam
soluções corporativas; tático – equipes de governança estruturam políticas e processos para
garantir a implantação das soluções; e operacional – equipes de desenvolvimento atuam nos
riscos individuais que podem impactar os objetivos do projeto ou produto. Com base no
modelo proposto e na análise dos dados coletados, em contraponto com o referencial teórico,
foi possível contribuir com a evolução do processo atual de gestão de riscos de projetos da
organização, destacando suas forças, fraquezas, oportunidades e ameaças.
Palavras-chave: Gestão de Riscos, Estrutura Analítica de Riscos, Projetos de
Software; Setor Bancário.
ABSTRACT
The management of operational risk, credit risk, image risk and liquidity risk are
very developed areas in the banking sector; however, the risk management of projects in this
area needs constant investment in research and training to provide its evolution. The tools and
risk management techniques have been developed to improve the success of projects; though,
many software projects in the banking sector are still executed without the use of
methodologies, and this may cause financial losses greater than the project budget. In 2013
the Brazilian banking sector invested US$ 7.9 billion on technology projects, even so, it is
observed that the country still has lack of historical databases about the risks that affect this
type of projects. This research aims to propose a risk management model applicable to
software projects in the Brazilian banking sector, allowing to identify and prioritize the main
risks of the portfolio. It can be classified as exploratory, descriptive and qualitative, using the
unique case study method in one of the largest private bank in Brazil. It used the analysis of
theoretical propositions technique and data were collected through interviews, internal
documents and databases. As a result, using the organization historical database of project
risks, it was possible to group them into a Risk Breakdown Structure as suggested by the
taxonomy of the Software Engineering Institute, and identify that the main risks of the
software projects in the organization are the same existing in the literature: unstable scope,
unrealistic cost; and lack of appropriate management techniques. In conclusion we propose a
risk management model for the portfolio of software projects in the banking sector. The STOp
model guide the management of risks between the various hierarchical levels: strategic -
executives assess the main risks of the portfolio and authorize enterprise solutions; tactical -
governance teams prepare policies and processes to ensure the implementation of the
solutions; and operational - development teams work on individual risks that may impact the
project or product objectives. Based on the proposed model and data analysis, as opposed to
the theoretical framework, it was possible to contribute with the evolution of the project risk
management process existing in the company, highlighting its strengths, weaknesses,
opportunities and threats.
Keywords: Risk Management, Risk Breakdown Structure, Software Projects;
Banking Sector.
SUMÁRIO
LISTA DE FIGURAS ........................................................................................................... XII
LISTA DE TABELAS ......................................................................................................... XIV
LISTA DE ABREVIATURAS E SIGLAS ......................................................................... XV
1 INTRODUÇÃO ...................................................................................................... 17
1.1 APRESENTAÇÃO ................................................................................................... 17
1.2 PROBLEMATIZAÇÃO E QUESTÃO DE PESQUISA ......................................... 21
1.3 OBJETIVO DA PESQUISA .................................................................................... 26
1.4 RELEVÂNCIA DO TEMA E JUSTIFICATIVA .................................................... 26
1.5 ESTRUTURA DA DISSERTAÇÃO ....................................................................... 30
2 REFERENCIAL TEÓRICO ................................................................................. 32
2.1 GESTÃO DE PROJETOS DE TI ............................................................................. 32
2.1.1 Conceitos e Histórico .............................................................................................. 32
2.1.2 Sucesso em Projetos ................................................................................................ 33
2.1.3 Tipologia de Projetos .............................................................................................. 36
2.1.4 Modelos de Referência em Gestão de Projetos .................................................... 39
2.1.4.1 PMBOK – Project Management Body of Knowledge ............................................. 40
2.1.4.2 PRINCE2 – Projects in a Controlled Environment ................................................. 42
2.1.5 Modelos de Maturidade em Gestão de Projetos .................................................. 47
2.1.5.1 PMI – OPM3 (Organizational Project Management Maturity Model) ................... 49
2.1.5.2 OGC – P3M3 (Portfolio, Programme and Project Management Maturity Model) . 50
2.1.6 Metodologias de Desenvolvimento de Software ................................................... 53
2.1.6.1 Scrum ........................................................................................................................ 55
2.1.6.2 Modelo V .................................................................................................................. 57
2.2 GESTÃO DE RISCOS DE TI .................................................................................. 58
2.2.1 Conceitos e Histórico .............................................................................................. 58
2.2.2 Categorização dos Riscos ....................................................................................... 60
2.2.2.1 Categorização dos Riscos Corporativos ................................................................... 60
2.2.2.2 Categorização dos Riscos de Projetos ...................................................................... 62
2.2.3 Riscos em Projetos .................................................................................................. 65
2.2.4 Riscos em Projetos de Software ............................................................................. 70
2.2.5 Gestão de Riscos em Projetos ................................................................................ 73
2.2.6 Gestão de Riscos em Projetos de Software ........................................................... 75
2.2.7 Modelos de Referência em Gestão de Riscos........................................................ 78
2.2.7.1 Modelo de Referência em Gestão de Riscos da ISO – ISO 31000........................... 79
2.2.7.2 Modelo de Referência em Gestão de Riscos de Projetos do PMI ............................ 84
2.2.7.3 Modelo de Referência em Gestão de Riscos de Software do SEI ............................ 87
2.2.7.4 Modelo de Referência em Gestão de Riscos de Software do Boehm ...................... 91
2.2.8 Identificação dos Riscos ......................................................................................... 92
2.2.8.1 Listas de Verificação ................................................................................................ 94
2.2.8.2 TBRI – Taxonomy-Based Risk Identification ........................................................... 96
2.2.8.3 GTAG12 – Global Technology Audit Guide 12: Auditing IT Projects .................... 98
2.2.8.4 Registro de Riscos .................................................................................................... 99
2.3 GESTÃO ESTRATÉGICA DE TI ......................................................................... 100
2.3.1 Conceitos e Histórico ............................................................................................ 100
2.3.2 Alinhamento Estratégico de TI e Negócios ........................................................ 102
2.3.3 Governança de TI ................................................................................................. 106
2.3.3.1 Gestão de Projetos .................................................................................................. 108
2.3.3.2 Gestão de Riscos ..................................................................................................... 109
2.3.4 O Setor Bancário Brasileiro................................................................................. 110
2.4 SÍNTESE DO REFERENCIAL TEÓRICO ........................................................... 114
3 METODOLOGIA DA PESQUISA ..................................................................... 122
3.1 ABORDAGEM E CONTEXTUALIZAÇÃO ........................................................ 122
3.2 DELINEAMENTO DA PESQUISA ...................................................................... 126
3.2.1 Questões de Estudo ............................................................................................... 129
3.2.2 Proposições de Estudo .......................................................................................... 130
3.2.2.1 Premissa 1 e Proposições Associadas ..................................................................... 132
3.2.2.2 Premissa 2 e Proposições Associadas ..................................................................... 134
3.2.2.3 Premissa 3 e Proposições Associadas ..................................................................... 136
3.2.3 Unidade de Análise ............................................................................................... 137
3.2.4 Vinculação dos Dados às Proposições ................................................................. 139
3.2.5 Critérios para a Interpretação dos Achados do Estudo .................................... 141
3.3 PROCEDIMENTOS DE COLETA E ANÁLISE DOS DADOS .......................... 142
3.3.1 Etapas da Pesquisa ............................................................................................... 143
3.3.2 Fontes de Evidências ............................................................................................ 144
3.3.2.1 Entrevistas .............................................................................................................. 145
3.3.2.2 Registros em Arquivos ........................................................................................... 146
3.3.2.3 Documentação ........................................................................................................ 147
3.3.3 Caracterização da Organização .......................................................................... 148
3.3.4 Procedimentos de Coleta de Dados ..................................................................... 148
3.3.5 Procedimentos de Análises de Dados .................................................................. 150
3.4 LIMITAÇÕES DA PESQUISA ............................................................................. 152
4 ANÁLISE E INTERPRETAÇÃO DOS RESULTADOS ................................. 154
4.1 COLETA DE DADOS ........................................................................................... 154
4.2 ANÁLISE DAS PROPOSIÇÕES .......................................................................... 157
4.2.1 Premissa 1 .............................................................................................................. 158
4.2.1.1 Proposição 1 ........................................................................................................... 158
4.2.1.2 Proposição 2 ........................................................................................................... 168
4.2.1.3 Proposição 3 ........................................................................................................... 173
4.2.2 Premissa 2 .............................................................................................................. 180
4.2.2.1 Proposição 4 ........................................................................................................... 181
4.2.2.2 Proposição 5 ........................................................................................................... 186
4.2.2.3 Proposição 6 ........................................................................................................... 198
4.2.3 Premissa 3 .............................................................................................................. 205
4.2.3.1 Proposição 7 ........................................................................................................... 205
4.2.3.2 Proposição 8 ........................................................................................................... 212
5 CONCLUSÕES ..................................................................................................... 219
6 CONTRIBUIÇÕES PARA A PRÁTICA ........................................................... 229
REFERÊNCIAS ................................................................................................................... 236
ANEXO 1 – VISÃO GERAL DA TBRI (TAXONOMY-BASED RISK
IDENTIFICATION) ............................................................................................................. 245
ANEXO 2 – VERSÃO REDUZIDA DA LISTA GTAG12 ............................................... 248
APÊNDICE 1 – ROTEIRO DE ENTREVISTA ................................................................ 250
LISTA DE FIGURAS
Figura 1. Resultado dos projetos de tecnologia no período de 2004 a 2012. ........................... 18
Figura 2. Gastos com tecnologia no setor bancário. ................................................................. 20 Figura 3: Tipo de gastos com tecnologia no setor bancário. .................................................... 21 Figura 4: Avaliação do sucesso do projeto no tempo. .............................................................. 34 Figura 5: Projetos categorizados por finalidade. ...................................................................... 37
Figura 6: Modelo diamante....................................................................................................... 38 Figura 7: Grupos de processos do PMBOK. ............................................................................ 41 Figura 8: Os cinco níveis de maturidade do CMMI. ................................................................ 47
Figura 9: Modelo de maturidade OPM3. .................................................................................. 50 Figura 10: Modelo de maturidade P3M3. ................................................................................. 53 Figura 11: Visão geral do Scrum. ............................................................................................. 56 Figura 12: Relacionamento entre atividades no Modelo V. ..................................................... 57
Figura 13: Modelo V aplicado de forma incremental............................................................... 58 Figura 14: Exemplo de uma estrutura analítica de riscos. ........................................................ 63 Figura 15: Distribuição de riscos seguindo a taxonomia de riscos do SEI............................... 64
Figura 16: O nível de exposição ao risco diminui ao longo do projeto. ................................... 67 Figura 17: Dimensões da gestão de riscos. ............................................................................... 68
Figura 18: Fatores críticos de sucesso para a gestão de riscos em projetos. ............................ 70 Figura 19: O espectro da incerteza. .......................................................................................... 74
Figura 20: Passos da gestão de riscos em projetos de software proposto por Boehm. ............. 77 Figura 21: Linha do tempo da história da ISO. ........................................................................ 80
Figura 22: Modelo de referência para a gestão de riscos da ISO (ISO 31000). ....................... 83 Figura 23: Hierarquia dos recursos oferecidos pelo PMI para a gestão de riscos. ................... 84 Figura 24: Processo de gestão de riscos. .................................................................................. 90
Figura 25: Estrutura da TBRI. .................................................................................................. 97 Figura 26: Cinco áreas chave para análise dos riscos. .............................................................. 98
Figura 27: Bancarização dos países. ....................................................................................... 112 Figura 28: Número de agências por 100 mil adultos bancarizados ........................................ 113 Figura 29: Etapas do estudo de caso. ...................................................................................... 126
Figura 30: Construindo teorias a partir de um estudo de caso................................................ 128 Figura 31: Modelo teórico. ..................................................................................................... 132 Figura 32: Etapas da pesquisa. ............................................................................................... 144 Figura 33: Amostra da base de dados de projetos. ................................................................. 147
Figura 34: Encadeamento de evidências. ............................................................................... 149 Figura 35: Cronograma de atividades para desenvolvimento da dissertação. ........................ 153 Figura 36: Atividades do processo Identificar e Analisar Riscos. .......................................... 161 Figura 37: Como cadastrar um novo risco. ............................................................................ 162 Figura 38: Exemplo de registro de riscos utilizando template antigo da metodologia........... 163
Figura 39: Exemplo de boletim de projetos............................................................................ 164 Figura 40: Projetos cadastrados. ............................................................................................. 165 Figura 41: Riscos cadastrados. ............................................................................................... 166 Figura 42: Projetos ativos que possuem registro de riscos. .................................................... 167
Figura 43: Tela de cadastro do risco. ...................................................................................... 171
Figura 44: Campos disponíveis na base de dados de riscos ................................................... 172 Figura 45: Matriz de probabilidade x impacto dos riscos do projeto. .................................... 173
Figura 46: Visão geral dos processos da metodologia de gestão de projetos. ........................ 179 Figura 47: Macro fluxo do processo de gestão de demandas. ................................................ 184 Figura 48: Categorização dos projetos – distribuição por tipo. .............................................. 185 Figura 49: Principais riscos reportados pelos entrevistados. .................................................. 193 Figura 50: Pesquisa interna realizada pela área de qualidade. ............................................... 194
Figura 51: Processo de gestão de riscos. ................................................................................ 195 Figura 52: Cálculo do nível de exposição ao risco. ................................................................ 195 Figura 53: Visão gerencial do projeto. ................................................................................... 196 Figura 54: Riscos vencidos e exposição ao risco. .................................................................. 196 Figura 55: Gráfico de nuvem da frequência de palavras. ....................................................... 198
Figura 56: Gráfico de distribuição dos riscos conforme a taxonomia do SEI. ....................... 202 Figura 57: Estrutura analítica dos riscos do portfólio de projetos selecionados. ................... 204
Figura 58: Critérios de sucesso dos projetos de software. ...................................................... 209 Figura 59: Manual de desempenho dos projetos. ................................................................... 210 Figura 60: Indicador de desempenho dos projetos. ................................................................ 211 Figura 61: Seção riscos e problemas do status report do programa A. .................................. 214
Figura 62: Seção riscos e problemas do status report do programa B. .................................. 215 Figura 63: Seção riscos e problemas do status report do programa C. .................................. 216
Figura 64: Indicadores corporativos de gestão de projetos de software. ................................ 217 Figura 65: Modelo STOp de gestão de riscos para projetos de software. .............................. 219 Figura 66: Análise SWOT. ..................................................................................................... 229
LISTA DE TABELAS
Tabela 1: Perdas operacionais significativas no sistema financeiro. ........................................ 23 Tabela 2: Notícias sobre falhas nos sistemas de instituições financeiras brasileiras................ 24 Tabela 3: Principais categorias de riscos que serão gerenciadas e divulgadas em 2014. ......... 29 Tabela 4: Fatores de sucesso em projetos pequenos
a. ............................................................. 35
Tabela 5: Principais associações de gestão de projetos e seus modelos. .................................. 39
Tabela 6: Síntese dos sete princípios do PRINCE2. ................................................................. 43
Tabela 7: Síntese dos sete temas do PRINCE2. ....................................................................... 44
Tabela 8: Síntese dos sete processos do PRINCE2. ................................................................. 45 Tabela 9: Lista dos modelos de maturidade em gestão de projetos.......................................... 48 Tabela 10: Algumas das principais metodologias de desenvolvimento de software. .............. 54 Tabela 11: Sugestão de categorias de riscos em uma instituição financeira. ........................... 61 Tabela 12: As incertezas podem impactar o sucesso de um novo produto (exemplos). .......... 66
Tabela 13: Principais riscos em projetos de TI......................................................................... 71
Tabela 14: Exemplo de monitoramento dos principais riscos de um projeto de software. ...... 92 Tabela 15: Exemplo parcial de uma lista de verificação utilizando EAR como referência. .... 96 Tabela 16: Principais facilitadores e inibidores do alinhamento estratégico.......................... 104
Tabela 17: Critérios para avaliação da maturidade do alinhamento entre TI e negócios. ...... 104 Tabela 18: Definições de governança de TI. .......................................................................... 107
Tabela 19: Síntese do referencial teórico sobre o tema GESTÃO ESTRATÉGICA DE TI. . 114
Tabela 20: Síntese do referencial teórico sobre o tema GESTÃO DE PROJETOS DE TI. .. 116
Tabela 21: Síntese do referencial teórico sobre o tema GESTÃO DE RISCOS DE TI. ........ 118 Tabela 22: Situações relevantes para diferentes métodos de pesquisa. .................................. 124 Tabela 23: Aspectos relevantes identificados no referencial teórico (premissa 1). ................ 133
Tabela 24: Aspectos relevantes identificados no referencial teórico (premissa 2). ................ 134 Tabela 25: Aspectos relevantes identificados no referencial teórico (premissa 3). ................ 136
Tabela 26: Tipos de projetos para estudos de caso. ................................................................ 138 Tabela 27: Pontos fortes e fracos das fontes de evidências utilizadas no estudo. .................. 140 Tabela 28: Vinculação dos dados às proposições. .................................................................. 140 Tabela 29: Perfil dos entrevistados e dados das entrevistas. .................................................. 155
Tabela 30: Respostas à pergunta 1. ........................................................................................ 158 Tabela 31: Respostas às perguntas 2a e 2b. ............................................................................ 168
Tabela 32: Respostas às perguntas 3a e 3b. ............................................................................ 174 Tabela 33: Status dos Projetos. ............................................................................................... 180 Tabela 34: Respostas às perguntas 4a e 4b. ............................................................................ 181 Tabela 35: Respostas às perguntas 5a, 5b e 5c. ...................................................................... 187 Tabela 36: Frequência de palavras. ........................................................................................ 197
Tabela 37: Respostas à pergunta 6. ........................................................................................ 199 Tabela 38: Distribuição dos riscos conforme a taxonomia do SEI......................................... 201 Tabela 39: Respostas à pergunta 7. ........................................................................................ 205 Tabela 40: Respostas à pergunta 8. ........................................................................................ 212 Tabela 41: Análise SWOT. ..................................................................................................... 231
Tabela 42: Visão geral da TBRI – Taxonomy-Based Risk Identification. .............................. 245 Tabela 43: Lista de assertivas sugeridas pelo GTAG12. ........................................................ 248
Tabela 44: Parte 1 – Dados do entrevistado. .......................................................................... 250 Tabela 45: Parte 2 – Roteiro de entrevista. ............................................................................. 250
LISTA DE ABREVIATURAS E SIGLAS
BACEN: Banco Central do Brasil
CCTA: The Central Computer and Telecommunications Agency
CMM: Capability Maturity Model
CMMI: Capability Maturity Model Integration
CMN: Conselho Monetário Nacional
CPI: Cost Performance Index
CRO: Chief Risk Officer
IEC: International Electrotechnical Commission
IEEE: Institute of Electrical and Electronics Engineers
ITGI: Information Technology Governance Institute
FEBRABAN: Federação Brasileira de Bancos
GTAG12: Global Technology Audit Guide 12: Auditing IT Projects
IBGC: Instituto Brasileiro de Governança Corporativa
IIA: Institute of Internal Auditors
IPMA: International Project Management Association
ISACA: Information Systems Audit and Control Association
ISO: International Organization for Standardization
MDS: Metodologia de Desenvolvimento de Software
MGP: Metodologia de Gestão de Projetos
OGC: The Office of Government Commerce
OPM3: Organizational Project Management Maturity Model
ORX: Operational Riskdata eXchange Association
PwC: PricewaterhouseCoopers
P3M3: Portfolio, Programme and Project Management Maturity Model
PMBOK: Project Management Body of Knowledge
PMI: Project Management Institute
PRINCE2: Projects in a Controlled Environment
SEI: Software Engineering Institute
SUSEP: Superintendência Nacional de Seguros Privados
SPI: Schedule Performance Index
TBQ: Taxonomy-Based Questionnaire
TBRI: Taxonomy-Based Risk Identification
TI: Tecnologia da Informação
17
1 INTRODUÇÃO
1.1 APRESENTAÇÃO
A gestão de projetos é uma disciplina recente no campo da administração. As primeiras
associações e instituições surgiram na década de 1960, mas foi a partir da década de 1990 que foi
observado um crescimento expressivo no número de seus associados, fato que colaborou com a
expansão dos estudos acadêmicos e profissionais na área (Carvalho & Rabechini, 2011).
Turner (2009) comenta que 30% da economia global é baseada em projetos. Segundo
pesquisa realizada pela PricewaterhouseCoopers (2012), em que participaram 1.524 gerentes e
executivos envolvidos com a gestão de projetos, programas e portfólio de 38 países, foi
verificado que 97% dos respondentes concordam que o gerenciamento de projetos é crítico para o
desempenho do negócio, crescimento e sucesso da organização; ou seja, as organizações
percebem que o gerenciamento adequado de projetos é uma estratégia para se manterem
competitivas.
Os conceitos de gerenciamento de projetos, apesar de relativamente modernos, vêm
sendo amplamente aplicados em diversos setores e organizações, tais como defesa, construção,
indústrias farmacêutica e química, setor bancário, hospitais, contabilidade, publicidade, direito,
governos e Nações Unidas (Kerzner, 2013).
Gerentes de projetos experientes entendem que nem todos os projetos podem ou devem
ser gerenciados da mesma forma, pois o setor da indústria, o tipo de organização e os requisitos
são únicos para cada projeto (Project Management Institute [PMI] & Institute of Electrical and
Electronics Engineers [IEEE], 2013). Mais especificamente com relação aos projetos de
tecnologia, o The Standish Group International publica anualmente o relatório CHAOS
Manifesto, que utiliza para sua análise uma base de dados com mais de 50.000 projetos de
tecnologia. O gráfico na Figura 1 apresenta a evolução desses projetos de 2004 a 2012, e, como
18
pode ser observado, nesse período menos da metade dos projetos de tecnologia foi concluído com
sucesso.
Apesar da taxa de sucesso ter aumentado nos últimos anos, em 2012, por exemplo, nota-
se que somente 39% dos projetos foram concluídos com sucesso (entregues no prazo, dentro do
orçamento, com a qualidade esperada e funções necessárias), 43% apresentaram algum tipo de
problema (atraso, estouro do orçamento, falta de qualidade e/ou não entrega de todas as funções
necessárias) e 18% falharam (foram cancelados antes da conclusão ou nunca foram utilizados).
Figura 1. Resultado dos projetos de tecnologia no período de 2004 a 2012.
Fonte: The Standish Group International, 2013.
A gestão de riscos é uma disciplina essencial para a tomada de decisões eficazes e
comunicação dos resultados dentro das organizações (International Organization for
Standardization [ISO] & International Electrotechnical Commission [IEC], 2006). Seu uso foi
incorporado à gestão de projetos na década de 1980, com a sua utilização em projetos norte-
-americanos de equipamentos de defesa, na construção civil e em indústrias de petróleo (Santos,
2007).
19
Rabechini e Carvalho (2013) realizaram uma pesquisa em quatro estados brasileiros com
415 profissionais de gerenciamento de projetos no período de 2008 a 2009 e identificaram que a
gestão de riscos em projetos influencia a percepção de sucesso dos projetos. Nesse estudo, a
percepção de sucesso do projeto estava relacionada com: (1) entregar o escopo planejado;
(2) garantir a qualidade do produto final; (3) atender às expectativas do cliente; e (4) satisfazer a
equipe de projeto.
A gestão de riscos orienta a tomada de decisões, da alocação da riqueza à salvaguarda da
saúde pública, da condução da guerra ao planejamento familiar e da contratação de um seguro ao
uso do cinto de segurança. A capacidade de definir o que poderá acontecer no futuro e de optar
entre várias alternativas faz parte do cotidiano das pessoas e das organizações (Bernstein, 1997).
Em instituições financeiras, gerir riscos é um processo muito desenvolvido,
principalmente em bancos e companhias seguradoras (Salles, Soler, Valle, & Rabechini, 2010).
Para um banco, a análise de risco é um componente fundamental para garantir a competitividade
e continuidade dos negócios. Por exemplo, para aprovar a concessão de um crédito para um
cliente, o banco deve prever, por meio de modelos matemáticos, qual a real possibilidade de
recebimento desse crédito e, para isso, utiliza robustos sistemas computacionais que analisam o
perfil do cliente em conjunto com dados históricos de variáveis mercadológicas.
Desde 1992 a Federação Brasileira de Bancos (FEBRABAN) realiza estudos com as
principais instituições financeiras com o objetivo de mapear o estágio da tecnologia bancária no
País e suas tendências. A pesquisa publicada em 2014 revelou que os gastos com tecnologia no
setor bancário brasileiro continuam crescendo em ritmo acelerado, 9% ao ano, em média, desde
2009 (Figura 2), somando R$20,6 bilhões em 2013. Em 2013 o Brasil gastou R$114,4 bilhões em
tecnologia, isso significa que os gastos realizados pelo setor bancário correspondem a 18% dos
gastos de tecnologia no Brasil e mantém o País como personagem relevante no cenário
internacional do setor de tecnologia bancária, superando outros mercados emergentes, como Índia
e México, e próximo a países desenvolvidos, como França e Alemanha (Federação Brasileira de
Bancos [FEBRABAN], 2014).
20
Figura 2. Gastos com tecnologia no setor bancário.
Fonte: FEBRABAN, 2014.
As despesas com software aumentaram em 20% no período de 2009 a 2013. Em 2013
passaram a representar 40% do total gasto com tecnologia, ou seja, R$8,2 bilhões (Figura 3). Isso
significa que 7,2% dos gastos com tecnologia no Brasil em 2013 foram investidos em projetos de
software no setor bancário. A aquisição e o desenvolvimento de softwares constituem a categoria
de gastos que mais cresceu, refletindo o aumento da demanda do negócio para ofertar produtos e
serviços aos clientes através de internet banking e mobile banking (FEBRABAN, 2014).
A crescente representatividade dos gastos com software é um indicativo da evolução do
setor e de sua contribuição para o desenvolvimento do mercado interno, gerando demanda por
profissionais especializados, com capacidade de estruturação e raciocínio lógico, conhecimento
em diversas plataformas de desenvolvimento, linguagens de programação, gestão de projetos e
gestão de riscos. Dentre os gastos de desenvolvimento de software, os novos
desenvolvimentos/manutenção evolutiva representam 65% dos gastos em 2013, seguido pela
manutenção corretiva/sustentação, representando 20% dos gastos (FEBRABAN, 2014).
Em 2013 as instituições financeiras anunciaram uma série de iniciativas visando às
melhorias de eficiência. Algumas delas até mesmo assumiram compromissos de metas nesse
sentido. Em geral, os programas de eficiência estabelecidos pelos bancos têm foco em redução de
custos, mudanças nas estruturas organizacionais, diminuição nos quadros de pessoal, ampliação
do nível de terceirização e reforço das estruturas de gestão de riscos (FEBRABAN, 2013b).
21
Figura 3: Tipo de gastos com tecnologia no setor bancário.
Fonte: FEBRABAN, 2014.
Segundo pesquisa da PricewaterhouseCoopers (2013), tais iniciativas são novas fontes
de riscos para o setor bancário e corroboram a necessidade de se investir cada vez mais em gestão
de riscos. A pesquisa apresenta diversas situações que ocorrem no dia a dia das empresas e são
fontes de novos riscos para a organização; entre elas destacam-se: (1) uma grande mudança:
crescimento, reestruturações ou novos mercados, produtos e parceiros criam novos riscos;
(2) maior complexidade na estrutura operacional: contratar novos prestadores de serviços ou
outros parceiros pode criar novos riscos ao negócio; e (3) maior dependência de tecnologia: o
uso de novas tecnologias e investimentos pode criar riscos associados com as interações internas
e externas.
1.2 PROBLEMATIZAÇÃO E QUESTÃO DE PESQUISA
Uma instituição financeira está sujeita a diversos tipos de riscos, entre eles: risco de
crédito, risco de imagem, risco de liquidez, risco de subscrição, risco estratégico, risco
22
operacional, risco socioambiental e risco de projeto (Marshall, 2002; McNally, 2013). Até o
momento, os órgãos reguladores dos sistemas financeiros internacional e nacional não criaram
uma normativa específica para a implantação de uma estrutura de gestão de riscos de projetos nas
instituições financeiras. Para tais órgãos, a classificação de risco mais próxima para os riscos de
projetos de software é o risco operacional (Deloitte, 2014).
A gestão de riscos é essencial para garantir a solidez de uma instituição financeira;
contudo, somente os riscos identificados podem ser analisados e monitorados adequadamente. Se
uma operação bancária está sujeita à regulamentação de órgãos externos, tais como CMN
(Conselho Monetário Nacional), Banco Central do Brasil (Bacen) e auditorias externas, e esses
órgãos devem, entre outras funções, monitorar como os bancos estão controlando seus riscos, é
factível que os riscos de projetos de software que envolvem bilhões de reais também sejam
monitorados.
A Resolução do CMN nº 3.380, de 2006, que está em linha com a definição do Acordo
de Capitais Basileia II, define que risco operacional é a possibilidade de ocorrência de perdas
resultantes de falha, deficiência ou inadequação de processos internos, pessoas e sistemas, ou de
eventos externos. Entre os eventos de risco operacional podem-se destacar falhas em sistemas de
tecnologia da informação e falhas na execução, no cumprimento de prazos e na gestão das
atividades na instituição. A estrutura de gestão do risco operacional deve prever identificação,
avaliação, monitoramento, controle e mitigação do risco operacional (Aaltonen, 2012).
Marshall (2002, p. 270) esclarece como a gestão de riscos de projetos diferencia-se da
gestão de risco operacional:
A gerência de projeto está se tornando mais importante dentro das empresas de serviços
financeiros à medida que um maior número de atividades se tornam únicas e não repetidas e à
medida que as empresas se direcionam à habilitação individual e organizações mais
horizontalizadas. Um aspecto crítico da gerência de projeto é a avaliação dos riscos do projeto,
necessária sempre que a empresa se vê frente a novos procedimentos ou processos, mudanças
gerenciais, mudanças de pessoal, programas novos ou únicos ou mudanças no padrão dos
problemas. Infelizmente, a gerência dos riscos de projetos se torna especialmente difícil por sua
natureza de execução única. Ela envolve tarefas não familiares com riscos não familiares,
muitas vezes com pessoas não familiarizadas uma com as outras e uma estrutura organizacional
com metas de projeto mal definidas. Tudo isto se combina para exacerbar os riscos. Mais ainda,
a identificação e a medição podem ser mais difíceis para riscos de projeto do que para os riscos
operacionais continuados. Existem duas razões para isto. A primeira, a ausência de dados
históricos torna a análise detalhada não confiável. A segunda, a ordem das atividades no projeto
faz diferença no nível de risco do projeto. Isto raramente é verdade nos processos operacionais,
para os quais podemos pressupor um estado estável, baseado em uma longa experiência com o
processo.
23
A Tabela 1 apresenta algumas perdas operacionais significativas que ocorreram nos
últimos anos no sistema financeiro internacional.
Tabela 1: Perdas operacionais significativas no sistema financeiro.
Classificação Ano Instituição
financeira
Valor
(US$ milhões) Descrição
Fraude interna 2008 Societé Generale 6.750
Manipulação dos registros de
negociação de operações ocultou perdas
no mercado de futuros, que se
acumularam.
Fraude interna 1995 Barrings 1.298
Manipulação dos registros de
negociação de operações ocultou perdas
no mercado de derivativos, que se
acumularam.
Fraude externa 1999 Republic New York 611 Fraude cometida por cliente de custódia.
Falhas em
sistemas 2004 Sumitomo Mitsui 350
Uso de key-logger, programa capturador
do que se digita para acesso a senhas e
desvio de recursos.
Demandas
trabalhistas 2004 Merril Lynch 250
Acordo extrajudicial por discriminação
a mulheres no trabalho.
Danos a ativos
físicos 2001 Bank of New York 140
Danos monetários pelo atentado de 11
de setembro.
Nota. Fonte: Aaltonen, 2012.
A Operational Riskdata eXchange Association (ORX – Bolsa Internacional de Troca de
Dados de Perdas Operacionais) é uma organização sem fins lucrativos dedicada ao avanço da
mensuração e gestão do risco operacional no mercado financeiro global. Foi fundada em 2002
com o objetivo principal de criar uma plataforma para a troca segura e anônima de dados de alta
qualidade sobre perdas com riscos operacionais e é controlada por 66 bancos de 20 países, entre
eles: Banco Bradesco S.A., Banco do Brasil S.A., Banco Votorantim S.A., Itaú Unibanco S.A. e
Grupo Santander (http://www.orx.org, recuperado em 9 novembro, 2014). A ORX divulgou que
o valor médio das perdas operacionais registradas entre 2002 e 2007 por falhas de sistemas e
gestão inadequada de atividades nos bancos correspondeu a 0,6% do total de suas receitas brutas
(Superintendência Nacional de Seguros Privados [SUSEP], 2012).
Muitos projetos no Brasil são desenvolvidos sem que haja o adequado uso de
metodologias e/ou modelos de gestão de risco. A não utilização de uma gestão de riscos eficaz
pode causar inúmeras perdas nos projetos, de caráter financeiro e de recursos, com intensidade e
impactos variáveis (Rovai, 2005).
24
Na Tabela 2 encontram-se algumas notícias publicadas nos jornais sobre falhas nos
sistemas de instituições financeiras brasileiras.
Tabela 2: Notícias sobre falhas nos sistemas de instituições financeiras brasileiras.
Jornal Data Notícia
Terra 27/01/2012 IPVA: troca de bancos e falha em sistema gera confusão no RJ. Troca
de bancos para emissão de guias, do Itaú para o Bradesco, e a posterior
falha na migração do sistema via Detran do Imposto sobre a Propriedade
de Veículos Automotores (IPVA), no Rio de Janeiro, trouxeram
problemas para os contribuintes que quiseram deixar em dia a
documentação do carro (Naddeo, 2012).
Portal T1 Notícias 09/03/2013 Por falhas em sistema de banco, cartões de servidores continuam
bloqueados. Os 1.645 servidores públicos do Estado de Tocantins que
contraíram empréstimos consignados no Banco Bonsucesso tiveram seus
cartões bloqueados; isso porque, devido a uma falha no sistema do banco,
mesmo o Estado tendo feito o desconto em folha, o pagamento não foi
creditado (Pereira, 2013).
Folha de São Paulo 26/08/2013 Brechas em sites do Bradesco e do Banco do Brasil expõem milhões de
clientes. Diferentes brechas de segurança encontradas nos sites do Banco
do Brasil, do Bradesco, do serviço de pagamentos Moip e da Boa Vista
Serviços (administradora do cadastro de devedores SCPC) expuseram
recentemente dados privados de milhões de pessoas (Gonzaga, 2013).
Folha de São Paulo 10/12/2013 Falha em aplicativos do Banco do Brasil expõe contas de clientes. Uma
falha na implantação de um aplicativo do Banco do Brasil para iPhone e
Android em 09/12/2013 permitiu que usuários tivessem acesso a extratos e
a dados de outros clientes que também estivessem usando o aplicativo no
mesmo momento (Gonzaga, 2013).
Sindicato dos
Bancários Bahia
16/12/2013 Nova falha no sistema do Banco do Brasil. No dia 15/12/2013 os caixas
eletrônicos e o internet banking ficaram fora do ar, impossibilitando a
realização de operações (Sindicado Bancários Bahia, 2013).
Portal IG 02/01/2014 Problema no Itaú gerou cobrança em dobro na véspera do Ano Novo. Um problema no sistema de processamento do Itaú gerou duplicidade de
algumas compras feitas com cartão de débito por clientes do banco
(Almeida, 2014).
Valor Econômico 24/09/2014 Pane derruba faturamento da Allianz no país. A seguradora alemã
Allianz perdeu quase 40% do faturamento de seguros de sua operação
brasileira no primeiro semestre decorrente de problemas na troca de seu
sistema operacional no começo deste ano. Clientes ficaram sem
atendimento e corretores não conseguiam fazer negócios (Folego, 2014).
Nota. Fonte: elaborado pelo autor.
Alberts e Dorofee (2012), com a equipe de engenheiros do Software Engineering
Institute (SEI), identificaram que, embora a maioria das organizações utilize a gestão de riscos
durante o desenvolvimento de projetos de software críticos, falhas evitáveis continuam a ocorrer
em um ritmo alarmante. Em muitos casos, as causas dessas falhas podem ser atribuídas às
deficiências nas práticas de gestão de risco utilizadas pelos gestores dos projetos e suas
organizações. Por exemplo, por meio de avaliações independentes os autores observaram que
diversos riscos significativos não são levados ao conhecimento dos tomadores de decisão.
25
Quando os tomadores de decisão não têm conhecimento dos riscos, eles são incapazes de tomar
medidas para mitigá-los.
Entre os processos de gestão de riscos, o processo de identificação de riscos é a origem
de todo o processo e exige um elevado grau de conhecimento e criatividade, demandando a
opinião de especialistas (Chapman & Ward, 2004; Chapman, 1990). Uma ferramenta muito útil
que pode ajudar os gerentes de projetos a serem mais assertivos na identificação de riscos é a
utilização de uma lista com os riscos de maior probabilidade e impacto gerados a partir de bases
históricas de sua organização e/ou ramo de atividade (Holzmann & Spiegler, 2011).
Existem listas genéricas com o principais riscos de projetos de software (Boehm, 1991;
Koolmanojwong & Boehm, 2013). Entretanto, Holzman e Spiegler (2011) demonstraram que
organizações que possuem bases de dados históricas podem gerar suas próprias listas com os
maiores riscos desses projetos, ou seja, são listas específicas que refletem, além das
características do tipo de projeto, a realidade da organização e/ou de um setor.
Os projetos de software em uma instituição financeira são utilizados como instrumento
para materializar a estratégia da organização, sendo assim, o sucesso desses projetos é
fundamental para garantir o avanço da organização a um novo patamar de serviços e produtos.
Apesar de sua importância estratégica, observa-se na mídia e na pesquisa do The Standish Group
International que diversos projetos de software fracassam tanto em organizações financeiras
quanto em outros tipos de organizações.
Para melhorar o sucesso dos projetos de software, é necessário aplicar os processos de
gestão de riscos de forma contínua e metodológica ao longo de todo o ciclo de vida do projeto. O
uso adequado desses processos é fundamental na fase de planejamento, pois os riscos
identificados logo no início do projeto são insumos importantes para garantir estimativas de custo
e prazo reais, além de determinar a viabilidade econômico-financeira do projeto (Rovai, 2005).
Depreende-se que um dos desafios dos gestores de projetos de software, não é apenas
entregar os projetos, mas entregá-los com qualidade cumprindo o planejamento de custo, escopo
e prazo. Para isso torna-se necessária a utilização de técnicas e ferramentas de gestão de riscos
adaptadas à realidade desses profissionais.
A fim de direcionar a realização do estudo, foi formulada a seguinte questão de
pesquisa:
26
– Como deve ser estruturado um modelo de gestão de riscos que seja aplicável a projetos
de software no setor bancário brasileiro?
1.3 OBJETIVO DA PESQUISA
Esta pesquisa tem como objetivo principal propor um modelo de gestão de riscos que
seja aplicável a projetos de software no setor bancário brasileiro.
Como objetivos específicos destacam-se os seguintes:
a) Definir os critérios necessários para agrupar os riscos identificados e armazenados em
bases históricas de projetos de software.
b) Agrupar os riscos dos projetos de software permitindo identificar e priorizar os
principais riscos.
c) Apresentar aos executivos uma visão estratégica dos principais riscos de projetos de
software.
1.4 RELEVÂNCIA DO TEMA E JUSTIFICATIVA
Segundo Boehm and DeMarco (1997), gerenciar o risco de projetos de software faz
muito sentido, mas divulgar seus resultados para o mercado pode ter sérias implicações para uma
organização. Se um software falha, a existência de um plano formal de gestão de riscos que
reconhecia a possibilidade de tal falha poderia complicar, e até mesmo comprometer legalmente,
a organização e seus representantes. Esta é umas das razões que justifica a ausência de
publicações com dados históricos de riscos de projetos de software.
O objetivo desta dissertação é propor um modelo prescritivo, porque, de acordo com
Martins e Theóphilo (2009), o modelo é uma explicação da teoria. Trata-se de uma forma de
caracterizar as ideias fundamentais da teoria com o auxílio de conceitos conhecidos. Um modelo
tem as seguintes funções: (a) seletiva – permite que fenômenos complexos sejam visualizados e
27
compreendidos; (b) organizacional – classifica os elementos da realidade segundo um esquema;
(c) fertilidade – evidencia outras aplicações em distintas situações; (d) lógica – permite explicar
como ocorre o fenômeno; (e) normativa – permite prescrições; e (f) sistêmica – orienta os
procedimentos de forma sequencial e estruturada.
Modelos prescritivos são aqueles que indicam padrões a serem seguidos ou que relatam
as melhores práticas (Laurindo, Shimizu, Carvalho, & Rabechini, 2001), ou seja, definem um
conjunto prescrito de elementos organizados em um fluxo de trabalho previsível (Pressman,
2011, p. 59). Mesmo quando o que acontece for sem precedentes, em um modelo prescritivo, os
acontecimentos são valorizados por sua similaridade com o sistema constituído, trazendo ordem
ao caos existente (Sahlins, 1990, p. 13).
As questões referentes à gestão de riscos em projetos de software são um assunto
relativamente novo no Brasil, e frequentemente causam confusão e mal entendido entre os
profissionais brasileiros (Schmitz, Alencar, & Villar, 2007). Cada projeto tem suas características
únicas e é executado em um ambiente específico; logo, não existe um catálogo de riscos-padrão
que atenda a todos os tipos de projeto. Torna-se necessário que cada organização ou setor
desenvolva seu próprio catálogo para garantir maior assertividade na gestão de riscos. Os
problemas mais comuns em projetos dizem respeito a objetivos mal definidos, planejamento de
má qualidade, proposta malfeita, falhas na execução, má organização e também falta de técnicas
de controle empregadas pelo gerente do projeto (Maximiano, 2010).
Silva, Chamon e Camarini (2006) realizaram uma pesquisa na região do Vale do Paraíba
– SP. Foram entrevistados 16 profissionais (gerentes e coordenadores) que atuavam em projetos
de software. A amostra estava inserida em 11 organizações distintas operando nos setores da
indústria, serviços e governo. Foi verificado que os gerentes realizam o gerenciamento de risco
de modo intuitivo e informal, por meio dos mecanismos de controle usados para gerenciar outras
dimensões do projeto, como escopo, custos, prazos e aquisições. Entre as dificuldades para a
realização de um gerenciamento efetivo de riscos, os participantes da amostra indicaram os
prazos curtos, a falta de recursos e a falta de cultura e de conhecimento sobre a gestão de risco.
Percebeu-se, também, que alguns gerentes entendem o gerenciamento de risco como uma
auditoria similar àquelas realizadas pela área da qualidade.
28
Silva (2011), com o objetivo de selecionar artigos brasileiros e suas considerações sobre
o tema de riscos em projetos de sistemas de informação, realizou uma pesquisa on-line em 15
importantes periódicos nacionais. A pesquisa foi realizada utilizando-se o termo “risco” para a
busca e, na sequência, foi realizada a análise dos artigos apresentados no resultado da busca para
avaliar se estavam relacionados ao tema de riscos em projetos de software. Como resultado dessa
pesquisa constatou-se que não há artigos relevantes sobre o tema nos periódicos selecionados.
Leopoldino e Borenstein (2011) revisaram a literatura e não identificaram nenhum
trabalho no Brasil sobre a identificação de categorias de riscos em projetos de software. Sendo
assim, realizaram uma pesquisa com 81 profissionais brasileiros que atuavam em projetos de
software e, com base nos riscos identificados, sugeriram uma estrutura de riscos com sete
categorias.
A gestão de riscos dos negócios é algo que já faz parte da realidade das empresas
brasileiras – especialmente as que participam de setores regulados ou têm ações negociadas em
bolsa. A pesquisa “O estágio atual da gestão de riscos – estratégias e ações para o crescimento
sustentável”, realizada pela Deloitte (2014) com 84 empresas, sendo sete instituições financeiras
e a maioria das empresas de grande porte com faturamento anual acima de R$1 bilhão, dispõe-se
a mensurar o estágio de maturidade das práticas de gestão de riscos das empresas que atuam no
Brasil.
A pesquisa revelou que, apesar da falta de categorização dos riscos em projetos por parte
dos órgãos reguladores do setor financeiro, as organizações começaram a se preocupar com essa
categoria de riscos. Conforme pode ser observado na Tabela 3, a categoria “Investimentos e
projetos” passou a ser considerada uma das principais categorias de riscos que serão gerenciadas
pelas empresas em 2014, mas seus resultados não serão reportados ao mercado, pois não estão
relacionados a nenhuma lei ou regulamentação vigente. As categorias de riscos estão
classificadas por ordem de importância para os entrevistados.
A complexidade do mercado financeiro e suas regulamentações aumentam o desafio da
gestão de riscos em um banco. A complexidade é tamanha que 83% dos bancos brasileiros já
apresentam executivos na função de Chief Risk Officer (CRO) reportando-se diretamente ao
Presidente. O CRO é o executivo responsável pela área de gestão de riscos de uma empresa, algo
29
que envolve a identificação, a análise e a mitigação de ameaças internas e externas aos negócios
(FEBRABAN, 2013a).
Tabela 3: Principais categorias de riscos que serão gerenciadas e divulgadas em 2014.
Riscos gerenciados internamente Riscos reportados ao mercado
Aderência a regras Condições econômicas e tendências de indústria
Tributário e fiscal Mercados
Trabalhista Leis e regulamentações
Ética, fraude e canal de denúncia Concorrência
Fluxo de caixa Geopolítica
Reputação e imagem Ambiental, saúde e segurança
Segurança da informação Compliance legal e regulatório
Concorrência e mercado Gestão de contratos
Alçadas de aprovação Litígios e resolução de conflitos
Gestão de contratos Perigos e perdas catastróficas
Investimentos e projetos Reputação e relacionamento com as partes interessadas
Nota. Fonte: Deloitte, 2014.
Considerando a importância do setor bancário para o Brasil, a ausência de informações e
normativas sobre riscos em projetos no setor, a necessidade que esse tipo de organização tem de
gerir os riscos adequadamente e os altos investimentos em projetos de software, este estudo busca
auxiliar tanto pesquisadores quantos profissionais da área, contribuindo com a formação de uma
base de dados histórica sobre os riscos desses projetos.
Segundo Martins e Theóphilo (2009), uma questão de pesquisa pode ser motivada por
circunstâncias profissionais e esta foi justamente a fonte de inspiração para este estudo: a
dificuldade do autor em identificar riscos comuns aos projetos de software no ambiente de
trabalho. Esse interesse foi reforçado pelo artigo de Thamhain (2013), o qual explica que é
possível destacar três grupos de variáveis inter-relacionadas que devem ser consideradas na
gestão de riscos: grau de incerteza, complexidade e impacto. Entender essas variáveis é
importante para selecionar o modelo de gestão de riscos mais adequado, além das pessoas e
organizações necessárias para lidar eficientemente com a situação de risco específica.
Em síntese, os fatores que contribuíram para o interesse no desenvolvimento do tema
desta dissertação são os seguintes:
– Os modelos de referência desenvolvidos por renomados autores e instituições
internacionais não são específicos para o setor bancário brasileiro;
30
– Em uma instituição financeira a gestão de riscos é tão complexa e importante que
possui uma área executiva responsável por esse assunto;
– Em 2013, os valores investidos em projetos de software no setor bancário
representaram 7,2% dos gastos com tecnologia no Brasil (R$ 8,2 bilhões);
– O Brasil tem carência de estudos e bases históricas sobre riscos de projetos de
software.
1.5 ESTRUTURA DA DISSERTAÇÃO
Além deste capítulo introdutório, a dissertação está estruturada da seguinte forma:
– Capítulo 2 – Referencial Teórico.
Este capítulo contém a revisão da bibliografia organizada da seguinte forma:
. Gestão de Projetos de TI (Tecnologia da Informação) – conceitos, histórico, sucesso
em projetos de software, tipologia de projetos, modelos de referência em gestão de projetos,
modelos de maturidade em gestão de projetos e metodologias de software.
. Gestão de Riscos de TI – conceitos, histórico, categorização de riscos, riscos em
projetos, riscos em projetos de software, gestão de riscos em projetos, gestão de riscos em
projetos de software, modelos de referência em gestão de riscos e identificação dos riscos.
. Gestão Estratégica de TI – conceitos, histórico, alinhamento estratégico de TI e
negócios, governança de TI e o setor bancário brasileiro.
. Síntese do Referencial Teórico – resumo do referencial teórico organizado por tema,
subtema, autor e aspectos relevantes.
– Capítulo 3 – Metodologia da Pesquisa.
Neste capítulo apresentam-se os procedimentos metodológicos que orientaram a coleta e
análise de dados, bem como as limitações da pesquisa.
– Capítulo 4 – Análise e Interpretação dos Resultados.
31
Este capítulo apresenta a descrição dos achados da pesquisa e a verificação das
proposições realizadas.
– Capítulo 5 – Conclusões.
Este capítulo apresenta as conclusões e reflexões acerca dos dados analisados, sempre
considerando o referencial teórico existente e respondendo a questão de pesquisa.
– Capítulo 6 – Contribuições para a Prática.
Este capítulo apresenta uma Análise SWOT da organização estudada com base no
modelo proposto.
32
2 REFERENCIAL TEÓRICO
2.1 GESTÃO DE PROJETOS DE TI
2.1.1 Conceitos e Histórico
De acordo com o Project Management Institute (PMI, 2013a) um projeto pode ser
definido como um esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo e a gestão de projetos pode ser definida como a aplicação do conhecimento,
habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos.
Segundo o OGC (The Office of Government Commerce [OGC], 2009) um projeto pode
ser definido como uma organização temporária que é criada com o objetivo de entregar um ou
mais produtos de negócios em conformidade com o caso de negócios aprovado e a gestão de
projetos pode ser definida como o planejamento, delegação, monitoramento e controle de todos
os aspectos do projeto, e a motivação dos envolvidos, para alcançar os objetivos do projeto dentro
das metas de desempenho esperadas para o tempo, custo, qualidade, escopo, benefícios e riscos.
As últimas décadas têm sido caracterizadas por mudanças significativas. Nos anos 60 o
foco era a produção em massa onde as empresas de manufatura se esforçaram para aumentar a
produção com a introdução de novos métodos e sem grandes preocupações com a qualidade.
Durante os anos 70 o objetivo principal era produzir com qualidade e mantendo a alta
produtividade, impondo para isso uniformidade e restringindo a variedade de produtos. Nos anos
80 foi dada ênfase na variedade de produtos, pois os clientes queriam produtos diferenciados,
para isso as empresas introduziram sistemas flexíveis de manufatura enquanto mantinham a
qualidade e alta produção. Nos anos 90 os clientes queriam novidades, ao comprar um produto
novo não queriam um modelo antiquado e o tempo de desenvolvimento de produtos e sua via útil
no mercado encolheu requerendo que novos produtos fossem introduzidos rapidamente e de
maneira eficiente (Turner, 2009).
33
Agora os consumidores querem novas funcionalidades, um celular, por exemplo, não faz
somente ligações telefônicas, serve para enviar mensagens, e-mails, acessar internet, tocar
música, jogar jogos, tirar fotografias e outras coisas. As empresas precisam adotar estruturas
flexíveis para responder as mudanças do ambiente e para ganhar competitividade devem manter-
se em constante processo de melhoria de seus processos de negócios. Muitos clientes esperam
que todo produto seja feito sob medida e todo produto seja um mini projeto (Turner, 2009).
Acompanhando as mudanças que ocorreram nas organizações nas últimas décadas, a
gestão de projetos também tem evoluído. Foi a partir da década de 60 que surgiram as primeiras
associações dedicadas ao estudo do gerenciamento de projetos, como o PMI e o International
Project Management Association (IPMA). Na década de 70 surgem softwares de apoio à Gestão
de Projetos que se consolidam na década seguinte. Nas décadas de 80 e 90 se consolidam as boas
práticas de gestão de projetos, inclusive na segunda metade da década de 90 observa-se um
crescimento acentuado das associações e instituições de gerenciamento de projetos. Em 1996
surgiu a primeira edição do Project Management Body of Knowledge (PMBOK) que é o guia de
conhecimento em gerenciamento de projetos publicado pelo PMI. Ainda na década de 90 os
gerentes de projetos aprenderam a desenvolver seus empreendimentos, administrando
isoladamente escopo, prazo, custos e qualidade. A partir da virada do milênio observa-se que é
necessário aprimorar algumas áreas de conhecimento, como é o caso da gestão de riscos em
projetos (Carvalho & Rabechini, 2011).
2.1.2 Sucesso em Projetos
Bakker, Doonstra e Wortmann (2010) estudaram a evolução do conceito de sucesso para
projetos de software. De acordo com suas pesquisas bibliográficas, o conceito tradicional de
sucesso de projeto utilizando os critérios de custo, prazo e escopo é frequentemente utilizado em
publicações que estudam a relação entre a gestão de riscos e o sucesso dos projetos de software.
Entre as 26 publicações analisadas no período de 1997 a 2009, todas utilizando dados empíricos,
aproximadamente dois terços ainda utilizam a tríplice restrição para avaliar o sucesso do projeto.
O sucesso em projetos é um assunto que gera bastante discussão, pois o sucesso de um
projeto pode ser avaliado por diversas perspectivas. Cada pessoa ou organização envolvida no
34
projeto pode ter um critério diferente para avaliar o sucesso do projeto, e muitas vezes, ao atender
o critério de uma pessoa ou organização específica, a avaliação dos demais grupos pode sofrer
impacto negativo (Carvalho & Rabechini, 2011).
O conceito mais tradicional para avaliar o sucesso em um projeto está baseado no
"triângulo de ferro", denominação da tríplice restrição: custo, prazo e escopo (também conhecida
como desempenho técnico). Dessa forma, para que um projeto seja considerado um sucesso, deve
ser realizado dentro do orçamento planejado, cumprir o cronograma estabelecido e entregar um
produto ou serviço conforme as especificações solicitadas pelas partes interessadas. Entretanto,
tal conceito de sucesso em projetos é ambíguo, pois por um lado existem projetos concluídos
dentro prazo e orçamento planejados que foram considerados um fracasso e, por outro lado
também existem projetos concluídos acima do prazo e orçamento planejados que foram
considerados um sucesso (Pinto & Slevin, 1988).
Figura 4: Avaliação do sucesso do projeto no tempo.
Fonte: Pinto & Slevin, 1988.
Pinto e Slevin (1988) abordam a importância de avaliar periodicamente o sucesso do
projeto, pois determinar seu sucesso ou fracasso somente ao final do projeto pode ser desastroso.
Conforme Figura 4, os autores organizam no tempo o sucesso do projeto em duas perspectivas:
(1) projeto – são os fatores internos ao projeto – custo, prazo e escopo – que determinam sua
eficiência, ou seja, o projeto é realizado pela equipe conforme planejado; e (2) cliente – são os
fatores externos ao projeto que determinam a eficácia do produto ou serviço gerado pelo projeto,
35
ou seja, o resultado do projeto gera os benefícios esperados pelo cliente. Os fatores externos são:
uso – o projeto será ou está sendo utilizado adequadamente pelos clientes; satisfação – o cliente
está satisfeito com as entregas intermediárias e finais do projeto; e eficácia – os benefícios
esperados serão ou estão sendo colhidos.
O Standish Group acompanha a evolução do sucesso dos projetos de software desde
1985 utilizando as variáveis da tríplice restrição como fatores de sucesso. Na publicação de 2013
observa-se um aumento no número de projetos pequenos e ágeis e diminuição dos projetos
maiores que utilizam metodologias de desenvolvimento de software em cascata
(desenvolvimento sequencial onde as entregas são realizadas somente ao término do projeto).
Para acompanhar esta mudança no ambiente de desenvolvimento de software e respeitar as
características dos projetos ágeis, o Standish Group criou uma versão especial dos fatores de
sucesso para estes projetos. A Tabela 4 descreve estes fatores e seu respectivo peso no cálculo da
taxa de sucesso do projeto.
Tabela 4: Fatores de sucesso em projetos pequenos a.
Fator de sucesso Descrição Pontos
Suporte do executivo
A pessoa mais importante em um pequeno projeto é o patrocinador (executivo),
sendo assim, o patrocinador é o principal responsável pelo sucesso ou fracasso
do projeto.
20
Envolvimento do
usuário
As pesquisas demonstram claramente que os projetos que não possuem o
envolvimento adequado do usuário apresentam baixo desempenho. A
participação do usuário tem um papel fundamental na resolução de problemas.
15
Desempenho Escopo de trabalho pequeno, bem definido e com baixa complexidade permite
entregas rápidas com sucesso. 15
Recursos qualificados Um projeto é feito de pessoas e a equipe do projeto é peça chave para garantir o
sucesso do projeto. 13
Experiência em gestão
de projetos
O controle do progresso dos pequenos projetos é essencial para garantir a
colaboração entre a equipe do projeto e os usuários. 12
Processos ágeis
Utilização da filosofia dos projetos ágeis e adequada utilização dos processos
para garantir o envolvimento do usuário, suporte do executivo e outros fatores
de sucesso.
10
Outros Objetivos do negócio claros; maturidade emocional; execução; e ferramentas e
infraestrutura. 15
Nota. Fonte: adaptado de The Standish Group International, 2013. a Projetos pequenos são aqueles onde o custo com a força de trabalho é inferior a US$ 1milhão e projetos grandes são
aqueles onde o custo com a força de trabalho é superior a US$10 milhões.
Segundo Agarwal and Rathod (2006) o sucesso é um fenômeno relativamente raro no
mundo dos projetos de software. Os autores realizaram uma pesquisa e identificaram que existe
uma grande diferença na percepção do significado de sucesso nas mentes das pessoas que
avaliam o desempenho do projeto de software. Os stakeholders externos ao projeto entendem que
36
realizar o custo e prazo planejados significa o sucesso do projeto; entretanto, para os stakeholders
internos (desenvolvedores, gerentes de projeto e gerentes de conta) o mais importante é entregar
o escopo solicitado com a qualidade necessária.
Para o PMI (2013a) o sucesso do projeto deve ser medido em termos da sua conclusão
dentro das restrições de escopo, tempo, custo, qualidade, recursos e risco, conforme aprovado
entre os gerentes de projetos e a equipe sênior. Para garantir a realização dos benefícios do
projeto empreendido, um período de teste pode ser parte do tempo total do projeto antes da sua
entrega para operação permanente. O sucesso do projeto deve referir-se às últimas linhas de base
aprovadas pelas partes interessadas autorizadas.
2.1.3 Tipologia de Projetos
Patah (2010) descreve a importância da classificação dos projetos:
Com o objetivo de avaliar e comparar o sucesso nos projetos é necessário classificá-los segundo
critérios pré-definidos. Além do próprio levantamento dos critérios, é necessário identificar os
projetos e as informações relacionadas aos mesmos que permitam a aplicação dos critérios.
Crawford, Hobbs e Turner (2006) explicam que as organizações que realizam muitos
projetos precisam identificar seus tipos de projetos e criar um sistema de categorização de
projetos adequado a sua realidade, pois dessa forma é possível descrever e comparar os projetos
entre si. Para isso criaram um modelo que permite às organizações examinarem seus sistemas de
categorização de projetos existentes, entenderem melhor como eles funcionam e orientar como
estes sistemas podem ser reorganizados. As principais razões para isso são:
– Garantir o alinhamento estratégico: priorizar os melhores projetos para maximizar o
retorno do investimento do portfólio de projetos; e controlar a eficácia dos investimentos em
projetos;
– Desenvolver as competências corretas: conhecer suas áreas de atuação estratégica;
desenvolver as competências necessárias para realizar o projeto com sucesso; alocar os recursos e
fornecer as ferramentas adequadas para o projeto;
– Diferenciar os projetos das operações rotineiras;
37
– Diferenciar projetos, programas e portfólio de projetos;
– Fornecer uma linguagem comum;
– Criar uma cultura de gestão de projetos.
Segundo Padovani (2007), uma forma bastante simples de classificar os projetos dentro
de uma organização é organizá-los conforme sua finalidade, por exemplo: manutenção,
infraestrutura de P&D, informática ou engenharia. Segundo pesquisa realizada por Castro e
Carvalho (2010) com 31 participantes de diversas empresas brasileiras, identificou-se que 74%
das organizações pesquisadas adotam a categorização de projetos por finalidade, com destaque
para os projetos de desenvolvimento de tecnologia e de sistemas de informação, conforme
apresentado na Figura 5. É importante destacar que existe uma concentração de respostas
oriundas de empresas do setor financeiro (26%).
Figura 5: Projetos categorizados por finalidade.
Fonte: Castro & Carvalho, 2010.
Shenhar e Dvir (2007) fazem uma crítica ao modelo processual tradicional de gestão de
projetos e sugerem uma abordagem contingencial que considere as diferentes características dos
projetos. A Figura 6 apresenta graficamente o modelo. O modelo NTCP (Novidade, Tecnologia,
Complexidade e Passo), também conhecido como modelo Diamante, sugere que o estilo de
gestão de projetos deve ser adaptado ao tipo de projeto. Para isso os autores sugerem que os
projetos sejam classificados de acordo com quatro dimensões:
38
Figura 6: Modelo diamante.
Fonte: Shenhar & Dvir, 2007.
(1) novidade – representa as incertezas do objetivo do projeto e do mercado. Busca
medir se os produtos ou serviços resultantes do projeto são novos para os clientes, usuários ou
mercado em geral, além do nível de clareza dos requisitos do produto na fase de planejamento do
projeto. O tempo disponível para concluir os requisitos do produto e a acurácia e confiabilidade
dos dados de mercado determinam a estrutura de gestão necessária para conduzir o projeto;
(2) tecnologia – representa o nível de incerteza existente na tecnologia necessária para
desenvolver o projeto, ou seja, quanto mais nova a tecnologia, maiores os riscos para o projeto e
maior a quantidade de controles necessários para garantir o sucesso do projeto. O tempo
disponível para concluir o desenho do projeto e a intensidade das atividades técnicas determinam
as habilidades técnicas necessárias tanto para o gerente do projeto quanto para a equipe;
(3) complexidade – representa não apenas a complexidade do produto, mas também os
processos, tarefas e organização do projeto. Afeta a organização do projeto e o nível de
burocracia e formalidade necessária para realizar a gestão conforme esperado;
39
(4) Passo – representa a urgência do projeto, ou seja, quanto tempo disponível existe
para completar o trabalho. Impacta o tempo disponível para as fases de planejamento e revisões, a
autonomia da equipe do projeto, e os projetos mais urgentes exigem maior envolvimento da
gerência sênior.
Rabechini e Carvalho (2009) realizaram uma revisão da literatura para analisar o
relacionamento entre os fatores críticos de sucesso e as tipologias de projeto. A proposição da
pesquisa sugeria que os fatores críticos de sucesso não são absolutos, mas sim relativos às
contingências dos projetos, ou seja, alguns fatores seriam mais significativos para o sucesso,
conforme a tipologia de projeto. Verificou-se com este estudo que a abordagem contingencial de
gestão de projetos tem crescido; entretanto, o relacionamento entre a literatura de fatores críticos
de sucesso com a abordagem contingencial não se apresentou consolidada.
2.1.4 Modelos de Referência em Gestão de Projetos
Segundo Patah (2010), existem diversos modelos de referência de gestão de projetos
disponíveis para utilização por profissionais e organizações. Os modelos mais difundidos são
disponibilizados por institutos e associações dedicados ao estudo de projetos e podem ser
observados na Tabela 5.
Tabela 5: Principais associações de gestão de projetos e seus modelos.
Instituto Modelo País de
origem Foco Website
PMI – Project
Management Institute
Project Management Body
of Knowledge (PMBoK)
EUA Gestão geral de
projetos
www.pmi.org
IPMA –International
Project Management
Association
ICB – IPMA Competence
Baseline
União
Europeia
Gestão geral de
projetos
www.ipma.ch
AIPM – Australian
Institute of Project
Management
AIPM – Professional
Competency Standards for
Project Management
Austrália Gestão geral de
projetos
www.apm.org.uk
OGC – Office of
Government Commerce
PRINCE2 – Projects in
Controlled Environments
Reino
Unido
Gestão de
projetos de
sistemas de
informação
http://www.prince-
officialsite.com
JPMF – Japan Project
Management Forum
ENAA Model Form-
International Contract for
Process Plant Construction
Japão Gestão de
projetos de
construções
www.enaa.or.jp
Nota. Fonte: Patah, 2010.
40
Nesta dissertação serão abordados o modelo do PMI que é a instituição com maior
número de associados no Brasil e o modelo do OGC que tem foco em projetos de software.
2.1.4.1 PMBOK – Project Management Body of Knowledge
O PMI (Project Management Institute) foi criado nos EUA em 1969, é uma instituição
sem fins lucrativos dedicados ao avanço do gerenciamento de projeto contando com um conjunto
de normas direcionadas a esse tema. Em 1987, o PMI publicou a primeira versão do PMBOK,
documento que busca fornecer uma referência básica do conhecimento das práticas de
gerenciamento de projetos. Atualmente, o mesmo encontra-se em sua quinta edição, publicada
em 2013. Este documento é aceito pela ANSI (American National Standard Institute) (Patah,
2010).
O PMBOK fornece diretrizes para o gerenciamento de projetos individuais e define os
conceitos relacionados com o gerenciamento de projetos. Ele também descreve o ciclo de vida de
gerenciamento de projetos e seus respectivos processos, assim como o ciclo de vida do projeto. O
PMI e o IEEE Computer Society firmaram uma parceria e elaboraram o guia Software Extension.
Este guia complementa o PMBOK e fornece diretrizes para os gestores de projetos de software
(PMI, 2013a; PMI & IEEE, 2013).
O PMBOK (2013a) descreve 47 processos necessários para a gestão de projetos. Cada
processo possui entradas, ferramentas ou técnicas e gera uma ou mais saídas. Os processos estão
organizados em cinco grupos de processos e 10 áreas de conhecimento. A Figura 7 apresenta o
relacionamento entre os grupos de processo:
(1) iniciação – são os processos executados para definir um novo projeto ou uma nova
fase de um projeto existente através da obtenção de autorização para iniciar o projeto ou fase;
(2) planejamento – são os processos necessários para definir o escopo do projeto, refinar
os objetivos e definir a linha de ação necessária para alcançar os objetivos do projeto;
(3) execução – são os processos realizados para executar o trabalho definido no plano de
gerenciamento do projeto e satisfazer as especificações do projeto;
41
(4) monitoramento e controle – são os processos necessários para acompanhar, analisar e
controlar o progresso e desempenho do projeto, identificar as áreas onde serão necessárias
mudanças no plano, e iniciar as mudanças correspondentes;
(5) encerramento – são os processos executados para finalizar todas as atividades de
todos os grupos de processos, fixando encerrar formalmente o projeto ou fase.
Figura 7: Grupos de processos do PMBOK.
Fonte: PMI, 2013a.
As dez áreas de conhecimento estão organizadas da seguinte forma:
(1) integração – descreve os processos e atividades necessários para identificar, definir,
combinar, unificar e coordenar os vários processos e atividades dentro dos grupos de processos.
Inclui características de unificação, consolidação, comunicação e ações integradoras que são
essenciais para a execução controlada do projeto até a sua conclusão, a fim de gerenciar com
sucessos as expectativas das partes interessadas, e atender aos requisitos;
(2) escopo – descreve os processos necessários para assegurar que o projeto contemple
todo e somente o trabalho requerido para completar o projeto com sucesso;
(3) tempo – descreve os processos necessários para assegurar a conclusão do projeto no
prazo definido;
(4) custo – descreve os processos envolvidos em planejamento, estimativas, orçamentos,
financiamento, gestão e controle dos custos, para assegurar que o projeto se encerrará dentro do
orçamento aprovado;
42
(5) qualidade – descreve os processos e as atividades da organização executora que
determinam as políticas de qualidade, os objetivos e as responsabilidades, de modo que o projeto
satisfaça às necessidades para as quais foi empreendido.
(6) recursos humanos – descreve os processos que organizam, gerenciam e guiam a
equipe do projeto para assegurar o melhor desempenho possível;
(7) comunicação – descreve os processos necessários para assegurar que as informações
do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas,
gerenciadas, controladas, monitoradas e finalmente dispostas de maneira oportuna e apropriada;
(8) riscos – descreve os processos necessários para planejamento, identificação, análise,
planejamento de respostas e controle dos riscos do projeto;
(9) aquisições – descreve os processos necessários para aquisição de bens, serviços e
resultados externos à equipe do projeto;
(10) partes interessadas – descreve os processos necessários para identificar todas as
pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar
as expectativas das partes interessadas e seu impacto no projeto, e desenvolver estratégias de
gestão apropriadas para o engajamento eficaz das partes interessadas nas decisões e execução do
projeto.
2.1.4.2 PRINCE2 – Projects in a Controlled Environment
PRINCE2 é um método baseado em processos para garantir a efetiva gestão de projetos.
Utilizado extensivamente pelo Governo do Reino Unido, o PRINCE2 é amplamente reconhecido
e utilizado internacionalmente pelo setor privado. Trata-se de um método de domínio público que
oferece um guia com as melhores práticas em gestão de projetos. As principais características do
método são: foco na justificativa do negócio; estrutura organizacional definida para o time de
gestão de projetos; abordagem do planejamento baseada no produto; ênfase na divisão do projeto
em estágios gerenciáveis e controláveis; e flexibilidade que pode ser aplicada a qualquer tipo de
projeto (http://pt.wikipedia.org/w/index.php?title=PRINCE2&oldid=37562711, recuperado em 7
março, 2014).
43
O método foi criado em 1989 com o nome PRINCE. Desenvolvido pela The Central
Computer and Telecommunications Agency (CCTA) que posteriormente passou a chamar-se The
Office of Government Commerce (OGC). Foi originalmente baseado no método de
gerenciamento de projetos PROMPT criado em 1975 pela Simpact Systems Limited e adotado
pela CCTA em 1979 como método padrão a ser utilizados em todos os projetos de sistemas de
informação do Governo do Reino Unido. A primeira versão do PRINCE2 foi publicada em 1996
com a contribuição de um consórcio de 150 organizações europeias e a última revisão foi
publicada em 16 de junho de 2009 pelo OGC com o nome PRINCE2:2009 Refresh. PRINCE2 é
uma marca registrada da AXELOS Limited que é uma joint venture entre o Gabinete do Governo
do Reino Unido e a empresa CAPITA (http://www.axelos.com, recuperado em 15 novembro,
2014).
A estrutura do PRINCE2 é composta por um conjunto de princípios, um conjunto de
temas de controle, um ciclo de vida do processo e orientações para combinar o método para o
ambiente do projeto. O ciclo de vida do processo é composto por um conjunto de atividades
necessárias para direcionar, gerenciar e entregar um projeto (Murray, 2011; OGC, 2009).
Tabela 6: Síntese dos sete princípios do PRINCE2.
Princípio Descrição
Justificativa contínua
do negócio.
A justificativa para início do projeto deve ser aprovada, documentada e manter-se válida até
o término do projeto.
Aprender com a
experiência.
A equipe do projeto aprende com as experiências anteriores. No início do projeto as lições
aprendidas em projetos anteriores devem sem revistas, durante o projeto as melhorias
devem ser aplicadas e ao término do projeto devem ser documentadas na base histórica da
organização.
Papéis e
responsabilidades
definidos.
Os papéis e responsabilidades no projeto devem ser definidos e acordados para atender os
interesses dos patrocinadores, usuários e fornecedores.
– Patrocinadores são as pessoas e/ou organizações que aprovam os objetivos do projeto e
garantem o dinheiro necessário para o investimento.
– Usuários são as pessoas e/ou organizações que utilizarão o produto após o término do
projeto.
– Fornecedores são as pessoas e/ou organizações (internos ou externos) que proveem os
recursos e conhecimentos necessários para o projeto.
Gestão por estágios. O projeto é planejado, monitorado e controlado estágio por estágio.
Gestão por exceção.
Deve ser definido um plano de alçadas de autorização para aprovação dos desvios nos
objetivos do projeto. Os seis objetivos são: tempo, custo, qualidade, escopo, riscos e
benefícios.
Foco no produto. Foco na definição e entrega dos produtos, principalmente nos requisitos de qualidade.
Adequação ao
ambiente do projeto.
A metodologia deve ser adequada ao ambiente do projeto: tamanho, complexidade,
importância, capacidade e risco.
Nota. Fonte: adaptado de OGC, 2009.
44
Os princípios são as boas práticas obrigatórias que um projeto deve seguir. São
derivados de lições boas e ruins que afetam o sucesso do projeto. Os princípios fornecem um
framework de boas práticas para as pessoas envolvidas no projeto, garantido que o método seja
aplicado na medida certa para garantir o sucesso do projeto e não seja de forma demasiadamente
prescritiva. A Tabela 6 sintetiza os sete princípios do modelo (OGC, 2009).
Os temas descrevem os aspectos da gestão de projetos que devem ser continuamente
endereçados durante todo o projeto. Os temas são integrados para garantir a efetividade dos
processos de gestão do projeto. Todos os temas devem ser aplicados no projeto, respeitando a
flexibilidade do método em relação ao projeto. A Tabela 7 resume os temas (OGC, 2009).
Tabela 7: Síntese dos sete temas do PRINCE2.
Temas Descrição
Business Case
Por quê?
O projeto se inicia com uma ideia com potencial de gerar benefícios para a organização.
Este tema define como a ideia será desenvolvida em uma proposta de investimento viável
para a organização e como os objetivos da organização serão monitorados no decorrer do
projeto.
Organização
Quem?
Este tema descreve como a equipe do projeto será estruturada dentro da organização e os
papéis e responsabilidades de seus integrantes.
Qualidade
O que?
Explica como os requisitos do projeto serão desenvolvidos de modo que todos os
participantes entendam os atributos de qualidade dos produtos a serem entregues. Dessa
forma é possível planejar como a entrega será garantida.
Planos
Como?
Quanto?
Quando?
Os projetos prosseguem com base em uma série de planos aprovados. Este tema descreve as
etapas necessárias para o desenvolvimento dos diversos planos do projeto e as técnicas a
serem aplicadas.
Riscos
E se?
Os projetos geralmente possuem mais riscos do que as atividades operacionais do dia a dia.
Este tema define como os gerentes devem gerenciar as incertezas em seus planos e no
ambiente do projeto como um todo.
Mudanças
Qual o impacto?
Problemas, solicitações de mudança ou falhas de qualidade podem impactar as tarefas
concluídas, em andamento ou planejadas. Ou seja, as mudanças podem impactar a linha de
base do projeto e comprometer seus objetivos. Este tema descreve como as mudanças serão
gerenciadas.
Progresso
Onde estamos?
Para onde vamos?
Devemos continuar?
Este tema trata da governança do projeto para garantir seu contínuo progresso. Explica o
processo de tomada de decisões na aprovação de planos, no monitoramento do desempenho
efetivo e no processo de reportar adequadamente os problemas aos níveis hierárquicos
superiores.
Nota. Fonte: adaptado de OGC, 2009.
O método fornece um modelo de processos, onde são descritas as atividades necessárias
para direcionar, gerenciar e entregar o projeto. Um processo é um conjunto estruturado de
atividades desenhadas para atender um determinado objetivo. A Tabela 8 sintetiza as principais
características dos processos do PRINCE2.
45
Tabela 8: Síntese dos sete processos do PRINCE2.
Processos Descrição
Preparando um
projeto
Este processo evita que os projetos sem um motivo claro para execução sejam iniciados. As
atividades deste processo devem ser limitadas a verificar se o projeto é viável em termos
financeiros, técnicos e operacionais. As atividades são:
– Definir o executivo responsável pelo projeto e o gerente do projeto;
– Buscar experiências anteriores;
– Estruturar e definir a equipe de gestão do projeto;
– Preparar o Business Case;
– Definir a abordagem do projeto e montar o sumário do projeto;
– Planejar o início do projeto.
Direcionando um
projeto
Este processo descreve as atividades de gerenciamento do comitê executivo. Após a
aprovação do Business Case o comitê executivo deve eleger o gerente do projeto que dará
início ao projeto. O papel do comitê executivo do projeto é acompanhar o projeto através de
relatórios e controles, atuando em algumas tomadas de decisão. Qualquer situação fora
deste contexto deve ser direcionada pelo gerente do projeto. Para que este processo ocorra
sem grandes percalços, é fundamental que as alçadas de decisão dentro do projeto estejam
claramente definidas. As atividades são:
– Autorizar o início do projeto;
– Autorizar o plano das fases;
– Tomar decisões críticas quando necessário;
– Determinar o fim do projeto.
Iniciando um
projeto
Este processo descreve as atividades que o gerente de projetos deve realizar para
estabelecer uma base sólida para o início do projeto. A principal entrega é o documento de
iniciação do projeto que contém uma visão geral do plano do projeto e define as linhas de
bases com as metas de desempenho dos seis objetivos do projeto: tempo, custo, qualidade,
escopo, riscos e benefícios. As atividades são:
– Elaborar a estratégia de gestão de riscos do projeto;
– Elaborar a estratégia de gestão de execução do projeto;
– Preparar a estratégia de gestão de qualidade do projeto;
– Preparar a estratégia de comunicação do projeto;
– Determinar os controles de progresso do projeto;
– Criar o planejamento do projeto;
– Revisar o caso de negócio;
– Documentar o processo de início do projeto.
Gerenciando as
fases do projeto
Este processo descreve as atividades necessárias para prover o comitê executivo com
informações suficientes para a tomada de decisões. O comitê executivo deve avaliar o
sucesso do estágio atual do projeto, aprovar o início do próximo estágio, revisar o plano do
projeto, avaliar se os riscos continuam aceitáveis e confirmar se a justificativa do projeto
continua válida. O gerente de projeto deve garantir que a atenção do projeto está voltada
para a entrega dos produtos. As atividades são:
– Autorizar o início das atividades;
– Monitorar progresso das atividades;
– Revisar se os produtos entregues atendem os objetivos do projeto;
– Reportar os pontos de atenção ao comitê executivo;
– Gerenciar riscos e problemas;
– Tomar as ações corretivas.
46
Processos Descrição
Gerenciando a
entrega de produtos
Este processo está voltado para as atividades diárias dos líderes da equipe necessárias para
garantir a entrega dos produtos e garantir a conexão entre o gerente do projeto e as equipes.
As atividades são:
– Solicitar aprovação de início do desenvolvimento de novos produtos ao gerente de
projeto;
– Criar um planejamento interno para controle dos responsáveis por atividade dentro da
equipe;
– Garantir que os produtos estão sendo desenvolvidos de acordo com o especificado em
termos de escopo e no padrão de qualidade solicitado;
– Obter a validação e aceite dos produtos finalizados.
Gerenciando a
transição entre os
estágios
Um projeto, seja ele grande ou pequeno, deve garantir que seus produtos proporcionarão os
benefícios esperados à organização. O monitoramento do escopo do projeto deve assegurar
isto, especialmente durante a transição entre as fases do projeto. As atividades são:
– Garantir que todos os produtos previstos na fase anterior foram entregues;
– Preparar o planejamento da próxima fase;
– Revisar a documentação do projeto produzida até o momento;
– Registrar possíveis lições aprendidas para serem utilizadas em outras fases do projeto e
até em outras iniciativas dentro da organização;
– Solicitar autorização para início da próxima fase.
Encerrando um
projeto
O projeto encerra-se após a entrega de todos os produtos previstos. O encerramento do
projeto tem os seguintes objetivos:
– Verificar a aceitação dos produtos entregues junto aos usuários;
– Garantir que existe uma estrutura para suporte do produto após a desestruturação do
projeto;
– Revisar o desempenho do projeto de acordo com os cronogramas estipulados.
Nota. Fonte: adaptado de OGC, 2009.
Um dos sete princípios do PRINCE2 diz que a metodologia deve ser adequada ao
ambiente do projeto. Adequar significa que as medidas necessárias para a aplicação da
metodologia devem ser adequadas às características individuais do projeto, garantindo que a
estrutura de governança, planejamento e controle seja apropriada. Ou seja, a estrutura não pode
ser muito onerosa para um projeto simples nem muito informal para um projeto grande ou
complexo. Tanto a organização quanto o gestor do projeto possuem a responsabilidade de aplicar
o princípio da adequação ao ambiente do projeto (OGC, 2009).
As responsabilidades da organização são de caráter amplo e genérico: definir as
responsabilidades pelos processos; definir as regras de escalada de problemas; definir os
templates padrão; treinar e desenvolver as pessoas; integrar os processos de negócios; fornecer as
ferramentas necessárias; e garantir a avaliação do processo. As responsabilidades do gestor do
projeto são específicas para o projeto: adaptar os temas por meio das estratégias e controles;
incorporar termos específicos; revisar as descrições do produto; revisar as descrições de funções;
e ajustar os processos (OGC, 2009).
47
2.1.5 Modelos de Maturidade em Gestão de Projetos
O principal objetivo de um modelo de maturidade é permitir que a organização avalie
suas capacidades e se compare com as melhores práticas disponíveis no mercado. Dessa forma, a
organização identifica seus pontos positivos e negativos, o que lhe permite traçar um plano de
ação de melhoria. Os modelos de maturidade são aplicados a uma vasta gama de capacidades,
desde a gestão de riscos e gestão de conhecimento até a completa gestão de projetos e gestão de
portfólio. Geralmente, os modelos de maturidade propõem níveis de capacidade em sequência
onde cada nível é atingido quando a organização atende a uma lista de critérios que são
considerados as melhores práticas de mercado. Também é importante destacar que tais modelos
incluem indicadores e outros elementos como estrutura organizacional, treinamento e
comunicação (Killen & Hunt, 2009, 2013).
Figura 8: Os cinco níveis de maturidade do CMMI.
Fonte: Eugênia et al., 2006.
O Capability Maturity Model Integration (CMMI) é o modelo de maturidade
desenvolvido pelo Software Engineering Institute (SEI) em 1991 para integrar as melhores
práticas no campo da engenharia de software. É uma evolução do Capability Maturity Model –
CMM e serviu de base para criação de diversos modelos de maturidade em gestão de projetos e
portfólio. Este modelo está estruturado por meio de um conjunto de áreas de processos relativas a
várias disciplinas (engenharia, gestão de projetos, etc.) que são distribuídas ao longo de cinco
níveis de maturidade: (1) inicial – os processos são imprevisíveis, pouco controlados e reativos;
48
(2) gerenciado – os processos são caracterizados por projetos e as ações são frequentemente
reativas; (3) definido – os processos são caracterizados para organizações e são proativos; (4)
quantitativamente gerenciado – os processos são medidos e controlados; e (5) otimização – foco
contínuo na melhoria dos processos (Eugênia, Volkmer, & Vasques, 2006). A Figura 8 apresenta
como estão organizados os cinco níveis de maturidade do CMMI.
Existe uma variedade de modelos para avaliação de maturidade em gestão de projetos,
conforme apresentados na Tabela 9.
Tabela 9: Lista dos modelos de maturidade em gestão de projetos.
Nº Acrônimo Nome Proprietário
1 OPM3 Organizational Project Management
Maturity Model
Project Management Institute (PMI)
2 P3M3 Portfolio, Programme, Project Management
Maturity Model
Office of Government Commerce (OGC)
3 P2M Project & Program Management for
Enterprise Innovation (P2M)
Project Management Association of Japan
(PMAJ)
4 PMMM Project Management Maturity Model PM Solutions
5 PPMMM Project Portfolio Management Maturity
Model
PM Solutions
6 PMMM Programme Management Maturity Model Programme Management Group
7 PMMM Project Management Maturity Model KLR Consulting
8 (PM)2 The Berkeley Project Management Process
Maturity Model
Department of Civil Engineering University
of California at Berkeley
9 ProMMM Project Management Maturity Model Project Management Professional Solutions
Limited
10 MINCE2 Maturity Increments IN Controlled
Environments
MINCE2 Foundation
11 PPMM Project and Portfolio Management Maturity PriceWaterhouseCoopers (PWC) Belgium
12 CMMI Capability Maturity Model Integration Software Engineering Institute (SEI)
13 SPICE Software Process Improvement and
Capability dEtermination
Software Quality Institute Griffith
University, Australia
14 FAA-iCMM Federal Aviation Administration -
Integrated Capability Maturity Model
US Federal Aviation Administration
15 Trillium Trillium Bell Canada
16 EFQM EFQM Excellence Model European Foundation for Quality
Management (EFQM)
17 COBIT Control Objectives for Information and
related Technology
Information Systems Audit and Control
Association (ISACA)
18 INK INK Managementmodel Instituut Nederlandse Kwaliteit (INK)
19 ProjectProof VA Volwassenheidsmodel Van Aetsveld
20 PAM Project Activity Model Artemis
21 Project
Excellence
Model
The Project Excellence Model Berenschot
22 PMMM Project Management Maturity Model International Institute for Learning (IIL)
H. Kerzner
Nota. Fonte: Man, 2007.
49
Segundo Man (2007), um modelo de maturidade para projetos possui dois componentes
básicos: (1) um modelo de referência de maturidade; e (2) um método de avaliação. O modelo de
referência de maturidade é uma descrição dos requisitos que uma organização deve atender a fim
de atingir um grau de maturidade desejado incorporado pelo modelo de maturidade. O método de
avaliação explica o que deve ser feito para avaliar se um requisito é cumprido e se uma
organização alcançou um nível de maturidade. Os níveis de maturidade em gestão de projetos
variam de 3 a 8 (Neverauskas & Čiutienė, 2011), sendo que não há um conceito unânime sobre o
conteúdo de cada nível entre os diversos modelos.
Esta dissertação aborda os modelos do PMI, a instituição com maior número de
associados no Brasil e do OGC que tem foco em projetos de software.
2.1.5.1 PMI – OPM3 (Organizational Project Management Maturity Model)
O modelo de maturidade OPM3 é um padrão criado pelo PMI em setembro de 2003,
resultado de estudos iniciados em 1998 e com a contribuição de mais de 800 profissionais de 35
países. O modelo foi atualizado em 2013 e propõe uma gestão sistemática de projetos, programas
e portfólio em alinhamento com os objetivos estratégicos das organizações e baseia-se na ideia da
correlação entre as capacidades organizacionais em gestão de projetos, programas e portfólio e
sua efetividade na implantação da estratégia corporativa (PMI, 2013b).
Este modelo está organizado fisicamente em três partes relacionadas a três elementos
para aplicação nas organizações. O primeiro elemento é conhecido como “Conhecimento” e pode
ser definido como o momento em que a organização irá adquirir os conhecimentos necessários
para o entendimento do conteúdo do modelo, compreendendo todo o escopo de melhores
práticas, glossário, ferramenta de auto avaliação, conceitos e metodologia do OPM3.
O segundo elemento é chamado de “Avaliação” e está relacionado ao processo de
avaliação do grau de maturidade da organização na gestão de portfólio, programas e projetos.
Esta avaliação ocorre por meio de comparação das características do estado atual de maturidade
da organização contra o modelo de referência descrito pelo modelo.
No terceiro elemento conhecido como “Melhoria”, as organizações que decidem ir
adiante com a implantação de ações para aumentar sua maturidade utilizam o resultado da
avaliação para planejar e implantar as ações de melhoria na maturidade de gestão de portfólio.
50
Estes três elementos estão organizados em um ciclo contínuo de cinco passos: (1) preparar–se
para a avaliação; (2) realizar a avaliação; (3) planejar melhorias; (4) implantar melhorias; (5)
repetir o processo.
As melhores práticas e capacidades do padrão OPM3 estão mapeadas em dois fatores
principais: domínios e estágios. Os domínios do modelo referem-se à Gestão de Projetos, Gestão
de Programa e Gestão de Portfólio. Já os estágios referem-se aos processos de uniformizar,
medir, controlar e melhorar continuamente os processos de gestão. Dentro da construção do
modelo OPM3 estão combinados os cinco grupos de processos: iniciação, planejamento,
controle, execução e encerramento interagindo com cada um dos domínios de forma progressiva
através dos estágios de melhoria de processos. A Figura 9 apresenta o modelo de construção do
OPM3 (PMI, 2013b).
Figura 9: Modelo de maturidade OPM3.
Fonte: PMI, 2013b.
2.1.5.2 OGC – P3M3 (Portfolio, Programme and Project Management Maturity Model)
O P3M3 foi desenvolvido pela OGC em 2006 sendo uma evolução do modelo de
maturidade em gestão de projetos da OGC que por sua vez foi baseado nos processos do modelo
de maturidade do CMM. Possui cinco níveis de maturidade e integra três modelos individuais
para a gestão de portfólio (PfM3), programas (Pgm3) e projetos (PjM3). Estes modelos estão
51
conectados, mas são independentes. Complementando sua estrutura, o modelo P3M3 é composto
de perspectivas de processos e atributos (OGC, 2010).
Os cinco níveis de maturidade do modelo P3M3 para a gestão de portfólio podem ser
descritos da seguinte forma:
(1) Consciência do Processo – neste nível o executivo da organização reconhece
programas e projetos assim como mantém uma lista informal de seus investimentos em cada um
deles. Pode não haver controle formal e processo de documentação.
(2) Processos Repetitivos – a organização assegura que cada um dos programas e/ou
projetos em seu portfólio seja conduzido com seus próprios processos e procedimentos com um
mínimo de padrão especificado. Existe consistência ou coordenação limitada.
(3) Processos Definidos – significa que a organização tem seus próprios processos de
programas e portfólio, que são definidos, documentados e controlados centralmente, sendo que
estes programas e projetos podem ter flexibilidade dentro destes processos de forma a
adequarem-se a cenários específicos.
(4) Processos Gerenciados – caracterizado pela organização que obtém e mantém as
métricas específicas de gestão em todo o seu portfólio de programas e projetos, como forma de
prever o desempenho futuro. A organização avalia a sua capacidade para gerir programas e
projetos, assim como priorizá-los adequadamente.
(5) Processos Otimizados – é possível identificar evidências de melhoria contínua dos
processos de forma proativa. Os processos são claramente otimizados com controles bem
definidos e comportamentos que possibilitam a entrega dos objetivos estratégicos da organização
por meio de uma variedade de processos e ferramentas. Existe uma gestão ativa da
interdependência entre os planos dos programas e projetos do portfólio e os planos de negócios.
Para os três modelos de avaliação (portfólio, programa e projetos) o modelo P3M3 foca
em sete perspectivas de processos que podem ser revisadas de forma individual ou agrupadas. A
Figura 10 representa o modelo de maturidade P3M3.
As sete perspectivas do modelo são:
52
(1) Controle de Gestão – está relacionado com os controles internos de uma iniciativa e
como sua direção será mantida ao longo do ciclo de vida por meio de pontos de controle que
possibilitem a parada ou o redirecionamento se necessário.
(2) Gestão de Benefícios – processo que está ligado a garantia de que os resultados das
mudanças de negócio desejados sejam claramente definidos, medidos e entendidos por meio de
uma abordagem estruturada.
(3) Gestão Financeira – procura assegurar que os prováveis custos da iniciativa sejam
capturados e avaliados dentro de um business case e que os mesmos sejam categorizados e
gerenciados durante o ciclo de vida do investimento.
(4) Engajamento de Partes Interessadas – é reconhecido como chave para o sucesso e
inclui o planejamento da comunicação, identificação e uso de diferentes canais de comunicação
assim como outras técnicas que possibilitem atingir os objetivos de engajamento.
(5) Gestão de Riscos – tem como objetivo manter o balanceamento entre as ameaças e
oportunidades com a gestão apropriada das ações para minimizar ou eliminar a probabilidade de
ocorrência de ameaças identificadas, ou minimizar os impactos assim como maximizar as
oportunidades de forma proativa.
(6) Governança Organizacional – tem como foco verificar como as entregas das
iniciativas estão alinhadas com a direção estratégica da organização, olhando como fatores
externos que impactam as iniciativas são controlados, e como maximizar o resultado final.
(7) Gestão de Recursos – está relacionado com o planejamento, priorização e execução
da gestão de todo o tipo de recursos requeridos para a entrega de uma iniciativa e inclui: recursos
humanos, equipamentos, instalações, fornecedores, informações, ferramentas e times de suporte.
A auto avaliação do modelo P3M3 consiste em nove questões que endereçam
capacidades dos processos e provê informações sobre o nível de maturidade da organização em
relação à gestão de portfólio, programas e projetos. A auto avaliação provê uma visão geral da
organização com relação à maturidade em gestão de portfólio, programas ou projetos e pode ser
utilizada para identificação das forças e fraquezas em relação a esses processos de gestão (OGC,
2010).
53
Figura 10: Modelo de maturidade P3M3.
Fonte: OGC, 2010.
2.1.6 Metodologias de Desenvolvimento de Software
Atualmente é amplamente entendido que a utilização de uma adequada Metodologia de
Desenvolvimento de Software (MDS) melhora a eficiência e eficácia do produto final. Ao longo
dos últimos 25 anos muitas metodologias foram propostas (Cascata, Modelo V, Espiral, Scrum,
XP, etc.). No entanto, cada projeto tem uma característica única e isso significa que uma MDS
pode ser adequada para um projeto e não ser adequada para outro. Escolher a MDS errada pode
atrasar o cronograma do projeto e gerar retrabalho desnecessário. Portanto, muitas vezes a equipe
do projeto enfrenta a difícil tarefa de selecionar a MDS mais adequada (Guntamukkala, Wen, &
Tarn, 2006).
Não existe um critério empírico estabelecido para selecionar a MDS mais adequada para
conduzir um projeto ao sucesso. As equipes de projeto preferem as metodologias Cascata e
Modelo V quando: (a) os requisitos são claros; e (b) é esperada manutenção futura frequente do
software. Por outro lado, as equipes de projeto preferem as metodologias Scrum e XP quando: (a)
os requisitos mudam constantemente; (b) a equipe é pequena; (c) os riscos são desconhecidos; e
(d) o prazo é restrito (Guntamukkala et al., 2006).
A escolha de qual MDS utilizar deve ocorrer logo na fase de planejamento do projeto,
pois tal decisão pode impactar o custo, cronograma e alocação de recursos. Na Tabela 10
54
encontra-se uma breve descrição de algumas das principais metodologias de desenvolvimento de
software.
Tabela 10: Algumas das principais metodologias de desenvolvimento de software.
Metodologia Características Autor(es)
Codificar e Consertar
(Code and fix)
No final dos anos 60 o desenvolvimento de software era considerado
uma arte e não existia um processo formalmente estabelecido. Neste
modelo os programadores simplesmente codificavam com base em
conversas com os usuários e depois se reuniam para testar e consertar os
erros em conjunto (Guntamukkala et al., 2006).
Não há
Cascata (Waterfall) Nos anos 70 com a necessidade de desenvolver grandes sistemas
computacionais, o autor propôs a criação de um processo organizado
sequencialmente com diversas fases bem definidas, são elas: Requisitos
do Sistema, Requisitos do Software, Análise, Desenho do Programa,
Codificação, Testes e Operação. O autor nunca chamou seu modelo de
“cascata”, este nome foi popularizado posteriormente devido ao formato
de cascata de seu diagrama, onde a fase seguinte do processo somente
pode ser executada após o término da fase anterior (Royce, 1970).
Winston W.
Royce
Modelo V
(V-Model)
Este modelo é uma variação do modelo cascata e foi originalmente
desenvolvido pelas Forças Armadas da Alemanha em 1979. Seu objetivo
principal é relacionar as atividades de desenvolvimento de software com
as atividades de garantia da qualidade (Bucanac, 1999).
Forças Armadas
da Alemanha
Espiral
(Spiral)
Processo de desenvolvimento de software orientado a risco criado em
1988. Seu autor propõe uma espiral onde cada ciclo da espiral representa
uma fase distinta do processo. Dessa forma, o ciclo mais interno está
preocupado com a Viabilidade do Sistema, o ciclo seguinte com a
Definição dos Requisitos, o ciclo seguinte com o Desenho do Sistema e
assim por diante. A cada novo ciclo as atividades de gerenciamento de
risco são revisitadas (Boehm, 1988).
Barry W.
Boehm
Scrum Concebido inicialmente em 1990 por Jeff Sutherland, evoluiu
posteriormente com a contribuição de Ken Schwaber e Mike Beedle. Os
princípios do Scrum são consistentes com o manifesto ágil e são usados
para orientar as atividades de desenvolvimento dentro de um processo
iterativo, onde cada ciclo do processo é chamado de Sprint. Enfatiza o
uso de um conjunto de padrões de processos de software que provaram
serem eficazes para projetos com prazos de entrega apertados e
requisitos críticos de negócio (Pressman, 2011).
Jeff Sutherland,
Ken Schwaber
e Mike Beedle
RUP – Rational
Unified Process
(Processo Unificado
da Rational)
Modelo proprietário da empresa Rational, adquirida pela IBM, que foi
criado originalmente em 1996 por Ivar Jacobson e vem sendo
continuamente aperfeiçoado ao longo do tempo por outros autores. É um
modelo iterativo com quatro fases distintas: Iniciação, Elaboração,
Construção e Transição. No entanto, ao contrário do modelo em cascata,
onde as fases estão diretamente relacionadas com a parte técnica, no
RUP as fases estão estreitamente relacionadas aos negócios
(Sommerville., 2011).
Ivar Jacobson,
Grady Booch,
James
Rumbaugh e
Philippe
Kruchten
XP – Extreme
Programming
(Programação
Extrema)
O trabalho seminal sobre o tema foi escrito em 1999. Emprega uma
abordagem orientada a objetos como seu paradigma de desenvolvimento
preferido e envolve um conjunto de regras e práticas constantes no
contexto de quatro atividades metodológicas iterativas: Planejamento,
Projeto, Codificação e Testes. O autor define um conjunto de cinco
valores que estabelecem as bases para todo trabalho realizado como parte
da XP: Comunicação, Simplicidade, Feedback, Coragem e Respeito
(Pressman, 2011).
Kent Beck
Nota. Fonte: elaborado pelo autor.
55
Nesta dissertação serão abordadas com maior profundidade as metodologias Scrum e
Modelo V, pois são as metodologias homologadas na empresa objeto do estudo de caso.
2.1.6.1 Scrum
Com o objetivo de encontrar melhores maneiras de se desenvolver softwares, dezessete
renomados desenvolvedores assinaram em 2001 o “Manifesto para o Desenvolvimento Ágil de
Software”. Esse documento contempla um conjunto de valores e princípios em que se valorizam
indivíduos e interações acima de processos e ferramentas, softwares funcionais acima de
documentação, colaboração com o cliente acima de negociação de contrato e respostas às
mudanças acima de seguir um plano (http://www.agilemanifesto.org, recuperado em 15
novembro, 2014).
O Scrum é fundamentado no empirismo, o qual define que o conhecimento vem das
experiências e tomadas de decisões baseadas no que é conhecido. O empirismo é baseado em três
pilares: transparência, inspeção e adaptação. A transparência requer que os principais aspectos do
processo estejam visíveis e padronizados para que os interessados tenham o mesmo
entendimento, tal como, a definição de uma linguagem comum e o que se entende como algo
concluído. A inspeção deve ocorrer frequentemente para detectar indesejáveis variações e deve
ser realizada, de preferência, por um especialista. A adaptação significa que o processo ou
produto deve ser adaptado quando o especialista identificar um desvio ou produto inaceitável
(Schwaber & Sutherland, 2013).
O Scrum é considerado uma metodologia ágil e é um framework estrutural dentro do
qual é possível empregar vários processos ou técnicas. O Scrum aplica uma abordagem
incremental e iterativa para melhorar a previsibilidade e o controle de risco (Schwaber &
Sutherland, 2013).
As equipes do Scrum consistem do Dono do Produto, Scrum Master e Time de
Desenvolvimento. O Dono do Produto é a única pessoa responsável pelo gerenciamento do
backlog do produto, o Scrum Master é o responsável por garantir que o Scrum está sendo
aplicado corretamente e o Time de Desenvolvimento é uma equipe disciplinar responsável por
realizar a entrega com tamanho ideal de três a nove integrantes (Schwaber & Sutherland, 2013).
56
O Scrum usa eventos de tempos pré-definidos (time-box) para criar regularidade e evitar
perda de tempo. O coração do Scrum é o Sprint, um time-box de duas a quatro semanas em que
uma entrega concluída e utilizável é criada. O Sprint consiste de cinco eventos: Planejamento do
Sprint, Daily Meeting, Execução do Sprint, Revisão do Sprint e Retrospectiva do Sprint.
No Planejamento do Sprint, que dura aproximadamente oito horas, o Dono do Produto
apresenta os itens do backlog do produto priorizados de acordo com os objetivos organizacionais.
É importante destacar que o backlog do produto nunca está pronto e os primeiros
desenvolvimentos apenas estabelecem os requisitos inicialmente entendidos e melhores
entendidos. Em seguida, o Time de Desenvolvimento estima o escopo que poderá ser
desenvolvido no Sprint e como o trabalho será executado. Os itens do backlog selecionados em
conjunto com o plano para desenvolvê-los são chamados de Sprint Backlog. O Daily Meeting é
uma reunião diária de 15 minutos para inspecionar a evolução das atividades e criar um plano
para as próximas 24 horas. A Figura 11 apresenta resumidamente a visão geral do framework
Scrum (Schwaber & Sutherland, 2013).
Figura 11: Visão geral do Scrum.
Fonte: adaptado de Schwaber & Sutherland, 2013.
Na Execução do Sprint o time de desenvolvimento analisa, codifica e testa os itens
selecionados. Na Revisão do Sprint, as equipes do Scrum e os stakeholders se reúnem para
verificar o que foi e o que não foi entregue, os desafios enfrentados, as lições aprendidas, bem
como redefinir o backlog do produto a partir dos itens antigos e dos novos que venham a surgir.
57
A Retrospectiva do Sprint é uma reunião feita pela equipe para inspecionar o último Sprint e
propor adaptações para buscar melhorias no próximo Sprint (Schwaber & Sutherland, 2013).
Equipes ágeis funcionam melhor quando alocadas no mesmo espaço físico, pois além de
facilitar a comunicação e colaboração, se provou ser um meio eficaz de aumentar a produtividade
da equipe (Lalsing, Kishnah, & Pudaruth, 2012).
2.1.6.2 Modelo V
O Modelo V é um processo prescritivo e tradicional que fornece um roteiro de
atividades pré-estabelecidas razoavelmente eficaz para as equipes de desenvolvimento de
software. É um método prescritivo porque prescreve um conjunto de artefatos, atividades
encadeadas logicamente e mecanismos de controle de mudanças que objetivam garantir a
qualidade esperada do produto final. É um método tradicional porque é uma variação do modelo
cascata, também conhecido como ciclo de vida clássico e sugere uma abordagem sequencial e
sistemática do início ao fim do projeto de software (Pressman, 2011).
O Modelo V representado na Figura 12 foi originalmente desenvolvido pelas Forças
Armadas da Alemanha. Seu objetivo principal é relacionar as atividades de desenvolvimento de
software com as atividades de garantia da qualidade (Bucanac, 1999).
Figura 12: Relacionamento entre atividades no Modelo V.
Fonte: adaptado de Bucanac, 1999.
Este tipo de modelo funciona bem quando os requisitos do sistema são bem desenhados,
documentados e compreendidos por todos os envolvidos no projeto. Por outro lado, pode gerar
58
interrupções no processo, pois a fase posterior somente pode ser iniciada após o término da fase
anterior (Pressman, 2011).
A dinâmica atual dos negócios bancários exige que o desenvolvimento de software seja
cada vez mais rápido, eficaz e eficiente. Sendo assim é importante utilizar uma das variações do
Modelo V que consiste em dividir o escopo total do projeto em funcionalidades menores,
gerenciáveis e controláveis. Conforme apresentado na Figura 13, o encadeamento dessas
funcionalidades permite realizar entregas parciais do software de forma incremental, melhorando
a previsibilidade e o controle do risco.
Figura 13: Modelo V aplicado de forma incremental.
Fonte: adaptado de Pressman, 2011.
2.2 GESTÃO DE RISCOS DE TI
2.2.1 Conceitos e Histórico
A palavra risco deriva, originalmente, do italiano antigo risicare, que quer dizer ousar
(Bernstein, 1997) e, no sentido de incerteza, deriva do latim risicu e riscu. Ou seja, risco pode ser
59
interpretado como um conjunto de incertezas que podem ocorrer ao ousar fazer algo (Salles et
al., 2010).
Na linguagem cotidiana e em várias disciplinas especializadas os termos risco e
incerteza são usados de muitas maneiras diferentes. Ao consultar o dicionário Michaelis de
Língua Portuguesa nota-se a diferença entre os conceitos: risco é a possibilidade de perigo,
incerto mas previsível, que ameaça de dano a pessoa ou a coisa, isto é, situação em que há
probabilidades mais ou menos previsíveis de perda ou ganho como, por exemplo, em um jogo de
azar ou em uma decisão de investimentos; e incerteza é a falta de certeza, hesitação, dúvida ou
indecisão (Melhoramentos, 2011).
Existem evidências sugerindo que a gestão de riscos utilizando negociação de futuros de
commodities já era praticada na Índia por volta de 2000 a.C.; entretanto, os princípios básicos da
gestão de riscos datam da época da Grécia Clássica e do Império Romano, onde, a partir dos anos
1100 d.C. os vendedores em feiras medievais assinavam contratos prometendo entrega futura dos
itens que vendiam (Ramirez, 2008).
Cicco (1990, p. 25)1 apud (Silva, 2011) apresenta a gestão de riscos pelo ponto de vista
dos profissionais de mercado: para os profissionais da área de seguros, trata-se da ciência que se
ocupa dos chamados riscos seguráveis e de redução dos custos de seguro; para os profissionais da
área financeira, consiste no uso de técnicas de proteção de ativos financeiros e no manejo
adequado de taxas de juros; para muitos políticos e analistas sociais, representa o controle de
situações que podem afetar o meio ambiente e são decorrentes do avanço tecnológico crescente e
desordenado; e para trabalhadores da saúde, pode significar o mesmo que garantia da qualidade
dos serviços prestados aos pacientes.
Uma definição de risco e gestão de riscos genérica para o ambiente corporativo pode
ser encontrada na norma ISO 31000 – Gestão de Riscos – que esclarece que todas as atividades
de uma organização envolvem risco: risco é um desvio positivo e/ou negativo em relação aos
objetivos, que podem ter diferentes aspectos (tais como metas financeiras, de saúde e segurança e
ambientais) e aplicar-se em diferentes níveis (tais como estratégico, em toda a organização, de
1 Cicco, F. M. G. A. F. de (1990, outubro). O gerenciamento dos riscos empresarias nos anos 90. Revista do Instituto
de resseguros do Brasil, Ano 51(254), 25-26.
60
projeto, de produto e de processo); e gestão de riscos são as atividades coordenadas para dirigir e
controlar uma organização no que se refere a riscos (ISO, 2009).
Uma definição de risco e gestão de riscos específica para projetos pode ser encontrada
no PMBOK: risco é um evento ou uma condição incerta que, se ocorrer, provocará um efeito
positivo (oportunidade) ou negativo (ameaça) nos objetivos do projeto tais como custo, escopo,
prazo ou qualidade; e gestão de risco é o conjunto de processos, técnicas e ferramentas
necessários para aumentar a probabilidade e o impacto dos eventos positivos e diminuir a
probabilidade e o impacto de eventos negativos no projeto (PMI, 2013a). A partir desta definição,
fica claro que o risco somente existe quando impacta positiva ou negativamente o objetivo do
projeto, ou seja, para que a gestão de riscos seja aplicada com sucesso é fundamental definir
claramente quais são os objetivos do projeto e sua importância para a organização (PMI, 2009).
Com relação aos projetos de software a norma ISO/IEC 16085 – Systems and software
engineering—Life cycle processes—Risk management (2006) define a gestão de riscos da
seguinte forma:
A gestão de riscos é uma disciplina chave para a tomada de decisões eficazes e comunicação
dos resultados dentro das organizações. O objetivo do gerenciamento de risco é identificar
potenciais problemas gerenciais e técnicos antes que eles ocorram, de modo que possam ser
tomadas ações antecipadas para reduzir ou eliminar a probabilidade e/ou impacto destes
problemas caso eles ocorram. É uma ferramenta fundamental para determinar continuamente a
viabilidade dos planos de projetos, para melhorar a busca e identificação de potenciais
problemas que podem afetar as atividades do ciclo de vida e da qualidade e desempenho dos
produtos e para a melhoria da gestão ativa dos projetos (tradução livre).2
2.2.2 Categorização dos Riscos
2.2.2.1 Categorização dos Riscos Corporativos
Estabelecer uma hierarquia de categorias de risco dentro de uma organização é muito
útil porque permite agrupar os riscos comuns à organização facilitando o prognóstico, prevenção,
2 Risk management is a key discipline for making effective decisions and communicating the results within
organizations. The purpose of risk management is to identify potential managerial and technical problems before
they occur so that actions can be taken that reduce or eliminate the probability and/or impact of these problems
should they occur. It is a critical tool for continuously determining the feasibility of project plans, for improving the
search for and identification of potential problems that can affect life cycle activities and the quality and performance
of products, and for improving the active management of projects.
61
controle e redução do risco. Embora as classificações dos diferentes tipos de risco a que se expõe
uma instituição financeira sejam diversas, a Tabela 11 sugere um possível agrupamento dos
riscos (Fortuna, 2013; Marshall, 2002).
Tabela 11: Sugestão de categorias de riscos em uma instituição financeira.
Tipo de Risco Descrição
Risco de Crédito
Risco de perdas associadas ao não cumprimento pelo tomador ou contraparte de suas
respectivas obrigações financeiras nos termos pactuados, à desvalorização de contrato de
crédito decorrente da deterioração na classificação de risco do tomador, à redução de ganhos
ou remunerações, às vantagens concedidas na renegociação e aos custos de recuperação;
Risco de Imagem Risco de danos à reputação da instituição junto a clientes, concorrentes, órgãos reguladores,
parceiros comerciais, entre outros, acarretando impactos no valor da marca;
Risco de Liquidez
Risco de ocorrência de desequilíbrios entre ativos negociáveis e passivos exigíveis –
"descasamentos" entre pagamentos e recebimentos – que possam afetar a capacidade de
pagamento da instituição, levando-se em consideração as diferentes moedas e prazos de
liquidação de seus direitos e obrigações;
Risco de Mercado
Risco da flutuação adversa do valor de ajuste diário de mercado de um portfólio financeiro
(seja dentro ou fora do balanço patrimonial) durante o período necessário para liquidar o
portfólio.
Risco de País Risco político que cerca investimentos, projetos, empréstimos ou ativos da empresa mantidos
em um país estrangeiro.
Risco de Projeto
Os autores destacam que os dois principais riscos de um projeto são não cumprir o prazo e
custo planejados e sugere utilizar a definição do PMI como referência para o conceito de
risco.
Risco de
Subscrição
Risco oriundo de uma situação econômica adversa que contraria tanto as expectativas da
sociedade seguradora no momento da elaboração de sua política de subscrição quanto as
incertezas existentes na estimação das provisões;
Risco de
Tecnologia
Risco potencial de falhas associadas a hardware, software e dados de computadores e
comunicações.
Risco Estratégico Risco de implementar uma estratégia malsucedida ou ineficaz que fracasse em alcançar os
retornos pretendidos;
Risco Legal Risco de não cumprimento da regulamentação do negócio.
Risco Operacional
Risco de perdas resultantes de falha, deficiência ou inadequação de processos internos,
pessoas e sistemas, ou de eventos externos. Inclui o risco legal, associado à inadequação ou
deficiência em contratos firmados pela instituição, bem como a sanções em razão de
descumprimento de dispositivos legais e a indenizações por danos a terceiros decorrentes das
atividades desenvolvidas pela instituição;
Nota. Fonte: Fortuna, 2013; Marshall, 2002.
Silva e Hein (2012) realizaram uma pesquisa bibliométrica no Brasil para identificar o
volume de produção científica nos periódicos de contabilidade listados no qualis/capes sobre
gestão de risco. Identificou-se que os tipos de riscos mais mencionados são: crédito (14,5%);
mercado (9,3%); operacional (7,2%); legal (3,1%) e país (3,12%).
Para Leopoldino e Borenstein (2011) a categorização de variáveis de riscos permite uma
maior compreensão das suas relações e a possibilidade do tratamento das mesmas em um nível
mais alto, lidando com fatores de maior grau de abrangência ao invés de se pulverizar esforços
62
controlando muitas pequenas variáveis simultaneamente. Sendo assim, realizaram uma pesquisa
no Brasil com profissionais da área de desenvolvimento de software e agruparam os riscos em
sete categorias: gerência de projetos; equipe de desenvolvimento; escopo e requisitos;
conhecimento e incerteza tecnológica; relacionamento com o ambiente externo; relacionamento
com o cliente/usuário; e valor/ importância atribuídos ao projeto.
2.2.2.2 Categorização dos Riscos de Projetos
Os diferentes níveis hierárquicos dentro de uma organização exigem visões de riscos
distintas, pois suas responsabilidades, habilidades e horizonte de tempo são completamente
diferentes. No nível operacional os engenheiros observam principalmente os riscos técnicos, no
nível tático os gerentes se preocupam com o custo, prazo, requisitos, qualidade e desempenho, e
no nível estratégico os executivos analisam os riscos que podem impactar a rentabilidade,
qualidade e prazo esperado de um ou diversos projetos (Higuera & Haimes, 1996).
Uma lista de riscos identificados pode ser priorizada para determinar quais riscos devem
ser endereçados primeiro, mas isso não permite compreender a estrutura de riscos do projeto.
Uma EAR permite identificar temas recorrentes e áreas de concentração de riscos, além de servir
como um guia para o processo de gestão de riscos. A melhor maneira de lidar com uma grande
quantidade de dados é estruturar a informação para facilitar a compreensão. A EAR facilita a
comunicação, a comparação com outros projetos e também serve como um documento de lições
apreendidas para futuros projetos (Hillson, 2003).
A EAR é uma técnica que permite agrupar possíveis causas de riscos. Podem ser usadas
várias abordagens como, por exemplo, uma estrutura baseada nos objetivos do projeto por
categoria. A estrutura analítica dos riscos ajuda a equipe do projeto a considerar muitas fontes a
partir dos quais os riscos podem surgir em um exercício de identificação de riscos. Diferentes
estruturas analíticas de riscos serão apropriadas para diferentes tipos de projetos. A EAR é uma
representação hierárquica dos riscos, de acordo com suas categorias de riscos (PMI, 2013a). A
Figura 14 apresenta um exemplo de uma EAR.
Considerando o impacto estratégico que os projetos têm nos negócios, a adequada gestão
de portfólio torna-se uma vantagem competitiva da organização, pois potencializa os efeitos
positivos da inovação de novos produtos/serviços. Além de garantir que o portfólio de projetos
63
está alinhado com a estratégia da organização, é fundamental que os melhores projetos sejam
conduzidos e seus riscos e progressos adequadamente monitorados desde a concepção até o pós-
lançamento do produto/serviço (Killen & Hunt, 2009, 2013).
Figura 14: Exemplo de uma estrutura analítica de riscos.
Fonte: PMI, 2013a.
Para aquelas empresas que já possuem uma base histórica de projetos, Holzman e
Spiegler (2011) criaram um processo metodológico para identificar os riscos de um portfólio a
partir dos registros dos projetos. O método utilizado foi o seguinte: (1) seleção dos registros de
riscos dos projetos que seriam analisados; (2) leitura dos documentos e categorização dos riscos
por meio da análise de conteúdo; e (3) clusterização dos dados para organizar os riscos em uma
EAR. O objeto de estudo foi uma empresa Israelense de desenvolvimento de software.
Holzman e Spiegler (2011) ainda mencionam que na indústria de software já existe uma
EAR disponível e que é muito utilizada e poderia ser aplicada em seu método. Trata-se da TBRI
64
(Taxonomy-Based Risk Identification) do SEI que categoriza os riscos em três classes: engenharia
do produto; ambiente de desenvolvimento e restrições do programa.
A TBRI acompanha todo o ciclo de vida do desenvolvimento de software e oferece um
framework para organizar os dados e as informações. Trata-se de um questionário e um processo
organizado de entrevistas para sua aplicação. A taxonomia organiza os riscos de projetos de
software em uma estrutura hierárquica de categorias. O questionário é uma ferramenta elaborada
para garantir que todas as áreas de riscos sejam sistematicamente endereçadas, enquanto o
processo de entrevistas é desenhado para garantir que todas as questões sejam respondidas tanto
pelos engenheiros quanto pelos gestores de maneira a produzir os melhores resultados (Higuera
& Haimes, 1996).
Figura 15: Distribuição de riscos seguindo a taxonomia de riscos do SEI.
Fonte: Higuera & Haimes, 1996.
A falta de bases de dados com informações históricas de riscos de projetos é um
problema enfrentado pelos gestores de projetos que o SEI procura solucionar oferecendo uma
65
base de dados com suas lições aprendidas. Na Figura 15 pode-se observar o resultado deste
trabalho que apresenta os riscos consolidados utilizando-se a Taxonomia de Riscos do SEI
(Higuera & Haimes, 1996).
Importante observar que a distribuição dos riscos ocorre de maneira uniforme entre as
três categorias, sendo 30% engenharia, 33% desenvolvimento e 37% restrições (Higuera &
Haimes, 1996).
2.2.3 Riscos em Projetos
Os riscos de um projeto devem ser considerados em dois grandes níveis: (1) riscos do
projeto ou risco geral do projeto; e (2) riscos no projeto. Geralmente os gestores de projetos
consideram somente os riscos no projeto que são os riscos individuais identificados e registrados
no Registro de Riscos. Raramente são considerados os riscos do projeto que são os riscos
associados com o escopo e benefícios do projeto onde se procura avaliar qual o impacto do
projeto para a organização (Hillson, 2013b).
Embora os riscos existam em praticamente todo o subsistema organizacional, é
especialmente notável como eles são relevantes nos projetos de desenvolvimento de novos
produtos devido ao envolvimento de diversas áreas e funções dentro da empresa. Os riscos que
aparentemente afetam apenas o projeto do novo produto podem se propagar por toda a empresa,
ampliando seu impacto nos recursos, cronogramas e desempenho da organização. A Tabela 12
ilustra alguns exemplos de riscos do projeto que impactaram não apenas o resultado do projeto,
mas todo o resultado da organização (Shenhar, Milosevic, Dvir, & Thamhain, 2007).
Os riscos do projeto devem ser considerados antes mesmo do início do projeto, isto é,
durante a fase de concepção do projeto (elaboração do business case). Neste momento, quando os
objetivos, investimentos e benefícios do projeto estão sendo esclarecidos, é fundamental que
também sejam avaliados os riscos que o projeto apresenta para a organização. Com base nestas
informações, os executivos estarão aptos a avaliar se o projeto está dentro do nível de risco
tolerado pela organização e alinhado com a estratégia organizacional. Neste nível, o risco do
projeto é avaliado com base no escopo proposto, estrutura necessária e contexto do projeto dentro
do cenário econômico (Hillson, 2013b).
66
Tabela 12: As incertezas podem impactar o sucesso de um novo produto (exemplos).
Descrição do Fato
Novo CD player ultra portátil falhou no mercado devido ao custo unitário de produção superior ao esperado.
Lançamento de novo produto de fundo mútuo foi um fracasso, pois as necessidades dos investidores e condições
econômicas mudaram.
Desenvolvimento de nova droga foi cancelado durante a fase de testes clínicos, pois a aprovação do FDA foi
negada.
Desenvolvimento de um satélite de telecomunicações resultou em uma grande perda financeira devido ao retrabalho
resultante de alterações regulatórias.
Atraso de dois anos na operação piloto de uma nova refinaria de óleo devido a descoberta de novas preocupações
ambientais.
Nota. Fonte: Shenhar et al., 2007.
O projeto é aprovado e se inicia após criteriosa avaliação do risco geral do projeto. Neste
momento os processos tradicionais de identificação e análise individual dos riscos podem ser
utilizados pela equipe do projeto (Hillson, 2013b).
Chapman e Ward (2007) esclarecem que as incertezas de um projeto estão presentes
durante todo o ciclo de vida de desenvolvimento do projeto, mas durante o início do projeto estas
incertezas são mais evidentes. Os dois principais fatores de incerteza de um projeto estão
relacionados com: a variabilidade em relação às medidas de desempenho do projeto, tais como
custo, prazo e qualidade; e a ambiguidade associada à falta de clareza dos requisitos, a falta de
dados e ignorância sobre a quantidade de esforço que deveria ser investido para esclarecer a
situação. As principais incertezas de um projeto podem ser organizadas em cinco grandes áreas:
(1) Variabilidade associada à estimativa de parâmetros do projeto – falta de
especificações claras, de experiência, complexidade, inter-relacionamentos de atividades, análise
limitada do processo envolvido na atividade, além da possibilidade de ocorrência de alguns
eventos que produzem efeitos nos objetivos;
(2) Incertezas sobre a base da estimativa – a qualidade das estimativas é questionável,
pois depende de quem realizou as estimativas, quais técnicas e parâmetros foram utilizados e se
os riscos “conhecidos desconhecidos” e “desconhecidos desconhecidos” foram considerados;
(3) Incertezas sobre o desenho e a logística – nos estágios de concepção de um projeto a
natureza das entregas e do processo para produzi-las é fundamentalmente incerto;
(4) Incertezas sobre objetivos e prioridades – uma das formas para melhorar o
desempenho de um projeto é ter clareza dos seus objetivos e da importância relativa entre eles.
67
Por exemplo, se a prioridade relativa de prazo, custo e desempenho não estiverem claros, a
incerteza associada a estes fatores será bem relevante.
(5) Incertezas sobre o relacionamento entre os envolvidos no projeto – uma fonte de
incertezas é a multiplicidade de pessoas, organizações e unidades de negócio envolvidas no
projeto. O relacionamento entre as partes muitas vezes é complexo e aumenta as incertezas.
Conforme pode ser observado na Figura 16, o nível de exposição ao risco de um projeto
é alto no início e diminui à medida que o projeto progride ao seu término, pois conforme a
quantidade de informações sobre o projeto aumenta, as incertezas diminuem. A gestão de riscos
trata as incertezas assumidas nas premissas e estimativas iniciais do projeto, permitindo estimar
uma reserva de contingência para cobrir as ações de resposta aos riscos conhecidos e uma reserva
gerencial para os custos desconhecidos. O objetivo das reservas é garantir com certo grau de
segurança as variações de custo e prazo que podem ocorrer ao longo do projeto (PMI, 2009).
Figura 16: O nível de exposição ao risco diminui ao longo do projeto.
Fonte: adaptado de PMI, 2013a.
68
Segundo Thamhain (2013) é possível destacar três grupos de variáveis inter-
relacionadas que devem ser consideradas na gestão de riscos e podem ser observadas na Figura
17. Entender estas variáveis é importante para selecionar o modelo de referência para a gestão de
riscos mais adequada, além das pessoas e organizações necessárias para lidar eficientemente com
a situação de risco específica:
Figura 17: Dimensões da gestão de riscos.
Fonte: adaptado de Thamhain, 2013.
(1) Grau de incerteza pode ser dividido em quatro categorias: (a) Variações das
variáveis conhecidas do projeto, tais como custo, prazo ou requisitos. Podem ser controladas de
forma eficiente pelas ferramentas convencionais de planejamento, execução e monitoramento do
projeto; (b) Contingências são os eventos conhecidos que podem ocorrer e afetar negativamente o
desempenho do projeto. Alguns métodos analíticos tais como PERT (Project Evaluation and
Review Technique) e simulações ajudam a antecipar a materialização estes eventos; (c) Acidentes
são eventos possíveis de serem identificados, mas a probabilidade e impacto são muito difíceis de
69
serem previstos; e (d) Desconhecido-desconhecido são eventos vistos como impossíveis de
acontecer dentro do contexto do projeto e passam a ser conhecidos pela equipe do projeto
somente quando ocorrem.
(2) Complexidade do projeto: existem diversos estudos que ajudam a classificar a
complexidade de um projeto, sendo que o foco principal está baseado em dois aspectos: a
“complexidade no projeto” que foca o ambiente organizacional, social e político e a
“complexidade do projeto” que foca a dimensão do porte (tamanho) do projeto sendo este mais
comumente utilizado e referenciado neste modelo como Projeto, Programa e Portfólio.
(3) Impacto do risco no projeto e organização: apesar de projetos complexos serem
susceptíveis a apresentar um impacto maior na organização, projetos pequenos podem também
impactar grandes segmentos do negócio. Sugerem-se quatro categorias de riscos baseadas no
impacto que estes podem gerar: (1) categoria I são os riscos que podem ser identificados e
tratados antes mesmo de afetar o desempenho do projeto; (2) categoria II são os riscos que podem
ser tratados e impactam um grupo de tarefas específico dentro do projeto; (3) categoria III são os
riscos que impactam o desempenho do projeto, tal como atraso no prazo final e estouro do
orçamento; e (4) categoria IV são os riscos cujo impacto extrapola o impacto no projeto e
impacta a operação da organização.
A atitude das organizações e das partes interessadas em relação aos riscos pode ser
influenciada por dois importantes fatores: apetite ao risco, que é o grau de incerteza que uma
entidade está disposta a aceitar, na expectativa de uma recompensa; e tolerância a riscos, que é o
grau, a quantidade ou o volume de risco que uma organização ou indivíduo está disposto a tolerar
(PMI, 2009).
A Figura 18 apresenta os critérios genéricos para o sucesso da gestão de riscos em
projetos na visão do PMI (2009): reconhecer o valor da gestão de riscos – investir na gestão de
riscos significa investir em uma valiosa disciplina que gera retorno positivo para a gestão
organizacional, para a gestão de projetos e para todos os envolvidos no projeto;
responsabilidade e compromisso individual – todos os participantes e envolvidos no projeto
devem entender e aceitar sua responsabilidade pela realização de atividades relacionadas à gestão
de riscos; comunicação aberta e sincera – qualquer ação ou atitude que envolva a omissão ou
dificulte a comunicação de riscos do projeto, reduzem a eficácia do processo de tomada de
70
decisões; compromisso organizacional – o compromisso organizacional somente pode ser
estabelecido se a gestão de riscos estiver alinhada com os objetivos e valores da organização. A
gestão de riscos em projetos pode exigir um nível mais elevado de apoio gerencial do que outras
disciplinas de gestão de projetos, pois muitas vezes os riscos exigem aprovação ou respostas de
pessoas que estão em níveis hierárquicos superiores ao do gerente de projeto; esforço compatível
com o projeto – o esforço e custo dispendido com as atividades de gestão de riscos devem ser
compatíveis com o valor potencial de seus benefícios tanto para o projeto quanto para a
organização; e integração com a gestão de projetos – a gestão de riscos em projetos não pode
ser realizada de forma isolada, pois seu sucesso depende da adequada execução dos demais
processos de gestão de projetos.
Figura 18: Fatores críticos de sucesso para a gestão de riscos em projetos.
Fonte: adaptado de PMI, 2009.
2.2.4 Riscos em Projetos de Software
Os riscos em projetos de software podem ser decorrentes de vários fatores, sendo os
mais comuns: mudanças de requisitos, falta de conhecimento, tecnologias defeituosas, Gold
Plating e cronogramas de projetos irreais. Em relação à mudança de requisitos é comum existir
pequenos ajustes quando não se tem uma visão clara do projeto. A falta de conhecimento ocorre
quando não se tem experiência sobre uma determinada tecnologia e, consequentemente, o projeto
estoura o prazo e orçamento, pois não considera o tempo necessário para aprendizado da equipe.
As tecnologias defeituosas são aquelas que ainda não estão maduras o suficiente e a equipe se
depara com um problema de viabilidade. O risco de Gold Plating refere-se a grandes alterações
de requisições de um item que era demasiadamente pequeno. Os cronogramas de projetos irreais
71
advêm de subestimar o tempo de desenvolvimento que a equipe necessitará para concluir o
projeto (Suresh Babu & Srivatsa, 2011).
Miorando (2010) organizou a Tabela 13 com um resumo dos principais riscos em
projetos de TI encontrados na literatura.
Tabela 13: Principais riscos em projetos de TI.
Categoria de Risco Fator de Risco Descrição
Custos
Incerteza quanto à
conclusão do projeto dentro
dos custos projetados.
Atendimento ao
orçamento
Quão bem os custos e contingências do projeto estão
estimados?
Exposição financeira Até que ponto o projeto permite abordagens de
contingência para eventos inesperados?
Estimativas e
contingências
Quão seguro é o projeto quanto às estimativas de custos e
contingências
Benefícios
Incerteza quanto à completa
realização dos benefícios
esperados.
Clareza dos benefícios Quão claro estão descritos os benefícios do projeto?
Necessita-se de algum trabalho adicional para alcançar os
benefícios?
Confiabilidade dos
benefícios
Quão confiável é a lógica que liga os benefícios
esperados com os resultados do projeto?
Validação dos benefícios Até que ponto os benefícios planejados foram validados?
Plano de realização dos
benefícios
Até que ponto é possível medir os benefícios do projeto?
Métricas e alvos Existem métricas e alvos estabelecidos para os benefícios
chave?
Processo de captura dos
benefícios
Existem processos para capturar e alavancar os
benefícios inesperados que forem descobertos?
Habilidades e experiência
Incerteza sobre a existência
das habilidades em TI e
experiência necessária para
realização do projeto.
Habilidades em TI A equipe de TI envolvida no projeto possui as qualidades
técnicas necessárias?
Habilidade na área de
negócios
A equipe envolvida no projeto possui a experiência
necessária na área de negócios do projeto?
Habilidades em gestão
de projetos
Quão experiente é a equipe na gestão de projetos?
Tamanho e complexidade
Incerteza devido ao
tamanho e complexidade do
projeto.
Tamanho do projeto Quão grande é o trabalho de TI no projeto?
Complexidade do projeto Quão complexo é o projeto em relação a outros projetos
realizados pela empresa?
Dependência de outros
projetos
Quão dependente é o projeto do sucesso de outros
projetos ou iniciativas de negócios?
Dependência de
indivíduos
Quão dependente é o projeto da habilidade e experiência
de um time específico de membros?
Arquitetura e desempenho
Incerteza sobre a
estabilidade da arquitetura,
do suporte de infraestrutura
e desempenho esperado para
o projeto.
Alinhamento da
arquitetura
Quanto a tecnologia proposta está alinhada com a
arquitetura de TI da empresa?
Segurança Quanto o projeto está compatível com as políticas de
segurança da empresa?
Ponto crítico de
desempenho
Quanto os benefícios são dependentes de um alto nível
de desempenho dos produtos do projeto?
Cronograma
Incerteza sobre a conclusão
do projeto dento do
cronograma projetado.
Prazos de
desenvolvimento
Os prazos projetados no cronograma são suficientes para
o desenvolvimento do projeto?
Interrupção do
desenvolvimento
Até que ponto os benefícios podem ser alcançados se o
projeto for terminado em um estágio intermediário?
72
Categoria de Risco Fator de Risco Descrição
Clareza de escopo
Incerteza sobre o escopo de
investimento.
Clareza do estado futuro A situação futura foi claramente antecipada,
compreendida e declarada no planejamento?
Clareza dos resultados Quão claros estão os resultados e suas relações com a
realização dos benefícios do projeto?
Clareza de foco nas áreas Até que ponto as áreas chaves foram incorporadas no
planejamento do projeto?
Suporte organizacional
Incerteza sobre o suporte
organizacional oferecido por
patrocinadores, gerentes,
unidades de negócio e
usuários.
Envolvimento das áreas
de negócio
Quanto às áreas de negócio estão envolvidas com o
projeto?
Suporte das áreas
impactadas pela
mudança
Quanto dos impactados pelas mudanças apoiam o
projeto?
Disposição do
patrocinador
Quão pronto, disposto e apto é o patrocinador para fazer
do programa um sucesso?
Patrocinadores Quanto à área de negócios está comprometida em
patrocinar o projeto?
Compromisso da fonte
de recursos
Existem recursos disponíveis vindo das áreas de negócio
afetadas pelo projeto?
Suporte de operações
computacionais
Quão comprometido é o pessoal de TI para fornecer
suporte durante o projeto?
Envolvimento da alta
gerência
Quanto à alta gerência da área de negócios está
comprometida com o projeto?
Impacto da mudança
Incertezas sobre a
habilidade das unidades de
negócio gerenciarem as
mudanças
Extensão das mudanças Quão extenso é o impacto do projeto?
Capacidade de mudança O pessoal impactado pelo projeto tem capacidade e
habilidade para assimilar as mudanças implantadas pelo
projeto?
Ambiente de negócio
Incerteza quanto à
instabilidade e
previsibilidade do ambiente
de negócio.
Adaptação às mudanças
de negócio
Quanto dos benefícios projetados serão realizados se as
prioridades de negócio mudarem?
Sensibilidade do
ambiente de negócio
Quanto os benefícios são contingentes na estabilidade do
ambiente de negócios?
Mudança das
necessidades dos clientes
Os benefícios poderão ser alcançados se as necessidades
dos clientes mudarem?
Maturidade tecnológica
Incerteza sobre a
maturidade da tecnologia
implantada.
Maturidade de TI Quão madura é a tecnologia a ser implantada pelo
projeto?
Sofisticação da TI Até que ponto as áreas afetadas estão familiarizadas com
a tecnologia utilizada no projeto?
Gestão de riscos
Incerteza sobre a adequação
do projeto e sua gestão de
riscos.
Planejamento das
diretrizes
Quanto o planejamento está adequado às boas práticas de
gestão de projeto?
Garantia da qualidade Existe garantia do processo de qualidade planejado para
o projeto?
Tomada de decisão Existe um processo efetivo para tomada de decisão no
projeto?
Nota. Fonte: Miorando, 2010.
73
2.2.5 Gestão de Riscos em Projetos
Segundo a International Organization for Standardization – ISO (ISO, 2009) a gestão
de riscos pode ser aplicada a toda uma organização, em suas várias áreas e níveis, a qualquer
momento, bem como a funções, atividades e projetos específicos.
A gestão de riscos pode ser justificada em quase todos os projetos. O nível de
formalização pode variar de projeto para projeto, dependendo de fatores como tamanho, tipo de
projeto, quem é o cliente, requisitos contratuais, a relação com o plano estratégico corporativo e a
cultura corporativa. É particularmente importante quando as apostas globais são altas e/ou
quando há uma grande dose de incerteza. A gestão de riscos obriga a equipe do projeto a se
concentrar no futuro, em que existe incerteza, e desenvolver planos adequados de ação para evitar
que questões potenciais se tornem problemas e impactem negativamente o projeto (Kerzner,
2013).
Segundo Lockyer and Gordon (2005), diferentemente da maioria das atividades
industriais, onde se lida com contextos conhecidos e relativamente estáveis, projetos se
preocupam com as mudanças e lidam com incertezas consideráveis. Assim, os riscos em
indústrias tendem a ser pequenos e aceitáveis enquanto que, em projetos, a situação é bem
diferente.
O objetivo da gestão de riscos em projetos é: (1) identificar eventos que possam
impactar os objetivos do projeto relacionados ao custo, escopo, prazo e qualidade; (2) quantificar
o impacto provável de cada evento; (3) definir uma referência para os eventos não controláveis
do projeto; e (4) mitigar os impactos, exercendo influência sobre os eventos controláveis do
projeto. Também é possível delimitar o escopo da atividade de gestão de riscos que se encaixa
entre a total certeza (a probabilidade de o evento ocorrer é de 100%) e a total incerteza (evento
que ninguém consegue imaginar), conforme apresentado na Figura 19 (Wideman, 1992).
Em 2002 Raz, Shenhar e Dvir (2002) diziam que as ferramentas e técnicas de gestão de
riscos foram desenvolvidas para melhorar o sucesso dos projetos; entretanto, os autores já
mencionavam que tais ferramentas ainda estaria na sua infância e investimentos em pesquisas e
treinamentos eram necessários. Segundo Alberts and Dorofee (2012) o problema continua, muito
projetos ainda falham devido à falta de maturidade das organizações em gestão de riscos. Os
74
problemas identificados são: falta de padronização na prática da gestão de riscos entre as diversas
áreas da organização; falta de integração entre a gestão de riscos dos projetos e as políticas da
organização; e aumento da complexidade dos ambientes empresariais.
Figura 19: O espectro da incerteza.
Fonte: Wideman, 1992.
Quanto mais complexo o projeto, maior a necessidade de gerenciar os riscos de forma
estruturada e organizada. Um gestor de projetos experiente consegue gerenciar os riscos de
projetos pouco complexos utilizando apenas seu conhecimento individual, análises e
experiências; entretanto, quanto mais complexo o projeto, maiores são os riscos técnicos e não
técnicos (custo e prazo), e mais robustos devem ser os controles. Ou seja, devem-se utilizar
métodos, ferramentas e processos adequados de gestão de riscos para garantir a realização dos
objetivos do projeto (Higuera & Haimes, 1996).
O nível de detalhe, a sofisticação das ferramentas, e a quantidade de tempo e recursos
aplicados devem ser proporcionais às características do projeto e sua importância para a
organização. Ou seja, teoricamente, um grande projeto com muitos benefícios deveria dispender
mais esforços na gestão de riscos do que um pequeno projeto (PMI, 2009).
A maioria das perspectivas de gestão de riscos envolve análise do contexto,
identificação, análise e avaliação de riscos, tratamento, monitoramento e conferência. No entanto,
para ser efetivo, um método de avaliação de riscos deve considerar os aspectos tecnológicos,
mercadológicos, financeiros, operacionais, organizacionais e de negócio, relacionando-os ao ciclo
de vida do projeto. Dessa forma, as possibilidades de estratégias para a gestão de riscos baseiam-
se em duas formas possíveis: uma objetiva a redução das circunstâncias de riscos e a outra cuida
do tratamento dos riscos após o seu surgimento (Aloini, Dulmin, & Mininno, 2007).
75
O passo inicial para uma boa gestão de riscos em projetos é planejar quais abordagens
serão utilizadas durante o projeto. Para isso é importante observar a singularidade de cada
organização, evidenciando-as nas abordagens de gestão de risco escolhidas. Não existem
soluções-padrão, pois cada corporação tem seu próprio limiar de exposição ao risco que deve ser
respeitado. Algumas empresas possuem padrão corporativo para o planejamento do risco, o que
facilita a tarefa do gestor de projetos e da equipe de risco, pois esta precisa apenas customizar o
padrão ao projeto em andamento (Carvalho & Rabechini, 2011).
2.2.6 Gestão de Riscos em Projetos de Software
A gestão de risco em projetos de software tem objetivos fundamentalmente diferentes:
prevenir riscos; mitigar e corrigir riscos; e garantir a falha segura do sistema. Para alcançar estes
objetivos devem ser considerados os seguintes princípios: (1) visão compartilhada do produto
com foco em resultado; (2) trabalho em equipe para atingir um objetivo comum; (3) reconhecer o
valor das oportunidades e o impacto dos efeitos adversos; (4) visão prospectiva para antecipar as
incertezas; (5) comunicação aberta entre todos os níveis envolvidos no projeto; (6) gestão
integrada ao garantir que a gestão de riscos seja uma parte importante da gestão do projeto; e (7)
processos contínuos para identificar e gerenciar os riscos rotineiramente durante todo o ciclo de
vida do projeto (Higuera & Haimes, 1996).
Durante o desenvolvimento de um software, existem diversas possibilidades para que
algo dê errado. A equipe que desenvolve o software espera realizar uma implantação segura e
completa e o cliente espera que não haja problemas com as transações no ambiente produtivo.
Mas, infelizmente, é crescente o número de casos em que os softwares são implantados e
apresentam consequências negativas para os usuários. Isto é mais significante quando os
softwares são utilizados nas áreas chave das organizações, pois uma falha gera impacto direto no
resultado do negócio. Ou seja, ao implantar um novo software ou realizar manutenções nas
versões existentes, a organização assume um grande número de riscos (Maguire, 2002).
A atividade de desenvolvimento de software é complexa e imprevisível. Isso significa
que os riscos devem ser controlados para garantir o sucesso do projeto. A probabilidade e o
impacto no desempenho do projeto devem ser considerados para o desenvolvimento de uma boa
76
estratégia de gestão de riscos. Isso significa que a gestão de riscos em software implica em
quantificar e priorizar os riscos por meio de uma adequada análise de probabilidade e impacto.
Quanto melhor o entendimento sobre os riscos envolvidos no projeto de software, melhor será o
resultado tanto do projeto quanto do produto final (Han & Huang, 2007; Huang & Han, 2008).
A gestão de riscos em um projeto de software deve abordar questões como a análise dos
requisitos funcionais, o estabelecimento do escopo, a identificação das funcionalidades
vulneráveis a falhas, a identificação dos eventos de risco, a análise do risco, o desenvolvimento
de um plano de gestão de risco e o controle de risco. Quando uma gestão de riscos é realizada de
forma correta, o projeto é concluído com sucesso, satisfazendo o cliente, realizando os objetivos
propostos e melhorando o desempenho financeiro da organização (Dey, Kinch, & Ogunlana,
2007).
A gestão de riscos será mais eficiente se sua prática for moldada ao tipo de projeto e
aderente aos processos, políticas e cultura organizacional (PMI, 2009). O guia Software
Extension to the PMBOK Guide apresenta a gestão de riscos em projetos de software e descreve
os riscos e estratégias de mitigação de riscos mais importantes para este tipo de projeto (PMI &
IEEE, 2013):
Cada projeto de software tem diferentes incertezas, riscos e oportunidades, porque cada projeto
de software é uma combinação única de requisitos, arquitetura e construção, resultando em um
produto de software diferente. Os riscos do projeto de software e os riscos técnicos de software
afetam todos os envolvidos. A gestão de riscos tem a intenção de aumentar a probabilidade de
atingir as metas do projeto, enquanto a gestão de oportunidades tem a intenção de superar as
metas do projeto. A gestão de oportunidades é geralmente praticada na gestão de projetos de
software, especialmente em projetos de adaptação que têm a oportunidade de responder
rapidamente às mudanças solicitadas pelo cliente, aplicar uma nova tecnologia, ou aceitar
recursos adicionais. O processo de gestão de riscos é um processo contínuo para a identificação
sistemática, análise, tratamento e monitoramento de risco em todo o ciclo de vida de um
produto ou serviço. Riscos que ocorrem geralmente em projetos de software incluem
engenharia, cronograma, custo, qualidade (por exemplo, segurança e disponibilidade), equipes e
fatores de risco dos envolvidos. Os possíveis tratamentos de risco incluem aceitar, evitar,
transferir ou mitigar o risco (tradução livre). 3
3 Each software development project has different uncertainties, risks, and opportunities because each software
project is a unique combination of requirements, design, and construction, resulting in a distinct software product.
Software project risks and software technical risks affect every stakeholder. Software risk management aims to
improve the probability of achieving the project goals; software opportunity management aims to exceed the project
goals. Opportunity management is commonly practiced in software project management, especially in adaptive
projects that have the opportunity to rapidly respond to customer-requested changes, apply new technology, or accept
additional resources. The risk management process is “a continuous process for systematically identifying,
analyzing, treating, and monitoring risk throughout the life cycle of a product or service”. Commonly occurring
risks for software projects include technical, schedule, cost, quality (e.g., security, safety, availability), team
77
Um dos primeiros livros publicados sobre gestão de riscos em projetos de software foi
escrito por Barry Boehm em 1989 e apresenta diversas técnicas para avaliação e controle dos
riscos em projetos de software divididos em seis passos: identificação, análise, priorização,
planejamento, solução e monitoramento (Boehm, 1989).
O modelo proposto por Boehm (1991) organiza os processos da gestão de riscos em dois
passos primários e cada um destes passos em três passos auxiliares com diversas técnicas
associadas. A Figura 20 apresenta de forma sumarizada a maioria dos passos e técnicas
envolvidas na gestão de riscos em projetos de software.
Figura 20: Passos da gestão de riscos em projetos de software proposto por Boehm.
Fonte: adaptado de Boehm, 1991.
dynamics, and customer/stakeholder risk factors. Risk treatments include accepting, avoiding, transferring, or
mitigating risk.
78
Zwikael (2009), após pesquisa envolvendo 783 participantes de diversos países, sendo
que 241 (30%) participantes eram profissionais da indústria de software, concluiu que a área de
conhecimento do PMBOK relacionada a risco em projetos, é a segunda mais importante na
determinação do sucesso de um projeto durante a fase de planejamento. Apesar da importância, o
autor observou uma baixa utilização dos processos de gestão de riscos, principalmente devido à
falta de disponibilidade dos gerentes funcionais durante a etapa de identificação de riscos e da
falta de prática na utilização das ferramentas e formalização dos riscos.
De acordo com Boehm (1991), apesar da diversidade de técnicas e ferramentas, os
gestores de projetos devem ter discernimento e focar nos fatores críticos de sucesso, mas por
diversas razões, alguns gestores esquecem este conceito básico e preocupam-se com questões
irrelevantes. O julgamento humano ainda é o item mais importante para o sucesso de um projeto
de software; entretanto, o modelo conceitual e as técnicas de avaliação de risco e controle podem
fornecer as competências necessárias para melhorar o julgamento humano.
2.2.7 Modelos de Referência em Gestão de Riscos
As empresas se utilizam de modelos de referência para organizar seus processos
gerenciais organizando assim seus modelos de gestão (Cardoso, 2008) e a bibliografia apresenta
diversos modelos de referência para gestão de riscos. Ao analisar os processos de alguns destes
modelos desenvolvidos ao longo do tempo por renomados autores e instituições internacionais,
observa-se que o processo de identificação de riscos é imprescindível em todos os modelos
estudados e destaca-se pela sua importância.
Os modelos são apresentados do mais genérico para o mais específico: o modelo da ISO
é de utilização genérica e atende qualquer segmento de mercado; o modelo do PMI é específico
para gestão de projetos, mas o PMI elaborou uma versão adaptada para projetos de software que
foi elaborada em conjunto com o IEEE (Institute of Electrical and Electronics Engineers); e o
modelo do SEI é específico para o desenvolvimento de projetos de software.
79
2.2.7.1 Modelo de Referência em Gestão de Riscos da ISO – ISO 31000
Para as organizações, as normas internacionais facilitam o comércio mundial e a
penetração em novos mercados, pois garantem que os produtos e serviços são seguros, confiáveis
e de boa qualidade. Além disso, são ferramentas estratégicas que ajudam a tornar a indústria mais
eficiente e eficaz, porque reduzem os custos, minimizam os erros e aumentam a produtividade
(http://www.iso.org, recuperado em 6 março, 2014).
A ISO é a maior desenvolvedora de normas internacionais voluntárias do mundo. Foi
fundada em 1947 e já desenvolveu mais de 19.500 normas abrangendo diversos aspectos de
tecnologia e negócios. Tais normas são desenvolvidas por meio de um consenso entre
especialistas de todo o mundo e oferecem o estado da arte em especificações de produtos,
serviços e boas práticas. Atualmente sua sede está localizada em Genebra na Suíça, possui 150
pessoas trabalhando em tempo integral e conta com membros de 162 países e 3.368 órgãos
técnicos para cuidar do desenvolvimento de padrões (http://www.iso.org, recuperado em 6 março,
2014).
A sigla ISO é uma referência mundial. Como o nome International Organization for
Standardization teria diferentes siglas em diferentes línguas (IOS em inglês, OIN em francês para
Organisation Internationale de Normalisation) decidiu-se pela sigla ISO que é derivada da
palavra grega isos e significa “igual” (http://www.iso.org, recuperado em 6 março, 2014).
A Figura 21 apresenta alguns dos principais acontecimentos na história da ISO: em 1960
foi publicada a ISO 31 (Sistema Internacional de Unidades), atual ISO 80000, para garantir a
uniformidade nas unidades de medida, por exemplo, metro para distância e segundos para tempo;
em 1987 foi publicada a família ISO 9000 de normas de gestão da qualidade que é amplamente
utilizada nas empresas ao redor do mundo; em 1996 foi lançada a ISO 14001, trata-se de uma
norma de gestão ambiental com ferramentas que ajudam as organizações a identificar e controlar
seus impactos ambientais; em 2005 foi publicada em conjunto com a IEC (International
Electrotechnical Commission) a ISO/IEC 27001, projetada para garantir a seleção adequada de
controles de segurança das informações da organização e tornou-se uma das mais populares
normas da instituição; em 2009 foi publicada a ISO 31000 que estabelece princípios e diretrizes
para a gestão de riscos nas organizações e será discutida em detalhes nesta dissertação; e em
80
2010 foi lançada a ISO 26000 que contém orientações sobre como as organizações podem operar
de uma maneira socialmente responsável (http://www.iso.org, recuperado em 6 março, 2014).
O modelo de referência em gestão de riscos da ISO foi lançado em 2009 e batizado
como “ISO 31000 – Gestão de riscos – Princípios e diretrizes”. Trata-se de um modelo genérico
aplicável a qualquer tipo de organização e qualquer tipo de risco, ou seja, pode ser aplicado em
uma empresa do setor bancário e tratar riscos de projetos.
Figura 21: Linha do tempo da história da ISO.
Fonte: elaborado pelo autor.
Segundo a ISO (ISO, 2009), embora o risco seja sempre gerenciado em algum grau, a
norma estabelece onze princípios que devem ser atendidos para tornar a gestão de riscos eficaz.
Adicionalmente sugere que as organizações elaborem, implantem e melhorem continuamente um
framework que integre o processo de gerenciamento de riscos com os demais processos existentes
na organização.
A ISO (ISO, 2009, p. 1) assim detalha o escopo da norma:
Esta norma fornece princípios e diretrizes genéricas para a gestão de riscos.
Esta norma pode ser utilizada por qualquer empresa pública, privada ou comunitária,
associação, grupo ou indivíduo. Portanto, esta Norma não é específica para qualquer indústria
ou setor.
Esta norma pode ser aplicada ao longo da vida de uma organização e a uma ampla gama de
atividades, incluindo estratégias, decisões, operações, processos, funções, projetos, produtos,
serviços e ativos.
Esta norma pode ser aplicada a qualquer tipo de risco, independentemente de sua natureza, quer
tenha consequências positivas ou negativas.
Embora esta norma forneça diretrizes genéricas, ela não pretende promover a uniformidade da
gestão de riscos entre organizações. A concepção e a implementação de planos e estruturas para
gestão de riscos precisarão levar em consideração as necessidades variadas de uma organização
81
específica, seus objetivos, contexto, estrutura, operações, processos, funções, projetos,
produtos, serviços ou ativos e práticas específicas empregadas.
Pretende-se que esta Norma seja utilizada para harmonizar os processos de gestão de riscos
tanto em normas atuais como em futuras. Esta norma fornece uma abordagem comum para
apoiar Normas que tratem de riscos e/ou setores específicos, e não substituí-las.
Para uma gestão adequada de riscos, a organização deve considerar os seguintes
princípios: (a) criar e proteger valor – contribuir com a realização dos objetivos e melhoria do
desempenho da organização; (b) ser parte integrante dos processos organizacionais – a gestão
de riscos deve estar presente em todos os processos organizacionais, incluindo o planejamento
estratégico, gestão de projetos e gestão de mudanças; (c) ser um componente do processo de
tomada de decisões – os riscos avaliados ajudam na tomada consciente de decisões e priorização
de ações; (d) endereçar a incerteza – os riscos dever ser identificados e declarados para que
sejam gerenciados; (e) desenvolver-se de uma forma sistemática, estruturada e contínua –
dessa forma é possível obter resultados consistentes, comparáveis e confiáveis; (f) basear-se nas
melhores informações disponíveis – considerar dados históricos, previsões e opiniões de
especialistas, mas sempre considerando as limitações de tais fontes de informação; (g) moldar-se
à organização – considerar as características internas e externas da organização, além de seu
apetite ao risco; (h) considerar fatores humanos e culturais – reconhecer as capacidades das
equipes internas e externas e como isso afeta à realização dos objetivos da organização; (i) ser
transparente e inclusiva – envolver adequadamente os tomadores de decisão em todos os níveis
da organização para que suas opiniões sejam consideradas e a gestão de riscos mantenha-se
atualizada; (j) ser dinâmica, iterativa e adaptável às mudanças – acompanhar as mudanças dos
ambientes internos e externos para manter os principais riscos sempre atualizados; (k) facilitar a
melhoria contínua da organização – investir constantemente na melhoria da maturidade em
gestão de riscos da organização (ISO, 2009).
O framework proposto pela ISO 31000 (2009) orienta o adequado gerenciamento de
riscos por meio do uso do processo de gestão de riscos que pode ser aplicado em diferentes níveis
da organização. Para as organizações que já possuem um processo formal de gestão de riscos,
sugere-se que a norma seja utilizada como referência para avaliar a suficiência e eficácia deste
processo. O framework é divido em cinco componentes:
(1) Mandato e comprometimento – para que a gestão de riscos seja adequadamente
introduzida e mantida na organização é necessário constar no planejamento estratégico da
82
organização e garantir o comprometimento dos executivos em todos os níveis. A administração
da organização deve: aprovar uma política de gestão de riscos alinhada com os objetivos da
organização; criar indicadores de desempenho; garantir a conformidade legal; e garantir recursos
para execução das tarefas.
(2) Concepção do framework organizacional – define como o sistema de gestão de riscos
deve ser implantado, monitorado e revisado dentro da organização. Para isso são necessárias
algumas etapas: entender o contexto externo e interno no qual a organização está inserida;
estabelecer uma política de gestão de riscos clara e divulgá-la de forma apropriada; garantir a
responsabilidade, autonomia e competência tanto para os responsáveis pela manutenção do
framework quanto para os responsáveis pelo gerenciamento dos riscos; integrar a gestão de
riscos aos processos organizacionais existentes; garantir os recursos necessários para a realização
das atividades (pessoas, métodos, ferramentas, processos, sistemas e treinamento); estabelecer os
mecanismos de comunicação interna; e estabelecer os mecanismos de comunicação externa
para atender os clientes, fornecedores, acionistas e órgãos reguladores.
(3) Implantação da gestão de riscos: definir a estratégia e o melhor momento para
implantar o framework e o processo de gestão de riscos, garantindo a adequada comunicação,
orientação e treinamento de todos os envolvidos no processo.
(4) Monitoramento e análise crítica do framework: medir o desempenho da gestão de
riscos por meio de indicadores e garantir a avaliação e contínua do framework.
(5) Melhoria contínua da estrutura: com base nos indicadores, definir ações para
melhorar a política, o plano e o framework de gestão de riscos.
Por fim, a norma detalha o processo de gestão de riscos, apresentado na Figura 22, que
são as atividades coordenadas para dirigir e controlar o efeito das incertezas nos objetivos da
organização.
(1) Comunicação e consulta: elaborar um plano de comunicação e consulta contínuo às
partes interessadas garantindo que seus interesses sejam compreendidos e considerados na
identificação, avaliação e tratamento dos riscos;
(2) Estabelecimento do contexto: definir a metodologia e o apetite ao risco da
organização orientando o escopo e critérios dos demais processos. Deve considerar os objetivos,
83
o contexto externo (ambiente cultural, social, político, legal, regulatório, financeiro, tecnológico,
econômico e competitivo) e interno da organização (governança, estrutura organizacional,
políticas, sistemas, cultura e estratégia);
Figura 22: Modelo de referência para a gestão de riscos da ISO (ISO 31000).
Fonte: ISO, 2009.
(3) Identificação de riscos: gerar uma lista abrangente de riscos baseada nas incertezas
que possam criar, aumentar, evitar, reduzir, acelerar ou atrasar a realização dos objetivos;
(4) Análise dos riscos: determinar as causas e fontes de riscos, suas consequências
positivas e negativas nos objetivos da organização, a probabilidade de que essas consequências
ocorram, a eficácia e eficiência dos controles atualmente existentes e a interdependência entre os
riscos. A análise pode ser qualitativa, sem quantitativa ou quantitativa;
(5) Avaliação de riscos: priorizar os riscos analisados considerando sua probabilidade,
impacto, tolerância aos riscos assumida para o processo e o contexto estabelecido;
(6) Tratamento de riscos: avaliar o nível do risco residual e tratá-lo quando este não for
tolerável. Existem várias alternativas para tratamento do risco: aumentar o nível do risco para
aproveitar uma oportunidade, eliminar a fonte de risco, alterar a probabilidade, alterar as
consequências ou compartilhar o risco com outra parte;
84
(7) Monitoramento e análise crítica: manter checagem ou vigilância regular para garantir
que os controles sejam eficazes e eficientes no projeto e na operação, além de identificar riscos
emergentes e avaliar o resultado do tratamento.
Pode-se notar que a norma é genérica e orientativa, ou seja, é uma referência para que as
organizações produzam seu próprio framework de gestão de riscos e muitos trabalhos ainda
devem ser desenvolvidos utilizando-se a ISO 31000 como guia. Em 2010 o IIA (Institute of
Internal Auditors) elaborou um manual explicando como a norma poderia ser utilizada pelos
auditores internos (MacLeod et al., 2010) e em 2012 Ernawati, Suhardi e Nugroho (2012)
propuseram um framework para gestão de riscos em tecnologia baseado na ISO 31000.
2.2.7.2 Modelo de Referência em Gestão de Riscos de Projetos do PMI
Para entender o modelo de referência em gestão de riscos do PMI é importante
compreender a relação entre suas diversas publicações utilizada neste estudo. A Figura 23
apresenta a relação entre a Prática-padrão para o Gerenciamento de Riscos em Projetos, Guia
PMBOK, livros didáticos, manuais e cursos.
Figura 23: Hierarquia dos recursos oferecidos pelo PMI para a gestão de riscos.
Fonte: PMI, 2009.
O PMI descreve essa relação da seguinte forma (2009, p. 1):
Práticas-padrão são guias para o uso de uma ferramenta, técnica ou processo identificado no
Guia PMBOK® ou outros padrões do PMI. As práticas-padrão são direcionadas aos públicos
que participam do gerenciamento de projetos. Isto inclui gerentes de projeto, a equipe do
projeto, a equipe contratada, supervisores e outros envolvidos no projeto.
85
Uma prática-padrão do PMI descreve processos, atividades, entradas e saídas para uma área de
conhecimento específica. A prática-padrão fornece informações sobre os processos, ferramentas
e técnicas significantes, o que fazem, por que são importantes, quando devem ser executados e
quem são os responsáveis. Uma prática-padrão não prescreve a forma como o processo deve ser
implantado, deixando esse assunto para outros fóruns, como manuais, livros didáticos e cursos.
O objetivo da prática-padrão para Gerenciamento de Riscos em Projetos é: (a) fornecer aos
profissionais de gerenciamento de projetos e outras partes interessadas um padrão que define os
aspectos da Gestão de Riscos em Projetos reconhecidos como uma boa prática na maioria dos
projetos e na maior parte do tempo e; (b) fornecer um padrão que é globalmente aplicável e
consistentemente aplicado (tradução livre). 4
Segundo o guia PMBOK (2013), a gestão de riscos do projeto não é uma atividade
opcional, trata-se de uma atividade essencial para atingir o sucesso da gestão do projeto. Os
objetivos da gestão de riscos do projeto são aumentar a probabilidade e o impacto dos eventos
positivos e diminuir a probabilidade e o impacto de eventos negativos no projeto. Para atender
esses objetivos foram desenvolvidos os seguintes processos: planejar o gerenciamento dos riscos,
identificar os riscos, realizar a análise qualitativa dos riscos, realizar a análise quantitativa dos
riscos, planejar as respostas aos riscos e controlar os riscos.
A gestão de risco continua a agregar valor ao projeto à medida que o planejamento
avança e mais informações tornam-se disponíveis sobre diversos aspectos, tais como clareza dos
interesses dos envolvidos, detalhamento do escopo, estimativas de tempo e custo mais assertivas
e premissas e restrições revisadas. Durante a execução do projeto, os processos de gestão de risco
monitoram as mudanças do projeto para identificar, analisar e elaborar adequados planos de
resposta aos novos riscos encontrados, além de revisar os riscos que não são mais plausíveis. A
gestão de riscos do projeto tem um papel fundamental na elaboração de estimativas realistas para
4 Practice standards are guides to the use of a tool, technique, or process identified in A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) or other PMI standards. Practice standards are targeted at
audiences who participate in the management of projects. This includes project managers, project personnel, contract
personnel, supervisors, and other project stakeholders.
A PMI practice standard describes processes, activities, inputs, and outputs for a specific Knowledge Area. It
provides information on what the significant process, tool, or technique is, what it does, why it is significant, when it
should be performed or executed, and, if necessary for further clarification, who should perform the process. A
practice standard does not prescribe how the process is to be implemented, leaving that subject for other forums such
as handbooks, manuals, and courses.
The purpose of the Practice Standard for Project Risk Management is to: (a) provide a standard for project
management practitioners and other stakeholders that defines the aspects of Project Risk Management that are
recognized as good practice on most projects most of the time and; (b) provide a standard that is globally applicable
and consistently applied.
86
as datas de conclusão e os custos do projeto. Finalmente, durante a fase de encerramento do
projeto, as lições aprendidas são revisadas, documentadas e armazenadas em local apropriado.
Dessa forma, o conhecimento adquirido pode ser disseminado pela organização, contribuindo
com o processo de aprendizagem e melhoria contínua da gestão de riscos (PMI, 2009).
Os processos envolvidos na gestão de riscos de projetos (PMI, 2009, 2013a; PMI &
IEEE, 2013):
Planejar o gerenciamento dos riscos – define o escopo e objetivos dos processos de
gestão de riscos, e garante que o processo de risco está integrado aos demais processos de gestão
do projeto. O principal benefício deste processo é que ele garante que o grau, tipo, e visibilidade
do gerenciamento dos riscos sejam proporcionais tanto aos riscos quanto à importância do projeto
para a organização. O plano de gerenciamento dos riscos é vital na comunicação, obtenção de
acordo e apoio das partes interessadas para garantir que o processo de gerenciamento dos riscos
seja apoiado de maneira efetiva;
Identificar os riscos – identifica e documenta as características do maior número
possível de riscos relevantes que podem afetar o projeto;
Realizar a análise qualitativa dos riscos – prioriza os riscos para análise ou ação
adicional por meio da avaliação e combinação de sua probabilidade de ocorrência e impacto. O
principal benefício deste processo é habilitar os gerentes de projetos a reduzir o nível de incerteza
e focar os riscos de alta prioridade;
Realizar a análise quantitativa dos riscos – analisa numericamente o efeito dos riscos
identificados nos objetivos gerais do projeto. O principal benefício deste processo é a produção
de informações quantitativas dos riscos para auxiliar a tomada de decisões e reduzir o grau de
incerteza dos projetos. Permite avaliar o efeito combinado dos riscos sobre o resultado geral do
projeto;
Planejar as respostas aos riscos – determina apropriadas ações e respostas estratégias
para cada risco individual e para o risco geral do projeto, além de integrá-los em um plano de
gerenciamento de projeto consolidado. Permite aumentar as oportunidades e reduzir as ameaças
aos objetivos do projeto. O principal benefício deste processo é a abordagem dos riscos por
prioridades, adicionando recursos e atividades no orçamento, no cronograma e no plano de
gerenciamento do projeto, conforme necessário;
87
Controlar os riscos – é o processo de implantação de planos de respostas aos riscos,
acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de
novos riscos e avaliação da eficácia do processo de riscos durante todo o projeto. O principal
benefício deste processo é a melhoria do grau de eficiência da abordagem dos riscos no decorrer
de todo o ciclo de vida do projeto a fim de otimizar continuamente as respostas aos riscos. É da
natureza dos projetos que as circunstâncias mudem durante seu planejamento e execução. A
quantidade de informação disponível sobre os riscos normalmente irá aumentar à medida que o
tempo passa. Alguns riscos ocorrem e outros não, novos riscos surgem ou são descobertos, e as
características daqueles que já foram identificados podem mudar. Por isso o processo de
identificação e análise dos riscos deve ser revisitado periodicamente e o progresso dos planos de
ação devem ser monitorados e ajustados sempre que necessário.
É fundamental que as saídas do processo de gerenciamento dos riscos do projeto sejam
consideradas nos demais processos de gerenciamento de projetos, pois podem impactar, por
exemplo:
– As estimativas dos requisitos de recursos, custo ou duração;
– A avaliação do impacto das mudanças de escopo propostas;
– O planejamento ou replanejamento da estratégia futura do projeto;
– A alocação de recursos para tarefas; e
– Os relatórios de progresso distribuídos aos envolvidos no projeto.
2.2.7.3 Modelo de Referência em Gestão de Riscos de Software do SEI
O SEI é um centro de pesquisa e desenvolvimento financiado pelo governo federal dos
Estados Unidos por meio de seu Departamento de Defesa e operado pela Universidade Carnegie
Mellon em Pittsburgh. O SEI trabalha em estreita colaboração com as organizações de defesa,
governo, indústria e academia para melhorar continuamente os processos relacionados a
engenharia de software e segurança de dados. Seu principal objetivo é ajudar as organizações a
melhorar as suas capacidades de engenharia de software e desenvolver ou adquirir o software
correto, livre de defeitos, dentro do orçamento e no tempo necessário. O SEI divulga suas
tecnologias para a comunidade global de engenharia de software por meio de seus cursos
88
públicos, conferências, relatórios técnicos e parceiros (http://www.sei.cmu.edu, recuperado em 6
março, 2014). O SEI tem conduzido pesquisas sobre a gestão de riscos desde a década de 90 e
diversas soluções foram desenvolvidas, testadas e implantadas nas organizações. Diversas
avaliações de risco em software já foram aplicadas utilizando a Taxonomia de Riscos e
continuam válidas até hoje (http://www.sei.cmu.edu/risk, recuperado em 3 abril, 2014).
Higuera e Haimes (1996, p. 2) explicam que o modelo de gestão de riscos não é apenas
teórico, trata-se de um modelo de sucesso que é amplamente utilizado pelas organizações e o
descrevem da seguinte forma:
Ampla literatura existe sobre o processo de avaliação e gestão de risco. A maioria destas
literaturas, no entanto, é dedicada a teorias e metodologias que não foram submetidas para o
teste final da prática. Este artigo apresenta teorias e processos desenvolvidos no SEI que foram
implantados com sucesso e testados em campo por numerosos clientes.
O objetivo do Programa de Riscos do SEI é capacitar engenheiros, gestores e outros tomadores
de decisão a identificar com antecedência suficiente, os riscos associados com a aquisição de
software, desenvolvimento, integração e implantação para que apropriadas estratégias de gestão
e mitigação possam ser desenvolvidas em tempo hábil. O tempo é crítico e o objetivo é agir o
mais cedo possível, antes que uma fonte de risco evolua para uma grande crise. Em outras
palavras, ser principalmente reativa em mitigação de riscos e controle ao invés de proativa na
prevenção e controle de risco é o coração de uma boa gestão de risco (tradução livre).5
Segundo Higuera and Haimes, a gestão de riscos é continua e deve ser aplicada durante
todo o ciclo de vida do projeto de software. O framework da metodologia possui três dimensões:
(1) Dimensão temporal – significa que os riscos devem ser entendidos e monitorados
conforme a evolução do projeto no tempo. A primeira fase de um projeto de software é a
Definição dos Requisitos, e é nesta fase onde se encontra a principal fonte de riscos críticos de
um projeto, pois quando os requisitos são mal definidos, as entregas não atendem a expectativa
do cliente e o projeto fracassa. O ciclo de vida do projeto, excetuando-se a fase de Definição de
Requisitos, é apresentado em duas visões distintas: micro visão – visão gerencial do gestor de
projetos; e macro visão – visão técnica dos engenheiros de software;
5 Ample literature exists on the process of risk assessment and management. The majority of this literature, however,
is devoted to theories and methodologies that have not been subjected to the ultimate test of practice. This paper
presents comprehensive theories and processes developed at the SEI that have been successfully deployed and tested
in the field by numerous clients.
The goal of SEI Risk Program is to enable engineers, managers, and other decision makers to identify, sufficiently
early, the risks associated with software acquisition, development, integration, and deployment so that appropriate
management and mitigation strategies can be developed on a timely basis. Time is critical and the goal is to act early
before a source of risk evolves into a major crisis. In other words, being mainly reactive in risk mitigation and
control rather than proactive in risk prevention and control is at the heart of good risk management.
89
(2) Dimensão metodológica – as metodologias utilizadas para compor o framework
permitem uma abordagem estruturada da avaliação e gestão dos riscos associados com o processo
de desenvolvimento de software. De uma forma geral a gestão de riscos ocorre em duas etapas: a
avaliação de riscos e a análise de risco. Por um lado, a avaliação de riscos permite identificar,
medir, quantificar e avaliar as consequências e impactos dos riscos ao responder três perguntas:
(1) O que pode dar errado? (2) Qual a probabilidade de dar errado? (3) Quais as consequências do
erro? Por outro lado, a análise de risco permite tomar decisões ao responder outras três
perguntas: (1) O que pode ser feito? (2) Quais as opções disponíveis? (3) Quais os impactos de
cada uma das opções?
(3) Dimensão humana – aborda os riscos originários da intensa atividade intelectual
necessária para o desenvolvimento de software em quatro perspectivas: (1) o indivíduo é uma
ampla fonte de riscos para o projeto, pois pode ocorrer a falta de treinamento, conhecimento,
habilidade, atitude, comprometimento com o projeto e lealdade à organização; (2) a equipe é um
grupo de indivíduos com habilidades complementares que trabalham de forma integrada para
alcançar o mesmo objetivo, ou seja, a equipe é a peça chave que vai garantir a adequada gestão
de riscos do projeto; (3) os gestores existem em diversos níveis hierárquicos (operacional, tático e
estratégico) e cada nível possui um escopo de atuação e nível de responsabilidade diferente,
sendo assim, a gestão de riscos do projeto deve possuir mecanismos que facilitem a análise de
riscos de forma detalhada e consolidada; (4) stakeholders são indivíduos ou organizações
internos ou externos que possuem interesses no projeto, por isso é importante entender seu papel
no projeto e quais ameaças ou oportunidades podem trazer ao projeto.
A metodologia do modelo de referência do SEI está fortemente apoiada no processo
contínuo de avaliação de riscos, na Taxonomia de Riscos que é um método para estruturar e
organizar os riscos, e na ferramenta TBQ (Taxonomy-Based Questionnaire) para identificação de
riscos (Higuera & Haimes, 1996).
O processo está representado na Figura 24, onde o círculo enfatiza que a gestão de riscos
é um processo contínuo, as setas apresentam o fluxo lógico da informação e a comunicação é
centro do processo para garantir a integração entre as atividades, pois este geralmente é o maior
obstáculo da gestão de riscos (Higuera & Haimes, 1996).
90
Figura 24: Processo de gestão de riscos.
Fonte: Higuera & Haimes, 1996.
As atividades do processo são:
– Identificar os riscos: relacionar os riscos do projeto;
– Analisar os riscos: significa converter os dados dos riscos em informações para a
tomada de decisões. Os riscos identificados precisam ser priorizados, mas antes devem ser
analisados para que suas causas e consequências sejam determinadas;
– Planejar a resposta aos riscos: identificar os responsáveis e elaborar um plano de ação
para cada um dos riscos. Dessa forma é possível integrar e priorizar as ações necessárias para
tratar os riscos. As ações podem ser mitigar (reduzir o impacto), evitar (não permitir que o risco
se materialize) ou aceitar o risco (caso ocorra, aceitar as consequências);
– Monitorar os riscos: acompanhar periodicamente a situação dos riscos e ações
necessárias. O uso de métricas de riscos é importante para facilitar a gestão do gerente de projeto;
– Solucionar os riscos: significa corrigir os desvios das ações planejadas, ou seja,
monitorar os gatilhos para garantir que os planos sejam acionados no momento correto e avaliar
se a solução foi satisfatória;
– Comunicar os riscos: para que os riscos sejam analisados e gerenciados corretamente é
necessário que estes sejam comunicados no momento oportuno para as pessoas certas, sejam
estes engenheiros, gerentes, executivos, clientes ou fornecedores.
91
2.2.7.4 Modelo de Referência em Gestão de Riscos de Software do Boehm
O modelo de referência proposto por Boehm está organizado em seis passos:
(1) identificação de riscos – produz uma lista com os riscos que podem comprometer o
sucesso do projeto. Neste passo é recomendável a análise do histórico de riscos de projetos
anteriores da organização. Para aperfeiçoar este processo recomenda-se que a organização
mantenha uma lista atualizada dos dez riscos de maior probabilidade e impacto.
(2) análise de riscos – avalia a probabilidade e impacto da perda gerada para cada um
dos riscos identificados, além de avaliar os riscos relacionados e seu efeito cascata. A acurácia
das estimativas é fundamental para garantir uma adequada priorização dos riscos.
(3) priorização de riscos – produz uma lista classificada com os riscos identificados e
analisados. A fase de priorização dos riscos é essencial para a adequada gestão de riscos, pois um
dos maiores problemas que deve ser evitado pelos gestores de projetos é gerar uma lista de riscos
tão grande que se torne ineficiente. O nível de exposição (Probabilidade * Impacto) deve ser
calculado para cada um dos riscos e dessa maneira será possível decidir quais os principais riscos
que devem ser solucionados e monitorados.
(4) planejamento da gestão de riscos – ajuda o gerente de projetos na tratativa de cada
um dos riscos identificados, por exemplo, por meio da coleta de informações, prevenção de
riscos, transferência de riscos, ou redução de riscos. Considera a coordenação dos diversos planos
de ação individuais e sua integração com o plano geral do projeto. Em primeiro lugar é necessário
desenvolver um plano com todas as ações necessárias que permitam manter os riscos sobre
controle, ou seja, definir como será realizado o monitoramento dos riscos, qual sua periodicidade
e quais os responsáveis.
(5) resolução de riscos – executar os planos de ação definidos para eliminar ou
solucionar os riscos. Uma das melhores soluções para reduzir a incerteza sobre determinados
requisitos de software é construir um protótipo, pois dessa forma é possível coletar informações
sobre seu desempenho.
(6) monitoramento de riscos – controlar periodicamente a execução, evolução e
efetividade dos planos de ação, além de tomar medidas corretivas quando necessário. Uma das
melhores técnicas para esta função é criar uma lista de controle do progresso dos dez riscos mais
92
significantes do período. Este tipo de controle é eficaz e eficiente, pois permite que a equipe do
projeto concentre-se nas questões realmente importantes. A Tabela 14 apresenta um exemplo de
uma lista de monitoramento de riscos para um projeto de um software para satélite. Os riscos que
estão se movendo para o topo da lista devem receber atenção especial. Os riscos que estão se
movendo para fora da lista devem continuar sendo monitorados, mas não são os itens prioritários.
Tabela 14: Exemplo de monitoramento dos principais riscos de um projeto de software.
Risco
Classificação
Progresso da solução Atual Anterior
Nº
meses
Substituição do desenvolvedor do
sensor de controle. 1 4 2 Candidato selecionado indisponível.
Atraso na entrega planejada do
hardware. 2 5 2
Atraso no processo de formalização
do contrato.
Formato do sensor de dados
indefinido. 3 3 3
Atuação da equipe de sensores
replanejada para próximo mês.
Ausência da equipe de testes. 4 2 3 Testadores comprometidos.
Tolerância a falhas pode
comprometer o desempenho. 5 1 3 Protótipo concluído.
Mudanças solicitadas no banco de
dados. 6 – 1
Agendar reunião com Analista do
Banco de Dados.
Definições dos testes de interface
com sistema de energia. 7 8 3 Tarefa atrasada; reuniões replanejadas.
Indefinições na interface do
usuário. 8 6 3 Protótipo concluído.
Novos requisitos de operação. – 7 3 Solucionado.
Incerteza na reutilização do
componente de monitoração. – 9 3
Pequenos ajustes necessários já
concluídos.
Nota. Fonte: adaptado de Boehm, 1991.
2.2.8 Identificação dos Riscos
A total desinformação só existe até que as coisas aconteçam pela primeira vez. A partir
daí, deixa de ser desconhecida, porque passa a existir informação histórica. A identificação de
riscos é o início do processo de gestão de riscos e pode ser desenvolvido em três etapas: analogia
com projetos anteriores; categorização de riscos; e identificação de novos riscos (Salles et al.,
2010).
A analogia com projetos anteriores significa buscar informações históricas sobre
projetos de natureza semelhante que já foram realizados externamente ou internamente à
organização; entretanto, observa-se que não existem bancos de dados históricos que permitam a
93
analogia externa. Dessa forma, a correta identificação e documentação dos riscos é importante
não apenas para o projeto, mas também para criar uma base histórica interna que servirá como
fonte de consulta para novos projetos e gerará padrões para a organização (Salles et al., 2010).
Segundo Hillson (2013a), os riscos somente são gerenciáveis quando identificados e
documentados de forma clara e precisa; entretanto, a identificação de riscos produz apenas uma
grande lista de riscos que é difícil de entender ou gerenciar.
A categorização de riscos consiste em agrupar os riscos por afinidade ou tipo e pode ser
representada por meio de uma EAR. Por fim, depois de organizadas as informações sobre o
projeto, a identificação de novos riscos é realizada utilizando-se diversas ferramentas e técnicas
(Salles et al., 2010).
A identificação e pré-avaliação dos riscos são os processos mais importantes da gestão
de riscos, isto porque o seu resultado tem um forte impacto sobre a precisão das análises
posteriores dos riscos. O processo é iterativo e deve estar presente em todo o ciclo de vida do
projeto (Chapman, 1998). De acordo com Kerzner (2013), os métodos para se identificar os
riscos são numerosos, e é comum classificá-los conforme suas fontes de informação ou pesquisa,
podendo ser objetivos ou subjetivos. O que se espera deste processo é a obtenção de uma lista de
riscos, devidamente registrados e categorizados, para que os processos posteriores do
gerenciamento de riscos do projeto possam ser realizados de forma plena e completa.
Segundo a ISO (2009), o processo de identificação de riscos é extremamente crítico,
pois um risco que não é identificado nesta fase não será incluído em análises posteriores, ou seja,
um risco somente pode ser analisado, planejado, monitorado e solucionado quando devidamente
identificado. É essencial que o risco seja identificado antes que este se torne um problema
(Higuera & Haimes, 1996). Além de identificar o que pode acontecer, é importante considerar
possíveis causas e cenários que mostrem quais consequências podem ocorrer. Convém que a
organização aplique ferramentas e técnicas de identificação de riscos que sejam adequadas aos
seus objetivos, capacidades e riscos enfrentados, além de envolver pessoas com conhecimento
adequado sobre os riscos (ISO, 2009);
O principal benefício do processo de identificação de riscos é a documentação dos riscos
existentes e o conhecimento e a capacidade que ele fornece à equipe do projeto de antecipar os
eventos. Trata-se de um processo iterativo porque novos riscos podem surgir ou se tornar
94
evidentes durante o ciclo de vida do projeto. Os riscos devem ser especificados de forma
consistente para garantir que cada risco seja compreendido claramente e sem equívocos para
permitir a análise e o desenvolvimento de respostas eficazes, além de permitir a comparação entre
o efeito relativo dos riscos (PMI, 2009, 2013a; PMI & IEEE, 2013).
2.2.8.1 Listas de Verificação
As revisões históricas são boas fontes de referência para identificar fatores de riscos, a
partir daí, surgem as técnicas de identificação de riscos a partir de listas de verificação (Keeling,
2000). Diversos estudos realizados desde 1981 geraram listas com os principais riscos
identificados em projetos de software. Ao comparar algumas destas listas, observam-se sete
riscos similares: (1) falta de entendimento dos requisitos; (2) falta de comprometimento e suporte
dos gerentes; (3) ausência do adequado envolvimento do usuário; (4) falta de comprometimento
do usuário; (5) falha no gerenciamento das expectativas do usuário; (6) mudanças de requisitos; e
(7) falta de uma metodologia de gestão de projetos efetiva (Arnuphaptairong, 2011).
As listas de verificação para identificação de riscos de projetos de software são comuns
tanto na literatura quanto na prática, pois é uma técnica simples, rápida e de baixo custo para a
equipe do projeto. No entanto, como existem diversas listas disponíveis, é difícil escolher qual
lista é a mais adequada para determinado projeto. Adicionalmente, a percepção dos riscos em um
projeto de software varia muito conforme o grupo de pessoas envolvidas, a cultura da empresa e
os estágios do ciclo de vida do projeto (Bannerman, 2008).
Segundo o Google Acadêmico a lista do Boehm é a mais citada com 1.456 citações e os
dez principais riscos em projetos de software foram atualizados em 2010, são eles: (1) arquitetura
complexa; (2) falta de pessoal; (3) restrições de prazo e orçamento; (4) software pronto (COTS –
Commercial Off-The-Shelf); (5) coesão entre as equipes do cliente, desenvolvedor e usuário; (6)
volatilidade dos requisitos; (7) incompatibilidade com a interface do usuário; (8) processo de
garantia da qualidade; (9) incompatibilidade dos requisitos; e (10) incompatibilidade dos
processos de aquisição e contratação (Koolmanojwong & Boehm, 2013).
Estas listas podem servir como um direcionamento para entender o cenário geral dos
principais riscos em projetos de software, porém deve-se considerar os fatores de divergência
95
entre as listas: (1) dimensão do tempo – está relacionada com a distância no tempo em que as
pesquisas foram conduzidas. Com o passar dos anos muitos fatores relacionados a tecnologia e
educação mudaram e os processos de gestão de projetos e gestão de riscos evoluíram; (2) cultura
– está relacionada com o país onde as pesquisas foram realizadas. Como os respondentes
possuem culturas diferentes, talvez os riscos mais comuns em um país não se apliquem nos
outros países; (3) áreas de aplicação – somente dois estudos definiram sua área de aplicação, ou
seja, os riscos podem variar conforme a área de aplicação do software; e (4) Método de Pesquisa
– alguns estudos utilizaram o método Delphi e outros utilizaram questionários eletrônicos, ou
seja, os constructos utilizados nas pesquisas podem ter sidos diferentes (Arnuphaptairong, 2011).
Para as organizações que ainda não possuem uma gestão de riscos madura, é possível
utilizar como referência as listas disponíveis na literatura; entretanto, para evitar os fatores de
divergência, recomenda-se que as organizações ou setores específicos elaborem suas próprias
listas de riscos baseadas na experiência dos projetos anteriores (Arnuphaptairong, 2011).
O PMBOK (PMI, 2013a) também sugere o uso de listas de verificação como uma das
possíveis técnicas de identificação de riscos no projeto:
As listas de verificação de riscos são desenvolvidas com base nas informações históricas e no
conhecimento acumulado, a partir de projetos anteriores semelhantes e outras fontes de
informações. O nível mais baixo da EAR também pode ser usado como uma lista de verificação
de riscos. Embora uma lista de verificação possa ser rápida e simples, é impossível criar uma
lista completa, e deve ser tomado todo o cuidado para assegurar que a lista de verificação não
seja usada para evitar o esforço de identificação adequada dos riscos. A equipe também deve
explorar os itens que não aparecem na lista de verificação. Além disso, a lista de verificação
deve ser revisada de vez em quando para remover ou arquivar itens relacionados. 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.
Os principais pontos positivos desta técnica são: captura a experiência prévia; e
apresenta uma lista de riscos detalhada. Os principais pontos negativos são: a lista de verificação
pode ficar muito extensa; os riscos que não estão na lista serão esquecidos; e geralmente
considera somente as ameaças e esquece as oportunidades. Os fatores críticos de sucesso para sua
aplicação efetiva: manter a lista atualizada; e utilizar uma estrutura analítica de riscos como
referência (PMI, 2009).
A literatura existente sobre o assunto tem caráter conceitual, como convém a modelos de
gerenciamento, carecendo de detalhes e resultados de implementações específicas. As listas de
verificação são frequentemente citadas para verificação de riscos, mas a única ferramenta
96
existente para levantamento consistente de riscos na área de projetos de software é o TBRI
(Taxonomy-Based Risk Identification), desenvolvido pelo SEI em 1993. Mesmo nesse caso, o
TBRI é um roteiro de identificação sistemática de riscos associados ao desenvolvimento de
projetos de software. Roteiros da mesma natureza para riscos em outros tipos de projeto não
foram encontrados na literatura (Silva et al., 2006).
As listas de verificação são compiladas para capturar a experiência de projetos anteriores
e utilizá-la em projetos similares. É possível estruturar a lista de verificação de riscos utilizando a
estrutura analítica de riscos da organização, conforme exemplo parcial demonstrado na Tabela
15. É útil apresentar a lista de verificação como um conjunto de riscos para que a equipe decida
quais são relevantes para o projeto (PMI, 2009).
Tabela 15: Exemplo parcial de uma lista de verificação utilizando EAR como referência.
Categoria Subcategoria Exemplo de Risco Afeta o projeto?
(Sim, Não, NA)
1. Risco
Técnico
1.1. Definição
de escopo
Mudanças de escopo podem ocorrer durante o
projeto Não
Escopo redundante pode ser descoberto. Sim
Etc. NA (não se aplica)
1.2. Interfaces
Técnicas Etc. NA (não se aplica)
Nota. Fonte: PMI, 2009.
2.2.8.2 TBRI – Taxonomy-Based Risk Identification
O TBRI é um método de identificação de riscos baseado em uma lista de verificação e
elaborado pelo SEI para projetos de software. Auxilia na identificação dos riscos conhecidos e
desconhecidos e é baseado nas seguintes premissas: os riscos de software são geralmente
conhecidos pela equipe técnica, mas são mal comunicados; um método estruturado e repetitivo de
identificação de riscos é necessário para garantir a gestão de riscos eficiente; e uma identificação
de riscos eficaz deve cobrir todo o ciclo de vida do projeto (Carr, Konda, Monarch, Walker, &
Ulrich, 1993).
A aplicação de uma lista de verificação no formato de um questionário semiestruturado
(TBQ – Taxonomy-Based Questionnaire) orienta o gestor na coleta sistemática dos riscos junto à
equipe do projeto. Os dados coletados são organizados e formam uma estrutura analítica de riscos
padronizada e organizada em três classes principais: (1) engenharia de produto – são os aspectos
97
técnicos do projeto relacionados a hardware, software e toda a documentação necessária; (2)
ambiente de desenvolvimento – são os métodos, procedimentos e ferramentas utilizados para
desenvolver o software; e (3) restrições do programa – são os fatores contratuais, organizacionais
e operacionais externos ao projeto que estão fora da alçada do gestor, mas podem gerar impacto
no sucesso do projeto (Carr et al., 1993).
Figura 25: Estrutura da TBRI.
Fonte: elaborado pelo autor.
A TBRI é organizada em três níveis: Classe; Elemento e Atributo. A Figura 25 apresenta
os dois primeiros níveis e o ANEXO 1 – VISÃO GERAL DA TBRI (TAXONOMY-BASED RISK
IDENTIFICATION) – apresenta a estrutura completa.
98
2.2.8.3 GTAG12 – Global Technology Audit Guide 12: Auditing IT Projects
O IIA elaborou a série GTAG (Global Technology Audit Guide) que consiste em 17
diferentes guias contendo boas práticas para a equipe de auditoria sobre questões relacionadas à
gestão de tecnologia da informação, risco, controle e segurança (https://na.theiia.org/standards-
guidance/recommended-guidance/practice-guides/Pages/Practice-Guides.aspx, recuperado em 3
abril, 2014). Dentre os 17 guias, o GTAG12 é um guia específico para avaliar riscos em projetos
de TI, ou seja, trata-se de um interessante instrumento para identificar tanto os riscos no projeto
quanto os riscos do projeto de TI (Wegrzynowicz & Stein, 2009).
Figura 26: Cinco áreas chave para análise dos riscos.
Fonte: Wegrzynowicz & Stein, 2009.
O GTAG12 foi elaborado em 2009. Possui técnicas para identificar e avaliar os riscos
relacionados aos projetos de TI e pode ser utilizado por auditores, gestores de projetos e
escritórios de projeto. Conforme pode ser observado na Figura 26, o guia orienta a identificação
99
de riscos com foco em cinco áreas chave: (1) gestão de projetos para garantir aderência à
metodologia de gestão de projetos da organização e utilização de boas práticas de mercado; (2)
alinhamento estratégico para garantir que o projeto está alinhado com a visão e missão da
organização; (3) Metodologia de Desenvolvimento de Software para garantir, durante todo o
ciclo de vida do projeto, aderência à metodologia definida que pode ser da própria organização,
da consultoria contratada ou do vendedor do pacote de software; (4) mudança organizacional para
garantir baixo impacto nas mudanças dos processos organizacionais geradas pela implantação do
projeto e, também na forma como as pessoas trabalham no dia a dia; e (5) pós implantação para
garantir suporte, estabilidade e segurança do software em ambiente produtivo (Wegrzynowicz &
Stein, 2009).
Para auxiliar no processo de identificação de riscos, o guia disponibiliza uma lista de
verificação que pode ser utilizada na identificação e avaliação dos riscos e controles do projeto.
Esta lista está agrupada de acordo com as áreas chave proposta pelo guia, com exceção da área de
gestão de projetos que permeia todas as áreas. Uma versão reduzida da lista de verificação é
apresentada no ANEXO 2 – VERSÃO REDUZIDA DA LISTA GTAG12.
2.2.8.4 Registro de Riscos
Um registro de riscos é uma ferramenta valiosa para compreender e gerenciar os riscos
da organização, pois como não é possível gerenciar o que não se pode medir, o registro de riscos
fornece um quadro com métricas que auxiliam a tomada de decisões com base em informações.
Os principais benefícios de um registro de riscos são: a discussão em torno dos riscos relevantes
que abrangem toda a organização; o registo é escrito usando linguagem interna para garantir que
ele se relaciona com a organização em questão; e a consequência e probabilidade são mensuradas
projeto a projeto (Mutton, 2012).
O registro dos riscos é o documento em que os resultados da análise dos riscos e o
planejamento das respostas aos riscos são registrados (PMI, 2013a). Geralmente os softwares de
gestão de projetos possuem funcionalidades específicas para registro e monitoramento de riscos,
mas também é possível organizar um documento de registros de riscos contendo as seguintes
informações: número do risco, descrição do risco, categoria, causa, consequência, probabilidade,
100
impacto, ação (evitar, mitigar, transferir ou aceitar), descrição do plano de ação, custo do plano
de ação, evento que aciona o plano de ação e responsável (Mutton, 2012).
Por mais útil que seja o registro de riscos, este instrumento não garante o sucesso do
projeto se a ferramenta não for utilizada de forma adequada, e pode até mesmo prejudicar o
desempenho do projeto. Três boas práticas que devem ser consideradas: (1) começar cedo: a
capacidade de gerenciar e mitigar o risco do projeto é mais fácil no início de um projeto, pois
uma vez que o projeto já tenha se iniciado e decisões tomadas, fica mais difícil e mais caro fazer
mudanças; (2) durante a identificação dos riscos a contribuição de pessoas de diversas áreas
(jurídico, vendas, tecnologia, recursos humanos, finanças, etc.) é muito valiosa, pois agrega
diferentes perspectivas na avaliação dos riscos; e (3) visitar e reavaliar os riscos regularmente,
pois os riscos não são estáticos do início ao fim do projeto, os riscos são dinâmicos e podem
mudar de um dia para outro (Guyer, 2012).
2.3 GESTÃO ESTRATÉGICA DE TI
2.3.1 Conceitos e Histórico
O que é gestão estratégica de TI (Tecnologia da Informação)? Para responder a esta
questão é importante entender os termos TI e estratégia.
Laurindo, Shimizu, Carvalho e Rabechini introduzem o conceito de Tecnologia da
Informação da seguinte forma (2001, p. 160):
O conceito de Tecnologia da Informação é mais abrangente do que os de processamento de
dados, sistemas de informação, engenharia de software, informática ou o conjunto de hardware
e software, pois também envolve aspectos humanos, administrativos e organizacionais (KEEN,
1993)6.
Alguns autores, como ALTER (1992)7, fazem distinção entre Tecnologia da Informação e
Sistemas de Informação, restringindo a primeira expressão apenas aos aspectos técnicos,
enquanto que a segunda corresponderia as questões relativas ao fluxo de trabalho, pessoas e
6 KEEN, P.G.W.: “Information Technology And The Management Theory: The Fusion Map”. IBM Systems Journal,
v.32, n.1, p.17-38, 1993. 7 ALTER, S.: Information Systems: a management perspective. Addison-Wesley Publishing Co. Massachusetts,
1992.
101
informações envolvidas. Outros autores, no entanto, usam o termo tecnologia da informação
abrangendo ambos aspectos, como é a visão de HENDERSON & VENKATRAMAN (1993) 8.
Hitt, Ireland e Hoskisson (2014) explicam que estratégia é um conjunto integrado e
coordenado de compromissos e ações definidos para explorar competências essenciais e obter
vantagem competitiva (concorrentes não conseguem copiar ou acham custoso demais para
imitar). Quando definem uma estratégia, as empresas escolhem alternativas para competir. Nesse
sentido, a estratégia definida indica o que a empresa pretende e o que não pretende fazer.
Em grande parte da literatura os termos estratégia e gestão estratégica são utilizados sem
distinção. Entretanto, no meio profissional, a palavra estratégia é comumente associada somente
com a etapa de formulação da estratégia ou com o processo de tomada de decisão estratégica. Por
esse motivo, é mais frequente o uso do termo gestão estratégica que representa uma abordagem
mais ampla do que o termo estratégia (Pedroso, 2010).
A palavra estratégia foi inicialmente utilizada no âmbito militar, entendida como grande
tática, centrada na força. A partir do século XX, a estratégia passou a significar a seleção de
meios e objetivos, privilegiando fatores psicológicos em detrimento da força (Bethlem, 1981).
Chandler define estratégia como (1962, p. 13):
A determinação das metas e objetivos básicos e de longo prazo de uma empresa, e a adoção de
ações e alocação de recursos necessários para atingir esses objetivos (tradução livre).9
Segundo Mintzberg (1987) a estratégia é um conjunto de definições caracterizadas por
cinco Ps: (1) plano – um conjunto de diretrizes ou tipo de ação conscientemente pretendido; (2)
pretexto – uma tática, uma manobra para superar um concorrente; (3) padrão – sequência de
ações padronizadas que refletem um comportamento consistente, cujos resultados podem ser
pretendidos ou não; (4) posição – localiza a organização em seu ambiente; assim, a estratégia é
uma força mediadora ou uma combinação entre organização e ambiente, ou seja, entre o contexto
interno e externo; e (5) perspectiva – seu conteúdo reflete não somente uma posição escolhida,
mas também uma maneira de perceber o mundo, ou seja, a estratégia é para a organização assim
como a personalidade é para o indivíduo.
8 HENDERSON, J.C. & VENKATRAMAN, N.: “Strategic Alignment: Leveraging Information Technology For
Transforming Organizations”. IBM Systems Journal. v.32, n.1, p.4-16, 1993. 9 The determination of the basic long-term goals and objectives of an enterprise, ande the adoption of course of
action and the allocation of resources necessary for carrying out these goals.
102
De acordo com Porter (1997) a estratégia é baseada em uma posição competitiva única
da organização, cujo conjunto de atividades deve ser coerente e alinhado à estratégia; a estratégia
envolve a escolha clara de objetivos conflitantes; e a eficiência operacional é necessária, mas não
suficiente para competir no mercado (Porter, 1997).
No ambiente da tecnologia da informação, onde as mudanças são constantes, as
vantagens competitivas tornam-se temporárias e não mais sustentáveis por um longo período de
tempo, obrigando as organizações a desenvolverem estratégias sustentadas por projetos cada vez
mais rápidos, baratos e melhores. Isso significa que é necessário reduzir o ciclo de vida do
projeto, diminuir seus custos e entregar um produto/serviço com um nível de qualidade percebido
pelo cliente cada vez maior (Hitt et al., 2014).
2.3.2 Alinhamento Estratégico de TI e Negócios
A tecnologia da informação transcendeu seu tradicional papel operacional e evoluiu para
um papel estratégico com potencial de não apenas suportar as estratégias de negócios, mas
também participar ativamente do planejamento estratégico da organização (Henderson &
Venkatraman, 1993).
Henderson e Venkatraman (1993) propuseram um Modelo de Alinhamento Estratégico
que apresenta a importância estratégica da TI dentro das organizações. O modelo é baseado em
quatro pilares: estratégia de negócios, estratégia de TI, infraestrutura e processos organizacionais
e infraestrutura e processos de TI.
Os autores explicam que a estratégia da organização pode definir a estratégia de TI, mas
o inverso também é possível, ou seja, a estratégia de TI pode influenciar a estratégia da
organização. Com base no modelo, são propostas quatro principais perspectivas de alinhamento
estratégico:
− Execução da estratégia: nesta perspectiva a estratégia de negócios atua como
impulsionadora da infraestrutura organizacional e de TI. Esta é a perspectiva mais comumente
utilizada e entendida, pois corresponde à clássica visão de gerenciamento estratégico. O critério
de desempenho para a definição do uso da TI são fatores financeiros;
103
− Transformação tecnológica: nesta perspectiva a implantação da estratégia de negócios
ocorre pela estratégia adequada de TI articulada com os necessários processos e infraestrutura de
TI. Neste caso a infraestrutura de TI não é restringida pela infraestrutura da organização dos
negócios. O critério de desempenho tem como base a liderança tecnológica para o
posicionamento da empresa no mercado de TI;
− Potencial competitivo: nesta perspectiva a administração explora como uma nova
competência na área de TI pode permitir novas estratégias de negócios com consequentes
implicações na infraestrutura organizacional. A escolha da estratégia de negócios decorre de uma
nova estratégia de TI adotada. O critério de desempenho é a liderança nos negócios.
− Nível de serviço: esta perspectiva foca em como construir uma organização de
serviços de TI de “classe mundial”. Isto requer um entendimento das dimensões externas de
estratégia de TI com adequação dos processos e infraestrutura internos. Este ajuste de estratégia
de TI cria as competências necessárias para atender as necessidades dos clientes. O critério de
desempenho é a satisfação do cliente.
Apesar da importância de garantir o alinhamento estratégico entre TI e negócios, a
dificuldade encontrada pelos executivos para o seu gerenciamento e uso na estratégia empresarial
é adotada como uma questão bastante crítica. A falta de habilidade das empresas em
compreenderem como a TI pode contribuir para os negócios deve-se, em parte, à ausência de
coordenação e alinhamento com as estratégias de negócios (Henderson & Venkatraman, 1993).
Conforme pode ser observado na Tabela 16, Luftman, Papp and Brier (1999)
identificaram os principais inibidores e facilitadores do alinhamento estratégico de TI e negócios.
Muitos destes inibidores são enfrentados pelos executivos em suas respectivas organizações,
interferindo de forma decisiva nos benefícios obtidos a partir da implantação de projetos de TI,
bem como no tempo de retorno desses investimentos.
O alinhamento estratégico de TI corresponde à aplicação da TI de uma forma apropriada
e em harmonia com as estratégias, objetivos e necessidades organizacionais. Um alinhamento
maduro envolve um relacionamento onde a TI e as outras áreas de negócios adaptam suas
estratégias conjuntamente. Termos como harmonia, junção, fusão, ajuste e integração são
frequentemente usados como sinônimos desse alinhamento (Luftman, 2000).
104
Tabela 16: Principais facilitadores e inibidores do alinhamento estratégico.
Facilitadores Inibidores
1. Apoio da alta gerência à área de TI. 1. Falta de relacionamento próximo entre a área de TI e
as demais.
2. Envolvimento da área de TI no desenvolvimento da
estratégia corporativa.
2. A área de TI não prioriza bem seus projetos.
3. A área de TI conhece os negócios da empresa. 3. A área de TI falha no cumprimento de seus
compromissos.
4. Parceria entre a área de TI e as demais. 4. A área de TI não entende dos negócios da empresa.
5. Projetos de TI são bem priorizados. 5. A alta gerência não apoia a área de TI.
6. A área de TI demonstra liderança. 6. Falta de liderança à área de TI.
Nota. Fonte: Luftman et al., 1999.
Luftman (2003) propõe a busca da maturidade do alinhamento de forma gradual. Seu
modelo de alinhamento estratégico baseia-se nos conceitos do CMM (Capabilyty Maturity
Model), porém com foco em práticas de negócios mais estratégicas. O modelo foi testado em
mais de 50 empresas internacionais e tornou-se uma ferramenta de benchmarking. Seu objetivo
principal é identificar recomendações específicas para melhorar o alinhamento de TI com o
negócio por meio de uma ferramenta que avalia seis critérios de maturidade, conforme Tabela 17.
Tabela 17: Critérios para avaliação da maturidade do alinhamento entre TI e negócios.
Critério de avaliação Descrição
1. Maturidade das comunicações Consiste no claro entendimento das questões referentes ao que importa para a
estratégia de sucesso nos negócios.
2. Maturidade na mensuração de
valor/competências
Corresponde ao estabelecimento de métricas comuns e claras do valor e
desempenho da TI e dos negócios.
3. Maturidade de governança Avalia se a responsabilidade pelos recursos, riscos, resolução de conflitos e
responsabilidade por TI são compartilhados entre parceiros de negócios, gestão
de TI e provedores de serviços, além de discussões sobre seleção, priorização e
balanceamento de projetos no portfólio.
4. Maturidade de parcerias Avalia o relacionamento existente entre TI e as áreas de negócios e como cada
organização percebe a contribuição de cada uma das partes.
5. Maturidade da tecnologia Avalia se TI é capaz de ir além do seu papel operacional e assume um papel de
suporte para todos os parceiros e clientes. Considera-se se TI aplica tecnologias
emergentes de forma eficiente, se direciona processos de negócios e estratégias
como um padrão e se prove soluções para as necessidades dos clientes.
6. Maturidade de habilidades Envolve todas as considerações acerca das pessoas para a organização e verifica
se TI vai além das considerações tradicionais de salário, treinamento e
desempenho, incluindo o ambiente social e cultural.
Nota. Fonte: adaptado de Luftman, 2003.
Laurindo et al (2001) comentam que embora exista um grande número de artigos
voltados à análise da relação entre TI e estratégia dos negócios, este é um tema que está em
constante evolução devido ao dinamismo do setor de tecnologia e das novas estratégias de
mercado. Alguns pontos que permeiam as diversas abordagens existentes na literatura:
105
– Necessidade de uma visão estratégica clara para o negócio e para a TI e visão da TI
como vantagem competitiva para o negócio e voltada para o mercado e para o usuário TI.
– Vantagem competitiva vinda da gestão da TI e de seu alinhamento estratégico com o
negócio e não de aplicações específicas de TI.
– Importância de serem considerados tanto os aspectos técnicos (incluindo
acompanhamento da evolução das disponibilidades do mercado de TI) como os organizacionais.
– Busca de eficácia e não somente da eficiência.
– Necessidade de relacionamento intenso e próximo entre executivos de TI e do negócio.
– Critérios variados de avaliação conforme a aplicação (aspectos técnicos,
organizacionais e estratégicos).
– Gestão dinâmica e flexível da TI. A gestão do planejamento estratégico da TI deve ser
um processo contínuo.
Garantir o alinhamento das estratégias de TI aos objetivos e estratégias da organização é
um dos principais objetivos da governança corporativa. O alinhamento estratégico é apresentado
como um dos principais meios de garantir que os investimentos realizados em tecnologia
agreguem valor à organização (Grembergen, 2004).
Por um lado a gestão de TI concentra-se no fornecimento efetivo interno dos serviços e
produtos de TI, e no gerenciamento das suas operações atuais, por outro lado, a governança de TI
é mais ampla e concentra-se na execução e na transformação da TI para atender as demandas
presentes e futuras dos negócios (foco interno) e dos clientes desses negócios (foco externo). Tal
fato não diminui a importância e a complexidade da gestão de TI, mas indica que a governança
de TI é orientada interna e externamente e considera tanto o tempo presente quanto o tempo
futuro. Outra diferença fundamental está relacionada com o uso da informação, pois enquanto a
gestão de TI está focada nas tecnologias que manipulam a informação, a governança de TI está
focada na aplicação dessas informações nos negócios (Peterson, 2004).
106
2.3.3 Governança de TI
A governança corporativa teve origem na década de 1930, com o desenvolvimento dos
mercados de capitais, responsáveis por boa parte do financiamento e consequente crescimento
das empresas. Ainda que o termo não existisse até o final dos anos 1970, suas características
principais foram apresentadas em 1932 por Berle e Means, ao apresentarem o problema da Teoria
da Agência, que trata dos inevitáveis conflitos de interesses entre acionistas, gestores, credores e
funcionários de uma empresa (Silveira, 2002).
O Instituto Brasileiro de Governança Corporativa descreve o conceito de governança da
seguinte forma (2009, p. 19):
É o sistema pelo qual as organizações são dirigidas, monitoradas e incentivadas, envolvendo os
relacionamentos entre proprietários, Conselho de Administração, Diretoria e órgãos de controle.
As boas práticas de Governança Corporativa convertem princípios em recomendações
objetivas, alinhando interesses com a finalidade de preservar e otimizar o valor da organização,
facilitando seu acesso a recursos e contribuindo para sua longevidade.
Segundo Hitt, Ireland and Hoskisson (2014), a governança corporativa é uma relação
entre as partes interessadas, utilizada para definir a direção de uma empresa e controlar o seu
desempenho. A forma como as empresas monitoram e controlam as decisões e ações de seus
gerentes de alto nível afeta a implantação das estratégias. Uma governança eficaz, que alinhe as
decisões da alta gerência aos interesses dos acionistas, pode ajudar a produzir uma vantagem
competitiva. Há três estratégias internas de governança na empresa moderna:
– concentração da propriedade: os proprietários e investidores contratam executivos de
alto nível para tomar decisões que maximizem o valor da empresa. Com percentuais
significativos de participação acionária, os investidores influenciam e monitoram as atitudes e
decisões estratégicas dos altos executivos.
– conselho de administração: composto por membros internos e externos, é um controle
de governança do qual se espera representação dos interesses coletivos dos acionistas. Com a
criação da lei Sarbanes-Oxley, se espera que o número de membros externos seja superior ao
número de membros internos, pois os membros externos são mais independentes da alta gerência
de uma empresa.
107
– remuneração de executivos: é um mecanismo de governança altamente visível e
frequentemente criticado. Salários, bônus e incentivos de longo prazo são usados para fortalecer o
alinhamento entre os interesses dos executivos e acionistas. O conselho de administração é
responsável por definir a eficácia do sistema de remuneração dos executivos.
Como forma de coibir e dificultar a manipulação de informações financeiras por parte
das organizações, diferentes medidas têm sido adotadas no mundo todo, especialmente para
garantir maior credibilidade aos investidores. A preocupação por parte de vários órgãos
reguladores com a governança corporativa tem levado à introdução de leis, acordos (como os
acordos de Basiléia II e Basiléia III, específicos para o setor bancário) e regulamentações que
venham garantir maior transparência e responsabilidade das organizações quanto às informações
divulgadas, cabendo a aplicação de penas e multas pesadas àqueles que não as cumprirem
(Lunardi, 2008).
Lunardi (2008) ainda esclarece que a TI aparece como o principal meio de garantir que
as informações (tanto financeiras quanto operacionais) sejam precisas, confiáveis e atualizadas,
além de estarem prontamente disponíveis quando solicitadas. Assim, percebe-se como as
decisões inerentes à TI precisam ser bem definidas, gerenciadas e supervisionadas pela alta
administração da empresa e não apenas pela área tecnológica, sendo a governança um importante
instrumento de gerenciamento. A Tabela 18 apresenta algumas definições de Governança de TI.
Tabela 18: Definições de governança de TI.
Definição Autor(es)
Os mecanismos de governança de TI referem-se aos padrões de autoridade necessários para as
atividades chave de TI em empresas de negócios, incluindo infraestrutura de TI, uso da TI e
gestão de projetos.
(Sambamurthy
& Zmud, 1999,
p. 261)
A governança de TI é composta pela liderança, estrutura organizacional e processos necessários
para garantir que a as atividades de TI sustentem e expandam os objetivos estratégicos da
organização.
(Grembergen,
2004, p. 1)
Governança de TI é a estrutura de relacionamento e processos para dirigir e controlar a empresa
de modo a atingir os objetivos corporativos, adicionando valor por meio do balanceamento do
risco versus retorno obtido pela TI e seus processos.
(ISACA, 2002,
p. 5)
Governança de TI é de responsabilidade do Conselho de Administração e da alta administração.
É uma parte integral da governança corporativa e é composta pela liderança, estrutura
organizacional e processos necessários para garantir que a as atividades de TI sustentem e
expandam os objetivos estratégicos da organização.
(ITGI, 2003, p.
10)
Governança de TI especifica a estrutura de responsabilidades e direitos necessários para a tomada
de decisões em TI.
(Weill, 2004)
Governança de TI descreve a distribuição das responsabilidades e direitos entre as pessoas da
organização quanto às decisões de TI, e define os mecanismos e procedimentos necessários para
monitorar as decisões estratégicas relacionadas à TI.
(Peterson, 2004,
p. 7)
Nota. Fonte: elaborado pelo autor.
108
A governança de TI é de fundamental importância para a organização, mas a questão
sobre como implantá-la na prática é um desafio tanto para os profissionais quanto para os
executivos. A simples elaboração de um modelo não significa necessariamente que a governança
de TI esteja realmente funcionando na organização é necessário adotar alguns mecanismos que
garantam a adequada governança (Grembergen, 2004). A seguir apresentam-se alguns dos
mecanismos de governança de TI adotados pelas organizações:
2.3.3.1 Gestão de Projetos
Quando a organização desenvolve projetos de forma esporádica, não há a necessidade de
desenvolver de forma sistemática habilidades para as iniciativas de projetos. Entretanto, se uma
organização dedica grande parte de sua energia à implantação de projetos, uma abordagem não
estruturada e disciplinada do seu gerenciamento conduz a ineficiências que podem ser danosas à
organização. O papel do escritório de projetos é desenvolver e fazer cumprir padrões e
procedimentos para projetos e programas dedicados à TI. Como busca monitorar o uso e a
aderência dos padrões da tecnologia, também tem a tarefa de coletar e relatar o progresso e o
desempenho dos projetos em andamento (Rau, 2004).
Weill (2002)10
apud Van Grembergen (2004, p. 18) identificou um conjunto de práticas
de gerenciamento capaz de auxiliar os executivos na busca por maior obtenção de valor por meio
da TI. São elas:
– Gestão de projetos: por meio da presença de um escritório de projetos, métodos de
padronização, engajamento de gerentes de negócios, definição de um patrocinador de negócios,
reuniões frequentes entre stakeholders e definição dos responsáveis pelos resultados obtidos.
– Clarificações de valor: por meio da revisão pós-implementação, acordos de nível de
serviço, justificativa de projetos e avaliação de desempenho que considere os custos, benefícios e
progressos em direção ao valor obtido esperado;
– Governança de TI: por meio do comitê diretivo de TI, comitê de estratégia de TI e da
definição de prioridades;
10
Weill, P. (2002). Research Briefing. MIT Sloan, 2(2) 1-10.
109
– Padronização da tecnologia: por meio de serviços compartilhados, aplicações
empresariais, arquitetura de TI, centralização da área de TI, conselhos de TI para estabelecer e
monitorar padrões e arquiteturas.
A adequada gestão dos projetos é um fator fundamental para garantir o sucesso dos
projetos de TI, mas para que esta relação se sustente, é necessário que os gestores de projetos
estejam preparados para assumir esta função. As habilidades necessárias para este tipo de
profissional assumiram novas dimensões e isto é uma grande mudança para a maioria dos
profissionais de TI, pois as habilidades técnicas sempre foram suas características dominantes.
Para suprir esta demanda as organizações e os profissionais de TI precisam incluir em sua grade
de treinamentos cursos de comunicação, marketing, negociação e gestão de pessoas (Luftman &
Brier, 1999).
2.3.3.2 Gestão de Riscos
A maior dependência da TI por parte das organizações tem feito com que os riscos
referentes à tecnologia e a sua utilização venham se tornando cada vez mais visíveis e
significantes. Brechas ou falhas na internet ou nos sistemas computacionais utilizados pelas
organizações podem causar sérias crises nos negócios, incluindo danos de reputação e imagem,
perda de negócios e até mesmo danos de responsabilidade legal (Hughes, 2006).
Cada vez mais, percebe-se que os riscos relacionados à TI e aos seus projetos estão
ficando maiores, especialmente porque estes são difíceis de serem identificados e,
constantemente, modificam-se ao longo do tempo. Diferentemente dos demais campos da
administração, a gestão do risco da TI constitui-se num novo tema de interesse, onde nem sempre
a tradicional gestão do risco se aplica (Hughes, 2006).
O rápido desenvolvimento das tecnologias, juntamente com o aumento da variedade e
complexidade é um desafio à gestão de projetos de TI. Isso tem aumentado o risco dos projetos
obterem menos benefícios do que o estimado, ou ainda ultrapassarem o orçamento e os prazos
previstos, fazendo com que os custos de adoção da TI aumentem drasticamente. Fica claro
entender por que os executivos querem uma resposta para a seguinte questão envolvendo os
riscos da TI: “como diminuir drasticamente o risco e melhorar o retorno sobre os investimentos
110
realizados em sistemas de informação?”. A resposta para essa questão está na necessidade de
realizar a gestão de riscos da TI como parte dos riscos da organização (Hughes, 2006).
Com a utilização dos computadores em diversas organizações, as informações
começaram a se concentrar em um único lugar e o grande volume dessas informações passou a
ser um problema para a segurança. Os riscos aumentaram com o uso dos microcomputadores, a
utilização de redes locais e remotas, a abertura comercial da Internet e a disseminação da
informática para diversos setores da sociedade. Boa parte dos dados que são importantes ao
negócio da empresa está armazenada em computadores, o que torna as organizações dependentes
da confiabilidade de seus sistemas baseados em TI; se a confiança nesses dados for destruída, o
impacto pode ser comparável à própria destruição da organização (Silva & Silveira, 2007).
Enquanto que a entrega de valor por meio da TI está focada na criação de valor ao
negócio, a gestão de risco está focada na preservação do valor do negócio (Grembergen, 2004).
2.3.4 O Setor Bancário Brasileiro
O modelo bancário trazido ao Brasil pelo Império foi o europeu. Entendiam-se como
atividades básicas de um banco as operações de depósitos e empréstimos, sendo que outros
serviços praticamente inexistiam. Os bancos sempre guardaram uma característica
excessivamente nobre. Um exemplo desse rigor eram as próprias gerências operacionais, as quais
obrigatoriamente deveriam manter contato com o público e ficavam situadas no fundo das
agências, com suas portas muito bem trancadas, por onde poucos ousariam entrar. Essa situação
estendeu-se até a metade do século XX, quando então, começaram as grandes transformações
provocadas pelo progresso e pela euforia do pós-guerra (Fortuna, 2013).
A partir dos anos 1950, propagaram-se os bancos e, com eles, os primeiros sintomas de
uma fraca capacidade empresarial para administrá-los. Mais de 500 matrizes bancárias
funcionavam na ocasião. Em 1945, por meio do Decreto-Lei 7.293, foi criada a Sumoc
(Superintendência da Moeda e do Crédito) que tinha como objetivo exercer o controle do
mercado monetário. Este decreto também criou o depósito compulsório que é um instrumento de
controle do volume de crédito e dos meios de pagamento que existe até os dias atuais. Nessa
111
época inúmeros bancos encerraram suas atividades ou desapareceram em fusões e incorporações,
saneando e solidificando o Sistema Financeiro Nacional (Fortuna, 2013).
A estrutura atual básica do sistema financeiro é derivada da reforma institucional de
1964 e 1965, que criou o Conselho Monetário Nacional e o Banco Central do Brasil, além da
regulamentação das diferentes instituições de intermediação, entre as quais o SFH (Sistema
Financeiro da Habitação). Posteriormente, em 1976, foi incorporada ao quadro institucional do
sistema a CVM (Comissão de Valores Mobiliários) (Fortuna, 2013).
Ainda hoje a principal função de um banco é intermediar transações financeiras, ou seja,
captar recursos de pessoas e empresas com sobras de caixa (superavitárias), remunerando-as por
isso, e emprestando e cobrando juros a pessoas e organizações com falta de caixa (deficitárias). A
diferença entre os juros cobrados dos agentes deficitários e os juros pagos aos agentes
superavitários é o chamado spread bancário. Este montante não representa apenas o lucro dos
bancos, mas envolvem também os impostos, inadimplência dos tomadores de crédito, despesas
administrativas, etc. O lucro dos bancos é o resultado de todos os processos e decisões de
negócios, mas não é a única forma de medir seu desempenho. Para manterem-se competitivas,
estas instituições financeiras também vivem os desafios das grandes corporações modernas:
relações complexas com todos os seus stakeholders, necessidade de capacidade financeira para
ampliar mercados e ações que aumentem a satisfação e a segurança de seus clientes (Moraes,
2012).
Além disso, a estrutura de governança deve ser robusta para garantir a aderência a
normas e evitar transações fraudulentas ou de alto risco que possam comprometer seus ativos e a
poupança de seus correntistas. Diversas crises mundiais que ocorreram nas décadas de 1980 e
1990 aliadas a uma cultura inflacionária no Brasil, fizeram com que os bancos que operam no
País tivessem que se adaptar a uma situação constante de instabilidade. Essa situação começou a
se alterar com a estabilização monetária trazida pelo Plano Real, que encerrou um longo período
de inflação elevada e permitiu que a economia brasileira se organizasse e voltasse a crescer. A
constante instabilidade e os sucessivos planos econômicos dos Governos exigiram que o sistema
de regulação dos bancos adotados pelo Banco Central do Brasil torna-se rígido e reconhecido
internacionalmente, fato este que contribuiu para que a crise internacional de 2008 não causasse
os graves efeitos encontrados em outras economias mundiais (Moraes, 2012).
112
Ao longo dos últimos anos, o cenário econômico tem favorecido a expansão do sistema
financeiro brasileiro e ampliado os índices de bancarização da população economicamente ativa.
A estabilidade macroeconômica e monetária, aliada ao crescimento da renda e ascensão social,
acelerou a procura por crédito, investimentos e meios de pagamento. Como consequência desse
cenário, é possível perceber que o setor financeiro continua se desenvolvendo. Desde 2009 o total
de ativos da indústria bancária vem crescendo a taxas de dois dígitos, somente de 2012 para 2013
o total de ativos da indústria bancária aumentou em 12%, passando de R$ 5,6 trilhões para R$ 6,3
trilhões, ou seja, este é um dos indicadores da evolução constante e uniforme dos bancos
(FEBRABAN, 2014).
A taxa de bancarização de 56%, conforme apresentado na Figura 27 equipara o Brasil a
outras nações emergentes – Turquia e Índia, por exemplo. No entanto, ainda fica abaixo dos
níveis registrados pelas economias desenvolvidas como EUA, Alemanha e Reino Unido, que
apresentam taxas de bancarização em torno de 97%. Isso representa um grande potencial de
expansão para os bancos de varejo, o que permite afirmar que a manutenção das taxas de
crescimento é sustentável para os próximos anos, caso o setor desenvolva mecanismos e produtos
voltados para a população que ainda não ingressou no mercado bancário (FEBRABAN, 2014).
Figura 27: Bancarização dos países.
Fonte: FEBRABAN, 2014.
O crescimento consistente da oferta de serviços financeiros para a população de forma
geral só pode ocorrer, no entanto, se houver um aumento da capilaridade dos pontos de
atendimento. Assim, reconhecendo essa necessidade, os bancos continuaram a investir no
aumento da presença dos pontos físicos, ampliando o número de agências e Postos de
Atendimento Bancário (PABs – dependências instaladas no interior de entidades de
administração pública ou empresas privadas) e por Postos de Atendimento Eletrônicos (PAEs –
113
áreas exclusivas de equipamentos de autoatendimento). Somados, os dois últimos canais tiveram
uma expansão de 3% no período de 2009 a 2013 (FEBRABAN, 2014).
Conforme pode ser observado na Figura 28, ao comparar o Brasil com benchmarks
internacionais e desconsiderando as fortes diferenças geográficas, demográficas, econômicas e
socioculturais, é possível observar que o Brasil, com 30 agências bancárias por 100.000 adultos
bancarizados, possui um índice de agências por adultos bancarizados acima de mercados
emergentes, como México e a Índia. O número nacional se aproxima mais de países
desenvolvidos, como, por exemplo, os EUA, que possuem agências mais compactas e com perfil
de atendimento diferenciado pelo maior índice de agências/adulto. Com relação ao número de
caixa eletrônico por população adulta, o Brasil ultrapassou países como Estados Unidos,
Alemanha e Reino Unido, contando com 220 caixas eletrônicos para cada 100 mil adultos
bancarizados (FEBRABAN, 2014).
Figura 28: Número de agências por 100 mil adultos bancarizados
Fonte: FEBRABAN, 2014.
Os diversos indicadores mostram que o sistema financeiro brasileiro é sólido e vive um
momento de expansão, tanto na oferta quanto na demanda. Ao mesmo tempo em que mais
brasileiros estão em busca de crédito, investimentos e meios de pagamento, o setor bancário tem
sido bem-sucedido em ampliar sua oferta de produtos e serviços juntamente com a abrangência
de sua atuação, aumentando assim pontos de atendimento, autoatendimento e qualidade dos
meios virtuais como internet e mobile banking (FEBRABAN, 2014).
114
2.4 SÍNTESE DO REFERENCIAL TEÓRICO
Foram elaboradas três tabelas para sintetizar o referencial teórico estudado:
– Tabela 19: Síntese do referencial teórico sobre o tema GESTÃO ESTRATÉGICA DE TI.
– Tabela 20: Síntese do referencial teórico sobre o tema GESTÃO DE PROJETOS DE TI.
– Tabela 21: Síntese do referencial teórico sobre o tema GESTÃO DE RISCOS DE TI.
Cada uma das tabelas apresenta os principais aspectos relevantes do tema (eixo teórico) organizados por subtema e autor(es).
A partir da síntese do referencial teórico são construídas e sustentadas as premissas e proposições deste estudo.
Tabela 19: Síntese do referencial teórico sobre o tema GESTÃO ESTRATÉGICA DE TI.
Subtema Autor(es) Aspectos relevantes
Conceito (Hitt et al., 2014) Estratégia é um conjunto integrado e coordenado de compromissos e ações definidos para explorar competências
essenciais e obter vantagem competitiva.
Categorização (Crawford et al., 2006) As organizações que realizam muitos projetos precisam categorizar seus projetos para compará-los entre si e
garantir o alinhamento estratégico.
Gestão de
Projetos
(Hitt et al., 2014) No ambiente de TI as mudanças são constantes e as vantagens competitivas temporárias, obrigando as
organizações a desenvolverem estratégias sustentadas por projetos cada vez mais rápidos, baratos e melhores.
(Luftman et al., 1999) Um dos principais facilitadores do alinhamento estratégico de TI e negócios é a adequada priorização dos
projetos.
(Turner, 2009) As empresas precisam adaptar-se as mudanças do ambiente e constantemente melhorar seus processos. Os clientes
esperam que os produtos sejam sob medida e todo produto seja um mini projeto.
(Weill, 2002) A gestão de projetos utilizando métodos padronizados é uma das práticas que auxiliam os executivos na obtenção
de valor por meio da TI.
115
Subtema Autor(es) Aspectos relevantes
Gestão de
Riscos
(Alberts & Dorofee, 2012) Falhas evitáveis em projetos de software continuam a ocorrer, pois diversos riscos significativos não são levados
ao conhecimento dos tomadores de decisão.
(Hughes, 2006) Para diminuir drasticamente os riscos da TI e melhorar o retorno sobre os investimentos realizados em projetos de
software é necessário realizar a gestão de riscos da TI como parte dos riscos da organização.
(Luftman, 2003) Alinhamento estratégico maduro entre TI e negócios significa que a governança é realizada de forma adequada e a
responsabilidade pelos riscos e recursos é compartilhada com os parceiros de negócios.
(Maguire, 2002) Diversos riscos são assumidos ao implantar ou alterar um software em uma área chave da organização, pois uma
falha gera impacto direto no resultado do negócio.
(PMI, 2009) O risco somente existe quando impacta positiva ou negativamente o objetivo do projeto, ou seja, para que a gestão
de riscos seja aplicada com sucesso é fundamental definir claramente quais são os objetivos do projeto e sua
importância para a organização.
A gestão de riscos deve estar alinhada com os valores organizacionais, pois muitas vezes os riscos exigem
aprovação ou respostas de pessoas que estão em níveis hierárquicos superiores ao do gerente de projeto.
(Shenhar et al., 2007) Os riscos que aparentemente afetam apenas o projeto podem se propagar por toda a empresa.
Gestão de TI (Henderson &
Venkatraman, 1993)
A TI transcendeu seu papel operacional e evoluiu para um papel estratégico com potencial de não apenas suportar
as estratégias de negócios, mas também participar ativamente da estratégia da organização.
(Laurindo et al., 2001) Para garantir o alinhamento estratégico entre TI e negócios é necessária a busca de eficácia e não somente da
eficiência.
(Peterson, 2004) A gestão de TI está focada nas tecnologias que manipulam a informação e a governança de TI está focada na
aplicação dessas informações nos negócios.
Governança
(Lunardi, 2008) A TI é o principal meio de garantir que as informações sejam precisas, confiáveis e atualizadas. As decisões
inerentes à TI precisam ser gerenciadas pela alta administração e a governança é um importante instrumento de
gestão.
(Grembergen, 2004)
O alinhamento estratégico é apresentado como um dos principais meios de garantir que os investimentos
realizados em tecnologia agreguem valor à organização.
A governança de TI é composta pela liderança, estrutura organizacional e processos necessários para garantir que
as atividades de TI sustentem e expandam os objetivos estratégicos da organização.
Modelos (Killen & Hunt, 2009,
2013)
O principal objetivo de um modelo de maturidade é identificar os pontos positivos e negativos da organização
comparada às boas práticas de mercado. Os modelos de maturidade são aplicados desde a gestão de riscos e
gestão de conhecimento até a completa gestão de projetos e gestão de portfólio.
(OGC, 2009) O tema Business Case do PRINCE2 garante que o projeto seja viável, esteja alinhado com os objetivos da
organização e garante o monitoramento e captura dos benefícios.
O tema Progresso do PRINCE2 trata da governança do projeto para garantir a aprovação dos planos, o
monitoramento do desempenho e a comunicação adequada dos problemas aos níveis hierárquicos superiores.
(PMI, 2013b) O modelo OPM3 propõe uma gestão sistemática dos projetos em alinhamento com os objetivos estratégicos das
organizações.
Nota. Fonte: elaborado pelo autor.
116
Tabela 20: Síntese do referencial teórico sobre o tema GESTÃO DE PROJETOS DE TI.
Subtema Autor(es) Aspectos relevantes
Conceito (PMI, 2013a) Um projeto pode ser definido como um esforço temporário empreendido para criar um produto, serviço ou
resultado exclusivo.
A gestão de projetos pode ser definida como a aplicação do conhecimento, habilidades, ferramentas e técnicas às
atividades do projeto para atender aos seus requisitos.
Categorização (Castro & Carvalho, 2010) 74% das organizações pesquisadas, principalmente as do setor financeiro, adotam a categorização de projetos por
finalidade, com destaque para os projetos de desenvolvimento de tecnologia e de sistemas de informação.
(Padovani, 2007) Uma forma bastante simples de classificar os projetos é organizá-los conforme sua finalidade, por exemplo:
manutenção, infraestrutura de P&D, informática ou engenharia.
(Shenhar & Dvir, 2007) Os projetos devem ser classificados de acordo com quatro dimensões: novidade, tecnologia, complexidade e
passo.
Gestão de
Riscos
(Alberts & Dorofee, 2012) Muitos projetos ainda falham devido à falta de maturidade das organizações em gestão de riscos.
(Carvalho & Rabechini,
2011)
A partir da virada do milênio observa-se que é necessário aprimorar a gestão de riscos em projetos.
(Higuera & Haimes, 1996) A gestão de risco em projetos de software tem como objetivos: prevenir riscos; mitigar e corrigir riscos; e garantir
a falha segura do sistema.
(Hughes, 2006) O rápido desenvolvimento das tecnologias, juntamente com o aumento da variedade e complexidade é um desafio
à gestão de projetos de TI. Isso tem aumentado o risco dos projetos obterem menos benefícios do que o estimado
ou ultrapassarem o orçamento e os prazos previstos.
Cada vez mais, percebe-se que os riscos relacionados à TI e aos seus projetos estão ficando maiores,
especialmente porque estes são difíceis de serem identificados e, constantemente, modificam-se ao longo do
tempo.
(Lockyer & Gordon,
2005)
A maioria das atividades industriais lida com contextos conhecidos e relativamente estáveis, mas os projetos
lidam com mudanças e incertezas consideráveis.
(PMI & IEEE, 2013) Cada projeto de software tem diferentes incertezas, riscos e oportunidades, pois são uma combinação única de
requisitos, arquitetura e construção, resultando em um produto de software diferente.
(PMI, 2009) A gestão de riscos deve estar integrada com a gestão de projetos, pois seu sucesso depende da adequada execução
dos demais processos de gestão de projetos.
A gestão de riscos do projeto tem um papel fundamental na elaboração de estimativas realistas para as datas de
conclusão e os custos do projeto.
(Babu & Srivatsa, 2011) Riscos em projetos de software mais comuns: mudanças de requisitos, falta de conhecimento, tecnologias
defeituosas, Gold Plating e cronogramas de projetos irreais.
Governança (Sambamurthy & Zmud,
1999, p. 261)
Os mecanismos de governança de TI referem-se aos padrões de autoridade necessários para as atividades chave de
TI, incluindo-se infraestrutura de TI, uso da TI e gestão de projetos.
117
Subtema Autor(es) Aspectos relevantes
Modelos (Guntamukkala et al.,
2006)
As metodologias Cascata e Modelo V são preferíveis quando os requisitos são claros e é esperada manutenção
futura do software. As metodologias Scrum e XP são preferíveis quando os requisitos mudam constantemente, a
equipe é pequena, os riscos são desconhecidos e o prazo é restrito.
(OGC, 2009) A metodologia de gestão de projetos deve ser adequada às características individuais do projeto, garantindo que a
estrutura de governança, planejamento e controle seja apropriada.
(Patah, 2010) O modelo de gestão de projetos do PMI é o mais divulgado no Brasil e o modelo do OGC (PRINCE2) tem foco
em projetos de software.
(PMI, 2013a; PMI &
IEEE, 2013)
O PMI e o IEEE Computer Society elaboraram o PMBOK Software Extension para fornecer diretrizes específicas
para os gestores de projetos de software.
(PMI, 2013a) A gestão de projetos pode ser definida como a aplicação do conhecimento, habilidades, ferramentas e técnicas às
atividades do projeto para atender aos seus requisitos.
(Rau, 2004) Se uma organização dedica grande parte de sua energia à implantação de projetos, uma abordagem não
estruturada e disciplinada da sua gestão conduz a ineficiências que podem ser danosas à organização.
Sucesso (Agarwal & Rathod, 2006) Nos projetos de software os stakeholders externos entendem que sucesso é realizar o projeto dentro do custo e
prazo planejados e os stakeholders internos (equipe do projeto) entendem que sucesso é entregar o escopo
solicitado com a qualidade necessária.
(Carvalho & Rabechini,
2011)
Cada pessoa ou organização envolvida no projeto pode ter um critério diferente para avaliar o sucesso do projeto.
(Guntamukkala et al.,
2006)
A utilização de uma adequada metodologia de desenvolvimento de software (MDS) melhora a eficiência e
eficácia do produto final.
(Luftman & Brier, 1999) A adequada gestão dos projetos é um fator fundamental para garantir o sucesso dos projetos de TI, mas para que
esta relação se sustente, é necessário que os gestores de projetos estejam preparados.
(OGC, 2009) A gestão de projetos pode ser definida como o planejamento, delegação, monitoramento e controle de todos os
aspectos do projeto para alcançar seus objetivos dentro das metas de desempenho esperadas para o tempo, custo,
qualidade, escopo, benefícios e riscos.
Os princípios do PRINCE2 fornecem um framework de boas práticas para garantir o sucesso do projeto.
(Patah, 2010) Para avaliar e comparar o sucesso nos projetos é necessário classificá-los segundo critérios pré-definidos.
(Pinto & Slevin, 1988) O sucesso do projeto deve ser avaliado pela perspectiva da eficiência (custo, prazo e escopo) e eficácia (o
produto/serviço gerado pelo projeto deve atender os benefícios esperados pelo cliente).
(Rabechini & Carvalho,
2013)
Sucesso do projeto está relacionado com: entregar o escopo planejado; garantir a qualidade do produto final;
atender as expectativas do cliente; e satisfazer a equipe de projeto.
(The Standish Group
International, 2013)
Um projeto de TI concluído com sucesso significa que foi entregue no prazo, dentro do orçamento, com a
qualidade esperada e com as funções necessárias.
O Standish Group acompanha a evolução do sucesso dos projetos de software desde 1985 utilizando as variáveis
da tríplice restrição (custo, escopo e prazo) como fatores de sucesso.
Nota. Fonte: elaborado pelo autor.
118
Tabela 21: Síntese do referencial teórico sobre o tema GESTÃO DE RISCOS DE TI.
Subtema Autor(es) Aspectos relevantes
Conceito (PMI, 2013a) Risco é um evento ou uma condição incerta que, se ocorrer, provocará um efeito positivo (oportunidade) ou
negativo (ameaça) nos objetivos do projeto tais como custo, escopo, prazo ou qualidade.
Gestão de risco é o conjunto de processos, técnicas e ferramentas necessários para aumentar a probabilidade e o
impacto dos eventos positivos e diminuir a probabilidade e o impacto de eventos negativos no projeto.
Categorização (Fortuna, 2013; Marshall,
2002)
Estabelecer uma hierarquia de categorias de risco dentro de uma organização é muito útil porque permite agrupar
os riscos comuns à organização facilitando o prognóstico, prevenção, controle e redução do risco.
(Higuera & Haimes, 1996) Os diferentes níveis hierárquicos dentro de uma organização exigem visões de riscos distintas, pois suas
responsabilidades, habilidades e horizonte de tempo são completamente diferentes.
(Hillson, 2003) A melhor maneira de lidar com uma grande quantidade de dados é estruturar a informação para facilitar a
compreensão, para isso a EAR (Estrutura Analítica de Riscos) permite identificar temas recorrentes e áreas de
concentração de riscos.
(Hillson, 2013b) Riscos do projeto são os riscos associados com o escopo e benefícios do projeto onde se procura avaliar qual o
impacto do projeto para a organização. Riscos no projeto são os riscos individuais identificados e registrados no
Registro de Riscos.
(Holzmann & Spiegler,
2011)
A TBRI (Taxonomy-Based Risk Identification) é uma EAR disponível e que é muito utilizada para categorizar
projetos de software.
(Kerzner, 2013) O nível de formalização necessário para a gestão de riscos depende da cultura corporativa, da relação do projeto
com a estratégia da organização e o tamanho e tipo de projeto.
O que se espera do processo de identificação de riscos é uma lista de riscos categorizados para que os processos
posteriores possam ser realizados de forma plena e completa.
(Leopoldino & Borenstein,
2011)
A categorização de variáveis de riscos permite uma maior compreensão das suas relações e a possibilidade do
tratamento das mesmas em um nível mais alto, lidando com fatores de maior grau de abrangência.
(Miorando, 2010) Principais categorias de riscos de TI encontradas na literatura: custos, benefícios, habilidades e experiência,
tamanho e complexidade, arquitetura e desempenho, cronograma, clareza de escopo, suporte organizacional,
impacto da mudança, ambiente de negócio, maturidade tecnológica e gestão de riscos.
(PMI & IEEE, 2013) Riscos que ocorrem geralmente em projetos de software incluem engenharia, cronograma, custo, qualidade e
equipes.
(PMI, 2013a) A EAR permite agrupar possíveis causas de riscos e ajuda a equipe do projeto a considerar na fase de
identificação de riscos.
(Salles et al., 2010) A categorização de riscos consiste em agrupar os riscos por afinidade ou tipo e pode ser representada por meio de
uma EAR.
Gestão de TI (Hughes, 2006) A maior dependência da TI por parte das organizações tem feito com que os riscos referentes à tecnologia e a sua
utilização venham se tornando cada vez mais visíveis e significantes.
(Grembergen, 2004) Enquanto que a entrega de valor por meio da TI está focada na criação de valor ao negócio, a gestão de risco está
focada na preservação do valor do negócio.
119
Subtema Autor(es) Aspectos relevantes
Governança (ISACA, 2002, p. 5) Governança de TI é a estrutura de relacionamento e processos para controlar a empresa de modo a atingir os
objetivos corporativos, balanceando o risco versus retorno obtido pela TI e seus processos.
(ISO, 2009) Uma adequada gestão de riscos deve considerar: criar e proteger valor, ser parte integrante dos processos
organizacionais, ser um componente do processo de tomada de decisões e moldar-se à organização.
Identificação (Arnuphaptairong, 2011) Diversos estudos realizados desde 1981 geraram listas com os principais riscos em projetos de software. Ao
comparar estas listas, observam-se alguns riscos similares: falta de entendimento dos requisitos; falta de
comprometimento dos gerentes e usuários; e falta de uma metodologia de gestão de projetos.
As organizações podem utilizar como referência as listas disponíveis na literatura, mas recomenda-se que sejam
elaboradas suas próprias listas de riscos baseadas na experiência dos projetos anteriores.
(Boehm, 1989) Identificação de riscos é o primeiro passo para a adequada gestão de riscos em projetos de software.
(Bannerman, 2008) As listas de verificação para identificação de riscos de projetos de software são comuns tanto na literatura quanto
na prática, pois é uma técnica simples, rápida e de baixo custo para a equipe do projeto.
(Boehm & DeMarco,
1997).
A existência de um plano que reconhecia a possibilidade de falha do software poderia comprometer legalmente a
organização e seus representantes. Esta é umas das razões que justifica a ausência de publicações com dados
históricos de riscos de projetos.
(Boehm, 1991) Uma das melhores técnicas para o monitoramento dos riscos é criar uma lista de controle do progresso dos dez
riscos mais significantes do período.
(Chapman & Ward, 2004) Dentre os processos de gestão de riscos, a identificação de riscos é a origem de todo o processo e exige um
elevado grau de conhecimento e criatividade, demandando a opinião de especialistas.
(Chapman & Ward, 2007) As incertezas de um projeto estão relacionadas com a variabilidade das medidas de desempenho (custo, prazo e
qualidade) e com a ambiguidade associada à falta de clareza dos requisitos.
(Carr et al., 1993) O TBRI é um método de identificação de riscos para projetos de software baseado na premissa de que os riscos
são geralmente conhecidos pela equipe técnica, mas são mal comunicados.
(Guyer, 2012) O registro de riscos deve ser utilizado desde o início do projeto, receber a contribuição do maior número de
stakeholders possível e ser reavaliado regularmente durante todo o ciclo de vida do projeto.
(Higuera & Haimes, 1996) A falta de bases de dados com informações históricas de riscos de projetos é um problema enfrentado pelos
gestores de projetos.
(Hillson, 2003) Uma lista de riscos identificados pode ser priorizada para determinar quais riscos devem ser endereçados
primeiro, mas isso não permite compreender a estrutura de riscos do projeto.
(Hillson, 2013a) Os riscos somente são gerenciáveis quando identificados e documentados de forma clara e precisa.
(Holzmann & Spiegler,
2011)
Organizações que possuem bases de dados históricas podem gerar suas próprias listas com os maiores riscos de
projetos de software.
Os autores estruturaram um método para identificar os principais riscos de um grupo de projetos a partir de seus
registros de riscos.
(Keeling, 2000) As revisões históricas são boas fontes de referência para identificar fatores de riscos, a partir daí, surgem as
técnicas de identificação de riscos a partir de listas de verificação.
120
Subtema Autor(es) Aspectos relevantes
Identificação (Koolmanojwong &
Boehm, 2013)
Alguns dos principais riscos em projetos de software: arquitetura complexa; falta de pessoal; restrições de prazo e
orçamento; software pronto; coesão entre os stakeholders; e volatilidade dos requisitos.
(Marshall, 2002) A ausência de dados históricos torna a análise detalhada não confiável.
(Maximiano, 2010) Não existe um catálogo de riscos padrão que atenda a todos os tipos de projeto. Torna-se necessário que cada
organização ou setor desenvolva seu próprio catálogo de riscos.
(Mutton, 2012) Um registro de riscos é uma ferramenta valiosa para compreender e gerenciar os riscos da organização, pois como
não é possível gerenciar o que não se pode medir, o registro de riscos fornece um quadro com métricas que
auxiliam a tomada de decisões com base em informações.
(PMI, 2009) As listas de verificação permitem capturar a experiência prévia e apresentar uma lista de riscos detalhada.
(PMI, 2013a) O registro dos riscos é o documento em que os resultados da análise dos riscos e o planejamento das respostas aos
riscos são registrados.
(Chapman, 1998) A identificação e pré-avaliação dos riscos são os processos mais importantes da gestão de riscos, isto porque o seu
resultado tem um forte impacto sobre a precisão das análises posteriores dos riscos.
(Salles et al., 2010) A identificação de riscos é o início do processo de gestão de riscos e pode ser desenvolvido em três etapas:
analogia com projetos anteriores; categorização de riscos; e identificação de novos riscos.
(Silva et al., 2006) As listas de verificação são frequentemente citadas para verificação de riscos, mas a única ferramenta existente
para levantamento consistente de riscos na área de projetos de software é o TBRI.
(Wegrzynowicz & Stein,
2009)
O GTAG12 do IIA possui uma abrangente lista de verificação para avaliar riscos em projetos de TI.
(Zwikael, 2009) Os processos de gestão de riscos são poucos utilizados nos projetos de software devido à indisponibilidade dos
gerentes funcionais na etapa de identificação de riscos e da falta de prática da equipe no uso das ferramentas e
formalização dos riscos.
Modelos (Boehm, 1988) O modelo em espiral é orientado a risco, pois a cada novo ciclo do projeto as atividades de gestão de risco são
revisitadas.
(Boehm, 1991) O julgamento humano é o item mais importante para o sucesso de um projeto de software, mas o modelo
conceitual e as técnicas de avaliação de risco fornecem as competências necessárias para melhorar o julgamento.
(Ernawati et al., 2012) Os autores propuseram um framework para gestão de riscos em tecnologia baseado na ISO 31000.
(Higuera & Haimes, 1996) O modelo de gestão de riscos do SEI é específico para projetos de software.
A gestão de riscos é continua e deve ser aplicada durante todo o ciclo de vida do projeto de software.
(ISO, 2009) O modelo de gestão de riscos da ISO é de utilização genérica e atende qualquer segmento de mercado.
(MacLeod et al., 2010) O IIA elaborou um manual explicando como o modelo de gestão de riscos da ISO pode ser utilizada pelos
auditores internos.
(Marshall, 2002) A ordem das atividades no projeto faz diferença no nível de risco do projeto.
(OGC, 2009) O tema Riscos do PRINCE2 define como os gerentes devem gerenciar as incertezas em seus planos e no ambiente
do projeto como um todo.
(OGC, 2010) A perspectiva de Riscos do modelo P3M3 tem como objetivo manter o balanceamento entre as ameaças e
oportunidades dos projetos.
121
Subtema Autor(es) Aspectos relevantes
Modelos (PMI & IEEE, 2013) O modelo de gestão de riscos do PMI é específico para gestão de projetos, mas o PMI elaborou uma versão
adaptada para projetos de software que foi elaborada em conjunto com o IEEE.
(Rovai, 2005) Apesar de sua importância, muitos projetos no Brasil são desenvolvidos sem que haja o adequado uso de
metodologias e/ou modelos de gestão de risco.
(Schwaber & Sutherland,
2013)
O Scrum aplica uma abordagem incremental e iterativa para melhorar a previsibilidade e o controle de risco.
(Thamhain, 2013) Para selecionar o modelo de referência para a gestão de riscos mais adequado é importante considerar o grau de
incerteza do projeto, o tamanho do projeto e o impacto do risco no projeto e organização.
Sucesso (Bakker et al., 2010) O conceito tradicional de sucesso de projeto utilizando os critérios de custo, prazo e escopo é frequentemente
utilizado em publicações que estudam a relação entre a gestão de riscos e o sucesso dos projetos de software.
(Dey et al., 2007) Quando a gestão de riscos é adequada, o projeto de software é concluído com sucesso, satisfazendo o cliente,
realizando os objetivos propostos e melhorando o desempenho financeiro da organização.
(Han & Huang, 2007;
Huang & Han, 2008)
Quanto melhor o entendimento sobre os riscos envolvidos no projeto de software, melhor será o resultado do
projeto quanto do produto final.
(Higuera & Haimes, 1996) Quanto mais complexo o projeto, maior a necessidade de gerenciar os riscos de forma estruturada e organizada
para garantir a realização dos objetivos do projeto.
(ISO & IEC, 2006) A gestão de riscos é um fator chave de sucesso para a gestão de projetos de software.
(PMI, 2009) O nível de detalhe, a sofisticação das ferramentas, e a quantidade de tempo e recursos aplicados devem ser
proporcionais às características do projeto e sua importância para a organização.
(PMI, 2013a) Sucesso do projeto deve ser medido em termos da sua conclusão dentro das restrições de escopo, tempo, custo,
qualidade, recursos e risco.
(Rabechini & Carvalho,
2013)
A gestão de riscos em projetos influencia a percepção de sucesso dos projetos.
(Raz et al., 2002) As ferramentas e técnicas de gestão de riscos foram desenvolvidas para melhorar o sucesso dos projetos.
(Schmitz et al., 2007) No Brasil existem poucas pesquisas envolvendo riscos de projetos de software relacionados ao sucesso de
projetos.
(Shenhar & Dvir, 2007) Quanto mais nova a tecnologia, maiores os riscos para o projeto e maior a quantidade de controles necessários
para garantir o sucesso do projeto.
(Wideman, 1992) O objetivo da gestão de riscos em projetos é identificar eventos que possam impactar os objetivos do projeto
relacionados ao custo, escopo, prazo e qualidade.
(Zwikael, 2009) A área de conhecimento do PMBOK relacionada a risco em projetos é a segunda mais importante na
determinação do sucesso de um projeto de software durante a fase de planejamento.
Nota. Fonte: elaborado pelo autor.
122
3 METODOLOGIA DA PESQUISA
O método de pesquisa é peça fundamental na pesquisa científica. Martins e Theóphilo
(2009, p. 37) esclarecem os conceitos de método e metodologia:
O objetivo da metodologia é o aperfeiçoamento dos procedimentos e critérios utilizados na
pesquisa. Por sua vez, método é o caminho para se chegar a determinado fim ou objetivo. A
metodologia é equiparada a uma preocupação instrumental: a ciência busca captar a realidade; a
metodologia trata de como isso pode ser alcançado.
Contemporaneamente, o entendimento é de que a expressão método científico é enganosa, pois
pode induzir a crer que consiste em um conjunto de regras exaustivas e infalíveis. Na verdade,
não existem tais receitas para investigar. O que se tem são estratégias de investigação científica
com técnicas gerais e particulares, e métodos especiais para diversas tecnologias e ciências. O
método científico não é, nem mais nem menos, senão a maneira de se construir boa ciência:
natural ou social, pura ou aplicada, formal ou factual.
Uma pesquisa parte de uma dúvida ou problema e busca uma resposta ou solução
usando um método científico. É o método que revela a ordem imposta aos diferentes processos
necessários para atingir o resultado desejado (Bervian, Cervo & Silva, 2002). Sendo assim, uma
vez definida a questão de pesquisa – “Como deve ser estruturado um modelo de gestão de
riscos que seja aplicável a projetos de software no setor bancário brasileiro?” – faz-se
necessária a definição de um método adequado para respondê-la. Este capítulo apresenta o
método, estratégias e técnicas de pesquisa utilizados para responder esta questão.
3.1 ABORDAGEM E CONTEXTUALIZAÇÃO
A pesquisa empírica realizada neste estudo pode ser classificada como exploratório-
descritiva, qualitativo-quantitativa, positivista, indutiva, e foi abordada por meio do método de
estudo de caso.
A pesquisa exploratória tem como objetivo aprofundar o conhecimento sobre o
problema a fim de torná-lo evidente e a pesquisa descritiva, juntamente com a exploratória,
habitualmente é realizada por pesquisadores sociais preocupados com a atuação prática (Gil,
2010).
123
Segundo Martins & Theóphilo (2009), as investigações científicas podem contemplar
simultaneamente avaliações quantitativas e qualitativas. As pesquisas quantitativas são aquelas
em que os dados e as evidências coletados podem ser quantificados e mensurados, ou seja, os
dados são filtrados, organizados e tabulados. As pesquisas qualitativas são aquelas que exigem
interpretações e análises de informações, fatos, ocorrências e evidências que não são expressas
por números.
A perspectiva positivista acredita que o mundo está em conformidade com as leis de
causalidade, as quais poderiam ser testadas de forma objetiva. Por outro lado, a perspectiva
interpretativista acredita que múltiplas realidades existem devido a construções subjetivas da
mente e o mundo já está socialmente construído, além disso, tenta compreender os fenômenos
por meio da análise de significados atribuídos pelas pessoas (Vries, 2005). Martins e Theóphilo
(2009, p. 41) explicam o positivismo:
O princípio da verificação é colocado como um dos pontos principais do positivismo lógico.
Segundo esse princípio, um enunciado é considerado verdadeiro somente se passível de
confronto do enunciado com a observação empírica. [...] O positivismo possui a crença na
unidade metodológica. Os métodos das ciências naturais são tomados como modelos também
nas ciências sociais, por considerar-se que tanto os fenômenos da natureza quanto os fenômenos
sociais são regidos por leis invariáveis.
Os métodos de pesquisa podem ser indutivos ou dedutivos. Os dedutivos buscam a
solução de um problema a partir de uma lei ou teoria, já os indutivos procuram respostas para um
problema a partir de constatações particulares que podem evoluir para generalizações (Mattar,
2005, p. 26)11
apud (Biancolino, 2010, p. 127). Os estudos de caso são generalizáveis a
proposições teóricas e não a populações ou universos. Nesse sentido, o estudo de caso, como
experimento, não representa uma amostragem e, ao fazer isso, seu objetivo é expandir e
generalizar teorias e não enumerar frequências, realizando uma análise “generalizante” e não
particularizante (Lipset et al.,1956, p.419-420)12
apud (Yin, 2010, p. 36).
Quanto à abordagem metodológica, os estudos exploratórios podem ser
operacionalizados a partir de cinco estratégias diferentes e as pesquisas na área das ciências
sociais aplicadas podem ser classificadas em experimental, de levantamento, de análise de
arquivos, pesquisa histórica e estudo de caso. A definição da abordagem mais adequada exige a
11
MATTAR, F. N. Pesquisa de marketing: metodologia, planejamento. (6a. ed.), São Paulo: Atlas, 2005. 12
Lipset, S.M., Trow, M., Coleman, J. (1956). Union democracy: the inside politics of the international
typographical union. New York. Free Press.
124
observação da forma da questão de pesquisa, a avaliação do controle sobre os eventos
comportamentais e o foco temporal (contemporâneo) da pesquisa. Assim, é importante definir,
em primeiro lugar, o problema a ser pesquisado para, depois, encontrar o procedimento de
pesquisa adequado (Yin, 2010, p. 29). A Tabela 22 apresenta as situações relevantes para
diferentes métodos de pesquisa.
Tabela 22: Situações relevantes para diferentes métodos de pesquisa.
Método Forma de questão de
pesquisa
Exige controle dos eventos
comportamentais?
Enfoca eventos
contemporâneos?
Experimento Como, por quê? Sim Sim
Levantamento
(survey)
Quem, o quê, onde, quantos,
quanto? Não Sim
Análise de arquivos Quem, o quê, onde, quantos,
quanto? Não Sim/Não
Pesquisa histórica Como, por quê? Não Não
Estudo de caso Como, por quê? Não Sim
Nota. Fonte: Yin, 2010, p. 29.
Martins e Theóphilo (2009, p. 61) explicam o método estudo de caso da seguinte forma:
A estratégia de pesquisa Estudo de Caso pede avaliação qualitativa, pois seu objetivo é o estudo
de uma unidade social que se analisa profunda e intensamente. Trata-se de uma investigação
empírica que pesquisa fenômenos dentro de seu contexto real (pesquisa naturalística), onde o
pesquisador não tem controle sobre eventos e variáveis, buscando aprender a totalidade de uma
situação e, criativamente, descrever, compreender e interpretar a complexidade de um caso
concreto. Mediante um mergulho profundo e exaustivo em um objeto delimitado – problema da
pesquisa -, o Estudo de Caso possibilita a penetração na realidade social, não conseguida
plenamente pela avaliação quantitativa.
De um modo geral, pode-se afirmar que avaliações quantitativas são mais adequadas ao
processo de testar teorias, enquanto as avaliações qualitativas são mais aplicáveis em situações
onde se deseja construir teorias (Grounded Theory), enfoque de pesquisa orientada por um
Estudo de Caso.
O estudo de caso conta com muitas técnicas utilizadas pelas pesquisas históricas, mas
acrescenta duas fontes de evidência que usualmente não são incluídas no repertório de um
historiador: observação direta dos eventos que estão sendo estudados e entrevistas das pessoas
neles envolvidas. Nestes termos, o método de estudos de caso é indicado quando se procura
responder a questões iniciadas com os termos “como” e “por que”, quando o evento estudado é
contemporâneo ao pesquisador e quando o mesmo não possui nenhum poder de inferência sobre
o objeto estudado. Nestes casos, as questões formuladas geralmente lidam com questões
operacionais que necessitam ser acompanhadas ao longo do tempo, ao invés de uma análise
pontual de eventos que podem ser analisados via quantificação de frequência ou de incidência
(Yin, 2010, p. 32).
125
Sarker, Xiao e Beaulieu (2012) avaliaram as tendências e padrões atuais de 85 artigos
utilizando análise qualitativa sobre sistemas de informação publicados no período de 2001-2011.
Os artigos foram selecionados a partir de quatro periódicos da Association for Information
Systems que não declararam explicitamente sua preferência por pesquisas qualitativas, são eles:
Management Information Systems (MISQ); Information Systems Research (ISR); Journal of
Management Information Systems (JMIS); e Journal of the Association for Information Systems
(JAIS). A pesquisa revelou:
(1) 71% dos artigos endereçavam questões iniciadas com o termo “como” e 18%
endereçavam questões iniciadas com o termo “o que”. Surpreendentemente, a pesquisa revelou
que uma proporção significativa (33%) dos artigos endereçava questões iniciadas com o termo “o
que” ou “qual”, por exemplo, “O que significa colaboração...”;
(2) Mais da metade dos artigos (54%) utilizaram estudo de caso único;
(3) A técnica mais comum de coleta de dados encontrada foi a entrevista, sendo 38 o
número médio de entrevistas conduzidas (máximo 145 e mínimo 6), ressaltando que não existe
um número recomendado de entrevistas;
(4) 64% gravaram e transcreveram as entrevistas, e quando não é possível gravar,
sugere-se explicar o motivo que não permitiu a gravação;
(5) 60% reportaram o uso de alguma forma de documento para complementar as
entrevistas;
(6) 88% contextualizam o caso antes da análise e interpretação dos dados;
(7) 37% apresentaram as contribuições na forma de um modelo e 26% na forma de uma
tabela.
Ainda no âmbito da tecnologia da informação, o método de estudo de casos vem sendo
utilizado com frequência na avaliação de suas aplicações. A adequação da abordagem de estudos
de caso à área de tecnologia da informação justifica-se através dos seguintes pontos (Benbasat,
Goldsteins, & Mead, 1987):
(1) Permite identificar o estágio atual de desenvolvimento da tecnologia e construir
teorias a partir das práticas verificadas;
126
(2) O objetivo da pesquisa é o de investigar aspectos de gestão e não os aspectos
técnicos;
(3) É frequente o surgimento de novos aspectos de TI que merecem ser estudados;
(4) O uso de estudos de caso é adequado para capturar o conhecimento dos profissionais
da área de TI e construir teorias a partir deste.
3.2 DELINEAMENTO DA PESQUISA
Yin (2010, p. 46) esclarece o que é um projeto de pesquisa da seguinte forma:
O projeto de pesquisa é a lógica que vincula os dados a serem coletados (e as conclusões a
serem tiradas) às questões iniciais do estudo. Todo estudo empírico tem um projeto de pesquisa
implícito, se não explícito. A articulação da “teoria” sobre o que está sendo estudado e o que
deve ser aprendido ajuda a operacionalizar os projetos de estudo de caso e torná-los mais
explícitos.
Ainda segundo Yin (2010, p. 48):
Coloquialmente, um projeto de pesquisa é um plano lógico para chegar daqui até lá, onde aqui
pode ser definido como o conjunto inicial de questões a serem respondidas e lá é algum tipo de
conjunto de conclusões (respostas) sobre essas questões. Entre “aqui” e “lá” pode ser
encontrado um número de passos importantes, incluindo a coleta e a análise de dados
relevantes. [...] O projeto da pesquisa é muito mais do que um plano de trabalho. A principal
finalidade do projeto é ajudar a evitar a situação na qual a evidência não aborda as questões
iniciais da pesquisa. Nesse sentido, um projeto de pesquisa trata de um problema lógico e não
de um problema logístico.
Figura 29: Etapas do estudo de caso.
Fonte: adaptado de Gil, 2010.
127
Não existe um consenso por parte dos pesquisadores quanto às etapas a serem seguidas
no desenvolvimento de um estudo de caso, porém, conforme apresentado na Figura 29, é possível
definir um conjunto de etapas que podem ser seguidas na maioria dos estudos de caso (Gil,
2010):
(1) Formulação do problema – constitui a etapa inicial da pesquisa e decorre de um
longo processo de reflexão e de imersão em fontes bibliográficas adequadas. O estudo de caso
não é adequado para mensurar o nível de correlação entre variáveis ou verificar hipóteses causais.
Sua principal utilização ocorre em estudos exploratórios e descritivos.
(2) Definição da unidade-caso – refere-se a um indivíduo num contexto definido,
podendo ser ampliado para um grupo social, uma organização, um processo social, uma
comunidade, uma nação ou mesmo toda uma cultura. Os casos também podem ser definidos do
ponto de vista temporal, por exemplo, um evento ou um projeto.
(3) Determinação do número de casos – o estudo pode ser constituído tanto de um único
quanto de múltiplos casos. A utilização de múltiplos casos é a situação mais frequente nas
pesquisas sociais, pois proporciona evidências inseridas em diferentes contextos exigindo uma
metodologia mais apurada e mais tempo para coleta e análise dos dados. Costuma-se utilizar um
único caso quando o acesso a múltiplos casos é difícil e o pesquisador tem possibilidade de
investigar um deles com profundidade devido ao acesso privilegiado aos dados.
(4) Elaboração do protocolo – documento que não apenas contém o instrumento de
coleta de dados, mas também define a conduta a ser adotada para sua aplicação. Constitui uma
das melhores formas de aumentar a confiabilidade do estudo de caso.
(5) Coleta de dados – utiliza-se sempre mais de uma técnica para conferir validade ao
estudo e evitar a subjetividade do pesquisador. Os resultados devem ser provenientes da
convergência ou da divergência das observações obtidas de diferentes procedimentos de coleta
que podem ser: análise de documentos, entrevistas, depoimentos pessoais, observação
espontânea, observação participante e análise de artefatos físicos.
(6) Avaliação e análise dos dados – como são utilizados diversos procedimentos de
coleta de dados, é esperado que sejam utilizados diferentes modelos de análise; entretanto, é
natural admitir que a análise dos dados seja de natureza predominantemente qualitativa.
128
(7) Preparação do relatório – existe um grau de formalidade menor em relação a outros
métodos de pesquisa, porém, verifica-se a tendência em apresentar os estudos de caso de maneira
semelhante aos demais relatórios de pesquisa (apresentação do problema, metodologia utilizada,
resultados obtidos e conclusões).
Eisenhardt (1989) descreve o processo para construção de teoria a partir de uma
pesquisa de estudo de caso. A Figura 30 apresenta o passo a passo do processo: (1) Iniciar –
definição da questão de pesquisa e organização dos constructos; (2) Selecionar casos – definição
do conceito da população do estudo para determinar o conjunto de entidades que participarão da
amostra; (3) Criar protocolos – definição dos diferentes métodos de coleta de dados, além das
possíveis combinações de dados quantitativos e qualitativos; (4) Trabalhar em campo – nesta fase
ocorre a sobreposição das fases de coleta de dados e análise, além disso, é possível flexibilizar os
métodos de coleta para aproveitar eventuais oportunidades identificadas; (5) Analisar dados –
utilizar diferentes técnicas de análise de dados permite olhar as evidências de forma profunda e
complementar; (6) Criar hipóteses – tabular e organizar as evidências de forma lógica e
estruturada para cada um dos constructos; (7) Comparar literatura – comparar as análises com as
literaturas similares e conflitantes de forma a validar e generalizar a teoria; e (8) Encerrar –
finalização do processo de construção da teoria a partir do momento em que ocorre a saturação,
ou seja, quando novas evidências não trazem novidades.
Figura 30: Construindo teorias a partir de um estudo de caso.
Fonte: adaptado de Eisenhardt, 1989.
Ainda segundo Eisenhardt (1989), esta abordagem possui algumas forças e fraquezas.
Forças: existe a probabilidade de geração de uma nova teoria; a teoria emergente pode ser testada
a partir de constructos mensuráveis e hipóteses validáveis; e a teoria resultante é empiricamente
válida. Fraquezas: complexidade devido ao grande volume e variedade de informações; e a teoria
construída pode ser estreita e idiossincrática, ou seja, uma teoria que só tem importância ou
significado para o autor e não para a comunidade científica.
129
O estudo deve apresentar detalhadamente os procedimentos realizados evidenciando
isenção da opinião do pesquisador. O estudo de caso deve revelar análises em profundidade, não
em extensão. A apresentação deve ser clara e concisa, evitando a inclusão de informações de
apoio em demasia, como por exemplo, histórico da organização. A fronteira entre o fenômeno
que está sendo estudado e seu contexto deve ser claramente delimitado. O estudo deve mostrar de
maneira convincente que foram coletadas e avaliadas as evidências relevantes e que seu
encadeamento é criativo e lógico. É importante que o pesquisador demonstre que a questão de
pesquisa foi tratada com rigor científico e seus objetivos alcançados (Martins & Theóphilo,
2009).
Um projeto de pesquisa utilizando o método estudo de caso deve conter cinco
componentes: (1) as questões do estudo; (2) as proposições, se houver; (3) as unidades de análise;
(4) a lógica que une os dados às proposições; e (5) os critérios para interpretar as constatações.
Yin (2010, p. 57) explica que:
Embora o atual nível de desenvolvimento não proporcione orientação detalhada sobre a
vinculação dos dados às proposições e critérios para interpretação dos achados, o projeto
completo de pesquisa deve indicar quais os dados a serem coletados – como indicado pelas
questões de estudo, suas proposições e suas unidades de análise. O projeto também deve dizer o
que deve ser feito após os dados serem coletados – como indicado pela lógica que vincula os
dados às proposições e aos critérios para a interpretação dos achados.
3.2.1 Questões de Estudo
A adequada definição da questão de pesquisa é peça-chave em qualquer estudo
científico. Caso seja escolhido um estudo de caso único é importante a autorização prévia da
direção da organização para os propósitos do pesquisador (Martins & Theóphilo, 2009).
Yin (2010, p. 49) explica que a o método do estudo de caso é mais apropriado para
questões do tipo “como” e “por que” e sugere três estágios para a elaboração de uma questão de
pesquisa relevante:
No primeiro, tente usar a literatura para estreitar seu interesse para um ou dois tópicos-chave,
sem preocupar-se com qualquer questão de pesquisa específica. No segundo, examine de perto
alguns estudos-chave sobre seu tópico de interesse. Identifique as questões nesses poucos
estudos e verifique se elas concluem com novas questões ou lacunas para a futura pesquisa.
Elas podem estimular, então, seu próprio raciocínio e imaginação e você pode se descobrir
articulando suas próprias questões potenciais. No terceiro estágio, examine outro conjunto de
130
estudos sobre o mesmo tópico. Eles podem proporcionar apoio para questões potenciais ou
mesmo sugerir maneiras de aperfeiçoá-las.
No contexto deste estudo, considerando-se que a tecnologia bancária é uma peça chave
na estratégia de um banco para garantir sua vantagem competitiva, encontra-se o desafio deste
tipo de organização em gerenciar adequadamente os riscos de seus projetos de software para
garantir seu sucesso, não apenas na perspectiva da eficiência (custo, prazo e escopo), mas
também na perspectiva da eficácia (o produto ou serviço gerado pelo projeto deve atender os
benefícios esperados pelo cliente).
3.2.2 Proposições de Estudo
Yin (2010, p. 50) elucida que as proposições tem a função de direcionar o escopo do
estudo. A questão de pesquisa é a essência do que se busca responder; entretanto, isoladamente
não aponta o caminho que deve ser estudado. O estabelecimento das proposições obriga o
pesquisador a refletir sobre o conteúdo teórico e sugerir uma direção para seu estudo.
Martins e Theóphilo (2009, p. 65) explicam o objetivo das proposições:
As proposições, no contexto de um Estudo de Caso, refletem explicações teóricas formuladas a
partir de algum conhecimento do caso e reflexões do pesquisador. As proposições podem ser
entendidas como uma teoria preliminar, criada pelo autor, que buscará, ao longo do trabalho,
defender e demonstrar.
Proposições orientam corretamente o estudo, contribuindo para a objetividade do trabalho.
Quanto mais proposições específicas um estudo contiver, mais ele permanece dentro de limites
exequíveis. No planejamento e condução de um Estudo de Caso as proposições substituem os
objetivos e as hipóteses normalmente formuladas nas pesquisas convencionais.
Nestes termos, a partir da revisão bibliográfica e objetivos específicos da pesquisa,
foram formuladas premissas e proposições associadas, de forma a propor um modelo acerca da
problematização da pesquisa e de suas questões recorrentes.
Martins e Theóphilo (2009, p. 29) assim explicam o que é um modelo:
A teoria constitui o núcleo essencial da ciência, sem a qual não se consegue avançar. Além dos
elementos básicos da visão clássica de teoria – cálculos e regras de correspondência –, os
estudiosos introduziram um terceiro elemento nas teorias: o modelo. Os modelos, segundo esse
entendimento, caracterizam as ideias fundamentais da teoria com auxílio de conceitos
familiarizados, antes da elaboração da teoria. [...] Não é único o conceito de modelo, cuja
significação dependerá da finalidade com que será utilizado. [...] Sob outro ponto de vista,
alguns autores entendem que modelo e interpretação são sinônimos, ou seja, os modelos são
131
compreendidos como interpretações de uma teoria. [...] Outro entendimento se dá pela
consideração de modelo como uma explicação de uma teoria. Assim é que o modelo como
interpretação e o modelo como explicação podem coexistir, favorecendo análises mais precisas
e claras. [...] Um modelo de um sistema ou processo é construído com poucas variáveis-fatores
manejáveis, de tal sorte que as relações mais significantes possam ser identificadas e estudadas.
Os autores também explicam o valor e limites do uso de modelos (Martins & Theóphilo,
2009, p. 29):
No campo das ciências fáticas, os modelos são considerados válidos se resistirem ao confronto
com os fatos, isto é, se forem verificados. A modelagem – construção de um modelo – é
posterior à clara definição do problema sob investigação, e, particularmente, das variáveis,
atributos e características do objeto que se deseja conhecer/explicar/prover. [...] Os modelos não
são verdadeiros nem falsos, são apenas mais ou menos adequados para certos usos. O valor e a
significância de um modelo não são dados por algo intrínseco: dependerão do campo no qual
vão ser aplicados, isto é, não serão verdadeiros nem falsos, mas sim úteis ou inúteis.
Um modelo tem as seguintes funções: seletiva – permite que fenômenos complexos
sejam visualizados e compreendidos; organizacional – classifica os elementos da realidade
segundo um esquema; fertilidade – evidencia outras aplicações em distintas situações; lógica –
permite explicar como ocorre o fenômeno; normativa – permite prescrições; e sistêmica – orienta
os procedimentos de forma sequencial e estruturada (Martins & Theóphilo, 2009).
As etapas para a construção de um modelo são: conceitualização – investigação de
teorias que ajudem a explicar o fenômeno representado. Depende da capacidade do pesquisador
em identificar problemas relevantes ao conhecimento da realidade sob investigação; modelagem
– processo de ajuste e evolução por meio da elaboração de representações mais simples e
analogias com estruturas teóricas consolidadas; solução do modelo operacional – relacionamento
entre o modelo operacional do sistema e a solução proposta; implantação – aplicação dos
resultados obtidos pela solução do modelo operacional; e validação – capacidade de explicação e
de previsão do modelo (Martins & Theóphilo, 2009).
Conforme pode ser observado na Figura 31, a revisão bibliográfica apresenta a Gestão
de Riscos de TI e a Gestão de Projetos de TI como Mecanismos de Governança de TI, ou seja,
são instrumentos que garantem a implantação das estratégias da organização. A Gestão de Riscos
é um agente catalizador do sucesso da Gestão de Projetos que, por sua vez, é um fator crítico de
sucesso para o desempenho, crescimento e sucesso da organização.
132
Figura 31: Modelo teórico.
Fonte: elaborado pelo autor.
A partir desses conceitos entende-se que uma organização complexa como um banco
pode utilizar sua base de dados de riscos de projetos de software para gerar diferentes visões de
riscos para diferentes níveis hierárquicos. Desta forma, é possível auxiliar tanto os executivos na
tomada de decisões estratégicas relacionadas aos riscos dos projetos (riscos que impactam a
organização), quanto os gerentes de projetos na gestão dos riscos nos projetos (riscos que
impactam os objetivos dos projetos).
3.2.2.1 Premissa 1 e Proposições Associadas
Premissa 1: Definir os critérios necessários para agrupar os riscos identificados e
armazenados em bases históricas de projetos de software.
Para a elaboração das proposições de pesquisa associadas à premissa 1, foram utilizados
os aspectos relevantes identificados no referencial teórico e relacionados na Tabela 23:
133
Tabela 23: Aspectos relevantes identificados no referencial teórico (premissa 1).
Referencial teórico e
empírico Aspectos relevantes
Proposição 1 – Registro de Riscos
(Higuera & Haimes,
1996)
A falta de bases de dados com informações históricas de riscos de projetos é um problema
enfrentado pelos gestores de projetos.
(Hillson, 2003) Apenas uma lista de riscos identificados não permite compreender a estrutura de riscos do
projeto.
(Holzmann &
Spiegler, 2011)
Organizações que possuem bases de dados históricas podem gerar suas próprias listas com
os maiores riscos de projetos de software.
(Maximiano, 2010) Não existe um catálogo de riscos padrão que atenda a todos os tipos de projeto. Torna-se
necessário que cada organização ou setor desenvolva seu próprio catálogo de riscos.
(PMI, 2013a) O registro dos riscos é o documento em que os resultados da análise dos riscos e o
planejamento das respostas aos riscos são registrados.
(Silva et al., 2006) As listas de verificação são frequentemente citadas para verificação de riscos, mas a única
ferramenta existente para levantamento consistente de riscos na área de projetos de software
é o TBRI.
Proposição 2 – Categorização de Riscos
(Carr et al., 1993)
O TBRI é um método de identificação de riscos para projetos de software e baseado na
premissa de que os riscos são geralmente conhecidos pela equipe técnica, mas são mal
comunicados.
(Fortuna, 2013;
Marshall, 2002)
Estabelecer uma hierarquia de categorias de risco dentro de uma organização é muito útil
porque permite agrupar os riscos comuns à organização facilitando o prognóstico,
prevenção, controle e redução do risco.
(Higuera & Haimes,
1996)
Os diferentes níveis hierárquicos dentro de uma organização exigem visões de riscos
distintas, pois suas responsabilidades, habilidades e horizonte de tempo são completamente
diferentes.
(Hillson, 2003) A melhor maneira de lidar com uma grande quantidade de dados é estruturar a informação
para facilitar a compreensão, para isso a EAR (Estrutura Analítica de Riscos) permite
identificar temas recorrentes e áreas de concentração de riscos.
(Holzmann &
Spiegler, 2011)
A TBRI (Taxonomy-Based Risk Identification) é uma EAR disponível e que é muito
utilizada para categorizar projetos de software.
(Leopoldino &
Borenstein, 2011)
A categorização de variáveis de riscos permite uma maior compreensão das suas relações e
a possibilidade do tratamento das mesmas em um nível mais alto, lidando com fatores de
maior grau de abrangência.
Proposição 3 – Processos Imaturos de Gestão de Riscos
(Alberts & Dorofee,
2012)
Muitos projetos ainda falham devido à falta de maturidade das organizações em gestão de
riscos.
(Luftman & Brier,
1999)
A adequada gestão dos projetos é um fator fundamental para garantir o sucesso dos projetos
de TI, mas para que esta relação se sustente, é necessário que os gestores de projetos
estejam preparados.
(Rovai, 2005) Apesar de sua importância, muitos projetos no Brasil são desenvolvidos sem que haja o
adequado uso de metodologias e/ou modelos de gestão de risco.
(Kerzner, 2013) O nível de formalização necessário para a gestão de riscos depende da cultura corporativa,
da relação do projeto com a estratégia da organização e o tamanho e tipo de projeto.
(Zwikael, 2009) Os processos de gestão de riscos são poucos utilizados nos projetos de software devido à
indisponibilidade dos gerentes funcionais na etapa de identificação de riscos e da falta de
prática da equipe no uso das ferramentas e formalização dos riscos.
(Chapman & Ward,
2004)
Dentre os processos de gestão de riscos, a identificação de riscos é a origem de todo o
processo e exige um elevado grau de conhecimento e criatividade, demandando a opinião de
especialistas.
(OGC, 2009) A metodologia de gestão de projetos deve ser adequada às características individuais do
projeto, garantindo que a estrutura de governança, planejamento e controle seja apropriada.
Nota. Fonte: elaborado pelo autor.
134
Proposição 1: O registro de riscos, quando adequadamente utilizado, é uma importante
ferramenta para a gestão de riscos. Constitui a base histórica dos riscos e planos de ações
identificados e analisados durante o projeto e permite gerar um catálogo de riscos para a
organização.
Proposição 2: A categorização dos riscos em uma Estrutura Analítica de Riscos
utilizando a TBRI permite agrupar uma grande quantidade de riscos comuns de projetos de
software e gerar diversas visões para diferentes níveis hierárquicos na organização.
Proposição 3: Dentre os processos de gestão de riscos, a identificação de riscos é o
processo mais importante, porque somente os riscos identificados podem ser gerenciados.
Entretanto, em organizações imaturas muitos projetos de software são desenvolvidos por
profissionais despreparados que não utilizam as metodologias disponíveis e, consequentemente,
não registram os riscos dos projetos.
3.2.2.2 Premissa 2 e Proposições Associadas
– Premissa 2: Agrupar os riscos dos projetos de software permitindo identificar e
priorizar os principais riscos.
Para a elaboração das proposições de pesquisa associadas à premissa 2, foram utilizados
os aspectos relevantes identificados no referencial teórico e relacionados na Tabela 24:
Tabela 24: Aspectos relevantes identificados no referencial teórico (premissa 2).
Referencial Teórico e
Empírico Aspectos relevantes
Proposição 4 – Categorização de Projetos
(Castro & Carvalho, 2010) 74% das organizações pesquisadas, principalmente as do setor financeiro, adotam a
categorização de projetos por finalidade, com destaque para os projetos de
desenvolvimento de tecnologia e de sistemas de informação.
(Crawford et al., 2006)
As organizações que realizam muitos projetos precisam categorizar seus projetos
para compará-los entre si e garantir o alinhamento estratégico.
(Luftman et al., 1999) Um dos principais facilitadores do alinhamento estratégico de TI e negócios é a
adequada priorização dos projetos.
(Padovani, 2007) Uma forma bastante simples de classificar os projetos é organizá-los conforme sua
finalidade, por exemplo: manutenção, infraestrutura, informática ou engenharia.
(Patah, 2010) Para avaliar e comparar os projetos é necessário classificá-los segundo critérios pré-
definidos.
(Shenhar & Dvir, 2007) Os projetos devem ser classificados de acordo com quatro dimensões: novidade,
tecnologia, complexidade e passo.
(Thamhain, 2013) Para selecionar o modelo de referência para a gestão de riscos mais adequado é
importante considerar o grau de incerteza do projeto, o tamanho do projeto e o
impacto do risco no projeto e organização.
135
Referencial Teórico e
Empírico Aspectos relevantes
Proposição 5 – Riscos em Projetos de Software
(Arnuphaptairong, 2011) Diversos estudos realizados desde 1981 geraram listas com os principais riscos em
projetos de software. Ao comparar estas listas, observam-se alguns riscos similares:
falta de entendimento dos requisitos; falta de comprometimento dos gerentes e
usuários; e falta de uma metodologia de gestão de projetos.
(Hillson, 2013b) Riscos do projeto são os riscos associados com o escopo e benefícios do projeto
onde se procura avaliar qual o impacto do projeto para a organização. Riscos no
projeto são os riscos individuais identificados e registrados no Registro de Riscos.
(Hughes, 2006) Cada vez mais, percebe-se que os riscos relacionados à TI e aos seus projetos estão
ficando maiores, especialmente porque estes são difíceis de serem identificados e,
constantemente, modificam-se ao longo do tempo.
(Koolmanojwong & Boehm,
2013)
Alguns dos principais riscos em projetos de software: arquitetura complexa; falta de
pessoal; restrições de prazo e orçamento; software pronto; coesão entre os
stakeholders; e volatilidade dos requisitos.
(Miorando, 2010) Principais categorias de riscos de TI encontradas na literatura: custos, benefícios,
habilidades e experiência, tamanho e complexidade, arquitetura e desempenho,
cronograma, clareza de escopo, suporte organizacional, impacto da mudança,
ambiente de negócio, maturidade tecnológica e gestão de riscos.
(PMI & IEEE, 2013) Riscos que ocorrem geralmente em projetos de software incluem engenharia,
cronograma, custo, qualidade e equipes.
(PMI & IEEE, 2013) Cada projeto de software tem diferentes incertezas, riscos e oportunidades, pois são
uma combinação única de requisitos, arquitetura e construção, resultando em um
produto de software diferente.
(Shenhar et al., 2007) Os riscos que aparentemente afetam apenas o projeto podem se propagar por toda a
empresa.
(Suresh Babu & Srivatsa,
2011)
Riscos em projetos de software mais comuns: mudanças de requisitos, falta de
conhecimento, tecnologias defeituosas, Gold Plating e cronogramas de projetos
irreais.
Proposição 6 – Lista de Riscos
(Arnuphaptairong, 2011) As organizações podem utilizar como referência as listas disponíveis na literatura,
mas recomenda-se que sejam elaboradas suas próprias listas de riscos baseadas na
experiência dos projetos anteriores.
(Boehm, 1989) Identificação de riscos é o primeiro passo para a adequada gestão de riscos em
projetos de software.
(Bannerman, 2008) As listas de verificação para identificação de riscos de projetos de software são
comuns tanto na literatura quanto na prática, pois é uma técnica simples, rápida e de
baixo custo para a equipe do projeto.
(Hillson, 2003) Uma lista de riscos identificados pode ser priorizada para determinar quais riscos
devem ser endereçados primeiro.
(Hillson, 2013a) Os riscos somente são gerenciáveis quando identificados e documentados de forma
clara e precisa.
(Keeling, 2000) As revisões históricas são boas fontes de referência para identificar fatores de riscos,
a partir daí, surgem as técnicas de identificação de riscos a partir de listas de
verificação.
(Kerzner, 2013) O que se espera do processo de identificação de riscos é uma lista de riscos
categorizados para que os processos posteriores possam ser realizados de forma
plena e completa.
(PMI, 2009) As listas de verificação permitem capturar a experiência prévia e apresentar uma
lista de riscos detalhada.
(Wideman, 1992) O objetivo da gestão de riscos em projetos é identificar eventos que possam
impactar os objetivos do projeto relacionados ao custo, escopo, prazo e qualidade.
Nota. Fonte: elaborado pelo autor.
136
Proposição 4: Os projetos devem ser categorizados e agrupados por finalidade e
tamanho/complexidade para que seja possível compará-los.
Proposição 5: Os principais riscos em projetos de software na organização estudada são
os mesmos apresentados na literatura: escopo instável, premissas de prazo e custo irreais,
tecnologia complexa e falta de habilidades em gestão de projetos.
Proposição 6: Os bancos devem ter a sua própria lista de verificação de riscos, pois é
uma importante fonte de referência para o processo de identificação de riscos.
3.2.2.3 Premissa 3 e Proposições Associadas
– Premissa 3: Apresentar aos executivos uma visão estratégica dos principais riscos de
projetos de software.
Para a elaboração das proposições de pesquisa associadas à premissa 3, foram utilizados
os aspectos relevantes identificados no referencial teórico e relacionados na Tabela 25:
Tabela 25: Aspectos relevantes identificados no referencial teórico (premissa 3).
Referencial Teórico e
Empírico Aspectos relevantes
Proposição 7 – Sucesso em Projetos
(Agarwal & Rathod, 2006) Nos projetos de software os stakeholders externos entendem que sucesso é realizar
o projeto dentro do custo e prazo planejados e os stakeholders internos (equipe do
projeto) entendem que sucesso é entregar o escopo solicitado com a qualidade
necessária.
(Bakker et al., 2010) O conceito tradicional de sucesso de projeto utilizando os critérios de custo, prazo e
escopo são frequentemente utilizados em publicações que estudam a relação entre a
gestão de riscos e o sucesso dos projetos de software.
(ISO & IEC, 2006) A gestão de riscos é um fator chave de sucesso para a gestão de projetos de
software.
(Pinto & Slevin, 1988) O sucesso do projeto deve ser avaliado pela perspectiva da eficiência (custo, prazo e
escopo) e eficácia (o produto/serviço gerado pelo projeto deve atender os benefícios
esperados pelo cliente).
(PMI, 2013a) Sucesso do projeto deve ser medido em termos da sua conclusão dentro das
restrições de escopo, tempo, custo, qualidade, recursos e risco.
(Rabechini & Carvalho, 2013) A gestão de riscos em projetos influencia a percepção de sucesso dos projetos.
(Raz et al., 2002) As ferramentas e técnicas de gestão de riscos foram desenvolvidas para melhorar o
sucesso dos projetos.
(The Standish Group
International, 2013)
Um projeto de TI concluído com sucesso significa que foi entregue no prazo, dentro
do orçamento, com a qualidade esperada e com as funções necessárias.
(Zwikael, 2009) A área de conhecimento do PMBOK relacionada a risco em projetos é a segunda
mais importante na determinação do sucesso de um projeto de software durante a
fase de planejamento.
137
Referencial Teórico e
Empírico Aspectos relevantes
Proposição 8 – Visão Estratégica de Riscos
(Alberts & Dorofee, 2012)
Riscos para Tomada de
Decisão
Falhas evitáveis em projetos de software continuam a ocorrer, pois diversos riscos
significativos não são levados ao conhecimento dos tomadores de decisão.
(Boehm, 1991) Uma das melhores técnicas para o monitoramento dos riscos é criar uma lista de
controle do progresso dos dez riscos mais significantes do período.
(Boehm, 1991) O julgamento humano é o item mais importante para o sucesso de um projeto de
software, mas o modelo conceitual e as técnicas de avaliação de risco fornecem as
competências necessárias para melhorar o julgamento.
(Grembergen, 2004) A governança de TI é composta pela liderança, estrutura organizacional e processos
necessários para garantir que a as atividades de TI sustentem e expandam os
objetivos estratégicos da organização.
(Hitt et al., 2014) No ambiente de TI as mudanças são constantes e as vantagens competitivas
temporárias, obrigando as organizações a desenvolverem estratégias sustentadas por
projetos cada vez mais rápidos, baratos e melhores.
(Hughes, 2006) Para diminuir drasticamente os riscos da TI e melhorar o retorno sobre os
investimentos realizados em projetos de software é necessário realizar a gestão de
riscos da TI como parte dos riscos da organização.
(ISACA, 2002, p. 5) Governança de TI é a estrutura de relacionamento e processos para controlar a
empresa de modo a atingir os objetivos corporativos, balanceando o risco versus
retorno obtido pela TI e seus processos.
(Lunardi, 2008) As decisões inerentes à TI precisam ser gerenciadas pela alta administração e a
governança é um importante instrumento de gestão.
(PMI, 2009) A gestão de riscos deve estar alinhada com os valores organizacionais, pois muitas
vezes os riscos exigem aprovação ou respostas de pessoas que estão em níveis
hierárquicos superiores ao do gerente de projeto.
Nota. Fonte: elaborado pelo autor.
Proposição 7: A adequada gestão de riscos é um fator chave para o sucesso dos projetos
de software, garantindo que estes sejam concluídos dentro do prazo, dentro do orçamento, com a
qualidade esperada e com as funções necessárias.
Proposição 8: Os principais riscos dos projetos de software devem ser apresentados em
uma visão estratégica para permitir a adequada análise e tomada de decisão pelos executivos da
organização.
3.2.3 Unidade de Análise
No método estudo de caso, os termos unidade de análise e “caso” são sinônimos.
Indivíduos, pequenos grupos, organizações e parcerias são casos concretos e de fácil delimitação.
Na sociologia, por exemplo, o indivíduo é a unidade primária de análise, onde a informação
138
relevante sobre este indivíduo é coletada e vários desses indivíduos formam um estudo de casos
múltiplos (Yin, 2010).
Yin (2010, p. 51) explica a importância das questões e proposições no direcionamento
do estudo junto à unidade de análise:
No estudo de caso clássico, por exemplo, o “caso” pode ser um indivíduo. (...) Você ainda
precisaria de questões e proposições de estudo para ajudar a identificar a informação relevante a
ser coletada sobre este indivíduo ou indivíduos. Sem essas questões e proposições, você seria
tentado a cobrir “tudo” sobre o(s) indivíduo(s), o que é impossível fazer. (...) Quanto mais um
estudo de caso contiver questões e proposições específicas, mais ele permanecerá dentro dos
limites viáveis.
Naturalmente, o “caso” também pode ser algum evento ou entidade, além de um único
indivíduo. Os estudos de caso têm sido realizados sobre decisões, programas, processos de
implementação e mudança organizacional.
Após definir a unidade de análise é importante delimitar o tempo, ou seja, o começo e o
fim do caso. Dessa forma é possível determinar o escopo da coleta de dados e distinguir os dados
sobre o sujeito do estudo de caso (o “fenômeno”) dos dados externos ao caso (o “contexto”) (Yin,
2010).
Yin (2010) aborda as características gerais do desenho de estudos de caso, partindo do
princípio que os casos podem ser únicos ou múltiplos, podendo também ser, simultaneamente,
holísticos (com uma unidade de análise) ou integrados (várias unidades de análise). Desta
combinação resultam quatro tipos diferentes de projetos para estudos de caso, apresentados na
Tabela 26.
Tabela 26: Tipos de projetos para estudos de caso.
Estudo de caso único Estudo de casos múltiplos
Holístico
(unidade única de análise) Caso único holístico Casos múltiplos holístico
Integrado
(unidades múltiplas de análise) Caso único integrado Casos múltiplos integrado
Nota. Fonte: adaptado de Yin, 2010.
Neste estudo será realizado o estudo de caso único integrado, recomendado para
aprender a totalidade de uma situação e descrever, compreender e interpretar um caso concreto
(Martins & Theóphilo, 2009).
O estudo de caso único justifica-se quando se trata de um caso representativo ou o
pesquisador tem acesso a uma situação inacessível à observação científica (Yin, 2010). A
organização estudada é representativa, pois se trata de um dos maiores bancos brasileiros e o
139
pesquisador, como funcionário da organização, possui acesso e permissão para utilizar os dados
disponíveis na ferramenta de gestão integrada de tecnologia, tais como custo, escopo, prazo e
riscos.
O estudo de caso único também se justifica pelo objetivo da pesquisa de propor práticas
que melhorem os processos utilizados na organização analisada, em consonância com a Portaria
Normativa n. 17, de 28 de dezembro de 2009, do Ministério da Educação, que dispõe as diretrizes
para mestrados profissionais no Brasil e coloca como objetivos destes a transferência de
conhecimentos para melhoria da eficácia, eficiência, competitividade e produtividade de
organizações públicas e privadas por meio da solução de problemas e geração e aplicação de
processos de inovação apropriados.
A unidade integrada de análise neste estudo é o projeto de software, pois Yin (2010, p.
73) explica que “o caso único pode ser um programa público que envolve um grande número de
projetos financiados – que seriam, então, as unidades integradas”. Como serão analisados
diversos projetos de software executados na organização, esta dissertação pode ser classificada
como um estudo de unidades múltiplas de análise.
O período analisado será delimitado pela base de dados de projetos disponível para
extração eletrônica, ou seja, os projetos de software iniciados no período de 01/01/2012 a
31/08/2014.
3.2.4 Vinculação dos Dados às Proposições
Segundo Yin (2010, p. 56), o objetivo da vinculação dos dados às proposições é
determinar com antecedência quais os passos da análise de dados e, dessa forma, garantir a coleta
de dados na medida exata para que não faltem dados nem sejam coletados dados em demasia. O
autor comenta:
As técnicas analíticas combinação de padrão, construção de explanação, análise de séries
temporais, modelos lógicos e síntese de casos cruzados, representam as formas de vinculação
dos dados às proposições. As análises reais exigirão que você combine ou calcule seus dados de
estudo de caso como um reflexo direto das proposições iniciais do estudo. Por exemplo, o
conhecimento de que algumas ou todas as suas proposições cobrem uma sequência temporal
significa que, eventualmente, algum tipo de análise de série temporal pode ser usada. A
observação desta forte probabilidade, durante a fase de projeto, chama sua atenção para a
140
necessidade de garantir a existência de procedimentos suficientes para coletar os marcadores de
tempo, como parte de seus planos de coleta de dados.
Na Tabela 27, Yin (2010, p. 129) explica os pontos fortes e fracos das fontes de
evidência utilizadas no estudo.
Tabela 27: Pontos fortes e fracos das fontes de evidências utilizadas no estudo.
Fonte de evidência Pontos fortes Pontos fracos
Documentação . Estável – pode ser revista repetidamente.
. Discreta – não foi criada em consequência
do estudo de caso.
. Exata – contém nomes, referências e
detalhes exatos de um evento.
. Ampla cobertura – longo período de tempo,
muitos eventos e muitos ambientes.
. Recuperabilidade – pode ser difícil de
encontrar.
. Acesso – pode ser negado deliberadamente.
Registros em
arquivo
. [Idem à documentação].
. Precisos e geralmente quantitativos.
. [Idem à documentação].
. Acessibilidade devido a razões de
privacidade.
Entrevistas . Direcionadas – focam os tópicos do estudo
de caso.
. Perceptíveis – fornecem inferências e
explanações causais percebidas.
. Parcialidade da resposta.
. Incorreções devido à falta de memória.
. Reflexividade – o entrevistado dá ao
entrevistador o que ele quer ouvir.
Nota. Fonte: Yin, 2010.
Para garantir a coleta dos dados na medida exata, a Tabela 28 apresenta como as três
fontes de dados devem ser relacionadas às proposições: entrevistas; registros em arquivos; e
documentação.
Tabela 28: Vinculação dos dados às proposições.
Proposições Dados coletados por fonte de evidência
a
Entrevistas Registros em arquivo Documentação
Proposição 1
Registro de Riscos
. 1 – Como os riscos de projetos
são documentados na
organização?
. Base de Dados de Riscos
. Base de Dados de
Projetos
. Processos da
Metodologia de Gestão de
Projetos
. Processos da
Metodologia de
Desenvolvimento de
Software
. Documentos dos
Projetos: requisitos, mapa
de stakeholders,
cronogramas, atas de
reuniões, boletins, etc.
Proposição 2
Categorização de
Riscos
. 2a – Os riscos são
categorizados?
. 2b – Em caso positivo, quais são
as categorias de risco utilizadas?
Proposição 3
Processo Imaturo
de Gestão de
Riscos
Para os projetos sem riscos
documentados:
. 3a – Por que os riscos não são
documentados na ferramenta de
gestão integrada de tecnologia?
. 3b – Como os riscos são
gerenciados neste caso?
141
Proposições Dados coletados por fonte de evidência
a
Entrevistas Registros em arquivo Documentação
Proposição 4
Categorização de
Projetos
. 4a – Como os projetos são
categorizados?
. 4b – Como os projetos são
priorizados?
Proposição 5
Riscos em
Projetos de
Software
. 5a – Quais os principais riscos
dos projetos de software?
. 5b – Como são planejadas as
respostas aos riscos?
. 5c – Como os riscos são
monitorados?
Proposição 6
Lista de Riscos
. 6 – Como os riscos são
identificados?
Proposição 7
Sucesso em
Projetos
. 7 – Quais os critérios utilizados
para avaliar o sucesso do projeto?
Proposição 8
Visão Estratégica
de Riscos
. 8 – Como os riscos dos projetos
são apresentados aos executivos?
Nota. Fonte: elaborado pelo autor. a As fontes de evidência estão detalhadas na seção 3.3.2 – Fontes de evidências
3.2.5 Critérios para a Interpretação dos Achados do Estudo
Com relação aos critérios para interpretação dos achados, Yin (2010, p. 57) explica:
As análises estatísticas oferecem alguns critérios explícitos para essas interpretações. Por
exemplo, por convenção, a ciência social considera que um nível p menor do que 0,05
demonstra que as diferenças observadas eram “estatisticamente significativas”. Entretanto,
muitas análises de estudos de caso não contarão com o uso da estatística e, portanto, voltam a
atenção para outras maneiras de pensar sobre esses critérios.
Yin destaca que no estágio de projeto da pesquisa, o desafio é antecipar e enumerar os
rivais importantes, para que se incluam informações sobre eles como parte da coleta de dados.
“Se pensar sobre as explanações rivais somente após a coleta estar completa, começara a
justificar e projetar um estudo futuro, mas não ajudara a completar seu estudo de caso atual.”
(Yin, 2010, p. 57).
Podemos concluir que um projeto bem estruturado fornece uma base sólida para a coleta
de evidências de confiabilidade e validade dos achados da pesquisa, condição essencial para a
elaboração de um adequado estudo científico. Entretanto, a pesquisa de estudo de caso configura-
se como um dos tipos mais difíceis de pesquisa a serem realizados devido à ausência de
142
procedimentos de rotina (Yin, 2010). Os critérios para a interpretação dos achados serão
detalhados na seção 3.3 – Procedimentos de Coleta e Análise de Dados.
3.3 PROCEDIMENTOS DE COLETA E ANÁLISE DOS DADOS
Segundo Martins e Theóphilo (2009, p. 66), o protocolo é um instrumento que direciona
a condução da estratégia de pesquisa e é assim definido:
O ponto central do protocolo, que deve ser construído a partir do início do projeto, é um
conjunto de questões que, de fato, refletem a investigação real. As questões são feitas ao
próprio pesquisador e funcionam como um checklist para que o investigador fique atento e se
lembre de todas as ações para condução do trabalho, particularmente, no levantamento das
informações que precisam ser coletadas e as razões de coletá-las. As questões e prévios avisos
registrados no protocolo ajudam o pesquisador a se manter no rumo correto à medida que a
coleta avança. Cada questão deve vir acompanhada de uma lista de prováveis fontes de
evidências e do instrumento de coleta que poderá ser utilizado, como, por exemplo: nomes de
possíveis entrevistados, tipos de documentos a serem consultados, roteiros de entrevistas,
planilhas de coleta de dados etc.
De acordo com Yin (2010, p. 106), o protocolo deve conter as seguintes seções:
(1) Uma visão geral do projeto do estudo de caso: objetivos e patrocínios do projeto,
assuntos do estudo de caso e leituras relevantes sobre o tópico sendo investigado.
(2) Procedimentos de campo: apresentação de credenciais, acesso aos locais do estudo
de caso, linguagem pertencente à proteção dos participantes, fontes de dados e advertências de
procedimentos.
(3) Questões de estudo de caso: questões específicas de estudo de caso que o
investigador deve ter em mente na coleta de dados, estrutura das tabelas com título, cabeçalho e
categorias para séries específicas de dados e potenciais fontes de informação para responder a
cada questão.
(4) Um guia para o relatório do estudo de caso: esboço, formato para os dados, uso e
apresentação de outa documentação e informação bibliográfica.
Gil (2010) explica que o processo de coleta de dados no estudo de caso é mais complexo
que em outras modalidades de pesquisa, pois utiliza diferentes técnicas de obtenção dos dados de
forma complementar. Após a definição da unidade-caso e da determinação do número de casos a
143
serem pesquisados, recomenda-se a elaboração de um protocolo, que se constitui no documento
que não apenas contém o instrumento de coleta de dados, mas também define a conduta a ser
adotada para sua aplicação. O protocolo desenvolvido para este estudo foi organizado em cinco
seções: (1) etapas da pesquisa; (2) fontes de evidências; (3) caracterização da organização; (4)
procedimentos de coleta de dados; e (5) procedimentos de análise de dados.
3.3.1 Etapas da Pesquisa
A Figura 32 apresenta as etapas da pesquisa.
(1) Apresentação e problematização: introduz o tema, identifica e explicita os problemas
existentes.
(2) Questão de pesquisa, objetivos gerais e específicos: define a questão de pesquisa e os
objetivos do estudo.
(3) Relevância do tema e justificativa: explica a relevância do estudo e suas justificativas
apresentando quais suas contribuições à sociedade.
(4) Referencial teórico: revisão da teoria existente sobre o tema estudado. Sua revisão é
constante durante todo o desenvolvimento da dissertação.
(5) Premissa e proposições: são as reflexões sobre o referencial teórico e tem a função de
direcionar o escopo do estudo.
(6) Seleção da unidade de análise: descreve o objeto de análise delimitando as fronteiras
do estudo.
(7) Protocolo de pesquisa: descrição dos procedimentos que serão executados durante as
fases de coleta e análise de dados.
(8) Coleta e análise de dados: execução dos procedimentos definidos no protocolo,
podendo sofrer eventuais ajustes após a análise exploratória dos dados.
(9) Conclusões: conclusão do estudo e recomendação de temas para futuras pesquisas.
(10) Contribuições para a prática: descrição da aplicação prática dos achados do estudo.
144
(11) Publicação do estudo: aprovação do estudo e publicação para consulta futura de
outros pesquisadores.
Figura 32: Etapas da pesquisa.
Fonte: elaborado pelo autor.
3.3.2 Fontes de Evidências
O planejamento é fundamental para orientar a análise dos dados e evidências levantadas.
A confiabilidade de um estudo de caso poderá ser garantida pela utilização (triangulação) de
várias fontes de evidências, possibilitando um estilo corroborativo de pesquisa. Para isso o
pesquisador deve organizar um encadeamento de evidências, ou seja, demonstrar lógica e
sintonia entre os elementos do plano, da execução e das conclusões da pesquisa (Martins &
Theóphilo, 2009). Nesse sentido, este estudo foi fundamentado nas seguintes fontes de
evidências: entrevistas, registros em arquivos e documentação.
145
3.3.2.1 Entrevistas
Yin (2010, p. 133) explica o uso das entrevistas no estudo de caso:
Uma das fontes mais importantes de informação para o estudo de caso é a entrevista. [...] As
entrevistas são conversas guiadas, não investigações estruturadas. [...] Um tipo de entrevista de
estudo de caso é a entrevista em profundidade. Você pode perguntar aos respondentes-chave
sobre os fatos de um assunto, assim como suas opiniões sobre os eventos. A entrevista pode
ocorrer durante um longo período de tempo e não em uma única ocasião. O entrevistado
também pode sugerir outras pessoas para serem entrevistadas, assim como outras fontes de
evidência. [...] Um segundo tipo de entrevista de estudo de caso é a entrevista focada, na qual a
pessoa é entrevistada durante um curto período de tempo. Nesses casos, as entrevistas até
podem permanecer abertas e assumir uma maneira conversacional, mas é maior a probabilidade
de ser seguido um determinado conjunto de questões derivadas do protocolo do estudo de caso.
Por exemplo, uma finalidade importante dessa entrevista pode ser simplesmente a de corroborar
determinados fatos que você já considera estabelecidos. [...] Ainda um terceiro tipo de
entrevista acarreta questões mais estruturadas, na linha de um levantamento formal. Esse
levantamento poderia ser projetado como parte de um estudo de caso integrado e produzir
dados quantitativos como parte da evidência do estudo de caso. [...] mesmo ao relatarem esses
eventos ou explicarem como ocorreram, as respostas dos entrevistados estão sujeitas aos
problemas comuns de parcialidade, má lembrança e articulação pobre ou inexata.
Neste estudo será utilizado o tipo de entrevista focada, pois o objetivo das entrevistas é
confrontar os dados coletados por meio de registros em arquivos e documentações e
complementar a identificação do nível de sistematização do processo de gestão de riscos dentro
da organização analisada. Para aqueles projetos que não possuem registros de riscos cadastrados
na ferramenta de gestão integrada de tecnologia, busca-se identificar junto aos gerentes dos
projetos por que os riscos não são cadastrados e como é realizada a gestão de riscos neste cenário.
As questões para as entrevistas semiestruturadas estão alinhadas com as proposições e descritas
na seção 3.2.4 – Vinculação dos Dados às Proposições, adicionalmente, no Apêndice 1 encontra-
se o roteiro detalhado utilizado para coletar os dados.
De acordo com Sarker (2012), não existe um número recomendado de entrevistas a ser
realizado, porém sugere-se que o número de entrevistas seja reportado no estudo. Dessa maneira,
serão convidados inicialmente 20 colaboradores envolvidos com projetos de software da
instituição objeto de estudo. As entrevistas serão realizadas até ocorrer a saturação do tema, ou
seja, até o momento em que as respostas tornarem-se repetitivas e nenhum conhecimento
adicional for agregado. Se necessário, o número de entrevistados pode ser ampliado durante a
fase de análise e interpretação dos dados. Para permitir uma visão ampla e geral do processo de
gestão de riscos de projetos de software na instituição, serão entrevistados colaboradores com
diversas funções: gestores de programas (executivos); gestores de projetos; analistas de sistemas;
146
analistas do escritório de projetos; e o superintendente responsável pela priorização do portfólio
de projetos de tecnologia para entender especificamente qual o critério de priorização de projetos
adotado pela instituição.
3.3.2.2 Registros em Arquivos
Yin (2010, p. 132) explica o uso dos registros em arquivos no estudo de caso:
Para muitos estudos de caso, os registros de arquivo – que frequentemente tomam a forma de
arquivos e registros computadorizados – também podem ser relevantes. [...] Para alguns
estudos, os registros podem ser tão importantes que se tornam objeto de recuperação extensa e
de análise quantitativa. Em outros estudos, eles podem ser apenas de relevância passageira.
Quando a evidência de arquivo for considerada relevante, o investigador deve ter o cuidado de
confirmar as condições sob as quais ela foi produzida, assim como a sua exatidão. [...] A
maioria dos registros de arquivo é produzida para uma finalidade específica e para um público
específico que não a da investigação do estudo de caso, e essas condições devem ser avaliadas
na interpretação da utilidade e da exatidão desses registros.
A pesquisa documental utiliza fontes primárias de dados, tais como documentos e bases
de dados de entidades privadas, com o objetivo de contribuir para a análise dos problemas
(Martins & Theóphilo, 2009).
Uma das fontes de evidências deste estudo de caso são duas bases de dados extraídas
eletronicamente da ferramenta de gestão integrada de tecnologia da instituição estudada.
A Figura 33 apresenta uma amostra da base de dados de projetos que contém as
seguintes variáveis: Código do Projeto, Nome do Projeto, Data da Criação, Fase do Projeto,
Situação do Projeto, Data de Início Planejada, Data de Término Planejada, Quantidade de Horas
Planejadas, Data de Início Realizada, Data de Término Realizada, Quantidade de Horas
Realizadas, Percentual Realizado, Indicador de Risco, CPI (Cost Performance Index) e SPI
(Schedule Performance Index).
A base de dados de riscos contém as seguintes variáveis: Número da Solicitação do
Risco, Código do Projeto Relacionado, Responsável pelo Cadastramento do Risco, Data de
Cadastramento do Risco, Descrição do Risco, Semáforo do Risco (verde, amarelo ou vermelho),
Probabilidade de Ocorrência do Risco, Impacto do Risco, Índice de Exposição ao Risco, Status
do Risco, Estratégia de Resposta ao Risco, Solução Proposta, Plano de Contingência, Data do
Gatilho do Risco, Data para Solução, e Responsável pelo Monitoramento do Risco.
147
Figura 33: Amostra da base de dados de projetos.
Fonte: relatório da ferramenta de gestão integrada de tecnologia do Banco Alfa.
3.3.2.3 Documentação
Yin (2010, p. 128) explica o uso da documentação no estudo de caso:
A informação documental é, provavelmente, relevante para todos os tópicos de estudo de caso.
Esse tipo de informação pode tomar várias formas e deve ser o objeto de planos explícitos de
coleta de dados. Por exemplo, considere a seguinte variedade de documentos: correspondência
eletrônica, minutas de reuniões, documentos administrativos, estudos formais do mesmo “local”
que está estudando e notícias que aparecem na mídia. [...] Os documentos são úteis mesmo que
não sejam sempre precisos e possam apresentar parcialidades. [...] Para os estudos de caso, o
uso mais importante dos documentos é para corroborar e aumentar a evidência de outras fontes.
[...] providenciar acesso para examinar os arquivos de qualquer organização sendo estudada [...]
muitas pessoas criticam a potencial confiança excessiva nos documentos na pesquisa de estudo
de caso. Isto ocorre provavelmente porque o pesquisador casual presume, erradamente, que
todos os tipos de documentos – inclusive as propostas para projetos ou programas – contêm a
verdade indubitável. [...] Devido à abundância de materiais disponíveis é importante focar a
informação mais pertinente. Uma sugestão seria separar ou realizar a triagem dos materiais de
acordo com sua aparente centralidade à investigação. Depois, passar mais tempo lendo ou
revisando o que parece central e eliminando outros materiais menos importantes, para uma
leitura ou revisão posterior.
Utiliza-se neste estudo documentos dos projetos e dos processos organizacionais.
Algumas informações dos projetos não podem ser extraídas eletronicamente, pois são
informações descritivas (desestruturadas) que estão armazenadas em documentos no formato
word, excel, power point e pdf. Os principais documentos dos projetos que estão neste formato
são: requisitos, mapa de stakeholders, cronogramas, atas de reuniões e boletins. Com relação aos
processos organizacionais, buscam-se os documentos relacionados aos processos da metodologia
148
de gestão de projetos e riscos, processos da metodologia de desenvolvimento de software e
governança de TI. Estes documentos servem para entender como os processos de gestão de
projetos e riscos são disseminados na organização, além de permitir aprofundar as informações
de determinados projetos quando necessário. Também são fontes de evidências para este estudo
as informações disponibilizadas na internet e intranet desta organização.
3.3.3 Caracterização da Organização
A organização não autorizou a divulgação de seu nome, sendo assim, será referenciada
neste estudo como Banco Alfa.
O estudo foi realizado em uma empresa privada, multinacional de capital nacional
presente em 22 países além do Brasil, atuante no setor bancário de varejo e atacado desde 1943,
possui atualmente mais de 90.000 colaboradores, valor de mercado estimado em US$ 81 bilhões
e conta com 5.000 agências e PABs no Brasil e exterior.
A área de tecnologia do Banco Alfa possui investimentos previstos no valor de R$ 11,1
bilhões entre 2012 e 2015, conta com aproximadamente 6.000 colaboradores, um Escritório de
Projetos de Tecnologia implantado e uma Área de Metodologia e Qualidade de Software que
determina os padrões de processo a serem seguidos pelas equipes de desenvolvimento de
software. As metodologias de desenvolvimento de software disponíveis tanto para as equipes de
desenvolvimento internas quanto externas é o Scrum e o Modelo V.
3.3.4 Procedimentos de Coleta de Dados
Yin (2010, p. 141) explica que o processo de coleta de dados para o estudo de caso é
mais complexo do que os usados nos outros métodos de pesquisa e explica três princípios que,
quando usados apropriadamente, podem ajudar a tratar dos problemas de estabelecimento da
validade do constructo e da confiabilidade da evidência do estudo de caso:
(1) Usar múltiplas fontes de evidência: o uso de apenas uma fonte de evidência não é
recomendado para a condução de um estudo de caso, pois a triangulação de dados originados de
149
diversas fontes é um dos pontos fortes desse método. Ao utilizar múltiplas fontes de evidência o
pesquisador aborda uma variação maior de aspectos históricos e comportamentais e consegue
desenvolver um processo corroborativo de linhas convergentes de investigação.
(2) Criar um banco de dados do estudo de caso: os dados coletados foram organizados e
documentados de forma que sejam facilmente recuperáveis. A falta de um banco de dados formal
é um defeito que precisa ser corrigido, pois uma base de dados aumenta notavelmente a
confiabilidade de todo o estudo de caso. Os quatro componentes que compõem a base
comprobatória de dados são: notas – anotações do pesquisador resultantes de entrevistas ou
análise de documentos; documentos – materiais utilizados para análise que devem ser
armazenados e indexados por uma bibliografia comentada; tabelas – dados quantitativos que
podem ser armazenados em arquivos computadorizados; e as narrativas – gravações ou atas das
entrevistas.
(3) Manter o encadeamento das evidências: permite que um observador externo siga a
derivação de qualquer evidência das questões de pesquisa iniciais para finalizar as conclusões do
estudo de caso, ou seja, deve ser possível relacionar as conclusões às questões iniciais de
pesquisa ou vice versa, conforme apresentado na Figura 34.
Figura 34: Encadeamento de evidências.
Fonte: adaptado de Yin, 2010.
Com relação aos registros em arquivos, a extração será realizada por meio dos relatórios
existentes na ferramenta de gestão integrada de tecnologia que permitem exportar os dados
selecionados para planilhas. Com relação as evidências documentais, estas serão coletadas
diretamente da intranet da organização, da ferramenta de gestão integrada de tecnologia, ou
150
recebidas dos entrevistados. As entrevistas foram realizadas pessoalmente no pólo administrativo
de trabalho dos entrevistados em São Paulo em uma sala de reuniões. Quando permitido, as
entrevistas foram gravadas em áudio, caso contrário haverá mais um participante colaborador do
autor para registrar a entrevista em uma ata de reunião.
3.3.5 Procedimentos de Análises de Dados
Como não há um roteiro para se analisar os resultados de um estudo de caso,
recomenda-se que a maior parte da avaliação e análise de dados seja realizada paralelamente ao
trabalho de coleta (Martins & Theóphilo, 2009).
Martins e Theóphilo (2009, p. 69) comentam o processo de análise dos dados:
De modo geral, a análise de dados consiste em examinar, classificar e, muito frequentemente,
categorizar os dados, opiniões e informações coletadas, ou seja, a partir das proposições, teoria
preliminar e resultados encontrados, construir uma teoria que ajude a explicar o fenômeno sob
estudo. O uso de técnicas quantitativas – estatísticas – é menos frequente. Não se deve também
esquecer o uso do material bibliográfico e de outras naturezas que compõem a plataforma
teórica do estudo, para sustentar análises, comentários, classificações, categorizações,
teorizações e conclusões.
A análise de um Estudo de Caso deve deixar claro que todas as evidências relevantes foram
abordadas e deram sustentação às proposições que parametrizaram toda a investigação. A
qualidade das análises será notada pelo tratamento e discussão das principais interpretações
concorrentes, bem como pela exposição dos aspectos mais significativos do caso sob estudo e
de possíveis laços com outras pesquisas assemelhadas.
De acordo com Yin (2010, p. 154) “a análise dos dados consiste no exame, na
categorização, na tabulação, no teste ou nas evidências recombinadas de outra forma, para tirar
conclusões baseadas empiricamente”. O procedimento de análise deve deixar claro que todas as
evidências relevantes foram abordadas dando sustentação às proposições que parametrizaram a
investigação. A qualidade das análises realizadas será notada pelo tratamento e discussão das
principais interpretações – linhas de argumentação concorrentes, bem como pela exposição dos
aspectos mais significativos do caso (Martins & Theóphilo, 2009).
Adicionalmente, Yin (2010) aponta quatro estratégias para tratar evidências de forma
imparcial com produção de conclusões analíticas robustas e explica que as estratégias não são
mutuamente exclusivas, podendo ser combinadas entre si:
151
(1) Proposições teóricas: proposições que embasaram os objetivos originais, refletindo
um conjunto de questões de pesquisa, revisões da literatura e novas proposições e/ou hipóteses.
(2) Desenvolvimento da descrição do caso: desenvolvimento de uma estrutura teórica
para a organização do estudo de caso, sem a definição de proposições teóricas iniciais.
(3) Uso de dados qualitativos e quantitativos: mesmo com o foco principal do estudo de
caso na análise qualitativa a inclusão de dados submetidos a análises estatísticas fortalecem a
estratégia analítica.
(4) Explanações rivais: tenta definir e testar explanações de hipóteses rivais, estruturas
descritivas rivais ou condições rivais a serem examinadas.
Neste estudo, a estratégia analítica geral utilizada foi a de proposições teóricas
combinada com o uso de dados qualitativos e quantitativos. A estrutura da pesquisa está aderente
a uma ligação entre a questão de pesquisa, a revisão bibliográfica, o estabelecimento de
premissas e a definição das proposições teóricas do estudo. Além disso, será utilizada uma base
com dados quantitativos fortalecendo assim a análise dos dados.
Além das estratégias para análise dos dados, Yin (2010, p. 164) define cinco técnicas
analíticas destacando que “nenhuma das técnicas analíticas deve ser considerada fácil de usar e
todas necessitarão de muita prática para serem utilizadas com eficácia.” No entanto, sua prática
culminará com estudos de casos robustos e de qualidade. São elas:
(1) Combinação de padrão: compara um padrão baseado empiricamente com um padrão
previsto, ou vários padrões alternativos.
(2) Construção da explanação: os dados do estudo de caso são analisados e uma
explanação sobre o caso é construída.
(3) Análise de séries temporais: condução de uma análise de séries temporais.
(4) Modelos lógicos: técnica analítica que consiste em combinar eventos empiricamente
observados com eventos teoricamente previstos.
(5) Síntese cruzada dos casos: análise realizada pelo cruzamento das descobertas entre
vários casos.
152
Considerando que as proposições foram elaboradas com base em eventos teoricamente
previstos, este estudo utilizará a técnica de modelos lógicos do nível organizacional, pois será
proposto um modelo de gestão de riscos para melhorar um processo observado na organização.
3.4 LIMITAÇÕES DA PESQUISA
Martins e Theóphilo (2009, p. 62) explicam as limitações do método estudo de caso:
Uma das maiores limitações da estratégia de pesquisa de um Estudo de Caso é a possibilidade
de contaminação do estudo pelas “respostas do pesquisador”, isto é, a forte possibilidade de o
pesquisador ter uma falsa sensação de certeza sobre suas próprias conclusões. Como o
pesquisador, em geral, conhece profundamente o fenômeno em estudo, ou melhor, pensa que o
conhece totalmente, poderá, deliberadamente, enviesar os dados e evidências de forma a
comprovar suas pressuposições iniciais. Reforçando: um dos maiores riscos da condução de um
Estudo de Caso é utilizar a investigação para comprovar posições preconcebidas.
Eisenhardt (1989, p. 547) descreve as fraquezas da construção de teorias a partir de
estudos de casos:
Algumas características consideradas como pontos fortes na construção de uma teoria a partir
de estudos de casos também podem ser consideradas pontos fracos. Por exemplo, o uso
intensivo de evidência empírica pode gerar uma teoria que é excessivamente complexa. A
referência para uma teoria adequada é a parcimônia, mas dado o volume normalmente
impressionante de dados, há uma tentação de construir uma teoria que tenta capturar tudo. [...]
Outro ponto fraco é que a construção de uma teoria a partir de estudos de casos pode resultar
em uma teoria estreita e idiossincrática, pois trata-se de uma abordagem de baixo para cima de
modo que as especificidades de dados produzam as generalizações da teoria. Os riscos são de
que a teoria descreva um fenômeno muito peculiar ou que o pesquisador seja incapaz de elevar
o nível de generalidade da teoria (tradução livre). 13
Os principais fatores limitantes para este estudo são:
– Utilização dos dados de apenas uma empresa do setor bancário, dificultando a
generalização do modelo para empresas de outros setores;
– Restrição de recursos disponível para a coleta de dados (somente o autor);
13
Some characteristics that lead to strengths in theory building from case studies also lead to weaknesses. For
example, the intensive use of empirical evidence can yield theory which is overly complex. A hallmark of good
theory is parsimony, but given the typically staggering volume of rich data, there is a temptation to build theory
which tries to capture everything. […] Another weakness is that building theory from cases may result in narrow and
idiosyncratic theory. Case study theory building is a bottom up approach such that the specifics of data produce the
generalizations of theory. The risks are that the theory describes a very idiosyncratic phenomenon or that the theorist
is unable to raise the level of generality of the theory.
153
– A base de dados dos riscos dos projetos de software da organização não possui
categorização, sendo necessário interpretar individualmente a descrição dos riscos para conseguir
categorizar conforme o catálogo de riscos da TBRI;
– Restrição do tempo disponível para o desenvolvimento e conclusão do estudo,
conforme cronograma apresentado na Figura 35.
Figura 35: Cronograma de atividades para desenvolvimento da dissertação.
Fonte: elaborado pelo autor.
154
4 ANÁLISE E INTERPRETAÇÃO DOS RESULTADOS
Conforme definido na metodologia, foram realizadas entrevistas semiestruturadas com
profissionais da instituição, análise de evidências documentais e análise das bases de dados de
projetos com o objetivo de responder a questão de pesquisa: “Como deve ser estruturado um
modelo de gestão de riscos que seja aplicável a projetos de software no setor bancário
brasileiro?”.
O estudo de caso único foi utilizado para buscar respostas à questão de pesquisa. Com
base em evidências obtidas com a revisão bibliográfica o estudo buscou descobrir por meio de
observações empíricas a experiência de especialistas em projetos de software envolvendo a
gestão de riscos. Este capítulo está estruturado em:
– Coleta de Dados: explica como as entrevistas foram realizadas, como as bases de
dados foram extraídas e como as evidências documentais foram obtidas;
– Análise das Proposições: contém os dados organizados e interpretados de acordo com
as premissas estabelecidas para este estudo, e ao final verifica se as proposições foram atendidas,
atendidas parcialmente ou não atendidas face às práticas encontradas na organização.
4.1 COLETA DE DADOS
As entrevistas foram agendadas em Ago-14 e as entrevistas realizadas no período de Set-
14 a Out-14. A extração eletrônica de dados foi realizada no dia 07/09/14 e a evidências
documentais foram coletadas ao longo do período de análise e interpretação dos dados.
Todos os entrevistados trabalham na Área de Tecnologia da Informação da organização
estudada, possuem mais de dez anos de experiência profissional e estão diretamente envolvidos
com projetos de software. O questionário foi enviado previamente para os entrevistados para
permitir reflexão prévia sobre o assunto e garantir uma reunião eficiente e produtiva.
155
Segundo Martins e Theóphilo (2009) o uso de gravador pode ser utilizado quando
houver aquiescência do entrevistado, sendo assim, a entrevista realizada com o Gerente e
Superintendente da Área de Planejamento de Demandas foi gravada em áudio e todas as demais,
por solicitação dos entrevistados, foram redigidas. Para evitar a perda de detalhes importantes do
depoimento do entrevistado as reuniões contaram com a participação de um colaborador do
pesquisador para registrar a entrevista em uma ata de reunião. As atas foram compartilhadas via
e-mail com os entrevistados para validação e complemento.
Para tornar a apresentação das informações extraídas da entrevista num formato mais
objetivo e lógico, somente os trechos mais significativos foram transcritos para este estudo. Além
disso, de modo a preservar o anonimato dos entrevistados e da organização analisada, houve a
supressão dos nomes dos entrevistados nas transcrições.
A Tabela 29 apresenta o perfil dos entrevistados e dados das entrevistas.
Tabela 29: Perfil dos entrevistados e dados das entrevistas.
Entrevistado Função
Data e hora
da entrevista Ambiente da entrevista
# Sigla
1 AC Gestor de Projetos 01/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
2 PJ Auditor de Projetos 01/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
3 AF Gestor de Projetos 03/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
4 SR Gestor de Projetos 03/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
5 AS Gestor de Programa 04/09/2014
07:30
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
6 RC PMO de Programa 04/09/2014
17:30
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
7 RS Gestor de Projetos 05/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
8 CT Gestor de Projetos 05/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
9 LB Coordenador da Área
de Qualidade
08/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
156
Entrevistado
Função Data e hora
da entrevista Ambiente da entrevista
# Sigla
10 EO Analista de Sistemas
Sênior
08/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
11 DB Analista de Sistemas
Sênior
10/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
12 LS Analista de Sistemas
Sênior
10/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
13 RM Gestor de Programa 12/09/2014
08:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
14 DM Analista de Sistemas
Sênior
12/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
15 FS Analista de Sistemas
Sênior
15/09/2014
09:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
16 FT Analista de Sistemas
Sênior
15/09/2014
10:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista.
17 TS
Gerente de
Planejamento de
Demandas 16/09/2014
18:00
A entrevista foi realizada em São Paulo em uma pequena
sala de reuniões da empresa. O ambiente demonstrou-se
neutro e adequado para a entrevista. O gerente e
superintendente solicitaram realizar a entrevista em
conjunto. 18 PM
Superintendente de
Planejamento de
Demandas
Nota. Fonte: elaborado pelo autor.
Também foram convidados outros dois colaboradores para participação no estudo.
Porém não foi possível conciliar a agenda em data hábil para inclusão neste estudo.
A extração eletrônica foi realizada pela área de Planejamento de Demandas que é
responsável pela manutenção da ferramenta de gestão integrada de tecnologia. Foram extraídas
duas bases de dados: (1) base de dados com 19.225 projetos cadastrados no período de 01/01/12 a
31/08/14, nas situações ativo, cancelado, suspenso e concluído; e (2) base de dados com 1.540
riscos cadastrados no período de 01/06/12 a 31/08/14.
Com relação às evidências documentais, os templates e documentos utilizados neste
estudo foram obtidos na intranet, junto aos entrevistados ou capturados diretamente na ferramenta
de gestão integrada de tecnologia da organização.
157
4.2 ANÁLISE DAS PROPOSIÇÕES
Segundo Yin (2010, p. 50), a questão de pesquisa isoladamente não aponta o caminho
que deve ser estudado, por isso é necessário que o pesquisador organize seus estudos
bibliográficos e elabore proposições, pois dessa forma é possível refletir sobre o conteúdo
teórico e sugerir uma direção para o estudo.
Sendo assim, após a formulação da questão de pesquisa e a partir da revisão
bibliográfica e objetivos específicos da pesquisa, foram formuladas premissas e proposições
associadas, de forma a propor um modelo acerca da problematização da pesquisa. Foram
elaboradas três premissas e oito proposições para guiar este estudo durante a fase de análise e
interpretação dos dados, os quais foram coletados a partir das entrevistas, evidências documentais
e bases de dados.
Uma vez determinada a lógica de análise, a estrutura utilizada para efetuar o cruzamento
das informações colhidas na empresa com base na aplicação do protocolo de pesquisa segue a
seguinte ordenação:
a) Apresentação da proposição de estudo;
b) Apresentação das questões expostas aos entrevistados;
c) Relato das informações colhidas em pesquisa de campo;
d) Análise das evidências documentais relacionadas à proposição;
e) Análise das informações extraídas das bases de dados de projetos;
f) Interpretação dos dados, incluindo a citação de eventuais novos conceitos não
relacionados anteriormente;
g) Verificação da proposição com base nas práticas encontradas na organização
(atendida, atendida parcialmente ou não atendida).
158
4.2.1 Premissa 1
Com base nos objetivos principal e específicos deste estudo foi elaborada a seguinte
premissa 1: “Definir os critérios necessários para agrupar os riscos identificados e
armazenados em bases históricas de projetos de software”.
4.2.1.1 Proposição 1
Para atender a premissa 1 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 1: “O registro de riscos, quando adequadamente utilizado, é uma importante
ferramenta para a gestão de riscos. Constitui a base histórica dos riscos e planos de ações
identificados e analisados durante o projeto e permite gerar um catálogo de riscos para a
organização”.
Para entender como os riscos de projetos de software são organizados e armazenados na
instituição, durante as entrevistas foi realizada a seguinte pergunta: “1 – Como os riscos de
projetos são documentados na organização?”. As respostas a esta pergunta são apresentadas na
Tabela 30, juntamente com as demais perguntas realizadas no decorrer da entrevista.
Tabela 30: Respostas à pergunta 1.
Entrevistado Resposta
# Sigla
1 AC
Na nossa equipe os riscos de projetos são documentados no mapa de riscos utilizando o template
padrão da metodologia de gestão de projetos.
Entrevistador: E onde vocês armazenam o mapa de riscos? Por que não utilizam a funcionalidade
de gestão de riscos disponível na ferramenta de gestão integrada de tecnologia?
Nós armazenamos o mapa de riscos na pasta da rede do projeto. Como este não é um item
obrigatório da ferramenta de gestão integrada de tecnologia, preferimos utilizar uma planilha,
pois dessa forma conseguimos reaproveitar os documentos dos projetos anteriores. Para falar a
verdade, não sei como reaproveitar os riscos dos projetos anteriores na ferramenta de gestão
integrada de tecnologia, talvez esta funcionalidade exista, mas nunca me informei. Foi boa esta
nossa conversa, vou me informar melhor sobre como utilizar a ferramenta de gestão de riscos.
159
Entrevistado
Resposta # Sigla
2 PJ
Nos projetos que audito não vejo um padrão com relação aos documentos de riscos. Algumas
áreas elaboram uma planilha bem detalhada com os riscos e atualizam este documento de forma
periódica. Outras áreas não possuem nenhum tipo de documentação de riscos do projeto. Tem
também aquelas áreas que apresentam os riscos de forma macro e nunca atualizam e quando
auditamos esses projetos, os responsáveis dizem que preenchem apenas para respeitar a
documentação obrigatória exigida pela metodologia, mas assumem que não fazem uma gestão
efetiva de riscos. Apesar disso, tenho percebido que no decorrer deste ano, cada vez mais
encontramos casos de sucesso onde os riscos são corretamente armazenados e gerenciados pela
ferramenta de gestão integrada de tecnologia. Resumindo, apesar da metodologia de gestão de
projetos orientar o preenchimento do registro de riscos na ferramenta de gestão integrada de
tecnologia, ainda encontramos falta de aderência a esta diretriz em diversos projetos, mas minha
percepção é que este cenário vem melhorando.
3 AF
Eu utilizo a ferramenta de gestão integrada de tecnologia para armazenar os riscos dos projetos,
pois é a orientação da metodologia de gestão de projetos. Antigamente utilizava o template padrão
em planilha, mas atualmente, quando você consulta o manual da metodologia, verá que o template
não está mais disponível e a área de metodologia recomenda o uso da ferramenta de gestão
integrada de tecnologia.
4 SR
Utilizo planilhas para documentar os riscos.
Entrevistador: E onde você armazena essas planilhas? Por que não utiliza a funcionalidade de
gestão de riscos disponível na ferramenta de gestão integrada de tecnologia?
No meu caso eu trabalho com projetos pequenos de até 500 horas e de curta duração, entre um e
três meses. Por isso entendo que não é necessário documentar os riscos dos projetos. Por meio de
boletins semanais eu consigo controlar os riscos, pois no final do boletim tenho uma lista de
pendências.
5 AS
Os riscos dos projetos são descritos em documentos específicos da metodologia de gestão de
projetos. Podem ser utilizadas planilhas ou a própria ferramenta de gestão integrada de
tecnologia.
6 RC
A gente utiliza a ferramenta SAP Solution Manager®
que faz todo o controle do projeto,
mapeamento dos processos e depois, controle daquilo que será desenvolvido e testado. Esta
ferramenta tem um módulo específico para controle de riscos e issues e funciona da seguinte
forma... imagine que alguém da equipe identifique um novo risco ou issue, o líder dessa frente faz
o cadastro na ferramenta com o máximo possível de detalhes, identifica o responsável, a
probabilidade e impacto do risco ou issue para que a ferramenta calcule a criticidade. Ao final do
cadastramento, quando o líder submete, a ferramenta armazena e notifica o responsável pela ação
enviando um e-mail. O responsável analisa e monitora esse risco. Quando o responsável finaliza o
tratamento e encerra o risco/issue, quem abriu o registro é notificado e somente esta pessoa pode
autorizar o encerramento do risco. Dessa forma garantimos que a pessoa que abriu o
risco/problema/issue está satisfeita com a resolução.
7 RS
Eu particularmente utilizo a ferramenta de gestão integrada de tecnologia para armazenar os
riscos, mas aqui na equipe algumas pessoas ainda utilizam os templates antigos da metodologia de
gestão de projetos.
8 CT Não sei responder como são armazenados na organização, mas aqui na nossa área temos o hábito
de utilizar diretamente o registro de riscos na ferramenta de gestão integrada de tecnologia.
9 LB
A orientação é documentar os riscos na ferramenta de gestão integrada de tecnologia utilizando o
registro de controle de riscos onde é cadastrada a descrição do risco, a data de identificação, o
plano de resposta, a data limite para o plano de resposta e os aprovadores do plano, juntamente
com o fechamento do risco após a eliminação do mesmo.
160
Entrevistado
Resposta # Sigla
10 EO
Interessante esta pergunta, pois justamente no mês passado fiz o treinamento da metodologia de
gestão de projetos e aprendi a utilizar a ferramenta de registro de riscos da ferramenta de gestão
integrada de tecnologia. Eu tenho o hábito de fazer a gestão de riscos no próprio boletim de
projetos, mas agora que fiz o curso, vou começar a utilizar a ferramenta de gestão integrada de
tecnologia.
11 DB
Os riscos não documentados na nossa área. Eventualmente uma ata de alguma reunião de
fechamento ou de homologação contém algum ponto referente a um risco encontrado e tratado,
mas não existe uma base ou registro específico.
Entrevistador: Você entende que o fato de não documentarem os riscos pode impactar o bom
andamento do projeto?
Para ser sincero entendo que não impacta. Como nossa área tem a cultura de gerenciar
problemas e pendências e não documentar riscos, nós geralmente ―apagamos incêndios‖ quando
os problemas aparecem. Mas também tem o outro lado da moeda, não gastamos tempo
procurando por problemas antes que eles aconteçam. Sinceramente não sei dizer se o fato de
tratar as incertezas com antecedência evitaria alguns problemas, tenho minhas dúvidas.
12 LS Os riscos devem ser reportados na documentação do projeto e apresentados à área solicitante,
principalmente durante a fase de elaboração e desenho da solução.
13 RM
Os riscos são documentados na matriz de riscos. Como os projetos que gerencio são em sua
maioria terceirizados, cada fornecedor tem uma planilha diferente para gerenciar os riscos e
pendências do projeto. Na verdade não acompanho onde os documentos são armazenados, mas
nos comitês de evolução dos projetos exijo que os riscos e pendências façam parte da reunião e o
histórico destas pendências seja apresentado enquanto não é solucionado.
14 DM
Os riscos são colocados em planilhas e ―esquecidos‖ na rede. Ainda não vi nenhum projeto com
os riscos identificados na ferramenta de gestão integrada de tecnologia. Onde possam ser
discutidos em um fórum e avaliadas se as respostas realmente são eficientes.
15 FS Os riscos são documentados nos reportes do PMO e apresentados nos comitês dos projetos onde
estão presentes representantes de todas as frentes dos projetos.
16 FT Os riscos, juntamente com as pendências dos projetos são documentados em reportes
disponibilizados e acompanhados em comitês pelo PMO.
Nota. Fonte: elaborado pelo autor.
Com base nas entrevistas foi possível identificar as diretrizes da organização
relacionadas à documentação dos riscos nos projetos de software e também como esses
documentos são utilizados na prática pelas equipes dos projetos. A diretriz atual indica que deve
ser utiliza a ferramenta de gestão integrada de tecnologia (Changepoint da Compuware) para o
registro de riscos, porém como a organização vem passando por um período de aculturamento no
uso da ferramenta, algumas vezes ainda são utilizados outros tipos de documentos.
Segundo os entrevistados, algumas justificativas para a falta de aderência total às
diretrizes da organização são:
– Falta de obrigatoriedade do uso do registro de riscos da ferramenta de gestão integrada
de tecnologia;
161
– Utilização de templates antigos da metodologia de gestão de projetos;
– Em projetos pequenos os riscos são documentados e gerenciados diretamente no
boletim de evolução semanal do projeto, juntamente com os problemas e pendências;
– Ausência de auditoria de qualidade dos documentos exigidos pela metodologia de
gestão de projetos com caráter punitivo;
– Em projetos terceirizados são utilizados os templates dos fornecedores;
– Em projetos acompanhados pelo escritório de projetos, os riscos são documentados
diretamente nas fichas de reporte do projeto que são apresentadas nos comitês;
– Para projetos concluídos, cancelados e suspensos, a ferramenta de gestão integrada de
tecnologia não permite consultar o histórico de riscos do projeto, ou seja, não é possível
reaproveitar as lições aprendidas no processo de identificação de riscos dos novos projetos.
Figura 36: Atividades do processo Identificar e Analisar Riscos.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
162
A Figura 36 apresenta as principais atividades envolvidas no processo de Identificar e
Analisar Riscos de acordo com o manual da metodologia de gestão de projetos, com destaque
para o artefato de saída que é o Registro dos Riscos. A responsabilidade pela elaboração da lista
de riscos é do gestor de projetos que deve envolver a equipe e os demais stakeholders do projeto
neste processo. Os principais insumos para o processo são a lista de stakeholders e os requisitos
do projeto já contemplando a solução técnica e suas principais entregas, pois dessa forma é
possível dimensionar o tamanho e complexidade do projeto que são importantes para determinar
o nível de risco.
Ao término desta etapa cada um dos riscos registrados terá um responsável pelo
acompanhamento, sua probabilidade e impacto avaliados, seu potencial de exposição calculado e
o plano de resposta elaborado.
Figura 37: Como cadastrar um novo risco.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
Observa-se na Figura 37 as orientações de preenchimento dos novos riscos na
ferramenta de gestão integrada de tecnologia, ou seja, o repositório oficial para registro dos riscos
de projetos de software da instituição. Apesar da figura não apresentar a totalidade dos campos
163
necessários para o cadastro do risco, fica evidente que a diretriz da organização é utilizar a
ferramenta de gestão integrada de tecnologia e não planilhas auxiliares. Cada um dos riscos
registrados na ferramenta é identificado por um código único associado ao projeto e ao sistema
aplicativo, também é permitido avaliar sua criticidade e até mesmo anexar documentos que
suportem a análise e plano de ação.
Entretanto, dada a dimensão da instituição, observou-se que não existe aderência
completa às diretrizes corporativas, uma vez que algumas áreas não utilizam a ferramenta de
gestão integrada de tecnologia como repositório oficial do registro de riscos dos projetos de
software. Além do registro de riscos oficial, observou-se que, para documentar os riscos dos
projetos, também são utilizados documentos de fornecedores, documentos antigos da
metodologia de gestão de projetos ou o próprio boletim de comunicação do projeto.
A Figura 38 apresenta um exemplo de template antigo da metodologia de gestão de
projetos preenchido e que era utilizado pela instituição antes da implantação da ferramenta de
gestão integrada de tecnologia. São duas planilhas separadas, porém interdependentes.
Figura 38: Exemplo de registro de riscos utilizando template antigo da metodologia.
Fonte: entrevistado número 7 – RS.
164
A primeira planilha é a Lista de Riscos. Nesta planilha se identifica o projeto, o gestor, a
descrição do risco, a avaliação da probabilidade de ocorrência (alta, média e baixa) e impacto
(alto, médio e baixo). A planilha calcula automaticamente a exposição ao risco por meio de uma
fórmula previamente configurada (baixa, alta, média ou crítica). Também possui um campo de
status (aberto, fechado pendente de aprovação e fechado), motivo de fechamento (eliminado,
confirmado e expirado) e espaço para comentários adicionais.
A segunda planilha é o Plano de Resposta a Riscos. Nesta planilha também se identifica
o projeto, o gestor e novamente a descrição do risco. As possíveis estratégias de resposta aos
riscos estão alinhadas aos conceitos descritos no PMBOK que são: aceitar, eliminar, mitigar ou
transferir. Também possui um campo para a descrição da solução proposta, o nome do
responsável e a data limite para implantação do plano de ação.
Figura 39: Exemplo de boletim de projetos.
Fonte: entrevistado número 4 – SR.
165
A Figura 39 apresenta um exemplo de boletim de projetos preenchido que é utilizado em
projetos de pequeno porte. Trata-se de uma planilha que possui diversas finalidades: (1)
comunicar o desempenho do projeto; (2) controlar a evolução do cronograma; (3) monitorar a
quantidade de replanejamentos; e (4) documentar e monitorar o andamento dos riscos, problemas
e pendências.
Mais especificamente com relação ao registro de riscos que é o foco dessa análise,
observa-se que é possível descrever o risco/problema/pendência, identificar seu status por meio
de um semáforo (alerta crítico, alerta, sob controle, não iniciado e finalizado), e cadastrar a data
de início real e data de conclusão real. Além disso, permite descrever o plano de ação, determinar
o responsável e a data limite para execução do plano.
O gráfico da Figura 40 apresenta a evolução da quantidade de projetos cadastrados na
ferramenta de gestão integrada de tecnologia ao longo do período de Jan-12 a Ago-14 sem
considerar o porte do projeto, ou seja, são projetos pequenos, médios ou grandes analisados de
forma conjunta que totalizam 19.225 projetos com 14,6 milhões de horas/homem de trabalho
previstas. Todos os projetos de software da organização criados neste período estão contidos
nessa análise, pois tal ferramenta funciona como controle corporativo garantindo que somente os
projetos aprovados são executados pela equipe de tecnologia.
Figura 40: Projetos cadastrados.
Fonte: elaborado pelo autor.
166
Figura 41: Riscos cadastrados.
Fonte: elaborado pelo autor.
O gráfico da Figura 41 apresenta a evolução da quantidade de riscos cadastrados ao
longo do período de Jun-12 a Ago-14 também desconsiderando as características de seus projetos
associados. O número de riscos registrados é inferior ao número de projetos cadastrados, pois
como foi identificado nas entrevistas, existem outras fontes de registro de riscos de projetos de
software que estão armazenados de forma descentralizada pela rede da organização e não foi
possível sua captura para análise nesse estudo. A base de dados analisada possui 1.540 riscos.
Segundo a percepção de alguns entrevistados, o uso da ferramenta de gestão integrada
de tecnologia se intensificou em 2014. Essa percepção é corroborada ao analisar conjuntamente
os gráficos das Figura 40 e Figura 41, pois percebe-se que, apesar do número de cadastramento
de novos projetos apresentar uma linha de tendência estável no período de Jan-12 a Ago-14 (linha
azul da Figura 40), mais de 70% dos riscos cadastrados na ferramenta ocorreu nos oito primeiros
meses de 2014 (linha verde da Figura 41) com uma linha de tendência de crescimento
exponencial (linha azul da Figura 41). A partir dessa leitura pode-se interpretar que o uso da
ferramenta se intensificou em 2014.
167
Porém, ao analisar o gráfico da Figura 42 que desconsidera os projetos suspensos,
cancelados e concluídos que não possuem riscos cadastrados, a interpretação é diferente. Ao
analisar somente os projetos ativos com registro de riscos associados, percebe-se que em Jan-14 e
Fev-14 houve o uso intenso do registro de riscos na ferramenta de gestão de tecnologia, porém
essa tendência não se manteve ao longo dos demais meses de 2014. Sendo assim, pode-se inferir
que a percepção dos entrevistados de que o uso da ferramenta intensificou-se é verdadeiro
somente para um período específico de dois meses em 2014. Ou seja, a partir de Mar-14, a
melhora significativa no uso da ferramenta voltou ao mesmo patamar de 2013, demonstrando que
a mudança de cultura dos profissionais, no que tange à documentação de riscos de projetos de
software, não se sustentou.
Figura 42: Projetos ativos que possuem registro de riscos.
Fonte: elaborado pelo autor.
Observa-se que a proposição 1 foi atendida face às práticas encontradas na organização.
A análise e interpretação dos dados revelou que, apesar de não haver um modelo único de
registro de riscos, a organização optou recentemente pelo uso de uma ferramenta corporativa para
gestão integrada de projetos de software e vem passando por um processo de aculturamento do
seu uso. A metodologia de gestão de projetos homologada educa e incentiva o uso do registro de
riscos explicando que este documento deve ser gerado durante a fase de Identificação de Riscos.
168
4.2.1.2 Proposição 2
Para atender a premissa 1 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 2: “A categorização dos riscos em uma Estrutura Analítica de Riscos
utilizando a TBRI permite agrupar uma grande quantidade de riscos comuns de projetos de
software e gerar diversas visões para diferentes níveis hierárquicos na organização”.
Para entender como os riscos de projetos de software são categorizados na instituição,
durante as entrevistas foram realizadas as seguintes perguntas: “2a – Os riscos são categorizados?
2b – Em caso positivo, quais são as categorias de risco utilizadas?”. As respostas para estas
perguntas são apresentadas na Tabela 31, juntamente com as demais perguntas realizadas no
decorrer da entrevista.
Tabela 31: Respostas às perguntas 2a e 2b.
Entrevistado Resposta
# Sigla
1 AC
Aqui na instituição os riscos são categorizados em Alto, Médio e Baixo.
Entrevistador: Alto, Médio e Baixo significa o índice de exposição ao risco baseado no cálculo de
probabilidade e impacto. Categoria é o tipo de risco, por exemplo, segundo o PMI os riscos podem
ser categorizados em Riscos Técnicos, Riscos Externos, Riscos Organizacionais ou Riscos de
Gestão.
Entendi. Neste caso, não sei responder como categorizamos os riscos. Eu nunca categorizei.
2 PJ Durante as auditorias de projeto que realizo aqui na organização nunca observei um projeto que
categorizasse os riscos.
3 AF
Entendo que os riscos deveriam seguir a categorização sugerida pelo PMI: técnica,
organizacional, externa e de gerenciamento do projeto. Entretanto, na prática, aqui na equipe
nunca vi alguém utilizar essas categorias de risco.
4 SR
Os riscos são classificados em Alto, Médio e Baixo.
Entrevistador: Alto, Médio e Baixo significa o índice de exposição ao risco baseado no cálculo de
probabilidade e impacto. Categoria é o tipo de risco, por exemplo, segundo o PMI os riscos podem
ser categorizados em Riscos Técnicos, Riscos Externos, Riscos Organizacionais ou Riscos de
Gestão.
Creio que aqui na instituição não categorizamos os riscos.
5 AS Os riscos não são categorizados.
6 RC
No SAP Solution Manager os riscos são apenas classificados conforme sua criticidade, mas não
são categorizados. A ferramenta é customizável e permitiria criar mais um campo com a categoria
do risco, mas até hoje não identificamos essa necessidade. Além disso, a equipe de consultoria que
nos auxilia com a gestão do projeto nunca mencionou essa prática.
169
Entrevistado
Resposta # Sigla
7 RS
Os riscos são classificados e priorizados de acordo a probabilidade e impacto, da seguinte forma:
a: probabilidade de acontecer (3:alta, 2:média, 1:baixa);
b: impactos de acontecer (3:alta, 2:média, 1:baixa).
c: exposição ao risco: através da fórmula = probabilidade x impacto, se (9:crítico, 6:alto, 3 ou
4:médio, 1 ou 2:baixo).
Entrevistador: Correto. Essa é a forma como os riscos são classificados, mas existe algum tipo de
categoria de riscos? Por exemplo: risco técnico, risco gerencial, risco de terceiros, etc.?
Acredito que não, mas podemos consultar o manual da metodologia de gestão de projetos... [após
consultar o manual] ... realmente o manual comenta que existem as seguintes categorias:
operacional, institucional, incerteza e externo. Mas isso não adianta, pois não temos esse campo
para preenchimento na ferramenta de gestão integrada de tecnologia.
8 CT Desconheço. Acho que aqui na instituição os riscos não são categorizados.
9 LB
Sim. Nos projetos que gerencio eu categorizo os riscos de acordo com o efeito que pode gerar no
projeto. Utilizo as categorias de prazo, custo e escopo. Apesar de não haver um campo específico
para categorizar o risco na ferramenta de gestão integrada de tecnologia eu procuro descrever o
risco utilizando a recomendação do PMI (Se UMA CAUSA existe, o EVENTO pode ocorrer,
levando ao EFEITO).
10 EO
Os riscos são categorizados em alto, médio e baixo.
Entrevistador: Entendo que essa é a forma como os riscos são classificados. Vocês agrupam os
riscos em técnicos, de gestão ou terceiros, por exemplo?
Não. Não organizamos os riscos dessa forma. Desconheço esse tipo de agrupamento de riscos.
11 DB
Sim. Crítico, alto, médio e baixo
Entrevistador: Essa é a forma como os riscos são classificados. Vocês agrupam os riscos em
técnicos, de gestão ou terceiros, por exemplo?
Não. Somente classifico pela probabilidade e impacto.
12 LS
Sim, os riscos devem ser categorizados com potencial impacto baixo, médio ou alto.
Entrevistador: Essa é a forma como os riscos são classificados. Vocês agrupam os riscos em
técnicos, de gestão ou terceiros, por exemplo?
Bom, se esse é o conceito para classificar riscos, então acho que não temos categorias. Eu não me
lembro de ter utilizado uma categoria de risco.
13 RM
Com certeza. Em uma matriz de probabilidade de ocorrer (alto, médio, baixo) x impacto (alto,
médio e baixo) resultado em um risco alto, médio ou baixo.
Entrevistador: Conceitualmente, essa é a forma como os riscos são classificados. Vocês agrupam
os riscos em técnicos, de gestão ou terceiros, por exemplo?
Não. Somente classifico. Seguindo esse conceito, entendo que os riscos não são categorizados aqui
na instituição.
14 DM
Não categorizamos os riscos. A metodologia de gestão de projetos menciona quatro categorias de
risco (operacional, institucional, incerteza e externo), porém, na prática, nunca vi ninguém
utilizar.
170
Entrevistado
Resposta # Sigla
15 FS
Sim, em geral consideramos um risco tudo o que pode causar algum obstáculo ao projeto. Risco,
issues e pendências.
Entrevistador: Entendi. Mas quando você descreve os riscos, vocês os agrupa de alguma forma?
Por exemplo em riscos técnicos, de gestão ou custos, por exemplo?
Geralmente quando atualizo os riscos do projeto com o PMO não especificamos o tipo de risco,
mas entendo que pela descrição do risco é possível identificar e agrupar os riscos semelhantes
16 FT Eu não categorizo os riscos e pelos materiais que observo da equipe, entendo que aqui na nossa
área ninguém categoriza.
Nota. Fonte: elaborado pelo autor.
Com base nas entrevistas foi possível identificar que existe uma diretriz da metodologia
de gestão de projetos da organização indicando que os riscos podem ser categorizados em
operacional, institucional, incerteza ou externo. Porém, percebe-se que essa diretriz não está
disseminada pela organização, pois a grande maioria dos entrevistados a desconhecia. Para os
entrevistados que conheciam essas diretrizes, eles entendem que apesar do manual mencionar
quatro categorias de riscos, não existe um campo na ferramenta de gestão integrada de tecnologia
que oriente esse preenchimento, ou seja, os riscos dos projetos de software não são categorizados
na organização.
Também falta clareza sobre o conceito de categorização de um risco, pois a grande
maioria dos entrevistados confundia tal conceito com o índice de exposição (alto, médio e baixo)
que é gerado a partir da análise de probabilidade e impacto. Outro tipo de categorização
identificado foi com relação ao efeito que o risco poderia causar aos objetivos de prazo, custo e
escopo do projeto, mas também é um tipo de categorização isolada de apenas um gestor de
projeto e não um conceito amplamente utilizado na organização.
A Figura 43 apresenta a tela de cadastramento dos detalhes do risco na ferramenta de
gestão integrada de tecnologia, onde observa-se que realmente não existe o campo “categoria de
risco” para preenchimento. Segundo o manual de metodologia de gestão de projetos as categorias
de riscos são descritas da seguinte forma:
– Operacional: tecnologia e riscos técnicos, conhecimento e competências, equipe,
liderança e gestão, implantação;
– Institucional: políticas empresariais, legal e contratual, ambiental e social, cultural;
171
– Incerteza: força maior, crises sociais, acidentes ou desastres, desconhecimento; e
– Externo: regulatório e governo, economia, mercado e concorrência.
Apesar da organização não categorizar os riscos de projetos de software conforme
estudado no referencial bibliográfico, é possível analisar a descrição dos riscos e categorizá-los
com base em um catálogo pré-estabelecido.
Figura 43: Tela de cadastro do risco.
Fonte: tela da ferramenta de gestão integrada de tecnologia do Banco Alfa.
Ao analisar os campos disponíveis na base de dados de riscos extraída da ferramenta de
gestão integrada de tecnologia observa-se que o campo “categoria de risco” não existe, ou seja a
instituição não possui um catálogo de riscos (Figura 44). Os campos disponíveis na base de
dados de riscos estão agrupados da seguinte forma:
– Identificação são os campos chave para relacionamento do registro com as demais
bases de dados, sendo: (1) Número da solicitação – código único gerado automaticamente pela
ferramenta para identificar o registro na base de dados; (2) Projeto Relacionado – código único
do projeto a qual o risco pertence; (3) Criado por – código único do usuário que registrou o risco
na ferramenta; e (4) Criado em – data de registro do risco na ferramenta.
172
Figura 44: Campos disponíveis na base de dados de riscos
Fonte: relatório da ferramenta de gestão integrada de tecnologia do Banco Alfa.
– Detalhes são as informações descritivas resultantes da análise do risco, sendo: (1)
Título – descrição detalhada do risco; (2) Probabilidade de Ocorrência – avaliação qualitativa do
usuário com relação a probabilidade de materialização do risco, sendo que as notas possíveis são
1-baixa, 2-média, e 3-alta; (3) Impacto do Risco – avaliação qualitativa do usuário com relação ao
impacto que a materialização do risco pode causar aos objetivos do projeto, sendo que as notas
possíveis são 1-baixo, 2-médio e 3-alto; (4) Índice de Exposição ao Risco – calculado
automaticamente pela ferramenta pela multiplicação das notas de probabilidade x impacto e
podem resultar em 1, 2, 3, 4, 6, e 9, permitindo plotar o risco nos quadrantes da matriz de
probabilidade x impacto, conforme Figura 45;
– Plano de Resposta são as informações descritivas resultantes da estratégia de resposta
ao risco, sendo: (1) Estratégia de Resposta ao Risco – identifica uma das possíveis ações sobre o
risco que são eliminar a probabilidade e/ou impacto, mitigar a probabilidade e/ou impacto,
transferir o risco para um fornecedor, ou aceitar as consequências do risco caso este se
materialize; (2) Solução Proposta – descrição do plano de ação; (3) Contingência – descrição da
ação de contingência caso o plano de ação não funcione corretamente; (4) Data do Gatilho do
Risco – data de acionamento do plano de ação; (5) Data para Solução – data limite para
encerramento do risco; e (6) Responsável – colaborador responsável pelo monitoramento do risco
até seu encerramento.
173
Figura 45: Matriz de probabilidade x impacto dos riscos do projeto.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
Observa-se que a proposição 2 não foi atendida face às práticas encontradas na
organização. A análise e interpretação dos dados revelou que os riscos de projetos de software
não são categorizados na organização. Existe uma oportunidade de melhoria neste sentido, pois
tanto a ferramenta de gestão integrada de tecnologia quanto a metodologia de gestão de projetos
não possuem um catálogo de riscos que oriente as equipes a tipificar o risco no momento do
cadastramento. Tal fato ficou evidente durante as entrevistas, pois as equipes desconhecem tal
conceito e seu objetivo.
4.2.1.3 Proposição 3
Para atender a premissa 1 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 3: “Dentre os processos de gestão de riscos, a identificação de riscos é o
processo mais importante, porque somente os riscos identificados podem ser gerenciados.
Entretanto, em organizações imaturas muitos projetos de software são desenvolvidos por
profissionais despreparados que não utilizam as metodologias disponíveis e, consequentemente,
não registram os riscos dos projetos”.
174
Para entender como são gerenciados os riscos de projetos de software não
documentados, durante as entrevistas foram realizadas duas perguntas. “Para os projetos sem
riscos documentados: 3a – Por que os riscos não são documentados na ferramenta de gestão
integrada de tecnologia? 3b – Como os riscos são gerenciados neste caso?”. As respostas a estas
perguntas são apresentadas na Tabela 32, juntamente com as demais perguntas realizadas no
decorrer da entrevista.
Tabela 32: Respostas às perguntas 3a e 3b.
Entrevistado Resposta
# Sigla
1 AC
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Entendo que os principais infratores para a ausência de documentação de riscos são a falta de
tempo ou a falha no levantamento dos riscos. No caso da falta de tempo, muitas vezes os projetos
estão atrasados e a equipe foca nas atividades técnicas para garantir a entrega do sistema
deixando de lado as atividades de gestão. Com relação a falha no levantamento dos riscos, acho
que falta um checklist na organização para ajudar na identificação de riscos recorrentes, pois as
equipes não têm a cultura de consultar os documentos de projetos anteriores para reaproveitar as
lições aprendidas.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
O que ocorre nesta situação é que não existe o gerenciamento de riscos, ou seja, as ações deixam
de ser tratadas de forma preventiva para evitar problemas e passam a ser tratadas de forma
reativa quando os problemas aparecem.
2 PJ
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Isso de fato ocorre por diversas vezes. Em vários projetos que audito observo a falta de cultura
dos gestores do projeto em dispensar mais tempo na fase de planejamento. Além disso, muitos
projetos já iniciam com atraso, ou seja, alguns passos do processo de gestão de projetos são
desconsiderados para que o prazo seja cumprido. A equipe entende que gerenciar riscos é uma
atividade supérflua e segue com o projeto sem as devidas análises.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Neste caso a gestão de riscos é nula. A equipe passa a gerenciar os problemas quando estes se
materializam.
3 AF
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Na nossa equipe temos a cultura de seguir a metodologia de gestão de projetos e documentar os
riscos. Não sei dizer ao certo se ainda temos muitos projetos na instituição sem documentação de
riscos. Se ainda existem, talvez seja a falta de cultura em gestão de projetos, ou seja, o jeito antigo
dos analistas de sistemas desenvolverem sistemas sem as técnicas adequadas de gestão,
pincipalmente no mainframe que é uma tecnologia mais antiga.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Ao meu ver, se os riscos não são documentados, os riscos não são gerenciados, pois não é possível
gerenciar aquilo que não existe. Neste tipo de situação, o que ocorre é o bom e velho "apagar
incêndio", ou seja, quando os problemas aparecem damos um jeito.
175
Entrevistado
Resposta # Sigla
4 SR
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Na minha opinião é muito claro que muitas vezes os riscos não são documentados por falta de
processos e ferramentas simples e claras. Além disso não são documentados por falta de
obrigatoriedade. Se não existir uma área que, de alguma forma, obrigue as equipes de projetos a
documentarem os riscos, sempre teremos projetos sem documentação de riscos. Acho que aqui na
instituição as equipes deveriam ser mais cobradas com relação a qualidade da documentação dos
projetos de sistemas.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Se os riscos não são documentados, só podem ser gerenciados de uma forma: pela experiência dos
membros da equipe do projeto. Ou seja, fica tudo na cabeça do gestor do projeto e da equipe. Se a
equipe muda, leva todo o histórico junto.
5 AS
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Este é um dilema que sempre existiu e continua existindo nos projetos aqui na instituição. Estamos
sempre atrasados e pela pressão em garantir a execução mais rápida do projeto, somada à falta
de compreensão sobre os benefícios dessa prática, o resultado é ignorar esse processo na gestão
do projeto.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
A consequência disso é que os problemas são tratados conforme aparecem, e é necessário
deslocar a equipe das atividades planejadas para resolver as questões urgentes. E o fato de
deslocar a equipe, significa que atividades que estavam avançando em um bom ritmo podem
atrasar. Ou seja, o fato de não gerir os riscos corretamente cria imprevistos e os problemas no
projeto vão aumentando e vai virando um caos, é uma ―bola de neve‖. No final das contas,
ninguém realmente sabe dizer que a causa dos problemas é a falta de acompanhamento dos riscos.
6 RC
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Essa é uma questão difícil de responder. Realmente diversos issues aparecem durante o projeto
sem que os envolvidos tenham identificado aquilo previamente como um risco. Talvez seja o
otimismo das pessoas que faz com que elas entendam que aquela incerteza nunca vai ocorrer e
ignoram o risco. Ou talvez porque realmente ninguém visualizou um possível problema em
determinada situação.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
No nosso programa optamos por tratar riscos e issues juntos. Inclusive semanalmente temos um
comitê específico para tratar desse assunto. Acho que deixa o processo mais simples e flexível,
pois tanto um risco como um issue precisam de um dono, de um plano de ação com uma data para
resolução e de acompanhamento.
176
Entrevistado
Resposta # Sigla
7 RS
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Vejo isso acontecer com frequência. Simplesmente porque os gestores de projeto negligenciam ou
ignoram este importante item. E olha que não é por falta de orientação hein! A metodologia é
muito clara neste aspecto, o registro de riscos é um documento obrigatório tanto na metodologia
de gestão dos projetos grandes quanto pequenos.
Entrevistador: Se é um item obrigatório, por que mesmo assim alguns gestores negligenciam o
processo?
Se você quer seguir a metodologia de gestão de projetos da instituição, esse é um item obrigatório.
Mas na prática, não existem nenhum tipo de punição caso o documento não seja preenchido. Às
vezes acho que a metodologia é mais para "inglês ver". Deveria ter um processo mais rigoroso
para garantir a execução dos processos. Talvez eu seja muito radical neste aspecto porque já
trabalhei em uma empresa de tecnologia mundial que era CMMI 5, lá vinha um auditor de
qualidade averiguar se a gente tinha seguido todos os processos e queria ver a documentação do
projeto armazenada no lugar correto.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Não são. Se você não documenta não gerencia. Resolve quando o "pepino" aparece.
8 CT
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
O prazo dos projetos é sempre muito curto e as pessoas ignoram aspectos gerenciais. As equipes
de sistema focam nos aspectos técnicos para entregar o sistema codificado. Como tenho a função
de multiplicadora da metodologia de desenvolvimento de sistemas, vejo que até mesmo os roteiros
e evidências de testes algumas vezes são desconsiderados ou tem baixa qualidade para garantir as
entregas em produção. Se esses profissionais são assim tão confiantes que entendem que não é
preciso testar o sistema, devem pensar que gestão de riscos é uma ―bobagem‖.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Os riscos não são gerenciados e por isso o projeto sofre diversas mudanças em prazo, custo e até
mesmo no escopo para conseguir resolver os problemas que aparecem.
9 LB
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Acredito que os riscos identificados são sempre documentados; porém, é comum ocorrerem falhas
na análise de riscos e nesses casos, os riscos não são identificados nem documentados.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Infelizmente, não são gerenciados. Se não registra é impossível tomar medidas mitigatórias para
evitar o risco. Também não dá para atribuir um responsável para um risco que não foi declarado
e risco que não tem dono não serve para nada.
10 EO
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Porque normalmente os gestores de projetos esquecem de mapear todos os possíveis riscos e
planos de ação. Normalmente os gestores acreditam que os riscos podem ser resolvidos sem
documentação e sem mapeamento. Somente no momento em que ocorre.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Através de reuniões e alinhamentos com a hierarquia. Apesar de não estarem formalizados,
durante os comitês dos projetos, os riscos e problemas são tratados.
177
Entrevistado
Resposta # Sigla
11 DB
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Realmente nem todos os riscos são documentados na ferramenta de gestão integrada de
tecnologia. Por mais que a equipe se esforce para identificar riscos, sempre existem aqueles riscos
que não foram previstos e ocorrem repentinamente e extraordinariamente.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
A diferença em relação aos riscos já identificados e documentados é que devem ter tratamento
tempestivo para gerenciamento e mitigação/eliminação dos mesmos, pois como o risco já se
concretizou, não existe mais tempo hábil para uma ação preventiva, tem que ser reativa mesmo.
Como dizem de forma vulgar, tem que "estancar o sangue".
12 LS
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Existem riscos que dependem de condições adversas, como doenças em membros da equipe e ou
indisponibilidade de condições que permitam a locomoção dos envolvidos até seu local de
trabalho, porém, são riscos contornáveis que já são previstos em todos os projetos, mesmo não
sendo reportados na documentação.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
O gestor do projeto deve elaborar alternativas para tais situações, de forma que os impactos
possam ser facilmente contornáveis e reajustados.
13 RM
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Ao meu modo de ver, quando isso acontece é devido à falta de disciplina e/ou credibilidade na
efetividade pelo gestor de projeto. No caso da falta de disciplina, entendo que esse profissional
não incorporou a gestão de riscos em sua rotina diária de trabalho, e com relação a credibilidade,
quero dizer que o profissional não acredita que a gestão de riscos vai ajudá-lo a entregar um
projeto de forma mais eficiente.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Os riscos são gerenciados pelo feeling do gestor. Sua experiência vai determinar onde e quando
ele deve atuar em situações de risco.
14 DM
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Sim, essa é uma situação que observo com certa frequência. Vejo que alguns colaboradores não
dedicam um tempo para o planejamento de projetos e identificação de riscos, geralmente
ocorrendo problemas e causando impactos em prazo ou escopo.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
Os riscos não são gerenciados e quando um problema acontece, muitas vezes é necessário rever o
escopo do projeto. Dessa forma tenta-se eliminar requisitos não essenciais para não impactar o
prazo da entrega final combinada com o nosso cliente e registrada nos nossos contratos de metas.
15 FS Não vejo casos assim na área em que trabalho.
16 FT
Entrevistador: Para os projetos sem riscos documentados, por que os riscos não são documentados
na ferramenta de gestão integrada de tecnologia?
Existem riscos que sempre podem ocorrer em todos os projetos, por exemplo: saída de funcionário,
greve e licença médica. São riscos recorrentes conhecidos por todos que automaticamente não são
reportados.
Entrevistador: Para os projetos sem riscos documentados, como os riscos são gerenciados?
São tomadas ações quando necessário. No momento em que um risco acontece, identifica-se uma
forma de resolver a situação.
Nota. Fonte: elaborado pelo autor.
178
Baseado nas entrevistas observa-se que os profissionais possuem clareza sobre a
importância da documentação e gestão de riscos e, adicionalmente, a metodologia de gestão de
projetos da organização é bastante clara com relação a obrigatoriedade do documento de registro
de riscos.
Todavia, apesar de sua importância para uma gestão de projetos adequada, a ausência da
documentação de riscos é uma realidade por diversos motivos: (1) estimativas de prazos de
projetos irreais pressionam os profissionais a realizar as entregas de software em um período
muito curto e, consequentemente, os processos necessários para a gestão de riscos são
negligenciados e ignorados; (2) ausência de um checklist para auxiliar na identificação dos riscos
mais comuns e recorrentes, de forma a aproveitar as lições aprendidas com projetos anteriores;
(3) falta de cultura dos profissionais em focar seu tempo planejando detalhadamente o projeto
antes de iniciar a execução; (4) ausência de controles que garantam a obrigatoriedade do
preenchimento do registro de riscos com qualidade; (5) otimismo dos profissionais envolvidos no
projeto que, apesar de conhecerem os riscos, ignoram sua gestão, pois julgam que tais situações
nunca vão acontecer; e (6) falta de técnicas e ferramentas adequadas que facilitem e estimulem a
identificação dos riscos desconhecidos.
A consequência da falta de documentação de riscos é muito clara para todos
profissionais entrevistados. Se os riscos não são identificados e documentados, a gestão de riscos
se transforma em uma gestão de problemas, ou seja, conforme os problemas ocorrem ao longo do
projeto as equipes se deslocam de suas atividades principais do projeto para solucioná-los. O fato
dessas equipes se deslocarem para resolver problemas urgentes podem impactar o bom
andamento de suas atividades e prejudicar os objetivos do projeto, tais como prazo e escopo.
Alguns entrevistados também mencionaram que, apesar da falta de documentação, em
algumas situações a gestão de riscos ocorre de uma forma não estruturada utilizando-se da
experiência do gestor. Quando a gestão de riscos é conduzida dessa forma, o projeto se torna
dependente de pessoas chaves e restringe a participação dos demais envolvidos.
A Figura 46 apresenta uma visão geral dos processos da metodologia de gestão de
projetos de software homologada na instituição, onde o registro de riscos é um artefato
obrigatório que está inserido nos processos “Identificar e analisar riscos” e “Monitorar e controlar
179
os riscos e problemas”. Constata-se que a diretriz da organização é bastante clara e específica
com relação a esse entregável de um projeto de software, mas o aculturamento dos profissionais e
os controles que garantem a formalização desse processo podem ser aperfeiçoados para garantir
maior aderência.
Figura 46: Visão geral dos processos da metodologia de gestão de projetos.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
Ao analisar a base de dados de projetos, observa-se que 328 (6,5%) dos 5.036 projetos
ativos possuem registro de riscos associados na ferramenta de gestão integrada de tecnologia,
conforme Tabela 33. Como foi observado nas entrevistas, tal fato não significa que os demais
4.708 (93,5%) projetos ativos não possuem riscos associados, pois como a ferramenta ainda não é
utilizada em sua plenitude para todos os projetos de software da instituição, alguns projetos ainda
utilizam planilhas não armazenadas no repositório oficial.
Os projetos cancelados, concluídos e suspensos não possuem riscos associados, pois
nesta situação não apresentam risco tanto para os objetivos do projeto quanto para a organização.
Porém, constatou-se que, como os riscos e planos de ação não ficam mais disponíveis para
consulta, os profissionais não conseguem reaproveitar os riscos mapeados em projetos anteriores.
Tal fato confirma a declaração do entrevistado “1-AC” que prefere utilizar planilhas para o
registro de riscos, pois dessa forma é possível reaproveitar o documento facilitando a
identificação de riscos em projetos futuros.
180
Tabela 33: Status dos Projetos.
Status dos
projetos
Quantidade de
projetos
Quantidade de
projetos com registro
de riscos
Descrição do status
Ativo 5.036 328 Indica que o projeto foi aprovado e
iniciado.
Cancelado 3.865 0
Indica que o projeto foi finalizado por
ação do gestor do projeto antes da
conclusão de todo o escopo planejado.
Concluído 9.957 0
Indica que o encerramento do projeto foi
efetivado após a formalização do aceite de
término do projeto e desmobilização da
equipe.
Suspenso 367 0
Indica que o projeto foi interrompido
inesperadamente por decisão estratégica
ou de força maior, tais como: mudança de
prioridade; estratégia de negócio; ou
reavaliação orçamentária
TOTAL 19.225 328
Nota. Fonte: elaborado pelo autor.
Observa-se que a proposição 3 foi atendida parcialmente face às práticas encontradas
na organização. A análise e interpretação dos dados revelou que tanto os profissionais
entrevistados quando as diretrizes apresentadas reconhecem a importância do processo de
identificação de riscos para a adequada gestão dos projetos, ou seja, se os riscos não são
identificados e documentados, a gestão de riscos se transforma em uma gestão de problemas que
é muito mais crítica e árdua para as equipes. Apesar da consciência de sua importância, observou-
se que na prática o processo é muitas vezes negligenciado devido à falta de tempo dos
profissionais, ausência de ferramentas simples como um checklist, falta de cultura, ausência de
controle de obrigatoriedade, e otimismo dos profissionais que julgam que os riscos nunca serão
materializados.
4.2.2 Premissa 2
Com base nos objetivos principal e específicos deste estudo foi elaborada a seguinte
premissa 2: “Agrupar os riscos dos projetos de software permitindo identificar e priorizar os
principais riscos”.
181
4.2.2.1 Proposição 4
Para atender a premissa 2 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 4: “Os projetos devem ser categorizados e agrupados por finalidade e
tamanho/complexidade para que seja possível compará-los”.
Para entender como os riscos de projetos de software são categorizados e agrupados na
instituição, durante as entrevistas foram realizadas duas perguntas: “4a – Como os projetos são
categorizados? 4b – Como os projetos são priorizados?”. As respostas a estas perguntas são
apresentadas na Tabela 34, juntamente com as demais perguntas realizadas no decorrer da
entrevista. Para entender esta questão foram entrevistados o gerente e superintendente da Área de
Planejamento do portfólio de projetos de tecnologia da instituição.
Tabela 34: Respostas às perguntas 4a e 4b.
Entrevistado Resposta
# Sigla
17
e
18
TS e
PM
Entrevistador: Como os projetos são categorizados?
Os projetos de desenvolvimento de sistemas são categorizados segundo seu tipo e tamanho. Antes
de serem aprovados, os projetos são considerados apenas ideias e utilizamos o conceito de
demanda, ou seja, cada ideia sugerida por um gestor de negócios é considerada uma demanda.
Com relação ao tipo as demandas são classificadas em quatro grandes grupos: Projeto, Caixa
Rápido, Fast Track ou Sustentação. Com relação ao tamanho, as demandas são classificadas de
acordo com a estimativa de horas, ou seja, o esforço homem/hora (porte) planejado para
desenvolvimento da solução, sendo: PP (Muito Pequeno), P (Pequeno), M (Médio), G (Grande) e
GG (Muito Grande).
Entrevistador: Poderia explicar as diferenças entre as demandas de Projeto, Caixa Rápido, Fast
Track e Sustentação?
São conceitos bastante simples e estão diretamente relacionados com a urgência daquela
necessidade para a organização.
. Demanda de Projeto: são as demandas de desenvolvimento ou de melhorias de sistemas que
possuem esforço e/ou complexidade relevantes e obrigatoriamente seguem o fluxo de gestão de
demanda trimestral.
. Demanda Caixa Rápido: são demanda urgentes que não seguem o ciclo trimestral de aprovação
da carteira de projetos; entretanto, para evitar abusos, possui regras bastante claras. Não tem
processo de priorização, usa o método FIFO (first in, first out), tem capacidade previamente
limitada a 15% da capacidade da área, podem ter no máximo 2.000 horas de desenvolvimento e
devem envolver somente um sistema da organização, ou seja, não pode ser um desenvolvimento
integrado entre vários sistemas. Este tipo de demanda é utilizado geralmente para pequenas
evoluções, correções, banners, etc.
. Demanda Fast Track: são demandas urgentíssimas que precisam da aprovação do vice-
presidente de tecnologia e do vice-presidente da área de negócios. Trata-se de uma exceção que é
atendida com análise prévia de impactos na carteira de projetos e demandas da área, pois passa
na frente de todos os outros projetos em andamento. Seu uso é bastante controlado e possui
controles bastante rígidos, geralmente são utilizados para demandas legais e oportunidades de
mercado com urgência de implantação.
182
Entrevistado
Resposta # Sigla
17
e
18
TS e
PM
. Sustentação: são demandas simples que possuem um orçamento e equipe separados para não
concorrerem com a priorização dos demais projetos. Estão organizadas em: atendimento – são
aquelas demandas que exigem apenas suporte por telefone ou e-mail; ordem de serviço – são as
demandas esporádicas não estruturadas que exigem codificação de software e são usadas, por
exemplo, para extração eventual de relatórios, extração de dados e consultas de auditorias; e bug
– são demandas necessárias para correção de erros em produção e com caráter de urgência. Ou
seja, demandas de sustentação são consideradas atividades do dia a dia para manterem o
ambiente produtivo em pleno funcionamento e não podem ser caracterizadas como projetos.
Entrevistador: Poderia explicar os critérios utilizados para classificar uma demanda como PP, P,
M, G e GG?
Claro! O Ciclo de Gestão de Demandas é composto por seis etapas, sendo elas: (1) geração de
ideias; (2) estimativa de porte (Grau W a); (3) seleção de ideias; (4) orçamento (Grau Z
b); (5)
priorização; e (6) planejamento da carteira.
Na etapa 1 (geração de ideias) as ideias são geradas a qualquer momento pelos gestores dos
negócios dentro da instituição, ou seja, a ferramenta de gestão integrada de tecnologia fica
disponível 24 horas, 7 dias por semana para que os gestores cadastrem suas ideias.
A etapa 2 (estimativa de porte) ocorre a cada três meses, período em que as ideias cadastradas
são encaminhadas para os pontos focais na área de tecnologia que são responsáveis pela
estimativa grau W. Não se espera nesta fase uma estimativa muito precisa, porém com base na
descrição da solicitação e em conversas com o gestor do negócio, o ponto focal de tecnologia
consegue, por experiência, identificar de forma macro qual o esforço necessário de manutenção
dentro dos sistemas da instituição e estimar o porte da demanda: PP (Muito Pequeno) – até 40
horas; P (Pequeno) – de 41 a 500 horas; M (Médio) – de 501 a 2.000 horas; G (Grande) – de
2.001 a 5.000 horas e GG (Muito Grande) – acima de 5.000 horas. Apesar de não ser uma
estimativa precisa, é uma forma rápida de estimar o esforço necessário para as ideias e permitir
ao gestor de negócios decidir pela continuidade ou não daquela ideia. Também é importante
destacar que uma demanda, após aprovada, pode ser tratada como um projeto único, mas também
pode virar um programa com diversos projetos.
Entrevistador: Você comentou que o ciclo de gestão de demandas tem seis etapas e explicou as
duas primeiras (geração de ideias e estimativa de porte). Poderia explicar a etapa 3 – seleção de
ideias?
Na etapa 3 (seleção de ideias) os gestores de negócios, com base nas estimativas, decidem se o
projeto é viável. Caso o projeto seja viável, a demanda segue para a etapa 4 de orçamento, caso
contrário a demanda é cancelada.
Entrevistador: Poderia explicar a etapa 4 – orçamento (Grau Z)?
Na etapa 4 (orçamento) serão identificadas todas as áreas impactadas pela demanda para realizar
o orçamento detalhado utilizando a técnica bottom up, ou seja, o ponto focal da demanda na área
de tecnologia é responsável em alinhar o escopo do projeto com todos os sistemas impactados que
por sua vez devem orçar a quantidade de horas que serão gastas no projeto e o prazo. Todos os
orçamentos são consolidados e dessa forma a área de negócio terá o orçamento final que será
utilizado como insumo para a priorização da demanda.
183
Entrevistado
Resposta # Sigla
17
e
18
TS e
PM
Entrevistador: Poderia explicar a etapa 5 – priorização?
Na etapa 5 (priorização), de posse do custo detalhado do projeto, o gestor de negócios atualiza o
business case do projeto e o submete para avaliação do Escritório de Investimentos que analisa o
fluxo de caixa, calcula o VPL (valor presente líquido) e determina a viabilidade econômico-
financeira do projeto no prazo máximo de cinco anos. A partir do VPL calculado as áreas de
negócio e tecnologia priorizam os melhores projetos com base em três critérios: maior vpl, retorno
mais rápido e menor vpl por hora/homem. Cada área de negócios (tecnologia, banco de atacado,
banco de varejo, cartões, seguros, etc.) possui seu orçamento próprio e a priorização de projetos
ocorre individualmente em cada área, ou seja, cada área possui sua carteira de projetos evitando
concorrência entre projetos de segmentos distintos.
Entrevistador: Poderia explicar a etapa 6 – planejamento da carteira?
Na etapa 6 (planejamento da carteira), as datas de início e fim dos projetos são planejadas de
acordo com a ordem de priorização dos projetos e dentro da capacidade orçamentária de cada
área.
Nota. Fonte: elaborado pelo autor. a sigla derivada do inglês Wide (amplo), trata-se de uma estimativa preliminar dos custos do projeto.
b sigla derivada do inglês Zoom (detalhe), trata-se de um orçamento detalhado dos custos do projeto.
Com base na entrevista observa-se que o processo de seleção e priorização de projetos
está bem definido na organização. As carteiras de projetos são organizadas por áreas de negócio,
os projetos são categorizados por tipo (projeto, caixa rápido e fast track) e tamanho (PP, P, M, G
e GG), e a priorização é feita com base no retorno financeiro do projeto (VPL). As demandas de
sustentação possuem orçamento apartado e são consideradas BAU (business as usual), ou seja,
são atividades do dia a dia que não devem ser consideradas como projetos. Para corroborar essa
observação, os entrevistadores apresentaram a circular interna que estabelece as diretrizes do
processo de seleção e priorização dos projetos de tecnologia e determina os papéis e
responsabilidades das áreas, ressaltando que em projetos de tecnologia, é uma prática de mercado
comum referenciar-se ao processo de seleção e priorização de projetos como gestão de demandas.
A Figura 47 apresenta o macro fluxo do processo de gestão de demandas descrito pelos
entrevistados, desde o processo de cadastramento das ideias até o planejamento do projeto.
Dentro do processo de gestão de demandas, os papéis e responsabilidades estão assim
definidos:
– Gestor de Demandas (superintendente de negócios): responsável por estimar e planejar
as demandas das áreas de negócio que atua e garantir o envolvimento das demais linhas de
negócio impactadas pela demanda;
184
Figura 47: Macro fluxo do processo de gestão de demandas.
Fonte: guia do processo de gestão de demandas do Banco Alfa.
– Executivo de Conta (superintendente de TI): responsável por centralizar e priorizar as
demandas da área de negócio que atende, garantindo o envolvimento de todas as áreas
impactadas pela demanda na área de tecnologia;
– Gestor de Recursos (gerentes, coordenadores e especialistas de TI): responsável pela
gestão do conhecimento versus as demandas da área em que atua, por meio de mapeamento de
habilidades e planejamento da capacidade, para os próximos 5 ou 6 meses, visando otimizar o
processo;
– Gestor do Projeto (analistas, coordenadores, especialistas de TI e gerentes):
responsável por planejar, administrar e tomar decisões visando reduzir riscos, solucionar conflitos
e mitigar impactos para gerar resultados que atendam aos objetivos e às expectativas previamente
acordadas;
185
– Gestor de Sustentação (analistas, coordenadores e gerentes): responsável por
acompanhar as requisições de serviços, atendimentos e bugs, reportando mensalmente a
capacidade utilizada para manutenção.
Nas tabelas e gráficos da Figura 48 foram considerados somente os projetos com status
Ativos e Concluídos, pois os projetos Cancelados e Suspensos podem não estar aderentes ao
processo de gestão de demandas e distorcerem as análises. Observa-se que:
– Os projetos do tipo Caixa Rápido, apesar de representarem 58% do número total de
projetos cadastrados, possuem um custo médio de 210 horas e consomem apenas 16% do
orçamento. Por um lado, esta analise mostra que a circular interna está sendo cumprida com
relação ao orçamento, pois aproximadamente 15% do orçamento é consumido com projetos do
tipo Caixa Rápido. Por outro lado, nota-se que o maior projeto deste tipo possui mais de 71 mil
horas de trabalho, ou seja, não está aderente à circular interna apresentada onde menciona que os
projetos do tipo Caixa Rápido podem ter no máximo 2 mil horas de desenvolvimento.
Figura 48: Categorização dos projetos – distribuição por tipo.
Fonte: elaborado pelo autor.
186
– Os projetos do tipo Projeto, representam 34% do número total de projetos cadastrados,
possuem um custo médio de 1.662 horas e consomem a maior parte do orçamento (73%). O
maior projeto possui 586 mil horas e trata-se de um projeto de atualização de versão de todos os
softwares básicos da organização (sistemas operacionais, banco de dados, linguagens de
programação, softwares de conectividade, etc.).
– Os projetos do tipo Fast Track, representam 9% do número total de projetos
cadastrados, possuem um custo médio de 954 horas e consomem 11% do orçamento,
demonstrando que seu uso é restrito conforme declarado pelos entrevistados.
Observa-se que a proposição 4 foi atendida face às práticas encontradas na organização.
A análise e interpretação dos dados revelou que os projetos de software são categorizados e
agrupados segundo sua finalidade e tamanho antes mesmo de serem aprovados, permitindo sua
comparação, priorização e ganho de eficiência no gerenciamento. Durante o processo de
estimativa as demandas são separadas segundo sua criticidade em quatro esteiras: Projeto, Caixa
Rápido, Fast Track ou Sustentação. Após as estimativas iniciais, as demandas são classificadas de
acordo com o tamanho em PP (Muito Pequeno), P (Pequeno), M (Médio), G (Grande) e GG
(Muito Grande). Por fim, as demandas são comparadas e os projetos selecionados e aprovados.
4.2.2.2 Proposição 5
Para atender a premissa 2 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 5: “Os principais riscos em projetos de software na organização estudada são
os mesmos apresentados na literatura: escopo instável, premissas de prazo e custo irreais,
tecnologia complexa e falta de habilidades em gestão de projetos”.
Para entender quais os principais riscos em projetos de software e como estes são
tratados na organização, durante as entrevistas foram realizadas as seguintes perguntas: “5a –
Quais os principais riscos dos projetos de software? 5b – Como são planejadas as respostas aos
riscos? 5c – Como os riscos são monitorados?”. As respostas para estas perguntas são
apresentadas na Tabela 35, juntamente com as demais perguntas realizadas no decorrer da
entrevista.
187
Tabela 35: Respostas às perguntas 5a, 5b e 5c.
Entrevistado Resposta
# Sigla
1 AC
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Entendo que os principais riscos para os projetos que desenvolvemos são o curto prazo estimado
para o projeto e a falta de mão de obra qualificada.
Entrevistador: por que você menciona curto prazo? Quem faz as estimativas? As estimativas não
são realistas?
As estimativas são realizadas por nós (gestores de projeto), mas dificilmente são respeitadas, pois
na maioria das vezes somos pressionados a finalizar o projeto em um tempo inferior ao estimado.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas de acordo com a probabilidade e impacto do risco. Os
riscos de baixa probabilidade e baixo impacto não me preocupam muito e eu mesmo planejo as
respostas, mas os demais discuto com a equipe e determino um responsável.
Entrevistador: como os riscos são monitorados?
São realizados acompanhamentos periódicos conforme a probabilidade/criticidade do risco pelos
responsáveis de cada um dos riscos.
2 PJ
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Acredito que os principais riscos são aqueles que afetam o custo, prazo ou qualidade do projeto.
Entrevistador: como são planejadas as respostas aos riscos?
Na maioria dos casos os planos de ação são discutidos somente após a ocorrência de um
problema e não de forma preventiva como deveria ocorrer.
Entrevistador: como os riscos são monitorados?
Pelo que tenho observado, na maioria das vezes o monitoramento dos riscos é substituído por
―monitoramento de problemas‖, ou seja, não há um monitoramento preventivo dos riscos.
3 AF
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Em primeiro lugar o planejamento ruim pode comprometer todo o projeto, entendo que este seja
um dos principais riscos para um projeto de desenvolvimento de sistemas, por esse motivo é
importante que o planejamento seja realizado com calma, em detalhes e por um profissional
experiente. Outros riscos que também ocorrem com frequência e possuem alto impacto para o
projeto são: perda de prioridade – quando um projeto perde prioridade aqui na organização e
trata-se de um projeto envolvendo a integração de vários sistemas, isso faz com que o gestor do
projeto perca sua força e não consiga os recursos necessários para concluir o projeto;
comunicação ineficaz – quando o canal de comunicação com os envolvidos não é bem
estabelecido, seja com os gerentes funcionais dos sistemas integrados ou seja com os usuários do
negócio, fatalmente o projeto terá problemas, por isso prezo por uma governança forte com o
estabelecimento de comitês e plano de escalada bem claro e transparente; evento externo -
algumas vezes ocorre algum evento externo que não temos como prever seu impacto no bom
andamento do projeto, por exemplo, quando o governo mudou as regras da poupança em um
prazo extremamente curto, tivemos que deslocar as equipes de diversos projetos para atuar nesta
medida legal, impactando o custo dos projetos, depois foram necessárias diversas horas extras
para recuperar os atrasos; e falta de conhecimento técnico - um projeto que envolve novas
tecnologias sempre é um desafio, pois como não conhecemos tecnicamente o projeto, isso gera
muitas incertezas e dificuldades para estimar o custo e prazo do projeto, além de exigir novas
habilidades que algumas vezes não temos na equipe.
Entrevistador: como são planejadas as respostas aos riscos?
Para cada um dos riscos identificados o próprio responsável pelo acompanhamento do risco deve
cadastrar e o plano de ação, porém este tem a liberdade de discutir com qualquer membro da
188
Entrevistado
Resposta # Sigla
equipe, inclusive discutir em nossas reuniões semanais, se necessário, quais as possíveis ações
para mitigar o risco.
Entrevistador: como os riscos são monitorados?
Durante todo o ciclo de vida do projeto os riscos são monitorados. A ferramenta de gestão
integrada permite gerar relatórios dos riscos e problemas cadastrados. Periodicamente utilizamos
este relatório para discussão nas reuniões operacionais do projeto.
4 SR
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Difícil dizer quais os principais riscos, porque para mim é muito claro que o principal risco de um
projeto de manutenção de sistemas nesta organização é a indefinição sobre o escopo, funções e
objetivos do produto a ser entregue.
Entrevistador: por que?
Aqui na organização existe uma pressão muito grande para o estabelecimento do prazo de
implantação pela nossa hierarquia, principalmente porque trabalhamos com releases, então
quando um usuário demanda um projeto, já quer saber qual o mês de implantação. Quando a área
de tecnologia passa uma data prevista, mesmo que todos saibam que é uma data PREVISTA,
parece que esta data está escrita na pedra e esquecem que sem o escopo completamente definido,
não é possível gerar estimativas de prazo certeiras. Ao longo da minha carreira, esse tipo de
problema já aconteceu diversas vezes e continua acontecendo. Hoje mesmo estou tendo problema
com isso. Estamos desenvolvendo um projeto simples de unificação dos contratos de crédito dos
clientes em todos os canais de comunicação e quando passei o orçamento eram trinta contratos
que seriam unificados, mas em um passe de mágica, agora temos cinquenta e cinco contratos e
querem que o prazo seja mantido, mesmo eu explicando que quanto mais contratos, maior o custo
e prazo para as fases de análise, desenho, testes, homologação e implantação... desculpe pelo
desabafo!
Entrevistador: como são planejadas as respostas aos riscos?
Depende da probabilidade de ocorrência x impacto daquele risco, isso é feito no momento do
cadastramento do risco e deve ser validado pelo responsável pelo risco em conjunto com o gestor
do projeto e, se necessário com a equipe também. Após calculada a criticidade do risco é preciso
escolher uma ação sobre o risco, que na nossa ferramenta de gestão de projeto é igual ao
PMBOK: aceitar, eliminar, transferir ou mitigar. Ou seja pensar como criar ações preventivas
para minimizar a probabilidade e impacto antes que o problema ocorra, bem como planejar ações
de contorno para quando ocorrer, e um plano B, caso o plano anterior não funcione.
Entrevistador: como os riscos são monitorados?
Durante todo o projeto e diretamente no boletim de acompanhamento do status do projeto, mas o
acompanhando sistemático do cronograma também me alerta sobre possíveis riscos de atraso que
não estão aparecendo no radar da equipe.
5 AS
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
O principal risco atrelado a um projeto é gerar uma entrega não conforme o desejado, devido aos
diversos fatores: um pedido mal feito, a não capacidade de extrair os detalhes por parte do
executor, problemas de comunicação, má administração de possíveis mudanças que aparecem
durante o projeto, etc.
Entrevistador: como são planejadas as respostas aos riscos?
No momento da ocorrência do risco. Normalmente as ocorrências mais comuns tem planos já
traçados com base no histórico.
Entrevistador: como os riscos são monitorados?
Não são monitorados. Caso se materializem são tratados como problemas.
189
Entrevistado
Resposta # Sigla
6 RC
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Atualmente no caso da implantação do ERP aqui na organização o nosso principal risco é o não
atingimento dos resultados financeiros previstos, pois como o projeto teve atrasos consideráveis
devido à falta de integração entre as diversas consultorias atuantes no projeto, os custos previstos
do projeto quase superaram os benefícios.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são elaboradas pelo dono do risco e discutidas e planejadas nos comitês
semanais para aprovação.
Entrevistador: como os riscos são monitorados?
O monitoramento é de responsabilidade do dono do risco, mas também temos um comitê semanal
específico para acompanhamento dos riscos e issues.
7 RS
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Os principais riscos dos projetos de software são estimativas de custo incorretas; mudança de
estratégia da empresa; gerenciamento fraco de escopo, ou seja, um escopo que não contempla
todas necessidades do usuário ou é mal entendida pela equipe técnica do projeto, por exemplo,
determinado item subtende-se ou são transparentes, ou ainda não afetam diretamente o projeto,
mas interferem; interferência externa do projeto (ex: perda de prioridade com demais projetos,
demanda legal do BACEN, expectativa de inflação – esta pode ser positiva ou negativa que
influenciará diretamente no custo do projeto).
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas via governança (conversas ou reuniões) com os gerentes de
projetos mais experientes, que vivenciaram riscos semelhantes, no entanto, não temos respostas
para todos os riscos. Quando conhecemos o risco e temos a certeza da consequência é possível
planejar adequadamente uma ação para o risco; entretanto, quando não conhecemos as
consequências e nem a probabilidade e acontecer, tomamos como resposta apenas nosso ‗feeling‘.
Entrevistador: como os riscos são monitorados?
Os riscos são monitorados via relatório de acompanhamento dos boletins semanais e também pela
verificação dos riscos com status ―em aberto‖ na lista de riscos.
8 CT
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
O principal risco de um projeto é a alteração do escopo, pois é a partir do escopo que todos os
controles do projeto são organizados. Se você inicia o projeto com um escopo simples, vai colocar
uma equipe não tão experiente e organizar controles de prazo, custo, comunicação e qualidade
simples, porém, se ao longo do projeto este escopo aumenta tornando o projeto complexo, todo o
seu planejamento e controles serão insuficientes e, fatalmente, o projeto não vai cumprir seus
objetivos.
Entrevistador: como são planejadas as respostas aos riscos?
São planejadas pelo gestor em conjunto com a equipe técnica e usuários, por isso é muito
importante incentivar a identificação e cadastramento dos riscos.
Entrevistador: como os riscos são monitorados?
No caso de projetos pequenos e simples, o acompanhamento é informal e realizado pelo próprio
analista de sistema, mas os projetos grandes e complexos possuem espaço reservado na agenda
dos comitês para discutir e monitorar os riscos.
190
Entrevistado
Resposta # Sigla
9 LB
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Os principais riscos são de custo (impacto no orçamento do projeto), prazo (atrasos) e escopo
(não atendimento a parte do escopo do projeto).
Entrevistador: como são planejadas as respostas aos riscos?
A resposta é definida conforme a matriz de probabilidade versus impacto, casos com baixa
probabilidade e baixo impacto podem até mesmo serem aceitos (risco assumido), casos de
probabilidade baixa, média ou alta de ocorrer juntamente com médio impacto, recebem um plano
individual de mitigação, este plano passa a fazer parte do plano do projeto. Os casos em que a
probabilidade de ocorrer e o impacto são altos devem ser eliminados para aceitação do plano do
projeto (ou o projeto pode não ser aprovado/iniciado até a eliminação do risco) ou, devem ser
efetuados ações para reduzir o impacto do risco ao menos para o nível médio.
Entrevistador: como os riscos são monitorados?
Os riscos são controlados por meio das reuniões de checkpoint do projeto (conforme período
definido no plano de comunicação) e, status reports também definidos no plano de comunicação.
10 EO
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Os riscos que mais me preocupam são os extremamente críticos que podem paralisar o projeto e
sobre os quais tenho pouca margem de manobra.
Entrevistador: e quais seriam estes riscos?
São as mudanças estratégicas de prioridade interna ou eventos externos que podem afetar o
ambiente econômico fazendo com que o produto gerado pelo projeto não tenha mais necessidade
para o cliente ou mesmo seja proibido por algum órgão regulador.
Entrevistador: como são planejadas as respostas aos riscos?
Com base na experiência da equipe.
Entrevistador: como os riscos são monitorados?
Os riscos são publicados e monitorados semanalmente no boletim de acompanhamento do projeto.
11 DB
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Os principais que vem à minha mente são: recursos humanos sem conhecimento suficiente sobre o
negócio, sobre o funcionamento técnico do sistema e também em gestão de projetos; prazos
negociados por gestores sem o devido conhecimento da complexidade e envolvimento dos
analistas e especialistas nos sistemas; e projeto dominado por interesses políticos dentro da
instituição onde as pessoas estão mais preocupadas em aparecer para crescer do que efetivamente
em garantir uma entrega de qualidade e que gere benefícios.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas avaliando a criticidade e a probabilidade do risco ocorrer.
Devem ser aplicadas informações factíveis no planejamento de respostas aos riscos e não apenas
cadastrar ações e depois não usar para nada.
Entrevistador: como os riscos são monitorados?
Existem relatórios que podem ser extraídos da ferramenta de gestão integrada de projetos, mas
para que a gestão seja efetiva é necessário expor e discutir os riscos, problemas e suas soluções
nas reuniões de posicionamento e depois comunicar para todos nos relatórios de status-report.
191
Entrevistado
Resposta # Sigla
12 LS
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Posso mencionar os dois principais que são a elaboração do cronograma de acordo com
expectativas da área de negócios ao invés da realidade do projeto, e a alteração constante de
escopo durante o decorrer do projeto, devido à má definição e levantamento de premissas.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas no momento em que o risco é identificado e este é um
processo constante que ocorre durante todo o ciclo de vida do projeto.
Entrevistador: como os riscos são monitorados?
Os riscos são monitorados durante todo o andamento do projeto, através do mapeamento e
comunicação a todos os envolvidos das situações de risco, para que dessa forma, em conjunto, os
envolvidos possam adotar a melhor solução minimizando ou mitigando os impactos do risco.
13 RM
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Na minha opinião o principal risco é a falta de habilidades e conhecimento em gerenciamento de
projetos das pessoas envolvidas, principalmente com relação ao gerenciamento do escopo que é a
essência de um projeto de sistemas. Um escopo fechado e claro permite um planejamento de custo,
prazo, garantia de qualidade e alocação das pessoas certas na hora certa, quero dizer, na minha
opinião é o principal fator de sucesso para o projeto.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas pela equipe do projeto em conjunto com os usuários, mas
infelizmente não vejo esse assunto ser bem tratado aqui na instituição, pois ocorrem muito
problemas durante o andamento do projeto que não foram mapeados como um risco
Entrevistador: como os riscos são monitorados?
O monitoramento é de responsabilidade do gestor do projeto, mas para estimular a identificação e
gestão adequada de riscos, procuramos abrir um espaço nos comitês semanais operacionais e
quinzenais executivos para discutir os riscos e problemas.
14 DM
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
Na minha visão o principal risco de projeto que vem ocorrendo na organização são as datas
impostas pelas hierarquias de entregas inviáveis, prejudicando a qualidade, comprometendo o
escopo original solicitado, e até mesmo o retorno financeiro calculado inicialmente. Outros dois
riscos que vem se materializando com frequência: (1) indisponibilidade dos recursos necessários
no prazo previsto, pois estes são envolvidos em atividades que atrasam e não são liberados para
atuar no projeto conforme combinado; (2) planejamento de um cronograma irreal pelos gestores.
Entrevistador: como são planejadas as respostas aos riscos?
Simplesmente são colocadas em planilhas e nunca recebem a devida atenção. Muitos gestores não
sabem nem como identificar um risco e como planejar ou confundem com pendências e problemas
identificados em tempo de construção ou até na fase de testes.
Entrevistador: como os riscos são monitorados?
Não vejo os riscos sendo monitorados. Apenas são comentados nos comitês as pendências dos
projetos, ou seja, se existia um risco ele muitas vezes já aconteceu e agora é um problema que
deve ser tratado de forma emergencial.
192
Entrevistado
Resposta # Sigla
15 FS
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
O principal risco dos projetos de desenvolvimento e manutenção de sistemas que vejo aqui na
organização e que mais me incomoda é o planejamento inadequado, tanto do ponto de vista do
gestor do negócio que não analisa corretamente a real necessidade do produto ou serviço
resultante do projeto para o mercado atual, quanto do ponto de vista da área de tecnologia que
não estima corretamente o tempo necessário para garantir uma entrega de qualidade respeitando
toda as fases de nossa metodologia de desenvolvimento de sistemas. Dessa forma, temos uma
entrega que foca no cumprimento do prazo, mas não se preocupa com a qualidade, afetando a
entrega do projeto, a moral dos envolvidos que precisam resolver problemas em ambiente
produtivo e a imagem da organização que pode ser exposta negativamente na mídia e junto aos
clientes.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos são planejadas, sempre que possível, em conjunto com a equipe, mas
sempre é responsabilidade do dono do risco organizar essas discussões. Nossa diretriz é que a
resposta ao risco seja realizada de forma rápida, clara e objetiva, buscando na medida do possível
a eliminação do risco, mas caso isso não seja possível, este deve permanecer no radar de todos os
envolvidos no projeto.
Entrevistador: como os riscos são monitorados?
Os riscos são acompanhados semanalmente nos comitês garantindo o envolvimento de todos,
principalmente dos gestores do negócio.
16 FT
Entrevistador: na sua opinião, quais os principais riscos dos projetos de software?
No meu ponto de vista, o maior risco ocorre quando o requisito não está bem definido e a análise
é pobre e sem qualidade. Estes itens podem gerar todos os problemas que o projeto pode ter, risco
de não entregar na data, risco de não entregar a funcionalidade esperada, risco de aumento de
custo e risco da necessidade de recursos adicionais.
Entrevistador: como são planejadas as respostas aos riscos?
As respostas aos riscos devem ser montadas e discutidas com várias pessoas da equipe ou mesmo
fora da equipe, de preferência pessoas que já passaram pelo problema ou presenciaram aquela
situação. Não vejo um risco ser tratado quando existe apenas uma pessoa trabalhando no assunto,
por isso a documentação de riscos é importante para permitir que as lições aprendidas em
projetos passados sejam utilizadas em projetos futuros.
Entrevistador: como os riscos são monitorados?
Após uma discussão bem feita sobre o risco e sendo de consenso da equipe que este deve ser
cadastrado, é importante ser o mais preciso possível ao determinar o gatilho e a data de gatilho
do plano de resposta ao risco, pois é com base nessa data que os riscos são monitorados. O
gatilho é uma situação que indica que o risco está prestes a ocorrer.
Nota. Fonte: elaborado pelo autor.
O gráfico da Figura 49 foi elaborado com base nas entrevistas e observa-se que os
principais riscos (top of the mind) reportados pelos entrevistados são os mesmos identificados na
literatura, com exceção da tecnologia complexa que não aparece como risco relevante dentro da
organização. Sendo que os principais riscos são:
193
– Escopo instável: significa que as definições das funcionalidades, necessidades,
comportamento e forma de utilização do sistema variam bastante durante a execução do projeto,
ou seja, devido a pressão pelo prazo, o projeto se inicia sem o entendimento completo dos
requisitos.
– Premissas de prazo e custo irreais: significa que os cálculos da estimativa de prazo e
esforço são baseados em um escopo incompleto, gerando o risco de não atingimento dos
objetivos estabelecidos e consequente replanejamento do projeto.
– Falta de habilidades técnicas e de gestão: significa que o gestor e/ou a equipe de gestão
não possuem experiência ou competências técnicas suficientes para controlar e monitorar de
forma adequada o projeto/programa, comprometendo os objetivos.
Figura 49: Principais riscos reportados pelos entrevistados.
Fonte: elaborado pelo autor.
O processo de planejamento de resposta aos riscos acontece geralmente no momento do
cadastramento do risco e é de responsabilidade compartilhada entre o dono do risco e a equipe. O
monitoramento dos riscos, de forma geral, ocorre semanalmente, sendo que nos projetos maiores
e mais estruturados o controle é realizado em discussões nos comitês, e nos projetos menores e
mais simples o controle é realizado diretamente no boletim de status em uma seção específica
para acompanhamento de riscos, pendências e problemas.
Em uma pesquisa realizada pela área de qualidade no período de 12/09/12 a 30/09/12
que contou com a participação de 670 analistas de sistemas da organização, foi possível
194
identificar quais os itens que mais dificultam o sucesso nos projetos, conforme Figura 50.
Observa-se que os principais problemas são os mesmos reportados pelos entrevistados, ou seja,
falta de clareza e estabilidade do escopo, além de prazos de projeto irreais.
Figura 50: Pesquisa interna realizada pela área de qualidade.
Fonte: intranet do Banco Alfa.
O processo de gestão de riscos descrito na metodologia de gestão de projetos, conforme
pode ser observado na Figura 51, ratifica as declarações dos entrevistados e fica claro que a
ferramenta de gestão integrada de tecnologia possui adequado fluxo de trabalho para
identificação, análise, planejamento de respostas e controle dos riscos dos projetos de software.
Observa-se que todos os envolvidos no projeto podem cadastrar riscos, porém, somente
o gestor do projeto possui autonomia para aceitar o risco e todo o processo de gestão de riscos
está sob sua responsabilidade. Mesmo que os riscos tenham um dono, o gestor do projeto deve
criar mecanismos para garantir o monitoramento dos riscos, seja este por meio de comitês ou
boletins conforme capturados nas entrevistas. Também é importante destacar o papel da equipe
que apoia o gestor do projeto na mensuração do risco, identificação do plano de ação e execução
da resposta ao risco, garantindo o envolvimento de todo o time no processo.
195
Figura 51: Processo de gestão de riscos.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
A Figura 52 apresenta o cálculo do nível de exposição ao risco que consiste na
multiplicação da nota de probabilidade e impacto realizada durante a fase de avaliação qualitativa
do risco.
Figura 52: Cálculo do nível de exposição ao risco.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
A Figura 53 apresenta a regras para composição dos semáforos do projeto. Nota-se que a
avaliação dos riscos influencia diretamente o status global do projeto, demonstrando sua
importância para o processo de gestão. Quando um projeto possui pelo menos um risco crítico ou
196
risco alto vencido, o status global do projeto é apresentado com o farol vermelho, indicando a
necessidade de atuação imediata do gestor.
Figura 53: Visão gerencial do projeto.
Fonte: manual da metodologia de gestão de projetos do Banco Alfa.
Ao analisar a qualidade do tratamento dos riscos, observa-se no gráfico da Figura 54 que
84% dos riscos estão sendo monitorados adequadamente, por outro lado, 16% dos riscos estão
vencidos, indicando falta de acompanhamento. Dentre os riscos vencidos, 69% possuem
exposição ao risco alto ou médio e precisam de atuação imediata. Tal cenário confirma a
declaração dos entrevistados de que não há homogeneidade na gestão dos riscos dentro da
organização e em alguns projetos os riscos não são adequadamente gerenciados.
Figura 54: Riscos vencidos e exposição ao risco.
Fonte: elaborado pelo autor.
197
É importante destacar que a metodologia de gestão de projetos da organização foi
elaborada utilizando como referência o guia PMBOK (2013), sendo assim, os riscos identificados
devem ser descritos com o maior número de detalhes possível e sugere-se utilizar a seguinte
estrutura de descrição dos riscos: “Se UMA CAUSA existe, o EVENTO pode ocorrer, levando ao
EFEITO”.
Utilizando-se o software NVivo da QSR foi gerada a Tabela 36 com a frequência das
palavras mais utilizadas na descrição dos riscos. Pode-se observar que a descrição de 435 riscos
(28%) mencionava a palavra “projeto” e 339 riscos (22%) mencionava a palavra “risco”,
demonstrando falta de padrão e objetividade na descrição dos riscos. Dessa forma, além de gerar
uma base histórica de lições aprendidas de baixa qualidade que dificulta pesquisas futuras,
também indica a ausência de diretrizes claras que suportem as equipes a descrever um risco de
forma clara, concisa e adequada.
Tabela 36: Frequência de palavras.
Palavra Contagem Palavras similares Palavra Contagem Palavras similares
Projeto 435 projeto, projetos homologação 86 homologação
Risco 339 risco, riscos plano 84 plano, planos
Atraso 311 atraso, atrasos poderá 67 poderá
entrega 178 entrega, entregas mudanças 58 mudança, mudanças
devido 144 devido, devidos problemas 58 problema, problemas
sistema 141 sistema, sistemas necessidade 57 necessidade,
necessidades
Testes 127 teste, testes, tests dados 57 dados
Falta 120 Falta impacto 56 impacto, impactos
escopo 101 Escopo recursos 56 recurso, recursos
Prazo 99 prazo, prazos requisitos 56 requisito, requisitos
Ambiente 98 ambiente, ambientes solução 56 solução
implantação 97 Implantação orçamento 55 orçamento
Nota. Fonte: elaborado pelo autor.
A Figura 55 apresenta um gráfico de nuvem que destaca as palavras utilizadas com
maior frequência na descrição dos riscos.
198
Figura 55: Gráfico de nuvem da frequência de palavras.
Fonte: elaborado pelo autor.
Observa-se que a proposição 5 foi atendida face às práticas encontradas na organização.
A análise e interpretação dos dados revelou que apesar da baixa qualidade encontrada na
descrição dos riscos registrados na ferramenta de gestão integrada de tecnologia, observa-se que
os principais riscos reportados tanto pelos entrevistados quanto pela pesquisa prévia já realizada
pela área de qualidade da organização, são os mesmos identificados na literatura, com destaque
para o escopo instável e premissas de prazo e custo irreais. A tecnologia complexa não é um risco
relevante para a organização, pois os sistemas críticos da organização estão instalados no
mainframe que é uma plataforma segura, estável e de baixa complexidade para as equipes de
desenvolvimento.
4.2.2.3 Proposição 6
Para atender a premissa 2 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 6: “Os bancos devem ter a sua própria lista de verificação de riscos, pois é
uma importante fonte de referência para o processo de identificação de riscos”.
Para entender como ocorre o processo de identificação de riscos nos projetos de software
na organização foi realizada a seguinte pergunta: “6 – Como os riscos são identificados?”. As
respostas para estas perguntas são apresentadas na Tabela 37, juntamente com as demais
perguntas realizadas no decorrer da entrevista.
199
Tabela 37: Respostas à pergunta 6.
Entrevistado Resposta
# Sigla
1 AC
Os riscos são identificados logo no início do projeto em conjunto com os usuários responsáveis
pelas definições do sistema. Durante a fase de planejamento do projeto ocorrem as reuniões de
entendimento do escopo proposto onde são mapeados os possíveis riscos tanto pela equipe técnica
quanto pela equipe da área de negócios.
2 PJ
Observo que na maioria das vezes os gestores de projetos não possuem a prática de identificar os
riscos do projeto durante a fase de planejamento conforme recomendado tanto pelas boas práticas
do PMBOK quanto pela metodologia de gestão de projeto. Na prática os riscos são identificados
durante a execução do projeto somente após a ocorrência de um problema, ou seja, quando isto
acontece não é possível planejar uma ação preventiva e o problema deve ser solucionado
imediatamente. Para resolver um problema, é necessário parar alguma atividade em andamento e
movimentar pessoas da equipe do projeto para resolver a questão, podendo impactar o prazo.
3 AF
Através de reuniões com os envolvidos aplicando a técnica de brainstorming é possível identificar
os riscos e planejar ações para mitigá-los, aceitá-los ou mesmo eliminá-los.
Entrevistador: quando ocorrem essas reuniões?
Não são reuniões específicas para falar sobre riscos, são reuniões onde se reúnem as equipes
técnicas dos diversos sistemas envolvidos com os gestores do produto para detalhar os requisitos
do aplicativo. Aproveitamos essas reuniões também para discutir eventuais riscos que possam
surgir durante as conversas. Na minha opinião, como o dono do produto está presente e
representa o sponsor, fica mais fácil já analisar os possíveis impactos em custo e prazo.
4 SR
Os riscos são identificados durante a fase de planejamento do projeto com base em minha
experiência e leitura que faço da situação atual do projeto. Quando vou preencher os riscos do
projeto procuro avaliar todos os envolvidos diretos e indiretos, sejam eles fornecedores de
produtos e serviços, usuários, ambiente onde será implantado o sistema, cenário
econômico, concorrentes e governos.
5 AS Não vejo os riscos sendo identificados com antecedência. Normalmente são identificados durante
a execução do projeto, conforme aparecem as situações específicas.
6 RC
Os líderes das diversas frentes do projeto têm acesso à ferramenta que utilizamos para
cadastramento de riscos ou issues. Quando este colaborador cadastra o risco ou issue, já
identifica um responsável para atuação e este responsável pode ser qualquer pessoa do projeto,
não precisa ser da sua equipe. Orientamos que a descrição do risco tenha detalhes suficiente para
fácil entendimento do responsável, além disso é necessário cadastrar também a probabilidade e
impacto para que a ferramenta calcule automaticamente a criticidade do risco. Ao término do
cadastramento a ferramenta dispara um e-mail para o responsável que deve cadastrar um plano
de ação com uma data de conclusão. Caso o responsável entenda que aquele risco não existe, deve
levá-lo para discussão no comitê semanal de riscos para e solicitar autorização para exclusão da
ferramenta.
7 RS
Entendo que as principais formas de identificação de riscos são:
(1) Levantamento do histórico de projetos anteriores, pois a documentação dos projetos
concluídos deveriam dar subsídios para evitar os riscos que se transformaram em issues; no
entanto, muitas vezes não divulgamos tais fatos em boas práticas para evitar que o projeto seja
entendido como malsucedido. Outro item importante que pode ser analisado nos projetos
anteriores são os relatórios de custo e prazo planejado e realizado, pois projetos de porte
semelhantes podem utilizar a variação ocorrida no passado como um indicador para o projeto
atual.
(2) A governança do projeto deve estimular a geração de ideias entre os participantes,
principalmente os gerentes de projetos mais experientes conseguem conduzir esse processo com
facilidade.
(3) Verificação do período de desenvolvimento do projeto. O projeto precisa considerar os
períodos de possíveis greves ou período de ‗freezing‘ não planejados devido a datas festivas ou
mesmo agora nas eleições quando o novo governo assumir pode mudar algumas regras como já
aconteceu em governos passados.
200
Entrevistado
Resposta # Sigla
8 CT
Os riscos são identificados em primeiro lugar com base na experiência adquirida do gestor do
projeto, mas também devem ser consideradas as lições aprendidas em projetos anteriores e
brainstorming com as equipes envolvidas.
9 LB
Ao longo da etapa de planejamento são identificados os principais riscos do projeto pelos
analistas de sistemas para preenchimento da documentação inicial do projeto, mas vejo que esse
processo ocorre informalmente em reuniões de trabalho durante todo o ciclo de vida do projeto.
Tanto os riscos quanto os problemas são discutidos de uma forma única, sem muito critério para
conceituar a diferença entre risco, problema ou pendência.
10 EO
Os riscos de um projeto devem ser identificados o quanto antes no ciclo de vida do projeto, por
isso são mapeados e mensurados no planejamento. A metodologia de gestão de projeto e o PMO
sugerem que é o momento ideal para formalizar a documentação do projeto, mas durante todo o
desenvolvimento do projeto surgem naturalmente pela equipe novos riscos ou problemas.
11 DB
Pela experiência do gestor que avalia todas as variáveis que podem influenciar a qualidade e o
prazo do projeto. Isso significa monitoramento constante para garantir a entrega no prazo
previsto e com todos os requisitos solicitados, mas o mais importante é garantir a estabilidade dos
sistemas legados durante a implantação, esse eu entendo que é o principal risco de todo e
qualquer projeto de sistemas que desenvolvemos aqui na organização.
12 LS
Os riscos do projeto devem ser levantados durante as fases de análise do desenho físico e
levantamento de escopo, pois quanto mais tarde forem identificados, mais riscos trarão para o
sucesso do projeto.
13 RM
Os riscos são identificados por todos os envolvidos, mas principalmente pelo gestor do projeto que
é responsável pelo monitoramento dos riscos de modo a garantir o atingimento dos objetivos de
prazo, custo e qualidade do projeto. A forma de identificação mais comum é a experiência
adquirida pelos diversos membros da equipe.
14 DM
Geralmente os riscos não são identificados no planejamento do projeto. Não é dedicado um tempo
para o levantamento destes riscos. Muitas vezes são colocados riscos genéricos a todos os projetos
como falta de recursos e não se analisa todos os cenários para identificar e planejar respostas aos
riscos. Isso ocorre porque os analistas estão preocupados simplesmente em cumprir a
documentação exigida pela metodologia. Outro ponto importante é que mesmo tendo identificado
o risco de falta de recursos por exemplo, a empresa não direciona recursos adicionais para que,
caso o risco aconteça seja possível mitigá-lo, isso quer dizer que se um risco acontecer sempre vai
causar impacto no prazo do projeto.
15 FS
Para a correta identificação dos riscos deve ser seguido uma metodologia como padrão, de modo
que erros anteriores sejam percebidos mais facilmente nos projetos futuros. Eles são identificados
por acompanhamento e ampla comunicação entre todos os envolvidos. A análise deve chegar até
os mínimos detalhes, de modo que os riscos ao serem encontrados sejam mitigados e eliminados.
16 FT
Os riscos são identificados no momento em que todas as necessidades são mapeadas e a análise é
feita com qualidade, neste momento você tem a visão dos principais problemas que podem ocorrer
e onde estão os ―gargalos‖ do projeto.
Nota. Fonte: elaborado pelo autor.
As entrevistas demonstram que os riscos são identificados na maioria das vezes durante
a fase de planejamento do projeto principalmente para garantir a formalização da documentação
exigida pela metodologia de gestão de projetos, mas durante todo o ciclo de vida novos riscos são
identificados sem necessariamente caracterizar a diferença entre riscos, problemas ou pendências.
A principal técnica utiliza é a troca de ideias em reuniões de trabalho entre o gestor, a equipe
técnica e os diversos envolvidos. Nota-se que a experiência do gestor é fundamental para garantir
201
que esse processo seja realizado da melhor maneira possível, não havendo uma diretriz
corporativa clara explicando como o processo deve ser conduzido de forma a garantir sua
qualidade.
Segundo a metodologia de gestão de projetos da organização as fontes e técnicas de
identificação de um risco são: revisões de documentação; lições aprendidas de projetos
anteriores; análise de stakeholders; análise das restrições e premissas do projeto; questionários,
entrevistas, brainstorming; análises de causa-raiz (ex: diagrama de Ishikawa); e análise de listas
de verificação. Apesar da metodologia de gestão de projetos mencionar algumas fontes e
técnicas para identificação de riscos, não existe aprofundamento explicando como aplicar as
técnicas.
Foi observado anteriormente que as descrições dos riscos não possuem padronização,
sendo assim, para identificar os principais riscos dos projetos de software garantindo maior
acurácia na análise dos dados, a classificação dos 1.540 riscos foi realizada individualmente, ou
seja, cada um dos riscos foi lido, interpretado e categorizado conforme a taxonomia proposta pelo
SEI: (1) Engenharia: Requisito, Desenho, Código, Integração ou Especialidade; (2)
Desenvolvimento: Processo, Método, Gestor, Gestão ou Cultura; e (3) Restrição: Recursos,
Contrato ou Interface. Após categorizar todos os riscos foi possível agrupá-los na Tabela 38 que
apresenta a distribuição dos riscos conforme a taxonomia do SEI.
Tabela 38: Distribuição dos riscos conforme a taxonomia do SEI.
Categoria Qtd. %
A1) Engenharia > Requisito 361 23,4%
A2) Engenharia > Desenho 35 2,3%
A3) Engenharia > Código e Teste Unitário 5 0,3%
A4) Engenharia > Integração 133 8,6%
A5) Engenharia > Especialidade 34 2,2%
B1) Desenvolvimento > Processo 38 2,5%
B2) Desenvolvimento > Método 180 11,7%
B3) Desenvolvimento > Gestor 309 20,1%
B4) Desenvolvimento > Gestão 122 7,9%
B5) Desenvolvimento > Cultura 50 3,2%
C1) Restrição > Recursos 227 14,7%
C2) Restrição > Contrato 20 1,3%
C3) Restrição > Interface 26 1,7%
TOTAL GERAL 1.540 100%
Nota. Fonte: elaborado pelo autor.
202
O gráfico da Figura 56 apresenta o histograma da distribuição com a indicação do valor
acumulado, permitindo assim, uma análise gráfica dos resultados do agrupamento.
Figura 56: Gráfico de distribuição dos riscos conforme a taxonomia do SEI.
Fonte: elaborado pelo autor.
A partir da categorização dos riscos observa-se uma grande preocupação (70% dos
riscos) das equipes de projetos de software com relação à Definição de Requisitos, Experiência
do Gestor, Restrição de Recursos e Métodos de Desenvolvimento. Por outro lado, as equipes
expressaram pouca preocupação relacionada à Codificação e Teste Unitário dos requisitos de
software.
Analisando-se em detalhes os registros de riscos contidos nas categorias em destaque
observa-se o seguinte:
(1) Definição de Requisitos: a codificação do software inicia-se mesmo com a falta de
clareza dos requisitos, premissas e restrições. Como consequência destes riscos as estimativas de
custo e prazo do projeto podem ser irreais e o software entregue pode não atender as expectativas
do cliente. É fundamental para o sucesso de um projeto de software que os requisitos sejam
estáveis, descritos de forma clara e completa, validados pelos desenvolvedores e tecnicamente
viáveis.
203
(2) Experiência do Gestor: o principal risco identificado está relacionado com a
dificuldade de planejamento do cronograma junto aos demais gestores funcionais. Gestores
inexperientes podem ter deficiências em planejamento e comunicação e não devem ser líderes de
projetos complexos que possuam diversas interfaces com sistemas legados, pois neste tipo de
projeto é necessário negociar com os gerentes funcionais um cronograma adequado para todos os
envolvidos e que atenda a necessidade do projeto. Além disso, é necessário garantir que esse
cronograma se realize conforme planejado durante a execução do projeto.
(3) Restrição de Recursos: é recorrente o risco dos recursos humanos não estarem
disponíveis para o projeto no momento adequado. Quando este tipo de risco se materializa, o
atingimento do custo e cronograma planejado fica comprometido, principalmente quando o
recurso humano está alocado em uma tarefa que pertence ao caminho crítico do projeto. Por isso
é fundamental que nesta situação o plano de ação seja imediatamente acionado e a liberação ou
substituição do recurso imediatamente realizada.
(4) Métodos de Desenvolvimento: alto risco de instabilidade nos ambientes de teste
integrado e homologação, tanto com relação às versões dos programas quanto com relação a
baixa qualidade e baixo volume de dados para testes. As duas principais consequências deste
risco são: (a) atraso no cronograma e/ou aumento dos custos durante a fase de testes, pois como
os testes não podem ser realizados na velocidade necessária, uma das possíveis soluções é
aumentar o período de testes e/ou alocar mais recursos para realizar as tarefas desta fase; (b)
baixa qualidade ao implantar o software em produção com alto volume de erros e possíveis
prejuízos à organização.
Conforme pode ser observado na Figura 57, a partir do agrupamento dos riscos, também
é possível construir graficamente a Estrutura Analítica dos Riscos do portfólio de projetos
selecionado para o estudo. Utilizando-se como referência o semáforo vermelho para os riscos
elevados, amarelo para os riscos moderados e verde para os riscos baixos, obtêm-se uma EAR
que apresenta em um painel único as principais preocupações do portfólio de projetos, ou seja, os
principais riscos recorrentes que devem ser monitorados frequentemente.
Analisando o painel observa-se os quatro elementos onde estão concentrados os
principais riscos do portfólio de projetos de software da empresa:
204
Figura 57: Estrutura analítica dos riscos do portfólio de projetos selecionados.
Fonte: elaborado pelo autor.
– Classe Engenharia / Elemento Requisito: definição das funcionalidades, necessidades,
comportamento e forma de utilização. Justificativa da viabilidade e estimativa de esforço;
– Classe Desenvolvimento / Elemento Método: ferramentas e equipamentos de apoio
usados no desenvolvimento, tais como simuladores, ferramentas, compiladores e plataformas;
– Classe Desenvolvimento / Elemento Gestor: experiência do gestor em planejamento e
controle da comunicação, custo, escopo, prazo e qualidade de um projeto de software;
– Classe Restrição / Elemento Recursos: restrições externas impostas com relação ao
prazo, orçamento ou pessoal.
Observa-se que a proposição 6 foi atendida parcialmente face às práticas encontradas
na organização. A análise e interpretação dos dados revelou que a organização não possui uma
lista de verificação própria e também não utiliza qualquer lista disponível na literatura. Observa-
se que a metodologia de gestão de projetos menciona a análise de listas de verificação como uma
das possíveis técnicas de identificação de riscos, porém não existe aprofundamento explicando
205
como aplicar tal técnica. Os entrevistados mencionaram que a principal fonte de identificação de
riscos é a experiência da equipe e dos stakeholders. Apesar da falta de uso de uma lista de
verificação pelas equipes, foi possível comprovar empiricamente que a lista de verificação
proposta pelo SEI para projetos de software pode ser imediatamente adotada pela organização.
4.2.3 Premissa 3
Com base nos objetivos principal e específicos deste estudo foi elaborada a seguinte
premissa 3: “Apresentar aos executivos uma visão estratégica dos principais riscos de
projetos de software”.
4.2.3.1 Proposição 7
Para atender a premissa 3 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 7: “A adequada gestão de riscos é um fator chave para o sucesso dos projetos
de software, garantindo que estes sejam concluídos dentro do prazo, dentro do orçamento, com a
qualidade esperada e com as funções necessárias”.
Para entender qual a percepção de sucesso em projetos na organização, durante as
entrevistas foi realizada a seguinte pergunta: “7 – Quais os critérios utilizados para avaliar o
sucesso do projeto?”. As respostas para estas perguntas são apresentadas na Tabela 39,
juntamente com as demais perguntas realizadas no decorrer da entrevista.
Tabela 39: Respostas à pergunta 7.
Entrevistado Resposta
# Sigla
1 AC
Na minha opinião um projeto de sucesso é aquele que atende as necessidades solicitadas pelo
cliente, ou seja, entregue a totalidade dos requisitos definidos e aprovados durante a fase de
planejamento e análise do projeto. Além do mais, considero muito importante que a implantação
seja realizada de forma tranquila e sem impactos tanto para o usuário do sistema que no meu caso
geralmente é o cliente desta instituição, quanto para a área de tecnologia, isso significa uma
implantação com qualidade e baixíssimo nível de erros ou falhas em ambiente produtivo.
206
Entrevistado
Resposta # Sigla
2 PJ
Acredito que a maioria dos gestores de projetos e programas, consideram o projeto um sucesso
quando este é finalizado dentro do prazo previsto. Porém na minha opinião devemos considerar
três itens principais: (1) o projeto é concluído dentro do custo previsto, isso significa que, além da
equipe elaborar um bom orçamento, também é competente no monitoramento dos custos
realizados. Este é um dos principais itens de preocupação na auditoria de projetos, pois no geral,
entendemos que o processo de estimativa e monitoramento de custos ainda precisa melhorar na
organização; (2) o projeto é concluído dentro do prazo. Talvez este seja o maior desafio dos
gestores dentro da organização, principalmente para os grandes projetos que se tornam muito
complexos a partir do momento que envolvem muitos sistemas e diferentes equipes com gerentes
funcionais distintos; e (3) o projeto é concluído com qualidade, tanto do ponto de vista de
codificação do sistema, ou seja, baixo índice de falhas em produção, quanto do ponto de vista da
documentação, ou seja, toda a documentação exigida pela metodologia de desenvolvimento de
sistemas e entregue durante as diversas fases do projeto esteja organizada, padronizada e
armazenada adequadamente para servir como lição aprendida em projetos futuros.
3 AF
Entendo que um projeto de sucesso cumpre basicamente cinco critérios: (1) atende os requisitos
definidos pelo cliente; (2) cumpre os prazos acordados; (3) cumpre os custos acordados; (4)
entrega um produto com qualidade; e (5) realiza uma comunicação eficaz ao longo do projeto.
Entrevistador: pode explicar um pouco mais em detalhes como você consegue mensurar se esses
cinco critérios foram atingidos?
(1) Atende os requisitos definidos pelo cliente – significa que durante toda o ciclo de vida do
projeto o cliente participa do projeto junto com a área de tecnologia sempre validando os
documentos intermediários. Basicamente isso quer dizer que o cliente especifica o sistema em
conjunto com a área de tecnologia, os protótipos de telas e relatórios são desenhados em conjunto,
os roteiros de testes são elaborados a quatro mãos, o sistema é testado e autorizado para
implantação. Tudo isso acontece sem surpresas, sempre atendendo as especificações e
expectativas do cliente.
(2) Cumpre os prazos acordados – no início do projeto a área de tecnologia entrega uma
estimativa de prazo do projeto e ao término da fase de escopo, antes do desenvolvimento, a
estimativa é revisada e gerado o cronograma final. Desde que não haja mudanças de escopo
relevantes durante a evolução do projeto, se espera que o cronograma seja cumprido por ambas
as partes.
(3) Cumpre os custos acordados inicialmente – o controle de custos sempre corre em paralelo ao
cronograma, no início é gerada uma estimativa e ao término da fase de escopo é gerado o
orçamento final já com os valores acordados com os fornecedores. Neste quesito, também se
espera que não ocorra variação até o término do projeto, garantindo que o fluxo de caixa
planejado seja cumprido e nenhum orçamento adicional tenha que ser aprovado pelo patrocinador
do projeto.
(4) Entrega um produto com qualidade – este é o item mais crítico, pois trabalho com manutenção
de sistemas legados críticos para a organização. No meu ponto de vista como gestor do projeto e
sendo da área de tecnologia, a minha maior satisfação é quando implantamos um novo produto e
não geramos impacto no legado. Quero dizer, se os erros em ambiente produtivo ocorrem nos
novos módulos, significa que temos controle da situação, pois geralmente trabalhamos com pilotos
em produção antes de liberar a versão para todos os clientes da organização. Entretanto, se os
erros acontecem nos módulos integrados impactando produtos ou serviços que já estavam estáveis
em produção isso é um sinal que nossos testes foram incompletos ou mal feitos e isso para mim é
um indicador que o controle de qualidade não foi efetivo.
(5) Realiza uma comunicação eficaz ao longo do projeto – não é somente ao final do projeto que
se mede seu sucesso ou fracasso, entendo que um projeto de sucesso é aquele que é bem
gerenciado do início ao fim, quer seja ele um projeto que enfrente problemas ou não. O importante
é sempre discutir a evolução do projeto com todos os envolvidos, pois isso, na minha opinião,
garante o envolvimento das pessoas certas no momento certo.
207
Entrevistado
Resposta # Sigla
4 SR
Eu vejo um projeto de sucesso quando o básico é bem feito. Não acredito em controles
mirabolantes ou técnicas muito avançadas para gerenciar meus projetos. O projeto de sucesso é
aquele que entrega o produto solicitado, com as funcionalidades desejadas, cumprindo o prazo,
garantindo o preço estabelecido, e com a qualidade esperada pelo cliente. Em resumo, projeto de
sucesso é aquele que cumpre o que foi planejado e combinado com o cliente sem desvios. Por isso
é essencial que o escopo seja completamente aprovado pelo cliente nos mínimos detalhes, só
depois é possível planejar prazos e custos reais que possam ser garantidos pela equipe de
tecnologia e por todos os envolvidos no projeto.
5 AS
Em minha opinião um projeto de sucesso é aquele que entrega o que foi pedido pelo cliente, com
qualidade, dentro do prazo e custo estimado. Não basta apenas entregar um produto final
atendendo as especificações do cliente porém sem qualidade, com custo acima do previsto e fora
do prazo, ou seja, um projeto nestas condições não pode ser considerado um projeto de sucesso.
6 RC
Entendo que os critérios de sucesso variam de pessoa para pessoa, depende do papel que esta
exerce dentro do projeto. No meu caso, como PMO, sucesso para mim é terminar o projeto com
um desvio máximo de 10% em relação a data e custo planejados. Mas para o meu chefe
(patrocinador do projeto), tenho certeza que seu principal interesse é ter o SAP rodando
corretamente de modo que os sistemas legados de compras, viagens e pagamentos possam ser
desligados e o novo processo seja mais eficiente. Quero dizer, para o patrocinador o importante é
que após implementado o sistema, os benefícios que foram propostos no business case se
materializem.
7 RS
Entendo que um projeto de sucesso é aquele que atende as necessidades propostas no escopo,
contemplando todos os requisitos funcionais e não funcionais do sistema, com qualidade adequada
tanto durante a fase de desenvolvimento quanto no pós-implantação, dentro dos custos e prazos
planejados e refinados no término da fase de escopo.
8 CT Para dizer que um projeto teve sucesso é importante que ele seja implantado no prazo, dentro do
custo planejado e contemple todo o escopo solicitado pelo cliente.
9 LB
Na minha opinião o sucesso é verificado a partir do atendimento integral dos requisitos definidos
para o projeto com qualidade e dentro do custo. Por isso o entendimento do escopo é fundamental
para o avanço consistente do projeto do início ao fim, sem um escopo claramente definido e
entendido por todas as partes envolvidas no trabalho, não é possível elaborar um orçamento que
retrate de forma fiel o custo envolvido. Principalmente no que tange aos fornecedores, se estes
receberem um escopo mal definido podem ocorrer duas coisas: ou o fornecedor adiciona uma
―gorda‖ margem de erro na sua proposta para se resguardar de futuras mudanças de escopo, ou
no decorrer do projeto vai solicitar um aditivo e, com certeza estará respaldado para isso.
10 EO
Na minha opinião, projeto de sucesso é aquele que atende as expectativas e os benefícios
esperados que foram solicitados pelo cliente. Tem várias formas de avaliar o sucesso ou fracasso
de um projeto, mas uma boa técnica é a utilização do VPL (valor presente líquido) para calcular o
retorno sobre o investimento, inclusive é um dos critérios de priorização de projetos utilizados
aqui na empresa. Escuto dizerem que um projeto de sucesso é aquele que atende o prazo e custo
planejado. Realmente do ponto de vista do gerente do projeto, esse é um aspecto importante, mas
veja o exemplo do Itaquerão que eu estava lendo recentemente. Para construir o estádio do
Itaquerão em São Paulo deveriam gastar R$ 370 milhões, mas no fim gastaram R$530 milhões, ou
seja um desvio de mais de 40% sobre o planejado. Além disso, a data prevista de término era Dez-
13, mas terminou em Mai-14, ou seja, atrasou 5 meses. Apesar de estourar o prazo e orçamento,
podemos dizer que é um projeto de fracasso? Eu entendo que não, pois apesar dos problemas, o
estádio foi entregue e está gerando benefícios permanentes para a cidade de São Paulo,
principalmente para a comunidade local, ou seja, os benefícios superaram os atrasos e estouro do
valor orçado. É por esse motivo que a avaliação financeira de um projeto é um passo fundamental
para medir seu sucesso. Para mim, projeto de sucesso é aquele que entrega um produto que gere
valor para a instituição.
208
Entrevistado
Resposta # Sigla
11 DB
Um projeto de sucesso é aquele que atende a expectativa do sponsor quanto a qualidade e retorno
financeiro. O êxito do produto alvo do projeto e a ausência de gaps de projeto são critérios para
avaliação.
Entrevistador: entendo que retorno financeiro significa que o produto ou serviço gere benefícios
financeiros superiores ao investimento, mas o que significa ausência de gaps de projeto?
Aqui na organização quando um projeto enfrenta um problema e surge a possibilidade de estourar
o prazo, é comum cortar uma parte do escopo definido para garantir a entrega na data prevista.
Esse escopo descartado é o que eu chamo de gap de projeto. Aparentemente o projeto teve
sucesso, mas o que acontece na sequência é que surge um novo projeto para implantar no sistema
aquelas funções que haviam sido descartadas. Isso me parece uma forma de ―maquiar‖ a
ineficiência do projeto, pois um projeto é transformado em dois projetos, quando na verdade
deveriam ser apenas fases distintas do projeto.
Entrevistador: e por que os gaps de projetos são tratados dessa forma na organização?
Infelizmente é uma questão política. As pessoas fazem isso porque o projeto faz parte de suas
metas pessoais e acham um ―jeitinho‖ para cumprir as metas.
12 LS
Projeto de sucesso é aquele em que ocorre a condução e execução de acordo com o estimado e
planejado. Ter um bom planejamento, cumprimento do cronograma independente de adversidades
durante o decorrer do projeto e um líder que saiba estimular e obter o melhor desempenho do
time, sempre com qualidade.
13 RM
Um projeto bem conduzido com boa gestão de escopo e tempo. O sucesso do projeto deve ser
medido através de indicadores discutidos e combinados no início do projeto com todos os
stakeholders.
Entrevistador: você utiliza indicadores para monitorar os projetos? Pode citar alguns exemplos?
O principal indicador que utilizo é o percentual de avanço do escopo do projeto. Toda semana
faço questão de ser informado e informar todos os envolvidos no projeto sobre a evolução do
projeto, quer seja por meio de comitês ou boletins. Por isso digo que um projeto de sucesso é
aquele que tem uma boa gestão de escopo e tempo. Em primeiro lugar o escopo tem que ser
fechado, se tiver qualquer mudança de escopo, o impacto no prazo deve ser avaliado e aprovado
pelo sponsor antes que o projeto seja replanejado. Em segundo lugar a gestão de tempo é
essencial, qualquer atividade não pode durar mais do que quatro semanas, porque entendo que
nesse nível de granularidade fica fácil avaliar, mesmo que de forma subjetiva, qual foi o avanço
da atividade, quer seja uma entrega de software, uma entrega de um documento de especificação
ou um roteiro de teste.
14 DM
Um projeto com um planejamento real que possa ser executado conforme o planejamento. Com
levantamento de riscos e que tenhamos em mãos reservas financeiras caso o risco aconteça.
Que realmente passe pela análise de viabilidade previa. Um projeto que apresente retorno
financeiro à empresa e que não seja implantado a qualquer custo colocando em risco a saúde
física e emocional dos colaboradores. Resumindo, um projeto que respeite a metodologia de
gestão de projetos desenhada para nossa organização.
15 FS
Um projeto de sucesso é o que não cause ferimentos a integridade da empresa e das pessoas
envolvidas nele durante todo o seu processo, e que traga os benefícios sugeridos ao ser planejado.
Para avaliar o sucesso, tudo deve ser analisado, a curto e longo prazo de acordo com o que foi
proposto. Não deixando de lado o que ele trouxe de aprendizado para os envolvidos. Por exemplo:
trouxe o retorno financeiro que havia sido planejado? Melhorou o processo proposto? Os
possíveis erros ficaram de exemplos para lições aprendidas? Entendo que os projetos deveriam ser
analisados após sua entrega, principalmente com relação a formalização da documentação do
sistema e suas falhas em produção, porque isso é a essência de um sistema de qualidade, estável e
fácil de manter.
209
Entrevistado
Resposta # Sigla
16 FT
Um projeto pode atender a sua expectativa e seus requisitos, mas considero um projeto de sucesso
quando atingimos os seguintes pontos: os riscos dos projetos são mapeados e estão sob controle;
os requisitos são bem definidos e fechados antes do início da construção; o projeto possui um
planejamento adequado e consegue segui-lo sem gerar esforço extra; e a equipe do projeto se
encontra em harmonia e existe um trabalho em equipe.
Nota. Fonte: elaborado pelo autor.
O gráfico da Figura 58 foi elaborado com base nas entrevistas e observa-se que os
principais critérios de sucesso reportados pelos entrevistados são os mesmos identificados na
literatura para os projetos de software:
Figura 58: Critérios de sucesso dos projetos de software.
Fonte: elaborado pelo autor.
– 75% entendem que o principal critério de sucesso é entregar o escopo aprovado pelo
cliente;
– 63% comentaram que cumprir o custo e prazo planejados é fundamental, pois garante
que o planejamento foi bem feito e o projeto foi conduzido de forma adequada evitando desvios
significativos;
– 56% entendem que é muito importante entregar um produto ou serviço com qualidade,
garantindo que todas as documentações e entregas intermediárias do projeto tenham qualidade e
sejam aprovadas pelo cliente, não apenas o produto ou serviço final;
– 31%, menos da metade, mencionaram a captura dos benefícios financeiros como um
dos critérios de sucesso do projeto, mais uma vez, coerente com a literatura estudada, pois a
210
maioria dos entrevistados faz parte das equipes do projeto de tecnologia e, geralmente o critério
de sucesso financeiro é a percepção de sucesso do patrocinador do projeto e não da equipe do
projeto;
– 13% apenas dos respondentes mencionaram que o fato de evitar riscos negativos por
meio de uma correta gestão de riscos influencia a percepção de sucesso do projeto.
A metodologia de gestão de projetos de software da organização esclarece seus
objetivos:
Esta norma estabelece a utilização da Metodologia de Gestão de Projeto (MGP) na área de
tecnologia e tem como principal objetivo orientar os colaboradores a iniciar, planejar, executar,
monitorar e controlar, e encerrar os projetos de forma estruturada e padronizada, aumentando
as condições favoráveis para o seu sucesso. Os objetivos da metodologia são:
– instituição de uma "linguagem comum" e das melhores práticas e padrões de gerenciamento
dos projetos;
– redução do nível de retrabalho e aumento de produtividade;
– antecipação de situações desfavoráveis e consequentemente redução dos imprevistos durante
a execução do projeto;
– elevação das condições para o sucesso dos projetos;
– transparência entre os envolvidos nos projetos;
– eficiência na comunicação;
– agilidade na identificação e solução de problemas, com base na análise de riscos;
– agilidade e assertividade na tomada de decisões, uma vez que as informações estão
estruturadas e disponibilizadas.
Pode-se observar que a metodologia de gestão de projetos menciona que seu uso
aumenta as condições favoráveis para o sucesso dos projetos de software, porém não foi explica
quais são esses critérios de sucesso. Tal fato demonstra que apesar não existirem critérios
formalmente estabelecidos, a percepção de sucesso em projetos dos entrevistados já faz parte da
cultura organizacional.
Figura 59: Manual de desempenho dos projetos.
Fonte: guia de indicadores da metodologia de gestão de projetos do Banco Alfa.
211
Ao consultar o guia de indicadores da metodologia de gestão de projetos, conforme
Figura 59, verifica-se que a ferramenta de gestão integrada de tecnologia possui relatórios que
permitem acompanhar a evolução do custo e prazo do projeto, identificados durante as entrevistas
como dois importantes critérios de sucesso do projeto. Ou seja, projetos que evoluem sem desvio
do planejado são considerados projetos de sucesso.
Considerando que os riscos somente podem ser gerenciados quando identificados, pode-
se afirmar que os projetos que não possuem registro de riscos cadastrados não realizam gestão de
riscos. Sendo assim, conforme Figura 60, ao comparar os indicadores de desempenho de custo e
prazo dos projetos que possuem registro de riscos cadastrados com os projetos que não possuem
registro de riscos cadastrados, observa-se que o fato de gerir os riscos não melhora os indicadores
de sucesso do projeto. Enquanto 48,4% dos projetos sem registro de riscos não possuem desvios
do esforço realizado em relação ao planejado, somente 21,3% dos projetos com registro de riscos
não possuem desvios. O mesmo ocorre com relação ao indicador de desvio de prazo, enquanto
23,4% dos projetos sem registro de riscos não possuem desvios do prazo realizado em relação ao
planejado, somente 11,3% dos projetos com registro de riscos não possuem desvios.
Figura 60: Indicador de desempenho dos projetos.
Fonte: elaborado pelo autor.
Observa-se que a proposição 7 não foi atendida face às práticas encontradas na
organização. A análise e interpretação dos dados revelou que a percepção de sucesso de um
projeto de software na organização é o mesmo apresentado na literatura; entretanto, não foi
possível validar empiricamente que os projetos que fazem uso das ferramentas de gestão de riscos
possuem indicadores de sucesso melhores do que aqueles que não as utilizam.
212
4.2.3.2 Proposição 8
Para atender a premissa 3 e com base no referencial teórico deste estudo foi elaborada a
seguinte proposição 8: “Os principais riscos dos projetos de software devem ser apresentados em
uma visão estratégica para permitir a adequada análise e tomada de decisão pelos executivos da
organização”.
Para entender como os riscos de projetos de software são apresentados aos executivos
para a tomada de decisão, durante as entrevistas foi realizada a seguinte pergunta: “8 – Como os
riscos são apresentados aos executivos?”. As respostas para estas perguntas são apresentadas na
Tabela 40, juntamente com as demais perguntas realizadas no decorrer da entrevista.
Tabela 40: Respostas à pergunta 8.
Entrevistado Resposta
# Sigla
1 AC
Os riscos dos projetos são apresentados e discutidos com os executivos nos comitês. A
periodicidade do comitê depende da relevância do projeto, geralmente os projetos menores não
possuem comitês e os riscos e problemas são reportados apenas no resumo executivo quinzenal
que possuem o status individual de todos os projetos que compõem a carteira de projetos da área.
2 PJ
São apresentados nos comitês de projeto ou comitês de portfólio, mas percebo que os executivos se
preocupam apenas com os problemas já evidentes, pois quando os riscos são apresentados fica a
sensação que são eventos sob controle.
3 AF
Na minha opinião muito pouco é mostrado aos executivos, apenas os riscos de projetos mais
comuns são comentados em uma reunião inicial ou de posicionamento. Outra fonte de riscos que é
apresentada aos executivos são os indicadores de projetos gerados semanalmente pela área de
qualidade. Apesar dos indicadores terem cara de problemas, pois mostram uma visão já ocorrida,
entendo que de alguma forma também são riscos para os projetos futuros, quero dizer que os
problemas que estão ocorrendo atualmente em trabalhos atuais, podem ser evitados nos próximos.
4 SR
Apesar da ferramenta de gestão integrada de tecnologia gerar relatórios com o status do projeto e
a situação dos riscos, o que vejo na prática é que são elaboradas apresentações onde são
destacados somente os riscos de maior impacto e probabilidade.
5 AS
Vejo os riscos serem apresentados aos executivos somente quando trata-se de programas
relevantes em que existe a atuação do PMO da área de tecnologia. Semanalmente, a equipe de
analistas do PMO coleta com os líderes técnicos o status dos projetos juntamente com os
problemas e possíveis riscos. Cada projeto possui uma ficha de projeto padrão que é organizada
em um sumário executivo e apresentado ao executivo no comitê do programa.
6 RC
Esse é um assunto bem sério. Todos os riscos que já foram aprovados no comitê operacional e
estão devidamente endereçados são passíveis de serem apresentados aos executivos. Entretanto,
como a reunião com o comitê executivo é de apenas uma hora, precisamos filtrar e elencar
somente os riscos com nível de exposição elevado que são os de alto impacto e alta probabilidade.
Durante o comitê os riscos devem ser apresentados em no máximo dez minutos já com sugestões
de planos de ação, pois é neste momento que são tomadas as decisões pelos executivos.
7 RS Os riscos são consolidados e apresentados aos executivos na reunião de kick-off do projeto.
8 CT
Entendo na maioria das vezes os riscos não são apresentados aos executivos. Pelo menos na nossa
área onde não temos projetos complexos, não temos o hábito de apresentar os riscos dos projetos
aos superintendentes e diretores.
213
Entrevistado
Resposta # Sigla
9 LB
Os riscos são apresentados não apenas aos executivos, mas sim a todos os envolvidos. Em
primeiro lugar o status report possui um indicador da quantidade de riscos envolvidos no projeto
e, em segundo lugar, os riscos estão disponíveis para consulta na própria ferramenta de gestão
integrada de tecnologia e apresentam a descrição dos riscos, o status atual, o plano de ação e a
data prevista para conclusão.
Entrevistador: mas o fato de estar registrado na ferramenta você entende que os envolvidos
realmente fazem uso dessa informação?
Realmente ninguém consulta de forma proativa, por isso faço questão de destacar os riscos nas
reuniões.
10 EO Os riscos não são apresentados aos executivos.
11 DB
Em apresentações onde são demonstrados os riscos, a criticidade dos mesmos, as respostas e a
criticidade após o risco mitigado. Essas apresentações não devem ser em linguagem acadêmica
como em uma metodologia de gestão de projetos. Na prática, somente os projetos de maior
relevância são apresentados aos executivos e, muitas vezes os problemas são tantos e mais
urgentes que os riscos perdem prioridade na discussão.
12 LS
Os riscos devem ser apresentados através das reuniões e reportes, através das documentações
pertinentes a elaboração e evolução do projeto. Sempre devem informar o potencial impacto que
podem causar e possíveis caminhos para mitigar os mesmos.
Entrevistador: isso realmente acontece na prática?
Na prática não vejo isso acontecer aqui na gerência. Acho que não temos essa cultura.
13 RM
Os riscos são apresentados inicialmente no plano de projeto e na reunião de kick-off. Os riscos
críticos são apresentados nas reuniões de acompanhamento com o executivo e os demais são
tratados pelas equipes nas reuniões de trabalho.
14 DM Nas ferramentas atuais somente se apresenta a evolução dos projetos não existe apresentação dos
riscos.
15 FS
Nos comitês semanais do PMO com os executivos se apresenta a evolução do projeto e todas as
pendências com os envolvidos de todas as áreas, informando gravidade, e o plano de ação para a
solução.
16 FT Semanalmente os analistas do PMO atualizam a ficha de projeto com os gestores e apresentam no
comitê semanal para os executivos de tecnologia e da área de negócios.
Nota. Fonte: elaborado pelo autor.
Pelas entrevistas percebe-se que não existe um processo claro e definido para a
consolidação dos riscos dos projetos em uma visão executiva. Quando se trata de um programa
com o envolvimento do escritório de projetos de tecnologia o processo de registro, consolidação e
apresentação dos problemas, riscos e pendências nos comitês executivos é evidente. Por outro
lado, nota-se que os riscos de projetos menores não são levados para discussão com os
executivos.
Foram coletados junto aos entrevistados alguns exemplos de relatórios apresentados em
comitês executivos de grandes projetos ou programas e selecionadas as seções referentes a riscos,
problemas e pendências (Figura 61, Figura 62 e Figura 63). As apresentações executivas
confirmaram os depoimentos dos entrevistados e demonstraram que o tema gestão de riscos não é
214
negligenciado nos grandes projetos e programas de desenvolvimento de software da organização,
ao contrário, este tema é tratado de forma transparente e adequada. Os riscos, problemas e
pendências críticos são levados de forma consolidada ao conhecimento dos executivos para a
tomada de decisões. A falta de padronização entre os diferentes relatórios confirma a ausência de
uma diretriz clara por parte da área de qualidade que é a responsável pela metodologia de gestão
de projetos; entretanto, mesmo sem um documento modelo que garanta a uniformidade dos
relatórios, nota-se o uso de boas práticas de gestão por parte dos líderes dos grandes projetos,
demonstrando experiência profissional e aculturamento da organização em relação a adequada
tratativa dos riscos dos projetos.
A Figura 61 apresenta a página de abertura do status report do “Programa A”. Como o
objetivo desta figura é exemplificar o uso dos relatórios de riscos, são apresentados apenas dois
dos cinco projetos envolvidos. Nota-se que de os riscos e problemas são tratados de forma
objetiva dando ciência aos executivos e permitindo a tomada de decisões quando necessário. Os
detalhes de cada um dos projetos estão inseridos no relatório e pode ser acessado ao clicar no
símbolo “i” ao lado do nome do projeto.
Figura 61: Seção riscos e problemas do status report do programa A.
Fonte: entrevistado número 5 – AS.
A Figura 62 apresenta a seção de indicadores de riscos e problemas do status report do
“Programa B”. Trata-se de um programa bastante amplo e complexo da organização que possui
diversas frentes, por esse motivo optou-se em apresentar os riscos e problemas de forma
215
quantitativa. No comitê são discutidos em detalhes os riscos mais críticos que estão identificados
no quadro “Riscos por Projeto Top 10”.
Figura 62: Seção riscos e problemas do status report do programa B.
Fonte: entrevistado número 6 – RC.
A Figura 63 apresenta a seção de indicadores de riscos e problemas do status report do
“Programa C”. Do lado esquerdo da figura observa-se a página inicial do relatório com um
panorama geral do projeto sobre os temas cronograma, escopo, riscos, prazo, progresso,
problemas, esforço e orçamento. Os detalhes de cada um dos temas podem ser acessados ao clicar
no símbolo “i” ao lado do tema. No detalhe do lado direito da figura observa-se os indicadores de
risco do programa que também podem ser acessados em detalhes quando necessário.
216
Figura 63: Seção riscos e problemas do status report do programa C.
Fonte: entrevistado número 13 – RM.
A Figura 64 apresenta alguns dos indicadores de gestão de projetos de software que são
publicados e distribuídos aos executivos semanalmente. Estes indicadores também são uma
importante fonte de informações para a tomada de decisões executivas, pois detectam riscos e
problemas na gestão dos projetos. Observa-se que no momento da geração do relatório em
10/10/2014 existiam 4.981 projetos ativos na organização e 740 projetos ativos na diretoria X. Os
indicadores têm o seguinte objetivo:
(1) Sem apontamento de horas há mais de 30 dias – detecta o risco de atraso no
cronograma do projeto devido à falta de alocação de recursos, pois como trata-se de um projeto
ativo que deveria ter atuação dos analistas de sistemas e respectivo consumo de horas de trabalho.
A falta de apontamento de horas somente se justifica para projetos concluídos, suspensos ou
cancelados.
217
(2) Esforço realizado maior que planejado – detecta o risco de ineficiência na execução
do projeto, ou seja, o projeto está consumindo mais horas de trabalho do que originalmente
planejadas. As causas podem ser diversas, por exemplo: estimativas com premissas irreais,
alterações de escopo sem avaliação de impacto e replanejamento, tecnologia complexa, falta de
conhecimento da equipe técnica, etc. O importante deste indicador é que ele aponta um risco ou
problema que deve ser averiguado.
(3) Em execução sem baseline – detecta o risco de replanejamento fora das alçadas
competentes, pois os projetos que estão não estão congelados podem ter seu prazo e custo
replanejados pelos analistas de sistemas sem autorização do gestor do projeto.
Figura 64: Indicadores corporativos de gestão de projetos de software.
Fonte: indicadores da área de qualidade do Banco Alfa.
Observa-se que a proposição 8 foi atendida parcialmente face às práticas encontradas
na organização. A análise e interpretação dos dados revelou que atualmente os riscos dos
principais projetos de software da organização são gerenciados de forma adequada e apresentados
em comitês executivos, porém cada projeto apresenta seus riscos individualmente e não há uma
visão integrada dos principais riscos da organização. Uma importante iniciativa da área de
qualidade foi criar alguns indicadores corporativos de gestão de projetos que são discutidos com
os executivos da área de tecnologia, tais indicadores são importantes fontes de informação que
podem detectar tanto problemas quanto riscos crônicos dentro da instituição. Neste sentido, existe
uma oportunidade de aprimorar os indicadores existentes incorporando o monitoramento dos
218
principais riscos da organização. É possível utilizar a estrutura analítica de riscos de projetos de
software proposta pelo SEI para viabilizar o monitoramento sugerido.
219
5 CONCLUSÕES
Com base na literatura estudada e na análise e interpretação de dados do estudo de caso
único é possível responder à questão apresentada para este estudo: “Como deve ser estruturado
um modelo de gestão de riscos que seja aplicável a projetos de software no setor bancário
brasileiro?”.
Figura 65: Modelo STOp de gestão de riscos para projetos de software.
Fonte: elaborado pelo autor.
O modelo STOp propõe-se a orientar a gestão de riscos dos projetos de software de uma
organização do setor bancário a partir do inter-relacionamento entre os três níveis hierárquicos
existentes nesse tipo de empresa: Estratégico, Tático e Operacional.
220
ESTRATÉGICO
Os riscos que aparentemente afetam apenas o projeto podem propagar-se por toda a
organização e afetar seus objetivos de longo prazo (Shenhar et al., 2007). Por esse motivo, é
fundamental a participação ativa da área de tecnologia da informação nas decisões estratégicas da
organização (Henderson & Venkatraman, 1993), garantindo que a gestão de riscos dos projetos
de software esteja alinhada com os valores organizacionais (PMI, 2009, 2013a; PMI & IEEE,
2013).
No nível estratégico, os executivos preocupam-se em avaliar os principais riscos do
portfólio de projetos de software e autorizar soluções corporativas que reduzam seus impactos
negativos. Ou seja, são decisões que envolvem grandes investimentos ou mudanças relevantes de
processos e estão acima da alçada das equipes de desenvolvimento.
ESTRUTURA ANALÍTICA DE RISCOS - EAR
A EAR é a melhor maneira de lidar com uma grande quantidade de dados, pois permite
estruturar a informação facilitando a compreensão e identificação de áreas de concentração de
riscos (Hillson, 2003). Para categorizar os riscos de projetos de software é recomendado utilizar a
Taxonomy-Based Risk Identification - TBRI, pois é uma EAR madura, desenvolvida em 1993
pelo Software Engineering Institute - SEI e amplamente utilizada até os dias de hoje (Holzmann
& Spiegler, 2011; Silva et al., 2006). A TBRI aborda tanto os riscos que podem impactar o custo,
escopo e prazo do projeto quanto os riscos operacionais que podem impactar o ambiente
produtivo da organização após a implantação do software (Hillson, 2013b; PMI & IEEE, 2013).
Uma EAR com base na TBRI fornece um painel gráfico executivo de apenas uma
página. Nesse painel é possível identificar visualmente onde estão localizados os principais riscos
do portfólio de projetos que merecem atenção, bem como aqueles que não preocupam as equipes
de desenvolvimento.
Neste estudo, a partir da base de dados histórica dos projetos de software, foi possível
interpretar individualmente a descrição dos riscos e categorizá-los conforme o catálogo proposto
pela TBRI. Na sequência, os riscos foram agrupados gerando o painel gráfico apresentado na
seção 4.2.2.3 e sinalizando as quatro categorias que concentravam as principais preocupações das
221
equipes de desenvolvimento: definição de requisitos, experiência do gestor, restrição de recursos
e métodos de desenvolvimento. Conclui-se que o catálogo de riscos utilizado pode ser
imediatamente adotado pela organização.
PRINCIPAIS RISCOS
A gestão de riscos de projetos de software está focada na preservação do valor do
negócio (Grembergen, 2004). Percebe-se que tais riscos estão tornando-se cada vez mais
significativos, principalmente porque são difíceis de serem identificados e modificam-se ao longo
do tempo (Hughes, 2006). Por esse motivo, é importante compreender o relacionamento entre os
principais riscos, possibilitando seu tratamento em um nível hierárquico superior, lidando com
fatores de maior grau de abrangência (Leopoldino & Borenstein, 2011) e compartilhando a
responsabilidade com os parceiros das áreas de negócio que patrocinam os projetos (Luftman,
2003).
A EAR pode ser decomposta até seu menor nível, que é o risco individual de cada
projeto. Partindo desse princípio é possível avaliar em detalhes os principais riscos que compõem
as categorias críticas da EAR e entender suas principais causas e consequências.
Neste estudo ficou confirmada a facilidade de decomposição oferecida pela técnica e sua
aplicação prática para a organização. Analisando em detalhes os registros de riscos contidos nas
categorias em destaque foi possível concluir que as principais fragilidades da organização estão
em concordância com a literatura: (1) falta de clareza dos requisitos, das premissas e das
restrições gera estimativas de custo e prazo irreais; (2) gestores de projeto inexperientes atrasam
os projetos porque não articulam com os gestores funcionais a alocação dos especialistas no
momento correto; e (3) instabilidades nos ambientes de teste integrado e homologação geram
incidentes em produção com prejuízos financeiros. Os detalhes estão apresentados na seção
4.2.2.3.
SOLUÇÕES
Considerando o impacto estratégico que os projetos têm nos negócios, é fundamental
que seus riscos sejam monitorados desde a concepção até o pós-lançamento do produto ou
222
serviço (Killen & Hunt, 2009 e 2013); entretanto, muitos projetos de software ainda falham
devido à falta de maturidade das organizações em gestão de riscos (Alberts & Dorofee, 2012).
Para reduzir drasticamente o nível de exposição ao risco desses projetos e melhorar o retorno
sobre seus investimentos é necessário gerir os riscos da área de tecnologia da informação de
forma corporativa (Hughes, 2006), permitindo analisar seus pontos positivos e negativos para
traçar um plano de ação de melhoria (Killen & Hunt, 2009 e 2013).
A partir dos principais riscos mapeados no portfólio de projetos de software é possível
estudar soluções que reduzam, ou até mesmo eliminem, os impactos negativos. Por exemplo:
(1) para a falta de clareza dos requisitos podem ser implantados processos de quality assurance
que garantam a qualidade dos artefatos de requisitos; (2) para a falta de experiência dos gestores
é possível ampliar a grade de treinamento desses profissionais e implantar um processo de
mentoring como uma das responsabilidades do PMO local de tecnologia; e (3) para as
instabilidades nos ambientes de teste integrado e homologação é necessária a criação de
ambientes apartados com estruturas idênticas ao ambiente produtivo, exigindo um grande
investimento financeiro. Entretanto, tais soluções são apenas sugestões que merecem estudos
detalhados para apresentação aos comitês executivos da organização.
TÁTICO
A governança de tecnologia é um importante instrumento de gestão (Lunardi, 2008)
composta pela liderança, pela estrutura organizacional e pelos processos necessários para garantir
que as atividades de tecnologia se sustentem e expandam os objetivos estratégicos da organização
(Grembergen, 2004).
No nível tático as equipes de governança preocupam-se em estruturar políticas e
processos para garantir que os riscos dos projetos e programas de software sejam adequadamente
comunicados aos executivos e as soluções corporativas sejam devidamente implantadas.
223
PROCESSOS
Se uma empresa dedica grande parte de sua energia à implantação de projetos, uma
abordagem não estruturada e disciplinada da sua gestão conduz a ineficiências que podem ser
danosas à organização (Rau, 2004); por isso, as metodologias de gestão de projetos e riscos
devem ser adequadas às características da organização, garantindo que a estrutura de governança,
planejamento e controle seja apropriada (OGC, 2009). Apesar de sua importância, muitos
projetos no Brasil são desenvolvidos sem que haja o adequado uso de metodologias e/ou modelos
de gestão de risco (Rovai, 2005).
Os processos compreendem as normativas, as metodologias e os manuais relacionados à
gestão de projetos e gestão de riscos de software existentes na organização. Tais diretrizes
permitem a padronização e o controle dos processos da área de desenvolvimento de sistemas a
fim de melhorar a qualidade geral dos projetos e das entregas de software em ambiente produtivo.
Neste estudo ficou evidente que as diretrizes estabelecidas pela área de qualidade por
meio das metodologias de gestão de projetos e de desenvolvimento de sistemas são guias
fundamentais para as equipes da área de desenvolvimento. Também ficou claro que os processos
de gestão de demandas necessários para categorização, priorização e seleção de projetos estão
devidamente estabelecidos e são de conhecimento das equipes envolvidas.
Porém, quando os processos não são adequadamente divulgados e controlados, as
equipes perdem a referência, e as atividades passam a ser desenvolvidas de diferentes maneiras.
Foi observado que o processo de identificação de riscos ainda não é executado de forma
homogênea pelas diversas equipes, prejudicando a reutilização de informações históricas. Tal fato
corrobora a literatura, que orienta o uso de metodologias e processos padronizados na busca pela
excelência.
FERRAMENTAS
O uso de ferramentas, técnicas e processos adequados de gestão de riscos garante a
realização dos objetivos do projeto (Higuera & Haimes, 1996), melhora sua taxa de sucesso (Raz
et al., 2002; The Standish Group International, 2013) e fornece as competências necessárias para
melhorar o julgamento dos profissionais que atuam em projetos de software (Boehm, 1991).
224
A área de qualidade deve determinar as ferramentas, as técnicas, o suporte e os
treinamentos necessários para que as equipes de desenvolvimento executem seus projetos de
software. Existem diversas ferramentas e técnicas para gestão de riscos disponíveis na literatura e
no mercado; porém, é preciso selecionar aquelas que mais se adaptam às necessidades da
organização.
O uso restrito de ferramentas e técnicas beneficia todas as áreas envolvidas no
desenvolvimento de software, pois a padronização do processo gera ganhos de eficiência. Além
disso, também permite a estruturação, a comparação e o reaproveitamento dos dados históricos.
Devido ao uso da ferramenta de gestão integrada de tecnologia pelas equipes de
desenvolvimento, foi possível extrair eletronicamente dados dos projetos para utilização neste
estudo e identificar os principais riscos atualmente existentes no portfólio. Conclui-se que é
importante tornar obrigatório o uso do registro de riscos na ferramenta, criar controles e métricas
para garantir seu uso e incorporar o catálogo de riscos da TBRI.
QUALIDADE
Um dos principais objetivos de um projeto é entregar um produto ou serviço com a
qualidade esperada (Wideman, 1992; Higuera & Haimes, 1996; Bucanac, 1999; Agarwal &
Rathod, 2006; Chapman & Ward, 2007; Rabechini & Carvalho, 2013; The Standish Group
International, 2013), e, para isso, é fundamental o papel da área de governança na definição dos
processos, das políticas, dos objetivos, das responsabilidades e dos controles, de modo que o
projeto satisfaça as necessidades para as quais foi empreendido (OGC, 2009; PMI, 2013a).
Um processo de gestão de riscos de qualidade é aquele que aumenta as chances de
sucesso do projeto, antecipando os problemas e as oportunidades, de modo que ações preventivas
possam ser realizadas com eficácia. Por isso, é fundamental a atuação da área de qualidade ao
estabelecer padrões por meio de manuais e normativas, além de garantir seu cumprimento por
meio de controles, indicadores e métricas. Adicionalmente, as áreas de compliance e auditoria
também desempenham papel importante nesse processo, validando a aderência e suficiência dos
controles estabelecidos.
Na organização estudada foi verificado que a estrutura proposta na literatura funciona
adequadamente. As áreas de governança mencionadas (qualidade, compliance e auditoria) têm as
225
alçadas e ferramentas necessárias para garantir o estabelecimento do processo de gestão de riscos
de projetos e sua realização pelas áreas executoras.
COMUNICAÇÃO
A gestão de riscos é essencial para a tomada de decisões eficazes e comunicação dos
resultados dentro das organizações (ISO & IEC, 2006). Os diferentes níveis hierárquicos exigem
visões de riscos distintas, pois suas responsabilidades, habilidades e horizonte de tempo são
completamente diferentes. No nível operacional, os engenheiros observam principalmente os
riscos técnicos; no nível tático, os gerentes preocupam-se com o custo, o prazo, os requisitos, a
qualidade e o desempenho; e, no nível estratégico, os executivos analisam os riscos que podem
impactar a rentabilidade, a qualidade e o prazo esperado de um ou diversos projetos (Higuera &
Haimes, 1996); entretanto, percebe-se que falhas evitáveis em projetos de software continuam a
ocorrer porque diversos riscos significativos não são levados ao conhecimento dos tomadores de
decisão (Alberts & Dorofee, 2012).
A área de governança tem o papel de monitorar e comunicar aos executivos o
desempenho do portfólio de projetos, destacando eventuais desvios significativos.
Adicionalmente, deve garantir que as estratégias da organização sejam comunicadas às equipes
de desenvolvimento.
Este estudo revelou que cada um dos principais projetos e programas da organização
comunica aos executivos seus riscos relevantes; porém, não existe uma visão integrada dos riscos
do portfólio. Atualmente, a área de qualidade monitora diversos indicadores de desempenho do
portfólio de projetos e possui um fórum estabelecido com o comitê executivo para apresentação
dos resultados e a tomada de decisões. A EAR pode ser incorporada aos indicadores existentes
utilizando o canal de comunicação instituído. Conclui-se que a governança é peça chave na
comunicação entre os diversos níveis hierárquicos, e os fóruns já existentes podem ser
aproveitados para tratar os assuntos relacionados à gestão de riscos dos projetos de software.
226
OPERACIONAL
Cada projeto de software tem diferentes incertezas, pois são uma combinação única de
requisitos, arquitetura e construção, resultando em um produto diferente (PMI & IEEE, 2013).
Devido ao rápido desenvolvimento das tecnologias, em conjunto com o aumento da variedade e
complexidade, a gestão desses projetos tornou-se um desafio, aumentando o risco de obterem
menos benefícios do que o estimado ou ultrapassarem o orçamento e os prazos previstos
(Hughes, 2006). Dessa forma, a utilização de métodos padronizados é uma prática que auxilia o
alcance dos objetivos (Weill, 2002).
No nível operacional, as equipes de desenvolvimento preocupam-se com os riscos
individuais que podem impactar os objetivos do projeto/programa (concluir dentro do prazo,
custo e qualidade planejados) e do produto/software (atender aos benefícios declarados no plano
de negócios).
IDENTIFICAÇÃO
Os riscos somente são gerenciáveis quando identificados e documentados em um
registro de riscos de forma clara e precisa (Hillson, 2013a). Entre os processos de gestão de
riscos, a etapa de identificação de riscos é a origem de todo o processo (Boehm, 1989) e também
a mais importante, pois tem um forte impacto sobre a precisão das análises posteriores
(Chapman, 1998). Para auxiliar nessa tarefa, o Taxonomy-Based Questionnaire - TBQ é uma
ferramenta para identificação de riscos em projetos de software com base na premissa de que os
riscos são geralmente conhecidos pela equipe técnica, mas são mal documentados e comunicados
(Carr et al., 1993).
Identificar os riscos significa gerar uma lista das incertezas que podem afetar os
objetivos do projeto, e, para isso, a metodologia de gestão de projetos da organização estudada
sugere algumas técnicas disponíveis na literatura, como, por exemplo: lições aprendidas; análise
das restrições e premissas; questionários, entrevistas e brainstorming; e listas de verificação,
entre outras. Entretanto, como não existe aprofundamento, foi observado nas entrevistas e na
análise das bases de dados que a falta do uso de técnicas adequadas gera registros de riscos de
baixa qualidade. Se a fase de identificação de riscos falhar, todo o processo de análise e
monitoramento fica comprometido.
227
Para garantir que o processo de gestão de riscos cumpra seu objetivo, é necessário
selecionar apenas uma ferramenta e incentivar seu uso de forma ampla e padronizada por toda a
organização. No caso da organização estudada, foi concluído que é possível adotar o TBQ, pois é
uma ferramenta madura, amplamente utilizada, específica para projetos de software, e possui
ampla cobertura dos riscos durante todo o ciclo de vida do projeto.
ANÁLISE
Os dados dos riscos devem ser convertidos em informações para a tomada de decisões
(Higuera & Haimes, 1996). Isso significa complementar o registro de riscos avaliando a
probabilidade de o risco se materializar, o impacto da perda gerada, seu efeito cascata (Boehm,
1991) e suas causas (ISO, 2009), permitindo, assim, a adequada priorização da lista de riscos e o
planejamento das respostas que aumentam as oportunidades e reduzem as ameaças aos objetivos
do projeto (PMI, 2009, 2013a; PMI & IEEE, 2013).
Após identificado o risco é necessário categorizá-lo, avaliar sua probabilidade e impacto
e definir o plano de ação e o responsável. Na organização estudada foi verificado que tanto a
metodologia de gestão de projetos quanto a ferramenta de gestão integrada de tecnologia
garantem que o risco identificado siga todo o fluxo do processo de análise. Mais uma vez a
análise dos dados corroborou a literatura, demonstrando que a análise do risco é essencial para o
processo de gestão de riscos e deve ser executada pelas equipes de desenvolvimento.
MONITORAMENTO
O registro de riscos deve ser reavaliado regularmente durante todo o ciclo de vida do
projeto (Guyer, 2012). Isso significa monitorar as métricas de riscos (Higuera & Haimes, 1996),
garantir que os controles são eficazes e eficientes (ISO, 2009) e identificar novos riscos (PMI,
2009, 2013a; PMI & IEEE, 2013). Uma técnica sugerida é criar uma lista de controle do
progresso dos dez riscos mais significantes do período (Boehm, 1991).
Monitorar os riscos significa manter vigilância constante para garantir que os controles
estabelecidos são eficazes e eficientes, evitando a materialização dos riscos. Os processos de
monitoramento de riscos da organização estudada mostraram-se bastante sofisticados, pois a
228
ferramenta de gestão integrada de tecnologia gera automaticamente indicadores e relatórios de
controle para acompanhamento da evolução dos riscos, planos de ação e planos de contingência.
O processo de monitoramento de riscos está alinhado às boas práticas descritas na literatura.
Foi concluído que o modelo proposto atende ao objetivo principal do estudo, pois é
sustentado integralmente pela literatura e sua implantação na organização estudada mostrou-se
viável. Por fim, a análise de aderência permitiu identificar algumas fragilidades no processo de
gestão de riscos de projetos de software da organização.
229
6 CONTRIBUIÇÕES PARA A PRÁTICA
Implantar processos em uma grande organização não é uma tarefa fácil, pois a cultura
organizacional já estabelecida impõe barreiras às mudanças. Sendo assim, antes de propor
mudanças é importante avaliar seus pontos positivos e negativos. Uma ferramenta muito útil que
pode ser utilizada nesse processo é a Análise SWOT (Strengths, Weaknesses, Opportunities e
Threats) apresentada na Figura 66.
Segundo Kotler (2000), a Análise SWOT contempla tanto a análise do ambiente interno
(forças e fraquezas) quanto a análise do ambiente externo (oportunidades e ameaças). A análise
do ambiente interno refere-se ao resultado de fatores controláveis pela organização, como
produtividade da mão de obra, inovação tecnológica, capacidade de autofinanciamento das
operações, imagem, amplitude da distribuição e localização, entre outros. A análise do ambiente
externo envolve forças macroambientais (econômicas, demográficas, tecnológicas, político-legais
e culturais).
Figura 66: Análise SWOT.
Fonte: adaptado pelo autor da Wikipédia.
230
A análise dos dados sobre o processo de gestão de riscos em projetos de software na
organização estudada, em contraponto com o referencial teórico, permite analisar os principais
pontos positivos e negativos do modelo proposto. Para sintetizar esses resultados foi realizada
uma Análise SWOT, que evidenciou as forças (objetivos alcançados, benefícios e satisfação), as
fraquezas (dificuldades, fracassos e descontentamento), as oportunidades (capacidade não
explorada e ideias de melhorias) e as ameaças (contexto adverso, oposição e resistência às
mudanças) relativas ao processo atual.
Como se trata de uma organização do setor bancário, o avanço tecnológico de seus
sistemas computacionais é fundamental para garantir a segurança das operações atuais e sustentar
seu crescimento futuro. Nesse sentido, garantir a eficiência e eficácia dos projetos de software
torna-se uma questão estratégica que pode ser alcançada com a ajuda de uma adequada gestão de
riscos. A Tabela 41 apresenta o resultado dessa análise e também propõe algumas sugestões de
melhoria. O objetivo dessa análise é colaborar com a evolução do processo de gestão de riscos
em projetos de software da organização.
231
Tabela 41: Análise SWOT.
Dimensão Elemento Forças Fraquezas Oportunidades Ameaças
Est
raté
gic
o
EAR . Não se aplica. . Atualmente a EAR não é
utilizada.
. Adotar a TBRI como
catálogo de riscos-padrão
para os projetos de software.
. Apresentar aos executivos o
piloto elaborado a partir da
base de dados de risco
atualmente existente, o qual
se mostrou viável.
. Necessário customizar a
ferramenta de gestão
integrada de tecnologia.
Principais
Riscos
. As equipes de
desenvolvimento expressaram
pouca preocupação com os
processos de Codificação e
Teste Unitário dos requisitos
de software. Isso demonstra
que a equipe possui sólidos
conhecimentos técnicos do
ambiente de
desenvolvimento.
. Os principais riscos
identificados neste estudo são
os mesmos da pesquisa
interna realizada pela área de
qualidade em setembro de
2012.
. Principais riscos: (a) escopo
instável; (b) premissas de
prazo e custo irreais; (c) falta
de habilidades técnicas e de
gestão; e (d) instabilidades
nos ambientes de teste
integrado e homologação.
. Apresentar aos executivos
os principais riscos crônicos
já conhecidos e propor
soluções definitivas ou
paliativas.
. Resistência às mudanças por
parte dos executivos, áreas de
negócios e equipes técnicas
envolvidas nos projetos de
software.
Soluções . Os principais riscos já estão
mapeados e os projetos
estruturantes possuem
orçamento reservado que
podem endereçar tais
questões.
. Nenhuma ação foi tomada
nos últimos dois anos para
melhorar o cenário
identificado em setembro de
2012.
. Avaliar se a pesquisa de
setembro de 2012 chegou ao
conhecimento dos executivos
e se foram propostas soluções
que podem ser
reaproveitadas.
. Alterações do ambiente
econômico e político podem
impactar a priorização das
soluções propostas.
232
Tá
tico
Processos . Existência de uma
metodologia de gestão de
projetos de software baseada
no guia de boas práticas do
PMI e adaptada às
necessidades e ao nível de
maturidade da organização.
. As metodologias de gestão
de projetos e de software
fornecem diretrizes claras
sobre os processos e
fornecem os templates
necessários para execução das
atividades.
. Processo de gestão de
demandas maduro.
. Ausência de controles que
garantam aderência total ao
uso da metodologia por todos
os colaboradores.
. O processo de identificação
de riscos não é executado de
forma homogênea.
. Criar indicadores de
qualidade de aderência à
metodologia de gestão de
projetos atrelados ao contrato
de metas dos colaborares.
. Fornecedores que utilizam
metodologias próprias não se
adaptarem à metodologia da
organização, principalmente
os fornecedores de pacotes de
software.
Ferramentas . Disponibilidade de uma
ferramenta de gestão de
projetos corporativa de
mercado (Changepoint da
Compuware). A ferramenta
permite gerenciar os projetos
desde a concepção da ideia
até a implantação em
ambiente produtivo, passando
pelas fases de seleção,
priorização, aprovação,
planejamento, execução,
monitoramento, controle e
encerramento do projeto.
. Falta de obrigatoriedade do
uso do registro de riscos da
ferramenta de gestão
integrada de tecnologia.
. Possibilidade de utilizar
templates antigos da
metodologia.
. Em projetos acompanhados
pelo escritório, os riscos são
documentados diretamente
nas fichas de reporte que são
apresentadas nos comitês e
não na ferramenta de gestão.
. Não é possível consultar os
riscos de projetos concluídos,
cancelados e suspensos.
. Treinar as equipes no uso da
ferramenta de gestão de
projetos, principalmente a
funcionalidade de gestão de
riscos (identificação, análise e
monitoramento).
. Disponibilizar o TBQ na
ferramenta de gestão de
projetos.
. Permitir a consulta dos
riscos dos projetos
concluídos, cancelados e
suspensos.
. Criar um catálogo de riscos-
-padrão na ferramenta de
gestão de projetos.
. Ferramenta de gestão de
projetos pouco utilizada no
Brasil.
. Dependência de fornecedor
externo para manutenção da
ferramenta de gestão.
Dimensão Elemento Forças Fraquezas Oportunidades Ameaças
233
Tá
tico
Qualidade . Existe uma base de dados
centralizada de riscos.
. A ferramenta de gestão
possui indicadores que
monitoram os registros de
risco incompletos ou
vencidos.
. As áreas de qualidade,
compliance e auditoria têm as
alçadas e ferramentas
necessárias para garantir tanto
o estabelecimento do
processo de gestão de riscos
de projetos quanto sua
realização pelas áreas
executoras.
. Nem todos os riscos são
documentados na ferramenta
de gestão.
. A auditoria de qualidade dos
documentos exigidos pela
metodologia de gestão de
projetos tem caráter
consultivo.
. Baixa qualidade na
descrição dos riscos.
. Criar indicadores específicos
para monitorar o volume do
uso do registro de riscos.
. Averiguar se os incidentes
em produção foram
previamente identificados
como riscos e devidamente
tratados.
. Alterar a abordagem da
auditoria de qualidade para
caráter punitivo.
. Padronizar a descrição de
riscos utilizando a sugestão
do PMBOK ―Se UMA
CAUSA existe, o EVENTO
pode ocorrer, levando ao
EFEITO‖.
. Novas tecnologias geram
novas incertezas que são
desconhecidas pelas equipes e
não são identificadas.
Comunicação . Cada um dos principais
projetos e programas da
organização comunica aos
executivos seus riscos
relevantes.
. Fluxo de comunicação
periódico já estabelecido
entre as áreas de governança
e o comitê executivo.
. Ausência de monitoramento
dos principais riscos do
portfólio.
. Incorporar a EAR aos
indicadores existentes.
. Não se aplica.
Dimensão Elemento Forças Fraquezas Oportunidades Ameaças
234
Op
era
cio
na
l
Identificação . Existe definição dos papéis e
das responsabilidades. A
responsabilidade pela
elaboração da lista de riscos é
do gestor de projetos, que
deve envolver a equipe e os
demais stakeholders do
projeto nesse processo.
. Colaboradores possuem
clareza sobre a importância
da documentação e gestão de
riscos.
. Registro de riscos é um
documento de preenchimento
obrigatório de acordo com a
metodologia de gestão de
projetos.
. Houve uma melhora no uso
da ferramenta de registro de
riscos no período de janeiro a
fevereiro de 2014 que não se
sustentou.
. Ausência da documentação
de riscos devido a prazos de
projetos apertados que
obrigam os profissionais a
pularem etapas do processo.
. Falta de cultura em gestão
de riscos.
. Somente 6,5% dos projetos
ativos possuem registro de
riscos na ferramenta de gestão
de projetos.
. Tornar obrigatório na
ferramenta de gestão
integrada o preenchimento do
TBQ para os projetos acima
de 500 horas. Dessa forma,
fica garantido que o processo
de identificação será
contemplado no projeto.
. Organizar workshops
específicos sobre gestão de
riscos de projetos para educar
as equipes.
. A inexistência da gestão de
riscos faz com que a gestão
de problemas se torne o foco
principal, deslocando de
forma não planejada os
profissionais de suas
atividades do projeto para
solucionar questões urgentes.
Análise . Ferramenta de gestão
integrada garante que o risco
identificado siga todo o fluxo
de análise.
. A categorização de riscos é
um conceito desconhecido
pelas equipes, e a ferramenta
de registro de riscos não
permite categorizar os riscos.
. Devido ao excesso de
otimismo, os profissionais
julgam que os riscos nunca
serão materializados.
. Obrigar os colaboradores ao
preenchimento da categoria
do risco com base no
catálogo-padrão.
. Não se aplica.
Monitoramento . Todo os riscos devem ter um
responsável associado.
. A ferramenta de gestão
integrada possui sofisticados
controles e relatórios de
monitoramento de riscos.
. Não se aplica. . Não se aplica. . Não se aplica.
Nota. Fonte: elaborado pelo autor.
Dimensão Elemento Forças Fraquezas Oportunidades Ameaças
235
A partir da interpretação dos dados deste estudo, aliada à Análise SWOT, é possível concluir que a organização tem avançado
na busca pela excelência em gestão de projetos, com investimentos em metodologias, ferramentas e treinamento de suas equipes;
porém, ainda há espaço para melhorar seus processos de gestão de riscos dos projetos de software.
236
REFERÊNCIAS
Aaltonen, A. (2012). Quantificação de Risco Operacional. Tese de doutorado, FGV - Escola de Administração de
Empresas de São Paulo, São Paulo, SP, Brasil. Disponível:
http://bibliotecadigital.fgv.br/dspace/handle/10438/10246
Agarwal, N., & Rathod, U. (2006). Defining “success” for software projects: an exploratory revelation. International
Journal of Project Management, 24(4), 358–370. doi:10.1016/j.ijproman.2005.11.009
Alberts, Christopher., & Dorofee, Audrey. (2012). Mission risk diagnostic (MRD) method description (CMU/SEI-
2012-TN-005). Recuperado em 15 novembro, 2014 de Software Engineering Institute, Carnegie Mellon
University website: http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=10075
Almeida, M. (2014, fevereiro 1). Problema no Itaú gerou cobrança em dobro na véspera do Ano Novo. Portal IG.
Recuperado em 15 novembro, 2014 de http://economia.ig.com.br/empresas/2014-01-02/problema-em-
sistema-gerou-cobranca-em-dobro-no-itau.html
Aloini, D., Dulmin, R., & Mininno, V. (2007). Risk management in ERP project introduction: review of the
literature. Information & Management, 44(6), 547–567.
Arnuphaptairong, T. (2011, March). Top ten lists of software project risks: Evidence from the literature survey.
Proceedings of the International MultiConference of Engineers and Computer Scientists, Hong Kong,
China, 1.
Bannerman, P. L. (2008). Risk and risk management in software projects: a reassessment. Journal of Systems and
Software, 81(12), 2118–2133.
Bakker, K. de, Boonstra, A., & Wortmann, H. (2010). Does risk management contribute to IT project success? A
meta-analysis of empirical evidence. International Journal of Project Management, 28(5), 493–503.
doi:10.1016/j.ijproman.2009.07.002
Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The case research strategy in studies of information systems. MIS
quarterly, 11(3), 369-386
Bernstein, P. L. (1997). Desafio aos deuses: a fascinante história do risco (16a ed.). São Paulo: Campus.
Bervian, P. A., Cervo, A. L. & Silva, R. da (2007). Metodologia Científica (6a ed.). Sao Paulo: Prentice Hall.
Bethlem, A. (1981). Os Conceitos de Política e Estratégia. RAE-Revista de Administração de Empresas, 21(1), 7-15.
Biancolino, C. A. (2010). Valor de uso do ERP e gestão contínua de pós-implementação: estudo de casos múltiplos
no cenário brasileiro. Tese de doutorado, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível:
http://www.teses.usp.br/teses/disponiveis/12/12136/tde-29112010-152921
Boehm, B. (1989). Software risk management. Michigan: IEEE Computer Society Press.
Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72.
doi:10.1109/2.59
Boehm, B. W. (1991). Software risk management: principles and practices. Software, IEEE, 8(1), 32–41.
Boehm, B. W., & DeMarco, T. (1997). Software risk management. IEEE software, 14(3), 17–19.
237
Bucanac, C. (1999). The v-model [Manual]. Karlskrona, Ronneby, Suécia: University Of Karlskrona. Recuperado
em 15 novembro, 2014, de http://www.bucanac.com/documents/The_V-Model.pdf
Cardoso, R. (2008). Construção de modelos de gestão articulados por modelos de referência: uma investigação
sobre o uso dos modelos de referência de qualidade e excelência. Tese de doutorado, Universidade Federal
do Rio de Janeiro, Rio de Janeiro, RJ, Brasil. Disponível: http://www.gpi.ufrj.br/pesquisa/producao-
academica/tesesdoutorado
Carr, Marvin., Konda, Suresh., Monarch, Ira., Walker, Clay., & Ulrich, F.. (1993). Taxonomy-based risk
identification (CMU/SEI-93-TR-006 ). Recuperado em 15 novembro, 2014 de Software Engineering
Institute, Carnegie Mellon University website: http://resources.sei.cmu.edu/library/asset-
view.cfm?AssetID=11847
Carvalho, M. M. de, & Rabechini, R. Jr. (2011). Fundamentos em gestão de projetos: construindo competências
para gerenciar projetos (3a ed.). São Paulo: Atlas.
Castro, H. G. de, & Carvalho, M. M. de. (2010). Gerenciamento do portfolio de projetos: um estudo exploratório.
Revista Gestão & Produção, 17(2), 283-296.
Chandler, A. D. Jr. (1962). Strategy and structure: chapters in the history of the american industrial enterprise.
Washington: Beard Books. Recuperado em 15 novembro, 2014 de http://books.google.com.br/books?hl=pt-
BR&lr=&id=xvz4WOOYzmAC&oi=fnd&pg=PA1&dq=strategy+ans+structure:+chapters+in+the+history
&ots=df-gssTWxY&sig=Fvfri3zTmIO7hv0GdGPoR3sBi_c
Chapman, C. (1990). A risk engineering approach to project risk management. International Journal of Project
Management, 8(1), 5–16. doi:10.1016/0263-7863(90)90003-T
Chapman, C., & Ward, S. (2004). Why risk efficiency is a key aspect of best practice projects. International Journal
of Project Management, 22(8), 619–632.
Chapman, C., & Ward, S. (2007). Project risk management: processes, techniques and insights. New Jersey: John
Wiley & Sons. Recuperado em 15 novembro, 2014 de http://books.google.com.br/books?hl=pt-
BR&lr=&id=m8JGyqbnWucC&oi=fnd&pg=PR5&dq=managing+project+risk+thamhain&ots=vqC_3wng
G1&sig=N_mC5HvG1Fpq1c7heoSLTxh3674
Chapman, R. J. (1998). The effectiveness of working group risk identification and assessment techniques.
International Journal of Project Management, 16(6), 333–343. doi:10.1016/S0263-7863(98)00015-5
Crawford, L., Hobbs, J. B., & Turner, J. R. (2006). Aligning capability with strategy: categorizing projects to do the
right projects and to do them right. Project Management Journal, 37(2), 38–50.
Deloitte. (2014). O estágio atual da gestão de riscos: estratégias e ações para o crescimento sustentável (2a ed.)
(Relatório de Pesquisa), São Paulo, SP, Deloitte Touche Tohmatsu Limited. Recuperado em 15 novembro,
2014 de http://www2.deloitte.com/content/dam/Deloitte/br/Documents/risk/Pesquisa-
InteligenciaGestaoRiscos2014.pdf
Dey, P. K., Kinch, J., & Ogunlana, S. O. (2007). Managing risk in software development projects: a case study.
Industrial Management & Data Systems, 107(2), 284–303.
Eisenhardt, K. M. (1989). Building Theories from Case Study Research. Academy of Management Review, 14(4),
532–550. doi:10.5465/AMR.1989.4308385
238
Ernawati, T., Suhardi, & Nugroho, D. R. (2012, September). IT risk management framework based on ISO
31000:2009. Proceedings of International Conference on System Engineering and Technology, Bandung,
Indonesia. doi:10.1109/ICSEngT.2012.6339352
Eugênia, A. P., Volkmer, J., & Vasques, R. C. (2006, junho 1). CMMI versão 1.2. ISD Brasil. Recuperado em 25
setembro, 2013 de http://www.isdbrasil.com.br/artigos/artigo_migracao.php
Federação Brasileira de Bancos. (2013a, outubro 08). Bancos apostam em nova função para gerir área de risco.
Recuperado em 9 novembro, 2014 de http://www.febraban.org.br/Noticias1.asp?id_texto=2198
Federação Brasileira de Bancos. (2013b). Pesquisa FEBRABAN de tecnologia bancária 2012. Recuperado em 9
novembro, 2014 de http://www.ciab.org.br/Imagem/PublicacaoItem/PDF/3.pdf
Federação Brasileira de Bancos. (2014). Pesquisa Febraban de Tecnologia bancária 2013. Recuperado em 9
novembro, 2014 de
http://www.febraban.org.br/7Rof7SWg6qmyvwJcFwF7I0aSDf9jyV/sitefebraban/Pesquisa%20FEBRABAN
%20de%20Tecnologia%20Banc%E1ria_2013.pdf
Portaria Normativa n.17, de 28 de dezembro de 2009 (2009). Dispões sobre o mestrado profissional no Brasil.
Diário Oficial da União, DF: Ministério da Educação e Cultura.
Folego, T. (2014, setembro 24). Pane derruba faturamento da Allianz no país. Valor Econômico. São Paulo.
Recuperado em 16 outubro, 2014 de http://www.valor.com.br/financas/3707960/pane-derruba-faturamento-
da-allianz-no-pais
Fortuna, E. (2013). Mercado Financeiro (19a ed.). São Paulo: Qualitymark.
Gil, A. C. (2010). Como elaborar projetos de pesquisa (5ª ed.). São Paulo: Atlas.
Gonzaga, Y. (2013, agosto 26). Brechas em sites do Bradesco e do Banco do Brasil expõem milhões de clientes.
Folha online. São Paulo. Recuperado em 18 abril, 2014 de
http://www1.folha.uol.com.br/tec/2013/08/1331286-brechas-em-sites-do-bradesco-e-do-banco-do-brasil-
expoem-milhoes.shtml
Grembergen, W. V. (2004). Strategies for information technology governance. Hershey, PA: Idea Group Publishing.
Guntamukkala, V., Wen, H. J., & Tarn, J. M. (2006). An empirical study of selecting software development life
cycle models. Human Systems Management, 25(4), 265–278.
Guyer, A. (2012). 3 Tips for Registering Risks. PM Network, 26(11), 61–61.
Han, W. M., & Huang, S. J. (2007). An empirical analysis of risk components and performance on software projects.
Journal of Systems and Software, 80(1), 42–50.
Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for
transforming organizations. IBM systems journal, 32(1), 4–16.
Higuera, R. P., & Haimes, Y. Y. (1996). Software risk management (CMU/SEI-96-TR-012). Recuperado em 15
novembro, 2014 de Software Engineering Institute, Carnegie Mellon University website:
http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=41707
Hillson, D. (2003). Using a risk breakdown structure in project management. Journal of Facilities Management,
2(1), 85–97. doi:10.1108/14725960410808131
Hillson, D. (2013a). Feedback. PM Network, 27(1), 7–7.
239
Hillson, D. (2013b). Implicit and explicit risk management. PM World Journal, 2(10), 1-3.
Hitt, M., Ireland, R. D., & Hoskisson, R. (2014). Strategic Management: Concepts: Competitiveness and
Globalization (11ª ed.). Boston: Cengage Learning.
Holzmann, V., & Spiegler, I. (2011). Developing risk breakdown structure for information technology organizations.
International Journal of Project Management, 29(5), 537–546. doi:10.1016/j.ijproman.2010.05.002
Huang, S. J., & Han, W. M. (2008). Exploring the relationship between software project duration and risk exposure:
a cluster analysis. Information & Management, 45(3), 175–182. doi:10.1016/j.im.2008.02.001
Hughes, G. (2006). Five steps to IT risk management best practices. Risk Management - New York, 53(7), 34–40.
Instituto Brasileiro de Governança Corporativa. (2009). Código das melhores práticas de governança corporativa
(4a ed.). São Paulo: IBGC.
Information Systems Audit and Control Association. (2002). Is auditing guideline IT governance: document G18
[Manual]. Rolling Meadows, IL, USA: Isaca.org. Recuperado em 11 maio, 2014 de
http://www.isaca.org/Knowledge-Center/Standards/Documents/Gx18ITgovernance.pdf
International Organization for Standardization. (2009). ISO 31000:2009 - risk management [Manual]. Geneva,
Suíca: Iso.org. Recuperado em 29 março, 2014 de http://www.iso.org/iso/home/standards/iso31000.htm
International Organization for Standardization; International Electrotechnical Commission. (2006). ISO/IEC
16085:2006 - Systems and software engineering - life cycle processes - risk management (2a ed.) [Manual].
Geneva, Suíca: Iso.org. Recuperado em 29 março, 2014 de
http://www.iso.org/iso/catalogue_detail.htm?csnumber=40723.
Information Technology Governance Institute. (2003). Board Briefing on IT Governance (2a ed.) [Manual]. Rolling
Meadows, IL, USA: Isaca.org. Recuperado em 15 novembro, 2014 de
http://www.isaca.org/restricted/Documents/26904_Board_Briefing_final.pdf
Keeling, R. (2000). Project management: an international perspective. New York City: St. Martin’s Press.
Kerzner, H. (2013). Project management a systems approach to planning, scheduling, and controlling. Hoboken, NJ:
Wiley.
Killen, C. P., & Hunt, R. A. (2009). Project portfolio management maturity model for dynamic environments. The
Australian Institute of Project Management, 1-9. Recuperado em 15 novembro, 2014 de
http://epress.lib.uts.edu.au/research/handle/10453/11281
Killen, C. P., & Hunt, R. A. (2013). Robust project portfolio management: capability evolution and maturity.
International Journal of Managing Projects in Business, 6(1), 131–151. doi:10.1108/17538371311291062
Koolmanojwong, S., & Boehm, B. (2013). A look at software engineering risks in a team project course.
Proceedings of Software Engineering Education and Training, San Francisco, CA, USA, 26. doi:
10.1109/CSEET.2013.6595233
Kotler, P. (2000). Administração de marketing (10a ed.). São Paulo: Prentice Hall.
Lalsing, V., Kishnah, S., & Pudaruth, S. (2012). People factors in agile software development and project
management. International Journal of Software Engineering & Applications, 3(1), 117–137.
doi:10.5121/ijsea.2012.3109
240
Laurindo, F. J. B., Shimizu, T., Carvalho, M. M. de, & Rabechini, R. Jr. (2001). O papel da tecnologia da informação
na estratégia das organizações. Gestão & Produção, 8(2), 160–179.
Leopoldino, C. B., & Borenstein, D. (2011). Componentes de risco para a gestão de projetos de software. Revista
Eletrônica de Administração, 17(3), 636–659.
Lockyer, K., & Gordon, J. (2005). Project management and project network techniques (7a ed.). New York: Prentice
Hall.
Luftman, J. (2000). Assessing business-IT alignment maturity. Strategies for information technology governance,
14(4), 1-51.
Luftman, J. (2003). Assessing IT/Business alignment. Information Systems Management, 20(4), 9–15.
Luftman, J., & Brier, T. (1999). Achieving and sustaining business: IT alignment. California Management Review,
42(1), 109–122.
Luftman, J., Papp, R., & Brier, T. (1999). Enablers and inhibitors of business: IT alignment. Communications of the
AIS, 1(3), 1-10.
Lunardi, G. L. (2008). Um estudo empírico e analítico do impacto da governança de TI no desempenho
organizacional. Tese de doutorado, Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, Brasil.
Disponível: http://www.lume.ufrgs.br/handle/10183/13248
MacLeod, A., MacDonald, P. A., Ybarra, B., Sorlie, T., Foster, B., & Stokka, T. (2010). Assessing the adequacy of
risk management [Manual]. Altamonte Springs, FL, USA: The Institute of Internal Auditors. Recuperado
em 16 novembro, 2014 de
https://na.theiia.org/certification/Public%20Documents/Assessing%20the%20Adequacy%20of%20Risk%2
0Management.pdf
Maguire, S. (2002). Identifying risks during information system development: managing the process. Information
Management & Computer Security, 10(3), 126–134. doi:10.1108/09685220210431881
Man, T. J. (2007). A framework for the comparison of maturity models for project-based management. Tese de
doutorado, Utrecht University, Utrecht, JE, Holanda. Disponível:
http://www.pmwiki.nl/sites/pmwiki.nl/files/Thesis_Tjman_2007.pdf
Marshall, C. (2002). Medindo e gerenciando riscos operacionais em instituições financeiras. Rio de Janeiro:
Qualitymark.
Martins, G. A., & Theóphilo, C. R. (2009). Metodologia da investigação científica para ciências sociais aplicadas
(2a ed.). São Paulo: Atlas.
Maximiano, A. C. A. (2010). Administração de projetos: como transformar ideias em resultados (4a ed.). São Paulo:
Atlas.
McNally, J. S. (2013). The 2013 COSO framework & SOX compliance: one approach to an effective transition
[Manual]). Coso.org. Recuperado em 16 novembro, 2014 de
http://www.coso.org/documents/coso%20mcnallytransition%20article-
final%20coso%20version%20proof_5-31-13.pdf
Melhoramentos. (2011). Michaelis dicionário escolar língua portuguesa (8o ed). São Paulo: Melhoramentos.
Mintzberg, H. (1987). The strategy concept I: five Ps for strategy. California management review, 30(1), 11-24.
241
Miorando, R. F. (2010). Modelo econômico-probabilístico de análise de risco em projetos de TI. Tese de doutorado,
Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, Brasil. Disponível:
http://www.lume.ufrgs.br/handle/10183/28817
Moraes, F. C. C. (2012, abril 25). A educação corporativa na gestão dos bancos no Brasil: um estudo sobre os
valores disseminados e as competências desenvolvidas pelos programas de formação gerencial. Tese de
doutorado, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível:
http://www.teses.usp.br/teses/disponiveis/12/12139/tde-26062012-162129/
Murray, A. (2011). PRINCE2 in one thousand words (White Paper/Setembro, 2011), Londres, Inglaterra, The
Stationery Office. Recuperado em 21 abril, 2014 de
http://www.axelos.com/gempdf/PRINCE2_in_One_Thousand_Words.pdf
Mutton, J. (2012). Do I really need a risk register? Keeping Good Companies, 64(8), 469–475.
Naddeo, A. (2012, janeiro 27). IPVA: troca de bancos e falha em sistema gera confusão no RJ. Terra Brasil.
Recuperado em 18 abril, 2014 de http://economia.terra.com.br/tributos/ipva-troca-de-bancos-e-falha-em-
sistema-gera-confusao-no-rj,b9083cd58176b310VgnCLD200000bbcceb0aRCRD.html
Neverauskas, B., & Čiutienė, R. (2011). The Theoretical Approach to Project Portfolio Maturity Management.
Economics & Management, 16, 845–851.
Office of Government Commerce. (2009). Managing successful projects with PRINCE2 (5a ed.). London: The
Stationery Office.
OGC. (2010). Portfolio, programme and project management maturity model (P3M3). London: The Stationery
Office.
Padovani, M. (2007). Apoio à decisão na seleção do portfólio de projetos: uma abordagem híbrida usando os
métodos AHP e programação inteira. Dissertação de mestrado, Universidade de São Paulo, São Paulo, SP,
Brasil. Disponível: http://www.teses.usp.br/teses/disponiveis/3/3136/tde-08082007-172433
Patah, L. A. (2010). Avaliação da relação do uso de métodos e treinamentos em gerenciamento de projetos no
sucesso dos projetos através de uma perspectiva contingencial: uma análise quantitativa. Tese de
doutorado, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível:
http://www.teses.usp.br/teses/disponiveis/3/3136/tde-17082010-123256/pt-br.php
Pedroso, M. C. (2010). Um modelo de gestão estratégica para serviços de saúde. Tese de doutorado, Universidade
de São Paulo, São Paulo, SP, Brasil. Disponível: http://www.teses.usp.br/teses/disponiveis/5/5137/tde-
24052011-115333/publico/MarceloCaldeiraPedroso.pdf
Pereira, D. (2013, setembro 3). Por falhas em sistema de banco, cartões de servidores continuam bloqueados. Portal
T1 Notícias. Recuperado em 18 abril, 2014 de http://t1noticias.com.br/estado/por-falhas-em-sistema-de-
banco-cartoes-de-servidores-continuam-bloqueados/47079
Peterson, R. (2004). Crafting information technology governance. Information Systems Management, 21(4), 7–22.
Pinto, J. K., & Slevin, D. P. (1988). Project success: definitions and measurement techniques. Project Management
Journal, 19(1), 67–72.
Project Management Institute. (2009). Practice standard for project risk management. Newtown Square, PA: Project
Management Institute.
242
Project Management Institute. (2013a). A guide to the project management body of knowledge: PMBOK® guide (5a
ed.). Newtown Square, PA: Project Management Institute.
Project Management Institute. (2013b). Organizational project management maturity model: OPM3® (3a ed.).
Newtown Square, PA: Project Management Institute.
Project Management Institute; Institute of Electrical and Electronics Engineers. (2013). Software extension to the
PMBOK guide fifth edition. Newtown Square, PA: Project Management Institute.
Porter, M. E. (1997). What is strategy? Harvard Business Review, 75(1), 156–157.
Pressman, R. S. (2011). Engenharia de software: uma abordagem profissional (7a. ed.). Porto Alegre: McGraw-Hill.
PricewaterhouseCoopers. (2012). Insights and trends: current portfolio, programme, and project management
practices (Relatório de Pesquisa/2012), Albany, NY, PricewaterhouseCoopers.
PricewaterhouseCoopers. (2013). 10 minutos sobre por que a atualização do COSO merece a sua atenção (Relatório
de Pesquisa/2013), São Paulo, SP, PricewaterhouseCoopers Brasil.
Rabechini, R, Jr., & Carvalho, M. M. de (2009). Gestão de projetos inovadores em uma perspectiva contingencial:
análise teórico-conceitual e proposição de um modelo. RAI - Revista de Administração e Inovação, 6(3), 63-
78. Recuperado em 9 novembro, 2014, de http://www.revistas.usp.br/rai/article/viewFile/79149/83221
Rabechini, R, Jr., & Carvalho, M. M. de (2013). Relacionamento entre gerenciamento de risco e sucesso de projetos.
Produção, 23(3), 570–581. Recuperado em 9 novembro, 2014, de
http://www.scielo.br/pdf/prod/v23n3/aop_t6_0005_0757.pdf
Ramirez, S. A. (2008). Enterprise-Wide Risk Management and Corporate Governance. Loyola University Chicago
Law Journal 39(1) 571-594. Recuperado em 16 novembro, 2014 de
http://lawecommons.luc.edu/cgi/viewcontent.cgi?article=1094&context=facpubs
Rau, K. G. (2004). Effective governance of IT: design objectives, roles, and relationships. Information Systems
Management, 21(4), 35–42.
Raz, T., Shenhar, A. J., & Dvir, D. (2002). Risk management, project success, and technological uncertainty. R&D
Management, 32(2), 101–109.
Rovai, R. L. (2005). Modelo Estruturado para Gestão de Riscos em Prouetos: Estudo de Múltiplos Casos. Tese de
doutorado, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível:
http://www.teses.usp.br/teses/disponiveis/3/3136/tde-01092006-180244/pt-br.php
Royce, W. W. (1970, August). Managing the development of large software systems. Proceedings of IEEE Western
Electronic Show and Convention, Los Angeles, CA, USA, 26.
Sahlins, M. D. (1990). Ilhas de História. Rio de Janeiro: Zahar.
Salles, C. A. C, Jr., Soler, A. M., Valle, J. A. S. do, & Rabechini, R, Jr. (2010). Gerenciamento de riscos em projetos
(2a ed.). Rio de Janeiro: FGV.
Sambamurthy, V., & Zmud, R. W. (1999). Arrangement for information technology governance: a theory of multiple
contingencies. MIS Quarterly, 23(2), 261–290.
Santos, N. F. Neto (2007). Gerenciamento de riscos dos projetos: uma proposta de modelo de maturidade. Tese de
doutorado, Universidade de Campinas, Campinas, SP, Brasil. Disponível:
http://www.bibliotecadigital.unicamp.br/document/?code=vtls000429484
243
Sarker, S., Xiao, X., & Beaulieu, T. (2012, November). Toward an Anatomy of “Successful” Qualitative Research
Manuscripts in IS: A Critical Review and Some Recommendations. Proceedings of the International
Conference on Information Systems, Orlando, FL, USA, 33.
Schmitz, E. A., Alencar, A. J., & Villar, C. B. (2007). Modelos qualitativos de análise de risco para projetos de
tecnologia da informação. São Paulo: Brasport.
Schwaber, K., & Sutherland, J. (2013). The scrum guide: the definitive guide to scrum: the rules of the game
[Manual]. Boston, MA, USA: Scrum.org. Recuperado em 9 novembro, 2014, de
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf
Shenhar, A. J., & Dvir, D. (2007). Reinventing project management: the diamond approach to successful growth and
innovation. Boston: Harvard Business Review Press.
Shenhar, A. J., Milosevic, D., Dvir, D., & Thamhain, H. (2007). Linking project management to business strategy.
Newtown Square, PA: Project Management Institute.
Silva, A. Netto, & Silveira, M. A. P. da (2007). Gestão da segurança da informação: fatores que influenciam sua
adoção em pequenas e médias empresas. Journal of Information Systems and Technology Management,
4(3), 375–397.
Silva, L. F. C. P. da (2011). Gestão de riscos em tecnologia da informação como fator crítico de sucesso na gestão
da segurança da informação dos órgãos da administração pública federal: estudo de caso da Empresa
Brasileira de Correios e Telégrafos - ECT. Dissertação de mestrado, Universidade de Brasília, Brasília, DF,
Brasil. Disponível: http://repositorio.unb.br/handle/10482/7473
Silva, L. C. F. Jr., Chamon, M. A., & Camarini, G. (2006). Gerenciamento de Risco em Projetos de Tecnologia da
Informação. REAd - Revista Eletrônica de Administração, 12(52), 52-75. Recuperado em 9 novembro,
2014, de http://www.seer.ufrgs.br/read/article/view/40012
Silva, P. C. da (2011). Análise da gestão de riscos em projetos de sistemas de informação. Dissertação de mestrado,
Universidade Federal do Rio Grande do Sul, RS, Brasil. Disponível:
http://www.lume.ufrgs.br/handle/10183/29982
Silva, T. P. da, & Hein, N. (2012, outubro). Análise da Produção Científica Brasileira nos Periódicos de
Contabilidade listados no Qualis/Capes: Bibliometria sobre Risco. Anais do Seminários em Administração,
São Paulo, SP, Brasil, 15.
Silveira, A. D. M. da (2002). Governança corporativa, desempenho e valor da empresa no Brasil. Dissertação de
mestrado, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível:
http://www.teses.usp.br/teses/disponiveis/12/12139/tde-04122002-102056
Sindicado Bancários Bahia. (2013, dezembro 16). Nova falha no sistema do banco do brasil. Sindicado dos
Bancários Bahia. Recuperado em 16 novembro, 2014 de
http://www.bancariosfeira.com.br/noticia.php?id=2092
Sommerville, I. (2011). Software engineering (9a ed.). Boston: Addison-Wesley.
Suresh Babu, G. N. K., & Srivatsa, S. K. (2011). Increasing Success of Software Projects through Minimizing Risks.
International Journal of Research & Reviews in Software Engineering, 1(1) 18-22.
244
Superintendência Nacional de Seguros Privados. (2012). Capital adicional relativo ao risco operacional: Relatório
final. Recuperado em 9 novembro, 2014, de http://www.susep.gov.br/setores-
susep/cgsoa/coris/dicem/arquivos-gt-operacional/2012-10-31-
%20Relatorio%20Final%20de%20Capital%20de%20Risco%20Operacional%20V2.pdf
Thamhain, H. (2013). Managing risks in complex projects. Project Management Journal, 44(2), 20–35.
doi:10.1002/pmj.21325
The Standish Group International. (2013). Chaos manifesto 2013 (Relatório de Pesquisa/2013), Boston, MA, The
Standish Group International. Recuperado em 16 novembro, 2014 de
http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Turner, J. R. (2009). The handbook of project-based management leading strategic change in organizations. New
York: McGraw-Hill.
Vries, E. J. de (2005, May). Episyemology and Methodology in Case Research: A Comparison Between European
and American IS Journals. Proceedings of European Conference on Information Systems, Regensburg,
Germany, 145.
Wegrzynowicz, K., & Stein, S. (2009). GTAG12 - Global technology audit guide: auditing IT projects. Altamonte
Springs, FL: The Institute of Internal Auditors.
Weill, P. (2004). Don’t just lead, govern: how top-performing firms govern IT. MIS Quarterly Executive, 3(1), 1–17.
Wideman, R. M. (1992). Project and program risk management: a guide to managing project risks and
opportunities. Newtown Square, PA: Project Management Institute.
Yin, R. K. (2010). Estudo de caso: planejamento e métodos (4a ed.). Porto Alegre: Bookman.
Zwikael, O. (2009). The relative importance of the PMBOK guide’s nine knowledge areas during project planning.
Project Management Journal, 40(4), 94–103.
245
ANEXO 1 – VISÃO GERAL DA TBRI (TAXONOMY-BASED RISK IDENTIFICATION)
A TBRI é organizada em três níveis: Classe; Elemento e Atributo. A Tabela 42
apresenta a visão geral.
Tabela 42: Visão geral da TBRI – Taxonomy-Based Risk Identification.
Classe / Elemento / Atributo
A. Engenharia
1. Requisito: definição das funcionalidades, necessidades, comportamento e forma de utilização.
Justificativa da viabilidade e estimativa de esforço.
a) Estabilidade – Os requisitos são estáveis?
b) Completude – Existem requisitos que deveriam estar nas especificações e não estão?
c) Clareza – É possível entender os requisitos da maneira como foram escritos?
d) Validade – O desenvolvedor e o cliente entendem a mesma coisa a partir dos requisitos?
e) Viabilidade – Existem requisitos tecnicamente difíceis de serem implementados?
f) Precedente – Existe algum requisito complexo?
g) Escala – O tamanho e complexidade do sistema são uma preocupação?
2. Desenho: tradução dos requisitos em um projeto eficaz respeitando as restrições.
a) Funcionalidade – Existe algum algoritmo especificado que pode não satisfazer os
requisitos?
b) Dificuldade – Alguma parte do modelo depende de premissas irreais ou otimistas?
c) Interfaces – As interfaces Software-Software e Software-Hardware estão bem definidas?
d) Desempenho – Existe alguma preocupação com o desempenho?
e) Testabilidade – Será fácil testar o software?
f) Restrições do hardware – O hardware limita sua habilidade para atender algum
requisito?
3. Código e Teste Unitário: tradução do desenho em código respeitando os requisitos em
unidades individuais.
a) Viabilidade – Os algoritmos e desenhos especificados são fáceis de implantar?
b) Teste – Os testes unitários especificados e o tempo disponível para sua realização são
suficientes?
c) Codificação/Implantação – As especificações dos desenhos estão suficientemente
detalhadas para a codificação?
4. Integração: integração das unidades em um sistema e garantia de que o software atende os
requisitos.
a) Ambiente – O ambiente de teste integrado/homologação permite simular cenários
realistas para demonstrar os requisitos?
b) Produto – Os critérios de aceitação e formalização foram acordados para todos os
requisitos?
c) Sistema – O software será integrado a outros sistemas existentes?
246
Classe / Elemento / Atributo
5. Especialidade: requisitos do produto ou desenvolvimento que exigem conhecimentos
especializados, tais como segurança e confiabilidade.
a) Manutenção – A arquitetura, desenho ou código geram alguma dificuldade para a
manutenção?
b) Confiabilidade – Foram especificados requisitos de disponibilidade?
c) Segurança – Será difícil verificar a qualidade dos requisitos de segurança?
d) Usabilidade – Existe alguma dificuldade no cumprimento dos requisitos de usabilidade?
B. Desenvolvimento
1. Processo: definição, planejamento, documentação, adequação, aplicação e comunicação dos
procedimentos utilizados para desenvolvimento do produto.
a) Formalidade – Existe mais de uma metodologia de desenvolvimento de software (MDS)
sendo usada?
b) Adequação – Foi necessário adaptar a MDS para este projeto/programa?
c) Controle do processo – É possível mensurar se a MDS está cumprindo suas metas de
produtividade e qualidade?
d) Familiaridade – As pessoas estão familiarizados com a MDS?
e) Controle do Software – Há um mecanismo para rastreabilidade dos requisitos, desde a
especificação até a implantação?
2. Método: ferramentas e equipamentos de apoio usados no desenvolvimento, tais como
simuladores, ferramentas, compiladores e plataformas.
a) Capacidade – Há recursos suficientes para as fases de pico de demanda, tais como
construção e testes?
b) Usabilidade – As pessoas entendem que as ferramentas de desenvolvimento são fáceis de
usar?
c) Familiaridade – As pessoas já conhecem as ferramentas de desenvolvimento?
d) Confiança – As ferramentas de desenvolvimento são consideradas seguras?
e) Suporte – Existe suporte às ferramentas de desenvolvimento?
3. Gestor: experiência do gestor em planejamento e controle da comunicação, custo, escopo,
prazo e qualidade de um projeto de software.
a) Planejamento – O projeto/programa está sendo gerenciado de acordo com o planejado?
b) Organização do projeto/programa – As pessoas entendem seus papéis e dos outros
envolvidos no projeto/programa?
c) Experiência em gerenciamento – O projeto/programa possui gestores experientes?
d) Interfaces do projeto/programa – A gestão comunica os problemas nas alçadas
competentes?
4. Gestão: métodos e ferramentas de apoio para gerenciar o projeto, tais como gestão de projetos,
gestão de configuração, garantia de qualidade e gestão de pessoas.
a) Monitoramento – Há boletins de status periodicamente estruturados?
b) Gestão de pessoas – O pessoal está treinado de acordo com as competências requeridas
para o projeto/programa?
c) Garantia de Qualidade – Existem mecanismos definidos para assegurar a qualidade?
d) Gestão da configuração – Existe um adequado sistema de gestão das configurações?
247
Classe / Elemento / Atributo
5. Cultura: cultura organizacional onde o trabalho será realizado, incluindo as atitudes das
pessoas e os níveis de cooperação, comunicação e moral.
a) Atitude de qualidade – O cronograma é suficiente para atender a qualidade esperada
pelo cliente?
b) Cooperação – As pessoas trabalham cooperativamente através das fronteiras funcionais?
c) Comunicação – Há boa comunicação entre os membros do projeto/programa?
d) Moral – Há algum problema em reter as pessoas que você precisa?
C. Restrição
1. Recursos: restrições externas impostas com relação ao prazo, orçamento ou pessoal.
a) Cronograma – Há dependências externas que podem vir a impactar o cronograma?
b) Equipe – Há alguma área em que as habilidades técnicas estão em falta (engenharia de
software, análise de requisitos, arquitetura, desenho físico, desenho lógico, linguagens de
programação, testes, gestão de configurações, garantia de qualidade, bases de dados,
domínio da aplicação ou análise de desempenho)?
c) Orçamento – Há recursos ou funções sendo excluídos para reduzir o custo?
d) Instalações – As instalações de desenvolvimento são adequadas?
2. Contrato: termos e condições do contrato do projeto.
a) Tipos de contrato – Quais os tipos de contrato existentes no projeto/programa (preço
fixo, custo + remuneração, etc.)?
b) Dependências – Há dependências de produtos externos ou serviços que podem afetar a
qualidade, orçamento ou cronograma?
3. Interface: relacionamento com os clientes, áreas corporativas e fornecedores.
a) Cliente – O tempo de aprovação do cliente é adequado? O mecanismo para chegar a
acordos com o cliente é efetivo?
b) Gestão executiva – A gestão do projeto/programa comunica os problemas para as alçadas
competentes?
c) Fornecedores – Existe confiança nos fornecedores para entrega de componentes críticos?
d) Política – As políticas da organização estão afetando o projeto/programa? Nota. Fonte: Carr et al., 1993.
248
ANEXO 2 – VERSÃO REDUZIDA DA LISTA GTAG12
A Tabela 43 apresenta uma versão reduzida da lista.
Tabela 43: Lista de assertivas sugeridas pelo GTAG12.
Área-chave / Agrupamento / Assertiva
Alinhamento Estratégico
1. Business Case 1.1. Gestão do Business Case – As previsões de custos e benefícios são realistas.
1.2. Custos do projeto – Um método padrão de estimativa é utilizado para todos os
pacotes de trabalho.
2. Plano de Projeto
2.1. Objetivo e escopo – O escopo do projeto está claramente definido e possui nível de
detalhes suficiente.
2.2. Estimativas, cronograma e escopo – Entender se as estimativas têm mudado ao
longo do projeto e qual o motivo.
3. Comunicação e Coordenação do Projeto
3.1. Comunicação e gestão da mudança – Todos conhecem o objetivo do projeto e o
cronograma de eventos.
3.2. Organização – Os papéis na organização estão definidos.
MDS – Metodologia de Desenvolvimento de Software
4. Desenho do Processo
4.1. Escopo de negócios – As regras de negócios estão definidas e validadas.
4.2. Desenho do processo – O desenho do processo está documentado.
5. Configuração e Desenvolvimento
5.1. Protótipos – Telas, relatórios e customizações estão documentados.
5.2. Configuração – Configuração das tabelas críticas foram revistas e estão
documentadas.
6. Aceite do Usuário
6.1. Homologação – A área de negócios está adequadamente envolvida para garantir
testes realistas.
6.2. Lista de problemas – Todos os problemas identificados foram corrigidos e possuem
aceites.
7. Transição
7.1. Plano de conversão de dados – Os dados convertidos são reconciliados com os
dados dos sistemas legado.
7.2. Manutenção paralela de dados – Verificações são realizadas para garantir que a
manutenção paralela de dados é realizada corretamente.
249
Área-chave / Agrupamento / Assertiva
8. Infraestrutura Técnica
8.1. Interfaces de usuário – Procedimentos de logon foram verificados.
8.2. Impressoras – Todas as impressoras foram configuradas e testadas no novo software.
Mudança Organizacional
9. Simulação de Negócios
9.1. Preparação – O ambiente técnico está disponível.
9.2. Completude – Todos os cenários de negócios críticos foram executados com
sucesso.
10. Manutenção de Dados e Pós Implantação
10.1. Usuários – Os usuários foram treinados.
10.2. Manutenção de Dados – Existem procedimentos para cada tipo de inclui/atualiza.
11. Papéis e Perfis
11.1. Perfis de acesso – Os perfis de acesso foram desenvolvidos e testados.
11.2. Riscos do negócio – Não existe nenhum problema relevante.
12. Treinamento do Usuário
12.1. Impacto – Todos os usuários entendem como seu trabalho será impactado pela
solução.
12.2. Treinamento – Os usuários foram treinados adequadamente.
Pós-implantação
13. Equipe Técnica
13.1. Competências – A equipe do projeto possui as competências técnicas necessárias.
13.2. Localização – A equipe do projeto é facilmente acessível.
14. Área de Negócios
14.1. Papéis – Cada área de negócios possui um ponto focal para o projeto.
14.2. Planejamento – Existe planejamento para treinamento, migração dos dados,
acompanhamento e encerramento do projeto.
15. Implantação em Ambiente Produtivo
15.1. Operação – Existe um plano para transferência do conhecimento.
15.2. Manutenção – Equipe de manutenção está preparada para receber o novo sistema.
16. Transição para o Suporte
16.1. Estratégia – A equipe de primeiro nível de suporte está devidamente treinada.
16.2. Correções em Produção – O processo para aplicação de correções em ambiente
produtivo está formalizado.
17. Plano de Continuidade do Negócio
17.1. Plano de Continuidade – O processo de contingência está devidamente
formalizado. Nota. Fonte: Wegrzynowicz & Stein, 2009.
250
APÊNDICE 1 – ROTEIRO DE ENTREVISTA
O roteiro para realização das entrevistas semiestruturadas está subdividido em duas
partes. A primeira parte pode ser observada na Tabela 44 e tem por objetivo a identificação dos
entrevistados, a obtenção de informações gerais sobre a atuação do mesmo na organização e a
coleta de impressões dos entrevistados sobre o tema.
Tabela 44: Parte 1 – Dados do entrevistado.
Dado do entrevistado Resposta
Nome
Área
Cargo/Função
Tempo na área
Tempo na empresa
Formação
Telefone
Nota. Fonte: elaborado pelo autor.
A segunda parte pode ser consultada na Tabela 45 e é constituída pelo conjunto de
questões elaboradas por meio da revisão da literatura sobre o tema abordado. A partir da coleta
destes dados buscar-se-á as evidências empíricas para corroborar as proposições elaboradas para
responder a questão de pesquisa.
Tabela 45: Parte 2 – Roteiro de entrevista.
Proposição Questões
1 – Registro de Riscos 1 – Como os riscos de projetos são documentados na organização?
R:
2 – Categorização de Riscos
2a – Os riscos são categorizados?
R:
2b – Em caso positivo, quais são as categorias de risco utilizadas?
R:
3 – Processo Imaturo de Gestão
de Riscos
3a – Para os projetos sem riscos documentados, por que os riscos não são
documentados na ferramenta de gestão integrada de tecnologia?
R:
3b – Para os projetos sem riscos documentados, como os riscos são gerenciados?
R:
4 – Categorização de Projetos
4a – Como os projetos são categorizados?
R:
4b – Como os projetos são priorizados?
R:
251
Proposição Questões
5 – Riscos em Projetos de
Software
5a – Quais os principais riscos dos projetos de software?
R:
5b – Como são planejadas as respostas aos riscos?
R:
5c – Como os riscos são monitorados?
R:
6 – Lista de Riscos 6 – Como os riscos são identificados?
R:
7 – Sucesso em Projetos 7 – Quais os critérios utilizados para avaliar o sucesso do projeto?
R:
8 – Visão Estratégica de Riscos 8 – Como os riscos dos projetos são apresentados aos executivos?
R:
Nota. Fonte: elaborado pelo autor.
