XXIV Encontro Nac. de Eng.

de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

Identificao de riscos em projetos de TI

Daniel Toshimitsu Vieira Nakashima (MBA_GO/ PRO/USP) nakashim@terra.com.br Marly Monteiro de Carvalho (PRO/POLI/USP) marlymc@usp.br

Resumo Neste artigo apresenta-se uma reviso das tcnicas de gerenciamento de projeto, em especial das ferramentas de gesto de riscos aplicadas a projetos de Tecnologia da Informao (TI). Existe um leque de modelos tericos adotados pelas empresas, tanto de cunho organizacional como no mbito especfico do projeto. O modelo terico discutido em maior profundidade neste artigo o do Project Management Body of Knowledge PMBoK, proposto pelo Instituto de Gesto de Projetos PMI (Project Management Institute). A abordagem metodolgica foi a de estudo de caso, desenvolvida em uma empresa de tecnologia em um projeto de telecomunicaes. Palavras chave: Gerenciamento de Projetos, Riscos, Tecnologia da Informao. 1. Introduo:

O crescimento da demanda por projetos de TI (Tecnologia da Informao), em todas as reas, um fato inquestionvel, e com ela os Gerentes de Projeto esto tendo que aprimorar suas tcnicas, adaptando-as a nova realidade. Segundo Carvalho et al. (2003), o leque de modelos tericos adotados pelas empresas abrangente, sendo alguns de cunho organizacional como o caso do CMM Capability Maturity Model e outros que enfocam boas prticas de gesto de projetos como o caso Project Management Body of Knowledge (PMBoK). Neste artigo, tem-se como foco o projeto e a rea de risco. O risco do negcio pode surgir de vrias formas, podendo estar ligado s decises de investimentos estratgicos, no lanamento de determinado produto, nas estratgias de marketing, competio de mercado e incertezas quanto ao comportamento das vendas entre outros fatores (LINSMEIER & PEARSON,1996). O objetivo deste artigo apresentar os desafios encontrados no gerenciamento de projetos de TI, detalhar risco, apresentar a necessidade de identificar e gerenciar riscos e demonstrar os resultados atravs de um estudo de caso onde estas tcnicas foram adotadas com sucesso. Devido complexidade do assunto, o foco ficar em projetos de TI que tenham como atividade principal a implantao de softwares de gerncia, porm poder ser adaptado as demais ramificaes da TI. 2. 2.1 Projetos de TI: Desafios atuais O mercado de TI para Telecom

O desafio das Operadoras de Telecomunicaes atender as expectativas dos seus consumidores, acionistas e das agncias reguladoras, e obter sucesso na guerra com seus concorrentes. Neste mercado to competitivo as operadoras tm procurado reduzir seus custos operacionais com terceirizaes, otimizao de infra-estrutura e implantao de softwares de gerncia (foco deste artigo). O mercado mundial de softwares de gerenciamento, s em 2002, movimentou mais de um bilho de dlares. Os analistas, mesmo cientes das redues de investimento por parte das

ENEGEP 2004

ABEPRO

4248

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

operadoras, esto apostando que estes nveis de investimento sero mantidos nos prximos cinco anos (BUGALA, 2003). Atentos reduo do capex (capital investido em infra-estrutura pelas operadoras), que no Brasil em 2002 foi de R$ 6 bilhes contra os R$ 20 bilhes investidos em 2001, os fabricantes de equipamentos esto trabalhando na diversificao do seu portflio de servios (SOARES & GRAA, 2003), oferecendo: gerenciamento de falhas; gerenciamento e relatrios de performance; gerenciamento das polticas e dos endereamentos (circuitos, rotas, domnios, etc.); gerenciamento e monitorao de equipamentos e sistemas. Com esta mudana de estratgia veio a necessidade da adaptao dos departamentos de vendas e operaes a esta nova realidade, o que tem exigido investimentos em treinamento e em redesenho de processos (PROVOST, 2003). 1.1 Projetos envolvendo softwares: Um novo paradigma

