Universidade Federal Do Rio de Janeiro Escola Politécnica Dcc/Npac

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
ESCOLA POLITCNICA
DCC/NPAC
ESTUDOS DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO

SOBRE PROJETO DE TRANSIO DE AMBIENTES CRTICOS
Paulo Souza Toledo Junior
2006
ESTUDOS DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO SOBRE
PROJETO DE TRANSIO DE AMBIENTES CRTICOS
Monografia apresentada no Curso de

Ps-Graduao em Gerenciamento de
Projetos, da Escola Politcnica, da
Universidade Federal do Rio de
Janeiro.
Orientadores:
Eduardo Linhares Qualharini
Maria Alice Ferruccio Rainho
Rio de Janeiro
Julho, 2006
ESTUDOS DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO SOBRE
Orientadores:
Eduardo Linhares Qualharini e Maria Alice Ferruccio Rainho
Monografia submetida ao Curso de Ps-graduao Gerenciamento de Projetos, da

Escola Politcnica, da Universidade Federal do Rio de Janeiro UFRJ, como parte
dos requisitos necessrios obteno do ttulo de Especialista em Gerenciamento de
Projetos.
Aprovado por:
______________________________________
Eduardo Linhares Qualharini
Orientador
______________________________________
Lysio Sllos da Costa Filho
______________________________________
Andr Dametto
______________________________________
Maria Alice Ferruccio Rainho
Orientadora
Rio de Janeiro
Julho, 2006
ii
TOLEDO JR, Paulo Souza.
Estudo de Riscos em Projetos de TI: Estudo de
Caso sobre Projeto de Transio de Ambientes Crticos /
TOLEDO JR, P. S. Rio de Janeiro: UFRJ/EP, 2006.
x, 34f.: il.; 29,7cm.
Orientadores: Eduardo Linhares Qualharini, Maria
Alice Ferruccio Rainho.
Monografia (especializao) UFRJ/ Escola
Politcnica/ Curso de Especializao em Engenharia,
NPAC, 2005.
Referncias Bibliogrficas: 33-34.
1. Gerenciamento. 2. Riscos. 3. Projetos TI.-
Monografia. I. QUALHARINI, E. L.; RAINHO, F, M. A. II.
Universidade Federal do Rio de Janeiro, Escola
Politcnica, Ps-graduao. III. Especialista.
iii
A
Deus, Sponsor Supremo;
Jesus Cristo, Gerente de todos os meus
Projetos e meu melhor Amigo; e Vanessa
Toledo, Stakeholder e minha amada
Esposa.
iv
Agradecimentos
A DEUS, por conduzir nossas vidas pelos

caminhos certos.
A minha esposa, simplesmente por existir.
Aos meus pais, pelos esforos em basear
minha formao
sobre valores morais e dignos.
Aos meus amigos e colegas de trabalho,
que junto vivenciaram
a superao de mais esta etapa.
A estas pessoas, e todas as demais, que
de alguma forma participaram
contribuindo para o xito deste trabalho,
meus sinceros agradecimentos.
v
RESUMO
ESTUDO DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO SOBRE

Resumo da Monografia submetida ao corpo docente do curso de Ps-Graduao em

Gerenciamento de Projetos Universidade Federal do Rio de Janeiro UFRJ, como
parte dos requisitos necessrios obteno do ttulo de Especialista em
Gerenciamento de Projetos.
Este trabalho pretende apresentar um estudo de caso sobre o projeto de transio de

um dos vinte e seis ambientes crticos de uma determinada Empresa no ramos de
Telecomunicaes, focando o gerenciamento dos riscos em projetos de TI, sobre o
prisma da Metodologia do PMI agregada ao ponto de vista do CobiT Metodologia
utilizada em Governana de TI , de forma que se possa criticar a anlise realizada
nesta transio; compartilhando assim das experincias conquistadas na prtica e
com as lies aprendidas de projetos anteriormente realizados com escopos similares.
Palavras-chave: Gerenciamento, Riscos, Projetos TI.
Rio de Janeiro
Julho, 2006
vi
SUMRIO
1 INTRODUO ................................................................................................ .1
1.1 Justificativa do Tema....................................................................................... .1
1.2 Objetivos ......................................................................................................... .2
1.2.1 Objetivo Geral ................................................................................................. .2
1.2.2 Justificativa e Importncia ............................................................................... .2
1.2.3 Objetivos Especficos ...................................................................................... .2
1.3 Descrio do Problema ................................................................................... .3
1.4 Hipteses ........................................................................................................ .3
1.5 Estrutura do Trabalho...................................................................................... .3
2 GERENCIAMENTO DE PROJETOS .............................................................. .4
2.1 O que gerenciamento de projetos ................................................................ .4
2.2 reas de Conhecimento em Gerenciamento de Projetos ................................ .6
2.3 Processos dos Projetos ................................................................................... .8
2.4 Grupos de Processos ........................................................................................9
3 O GERENCIAMENTO DE RISCOS EM PROJETOS DE TI............................11
3.1 O que Risco do Projeto? ..............................................................................11
3.2 O que Risco de TI? ......................................................................................11
3.2.1 Classes de Risco de TI ...................................................................................12
3.3 Por que Muitas Empresas No Praticam a Gerncia de Riscos? ....................12
3.4 Metodologias Praticadas no Mercado .............................................................14
3.4.1 Sobre Gerenciamento de Projetos ..................................................................14
3.4.2 Sobre Governana de TI .................................................................................15
3.5 Comentrios Sobre Gerenciamento de Riscos (Apndice A) ..........................17
4 AS EMPRESAS ..............................................................................................18
4.1 Cliente .............................................................................................................18
4.1.1 Perfil da Empresa ............................................................................................18
4.1.2 Estrutura Organizacional do Cliente ................................................................20
4.2 Fornecedor ......................................................................................................21
4.2.1 Perfil da Empresa ............................................................................................21
4.2.2 Estrutura Organizacional do Fornecedor .........................................................22
4.3 Contrato de Outsourcing do Cliente com o Fornecedor ...................................22
4.3.1 Resumo do Escopo do Contrato......................................................................23
4.3.2 Estrutura Hierrquica do Fornecedor para o Cliente........................................25
5 O PROJETO DE TRANSIO .......................................................................27
5.1 Compreenso do Ambiente do Projeto ............................................................27
vii
5.2 Estrutura Hierrquica do Fornecedor para o Projeto de Transio ..................27
5.3 Ambientes Crticos ..........................................................................................28
6 CONCLUSES E PROPOSIES ................................................................31
REFERNCIAS BIBLIOGRFICAS.............................................................................33
APNDICE A
ANEXO
viii
LISTA DE FIGURAS
Figura 1: Viso geral das reas de conhecimento em gerenciamento de

projetos e os processos de gerenciamento de projetos ........................ 8
Figura 2: Diagrama de Processos dos Projetos ..........................................................9
Figura 3: Grfico de Impacto de Riscos ....................................................................13
Figura 4: Organizao matricial fraca .......................................................................20
Figura 5: Organizao composta ..............................................................................22
Figura 6: Organograma de On-Going .......................................................................25
Figura 7: Organograma de Transio .......................................................................27
LISTA DE QUADROS
Quadro 1: Nmero de Metodologias Utilizadas pelas Organizaes ........................14
LISTA DE TABELAS
Tabela 1: Ambientes Contemplados na Transio ....................................................28
ix
LISTA DE ABREVIATURAS E SIGLAS
ATM Asynchronus Transfer Mode (Modo de Tranferncia Assncrona)

CPU Central Processor Unit (Unidade Central de Processamento)
CT Centro Tecnolgico
DBA Database Administrator (Administrador de Banco de Dados)
EAP Estrutura Analtica do Projeto
GP Gerente de Projeto
IP Internet Protocol (Protocolo Internet)
ISP Internet Solution Provider (Provedor de Servio de Internet)
LAN Local Area Network (Rede Local)
MPLS Multiple Protocol Label Switching
ODBC Open Database Connectivity (Conectividade em Banco de Dados
Abertos)
PDCA Plan Do Check Act (Mtodo de Melhorias Planejar Executar Checar
Atuar)
P&D Pesquisa & Desenvolvimento
PMBOK Project Management Body Of Knowledge (Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos)
PMI Project Management Institute (Instituto de Gerenciamento de Projetos)
PMO Project Management Office (Escritrio de Gerenciamento de Projetos)
QA Quality Assurance (Garantia da Qualidade)
RAID Redundant Array of Independent Disks (Conjunto Redundante de
Discos Independentes)
RAM Random Access Memory (Memria de Acesso Randmico)
SLA Service Level Agreement (Nvel de Atendimento de Servio)
SOW Statement Of Work (Documento de Trabalho)
TI Tecnologia da Informao
VIP Very Important Person (Pessoa Muito Importante)
WAN Wide Area Network (Rede Geograficamente Distante)
x
1
1 INTRODUO
Com a evoluo tecnolgica das ltimas dcadas surgiram inmeras

linguagens de programao, sistemas operacionais, bancos de dados, servidores de
aplicao, infra-estrutura de rede e diversos outros componentes que devem ser
levados em considerao no desenho da soluo de um sistema de TI [PEREZ, 2006].
A cada dia fica mais clara a percepo de que gerenciar projetos gerenciar
riscos. interessante observar a ingenuidade que existia por trs das tcnicas de
gerenciamento de projetos at h alguns anos atrs. Estas tcnicas partiam do
princpio, absurdamente otimista, de que nada iria dar errado ao longo do projeto. Ou
seja, ningum iria pedir demisso, ficar doente, ou mesmo render menos do que o
projetado no incio. Todas as ferramentas de desenvolvimento iriam funcionar
perfeitamente, no conteriam bugs, seriam fceis de aprender e de utilizar e assim por
diante. Os usurios saberiam exatamente o que querem, e seus desejos e
necessidades no mudariam durante o projeto. Alm disso, os analistas seriam
capazes de entender perfeitamente estas necessidades, sem nenhuma ambigidade e
sem deixar nada de fora. A fase de testes no revelaria muitos defeitos, apenas um
nmero suficiente deles, capaz de encher os dias previstos pelo cronograma original
para os testes. No haveria nenhum problema de hardware, nenhum vrus apareceria,
nenhum arquivo desapareceria. Depois, ningum entendia porque os planos e
cronogramas do projeto nunca davam certos [BELLOQUIM, 2006].
A maioria dos especialistas em TI acreditam que sendo um bom tcnico e

conhecendo todos esses componentes, os riscos de erros nos sistemas a serem
desenvolvidos so mnimos ou at mesmo quase inexistentes.
No entanto, essas mesmas pessoas esquecem de diversos fatores que podem

influenciar positivamente ou no os sistemas desenvolvidos hoje em dia, que so
justamente as disciplinas apontadas no PMBoK. E devido essa falha j de
conhecimento da maioria dos profissionais de informtica que existe uma grande
necessidade no s da presena e atuao do gerente de projetos, mas da
maturidade de todos esses profissionais de assumir essa necessidade.
1.1 Justificativa do Tema
Escolhido por se tratar de um projeto no qual tive participao ativa e decisria

para que o resultado esperado fosse alcanado com sucesso. Projeto que poderia
alavancar a minha carreira, com grande probabilidade de, ao trmino do mesmo, sair
2
da minha rea de atuao como Especialista em Sistemas Operacionais da

Microsoft e iniciar a minha carreira de Gerente de Projetos.
1.2 Objetivos
1.2.1 Objetivo Geral
Enfatizar o conceito de riscos e a importncia de praticar a sua gesto dentro

de projetos, abordando os principais processos definidos no PMBoK relativos ao
gerenciamento desta rea de conhecimento. Prticas que fundamentam alguns destes
processos sero apresentadas, visando consubstanciar o que est sendo exposto.
1.2.2 Justificativa e Importncia
Muito importante para a compreenso do problema apresentado, a disciplina

TI nas empresas. Como ela ainda vista, por muitos gestores, como uma grande
consumidora de recursos, que no uma inverdade, empresrios relegam a segundo
plano os gastos ditos no necessrios para a operao das atividades desta rea.
Estes empresrios assumem os riscos de TI sem o mnimo de conhecimento da sua
extenso e impacto [GALVES, 2006].
Para conhecimento de todos os riscos de TI importante que esta rea tenha

uma metodologia bsica e cada gestor e equipe estejam preparados para validar
Riscos; entender a extenso das perdas e impactos e habilitados a elaborar e manter
Planos de Contingncia. imprescindvel tambm que as Gerncias operacionais e os
tcnicos estejam, alm de preparados para apontar estes Riscos, definir aes
preventivas e corretivas a serem aprovadas pelos rgos superiores.
1.2.3 Objetivo Especfico
- Realizar um estudo de caso sobre o Projeto de Movimentao de Servidores

(transio de ambientes crticos) de uma grande empresa no ramo de
telecomunicaes (a qual ser denominada como CLIENTE) para o CT (Centro
Tecnolgico), da empresa em que trabalho, cuja localizao Hortolndia SP (a
empresa prestadora de servios ser denominada como FORNECEDOR);
- Fazer uma anlise crtica focada na rea de conhecimento de riscos e, se

