Modelo de gestão de riscos para projetos de software no setor bancário

Texto

(1)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.

(2) 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ósGraduaçã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.

(3) 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.

(4) 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ósGraduaçã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..

(5) DEDICATÓRIA Dedico esta dissertação a Cynthia Izumi Yamauchi Terlizzi..

(6) 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!.

(7) 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..

(8) 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..

(9) 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.

(10) 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.

(11) 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.

(12) 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.

(13) 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.

(14) 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.

(15) 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.

(16) TBQ: Taxonomy-Based Questionnaire TBRI: Taxonomy-Based Risk Identification TI: Tecnologia da Informação.

(17) 17. 1. 1.1. INTRODUÇÃO. 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) 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, notase 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) 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) 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) 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) 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) 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). Fraude interna. 2008. Societé Generale. 6.750. Fraude interna. 1995. Barrings. 1.298. Fraude externa. 1999. Republic New York. 611. Falhas em sistemas. 2004. Sumitomo Mitsui. 350. Merril Lynch. 250. Bank of New York. 140. Demandas 2004 trabalhistas Danos a ativos 2001 físicos Nota. Fonte: Aaltonen, 2012.. Descrição Manipulação dos registros de negociação de operações ocultou perdas no mercado de futuros, que se acumularam. Manipulação dos registros de negociação de operações ocultou perdas no mercado de derivativos, que se acumularam. Fraude cometida por cliente de custódia. Uso de key-logger, programa capturador do que se digita para acesso a senhas e desvio de recursos. Acordo extrajudicial por discriminação a mulheres no trabalho. Danos monetários pelo atentado de 11 de setembro.. 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) 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 Terra. Data 27/01/2012. Portal T1 Notícias. 09/03/2013. Folha de São Paulo. 26/08/2013. Folha de São Paulo. 10/12/2013. Sindicato dos Bancários Bahia. 16/12/2013. Portal IG. 02/01/2014. Valor Econômico. 24/09/2014. Notícia 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). 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). 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). 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). 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). 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). 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) 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) 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) 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) 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) 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 Aderência a regras Tributário e fiscal Trabalhista Ética, fraude e canal de denúncia Fluxo de caixa Reputação e imagem Segurança da informação Concorrência e mercado Alçadas de aprovação Gestão de contratos Investimentos e projetos Nota. Fonte: Deloitte, 2014.. Riscos reportados ao mercado Condições econômicas e tendências de indústria Mercados Leis e regulamentações Concorrência Geopolítica Ambiental, saúde e segurança Compliance legal e regulatório Gestão de contratos Litígios e resolução de conflitos Perigos e perdas catastróficas Reputação e relacionamento com as partes interessadas. 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) 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) 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) 32. 2. 2.1. REFERENCIAL TEÓRICO. 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) 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 manterse 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.