Softwares so produtos que tm sua eficincia diretamente associada qualidade da mo de obra utilizada na instalao e qualidade dos servios que a eles foram agregados na customizao. A seqncia de implementao normalmente composta pelas fases de anlise, especificao, desenvolvimento, aplicao, testes e manuteno dos componentes e, a documentao associada (IEEE-STD-610), porm os recursos necessrios variam de projeto para projeto. Os dois modelos comumente utilizados na implementao de softwares so apresentados a seguir: a. Cascata: Este modelo, desenvolvido por Royce (1970), assume que no fluxo de trabalho, uma atividade somente ocorrer depois que sua predecessora estiver concluda sem pendncias. Porm, Stillman (APUD FORSBERG & MOOZ, 1996), afirma que o Modelo em Cascata dificilmente pode ser utilizado em situaes reais, pois o mesmo no fornece informaes confiveis para levantamento de custos e tempo de execuo, e prov, a falsa impresso, que o desenvolvimento do projeto est imune a riscos (FORSBERG & MOOZ, 1996).
Requisitos do Sistema Requisitos do Software Projeto Preliminar Projeto Detalhado Codificao e Debug Testes e operao preliminar Operao e Manuteno

Figura 01 - Modelo tipo Cascata (ROYCE, 1970)

b. Espiral: Este modelo, desenvolvido por Boehm (1988), o modelo mais utilizado em projetos que envolvem software. Este modelo apresenta bons resultados no que se refere mitigao de riscos, mas sua representao espiral bastante confusa e, tende a ocultar as revises necessrias, dificultando o controle de tempo do processo.

ENEGEP 2004

ABEPRO

4249

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

Este modelo aderente ao utilizado pelo PMI (PMI, 2000, Fig. 2-5) que possui a vantagem de ser graficamente mais simples, o que facilita sua compreenso, porm deixa a falsa impresso
Custo Acumulativo

Determinar: Objetivos, Alternativas e Restries

Sentido do Progresso do Processo

Avaliar Alternativas: Identificar e Mitigar Riscos

Anlise de Risco

Anlise de Risco

Anlise de Risco R A
Planejamento dos Requisitos e do Ciclo de Vida

Partio do Reviso Comprometimento

Prottipo 1

Prottipo Operacional Prottipo 2 Prottipo 3 Modelos

Gerar o Plano de Desenvolvimento do Prximo Nvel do Desenvolvimento

Simulaes Conceito da Operao Requerimentos do Software

Benchmarks

Plano de Validao dos Desenvol- Requerimentos vimento Plano de Integrao e Teste Validao e Verificao do Projeto Implementao

Projeto de Implantao do Software

Detalhamento do Projeto

Teste de Aceitao

Integrao e Teste

Teste da Unidade

Avaliar alternativas do processo: Avaliao e Resoluo dos Riscos

Codificao

Planejamento das Prximas Fases

Determinar Processos, Objetivos,Alternativas e Restries

Gerao do Plano de Desenvolvimento do Produto

que o projeto um processo contnuo, escondendo as revises necessrias, e conseqentemente o tempo necessrio execuo do projeto.
Figura 2 - Modelo tipo Espiral (FORSBERG & MOOZ, 1996)

2.

Riscos: Ameaas e Oportunidades

Ward (2000) define risco como o efeito acumulativo da probabilidade de incerteza que pode afetar positivamente (oportunidade) ou negativamente (ameaa) o projeto, o que demonstra que gerenciar riscos de forma criteriosa fundamental para o sucesso do projeto. O PMI apresenta a Tabela 01 que relaciona os riscos aos impactos que estes podem gerar nos projetos (PMI, 2000, Fig. 11-2):
Avaliao de Impactos dos Riscos nos Principais Objetivos do Projeto (escala no linear) Baixo Moderado Alto 0,10 0,20 0,40 de <5% de Incremento 5 10% de 10 20% de de Custo Incremento de Custo Incremento de Custo <5% de Atraso reas no crticas so afetadas da Apenas aplicaes de alta demanda so afetadas 5 10% de Atraso reas crticas afetadas so 10 - 20% de Atraso Reduo de escopo no aceitvel pelo cliente Reduo da qualidade inaceitvel pelo cliente