cabvel, sugerir melhorias baseadas nas lies aprendidas, que sirvam para futuros
projetos de TI com escopos similares.
3
1.3 Descrio do Problema
Devido a um aditivo de contrato; transicionar, no perodo de 1 de junho de 2005

a 31 de janeiro do ano seguinte, 26 ambientes crticos localizados nos Data Centers
do CLIENTE (RJ e SP) para o CT do FORNECEDOR, em Hortolndia. Entretanto,
alguns ambientes poderiam ter a data de cutover (migrao) independente ou
coincidente com outros ambientes em alguns casos, essa coincidncia foi
obrigatria.
1.4 Hipteses
- Transicionar os 26 ambientes de forma a garantir o cumprimento da restrio

tripla (escopo, tempo e custo) e a qualidade das mudanas acordadas com o
CLIENTE;
- Transicionar menos ambientes devido a futuras redues no escopo por parte

do CLIENTE, mas sem reduo de prazo;
- Cancelamento do projeto, em dado momento, pelo CLIENTE com pagamento

de multa rescisria para o FORNECEDOR;
- Pagamento de multa, ao CLIENTE, por atraso no cutover de cada ambiente.
1.5 Estrutura do Trabalho
Alm desta introduo, o trabalho compreende os seguintes captulos:
O Captulo 2 contempla uma reviso bsica e sintetizada do aprendizado

obtido em gerenciamento de projetos, ou seja, a reviso literria. No Captulo 3, foram
abordados assuntos especficos sobre o gerenciamento de riscos em projetos de TI
sobre o prisma de duas metodologias: PMI e CobiT. No Captulo 4, foram colocadas
algumas informaes sobre as empresas CLIENTE e FORNECEDOR, na qual se
realizou o estudo de caso, passando em seguida para o Captulo 5 aonde foi
estabelecida a metodologia da pesquisa. Na sequncia, este Captulo aponta para o
Apndice A cujo detalhamento do projeto objeto do estudo e suas anlises so
realizadas. concluso (Captulo 6), a bibliografia e o Anexo I, encerram este
trabalho.
4
2 GERENCIAMENTO DE PROJETOS
Este captulo baseado na idia de fazer uma reviso dos principais conceitos
de gerenciamento de projetos utilizados pelo PMI, os quais foram passados ao longo
do Curso de Ps-graduao em Gerenciamento de Projetos, da Escola Politcnica, da
Universidade Federal do Rio de Janeiro UFRJ.
2.1 O que Gerenciamento de Projetos?
Segundo o PMI [2004], o gerenciamento de projetos a aplicao de

conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de
atender aos seus requisitos. O gerenciamento de projetos realizado atravs da
aplicao e da integrao dos seguintes processos de gerenciamento de projetos:
iniciao, planejamento, execuo, monitoramento e controle, e encerramento. O
gerente de projetos a pessoa responsvel pela realizao dos objetivos do projeto.
Gerenciar um projeto inclui:
- Identificao das necessidades;
- Estabelecimento de objetivos claros e alcanveis;
- Balanceamento das demandas conflitantes de qualidade, escopo,

tempo e custo; e
- Adaptao das especificaes, dos planos e da abordagem s

diferentes preocupaes e expectativas das diversas partes interessadas.
Por que devemos gerenciar projetos
Podemos destacar alguns motivos para que as mudanas sejam bem

administradas [POSSI, 2004]:
- Para evitar surpresa durante a execuo dos trabalhos, antecipando

riscos e situaes desfavorveis que podero ser encontradas. Projetos bem
geridos reduzem os riscos de surpresas e situaes desfavorveis. Caso essas
surpresas ou situaes apaream, o profissional sabe como contorn-las sem
ter que parar o andamento de um projeto;
- Para agilizar as decises, j que as informaes esto estruturadas e

disponveis. Sem a organizao dessas informaes (andamento do projeto,
riscos que esto surgindo e resultados j obtidos) no h tambm a agilizao
5
dessas decises (como a captao de recursos, alocao de pessoal),

retardando ou parando o projeto e dificultando a chegada ao resultado
proposto inicialmente;
- Para facilitar e orientar as revises do projeto. Com as informaes

(citadas no ponto anterior) disponveis, tem-se um maior controle sobre o
projeto, podendo revis-lo sempre que necessrio e redirecion-lo de uma
forma simples e vivel;
- Para otimizar a alocao de pessoas;
- Para documentar e facilitar estimativas para futuros projetos.

Documentar o conhecimento adquirido em projetos anteriores ou numa
primeira fase de um projeto em andamento que auxiliaria na reduo de riscos
e aumentando as probabilidades de sucesso de um projeto. Tambm se pode
aproveitar essas informaes/conhecimentos para replanejar o projeto.
Conforme argumentao do PMI [2004:8]; os gerentes de projetos

freqentemente falam de uma restrio tripla escopo, tempo e custo do projeto
no gerenciamento de necessidades conflitantes do projeto. A qualidade do projeto
afetada pelo balanceamento desses trs fatores. Projetos de alta qualidade entregam
o produto, servio ou resultado solicitado dentro do escopo, no prazo e dentro do
oramento. A relao entre esses fatores ocorre de tal forma que se algum dos trs
fatores mudar, pelo menos um outro fator provavelmente ser afetado. Os gerentes de
projetos tambm gerenciam projetos em resposta a incertezas. Um risco do projeto
um evento ou condio incerta que, se ocorrer, ter um efeito positivo ou negativo em
pelo menos um objetivo do projeto.
A equipe de gerenciamento de projetos possui uma responsabilidade

profissional com suas partes interessadas, inclusive clientes, a organizao executora
e o pblico.
importante observar que muitos processos dentro do gerenciamento de

projetos so interativos devido existncia, e necessidade, de uma elaborao
progressiva em um projeto durante todo o ciclo de vida do projeto. Isto , conforme
uma equipe de gerenciamento de projetos aprende mais sobre um projeto, poder
gerenciar com um nvel maior de detalhes.
O termo gerenciamento de projetos s vezes usado para descrever uma

abordagem organizacional ou gerencial do gerenciamento de projetos e de algumas
operaes j em andamento, que podem ser redefinidas como projetos, o que tambm
chamado gerenciamento por projetos.
6
2.2 reas de Conhecimento em Gerenciamento de Projetos
O PMI [2004], descreve nove reas de conhecimento; sendo elas:
Gerenciamento de integrao do projeto, descreve os processos e as

atividades que integram os diversos elementos do gerenciamento de projetos, que so
identificados, definidos, combinados, unificados e coordenados dentro dos grupos de
processos de gerenciamento de projetos. Ele consiste nos processos de
gerenciamento de projetos: Desenvolver o termo de abertura do projeto, Desenvolver
a declarao do escopo preliminar do projeto, Desenvolver o plano de gerenciamento
do projeto, Orientar e gerenciar a execuo do projeto, Monitorar e controlar o trabalho
do projeto, Controle integrado de mudanas e Encerrar o projeto.
Gerenciamento do escopo do projeto, descreve os processos envolvidos na

verificao de que o projeto inclui todo o trabalho necessrio, e apenas o trabalho
necessrio, para que seja concludo com sucesso. Ele consiste nos processos de
gerenciamento de projetos: Planejamento do escopo, Definio do escopo, Criar EAP,
Verificao do escopo e Controle do escopo.
Gerenciamento de tempo do projeto, descreve os processos relativos ao

trmino do projeto no prazo correto. Ele consiste nos processos de gerenciamento de
projetos: Definio da atividade, Seqenciamento de atividades, Estimativa de
recursos da atividade, Estimativa de durao da atividade, Desenvolvimento do
cronograma e Controle do cronograma.
Gerenciamento de custos do projeto, descreve os processos envolvidos em

planejamento, estimativa, oramentao e controle de custos, de modo que o projeto
termine dentro do oramento aprovado. Ele consiste nos processos de gerenciamento
de projetos: Estimativa de custos, Oramentao e Controle de custos.
Gerenciamento da qualidade do projeto, descreve os processos envolvidos

na garantia de que o projeto ir satisfazer os objetivos para os quais foi realizado. Ele
consiste nos processos de gerenciamento de projetos: Planejamento da qualidade,
Realizar a garantia da qualidade e Realizar o controle da qualidade.
Gerenciamento de recursos humanos do projeto, descreve os processos

que organizam e gerenciam a equipe do projeto. Ele consiste nos processos de
gerenciamento de projetos: Planejamento de recursos humanos, Contratar ou
mobilizar a equipe do projeto, Desenvolver a equipe do projeto e Gerenciar a equipe
do projeto.
7
Gerenciamento das comunicaes do projeto descreve os processos

relativos gerao, coleta, disseminao, armazenamento e destinao final das
informaes do projeto de forma oportuna e adequada. Ele consiste nos processos de
gerenciamento de projetos: Planejamento das comunicaes, Distribuio das
informaes, Relatrio de desempenho e Gerenciar as partes interessadas.
Gerenciamento de riscos do projeto descreve os processos relativos

realizao do gerenciamento de riscos em um projeto. Ele consiste nos processos de
gerenciamento de projetos: Planejamento do gerenciamento de riscos, Identificao de
riscos, Anlise qualitativa de riscos, Anlise quantitativa de riscos, Planejamento de
respostas a riscos e Monitoramento e controle de riscos.
Gerenciamento de aquisies do projeto descreve os processos que

compram ou adquirem produtos, servios ou resultados, alm dos processos de
gerenciamento de contratos. Ele consiste nos processos de gerenciamento de
projetos: Planejar compras e aquisies, Planejar contrataes, Solicitar respostas de
fornecedores, Selecionar fornecedores, Administrao de contrato e Encerramento do
contrato.
As reas de conhecimento em gerenciamento de projetos, organiza os 44

processos de gerenciamento de projetos dos grupos de processos de gerenciamento
de projetos, conforme exibido, a seguir, na figura 1.
8
Figura 1 Viso geral das reas de conhecimento em gerenciamento de projetos e os

processos de gerenciamento de projetos
Fonte: PMI [2004:11]
2.3 Processos dos Projetos
Os processos dos projetos so realizados por pessoas e normalmente se

enquadram em uma das duas categorias [POSSI, 2004]:
- Processos do gerenciamento de projetos se relacionam com a

descrio e a organizao do trabalho do projeto. Os processos de
gerenciamento de projetos, que so aplicveis maioria dos projetos.
- Processos orientados ao produto se relacionam com a especificao

e a criao do produto do projeto. Os processos orientados ao produto so
9
definidos pelo ciclo de vida do projeto e variam de acordo com a rea de

aplicao.
Figura 2 Diagrama de Processos dos Projetos

Fonte: POSSI [2004:36]
Na figura acima, para os processos de Planejamento, Execuo e Controle,

pode ser utilizado o Ciclo PDCA (mtodo que se baseia no controle de processos
visando melhoria contnua) em alguns projetos como por exemplo na rea de P&D
para a criao de um novo produto ou tecnologia. Entretanto, esse loop (repetio) do
PDCA termina no processo de encerramento.
2.4 Grupos de Processos
Os processos de gerenciamento de projetos podem ser organizados em cinco

grupos, cada um deles contendo um ou mais processos [POSSI, 2004]:
- Iniciao, a fase inicial do projeto, quando uma determinada

necessidade identificada e transformada em um problema estruturado a ser
resolvido por ele. Nessa fase, a misso e o objetivo do projeto so definidos,
bem como as melhores estratgias so identificadas e selecionadas.
- Planejamento, a fase responsvel por detalhar tudo aquilo que ser

realizado pelo projeto, incluindo cronogramas, interdependncias entre
atividades, alocao de recursos envolvidos, anlise de custos etc, para que,
no final dessa fase, ele esteja suficientemente detalhado para ser executado
10
sem dificuldades e imprevistos. Nessa fase, os planos auxiliares de

comunicao, qualidade, riscos, suprimentos e recursos humanos tambm so
desenvolvidos.
- Execuo, a fase que materializa tudo aquilo que foi planejado

anteriormente. Qualquer erro cometido nas fases anteriores fica evidente
durante esse processo. Grande parte do oramento e do esforo do projeto
consumida nessa fase.
- Controle, a fase que acontece paralelamente ao planejamento

operacional e execuo do projeto. Tem como objetivo acompanhar e
controlar aquilo que est sendo realizado pelo projeto de modo a propor aes
corretivas e preventivas no menor espao de tempo possvel aps a deteco
de anormalidade. O objetivo do controle comparar o status atual do projeto
com o status previsto pelo planejamento, tomando aes corretivas em caso de
desvio.
- Encerramento, a fase quando a execuo dos trabalhos avaliada

atravs de uma auditoria interna ou externa (terceiros), os livros e documentos
do projeto so encerrados e todas as falhas ocorridas durante o projeto so
discutidas e analisadas para que os erros similares no ocorram em novos
projetos.
11
3 O GERENCIAMENTO DE RISCOS EM PROJETOS DE TI
3.1 O que Risco do Projeto?
Segundo o PMI [2004], o risco do projeto um evento ou condio incerta que,

