NOVOS RISCOS PARA A GESTÃO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO COM EQUIPES LOCAIS NEW RISKS FOR INFORMATION TECHNOLOGY PROJECT MANAGEMENT WITH LOCAL TEAMS Glória Júnior, Irapuan, Chaves, Marcirio Silveira. Universidade Nove de Julho - UNINOVE, Brasil.
Resumo Este estudo identifica riscos novos e potencializados em projetos de Tecnologia da Informação (TI) com equipes locais. O caráter é exploratório no tocante ao levantamento dos riscos junto aos gerentes de projeto de empresas de diversos setores, onde foram confrontados os riscos encontrados na literatura com os elencados nas entrevistas. Os resultados incluem os riscos que foram identificados pelos entrevistados e ausentes na literatura, denominados riscos novos, e os riscos que foram mencionados significativamente pela literaturae pela pesquisa, denominados riscos potencializados. A implicação para a prática permite às empresas incluirem em suas gestões de riscos dos projetos de TI os riscos novos identificados e maior atenção aos riscos potencializados indicados neste trabalho, e assim permitir a criação de planos de mitigação. A contribuição teórica é a identificação de riscos adicionais ao estado da arte na área de gestão de projetos de TI.
Palavras-chave Gestão de Projetos; Projetos de TI; Identificação de Riscos; Riscos; Gestão de Riscos.
Abstract This study identifies new and leveraged risks in Information Technology (IT) projects with local teams. It is an exploratory survey regarding the risks identified with project managers from various sectors where the risks found in the literature were faced with those found in the interviews. The results include the risks identified by respondents and absent in the literature, called new risks, and the risks significantly mentioned by literature and research, called leveraged risks. The implication for practice allows companies to include in their management the new risks of IT projects and taking more attention to the leveraged risks indicated in this work, and thus Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 16
allow the creation of mitigation plans. The theoretical contribution is the identification of additional risks to the state of the art in the IT project management field.
Keywords Project Management; IT Projects; Risk Identification; Risks; Risk Management.
1.
Introdução
Diante do alto número de projetos que culminam em insucesso entre as empresas (1), a necessidade de identificação e o gerenciamento de riscos com o intuito de auxiliar na mudança deste panorama é imperativo (2; 12). Todos os projetos possuem riscos que são gerados na incerteza (1; 12), mas aqueles que possuem maior dependência tecnológica são propensos a terem um número maior de riscos (1). Os projetos de tecnologia da informação (TI) visam contribuir para que as empresas consigam mais rapidamente suprir suas necessidades (3; 4) e respondam ao mercado com maior velocidade (2). Possuem como característica marcante um alto grau de incerteza tecnológica durante sua execução (2; 1), portanto, detentores de um número maior de riscos. Na literatura é possível encontrar diversos riscos já identificados em projetos de TI (5; 6; 7; 8; 9; 10; 11; 21; 23), mas devido à contínua evolução tecnológica do mercado (3) riscos novos tendem a surgir.Desta forma, pode existir um crescente número de riscos, denominados riscos novos, sendo gerados mediante a evolução tecnológica que é disponibilizada nos projetos. Por outro lado, riscos rotulados como potencializados, podem ter ênfase na literatura e serem muito citados pelos gerentes de projeto. Assim, surge a necessidade de responder a questão de pesquisa: Quais são os riscos novos e potencializados em projetos de TI?
2.
Objetivos
Baseado na questão de pesquisa, esse artigo tem os seguintes objetivos: (i) revisitar os principais riscos em projetos de TI encontrados na literatura; (ii) elencar os principais riscos atualmente identificados por gestores de projetos de TI; e (iii) apresentar os riscos novos e potencializados nos projetos de TI. As justificativas para desenvolver a pesquisa são as seguintes: -
Relevância do tema: os riscos estão em todos os projetos (12) e há poucas ferramentas disponíveis para ajudar os gerentes de projeto para identificar e categorizar os fatores de risco (6) que são essenciais, sobretudo em projetos de TI (2);
-
Relevância dos objetivos do estudo: A evolução tecnológica constante (3; 4) pode criar riscos novos (1), no qual gera a necessidade dos gerentes de projetos de TI usarem todas as alternativas disponíveis para a identificação dos riscos (12); Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 17
-
Contribuição para a academia: incluir os riscos novos identificados por gestores de projetos no estado da arte da área de Gestão de Riscos e enfatizar a necessidade de estudos em profundidade (pesquisa-ação, por exemplo) sobre os riscos potencializados.
A próxima seção do trabalho compreende o referencial teórico, cujos temas são os projetos de TI e a gestão dos riscos. A seção três traz a metodologia e os procedimentos de pesquisa adotados. A seção quatro descreve a análise dos resultados. A seção cinco apresenta uma discussão, as limitações e as futuras pesquisas. A seção seis conclui o artigo.
3.
Referencial Teórico
O conjunto de processos a fim de suprir um objetivo ou um conjunto de objetivos é denominado projeto (12). Nos casos de desenvolvimento de sistemas, o produto é um sistema computacional e, em relação a projetos de infraestrutura de TI, são ações relacionadas a servidores, comunicação e outros (3; 4). As características do software são especificadas nos requisitos do projeto e as limitações, como a linguagem computacional a ser utilizada ou sistema operacional do servidor de dados, no item de restrições (12). O risco é um evento ou uma condição incerta que pode afetar pelo menos um objetivo do projeto, podendo ocasionar um ou mais impactos com possibilidade de resultados negativos ou positivos (2; 12). O risco pode ter como origem um requisito, uma premissa, uma restrição ou uma condição no projeto. A origem dos riscos está na incerteza existente em todos os projetos. Os riscos conhecidos são aqueles que foram identificados e analisados, possibilitando o planejamento de respostas. Em alguns casos não podem ser gerenciados de forma proativa, o que sugere que a equipe do projeto deve criar um plano de contingência. Um risco do projeto que já ocorreu também pode ser considerado um problema (12). Identificar os riscos é um processo de determinação de situações que podem afetar o projeto. Os participantes das atividades de identificação de riscos podem incluir o gerente do projeto, os membros da equipe do projeto, a equipe de gerenciamento dos riscos designadas, clientes, especialistas no assunto que são externos à equipe do projeto, usuários finais, outros gerentes de projetos, partes interessadas e especialistas em gerenciamento de riscos. Embora essas pessoas em geral sejam os principais participantes da identificação dos riscos, todo o pessoal do projeto deve ser estimulado a fazê-lo (12). O Gerente de Projetos deve realizar a identificação dos riscos o mais breve possível para que possa corroborar no gerenciamento e controle, pois a falta desse processo auxilia para o insucesso dos projetos (12; 13). O gerente de projetos deve considerar que a percepção dos riscos pode vir por meio de ferramentas, técnicas e experiências de outros projetos (14; 15). Existem várias técnicas de identificação dos riscos (12), tais como: (i) Brainstorming como forma de criação de sugestões dos participantes; (ii) Técnica Delphi com reuniões com especialistas; (iii) Entrevistas de participantes experientes dentro e fora do projeto; (iv) análise da Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 18
causa-raiz com análise da origem dos riscos; (v) uso de diagramas como o Diagrama de Causa e Efeito, Fluxogramas, Diagrama de Influência e outros; (vi) análise de SWOT como forma de mapear as fraquezas, forças, ameaças e oportunidades. A identificação inadequada de riscos pode contribuir para o insucesso do projeto (14; 16), sendo relevante avaliar e compreender os contextos externos e internos das organizações que influenciam significativamente a identificação dos riscos (17). Os gerentes de projetos devem investigar os tipos de riscos e meios plausíveis de mitigação (12). Deve-se também considerar a natureza do negócio e a necessidade de atingir os objetos da organização, visto que cada empresa está exposta a um conjunto de riscos específicos e sua abordagem deve ser consistente para cada projeto, onde a comunicação sobre os riscos e como lidar com eles devem ser abertas e sinceras (18). As respostas aos riscos refletem o equilíbrio da organização entre correr riscos e evitar riscos (12). Existemsituações que as experiências dos gerentes de projetos poderão influenciar negativamente na capacidade de julgamento dos riscos no qual, mesmo que o projeto apresente falhas e haja um descompasso, continuarão a acreditar que está tudo sob controle e esquecendo que se trata de uma nova situação, principalmente se a equipe é diferente (13). Finalmente, as empresas e os stakeholders estão dispostos a aceitar vários graus de riscos dependendo do grau de tolerância (12), desde que estejam dentro de seus limites e em equilíbrio com as recompensas que podem ser obtidas ao assumi-los (2; 12).
4.
Metodologia
Este artigo de natureza qualitativa e indutiva possui uma abordagem exploratória com o objetivo de aprofundar o conhecimento sobre o problema a fim de torná-lo evidente (19). Realizou-se um estudo de caso múltiplo (20) de seis projetos de TI. A coleta de dados consistiu de entrevistas a cinco gerentes de projetos e também incluiu a pesquisa documental com análise de artefatos dos projetos encerrados mencionados pelos gerentes de projetos. Uma análise de conteúdo foi realizada, pois é onde a análise adquire maior valor com o apoio do referencial teórico para a construção das categorias utilizadas neste estudo (19). A escolha das empresas para a pesquisa considerou a dependência tecnológica de seu core business e a maturidade em gestão de projetos. As entrevistas foram feitas por meio de um roteiro com perguntas semi-estruturadas. 4.1
Processo de Pesquisa
O processo da pesquisa consistiu em análise dos artefatos de projetos com vistas ao estabelecimento do referencial da gestão dos riscos em diversos projetos de TI encerrados (19). Os processos realizados estão dispostos na Figura 1, onde se podem encontrar os seguintes passos:
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 19
Processo 1. Elencar Riscos em Projetos de TI na Literatura. A partir da consulta ao estado da arte foram identificados riscos em projetos de TI com equipes locais. A escolha de projetos que possuem sua equipe no mesmo espaço geográfico deve-se a dois motivos: (i) os Gestores de Projetos entrevistados possuíam a equipe com essa característica; e (ii) para deixar explícito que não serão abordados projetos com equipes globais, que possuem características específicas, principalmente de riscos relacionados a conflito de culturas. A pesquisa considerou os artigos que eram das áreas de gestão de projetos e desenvolvimento de sistemas e publicados em periódicos relevantes no período de 1991 a 2013: Arabian Journal of Business and Management Review, IEEE, International Journal of Project Management, Journal of Management Information Systems, Journal of Management Research, Journal of Systems and Software, Journal of Theoretical & Applied Information Technology, Project Management Journal e South African Journal of Industrial Engineering; Processo 2. Categorização dos Riscos Elencados. Após os itens levantados foi realizada a categorização dos riscos; Processo 3. Entrevistas com os Gerentes de Projetos de TI. Um questionário semiestruturado foi aplicado aos Gerentes de Projeto de TI em relação ao último projeto, sejam eles casos de sucesso ou fracasso. Apenas um gerente de projetos relatou os dois últimos; Processo 4. Lista de Riscos Levantados pelos Gerentes de Projetos de TI. A partir das respostas foram elencados os riscos identificados pelos respondentes; Processo 5. Levantamento Documental de Riscos. Os artefatos documentais dos projetos são analisados e os riscos contidos são listados para análise de conteúdo; Processo 6. Eliminação de Riscos Duplicados. Os riscos encontrados nos artefatos e nas entrevistas nos quais a semântica era equivalente foram unificados; Processo 7. Adição de Riscos Divergentes. Os riscos encontrados com semântica diferente foram conjuntamente considerados; Processo 8. Classificação dos Riscos Levantados pelos Gerentes de Projetos de TI. Após a listagem pronta foram classificados os riscos nas categorias geradas no processo 2; Processo 9. Identificação dos Riscos Novos e Riscos Potencializados. Confrontando os riscos levantados na literatura com os riscos obtidos pela pesquisa houve duas possibilidades: a de riscos novos e riscos comuns, denominados de potencializados.
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 20
Elencar Riscos 1 em Projetos de TI na Literatura
5
2
Categorização dos Riscos Elencados
6
Eliminação de Riscos Duplicados
Levantamento Documental de Riscos 7
Entrevistas com os Gerentes de Projetos de TI
Lista com Riscos Levantados pelos 4 Gerentes de Projetos de TI
Classificação dos Riscos 8 Levantados pelos Gerentes de Projetos de TI
Identificação dos Riscos Novos e 9 Riscos Potencializados
3
Adição de Riscos Divergentes
Figura 1 - Procedimento da Pesquisa Fonte: os autores
4.2
Categorização e Classificação
A categorização ou agrupamento é um processo estruturalista que envolve o inventário, com o isolamento das unidades de análise e a classificação das unidades comuns com a identificação das categorias (19). Existem várias formas de agrupar os riscos em projetos de TI, como a criação de categorias de acordo com o enfoque: financeiro, técnico, comportamental, político, gerencial e legal de riscos (10). Outra maneira encontrada é por meio de cinco grandes grupos: Técnica, Programática, Suporte, Custos e Cronograma (2). A taxonomia foi realizada através de: (i) levantamento dos riscos encontrados na literatura a respeito de projetos de TI; (ii) cada risco recebeu um termo de acordo com o enfoque encontrado; (ii) reunir termos semelhantes em categorias. As aglutinações iniciais dos riscos levantados geraram as seguintes categorias: gestão de projetos, equipe, tecnologia e stakeholders. Analisando mais detalhadamente foram detectadosque muitos dos riscos em gestão de projetos eram referentes ao escopo e que mereciam a atenção devida, consequentemente foi crida a categoria escopo e os itens pertinentes foram reposicionados. Os riscos na categoria tecnologia diferiam quanto aos aspectos do tipo de projeto se de desenvolvimento ou infraestrutura. Portanto, foram particionados em duas novas categorias referente ao desenvolvimento e a infraestrutura, e eliminada a categoria tecnologia. Em situação semelhante estavam os riscos encontrados na categoria stakeholders, onde haviam vários pertinentes à organização, mas do ponto de vista interno. Esses riscos foram separados em uma Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 21
nova categoria denominada organização. Por fim, a lista resumiu-se às categorias: escopo, infraestrutura, desenvolvimento, equipe, gestão de projetos, stakeholders e organização. Em relação à categoria escopo foram designados os riscos relativos ao escopo, seus requisitos e aos processos. A categoria gestão de projetos é composta pelos riscos relativos à gestão de projetos e todas as funções e responsabilidades pertinentes ao gerente de projetos. A reunião dos riscos relativos à integração, relacionamento com outras pessoas, o nível do conhecimento técnico e o comportamento dos membros estão na categoria equipe. Os riscos relativos ao desenvolvimento de sistemas, integração com sistemas legados, análise de sistemas, utilização de componentes e a dinâmica na elaboração computacional foram reunidas na categoria denominada desenvolvimento. Na categoria infraestrutura foram reunidos os riscos referentes aos riscos de infraestrutura de TI, com abrangência da implantação de um servidor, instalação de software e a comunicação entre sistemas no meio físico. A categoria stakeholders recebeu os riscos relativos aos interessados no projeto, seus comportamentos, anseios e demais características que os envolvidos possam ter ou serem submetidos. Os riscos relativos ao ambiente externo e interno, estrutura e gerenciamento do cliente estão sob a categoria organização. O resultado deste trabalho será a identificação dos riscos novos e dos riscos potencializados. Os riscos novos são aqueles que foram mencionados pelos gerentes de projetos, mas não foram mencionados na literatura. Os riscos potencializados são aqueles que possuem relevância na literatura e na pesquisa realizada e que merecem atenção redobrada por parte dos gerentes de projetos, onde os critérios usados para a escolha foram: (i) o risco identificado na pesquisa deverá ter referência equivalente na literatura; (ii) deve ter sido citado na literatura por 40% dos autores utilizados, portanto, por pelo menos cinco autores; (iii) ter ao menos 40% de referência dos gerentes de projetos da pesquisa, portanto com ao menos duas referências.
5.
Análise dos Resultados
A pesquisa resultou na criação de duas listas de riscos: uma encontrada na literatura e outra obtida através da aplicação de entrevistas. Na literatura foram identificados 59 riscos com 178 menções realizadas pelos autores e na pesquisa foram elencados 49 riscos com 64 menções feitas pelos gerentes de projetos. 5.1
Respondentes
Os respondentes são gerentes de projetos e as empresas são de diversos setores e contribuíram com os riscos em seus projetos, conforme os dados dos respondentes na Figura 2. As empresas selecionadas foram aquelas que possuem total dependência com a tecnologia, como o setor bancário e de TI, ou que o negócio possui grande dependência para sua operacionalização, como o setor de varejo.
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 22
Respondente R1 R2 R3 R4 R5
Setor
Projetos - Troca de Servidor de e-mails Tecnologia de Informação - Software de gestão de documentos digitalizados - Novo sistema de seguros Bancário - Instalação de um novo Centro de Processamento de Dados Varejo - Instalação e customização de um Enterprise Resource Tecnologia de Informação Planning Tecnologia de Informação - Customização de um Enterprise Resource Planning
Figura 2 - Perfil dos respondentes e seus projetos Fonte: os autores
O Respondente 1 (R1) pertence a uma empresa do setor de TI, onde os riscos apresentados foram de dois projetos, um relacionado a uma troca de servidor de e-mails e outro projeto de instalação de software de gestão de documentos digitalizados. O Respondente 2 (R2) pertence a uma empresa do setor bancário onde relatou os riscos de um projeto de um novo sistema de seguros. O Respondente 3 (R3) está em uma empresa do setor de varejo de um projeto de instalação de um novo centro de processamento de dados. O Respondente 4 (R4) pertence à outra empresa do setor de TI de um projeto de instalação e customização de um Enterprise Resource Planning (ERP). O outro gerente de projetos entrevistado, denominado Respondente 5 (R5), atua em uma consultoria em TI em um projeto de customização de ERP. 5.2
Riscos Identificados
Os riscos elencados tanto na literatura quanto com os gerentes de projetos na pesquisa não consideraram se os projetos foram casos de sucesso ou fracasso, mas apenas se eram projetos de TI. Todos os riscos que não eram relativos a equipes que estavam fisicamente no mesmo local foram desconsiderados. A partir da identificação na literatura e nas entrevistas, os riscos foram aglutinados em tabelas por categorias. Todos os riscos foram identificados por um código (ID) composto por duas posições alfanuméricas: (i) primeira posição alfanumérica correspondedo a origem se os dados foram obtidos pela literatura L (literature) ou se através das entrevistas S (survey); (ii) categoria referente aos riscos: E (escope) para escopo, P (project) para gestão de projetos, T (team) para equipe, D (development) para desenvolvimento de sistemas, I (infrasctructure) para infraestrutura em TI, S (stakeholder) para os envolvidos no projeto e O (organization) para a organização. Em seguida é atribuído um número sequencial para melhor referência durante o texto. Nos casos em que um risco não possuia nenhuma referência, quer seja pela literatura ou pelos gerentes de projeto, foi atribuído o rótulo "Não Mencionado". A Figura 3 refere-se aos riscos da categoria escopo que possuem mais referências na literatura. Esses riscos incluem o dinamismo do ambiente (LE01, LE02 e LE07), o que deve ser Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 23
entendido (LE04 e LE05) e a maturidade dos processos (LE06). Quanto às entrevistas com os gerentes de projeto, esses se preocupam muito com o entendimento do escopo (LE04), com a falha na identificação das regras de negócio (LE05) e com a falta de avaliação das customizações (SE01). A categoria gestão de projetos está relacionada na Figura 4 que possui atenção especial por parte dos autores aos riscos relacionados à falha na aplicação da metodologia de gestão de projetos (LP02, LP03, LP04, LP06, LP07, LP11, LP12, LP13, LP14 e LP15), o comportamento do gerente de projetos (LG10 e LG13), seu perfil (LP01) e sua habilidade na gestão de riscos (LP08) e gestão de conhecimento (LP09). Já os gerentes de projetos mencionaram com mais veemência a falha em atender ao cronograma (LP03), a falha na gestão de projetos (LP04) e a reprovação por um órgão regulador (SP01). A Figura 5 lista os riscos da categoria equipe, os quais possuem forte direcionamento na literatura pela falta de competência técnica da equipe (LT01), de forma amena o tamanho da equipe (LT03, LT07), os aspectos de relacionamento entre os membros (LT02, LT04, LT06, LT08, LT09) e maturidade (LT05). Em relação ao resultado das entrevistas, não foi encontrada nenhuma tendência, apenas riscos relacionados a ações em campo (ST01), a troca de equipamentos (ST02) e a troca de equipe em determinadas situações (ST03). Os riscos identificados em desenvolvimento de sistemas na literatura estão elencados na Figura 6 sob a categoria desenvolvimento. Eles incluem a entrega periódica e antecipada dos produtos quando utilizada alguma metodologia ágil (LD06, LD07 e LD09), a gestão da equipe na criação de componentes (LD08), o impacto de novidades técnicas durante o desenvolvimento do projeto (LD02 e LD03), falhas no desenvolvimento do sistema (LD04 e LD05) e artefatos de terceiros (LD01). Os gerentes de projetos entrevistados tiveram como principal preocupação a dependência dos componentes de terceiros (LD01), falhas técnicas (LD04), falta de alinhamento nas interações entre sistemas (SD01) e mapeamento das funções do sistema (SD02). A categoria infraestrutura, apresentada na Figura 7, relaciona os riscos da literatura relativos aos problemas na identificação das necessiades técnicas (LI01), o aparecimento de novas tecnologias que podem afetar o projeto (LI02), riscos na falta de comunicação (LI03), falhas técnicas e de contingência (LI04 e LI05). Nos riscos mencionados pelos gerentes de projetos, a falha na identificação e de infraestrutura técnica (LI01 e LI04) foram apontados, bem como a perda de dados (SI01). Em relação ao ambiente foram mencionados a falha na atualização (SI02) e perda de configuração (SI02). Em se tratando dos envolvidos no projeto, há a categoria stakeholders que é evidenciada na Figura 8. É possível constatar os riscos da literatura como a falta de apoio do cliente (LS01 e LS05), alterações nas atitudes dos usuários (LS03), faltam de visão da agregação de valor no engajamento de parceiros (LS02) e a falta de alinhamento dos interesses (LS04). Os gerentes de projetos enumeraram os principais riscos dos stakeholders, que incluem erros com sistemas ou Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 24
processos de terceiros (SS01, SS03 e SS05), com os usuários (SS02, SS04 e SS06) e com a alta gerência (SS07). Na Figura 9 encontram-se os riscos da categoria organização, os quais estão relacionados às mudanças de pessoas-chave (LO04 e LO05), aos conflitos organizacionais (LO02 e LO03), estruturais (LO01 e LO07) e de recursos (LO06) de acordo com a literatura. As entrevistas apresentaram, junto aos gerentes de projetos, os problemas de estruturação interna (SO01, SO02, SO06, SO07, SO08 e SO09), greves (SO05) e negativa em melhoria de uso dos itens do projeto (SO03 e SO04). ID
Riscos
LE01 Ambiente volátil
LE02 Falta de requisitos estáveis LE03 Complexidade do Projeto LE04 Escopo mal-entendido
Descrição Continuidade do projeto em ambiente com muitas alterações de escopo depois de iniciado, tais como prazo, número de usuários e ferramenta a ser utilizada. Alterações nas definições e/ou objetivos de pacotes de tarefas depois que estavam definidos Projeto mais complexo do que inicialmente previsto Definição do escopo com finalização obscura ou inexistente
Falha na Identificação de regras de Falha no levantamento das regras de negócios negócio do projeto Falta de processos definidos ou incompleto LE06 Falta de maturidade do processo pelo cliente Mudanças de critério dos Alterações da forma como os entregáveis LE07 entregáveis serão disponibilizados Falha em avaliar que não seriam Falha na avaliação das SE01 necessárias novas customizações na customizações ferramenta adquirida pelo cliente LE05
Autores
GP
Boehm (1991); Jiang e Klein (2000); Schmidt et al (2001); Wallace (2004); Khan (2010); Buckl et al (2011); Lamersdorf (2011); De Wet (2013);
R1
Não Boehm (1991); Schmidt et al (2001); Wallace (2004); El Emam (2008); Pinna e Arakaki (2009); Mencionado Wet (2013) Não Jiang e Klein (2000); Wallace (2004); Gholami Mencionado (2012); Khan (2010); De Wet (2013) Boehm (1991); Schmidt et al (2001); Nakashima e R1; R2; R5 Carvalho (2004); Khan (2010); Wet (2013) Schmidt et al (2001); Wallace (2004); Pinna e Arakaki (2009) Pinna e Arakaki (2009) Buckl et al (2011) Não Mencionado
R1; R3 Não Mencionado Não Mencionado R3
Figura 3 - Riscos da Categoria Escopo Fonte: Os autores ID
Riscos Falta de competências
Descrição Ausência de competências esperadas de um gerente de projetos, dentre as quais e não se limitando a: liderança, gestão de conflitos, comunicação, etc
Estimativas subestimadas
Estimativas superestimadas ou subestimadas
LP01
LP02 Falha em atender ao cronograma LP03 Falha na gestão de projetos LP04
Autores GP Boehm (1991); Jiang e Klein (2000); Schmidt et al (2001); Wallace (2004); Bannerman (2007); El Não Emam (2008); Khan (2010); Lamersdorf (2011); Mencionado Gholami (2012); De Wet (2013)
Boehm (1991); Schmidt et al (2001); El Emam (2008); Lamersdorf (2011); Khan (2010); Wet (2013); Wallace (2004) Dificuldades em conseguir manter o Boehm (1991); Nakashima e Carvalho (2004); cronograma já estabelecido Schmidt et al (2001); Wallace (2004); De Wet (2013) Ausência do conhecimento necessário para Schmidt et al (2001);Bannerman (2007); El a aplicação de uma metodologia de gestão Emam (2008); Lamersdorf (2011); Khan (2010); de projetos Wallace (2004)
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 25
Não Mencionado R1; R3; R4
R2; R3
Continuação ID
Riscos Qualidade abaixo do esperado
Descrição Autores O produto ou serviço executado possui Boehm (1991); El Emam (2008); Khan (2010); qualidade abaixo do firmado com o cliente Gholami (2012); De Wet (2013)
Falha na gestão de terceiros
Equívocos na gestão de fornecedores em relação a atrasos, escolhas e sua relação com os produtos existentes no cliente Criação de datas de entregas irreais
LP05
LP06 LP07
Deadlines Artificiais Falha na gestão de riscos
LP08
LP09 LP10 LP11 LP12 LP13 LP14 LP15 LP16
Falta de capacidade de reconhecer/interpretar os indicadores de risco criados, bem como possuir a percepção da importância da gestão de riscos Falha na Gestão de Conhecimento Falha na criação de lições aprendidas e/ou utilização das lições aprendidas Falha no gerenciamento das As expectativas dos usuários não foram expectativas gerenciadas gerando muita esperança pelos usuários finais Incapacidade de criar Ausência de criação de compromisso junto compromisso com o usuário aos usuários para o projeto Alteração das características das Mudanças de atividades já definidas pelo Atividades próprio gerente de projetos, mas considerando o mesmo escopo. Incomprensão dos requisitos Falha em compreender os requisitos pedidos pelo cliente/usuários Inexistencia de Controle Falta de controle de um ou mais itens: tempo, custos e atividades Configuração do projeto realista Falha em estimar o tempo do projeto Gold Plating
Reprovação do entregável pelo SP01 órgão regulador Falha na Customização SP02
SP03
SP04
Janela apertada para a transição dos serviços
Limitação técnica da ferramenta com relação as necessidades do cliente
Schmidt et al (2001); Khan (2010); Lamersdorf (2011); Wet (2013)
GP Não Mencionado R2; R3; R5
Schmidt et al (2001); Khan (2010); Wallace (2004) Bannerman (2007); Schmidt et al (2001); Khan (2010)
Não Mencionado
Pinna e Arakaki (2009); Gholami (2012); Lamersdorf (2011); Khan (2010) Boehm (1991); Schmidt et al (2001); El Emam (2008)
Não Mencionado
Schmidt et al (2001); El Emam (2008); Wallace (2004) Jiang e Klein (2000); Gholami (2012)
Não Mencionado
Boehm (1991); Schmidt et al (2001) Schmidt et al (2001); Wallace (2004) Bannerman (2007); Khan (2010); De Wet (2013)
Uso de Gold Plating como solução de Boehm (1991) contorno para crises Reprovação dos processos e/ou sistemas do órgão regulador do setor em que a empresa cliente atua Erro ao customizar um sistema ERP conforme as características definidas pelo cliente Tempo disponível para utilização do servidor bastante reduzido, onde qualquer falha compromete o trabalho de um período inteiro As características da ferramenta definida pelo cliente para ser utilizada possui demasiada limitação técnica e de operacionalização
Não Mencionado
R1; R2; R3
Não Mencionado R3 Não Mencionado Não Mencionado Não Mencionado
Não Mencionado
R2; R3
Não Mencionado
R5
Não Mencionado
R4
Não Mencionado
R1
Figura 4 - Riscos da Categoria Gestão de Projetos Fonte: Os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 26
ID
Riscos Falta de competência técnica
LT01
Falta de compromisso LT02 Pessoal Insuficiente LT03
LT04
LT05 LT06
LT07
LT08 LT09 ST01 ST02
ST03
Descrição A equipe não possui conhecimento para utilizar a ferramenta, linguagem ou banco de dados. É considerada uma novidade para o grupo, mas não necessariamente para o mercado Ausência de compromisso e envolvimento da Equipe para com o projeto
Número de pessoas com conhecimento técnico insuficiente. Estão inclusos os cargos de analista, administrador de redes e similares Falhas na comunicação Problemas na comunicação das tarefas, determinações e outros itens entre o gerente de projetos/Gerente de TI e a equipe de desenvolvimento Falta de maturidade da equipe de Falta de maturidade/experiência da equipe desenvolvimento de desenvolvimento Falta de confiança Ausência de ambiente de confiança entre os membros da equipe Turn-over Troca de funcionários técnicos provocado por pedido de demissão ou por uma ação do gestor de projetos/Gerente de TI
Autores Boehm (1991); Jiang e Klein (2000); Schmidt et al (2001); Nakashima e Carvalho (2004); El Emam (2008); Lamersdorf (2011); Wallace (2004) Schmidt et al (2001); Khan (2010); Buckl et al (2011); Lamersdorf (2011); Gholami (2012) Jiang e Klein (2000); Schmidt et al (2001); Bannerman (2007); El Emam (2008)
GP
R1
Não Mencionado
R1
El Emam (2008); Khan (2010); Wallace (2004) Não Mencionado Pinna e Arakaki (2009); Khan (2010); Lamersdorf (2011) Lamersdorf (2011); Gholami (2012)
Não Mencionado Não Mencionado
Jiang e Klein (2000); Schmidt et al (2001)
Adapatação constante da equipe
Alterações na tecnologia empregada Buckl et al (2011) forçando a equipe a se adaptar Grandes barreiras culturais da Diferenças culturais, sociais ou de status- Pinna e Arakaki (2009) equipe de projetos quo entre os membros da equipe Entendimento do processo de Falha na compreensão do procedimento Não Mencionado atendimento da equipe de campo da equipe no atendimento ao cliente Transição de gerenciamento das Falha no processo de troca de máquinas máquinas para a nova equipe. para a nova equipe do projeto Não Mencionado ocasionando parada de produção Troca da equipe técnica após a Mudança da equipe de desenvolvimento implantação após a implantação por outra com menor número de técnicos, cada técnico com Não Mencionado menor conhecimento que o atual e com custos menores
Figura 5 - Riscos da Categoria Equipe Fonte: os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 27
Não Mencionado Não Mencionado Não Mencionado R4 R4
R1
ID LD01
LD02 LD03 LD04
LD05
LD06
LD07
LD08
LD09
Riscos Descrição Problemas com artefatos técnicos Problemas com os componentes de de terceiros terceiro no que se refere a dependência do sistema atual, comunicação, compatibilidade e integração Mudanças constantes de requisitos Alterações constantes nos requisitos técnicos técnicos após a aprovação do projeto Novidade técnica em Novidade técnica em desenvolvimento do Desenvolvimento sistema durante o projeto Falha técnica de desenvolvimento Falha proveniente de segurança de acesso sistêmico e não utilização de logs para detecção de erros Falha de testes no sistema Insuficiencia de testes e/ou falha na execução de testes dos componentes/sistema Falha na gestão de Falhas na condução e/ou aplicação de desenvolvimento de sistemas uma metodologia Agile para a gestão da equipe de desenvolvimento de sistemas Falha nas entregas Atraso nas entregas ou antecipações dos produtos diferentes da sugerida em uma metodologia Agile seguida pela equipe Falta de componentização Falha na concepção da componentização, erro na abstração, falta de flexibilidade e outros problemas de orientação ao objeto Falta de documentação
Autores Boehm (1991); El Emam (2008); Pinna e Arakaki (2009); Khan (2010); Lamersdorf (2011); De Wet (2013) Boehm (1991); El Emam (2008); Pinna e Arakaki (2009); Lamersdorf (2011) Jiang e Klein (2000); Schmidt et al (2001); El Emam (2008); Lamersdorf (2011) Pinna e Arakaki (2009); Lamersdorf (2011); Gholami (2012) Pinna e Arakaki (2009); Lamersdorf (2011)
Pinna e Arakaki (2009); Khan (2010)
El Emam (2008); Buckl et al (2011)
GP R1; R2; R3 Não Mencionado Não Mencionado R2 Não Mencionado Não Mencionado Não Mencionado
Pinna e Arakaki (2009) Não Mencionado
Documentação inexistente, incompleta ou Khan (2010) desatualizada
Não Mencionado
SD01
Falha na interação entre os O sistema desenvlvido não estava alinhado processos da empresa e o sistema com os processos executados na empresa
Não Mencionado
R3
SD02
Falha no mapeamento dos sistemas
Não Mencionado
R3
Falha na identificação das funções existentes no sistema utilizado na empresa
Figura 6 - Riscos da Categoria Desenvolvimento Fonte: os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 28
ID
Riscos Falha na identificação das necessidades técnicas
Descrição Falha na identificação das necessidades técnicas no que se refere a configuração do hardware escolhido, forma de LI01 licenciamento dos software e outros problemas em relação a infraestrutura de TI Novidade técnica em Infraestrutura Indica que a tecnologia empregada no projeto de infraestrutura é nova no LI02 mercado Falha na identificação do formato Falha na identificação do formato de comunicação com os LI03 de comunicação componentes/sistemas de terceiros Falha técnica de Infraestrutura Falha proveniente de hardware ou acesso LI04
Autores Pinna e Arakaki (2009); Gholami (2012); Khan (2010); Verner (2014)
R2; R3
Jiang e Klein (2000); Schmidt et al (2001); Lamersdorf (2011) Pinna e Arakaki (2009); Gholami (2012)
Gholami (2012); Khan (2010)
Falta de contingências LI05
LI06 SI01
SI02
SI03
GP
Ausência de contingência de serviços para Khan (2010) o projeto podendo acarretar parada total ou momentânea dos processos Tecnologia Imatura A tecnologia empregada não está Wallace (2004) consolidada junto ao fabricante e/ou ao mercado Perda de dados dos usuários Os técnicos provocaram a perda de dados Não Mencionado do cliente Falha na atualização Ao selecionar os componentes para atualização do hardware existente no cliente os técnicos não levaram em Não Mencionado consideração que as peças novas seriam incompatíveis com a existente Perda de configuração do ambiente O técnico perdeu a configuração das diretrizes do ambiente do cliente Não Mencionado provocando retrabalho para o projeto
Figura 7 - Riscos da Categoria Infraestrutura Fonte: os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 29
Não Mencionado Não Mencionado R1; R4 Não Mencionado Não Mencionado R1; R4
R4
R1
ID LS01
Riscos Falta de Apoio dos Usuários
Falta de Agregação de valor com LS02 parceiros
Descrição Autores Falta de apoio dos usuários da operação do Nakashima e Carvalho (2004); Schmidt et al cliente (2001); Buckl et al (2011) Incapacidade de gerar valor com a parceria Bannerman (2007); Schmidt et al (2001) com outros fornecedores/parceiros
Alterações nas atitudes dos usuários Falta de alinhado com os LS04 Stakeholders Usuários relutantes LS05
Mudanças no comportamento dos usuários Jiang e Klein (2000); Wallace (2004) envolvidos Projeto com falta de alinhamento com os Buckl et al (2011) interesses dos Stakeholders Usuários com atitudes negativas ou Wallace (2004) relutantes em relação ao projeto Excessivo de erros da ferramenta Quantidade de erros apresentados pela ferramenta implantada é muito superior ao SS01 Não Mencionado esperado Falha na compreensão do processo Os usuários e envolvidos diretos não de implementação do projeto compreendem o fluxo de instalação do SS02 Não Mencionado sistema na empresa gerando reclamações sobre o projeto Falta de conhecimento técnico por O fornecedor da ferramenta enviou uma parte do fornecedor da ferramenta equipe com técnicos que não conheciam o SS03 Não Mencionado comprada produto gerando atrasos e custos ao projeto
LS03
Usuários-chaves não possuiam tempo disponível para o projeto por excesso de tarefas e/ou determinação do seu superior direto Falta no levantamento de O fornecedor não realizou o levantamento requisitos pelo fornecedor corretamente que apresentou uma solução SS05 que não atendia aos requisitos, gerando atraso no projeto Ferramenta desacreditada junto aos O sistema utilizado, devido ao histórico de problemas apresentados, era considerado SS06 usuários confiável pelos usuários Não entendimento da Os usuários e gerentes relacionados complexidade do projeto pelos diretamente como projeto subestimaram a complexidade e o impacto do novo sistema SS07 stakeholders nas tarefas diárias gerando reclamações SS04
Falta de tempo disponivel dos usuários chaves
GP R5 Não Mencionado Não Mencionado Não Mencionado R1 R1
R1
R1
Não Mencionado
R5
Não Mencionado
R1
Não Mencionado
R1
Não Mencionado
R1
Figura 8 - Riscos da Categoria Stakeholder Fonte: os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 30
ID
Riscos Mudanças organizacionais LO01 simultâneas Conflitos culturais LO02
Descrição Cliente mudando a estrutura da empresa enquanto o projeto está em andamento Choques culturais entre os usuários, técnicos ou equipe de gestão Conflitos internos Existência de conflitos entre os usuários LO03 dos departamentos do cliente Mudança do Gerente sênior Alteração do gerente sênior do projeto LO04 com papel de key-user Mudança do dono do projeto Alteração do sponsor do projeto após o LO05 projeto iniciado Recursos insuficientes Recursos disponibilizados ao projeto LO06 insuficientes, tais como budget e tempo Retirada do Apoio da Alta Alta gerência retira o poder e/ou auxilio do LO07 gerência gerente de projetos Indefinições de Processos A organização não possui processos SO01 claramente definidos, onde as ações são tratadas ad hoc como uma constante Falta de apoio do novo Após a troca do patrocinador o projeto SO02 Patrocinador não recebe o apoio e a atenção devida gerando inércia nas atividades Falta de compreensão do valor Os acionistas e diretoria não SO03 agregado do projeto à compreendem o valor agregado do organização projeto para a organização Falta de treinamento dos usuários Negativa da geração de custos pelo patrocinador referente ao treinamento dos SO04 usuário para a ferramenta, pode acarretar resistência para a sua utilização Greve do setor Greve no setor do cliente no qual os usuários-chaves não trabalharam e em SO05 casos mais extremos a equipe do projeto não conseguiu entrar na empresa Indefinição na nomeação de Indefinição do gerente de área em definir SO06 usuário chave os usuários-chaves para o projeto Indefinições da hierarquia de Falta de clareza no fluxo de aprovação do SO07 aprovação projeto dentro da empresa Resistência a alterações nos Resistência das alterações dos processos SO08 processos na organização por parte de alguns integrantes da alta gerência do cliente Troca do Patrocinador na fase de Troca do sponsor no momento da SO09 implantação implantação do sistema, acarretando alterações e mudanças de escopo
Autores Schmidt et al (2001); Bannerman (2007); Wallace (2004) Gholami (2012); Khan (2010) Schmidt et al (2001); Wallace (2004) Schmidt et al (2001); Wallace (2004) Schmidt et al (2001); Wallace (2004) Jiang e Klein (2000); El Emam (2008) Jiang e Klein (2000); Wallace (2004)
GP Não Mencionado Não Mencionado R1 Não Mencionado Não Mencionado R2 Não Mencionado
Não Mencionado
R1; R5
Não Mencionado
R1
Não Mencionado
R1
Não Mencionado
R1
Não Mencionado
R2
Não Mencionado
R5
Não Mencionado
R5
Não Mencionado
R1
Não Mencionado
R1
Figura 9 - Riscos da Categoria Organização Fonte: os autores
5.3
Análise dos Riscos Novos
Os riscos novos estão presentes em todas as categorias conforme a Figura 10. Na categoria escopo a falha na avaliação das customizações foi a novidade apontada. Os riscos Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 31
novos referentes à categoria gestão de projetos apresentaram itens relativos à reprovação de órgão regulador, customizações, tempo para processamento e limitações técnicas. A categoria equipe apresentou riscos relacionados à permanência da equipe e entendimento dos processos em campo. Em relação à categoria desenvolvimento os riscos referem-se à integração e mapeamento de processos. Na categoria infraestrutura foram identificados riscos a respeito da perda de informações dos clientes, gerado principalmente pela troca de servidores e problemas no backup realizado, e as falhas da equipe de TI no processo de substituição do equipamento e no armazenamento das cópias. Em relação à categoria dos stakeholders problemas com o fornecedor dominaram o tema, bem como a falta de conhecimento de como os processos serão executados. A empresa, caracterizada pela categoria de organização, apresentou riscos relativos à estrutura interna da empresa e ao comportamento, muitas vezes negativo, dos usuários. Categoria Escopo Gestão de Projetos
Equipe Desenvolvimento Infraestrutura
Stakeholders
Organização
ID SE01 SP01 SP02 SP03 SP04 ST01 ST02 ST03 SD01 SD02 SI01 SI02 SI03 SS01 SS02 SS03 SS04 SS05 SS06 SS07 SO01 SO02 SO03 SO04 SO05 SO06 SO07 SO08 SO09
Riscos Falha na avaliação das customizações Reprovação do entregável pelo órgão regulador Falha na Customização Janela apertada para a transição dos serviços Limitação técnica da ferramenta com relação as necessidades do cliente Entendimento do processo de atendimento da equipe de campo Transição de gerenciamento das máquinas para a nova equipe. Troca da equipe técnica após a implantação Falha na interação entre os processos da empresa e o sistema Falha no mapeamento dos sistemas Perda de dados dos usuários Falha na atualização do Hw Perda de configuração do ambiente Excessivo de erros da ferramenta Falha na compreensão do processo de implementação do projeto Falta de conhecimento técnico por parte do fornecedor da ferramenta comprada Falta de tempo disponivel dos usuários chaves Falta no levantamento de requisitos pelo fornecedor Ferramenta desacreditada junto aos usuários Não entendimento da complexidade do projeto pelos stakeholders Indefinições de Processos Falta de apoio do novo Patrocinador Falta de compreensão do valor agregado do projeto à organização Falta de treinamento dos usuários Greve do setor Indefinição na nomeação de usuário chave Indefinições da hierarquia de aprovação Resistência a alterações nos processos na organização Troca do Patrocinador na fase de implantação
Figura 10 - Riscos novos obtidos pela pesquisa Fonte: os autores
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 32
5.4
Análise dos Riscos Potencializados
Os riscos potencializados são apresentados na Figura 11, sendo o primeiro o "SE01 Escopo mal-entendido" com oito autores na literatura e três nas entrevistas fazendo referência, onde mesmo com orientações de validação dos documentos com os stakeholders (12) ainda é um risco presente nos projetos. O segundo risco "SP03 - Falha em atender ao cronograma" foi referenciada por seis autores na literatura e três nas entrevistas, é possível identificar que, apesar das técnicas de gerenciamento de tempo, diagrama de caminho crítico e PERT/CPM difundidas no mercado (12) é persistente nos projetos. O risco "SD01 - Problemas de compatibilidade com os sistemas existentes" obteve cinco autores na literatura e três gerentes de projetos fazendo menções, mesmo com a sugestão de realizar o mapeamento dos processos através de WBS (12) e a identificação das funções através de diagramas de caso de uso e atividades (3; 4) o risco continua a existir. Categoria Escopo Gestão de Projetos Desenvolvimento
ID SE04 LP03 SD01
Riscos Escopo mal-entendido Falha em atender ao cronograma Problemas com artefatos técnicos de terceiros
Figura 11 - Riscos potencializados obtidos pela pesquisa Fonte: os autores
6.
Discussão
Um dos pontos passíveis de discussão é o fato de em determinadas situações um risco poder ser eletivo a mais de uma das categorias, visto a abrangência do seu impacto ou a sua provável origem. Nesta visão pode-se citar o risco LT04 que corresponde à falha de comunicação entre o gerente de projetos e a equipe que foi atribuída à categoria equipe ao invés da categoria gestão de projetos pelo impacto ser na equipe e o risco LT09 sobre as diferenças culturais atribuída a categoria equipe ao invés de stakeholder por se tratar de um problem específico dos membros da equipe. Outro ponto que pode provocar divergências é a respeito dos riscos LO04 e LO05 a respeito, respectivamente, das mudanças do gerente sênior e do dono do projeto serem atribuídas à categoria organização pelo fato de ser uma mudança organizacional de um usuáriochave devido a um turnover e o outro risco devido à mudança do responsável no papel de dono do projeto. Independentemente de um risco poder ser interpretado em outra categoria, no momento da classificação dos riscos obtidos nas entrevistas seguiu-se o mesmo critério para a categoriazação dos riscos obtidos no estado da arte. Os riscos levantados nas entrevistas também podem conjecturar a respeito do desmembramento em cadeia, como o risco da perda de dados do cliente derivar da falta de Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 33
competência técnica, no qual carece de uma análise mais detalhada servindo de tema para futuras pesquisas. Uma das limitações desta pesquisa é o reduzido número de entrevistas, o que dificulta a generalização dos resultados. O trabalho apresentado também se limita a discorrer sobre os itens identificados pelos autores, independentemente se o projeto de TI era de infraestrutura ou o desenvolvimento de um sistema. Sugere-se que em futuras pesquisas haja um maior número de entrevistas e a divisão dos itens por tipo de projeto e a especialização em algum setor empresarial. Contudo, deve-se referir a dificuldade de acesso a empresas no Brasil para se realizar trabalhos empíricos, especificamente gestores de projetos disponíveis a conceder entrevistas, que muitas vezes incluem informações sensíveis sobre os projetos.
7.
Conclusão
Os projetos de TI são detentores de alto grau de incerteza tecnológica durante sua execução (2; 1) e devido à contínua evolução tecnológica do mercado (3) riscos novos tendem a surgir, onde o gerente de projetos é responsável por identificar os riscos o mais cedo possível para prover sua mitigação (12). Em relação ao primeiro objetivo de revisitar os principais riscos em projetos de TI encontrados na literatura, o resultado do levantamento apontou como comumente citados os riscos de ambiente volátil (Escopo/LE01), falta de competência (Gestão de Projetos/LP01), falta de competência técnica (Equipe/LT01), problemas de artefatos técnicos de terceiros (Desenvolvimento/LD01), falha na identificação das necessidades técnicas (Infraestrutura/LI01), falta de apoio dos usuários (Stakeholders/LS01) e mudanças organizacionais simultâneas (Organização/LO01). Diante destes riscos apontados, percebe-se que a mudança do ambiente é muito provável e até esperada pelo número de indicações (LE01).A mitigação de seus impactos pode encontrar problemas de competências da equipe (LP01, LT01 e LI01), nos membros da organização que podem não cooperar (LS01), técnicos com fornecedores (LD01) e em uma organização que, em ressonância com o LE01, está em constante mudança (LO01). O outro objetivo definido na pesquisa refere-se a elencar os principais riscos atualmente identificados por gestores de projetos de TI, neste processo pode-se ressaltar os riscos que tiveram maior menção: o do escopo mal-entendido (Escopo/LE04), a falha em atender ao cronograma (Gestão de Projetos/LP03), falha na gestão de terceiros (Gestão de Projetos/LP06), falha no gerenciamento de expectativas (Gestão de Projetos/LP10), problemas com artefatos de terceiros (Desenvolvimento/LD01), falha na identificação das necessidades técnicas (Infraestrutura/LI01), falha técnica na infraestrutura (Infraestrutura/LI04), perda de dados (Infraestrutura/SI01) e indefinições de processos (SO01).
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 34
Estes riscos podem indicar a necessidade de maior atenção por parte do gerente de projetos, no que se refere ao planejamento do que deve ser elabora e quando (LE04, LP03, LP10 e LI01). Um ponto importante é que, assim como levantado no estado da arte, os problemas oriundos de terceiros carecem de atenção (LP06 e LD01), apenas nas entrevistas apresentaram que a atenção deve ser estendida as suas ações na organização que estão prestando serviços (SI01). O fato da indicação de que o gerente de projetos pode deparar-se com processos indefinidos (SO01) tende a salientar que existem muitas empresas que não possuem um nível de formalização de seus processos no Brasil. Os riscos mencionados em TI (LI04) sugerem a necessidade de capacitação técnica. Nas categorias de Equipe e Stakeholders os riscos foram citados apenas uma única vez, podendo indicar que existe muita diversidade e que um estudo mais profundo é indicado. O terceiro objetivo da pesquisa, que consiste na apresentaçãodos riscos novos e potencializados nos projetos de TI. Foi realizado elencando riscos não encontrados no estado da arte, portanto riscos novos. Não obstante, também elencou os riscos indicados simultaneamente na literatura e nas entrevistas e, portanto, são riscos potencializados.O fato de apresentar mais riscos novos do que potencializados evidencia a necessidade de mais estudos na área de gerenciamento de riscos e corrobora a respeito do dinamismo que as organizações estão inseridas. Em relação à contribuição do trabalho para a aplicação prática dos riscos novos, recomenda-se que façam parte dos futuros gerenciamentos de riscos e os riscos potencializados devem ser encarados como um alerta aos gerentes de projetos nos próximos trabalhos de TI. A contribuição teórica dos riscos novos identificados deve servir como pilar para o desenvolvimento de pesquisas confirmatórias, enquanto os riscos potencializados indicama necessidade de retirar o véu da obscuridade que ainda permeia os riscos nas organizações.
8.
Referências Bibliográficas
(1)
Sauser, B. J., Reilly, R. R. andShenhar, A. J., "Why projects fail? How contingency theory can provide new insights – A comparative analysis of NASA’s Mars Climate Orbiter loss", International Journal of Project Management, Vol. 27, 2009, p.665–679.
(2)
Nakashima, D. T., and Carvalho, M. M., "Identificação de riscos em projetos de TI", XXIV Encontro Nacional de Engenharia de Produção - ENEGEP, 2004, p.4248–4255.
(3)
Pressman, R., "Engenharia de Software", São Paulo: McGraw-Hill, 6ª.ed ,2011.
(4)
Sommerville, I., "Engenharia de Software", São Paulo, Pearson Education, 9ª. ed, 2011.
(5)
Boehm, B. W., "Software risk management: principles and practices", IEEE, 1991, p.32-41.
(6)
Wallace, L., Keil, M., and Rai, A., "How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model", Decision Sciences, nr.35, 2004, p.289-321. Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 35
(7)
Bannerman, Paul L., "Software Project Risk in the Public Sector", Proceedings of the 2007 Australian Software Engineering Conference (ASWEC'07), 2007.
(8)
Khan, Q., and Ghayyur, S., "Software Risks and Mitigation in Global Software Development", Journal of Theoretical & Applied Information Technology, nr. 22, 2010, p.5869.
(9)
Buckl, S., Matthes, F., Monahov, I., Roth, S., Schulz, C., andSchweda, C. M., "Towards an agile design of the enterprise architecture management function", Enterprise Distributed Object Computing Conference Workshops (EDOCW), 2011 - 15th IEEE International, 2011, August, p.322-329.
(10) Gholami, S., "Critical Risk Factors in Outsourced Support Projects of IT", Journal of Management Research, nr.4, 2012, p.1–13. doi:10.5296/jmr.v4i1.939. (11) De Wet, B., and Visser, J. K., "An evaluation of software project risk management in South Africa", South African Journal of Industrial Engineering, nr.24, 2013, p.14-29. (12) PMI, "Project Management Body of Knowledge - Um guia do conjunto de conhecimentos em gerenciamento de projetos", Pensilvânia, Four Campus Boulevard, 2013. (13) Jani, A., "An experimental investigation of factors influencing perceived control over a failing IT Project", International Journal of Project Management, nr.26, 2008, p.726–732. (14) Jani, A., "Escalation of commitment in troubled IT projects: influence of project risk factors and self-efficacy on the perception of risk and the commitment to a failing project", International Journal of Project Management, nr. 29, 2010, p.934–945. (15) Sharma, A., Sengupta, S., and Gupta, A., "Exploring risk dimensions in the Indian software industry", Project Management Journal, nr. 42, 2011, p.78–91. (16) Karel Bakker, Boonstra, A., and Wortmann, H., "Does risk management contribute to IT project success? A meta-analysis of empirical evidence", International Journal of Project Management, 2009, p.493-503. (17) ABNT, "NBR ISO 31000:2009 – Gestão de Riscos – Princípios e diretrizes", 2009, p.1-24. (18) Alao, Esther Monisola andAdebawojo, Oladipupo, "Risk and Uncertainty In Investment Decisions: An Overview", Arabian Journal of Business and Management Review (OMAN Chapter), nr. 2, 2012, p.53-64 (19) Martins, G. A., and Theóphilo, C. R., "Metodologia da Investigação Científica para Ciências Sociais Aplicadas", São Paulo, Atlas, 2a. ed., 2009. (20) Yin, R. K., "Estudo de caso: planejamento e métodos", Porto Alegre, Bookman, 4ª. ed, 2009. Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 36
(21) El Emam, K., and Koru, A. G., "A replicated survey of IT software project failures", Software - IEEE, nr. 25(5), 2008, p.84-90. (22) Jiang, J., & Klein, G., "Software development risks to project effectiveness", Journal of Systems and Software, nr. 52(1), 2000, p.3-10. (23) Lamersdorf, A., Munch, J., Torre, A. Fernández del Viso, and Sanchez, C. R. R., "A riskdriven model for work allocation in global software development projects", 6th IEEE International Conference on Global Software Engineering (ICGSE), 2011, Agosto, p.15-24. (24) Pinna, C. C. A., and Arakaki, R., "Arquitetura de software: uma abordagem para gestão de riscos em projetos de TI", Integração, Ano XV, nr. 57, 2009, p.111-120. (25) Schmidt, R., Lyytinen, K., Keil, M., and Cule, P., "Identifying software project risks: an international Delphi study", Journal of Management Information Systems, nr. 17(4), 2001, p.5-36.
Apêndice A – Protocolo de Entrevista Passo 1. Realizar a introdução sobre o pesquisador e a pesquisa a ser feita Passo 2. Descrever como será conduzida a entrevista Passo 3. Ressaltar a preocupação da confidencialidade e privacidade dos entrevistados. Explicar como os dados coletados serão mantidos no anonimato Passo 4. Perguntar aos participantes se o pesquisador possui a permissão para gravar a entrevista (Iniciar a gravação, dependendo da resposta do item 4) Passo 5. Iniciar as questões (Q) Sobre o Entrevistado (Q1) Você atua como gerente de projetos na empresa? (Q2) Qual o setor da empresa? (Q3) Você realiza a gestão de riscos nos projetos? Sobre o Projeto Considernado o último projeto que trabalhou você pode mencionar: (Q4) Qual o Tempo de duração do projeto (aproximadamente)? (Q5) O projeto foi caracterizado por ter foco no Desenvolvimento, Infraestrutura ou Outro (especificar)? (Q6) Qual(is) o(s) objetivo(s) do projeto? Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 37
(Q7) Quais os riscos do projeto que você poderia relacionar? (Q8) Alguma outra observação que será interessante para a pesquisa? Passo 6. Finalizar a gravação, caso tenha sido iniciada
Agradecimento Agradecemos à professora doutora Rosária de Fátima Segger Macri Russo pela revisão cuidadosa e análise crítica da primeira versão deste documento.
Correspondência: Irapuan Glória Júnior E-mail:
[email protected] Marcirio Silveira Chaves E-mail:
[email protected] Universidade Nove de Julho – UNINOVE Av. Francisco Matarazzo, 612 – Água Branca – São Paulo – Brasil Programa de Mestrado Profissional em Administração - Gestão de Projetos (PMPA-GP) Telefone: +55 11 3665-9321
Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. ISSN 2346-9161. Vol.5, No.2, A.I., pp.16-38. 2014. Recepción: 01/05/2014. Aceptación: 24/06/2014. Publicación: 10/12/2014. 38