Objetivo do Projeto Custo Prazo Escopo Qualidade

Muito Baixo 0,05 Incremento Custo insignificante Atraso insignificante Variao dificilmente detectvel Degradao qualidade imperceptvel

Muito Alto 0,80 >20% de Incremento de Custo >20% de Atraso Impossibilidade concluir o projeto de

Reduo da qualidade necessita de aprovao do cliente

Projeto perdido. Resultado desastroso.

Tabela 01 - Influencia dos Riscos nos Resultados dos Projetos

Nem todo projeto necessita de Gerenciamento de Riscos formal, mas importante que o processo seja monitorado e controlado sistematicamente durante todo o ciclo de vida do mesmo. importante salientar que nenhum especialista capaz de prever todas as
ENEGEP 2004 ABEPRO 4250

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

possibilidades, assim buscar informaes em fontes seguras, externas ao grupo de gerenciamento fundamental na fase de identificao dos riscos. As seguintes ferramentas para identificao de riscos podem ser utilizadas (em separado ou em conjunto) durante a execuo de um projeto (PMI, 2000, Cap. 11.2.2): Reviso da documentao: Anlise estruturada da documentao existente de projetos similares; Tcnicas de reunio de informao: Brainstorming, Delphi, entrevista a especialistas e SWOT; Checklists: Normalmente elaborados a partir de dados histricos de projetos similares; Anlise das premissas: Este processo consiste em comparar as premissas adotadas durante a fase de concepo do projeto com o real, e levantar os riscos em caso de divergncias; Tcnicas de diagramao: Diagramas de Causa-e-Efeito, Fluxogramas e Diagramas de Influencia.

Uma vez identificados, os riscos podem ser divididos em cinco categorias: Tcnica, Programtica, Suporte, Custo e Cronograma (PRITCHARD, 2001). Esta diviso tem o objetivo de focar os melhores esforos nos riscos certos. Na Tabela 02 encontramos exemplos de riscos que podemos encontrar em cada uma das categorias:
Categoria do Risco Tcnica Propriedades fsicas Propriedades materiais Propriedades de radiao Teste e modelao Disponibilidade de materiais Disponibilidade de pessoal Qualidade tcnica do pessoal Segurana Confiabilidade Treinamento e suporte Equipamentos Recursos humanos Sensibilidade ao risco tcnico Sensibilidade ao risco programtico Sensibilidade ao risco tcnico Sensibilidade ao risco programtico Fontes de Risco Integrao e interfaces Projeto de software Segurana Solicitao de mudanas Impacto ambiental Problemas de comunicao Greves Solicitao de mudanas Segurana do sistema Dados tcnicos Dados da edificao Dados e interoperabilidade Sensibilidade ao risco de suporte Sensibilidade a riscos do cronograma Sensibilidade ao risco de suporte Erro de estimativa Deteco de falhas Ambiente operacional Complexidade do sistema Recursos nicos e especiais Mudanas polticas Estabilidade da Contratante Perfil de financiamento Mudanas regulatrias Transportabilidade Suporte a recursos computacionais Embalagem, manuseio e armazenamento Margens Erro de estimativa Sensibilidade aos riscos do custo Nmero de caminhos crticos

Programtica

Suporte

Custo

Cronograma

Tabela 02 - Fontes tpicas de risco, por categoria (Pritchard, 2001, Tab. 1)