se ocorrer, ter um efeito positivo ou negativo sobre pelo menos um objetivo do
projeto, como tempo, custo, escopo ou qualidade (ou seja, em que o objetivo de tempo
do projeto a entrega de acordo com o cronograma acordado; em que o objetivo de
custo do projeto a entrega de acordo com o custo acordado, etc.). Um risco pode ter
uma ou mais causas e, se ocorrer, um ou mais impactos.
O risco pode ser parametrizado utilizando percentagem, por exemplo ; j a

incerteza, no pode ser parametrizada existe ou no existe. Projetos trabalham com
incerteza, porm s possvel gerenciar o risco. Logo, o gerente de projeto tem o
objetivo de transformar o que pode ser uma vaga incerteza em risco identificado e, se
possvel, quantificado.
importante ressaltar que os riscos so referentes ao empreendimento

basicamente coisas que afetam o retorno de capital. Sendo assim, outros tipos de
riscos como sade, meio ambiente e segurana podem ser analisados, mas
sempre pelo prisma do negcio.
3.2 O que Risco de TI?
O risco de TI mais do que simplesmente a segurana de TI e inclui risco de

projeto, risco de arquitetura, risco com fornecedor, satisfao do cliente, dentre outros
fatores. A execuo de projetos de TI, em especial, bastante diferente da maioria
dos demais tipos de projetos , devido complexidade do empreendimento, a
constante dificuldade de visualizao do produto a ser desenvolvido ou do servio a
ser entregue; alm das dificuldades de comunicao entre o executor e o solicitante.
Portanto, nada mais natural, que a ocorrncia de eventos que impactem os objetivos
do projeto que no foram identificados durante a fase de planejamento. Este assunto
vem requerendo, por parte das empresas prestadoras de servios ou desenvolvedoras
de softwares, maior estruturao de suas fontes de riscos, face aos fracassos
anteriores em seus projetos.
12
3.2.1 Classes de Risco de TI
So definidas sete classes de riscos de TI, onde, em cada caso, ocorrendo

algum erro em TI, gera consequncias negativas para o negcio [JORDAN; SILCOCK,
2005]:
1. Projetos falhando na entrega quanto a implementao de novos

sistemas, atualizaes ou melhorias dos existentes;
2. Continuidade nos Servios de TI quando operaes de negcios

saem do ar, gerando indisponibilidade ou queda de performance que impactam os
usurios e o negcio;
3. Recurso da Informao falhando em proteger e preservar, seja por

uma estrutura inadequada de backup incidindo na no recuperao de dados perdidos
ou seja por falta de segurana da informao (vulnerabilidades que permitam a
espionagem industrial ou fraude) ;
4. Provedores de Servios e Vendedores quebra na cadeia de valores

de TI. Aplicaes de terceiros que so crticas para o negcio apresentam falhas
constantes e o suporte inadequado para a correo destas (ponto cuidadosamente
tratado em contratos de outsourcing);
5. Aplicaes sistemas falhando por manuteno inadequada dos

desenvolvedores internos;
6. Infraestrutura fundaes abaladas nome genrico para

computadores centralizados e distribudos, e recursos de rede os quais as aplicaes
esto hospedadas. Problemas diversos como sistemas operacionais com bugs,
cabeamento no estruturado, queda de energia no contingenciada etc.; e
7. Estratgico e Emergente desativado por TI. Quando ocorre um

desalinhamento estratgico e tecnolgico, impossibilitando a atualizao do parque
tecnolgico para gerar oportunidades e manter a concorrncia no mercado.
3.3 Por que Muitas Empresas No Praticam a Gerncia de Riscos?
Alencar & Schmitz [2005, p.48] comentam A despeito dos enormes benefcios
que a gerncia de risco pode trazer em termos de um aumento significativo no nmero
de projetos que terminam com sucesso, muitas organizaes tm dificuldade em
adotar a sua prtica.
13
Muitas organizaes desenvolvem, ao longo do tempo, uma cultura na qual

aqueles que ousam apontar as incertezas a que todo projeto est, naturalmente,
exposto so taxados de pessimistas ou derrotistas. Esse tipo de organizao tende a
valorizar os esforos dos heris de ltima hora, que trabalham ininterruptamente para
finalizar aquilo que deveria ter sido feito dentro do calendrio de atividades acordado
com o cliente.
Ao se negarem a reconhecer a contribuio que a anlise destas incertezas

podem trazer para a gerncia dos projetos que desenvolvem anualmente, estas
organizaes acabam condenando a atividade de anlise de risco ao ostracismo.
Em consequncia, as estimativas de custo, tempo e fluxo de caixa gerados por

seus gerentes de projetos dificilmente corresponde realidade. Os projetos que estes
gerentes executam esto, frequentemente, atrasados, criando um ambiente propcio
para o surgimento dos heris de ltima hora, que a organizao tanto valoriza.
Para se ter uma noo real do impacto que este tipo de cultura pode causar, a
figura abaixo demonstra uma correlao entre o risco e o custo no projeto.
Risco Custo
Custo para corrigir
Alto um evento de Risco
Probabilidade de
ocorrncia de Risco
Baixo
Inicio Encerramento
Ciclo de Vida do Projeto
Figura 3 Grfico de Impacto dos Riscos

Fonte:http://www.aemp.com.br/biblioteca_digital/PMI%20&%20ACAD%20EMPREND_2.pdf.
Acessado em 25/02/06.
Pode-se observar na Figura 3, que na fase inicial do projeto, existe uma alta
probabilidade de ocorrncia de risco; porm, o custo para a correo deste evento
inversamente proporcional sua probabilidade de ocorrncia. Na medida em que o
projeto se aproxima da fase de encerramento, esta inverso proporcional volta a
acontecer. Ou seja, existe uma baixa probabilidade de ocorrncia de risco, mas caso
este evento ocorra, o custo para a correo do mesmo elavado e pode comprometer
o projeto impacto na restrio tripla.
14
3.4 Metodologias Praticadas no Mercado
Atualmente, existem diversas metodologias que so utilizadas em

Gerenciamento de Projetos e em Governana de TI. Dentre estas, as mais conhecidas
e praticadas pelas organizaes so: PMI, MSF, CobiT, ITIL, CMM, ISO17799 etc.
PMI-RS Journal, Edio 9 [2005:2], atravs de um artigo desenvolvido por

Adilson Pize, afirma que: Um estudo de benchmarking realizado no Brasil em 2004,
com 73 organizaes dos mais diferentes setores, entre eles construo, consultoria,
tecnologia da informao, telecomunicaes, petrleo, gs e energia, demonstrou o
seguinte quadro:
Quadro 1 Nmero de Metodologias Utilizadas pelas Organizaes.
(1)
11% (4) 16% (1)
(2)
23% (3)
(3)
50% (2) (4)
Fonte: Adaptado de http://www.pmirs.org.br/PMI-RSJournal/PMI-

RSJournalNro09.pdf acessado em 21/05/06.
Como podemos observar pelo grfico acima, apenas 11% das organizaes
pesquisadas no possuem e no esto implantando metodologias para o
gerenciamento de seus projetos.
Este mesmo estudo detectou que os setores de tecnologia e telecomunicaes

so os mais bem estruturados em termos de metodologias em gerenciamento de
projetos.
3.4.1 Sobre Gerenciamento de Projetos
O Gerenciamento de Riscos sobre o prisma da metodologia do PMI [2004],

apresenta os seguintes processos:
15
- Planejamento do Gerenciamento de Riscos, deciso de como

abordar, planejar e executar as atividades de gerenciamento de riscos de um
priojeto;
- Identificao de Riscos, determinao dos riscos que podem afetar o

projeto e documentao de suas caractersticas;
- Anlise Qualitativa de Riscos, priorizao dos riscos para anlise ou

ao adicional subseqente atravs de avaliao e combinao de sua
probabilidade de ocorrncia e impacto;
- Anlise Quantitativa de Riscos, anlise numrica do efeito dos riscos

identificados nos objetivos gerais do projeto;
- Planejamento de Respostas a Riscos, desenvolvimento de opes e

aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do
projeto;
- Monitoramento e Controle de Riscos, acompanhamento dos riscos

identificados, monitoramento dos riscos residuais, identificao dos novos
riscos, execuo de planos de respostas a riscos e avaliao da sua eficcia
durante todo o ciclo de vida do projeto.
3.4.2 Sobre Governana de TI
O Gerenciamento de Riscos sobre o prisma da metodologia do CobiT

[2000c], apresenta o seguinte processo:
- Avaliao de Riscos, contendo os seus objetivos sobre o assunto,

conforme descrito no Anexo I, baseia-se em Fatores Crticos de Sucesso,
Indicadores Chaves de Objetivos e de Desempenho e um Modelo de
Maturidade para auxiliar na identificao de importantes fatores de deciso.
Para melhor compreenso, de uma forma geral, esses Fatores, Indicadores e

Modelos de Maturidade so aplicados em todos os Processos do CobiT e podem ser
genericamente explanados da seguinte forma:
Fatores Crticos de Sucesso, definem as mais importantes questes ou

aes para o gerenciamento alcanar controles sobre e dentro dos processos de TI.
Eles devem ser gerenciados orientados em guias de implementao e identificadas as
16
coisas mais importantes a serem feitas, estrategicamente, tecnicamente,

organizacionalmente e proceduralmente;
Indicadores Chaves de Objetivos definem mtricas que dizem ao

gerenciamento aps o fato se um processo de TI foi alcanado em seus requisitos
de negcios, geralmente expressados em termos de critrio de informao:
- Disponibilidade da informao necessria para suportar as

necessidades de negcio;
- Ausncia de riscos de integridade e confidencialidade;
- Eficincia de custos em processos e operaes;
- Confirmao de fidedignidade, eficcia e conformidade.
Indicadores Chaves de Desempenho definem mtricas para determinar o

quo bom esto as performances dos processos de TI em relao aos objetivos a
serem alcanados; so indicadores de pistas se um objetivo ser desejavelmente
alcanado ou no; e so bons indicadores de potencialidade, prticas e habilidades.
Modelos de Maturidade, em resumo:
- Referem-se aos requisitos de negcios e os aspectos permitidos em

diferentes nveis de maturidade;
- Escalas utilizadas em comparaes pragmticas;
- Escalas onde a diferena pode ser mensurvel de um modo fcil;
- So reconhecveis como um perfil de empresa relativa para

governana de TI, segurana e controle;
- Ajuda a definir as posies de Como e Para ser relativas

governaa de TI, segurana e controle de maturidade;
- Permitem, quando possvel, nveis discretos que criam pontos iniciais

que so difceis de cruzar;
- Se aplicam cada vez mais aos fatores crticos de sucesso;
- No so especficos indstria e nem sempre aplicveis, o tipo de

negcio define o que apropriado.
17
3.5 Comentrios Sobre Gerenciamento de Riscos (Apndice A)
Para melhor entendimento do documento de trabalho do projeto referenciado

no Apndice A, mais especificamente no Captulo 5 deste Apndice , faz-se
necessria a explanao sobre dois conceitos bsicos, porm fundamentais, em
gerenciamento de riscos, que a Probabilidade do Risco (chance de ocorrncia de um
risco) e o Impacto do Risco (determina o impacto que causar o risco em caso de
ocorrncia). Estes conceitos geram a Matriz de Severidade de Riscos (P x I),
classificando-os como altos, mdios, baixos ou indeterminados.
A partir desta matriz so sugeridas aes como: tratar preventivamente, tratar

com planos de contingncia ou monitorar.
O Rank classifica a Severidade de acordo com a avaliao tcnica e de

negcio, sendo nmero 1 o mais crtico.
Os riscos esto agrupados em duas categorias: Riscos para o Negcio e

Riscos para o Projeto; e no Rank, do maior para o menor risco. Abaixo destacado o
principal risco para este ambiente, o qual est categorizado nos Riscos para o
Projeto:
Quadro 2
Plano de
Rank NR Tipo Risco Imp Prob Sev Estratgia Plano de Mitigao Observao
Contingncia
Negociao junto
ao CLIENTE para
aumentar a
prioridade deste
projeto
(responsvel pela
Atraso no projeto
negociao: GP
em decorrncia da
FORNECEDOR e
Indisponibilidade
GP CLIENTE).
das equipes de
desenvolvimento
Planejamento
para definio dos No h
detalhado das
cenrios de Conteno No observa-
1 1 E A A A necessidades de
homologao e na do Risco Aplicvel. es
recursos das
elaborao em adicionais.
reas de
conjunto do plano
desenvolvimento.
detalhado do
projeto, anlise de
Negociao junto
impacto e plano de
a rea de
Fallback.
desenvolvimento
dos recursos
necessrios para
as atividades
(responsvel GP
CLIENTE).
Fonte: O autor
Este risco impactaria diretamente no cronograma, ou seja, em atraso dos

deliverables previstos no escopo do projeto. Consequentemente resultaria em
penalidade financeira por este atraso, afetando completamente a restrio tripla.
18
4 AS EMPRESAS
4.1 Cliente
4.1.1 Perfil da Empresa
A Empresa est completando 40 anos e seu quadro de funcionrios conta com

