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.

Projetos de TI: Desafios atuais

2.1

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

Avaliar Alternativas:
Identificar e Mitigar
Riscos

Sentido do Progresso
do Processo

Anlise de Risco

Anlise de Risco

Anlise de Risco

Comprometimento

Planejamento dos
Requisitos e do
Ciclo de Vida

Gerar o Plano de
Desenvolvimento do
Prximo Nvel do
Desenvolvimento

Prottipo 2

Simulaes
Conceito da
Operao Requerimentos
do Software

Determinar Processos,
Objetivos,Alternativas
e Restries

Teste de
Aceitao

Planejamento das
Prximas Fases

Validao e
Verificao
do Projeto
Implementao

Plano de
Integrao
e Teste

Avaliar alternativas do
processo: Avaliao e
Resoluo dos Riscos

Prottipo 3
Modelos

Projeto de
Implantao
do Software

Plano de Validao dos

Desenvol- Requerimentos
vimento

Integrao e
Teste

Partio do
Reviso

Prottipo
Operacional

Prottipo 1

Teste da
Unidade

R
A

Benchmarks

Detalhamento
do Projeto

Codificao

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):

Objetivo
do Projeto
Custo
Prazo
Escopo
Qualidade

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

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

da

<5% de Atraso

5 10% de Atraso

reas no crticas
so afetadas

reas crticas
afetadas

Apenas aplicaes
de alta demanda
so afetadas

Reduo da qualidade
necessita
de
aprovao do cliente

so

Muito Alto
0,80
>20% de Incremento
de Custo

10 - 20% de Atraso

>20% de Atraso

Reduo de escopo
no aceitvel pelo
cliente
Reduo da qualidade
inaceitvel pelo cliente

Impossibilidade
concluir o projeto

de

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

Programtica

Suporte

Custo

Cronograma

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

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:

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.

4.2

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

Custo

Cronograma

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

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

Aes Planejadas

Baixo Mdio Alto Baixo Mdio Alto

(1-3) (4-6) (7-9) (1-3) (4-6) (7-9)

1. Fechar
escopo do
projeto

2. Obter apoio
da Operao
do cliente

3. Adequar a
capacitao
tcnica do
time local

4. Atender ao
cronograma

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

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:

(2 ; 3)

(4)

6
5

Mdio

4
2
1

Baixo

Impacto do Risco

Alto

(1)

2
Baixo

Mdio

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.

5.

Concluses:

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

Provost,

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