De acordo com Pritchard (2001), nem todo risco identificado precisa ser gerenciado, porm a deciso qual risco gerenciar e como agir deve cuidadosamente analisada para evitar a gerao equivocada de um risco negativo, no previsto (NRC, 1989). A atividade de identificar riscos e o seu plano de ao so dinmicos, sendo assim fundamental a constante monitorao do processo, isto evitar surpresas indesejadas. Na escolha de quais riscos devem ser gerenciados modelos so bastante teis, porm sua aplicao deve ser muito criteriosa. Nas organizaes, o normal, cada pessoa ou departamento tentar encobrir suas deficincias e camuflar os verdadeiros riscos, o que dificulta o sucesso da aplicao do modelo. Cabe ao time de gerenciamento trabalhar as informaes, eliminar as equivocadas e obter os resultados desejados (PRITCHARD, 2001).

ENEGEP 2004

ABEPRO

4251

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

A identificao dos riscos do projeto, pode ser feita utilizando-se uma ferramenta bastante til e prtica, que consiste de trs passos que sero detalhados em seguida: Passo 1: Na planilha-modelo, Tabela 03, os riscos so anotados, detalhados e classificados quanto a sua criticidade, e os Impactos e a suas Magnitudes so divididos em nove subclasses. Esta diviso tem por objetivo facilitar priorizao das atividades de impactos semelhantes, flexibilizando a graduao, sem perder a praticidade.
Impacto do Risco Atividade Baixo Mdio (1-3) (4-6) Alto (7-9) Magnitude do Impacto Baixo Mdio (1-3) (4-6) Alto (7-9) Ao Planejada

Tabela 03 - Modelo de Planilha para Anlise de Riscos

Passo 2: Na Figura 3 so marcados os pontos na matriz de Impacto x Magnitude, ficando distribudos nas trs reas, que demonstram: o que deve ser gerenciado (Riscos Crticos regio vermelha), o que deve ser monitorado de perto (Riscos Mdios - regio amarela) e o que no precisa ser gerenciado (Riscos Leves - regio azul). Passo 3: Elaborao do Plano de Ao de modo que seja to abrangente quanto possvel e que analise o projeto em todas as suas interfaces, evitando assim que uma ao tenha uma reao negativa em outra parte do projeto. O resultado dever ser anotado na coluna Ao Planejada da Tabela 03. 3. Aspectos Metodolgicos

A abordagem metodolgica de estudo de caso foi utilizada para elaborar uma anlise do modelo de risco advogado pelo PMBoK (PMI, 2000) aplicado a implementao de projetos de software (YIN, 1991; CLAVER et al., 2000). Os critrios para seleo do caso foram: a complexidade do projeto que justifique uma abordagem estruturada de risco, a organizao e estruturao da atividade de projetos e investimentos crescentes na atividade de projetos. 4. Gerenciando Riscos: Estudo de Caso

Esta seo tem por objetivo demonstrar a viabilidade do modelo apresentado na seo 3 atravs de sua aplicao. 4.1 Escopo

Baseia-se na substituio do Software AAA de uma rede de acesso de mbito nacional que possui como clientes provedores de acesso a Internet, bancos, autarquias, etc.. A deciso de substituio ocorreu por trs motivos: 4.2 O software existente possua protocolo proprietrio, que dificultava a ampliao da rede com outros vendors; O novo software atende aos protocolos Radius (IETF, 2000), sendo assim, multivendor; O novo software permite o gerenciamento e a configurao centralizada da rede. Gerenciamento do Risco:

ENEGEP 2004

ABEPRO

4252

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

Esta seo apresenta de forma objetiva os principais riscos negativos encontrados durante o processo de implantao do escopo descrito na seo 5.1, os quais foram divididos nas seguintes categorias:
Categoria do Risco Tcnica Programtica Suporte Fonte do Risco Escopo: Tanto a RFP (Request for Proposal) quanto a proposta tcnica no eram claros. Isto tinha impacto na aceitao do trabalho e na receita. Problemas de comunicao: O time de Operao do cliente no desejava a substituio do software. Isto dificultava a obteno de informaes fundamentais ao projeto. Falta de especialistas no software: O time local no possua conhecimento tcnico suficiente para implantao do software. Isto tinha impacto direto no cronograma e no custo do projeto. Margens Sensibilidade ao risco tcnico Sensibilidade ao risco programtico Sensibilidade ao risco de suporte Sensibilidade ao risco de cronograma Sensibilidade ao risco tcnico Sensibilidade ao risco programtico Sensibilidade ao risco de suporte Sensibilidade ao risco de custo Grau de simultaneidade de tarefas