cerca de quatorze mil empregados entre funcionrios e terceiros.
A empresa oferece solues completas de telecomunicaes a todo mercado

brasileiro, incluindo telefonia local, longa distncia nacional e internacional,
transmisso de dados, televiso e internet, alm de assegurar atendimento em
qualquer ponto do territrio nacional atravs de solues via satlites.
Seja em telefonia, dados ou internet, os servios da Empresa oferecem um mix ideal
entre tecnologia, qualidade, segurana e rentabilidade, tanto para o mercado
corporativo quanto para o residencial e tambm para o setor pblico.
A Empresa possui a maior rede de telecomunicaes do Brasil, reunindo fibras

pticas, cabos submarinos e satlites e profissionais altamente qualificados.
Dados
A Empresa fornece a mais completa soluo em comunicao digital (dados,
voz e vdeo) para empresas, com diferentes velocidades e abrangncia nacional,
atingindo at mesmo reas onde no se encontram redes convencionais.
Redes Multiservios
Para manter interconectadas as unidades de negcios, fornecedores e

parceiros espalhados pelo Brasil e pelo mundo, a Empresa disponibiliza servios
corporativos que utilizam as mais avanadas tecnologias do setor (X25, Frame Relay,
ATM e IP).
Internet
Do simples acesso at a formao de provedores de servios de internet (ISP),
a Empresa oferece o maior Backbone da Amrica Latina para que as empresas
naveguem pela Internet em Banda Larga. As solues da Empresa suportam diversas
tecnologias internet - protocolo e multiprotocolo internet (IP e MPLS), por exemplo.
19
Valor Adicionado
Empresa oferece para o mercado corporativo solues completas de

hospedagem de software e hardware, proteo de sistemas - atravs de elaborados
processos de segurana -, realizao de reunies e treinamentos distncia,
comrcio eletrnico e muito mais.
Televiso & Rdio
Atravs de sua estrutura de centros de TV espalhados pelas principais cidades

brasileiras, a Empresa disponibiliza para empresas servios de transmisso de sinais
digitais e analgicos de Rdio e TV, em mbito nacional, utilizando a mais alta
tecnologia terrestre e via satlite.
Solues de Relacionamento
A Empresa oferece solues completas para empresas, com a tecnologia da

Rede Inteligente e Atendimento Automtico: conexo rede 100% digital da Empresa;
formao de rede privativa virtual de voz; realizao de videoconferncias;
disponibilidade de canais de comunicao com o mercado e terceirizao do
atendimento.
Telefonia Local
Ao mercado corporativo, a Empresa oferece um servio completo de

telecomunicaes, conectando o(s) PABX(s) da(s) empresa(s) diretamente s suas
modernas centrais, 100% digitais. A Telefonia Local da Empresa para o mercado
corporativo est disponvel em todo Pas, sendo uma opo para as empresas que
desejam maior qualidade, confiabilidade e preo para o servio de telefonia fixa.
Telefonia de Longa Distncia
Ligaes interurbanas, nacionais e internacionais, planos de tarifas

corporativos e residenciais de acordo com o perfil de cada cliente e cartes ps-pagos
e pr-pagos. O cliente residencial ou corporativo da Empresa conta com todas essas
solues, podendo falar com o Brasil e o mundo com mais qualidade e pagando
menos.
20
Internet Residencial
Para o mercado residencial, a Empresa oferece a internet gratuita da Empresa,

que garante qualidade de conexo e servios, atravs de chamada telefnica local.
Entre os benefcios oferecidos esto a conexo rpida, sem sinal de ocupado; suporte
24 horas; duas contas de e-mail por usurio, com at 30 Mb de armazenamento cada
uma; antivrus; anti-spam; e links para os melhores sites disponveis na Internet.
Satlites
Os satlites da Empresa podem receber e transmitir sinais de televiso, rdio,

telefone, internet e dados para aplicaes de entretenimento, telemedicina,
teleducao, negcios, servios essenciais para as comunidades distantes e
atividades militares. Hoje, por exemplo, mais de 15 milhes de residncias brasileiras
assistem TV via satlite Empresa, de forma gratuita. Como servios complementares
para criao de redes ou emissoras independentes de TV e outros grupos de
comunicao, a Empresa oferece as mais variadas opes de contratao, larguras de
banda e tecnologias.
4.1.2 Estrutura Organizacional do CLIENTE
Figura 4 Organizao matricial fraca

Fonte: PMI [2004:30]
21
Apesar de estar em fase de restruturao devido a sua recente compra pela

atual Empresa Controladora , o CLIENTE ainda pode ser considerado como uma
organizao matricial fraca. Entretanto, para o Projeto de Transio dos Ambientes
Crticos para o CT do FORNECEDOR, foi montada uma estrutura mais projetizada
para facilitar o gerenciamento deste projeto e da integrao entre o CLIENTE e o
FORNECEDOR.
4.2 FORNECEDOR
4.2.1 Perfil da Empresa
Incorporada em 1911, somente em 1924, o FORNECEDOR veio a ter o atual

nome conhecido no mercado. Atualmente, o FORNECEDOR a maior empresa do
mundo em tecnologia da informao. Em 2004, foi considerada a nona maior
corporao dos Estados Unidos e no final de 2003, o FORNECEDOR possua mais de
319.000 funcionrios atendendo os seus clientes em 160 pases ao redor do mundo.
O FORNECEDOR chegou no Brasil em 1917. Montou sua primeira fbrica, em

Benfica (RJ), em 1939 e, posteriormente, em Sumar (SP), em 1971. Hoje, a Empresa
no Brasil, possui cerca de 15.000 funcionrios.
Principais linhas de Negcio:
- Servios de Consultoria de Negcios
- Servios de Tecnologia Integrada
- Servios de Outsourcing Estratgico
- Servios de Gerenciamento de Aplicao
- Servios de Hospedagem de Negcios Eletrnicos (e-Business Hosting)
- Venda e Manuteno de Hardware Proprietrio

22
4.2.2 Estrutura Organizacional do FORNECEDOR
Figura 5 Organizao composta

Fonte: PMBOK [2004:31]
O FORNECEDOR sempre trabalhou de forma composta e projetizada no que

tange aos clientes da rea de Outsourcing Estratgico. Desta forma, possvel maior
sinergia entre as equipes e gerentes de transio e ongoing durante a fase de
transio de ambientes crticos para o CT, bem como a posterior manuteno e
garantia da qualidade de continuidade do que foi efetivamente migrado.
4.3 Contrato de outsourcing do CLIENTE com o FORNECEDOR
Visando reduo dos custos com TI, em abril de 2003, o CLIENTE fechou
com o FORNECEDOR Brasil, um contrato de outsourcing com durao de dez anos,
com compra de ativo servidores, storages, equipamentos de rede etc. Em junho de
2003, todos os funcionrios de TI do CLIENTE foram submetidos a uma entrevista
com o FORNECEDOR, sendo que parte deles no foi aproveitada nem pelo
CLIENTE nem pelo FORNECEDOR , parte foi terceirizada e apenas uma pequena
parte foi admitida pelo FORNECEDOR obviamente funcionrios-chave que foram
apontados pelo CLIENTE, para a plena continuao dos servios de TI, devido
senioridade e profundo conhecimento do ambiente.
23
4.3.1 Resumo do Escopo do Contrato
- Transferncia de ativos
- Atualizao do parque tecnolgico
- Servios de Data Center
- Servios Mainframe
- Gerncia de Servidor Mainframe
- Gerncia de Storage Mainframe
- Gerncia de Banco de Dados Mainframe
- Gerncia de Infra-Estrutura de Data Center
- Especificao das Mtricas de Nveis Base (volumetria)
- Mtricas de Nveis Base (volumetria)
- Especificao das Mtricas de Nveis de Servios
- Mtricas de Nveis de Servios
- Servios Midirange
- Gerncia do Servidor Midirange
- Gerncia de Storage Mainframe
- Gerncia de Banco de Dados Midirange
- Gerncia de Infra-Estrutura de Data Center
- Servio de Manuteno de Hardware
- Manuteno de Hardware de Servidores
- Manuteno de Hardware de Storage
- Manuteno de Hardware de Equipamentos de Rede
- Servios de Gerncia de Rede

24
- Controle do Gerenciamento de Sistemas (SMC)
- Gerncia de Problemas
- Gerncia de Situaes Crticas
- Gerncia de Mudanas
- Gerncia de Capacidade e Performance
- Gerncia de Configurao
- Gerncia de Segurana
- Gerncia de Nveis de Servios
- Suporte de Infra-Estrutura de TI a Demandas Adicionais
- Interao com o Help-Desk do CLIENTE
- Gerncia de Chamados
- Administrao de Usurios
- Matrizes de Criticidade de Sistemas e Severidades
- Matriz de Criticidade de Sistemas
- Matriz de Severidades
- Matriz de Escalonamento de Problemas
- Projeto Migrao dos Servidores (Ambientes Crticos)
- Projeto Absoro de Produes
No final de 2004, o CLIENTE j controlada por uma empresa multinacional

negociava um aditivo de contrato com reduo de escopo, visando insourcing
(retomada) de algumas reas.
25
4.3.2 Estrutura Hierrquica do FORNECEDOR para o CLIENTE
Project
Project Executive
Executive
Delivery
Delivery Project
Project
Executive
Executive
Project
Project Managers
Managers
Production
Production Manager
Manager Human
Human Resource
Resource Support
Support Manager
Manager
Manager
Manager Field
Field Service
Service
Coordinator
Coordinator
Support
Support Coordinator
Coordinator
Unix
Unix Team
Team Leader
Leader Paulo
Paulo Toledo
Toledo Oracle
Oracle Team
Team Leader
Leader
Windows
Windows Team
Team Leader
Leader
Notes
Notes Team
Team Leader
Leader Mainframe
Mainframe Team
Team Leader
Leader
Figura 6 Organograma de On-Going

Fonte: O Autor
Descrio dos Cargos apresentados na Figura 5 (estrutura hierrquica do

FORNECEDOR dentro do CLIENTE) :
Project Executive (PE) Posto maior da estratura hierrquica do

FORNECEDOR dentro do CLIENTE. O PE o Executivo responsvel pela parte
financeira do contrato.
Delivery Project Executive (DPE) Executivo responsvel pela entrega do

produto ao CLIENTE, garantindo as mtricas e SLAs de acordo com o contrato de
outsourcing vigente.
Human Resource Manager Gerente de recursos humanos dentro do

CLIENTE. Os usurios do FORNECEDOR podem ter um gerente de recursos
humanos diferente do seu gerente funcional ou esses papis podem ser acumulados
numa nica pessoa.
Project Managers Gerentes de projetos responsveis pelo gerenciamento

dos projetos internos demandados pelo CLIENTE. Respondem diretamento ao DPE e
intereragem com os gerentes funcionais para alocao de recursos.
Production Manager Gerente responsvel pela produo do cliente que foi

absorvida pelo FORNECEDOR, garantindo que todos os processos sejam controlados
26
e documentados. Normalmente, o responsvel pelo controle de acesso fsico ao

Data Center do CLIENTE.
Support Manager Gerente responsvel pela reas de suporte tcnico e

servio de campo. Responsvel tambm pela confeco do Book (documento
entregue mensalmente ao CLIENTE com todas as mtricas, avaliaes e dados
estatsticos para o devido acompanhamento do que foi e do que deve ser melhorado;
alm das reflexes financeiras associadas a essas mudanas).
Field Service Coordinator Responsvel por coordenar o atendimento aos

usurios (incluindo os VIPs) e pela atualizao tecnolgica do parque computacional
do CLIENTE.
Support Coordinator Responsvel por coordenar as diversas equipes de

suportes (nvel 3: servidores e situaes crticas). Garantir que todos os processos de
mudanas sejam documentados e aprovados (atravs de gerncia de mudanas)
antes de serem executados e que todos os chamados sejam atendidos de forma a
manter o SLA acordado.
Team Leader Lder do seu time de suporte. Responsvel pelo planejamento

e solues tcnicas para melhoria do ambiente, e solues corretivas, em casos de
situaes crticas. Acompanhamento e orientao nas atividades desempenhadas por
sua equipe.
27
5 O PROJETO DE TRANSIO
5.1 Compreenso do Ambiente do Projeto
Em maio de 2005, foi emitido e assinado um apndice do termo aditivo ao