Custo

Cronograma

Tabela 04 - Categorias dos riscos do Caso e as suas fontes

Como podemos observar na Tabela 04, os riscos so interdependentes e dinmicos, qualquer ao tomada com o objetivo de mitigar um deles poderia afetar um outro. A estratgia adotada foi focar em aes que fossem simples, porm efetivas, buscando com poucas aes mitigar o maior nmero possvel de riscos. Na Tabela 05 so apresentados os riscos crticos negativos encontrados e seus planos de ao (Passos 1 e 3):
Impacto do Risco Atividade Magnitude do Impacto

Baixo Mdio Alto Baixo Mdio Alto (1-3) (4-6) (7-9) (1-3) (4-6) (7-9)

Aes Planejadas Agendada reunio com todos os interessados para equalizar as expectativas; Elaborao do documento tcnico onde todas as atividades foram listadas, negociadas e o escopo foi fechado; Controle estrito do escopo. Aceitao de ajustes e negociao de servios adicionais complementares. Definir os responsveis da Operao e da Engenharia que atuaro no projeto como facilitadores, e conseqentemente, como responsveis por obter as informaes necessrias; Atribuir no cronograma marcos de entrega de informaes da parte do cliente; Fazer apresentaes tcnicas a gerencia da operao, mostrando as vantagens da substituio; Treinar o time do cliente no novo software. Treinar o time local; Definir os responsveis da parte da Implementao, Engenharia e Suporte do time local que seriam treinados e seriam responsveis por acompanhar o especialista estrangeiro; Passar todas as informaes obtidas para os especialistas dos EUA para eles elaborarem o projeto de implantao do software, de acordo com as necessidades do cliente; Trazer especialista de uma outra unidade da empresa, preferencialmente da Amrica Latina (devido ao custo); Desenvolver processo de modo a no interferir na implantao dos equipamentos

1. Fechar escopo do projeto

2. Obter apoio da Operao do cliente

3. Adequar a capacitao tcnica do time local

4. Atender ao cronograma

Tabela 05 - Planilha com os riscos do Caso e o respectivo Plano de Ao

ENEGEP 2004

ABEPRO

4253

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

Listados os riscos e atribudos pesos aos seus impactos e magnitudes, estes dados foram assinalados no grfico (Passo 2), onde obtivemos o seguinte resultado:
(1)

Alto

(2 ; 3)

(4)

Impacto do Risco

Mdio Baixo

1 1

2 Baixo

5 Mdio

8 Alto

Magnitude do Risco

Figura 03 Matriz Impacto x Magnitude - Anlise de Riscos do Caso

Deste caso os seguintes pontos merecem destaque: Na planilha os riscos no precisam no primeiro momento ser listados em ordem de prioridade. Esta prioridade ser definida pelo grfico: os pontos localizados acima e a direita tm prioridade sobre os demais; Estes riscos foram considerados crticos por afetarem o projeto como um todo, ao comprometer o que Forsberg & Mooz (1996) chamam de principais pilares do projeto: Custo, Escopo e Cronograma. O PMI (PMI, 2000, Cap. 1.3.2) mais abrangente quanto ao que considera rea de Conhecimento da Gerncia de Projeto, porm em escolhendo os itens acima houve foco em solucionar a causa raiz dos riscos; Os demais riscos no foram listados por no serem relevantes ao artigo. Concluses:

5.