contrato de prestao de servios com o CLIENTE celebrado em maro de 2003
que trata especificamente do Projeto de Movimentao dos Servidores para o CT do
FORNECEDOR; sendo este o objeto de estudo deste trabalho. Por se tratar de um
projeto complexo e grandioso, e para melhor aproveitamento do que ser
estudado, a idia realizar o detalhamento de apenas 1 dos 26 ambientes
envolvidos, dando foco especialmente ao gerenciamento de riscos. O ambiente
alvo desse detalhamento para o referido estudo ser o TELACORE.
5.2 Estrutura Hierrquica do FORNECEDOR para o Projeto de Transio
Project
Project Executive
Executive
Delivery
Delivery Project
Project
Executive
Executive
Transition
Transition Manager
Manager Production
Production Manager
Manager
Project
Project Managers
Managers Technical
Technical Manager
Manager PMO
PMO && QA
QA Support
Support Manager
Manager
Unix
Unix Solution
Solution Architect
Architect Paulo
Paulo Toledo
Toledo Logistic
Logistic Support
Support
Intel
Intel Solution
Solution Architect
Architect
Backup
Backup Solution
Solution
Architect
Architect
Figura 7 Organograma de Transio

Fonte: O Autor
Descrio dos Cargos apresentados na Figura 6:
Transition Manager Gerente de projeto responsvel pelo projeto como todo.

Atua em nvel executivo e operacional, se relacionando com o CLIENTE, com o DPE
da conta e com a gerncia do CT (na qual receber e ser responsvel pela
manuteno dos ambientes migrados).
28
Project Managers Gerentes de projetos exclusivos para o gerenciamento

dos ambientes a serem migrados. Cada ambiente pode ser considerado como um
projeto.
PMO & QA Responsvel por auxiliar os gerentes de projetos. Compartilha a

execuo das tarefas de planejamento e acompanhamento.
Logistic Support Responsvel pelo suporte logstico de todos os projetos de

migrao. Atua diretamento com os GPs e com o Gerente Tcnico.
Technical Manager Responsvel pelo reviso tcnica das solues dadas

pelos Arquitetos de Soluo; auxlio na resoluo de pendncias tcnicas e
gerenciamento de alocao dos recursos tcnicos para os GPs, de forma a no
impactar as atividades de projetos que estejam acontecendo paralelamente.
Solution Architect Responsvel tcnico pelo planejamento e desenho da

soluo a ser adotada para a migrao do ambiente, devendo prever os riscos
tcnicos e suas mitigaes, elaborar a estratgia de migrao (contemplando
contingncia), especificar os equipamentos a serem comprados e confeccionar
documentos tcnicos (detalhamento tcnico das atividades, plano de movimentao,
plano de comuniacao) para auxiliar a migrao e confeco/reviso de SOW junto
ao GP.
5.3 Ambientes Crticos
Relao dos ambientes que fazem parte do Projeto de Transio:
Tabela 1 Ambientes Contemplados na Transio
ILR1 CACTRE SITEF

BILT0 SIEBEL PRD COPROG
CORPORATIVO SP INTEL (SD2000 e SVA
CDS SIEBEL CCE
HMG)
UXCDSDES SIEBEL CCP TELCO
BILLING DW TELACORE
EAI SAS BANCO DE RELACIONAMENTO (PGV)
EAITST UXBILSUN SAD
DBM SEF, UXCACDES, SHERIFF (Fraudes) e SEF HMG FRAUDVIEW
CACS S80, SP e INTEL GSA
Fonte: O Autor
Para cada um dos 26 ambientes, existe um documento de trabalho (mais

conhecido como SOW, que semelhante ao Plano de Projeto feito na fase de
Planejamento) padronizada, porm adaptada para a realidade de cada ambiente. Para
29
a maioria dos ambientes, este documento foi elaborado contendo a seguinte

abordagem:
Captulo 1 Informaes sobre o Documento
Fonte do Documento
Propsito
Histrico das Atualizaes
Aprovaes
Distribuio
Captulo 2 Identificao, Objetivo e Premissas do Projeto
Identificao do Projeto
Gerente FORNECEDOR do Projeto
Gerente CLIENTE do Projeto
Objetivo
Premissas
Estrutura de Deciso do Projeto
Captulo 3 Soluo
Descrio da Soluo
Arquitetura do Ambiente Atual
Arquitetura do Ambiente Final
Mecanismos de Comunicao Intersistemas
Componentes Liberados aps a Movimentao dos Ambientes
Soluo de Backup para o Ambiente
Abordagem
Fases da Movimentao dos Servidores
Estratgia de Cpia do Ambiente Produtivo para Bolha

Homolog.
Estratgia de Cpia do Ambiente Produtivo para Bolha Pr-

Cutover
Estratgia de Cutover
30
Contingncia nos Casos de Desastre
Estratgia para Recuperao de Processamento Retido
Etapas de Implementao da Soluo
Elaborao e Validao do Planejamento Detalhado de

Movimentao dos Servidores
Contruo do Ambiente Bolha
Instalaes e Configuraes no Ambiente Bolha
Cpia de Dados no Ambiente Biolha para Homologao
Transporte dos Equipamentos
Homologao Final e Migrao da Produo (Cutover)
Fallback Recuperao do Ambiente de Produo Original
Captulo 4 Planejamento
Datas-objetivo de Incio e Trmino do Projeto
Macro-Cronograma
Observaes Complementares
Captulo 5 Gerenciamento de Risco
Introduo sobre os Riscos
Resumo da Estratgia de Movimentao
Legenda e Nomenclatura
Critrio para Avaliao da Severidade
Estratgia para Tratamento de Riscos
Riscos para o Negcio
Riscos para o Projeto
Aps ter dado incio ao projeto, o CLIENTE cancelou o envio dos ambientes
SAD, SITEF e FRAUDVIEW, permancendo, portanto, 23 ambientes a serem migrados.
O documento de trabalho do projeto TELACORE ambiente objeto do estudo

de caso descrito no APNDICE A, explora detalhadamente a estrutura acima
mencionada.
31
6 CONCLUSES E PROPOSIES
Aps anlise realizada neste estudo de caso, respeitando o contexto em que o

projeto se encontra inserido, conclui-se que o gerenciamento de riscos foi bem
aplicado neste projeto cuja metodologia utilizada foi a do PMI, tendo em vista que o
projeto foi encerrado no prazo, dentro dos custos planejados, respeitando o escopo e
a qualidade dos deliverables.
Baseado na metodologia do PMI em Gerenciamento de Projetos ,

utilizaram-se todos os processos nesta rea de conhecimento, porm nem todas as
ferramentas; tendo em vista um grande aproveitamento das lies aprendidas de
projetos mais complexos anteriormente realizados. Dentre as ferramentas que no
foram utilizadas, pode-se destacar duas tcnicas: Delphi (utilizada na Identificao de
Riscos), devido a pouca quantidade de especialistas envolvidos e poucas divergncias
de opinies; e a rvore de Deciso (utilizada na Anlise Quantitativa de Riscos e
Tcnicas de Modelagem).
Baseado na metodologia do CobiT em Governana de TI , pode-se dizer

que este projeto utilizou quase todos os tpicos apresentados nos Fatores Crticos de
Sucesso e nos Indicadores Chaves de Objetivos. Porm, fez utilizao parcial dos
Indicadores Chaves de Desempenho. Quanto Maturidade, considero que o projeto
tenha alcanado o nvel 5 (Otimizado), mas em funo da aplicao da Metodologia do
PMI.
notrio, porm convm salientar que o gerenciamento de riscos quando bem

realizado fator crtico e decisivo para a obteno do sucesso de qualquer projeto.
Esse trabalho de concluso objetivou no somente a anlise de riscos do

estudo de caso de um determinado projeto realizado com sucesso, atravs da
aplicao da metodologia do PMI para gerenciamento de projetos; mas despertar e
ressaltar, para as organizaes, suas gerncias e demais stakeholders, especialmente
na rea de TI, a importncia do conhecimento mesmo que bsico da utilizao de,
pelo menos, uma metodologia cujo gerenciamento de riscos seja bem aplicado. No
discriminando e sim dando valor importncia das demais reas de conhecimento
dessa metodologia, mas ao meu ver, o Gerenciamento de Riscos uma das mais
difceis e importantes reas de conhecimento, pelo simples fato de lidar com as
incertezas; apesar de todas as tcnicas e ferramentas atualmente disponveis para
identificar e minimizar os riscos.
32
Tal a riqueza do assunto abordado, recomenda-se o aprofundamento de alguns

temas em futuras pesquisas, como por exemplo:
- Outras Metodologias que auxiliem Projetos de TI, como MSF (Microsoft

Solution Framework), CMM (Capability Maturity Model), e ITIL (Information
Technology Infrastructure Library);
- Gerenciamento de Mltiplos Projetos;
- Maturidade em Gerenciamento de Projetos.
Um estudo mais detido de livros como Risk Management Tricks of the Trade
de Rita Mulcahy, Project Managers Spotlight on Risk Managament de Kim
Heldman e Risk Management Guide for Information Technology Systems de Gary
Stoneburne, Alice Goguen e Alexis Feringa, pode ser de grande auxlio para
pesquisadores de Gerenciamento de Riscos e Gerenciamento de Riscos em TI, tendo
em vista seu forte contedo tcnico.
33
REFERNCIAS BIBLIOGRFICAS
ALENCAR, Antonio Juarez; SCHMITZ, Eber Assis. Anlise de Risco em Gerncia de

Projetos. So Paulo: Brasport, 2005. p.48.
PMI. PMBOK: Um guia do Conjunto de Conhecimentos em Gerenciamento de

Projetos. 3.ed. Pennsylvania: Project Management Institute, 2004. ISBN: 1-
930699-50-6 (CD-ROM). Cap. 1, p. 8 11, 29 31, Cap.11, p. 237.
JORDAN, Ernie; SILCOCK Luke. Beating IT Risks. England: John Wiley & Sons Ltd,
2005. Chap.3, p.49.
POSSI, Marcus et al. Capacitao em Gerenciamento de Projetos: Guia de

Referncia Didtica. Rio de Janeiro: Brasport, 2004. Cap.1, p.9, Cap. 3, p. 35
37.
REFERNCIAS ELETRNICAS
BELLOQUIM, tila. Riscos de Projetos. O que fazer com eles? Disponvel em

http://www.gnosisbr.com.br/artigos/AB0009.html. Acessado em 25/02/06.
GALVES, Jos Wanderlei Gava. Planos de Contingncia em TI. Disponvel em

http://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/07/
28/2003_07_28_0002.2xt/-template_interna. Acessado em 25/02/06.
PEREZ, Cristina Oliveira. Gerenciando Projetos de TI. Disponvel em

http://www.ietec.com.br/ietec/techoje/materias_tec/tecnologiadainformacao/tecn
ologiadainformacao/dtml_materia?id=http://www.ietec.com.br/ietec/techoje/tech
oje/tecnologiadainformacao/2003/10/10/2003_10_10_0002.2xt. Acessado em
04/06/06.
PIZE, Adilson. Metodologias de Gerenciamento de Projetos: Tornando o

Gerenciamento de Projetos Efetivo na Organizao. Disponvel em
http://www.pmirs.org.br/PMI-RSJournal/PMI-RSJournalNro09.pdf. Acessado
em 21/05/06.
34
RIBEIRO, Marco Antnio Kappel. Palestra do PMI-RS. Disponvel em

http://www.aemp.com.br/biblioteca_digital/PMI%20&%20ACAD%20EMPREND
_2.pdf. Acessado em 25/02/06.
WIERMANN, Gustavo Garcia. Riscos em Projetos: aprenda a conviver com eles.

Disponvel em
http://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/
2004/01/21/2004_01_21_0002.2xt/-template_interna. Acessado em 25/02/06.
Projeto Movimentao do
Ambiente TELACORE para o CT
Especificao do Projeto
APNDICE A
Gerente do Projeto: Charles Leal

Departamento: Strategic Outsourcing
Telefone: +55 21 99XX -9999
Internet: leal@fornecedor.com
Verso: 1.0
ltima Reviso em: 29/jun/2005
Impresso em: 29/jun/2005
1
CAPTULO 1 INFORMAES SOBRE O DOCUMENTO
Fonte do Documento
Este documento mantido como um documento online. Contate o autor para ter acesso
ltima verso atualizada.
Histrico das Atualizaes
# Verso Data da Verso Contedo Atualizado

1.0 29/06/2005 Criao do documento
Aprovaes
Data
Nome Funo E-Mail Telefone
Aprovao
Arnaldo Gerente de Projeto
alrnaldom@cliente.com.br (21) 20XX 2020
Machado CLIENTE
Dbora Gerente de Projeto
debora@cliente.com.br (21) 20XX 2021
Cardoso CLIENTE
Joaquim Gerente de Projeto
jcruz@fornecedor.com (21) 88XX 8888
Cruz FORNECEDOR
Mrio Gerente Tcnico
gomes@fornecedor.com (21) 78XX 1414
Gomes FORNECEDOR
Charles Gerente de Projeto
leal@fornecedor.com (21) 99XX 9999
Leal FORNECEDOR
Distribuio
Este documento foi distribudo para todas as pessoas relacionadas abaixo.
Nome Funo E-Mail Telefone
Gerente de Projeto
Arnaldo Machado alrnaldom@cliente.com.br (21) 20XX 2020
CLIENTE
Gerente de Projeto
Dbora Cardoso debora@cliente.com.br (21) 20XX 2021
CLIENTE
Gerente de Projeto
Joaquim Cruz jcruz@fornecedor.com (21) 88XX 8888
FORNECEDOR
Gerente Tcnico
Mrio Gomes gomes@fornecedor.com (21) 78XX 1414
FORNECEDOR
Gerente de Projeto
Charles Leal joaop@fornecedor.com (21) 99XX 9999
FORNECEDOR
Gerende de Produo
Lima Duarte duarte@fornecedor.com (19) 87XX 1234
FORNECEDOR
Arquiteto de Soluo
Paulo Toledo toledo@fornecedor.com (21) 99XX 2299
FORNECEDOR
PMO & QA
Rmulo Arantes arantes@fornecedor.com (21) 22XX 4455
FORNECEDOR
Executivo de Delivery
Moacyr Franco mfranco@fornecedor.com (21) 87XX 5665
FORNECEDOR
2
Gerente de Suporte
Livia Santana livia@fornecedor.com (21) 31XX 3334
FORNECEDOR
Especialista de Sistemas
Gisele Castro gisele@fornecedor.com (19) 23XX 4567
FORNECEDOR
Laerte Lima DBA FORNECEDOR laerte@fornecedor.com (19) 77XX 6534