O modelo do PMBoK (PMI, 2000) mostrou-se sinrgico as ferramentas aplicadas a rea de software e permitiu a construo de um procedimento de gerenciamento de risco coerente. Pritchard (2001) sustenta que os riscos so do tamanho da complexidade do projeto. O artigo concorda com esta afirmao, pois projetos de TI devem ser gerenciados de forma estrita devido as suas caractersticas peculiares, o que exige determinao e disciplina dos seus gestores na aplicao de metodologias adequadas para cada caso. Por ser um processo dinmico, as ameaas e oportunidades devem ser monitoradas durante todo o ciclo de vida do projeto, e devem ser analisados como um todo, dentro do escopo do projeto, isto levar a aes efetivas para mitigao dos riscos, evitando que a ao de mitigao gere um novo risco. No estudo de caso pudemos observar que o gerenciamento estrito dos riscos foi efetivo, pois levou o time de gerenciamento do projeto a obter resultados satisfatrios.

ENEGEP 2004

ABEPRO

4254

XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil, 03 a 05 de nov de 2004

O principal risco encontrado (Tabela 5, Atividade 1) poderia ter fadado o projeto ao fracasso. Foi demonstrado que, gerenciado de forma adequada, o risco foi mitigado, diminuiu a criticidade dos demais e gerou novas oportunidades (riscos positivos), que j geraram receita muitas vezes superior a inicial. Isto no seria possvel se este risco no tivesse sido tratado adequadamente, no tempo certo. 6. Bibliografia:

Boehm, B. W.: A Spiral Model of Software Development, The Institute of Electrical and Electronics Engineers Inc. (IEEE), 1988. Bugala, P. Worldwide Network and Service Management Forecast and Analysis,2003 2007, IDC Company, (http://www.idc.com/getdoc.jhtml;jsessionid=XQVC3D2T5FPEOCTFA4FSFEYKMUDYUIWD? containerId=28827 ), Agosto/2003. Carvalho, M. M.; Laurindo, F. J. B.; Pessa, M. S. P. (2003) Information Technology Project management to achieve efficiency in Brazilian Companies. In: KAMEL, Sherif. (Org.). Managing Globally with Information Technology.. Hershey, p. 260-271. Claver, E.; Gonzalez, R.; Llopis, J. : An analysis of research in information systems (1981-1997). Information & Management, v.37, n.4, p.181-195, Apr. 2000. Forsberg, K., Mooz, H.; Cotterman, H.: Visualizing Project Management, John Wiley & Sons, Inc, 1996. IEEE Computer Society, Standard Glossary of Software Engineering terminology, The Institute of Electrical and Electronics Engineers Inc. (IEEE), 1990. IETF Internet Engineering Task Force, RFCs: 2865, 2866, 2867, 2868, 2869 e outros, RADIUS Task Force, 2000. Linsmeier; W Pearson; R. An Introduction to Value at Risk Thomas J. Linsmeier e Neil D. Pearson University of Illinois Julho de 1996. NRC, National Research Council Committee on Risk Perception Communications, Improving Risk Communication, National Academy Press, 1989. Pritchard, C. L.: Risk Management Concepts and Guidance, ESI International, 2001. Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge, Project Management Institute Inc., 2000. Provost, M. Enterprise Infrastucture Seo Company Assesment, Current Analysis (http:// www.currentanalysis.com/currentcompete/index.cfm?nav=2&key=9m1dN514f4S&Ve ndorID=3558&FD=0&CFID=2806563&CFTOKEN=73772473), Agosto/2003.

Royce, Winston W.: Managing the Development of Large Software Systems, IEEE, 1970. Soares, E.;Graa, A. Hora de ir a luta - Seo Mercado, Revista Negcios em Telecomunicaes RNT 283, Advanstar, Maro/2003. Ward, J. LeRoy: Project Management Terms: A Working Glossary, ESI International, 2000. Winkler, R. L.: The Quantification of Judgment: Some Methodological Suggestions, Journal of the American Statistical Association 62, 1967 Yin, R.K.: Case Study Research: Design and Methods. Newbury Park, Rev. ed. Sage Publications,1991.

ENEGEP 2004

ABEPRO

4255