3
CAPTULO 2 IDENTIFICAO, OBJETIVO E PREMISSAS DO PROJETO
Identificao do Projeto
Movimentao do Ambiente TELACORE Produo para o CT
Gerente FORNECEDOR do Projeto

Charles Leal
Gerente CLIENTE do Projeto

Dbora Cardoso
Objetivo
O documento tem como objetivo:
Confirmar o entendimento do Plano do projeto pelo time do projeto;

Fornecer informao suficiente sobre a soluo e a abordagem do projeto, para
que Sponsor e time do projeto concordem em avanar para a fase de execuo;
Proporcionar uma estrutura bsica de trabalho detalhado para movimentao do ambiente

TELACORE para o CT.
Premissas
O projeto assume como premissa que os seguintes pr-requisitos de Hardware devero ser
disponibilizados pelo CLIENTE:
Servidor de Apoio (Bolha):
Modelo: IBM xSeries 225 8647-5BX

CPUs: 2 x 2.8 GHz
Memria: 1 GB RAM
Discos internos: 2 x 36 GB (RAID 1)
1 Placa Ethernet 10/100 Mbps
Storage IBM modelo LTO 3584 (pelo FORNECEDOR)

Os outages devero ser negociados junto s aras usurias.
Presena dos Key-User para testes das aplicaes.
Disponibilidade dos fornecedores / desenvolvedores / equipe de suporte das
aplicaes na instalao dos servidores do Ambiente de apoio bolha e em caso de
problemas. A rea usuria ir definir a categoria do suporte do fornecedor /
desenvolvedor no final de semana de cada onda: onsite ou standby.
Contrato de manuteno de hardware para todos os servidores e informaes
atualizadas dos contatos de acionamentos, disponibilizados aos tcnicos de standby;
4
CAPTULO 3 SOLUO
A soluo tcnica, a abordagem e as etapas de implementao apresentadas, foram revisadas

e ajustadas na fase de Avaliao do Plano Inicial de Movimentao, conforme definido no item
19.A.1.1.7 do Anexo 19A deste Aditivo do Contrato.
Descrio da Soluo
I.Arquitetura do Ambiente Atual
Soluo de Processamento :
o Hardware:
CPUs: 2 x 2.8 GHz
Memria: 1 GB RAM
o Software :
Sistema Operacional: Windows 2000 Server;
Aplicaes: DBTools Software, Jacada Integrator 4.0, Java 2 Runtime
Environment, Java 2 SDK Standard Edition v1.3.1_10, Orsus Uno, Microsoft
Windows Journal Viewer, MySQL Connector/ODBC 3.51, MySQL Server and
Clients 4.0.18, WebEx
Soluo de Backup:
Hardware: rob IBM LTO 2 3584 (Client via Rede)
Software: TSM Client
Soluo de Storage:
Hardware: No aplicvel
Software: No aplicvel
Soluo de Scheduler:
II.Arquitetura do Ambiente Final
Soluo de Processamento :
o Hardware:
CPUs: 2 x 2.8 GHz
Memria: 1 GB RAM
o Software :
Soluo de Backup:
Hardware: rob IBM LTO 2 3584 (Client via Rede)
Software: TSM Client
Soluo de Storage:
Hardware: No aplicvel
5
Soluo de Scheduler:
III.Mecanismo de Comunicao Intersistemas
O TELACORE faz interao com o Arbor atravs de procedure e interage tambm com vrios
outros sistemas de fraude que eram utilizados isoladamente.
IV.Componentes Liberados aps a Movimentao dos Ambientes
No sero liberados componentes aps a movimentao dos ambientes.
V.Soluo de Backup para o Ambiente TELACORE
No ocorrer mudana na soluo de Backup atual, pois o mesmo j foi alterado para a
soluo TSM. O ambiente atual possui um client TSM realizando backup atravs de uma rede
FAST Ethernet 100 Mbs armazenando os dados no Rob IBM LTO 2 3584, instalado no site do
CLIENTE. A mesma soluo ser aplicada na soluo final, utilizando-se do Rob IBM LTO 2
3584 instalado no datacenter em Hortolndia CT.
a) Recuperao e Converso de Backup Histrico
No ocorrero mudanas na poltica de backup atual, que consiste no armazenamento

dos drives atualmente definidos no Windows (C: e D:) com reteno de 60 dias. Os
dados atualmente armazenados em tape LTO 2, sero duplicados e os cartuchos
correspondentes sero enviados junto com os servidores para o datacenter em
Hortolndia CT. A cpia transportada ser ento importada no TSM existente no
datacenter em Hortolndia CT, ficando disponvel em caso de necessidade de
restore.
b) Recuperao de Backup Dirio
O backup dirio deste servidor realizado via TSM tape LTO 2, utilizando-se de link
fast ethernet. Havendo necessidade de restore (anterior a data da movimentao), o
mesmo ser feito via WAN, que foi dimensionada para comportar esta transferncia (2
links 155 mbps).
VI.Configuraes de Storage
No h soluo especfica de storage para este ambiente.

6
Abordagem
A estratgia adotada ser instalar o ambiente de apoio - bolha, fornecido pela CLIENTE, no
CT, com a mesma configurao do ambiente em produo do site do CLIENTE no RJ. O
sistema TELACORE ser instalado, pelo fornecedor da aplicao, neste ambiente de apoio -
bolha e aps efetuar os testes de homologao deste novo ambiente, o mesmo ser
considerado um servidor produtivo paralelo. Durante um perodo de 7 dias, o CLIENTE
juntamente com o fornecedor da aplicao estar configurando as 25 estaes para poderem
acessar os 2 servidores produtivos. Em seguida o antigo servidor instalado no CLIENTE ser
desativado, permanecendo apenas o novo servidor produtivo no CT.
A estratgia de movimentao est baseada em fases, conforme apresentado abaixo. Alm

disso, est apresentado o detalhamento das estratgias particulares para o ambiente
TELACORE : cpia do ambiente produtivo - homologao, cpia do ambiente produtivo - pr-
cutover, cutover e contingncia em casos de desastre.
1. Fases da Movimentao de Servidores
Planejamento Detalhado da Movimentao dos Servidores

Project Charter Fase 3.2 elaborao e validao do planejamento detalhado da
homologao , da movimentao hora-a-hora, da comunicao hora-a-hora
Preparao do Ambiente Atual

Project Charter Fase 7 - Configurao do ambiente atual para viabilizao da
movimentao de servidores.
Construo da infra-estrutura do Ambiente de apoio Bolha

Project Charter Fase 8 - Construo dos ambientes de apoio (Bolhas) do ambiente
atual para viabilizao da movimentao de servidores.
Homologao do Ambiente de apoio Bolha

Project Charter Fase 9 Homologao do novo ambiente.
Transporte dos equipamentos

Project Charter Fase 10 Transporte dos equipamentos entre sites.
Homologao da Migrao
Project Charter Fase 11 Homologao do novo ambiente (mudana de datacenter).
Migrao da Produo para o datacenter do FORNECEDOR em

Hortolndia CT
Project Charter Fase 12 Migrao da produo para o datacenter do FORNECEDOR
em Hortolndia CT.
2. Estratgia de Cpia do Ambiente Produtivo para o Ambiente de apoio - Bolha

Homologao (adotada na Fase 8 - Project Charter).
Sero instalados, pelo cliente e/ou fornecedor, as aplicaes no servidor bolha;

ou se cabvel, sero copiados os dados via secure copy.
3. Estratgia de Cpia do Ambiente Produtivo para a o Ambiente de apoio - Bolha

Pr-cutover (adotada na Fase 10 - Project Charter)
7
Aps a Homologao do Ambiente de apoio Bolha, as 25 estaes de

trabalho deste ambiente tero suas configuraes alteradas para acessar,
paralelamente, o servidor produtivo e o servidor bolha (futuro servidor produtivo).
4. Estratgia de Cutover (adotada na Fase 12 - Project Charter)
A data da virada da produo para o datacenter em Hortolndia CT ser

definida junto rea usuria e dever ocorrer no ms 7 de transio. O planejamento
do cutover independente de qualquer outro sistema que estiver sendo migrado no
momento;
Haver homologao pr-cutover e testes de homologao aps a migrao,
conforme critrios definidos no documento Planejamento Detalhado de Homologao;
Deciso GO / NOGO para a virada da produo para o datacenter em
Hortolndia CT;
5. Contingncia nos casos de desastre (adotada na Fase 12 - Project Charter)
Os riscos envolvidos na estratgia de migrao deste ambiente esto restritos

aplicao;
Em caso de problemas durante o cutover, o ambiente produtivo voltar a
funcionar normalmente, religando o antigo servidor de produo (NTRJO066), no
DataCenter do CLIENTE.
6. Estratgia para Recuperao de Processamento Retido do TELACORE
No h ao a tomar com relao ao processamento de dados retidos

ocasionados por paradas no ambiente.
8
Etapas de Implementao da Soluo
Esta seo do documento apresenta o detalhamento das atividades a serem executadas para
movimentao do Ambiente TELACORE.
I.Elaborao e Validao dos Planejamentos Detalhados de Movimentao dos

Servidores Fase 3.2 Project Charter
Elaborar conjuntamente com as reas de Desenvolvimento de Sistemas e

usurios finais do CLIENTE e do FORNECEDOR, o Planejamento Detalhado de
Homologao para os ambientes a serem movimentados, contendo os tipos de
testes a serem efetuados, mtricas a serem utilizadas e cenrios de testes a serem
executados, para os ambientes de apoio (bolha) e/ou contingncia, aps a
movimentao.
Validar o Plano Detalhado de Homologao com os Gerentes Gerais e
Diretoria de TI do CLIENTE.
Elaborar e validar com as reas de Infra-estrutura de TI e Desenvolvimento de
Sistemas do CLIENTE, o Planejamento Hora-a-Hora de Movimentao
Elaborar e validar com as reas de Infra-estrutura de TI e Desenvolvimento de
Sistemas do CLIENTE, o Planejamento Hora-a-Hora de Comunicao
Realizar e documentar a Reviso Tcnica de Qualidade e apresentar para a
rea de Infra-estrutura de TI do CLIENTE.
II.Construo do Ambiente de apoio Bolha Fase 7 Project Charter
Montar o Ambiente de apoio Bolha no CT, ficando com a seguinte configurao :

o Hardware:
CPUs: 2 x 2.8 GHz
Memria: 1 GB RAM
o Software :
III.Instalaes e configuraes no Ambiente de apoio Bolha Fase 8 Project Charter
Ser utilizado, para o ambiente bolha, um servidor com a mesma configurao

do servidor de produo, com 2 discos de 36 GB em RAID1.
Ser instalado o sistema operacional e atualizaes de segurana no servidor

bolha.
Sero instalados, pelo cliente e/ou fornecedor, as aplicaes no servidor bolha.
IV.Cpia de dados no Ambiente de apoio bolha para homologao Fase 8 Project

Charter
Cpia dos dados atravs do secure copy (se necessrio).
V.Testes de homologao do Ambiente de apoio Bolha Fase 9 Project Charter

9
Homologao do novo ambiente segundo o plano de homologao detalhado;

Go/NoGo. Caso haja NOGO o ambiente atual de produo do TELACORE ser
mantido.
VI.Cpia de dados no Ambiente de apoio bolha para cutover Fase 10 Project Charter
Cpia dos dados via WAN atravs do secure copy (se necessrio).
VII.Homologao final e migrao da produo (cutover) Fases 11 e 12 Project Charter
Homologao do novo ambiente, instalado no datacenter em Hortolndia CT,

conforme detalhamento descrito no documento Planejamento Detalhado de
Homologao;
Para a ativao do ambiente de produo no datacenter em Hortolndia - CT,
ser realizada apenas a atualizao dos dados do servidor bolha para o servidor de
produo atravs do secure copy, via WAN;
Aps a atualizao dos dados, o servidor do Ambiente de apoio bolha ser
desligado no Site do CLIENTE no RJ e o servidor bolha passa a ser colocado na
condio de produo no datacenter em Hortolndia - CT.
GO / NOGO caso haja NOGO o ambiente atual de produo do
TELACORE ser mantido.
VIII.Fallback Recuperao do Ambiente de Produo Original Fase 11 Project Charter
Em caso de uma deciso de fallback, o Ambiente produtivo ser religado no Site do CLIENTE
no RJ, no sendo necessria nenhuma outra ao para restabelecer a disponibilidade do
ambiente.
10
CAPTULO 4 PLANEJAMENTO
O planejamento da Onda, as janelas tcnicas e os percentuais de concluso de cada

atividade/fase apresentados sero revistos e eventualmente ajustados na fase de Avaliao do
Plano Inicial de Movimentao, conforme itens 19A.1.1.7 - Compromissos para Concluso do
Plano Final de Movimentao dos Servidores e 19A.1.2.2 Fases do Projeto Fase 3.1,
partes integrantes do Anexo 19A deste Aditivo do Contrato.
Datas-objetivo de Incio e Trmino do Projeto
Incio At o incio do ms de junho Trmino At o final do ms de dezembro
Macro-Cronograma
ID Nome da taref a % Complete
1 Onda Corporativo RJ - Telacore 23%

4 Fase 2 Reviso / Elaborao dos Planos de Movimentao dos servidores 91%
20 Fase 3 Anlise e Validao dos Planos de Movimentao e Homologao com a rea de Desenvolvimento e Ne 0%
49 Fase 5 Levantamento e Planejamento das alteraes no mo do de operao da p rodu o CLIENTE e dos Forne 0%
65 Fase 6 Implementao da infra-estrutura 0%
70 Fase 7 Co nfigurao do ambiente atual para viabilizar movimentao de servidores 25%
75 Fase 8 Co nstruo do s ambientes de apoio (Bolhas) do ambien te atual para viabilizao d a mo vimentao 0%
93 Fase 9 Ho mologao do novo ambien te 0%
107 Fase 10 Transporte, instalao e ativao dos equipamentos para o CT 0%
128 Fase 11 Homologao do novo ambiente (mu dana de d atacenter) 0%
135 Fase 12 Entrad a em produo no CTIBM 0%
142 Fase 13 - Concluso 0%
Observaes Complementares
Durante a fase de detalhamento do planejamento da movimentao do ambiente TELACORE, os
seguintes documentos sero gerados e submetidos para anlise e aprovao do CLIENTE:
Cronograma MS-Project: descreve a relao de atividades a serem realizadas para a

movimentao, prazos de execuo e equipe tcnica;
Planejamento Detalhado de Homologao: descreve as mtricas, condies, ferramentas,

resultados esperados e equipe tcnica para execuo dos testes, bem como, prev a equipe
tcnica do CLIENTE envolvida para anlise dos resultados obtidos;
Planejamento Detalhado de Movimentao: descreve os equipamentos a serem migrados,

localizao, relao de atividades a serem realizadas para o transporte, ativao do ambiente
aps a movimentao e recuperao do movimento retido, com seus respectivos prazos de
execuo e equipe tcnica envolvida. Neste documento tambm esto descritas as atividades
detalhadas de fallback.
11
CAPTULO 5 GERENCIAMENTO DE RISCO
O Plano de Gerenciamento de Risco apresentado foi avaliado e ajustado, na fase de

Avaliao do Plano Inicial de Movimentao conforme itens 19A.1.1.7 - Compromissos para
Concluso do Plano Final de Movimentao dos Servidores e 19A.1.2.2 Fases do Projeto
Fase 3.1, partes integrantes do Anexo 19A deste Aditivo do Contrato.
Introduo sobre os Riscos
O objetivo deste documento descrever os riscos identificados para o Projeto, seu impacto e
probabilidade, e as aes de mitigao previstas.
Este documento foi elaborado em conjunto pela equipe do FORNECEDOR e reas de
Arquitetura e Desenvolvimento de TI do CLIENTE.
Os riscos e as informaes associadas consideram a estratgia de movimentao prevista
(resumo a seguir) e devem ser analisados em relao ao contexto em que esto inseridos. A
coluna Observaes contm informaes adicionais pertinentes para o entendimento.
Os riscos esto agrupados em duas categorias, Riscos para o Negcio e Riscos para o
Projeto, e classificados pela Severidade, de acordo com a matriz includa no final do
relatrio.
Os perodos e durao previstos para os riscos (quando indicado) consideram o
planejamento de atividades.
Resumo da Estratgia de Movimentao do TELACORE (Contexto de Projeto)

As informaes a seguir representam um resumo da estratgia de movimentao do
TELACORE para o datacenter em Hortolndia - CT. Detalhes e informaes
complementares esto includas no documento de Estratgia de Migrao.
A estratgia de movimentao do ambiente produtivo do TELACORE para o CT
compreende a criao de um ambiente de apoio com porte e funcionalidade iguais ou
superiores ao ambiente atual, denominado Ambiente de apoio Bolha, localizado no
CT. Este ambiente, aps testes de homologao, estar pronto para assumir
definitivamente a produo.
Esto previstos testes de homologao, definidos no Plano de Homologao, de forma a
minimizar impacto para a produo do TELACORE. Para a realizao de testes no
Ambiente de apoio Bolha, o ambiente ser construdo de forma totalmente segregada
do ambiente atual, com acesso controlado e restrito para execuo dos testes. Sero
efetuados testes de integridade de dados e performance de conectividade.
Para o cutover a estratgia desligar o servidor produtivo NTRJO066, no DataCenter do
CLIENTE, realizando dessa forma, o chaveamento automtico do NTRJO067, como novo
servidor de produo no CT.
12
Legenda e Nomenclatura
Tipo:
E: Especfico para a movimentao (onda)
G: Geral, aplicvel para todas as movimentaes
Impacto (Imp), Probabilidade (Prob), Severidade (Sev):
A: Alto
M: Mdio
B: Baixo
Indet: Indeterminado
Nomenclatura:
Ambiente produtivo: refere-se a todo o ambiente que suporta a Produo do
TELACORE, incluindo ambiente primrio e secundrio
Critrio para Atribuio da Severidade
Matriz de Severidades
Impacto
Baixo Mdio Alto
Alta Mdio Alto Alto

Probabilidade
Mdia Mdio Alto Alto
Baixa Baixo Mdio Mdio
Estratgia para Tratamento de Riscos

Transferncia de Risco. Utilizando estratgia de transferncia, transferncia
total ou parcial de um risco para uma outra parte.
Contingncia de Risco: Quando existir uma contingncia planejada, pode ser
utilizada para cobrir custos gerados por um problema ocorrido.
Aceitao de Risco: Nesta estratgia, est de acordo com o risco e pronto
para aceitar as conseqncias decorrentes aos riscos ocorridos.
Reserva de Risco: Nesta estratgia, se planejam os custos para serem
usados quando ocorrer um risco ou quando for necessrio utilizar para conter um risco.
Conter Riscos. Quando houver risco, so tomadas aes para minimizar a
ocorrncia e efeito de um risco conhecido.
13
Riscos para o Negcio
Plano de
Contingncia
Risco
existente
Integrao dos somente se
planejamentos de houver
fallback, com o necessidade de
Problemas de
correspondente fallback durante
execuo das
alinhamento das a movimen-
atividades de
necessidades de Acionamento tao fsica.
fallback em funo Conteno
2 1 G A B M recursos. de equipes em
do do Risco
stand by. Historicamente,
compartilhamento
Utilizao de em todas as
de equipes do
equipes movimentaes
FORNECEDOR.
diferentes para efetuadas at o
atender todas as momento no
atividades. houve
necessidade de
fallback.
Caso haja
qualquer
impacto o
Monitorao
FORNECEDOR
intensiva do
ir interromper
ambiente
Problemas de o processo de
produtivo para
performance no cpia para que
possveis
ambiente produtivo no haja
impactos. No h
em decorrncia do Conteno impacto no
2 2 G A B M observaes
processo de cpia do Risco negcio do
A cpia ser adicionais.
do ambiente CLIENTE.
executada nos
produtivo para o
momentos de
ambiente bolha. Reavaliao de
menor
estratgia do
probabilidade de
processo de
impacto.
cpia do ambi-
ente produtivo
para a Bolha.
No Aplicvel a
Definio clara
este projeto
dos objetivos e o
Baixo desempenho porque os
escopo dos teste
ou perda de testes de
de Homologao
performance no homologao No h
Eliminao junto aos
2 3 G ambiente migrado A B M sero observaes
de Risco usurios e reas
devido a teste de abrangentes e adicionais.
de
Homologao no incluiro todos
desenvolvimento
representativo. os cenrios
e arquitetura do
crticos da
CLIENTE.
aplicao.
Estudos detalha-
dos da carga de
rede dos
ambientes atuais:
acesso dos usu- Historicamente,
rios on-line e em todas as
Baixa performance
interconectividade movimentaes
do ambiente
dos ambientes. Anlise e efetuadas at o
produtivo em
identificao momento no
funo da mudana
Conteno Utilizao de links das causas e houve
2 4 G de arquitetura de A B M
do Risco adicionais rpida ao problemas de
conectividade (para
aumentando a para soluo performance
WAN durante
disponibilidade do problema. em funo da
operao
planejada (2 x arquitetura de
assistida).
155 mb). conectividade
(WAN).
Execuo de
testes de homo-
logao antes do
cutover.
Plano de
Contingncia
Indisponibilidade do Conteno Execuo de Fallback ou No h
2 5 G A B M
ambiente produtivo do Risco testes de reparo do observaes
14
em funo de validao das problema, adicionais.

alterao na infra- alteraes de dependendo do
estrutura atual de infra-estrutura caso.
hardwares e (changes).
softwares dos
sistemas.
Participao das
reas de on-going
Apresentar Historicamente,
na elaborao e
problemas de em todas as
execuo do
operao/produo/ movimentaes
planejamento e
suporte devido ao efetuadas at o
SOW.
no envolvimento Conteno momento no
2 6 G A B M No Aplicvel.
das reas de on- do Risco houve
Plano de ao
going do problemas
para paralisao
FORNECEDOR no operao /
e recuperao
projeto de produo/
durante as
movimentao. suporte.
interrupes
programadas.
15
Riscos para o Projeto
Plano de
Contingncia
Negociao junto
ao CLIENTE para
aumentar a
prioridade deste
projeto
(responsvel pela
Atraso no projeto
negociao: GP
em decorrncia da
FORNECEDOR e
Indisponibilidade
GP CLIENTE).
das equipes de
desenvolvimento
Planejamento
para definio dos
detalhado das No h
cenrios de Conteno
1 1 E A A A necessidades de No Aplicvel. observaes
homologao e na do Risco
recursos das adicionais.
elaborao em
reas de
conjunto do plano
desenvolvimento.
detalhado do
projeto, anlise de
Negociao junto
impacto e plano de
a rea de
Fallback.
desenvolvimento
dos recursos
necessrios para
as atividades
(responsvel GP
CLIENTE).
Negociao
conjunta entre
CLIENTE e
Atraso no projeto FORNECEDOR
em decorrncia da para identificar
falta de janela tcnica que No h
Conteno
1 2 E disponibilidade de A M A seja adequada No Aplicvel. observaes
do Risco
Janelas Tcnicas para o adicionais.
para cutover para o TELACORE.
TELACORE.
Otimizao do
perodo de Janela
Tcnica.
Negociao de
impactos e
prioridades de
negcio junto ao
CLIENTE
(responsvel pela
Atraso no projeto
negociao: GP
em decorrncia da
FORNECEDOR e
indisponibilidade de
GP CLIENTE).
Janelas Tcnicas
No h
para configurao e Conteno
1 3 E A M A Negociao de No Aplicvel. observaes
cutover dos do Risco
prazos adicionais.
ambientes, junto s
considerando a
reas de
visibilidade de
desenvolvimento e
planejamento de
usurios.
requisitos de
negcio .
Otimizao do
perodo de Janela
Tcnica.
16
Plano de
Contingncia
Negociao para
aumentar a
prioridade deste
projeto, junto ao
CLIENTE
(responsvel pela
negociao: GP
FORNECEDOR e
GP CLIENTE).
Atraso no projeto
Envolvimento das
em decorrncia da
reas usurias
Indisponibilidade
nas atividades do
das reas usurias
projeto.
para a definio No h
Conteno
1 4 E dos cenrios de A B M No Aplicvel. observaes
do Risco Planejamento
homologao e adicionais.
detalhado das
para validao e
necessidades de
execuo do plano
recursos das
detalhado do
reas usurias.
projeto.
Negociao dos
recursos
necessrios para
as atividades,
junto s reas
usurias
(responsvel pela
negociao: GP
CLIENTE).
Novos sistemas
devero ser
implementados
prioritariamente
no CT.
Negociao de
prioridades de
negcio junto ao
CLIENTE, em
Atraso no projeto
caso de
em decorrncia de
versionamento.
Novos Projetos No h
Conteno
2 1 G (sistemas e A B M No Aplicvel. observaes
do Risco Alinhamento da
versionamento) e adicionais.
rea de
alterao da infra-
arquitetura de TI
estrutura atual.
do CLIENTE em
conjunto com a
equipe de
Transio do
FORNECEDOR
para avaliao de
impactos no
projeto e
definio de um
plano de ao.
17
Plano de
Contingncia
Uso de
mecanismos
automticos de
replicao de
dados: Oracle
Standby Server e
TSM Server.
Uso de
ferramentas
Oracle para
verificar
consistncia do
banco de dados
Corrupo dos (DBV e export).
Refazer todo o
dados durante a No h
Conteno processo , com
2 2 G replicao entre a A B M Configurao do observaes
do Risco re-sincronismo
produo e o TSM Server para adicionais.
da Bolha.
ambiente bolha. backup e restore
utilizando CRC.
Checklist de
integridade de
dados pelo
FORNECEDOR.
Realizao de
Reviso Tcnica
de Qualidade
durante o
sincronismo, para
aplicaes
crticas.
Negociao
antecipada com
Atraso no projeto
os fornecedores Avaliar
em decorrncia da
da aplicao substituio de
recusa dos
(responsvel pela Software,
Fornecedores da
negociao: GP Hardware e
aplicao em No h
Conteno FORNCEDOR e fornecedor da
2 3 G prestar servios em A B M observaes
do Risco GP CLIENTE). aplicao.
funo da alterao adicionais.
do local da
Contratao de No migrar, se
execuo da
Bolhas de no houver
atividade
profissionais para soluo.
contratada.
substituio dos
mesmos.
Atraso no projeto Antecipar a
No h
devido a problemas Conteno negociao de
2 4 G A B M No Aplicvel. observaes
de licenas de do Risco licenas com
adicionais.
software. fornecedores.
Diretrizes de Gerenciamento
CobiT Management Guidelines
Processo PO9 Avaliao de Riscos
ANEXO I
19
A seguir sero apresentadas as diretrizes de gerenciamento, conforme documento CobiT

Management Guidelines, publicado pelo IT Governance Institute [ITGI, 2000c], sobre o
processo P09 Avaliao de Riscos.
PO9 Avaliao de Riscos
Controle sobre o processo de TI de Avaliar Riscos com o objetivo de negcio

de suportar decises da administrao atravs do atingimento dos objetivos de TI e
fazer frente s ameaas mediante a reduo da complexidade, o aumento da
objetividade e a identificao de importantes fatores de deciso.
Assegurar o fornecimento da informao ao negcio que abordam os

requeridos Critrios de Informao e so medidos pelos Indicadores Chaves de
Objetivos.
atingido mediante o engajamento da prpria organizaao na identificao de

riscos e na anlise de seu impacto, envolvendo funes multidisciplinares e adotando
medidas viveis em termos de custo/benefcio para mitigar os riscos.
Considera Fatores Crticos de Sucesso que influenciam especficos

Recursos de TI e so medidos pelos Indicadores Chaves de Desempenho.
Fatores Crticos de Sucesso

H claramente definidos papis e responsabilidades para a alocao e
mensurao da gesto de riscos.
Uma poltica est estabelecida para definir limites de risco e tolerncia de
risco.
A avaliao de risco realizada combinando vulnerabilidades, ameaas e
valor dos dados.
A informao estruturada para avaliao do risco mantida, atualizada pelo
relatrio de incidentes.
Responsabilidades e procedimentos para definio, aceitao e um
aprimoramento do financiamento da gesto de riscos existem.
O foco da avaliao est primeiramente nas ameaas reais e em menos nas
tericas.
Sesses de brainstorming e anlises de causas que conduzem para a
identificao e mitigao dos riscos so executadas rotineiramente.
Uma verificao da realidade da estratgia conduzida por uma terceira
parte para aumentar a objetividade e repetida em tempos apropriados.
Indicadores Chaves de Objetivos
Aumento do grau de conscincia da necessidade de avaliaes de risco.
Diminuio do nmero de incidentes causados por riscos identificados aps
o fato.
Aumento do nmero de riscos identificados que tenham sido
suficientemente mitigados.
Aumento do nmero de processos de TI que tm documentao formal das
avaliaes de risco concludas.
Porcentagem apropriada ou nmero de medidas de custo eficazes da
avaliao de risco.
20
Indicadores Chaves de Desempenho
Nmero de reunies e de oficinas de gesto de riscos.

Nmero de projetos de aprimoramento da gesto de riscos.
Nmero de aprimoramentos para o processo de gesto de riscos.
Nvel de financiamento alocado projetos de gesto de riscos.
Nmero e freqncia de atualizaes para publicao dos limites de riscos e
polticas.
Nmero e freqncia dos relatrios de monitorao de riscos.
Nmero de pessoas treinadas na metodologia de gesto de riscos.
21
PO9 Modelo de Maturidade
Controle sobre o processo de TI de Avaliar Riscos com o objetivo de negcio de suportar

decises da administrao atravs do atingimento dos objetivos de TI e fazer frente s
ameaas mediante a reduo da complexidade, o aumento da objetividade e a identificao de
importantes fatores de deciso.
0 Inexistente. A avaliao de risco para processos e decises de negcio no ocorre. A

organizao no considera os impactos do negcio associados com as vulnerabilidades da
segurana e com as incertezas do projeto do desenvolvimento. A gerncia de risco no foi
identificada como relevante para adquirir solues de TI e entrega de servios de TI.
1 Inicial. A organizao est ciente de suas responsabilidades e obrigaes legais e

contratuais, mas considera os riscos de TI de uma maneira ad hoc, sem seguir processos ou
polticas definidas. As avaliaes informais do projeto de risco ocorrem como determinado
por cada projeto. As avaliaes de risco provavelmente no so identificadas
especificamente dentro de um projeto planejado ou so atribudas aos gerentes especficos
envolvidos no projeto. A gerncia de TI no especifica responsabilidade para a gesto de
risco em descries de trabalho ou em outros meios informais.
Especficos riscos relacionados a TI tais como a segurana, disponibilidade e integridade so
ocasionalmente considerados em uma base de projeto-por-projeto. Os riscos relacionados a
TI que afetam operaes cotidianas so discutidos raras vezes em reunies da gerncia.
Onde os riscos foram considerados, a mitigao inconsistente.
2 Repetvel mas Intuitivo. H emergente compreendimento que riscos de TI so

importantes e necessrios serem considerados. Alguma abordagem avaliao de risco
existe, mas o processo ainda imaturo e em desenvolvimento. A avaliao est geralmente
em um alto-nvel e tipicamente aplicada somente aos projetos principais. A avaliao de
operaes avanadas depende principalmente da gerncia de TI que levanta como um tem
da agenda, que acontece freqentemente somente quando os problemas ocorrem. A
gerncia de TI geralmente no define procedimentos ou descries de trabalho que tratam
da gesto de risco.
3 Processo Definido. Uma ampla poltica de gesto de risco na organizao define quando
e como conduzir as avaliaes de risco. A avaliao de risco segue um processo definido
que est documentado e disponvel a toda a equipe de funcionrios treinada. As decises
para seguir o processo e para receber o treinamento so deixadas discrio do indivduo. A
metodologia est convencendo e sondando, e assegura que os riscos chaves ao negcio
esto provavelmente para serem identificados. As decises para seguir o processo so
deixadas ao indivduo gerente de TI e no h nenhum procedimento para assegurar-se de
que todos os projetos estejam cobertos ou que o avano da operao est examinada para o
risco em uma base regular.
4 Gerenciado e Medido. A avaliao do risco um procedimento padro e as excees

para seguir o procedimento esto sendo observadas pela gerncia de TI. provvel que a
gesto de risco de TI uma funo definida da gerncia com nvel de responsabilidade
snior. O processo avanado e o risco avaliado no nvel do projeto individual e tambm
regularmente no que diz respeito a operao de TI por toda a parte. A administrao
avisada em mudanas no ambiente de TI que poderiam significativamente afetar os cenrios
do risco, tais como uma crescente ameaa vinda da rede ou as tendncias tcnicas que
afetam a sade da estratgia de TI. A administrao pode monitorar a posio do risco e
tomar decises informadas a respeito da exposio que est disposta a aceitar. A gerncia
snior e a gerncia de TI determinaram os nveis do risco que a organizao ir tolerar e tem
medidas padro para relaes de risco/retorno. A gesto de oramentos para a gesto de
risco operacional projetam-se para repensar os riscos em uma base regular. Uma base de
dados da gesto de risco est estabelecida.
5 Otimizado. A avaliao de risco foi desenvolvida ao estgio onde um amplo processo

estruturado na organizao reforado, seguido regularmente e bem controlado. O
brainstorming e a anlise de causas de risco, envolvendo os indivduos peritos, so aplicados
22
atravs da organizao inteira. A captura, a anlise e relato de dados da gesto de risco so

altamente automatizados. A orientao extrada dos lderes no campo e a organizao de
TI faz parte em grupos pares s trocas de experincias. A gesto de riscos
verdadeiramente integrada em todo o negcio e nas operaes de TI, esto bem aceitas e
envolve extensivamente os usurios dos servios de TI.

Universidade Federal Do Rio de Janeiro Escola Politécnica Dcc/Npac

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Universidade Federal Do Rio de Janeiro Escola Politécnica Dcc/Npac

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

ESTUDOS DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO

Paulo Souza Toledo Junior

Paulo Souza Toledo Junior

Monografia apresentada no Curso de

Paulo Souza Toledo Junior

Eduardo Linhares Qualharini e Maria Alice Ferruccio Rainho

Monografia submetida ao Curso de Ps-graduao Gerenciamento de Projetos, da

A DEUS, por conduzir nossas vidas pelos

ESTUDO DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO SOBRE

Paulo Souza Toledo Junior

Resumo da Monografia submetida ao corpo docente do curso de Ps-Graduao em

Este trabalho pretende apresentar um estudo de caso sobre o projeto de transio de

Palavras-chave: Gerenciamento, Riscos, Projetos TI.

Figura 1: Viso geral das reas de conhecimento em gerenciamento de

Quadro 1: Nmero de Metodologias Utilizadas pelas Organizaes ........................14

Tabela 1: Ambientes Contemplados na Transio ....................................................28

ATM Asynchronus Transfer Mode (Modo de Tranferncia Assncrona)

Com a evoluo tecnolgica das ltimas dcadas surgiram inmeras

A maioria dos especialistas em TI acreditam que sendo um bom tcnico e

No entanto, essas mesmas pessoas esquecem de diversos fatores que podem

1.1 Justificativa do Tema

Escolhido por se tratar de um projeto no qual tive participao ativa e decisria

da minha rea de atuao como Especialista em Sistemas Operacionais da

1.2.1 Objetivo Geral

Enfatizar o conceito de riscos e a importncia de praticar a sua gesto dentro

1.2.2 Justificativa e Importncia

Muito importante para a compreenso do problema apresentado, a disciplina

Para conhecimento de todos os riscos de TI importante que esta rea tenha

1.2.3 Objetivo Especfico

- Realizar um estudo de caso sobre o Projeto de Movimentao de Servidores

- Fazer uma anlise crtica focada na rea de conhecimento de riscos e, se

1.3 Descrio do Problema

Devido a um aditivo de contrato; transicionar, no perodo de 1 de junho de 2005

- Transicionar os 26 ambientes de forma a garantir o cumprimento da restrio

- Transicionar menos ambientes devido a futuras redues no escopo por parte

- Cancelamento do projeto, em dado momento, pelo CLIENTE com pagamento

- Pagamento de multa, ao CLIENTE, por atraso no cutover de cada ambiente.

1.5 Estrutura do Trabalho

Alm desta introduo, o trabalho compreende os seguintes captulos:

O Captulo 2 contempla uma reviso bsica e sintetizada do aprendizado

2.1 O que Gerenciamento de Projetos?

Segundo o PMI [2004], o gerenciamento de projetos a aplicao de

Gerenciar um projeto inclui:

- Identificao das necessidades;

- Estabelecimento de objetivos claros e alcanveis;

- Balanceamento das demandas conflitantes de qualidade, escopo,

- Adaptao das especificaes, dos planos e da abordagem s

Por que devemos gerenciar projetos

Podemos destacar alguns motivos para que as mudanas sejam bem

- Para evitar surpresa durante a execuo dos trabalhos, antecipando

- Para agilizar as decises, j que as informaes esto estruturadas e

dessas decises (como a captao de recursos, alocao de pessoal),

- Para facilitar e orientar as revises do projeto. Com as informaes

- Para otimizar a alocao de pessoas;

- Para documentar e facilitar estimativas para futuros projetos.

Conforme argumentao do PMI [2004:8]; os gerentes de projetos

A equipe de gerenciamento de projetos possui uma responsabilidade

importante observar que muitos processos dentro do gerenciamento de

O termo gerenciamento de projetos s vezes usado para descrever uma

2.2 reas de Conhecimento em Gerenciamento de Projetos

O PMI [2004], descreve nove reas de conhecimento; sendo elas:

Gerenciamento de integrao do projeto, descreve os processos e as