ESCOLA POLITÉCNICA
DCC/NPAC
ESTUDOS DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO
SOBRE PROJETO DE TRANSIÇÃO DE AMBIENTES CRÍTICOS
Paulo Souza Toledo Junior
Paulo Souza Toledo Junior
M o n o g r a f i a a p r e s e n t a d a n o C u r s o d e P ó s - G r a d u a ç ã o e m G e r e n c i a m e n t o d e P r o j e t o s , d a E s c o l a P o l i t é c n i c a , d a U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o .Orientadores:
Eduardo Linhares Qualharini
Maria Alice Ferruccio Rainho
Rio de Janeiro Julho, 2006
ii
Paulo Souza Toledo Junior
Orientadores:
Eduardo Linhares Qualharini e Maria Alice Ferruccio Rainho
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
______________________________________
Eduardo Linhares Qualharini
Orientador
______________________________________
Lysio Séllos da Costa Filho
______________________________________
André Dametto
______________________________________
Maria Alice Ferruccio RainhoOrientadora
Rio de Janeiro Julho, 2006
iii
TOLEDO JR, Paulo Souza.
Estudo de Riscos em Projetos de TI: Estudo de Caso sobre Projeto de Transição de Ambientes Críticos / TOLEDO JR, P. S. Rio de Janeiro: UFRJ/EP, 2006. x, 34f.: il.; 29,7cm.
Orientadores: Eduardo Linhares Qualharini, Maria Alice Ferruccio Rainho.
Monografia (especialização) – UFRJ/ Escola Politécnica/ Curso de Especialização em Engenharia, NPAC, 2005.
Referências Bibliográficas: 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 Politécnica, Pós-graduação. III. Especialista.
iv
A
Deus, Sponsor Supremo;
Jesus Cristo, Gerente de todos os meus
Projetos e meu melhor Amigo; e Vanessa
Toledo, Stakeholder e minha amada
Esposa.
v
Agradecimentos
A DEUS, por conduzir nossas vidas pelos
caminhos certos.
A minha esposa, simplesmente por existir.
Aos meus pais, pelos esforços em basear
minha formação
sobre valores morais e dignos.
Aos meus amigos e colegas de trabalho,
que junto vivenciaram
a superação 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.
vi
ESTUDO DE RISCOS EM PROJETOS DE TI: ESTUDO DE CASO SOBRE PROJETO DE TRANSIÇÃO DE AMBIENTES CRÍTICOS
Paulo Souza Toledo Junior
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Este trabalho pretende apresentar um estudo de caso sobre o projeto de transição de um dos vinte e seis ambientes críticos de uma determinada Empresa no ramos de Telecomunicações, 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 Governança de TI –, de forma que se possa criticar a análise realizada nesta transição; compartilhando assim das experiências conquistadas na prática e com as lições aprendidas de projetos anteriormente realizados com escopos similares.
Palavras-chave: Gerenciamento, Riscos, Projetos TI.
Rio de Janeiro Julho, 2006
vii 1 INTRODUÇÃO ... .1 1.1 Justificativa do Tema ... .1 1.2 Objetivos ... .2 1.2.1 Objetivo Geral ... .2 1.2.2 Justificativa e Importância ... .2 1.2.3 Objetivos Específicos ... .2 1.3 Descrição do Problema ... .3 1.4 Hipóteses ... .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 Não Praticam a Gerência de Riscos? ... ..12
3.4 Metodologias Praticadas no Mercado ... ..14
3.4.1 Sobre Gerenciamento de Projetos ... ..14
3.4.2 Sobre Governança de TI ... ..15
3.5 Comentários Sobre Gerenciamento de Riscos (Apêndice 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 Hierárquica do Fornecedor para o Cliente ... ..25
5 O PROJETO DE TRANSIÇÃO ... ..27
viii
6 CONCLUSÕES E PROPOSIÇÕES ... ..31 REFERÊNCIAS BIBLIOGRÁFICAS...33 APÊNDICE A
ix
Figura 1: Visão 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: Gráfico de Impacto de Riscos ... 13
Figura 4: Organização matricial fraca ... 20
Figura 5: Organização composta ... 22
Figura 6: Organograma de On-Going ... 25
Figura 7: Organograma de Transição ... 27
LISTA DE QUADROS Quadro 1: Número de Metodologias Utilizadas pelas Organizações ... 14
LISTA DE TABELAS Tabela 1: Ambientes Contemplados na Transição ... 28
x
ATM Asynchronus Transfer Mode (Modo de Tranferência Assíncrona)
CPU Central Processor Unit (Unidade Central de Processamento)
CT Centro Tecnológico
DBA Database Administrator (Administrador de Banco de Dados)
EAP Estrutura Analítica do Projeto GP Gerente de Projeto
IP Internet Protocol (Protocolo Internet)
ISP Internet Solution Provider (Provedor de Serviço 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 (Método 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 (Escritório 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 (Memória de Acesso Randômico)
SLA Service Level Agreement (Nível de Atendimento de Serviço)
SOW Statement Of Work (Documento de Trabalho)
TI Tecnologia da Informação
VIP Very Important Person (Pessoa Muito Importante)
1
INTRODUÇÃO
Com a evolução tecnológica das últimas décadas surgiram inúmeras linguagens de programação, sistemas operacionais, bancos de dados, servidores de aplicação, infra-estrutura de rede e diversos outros componentes que devem ser levados em consideração no desenho da solução de um sistema de TI [PEREZ, 2006].
A cada dia fica mais clara a percepção de que gerenciar projetos é gerenciar riscos. É interessante observar a ingenuidade que existia por trás das técnicas de gerenciamento de projetos até há alguns anos atrás. Estas técnicas partiam do princípio, absurdamente otimista, de que nada iria dar errado ao longo do projeto. Ou seja, ninguém iria pedir demissão, ficar doente, ou mesmo render menos do que o projetado no início. Todas as ferramentas de desenvolvimento iriam funcionar perfeitamente, não conteriam bugs, seriam fáceis de aprender e de utilizar e assim por diante. Os usuários saberiam exatamente o que querem, e seus desejos e necessidades não mudariam durante o projeto. Além disso, os analistas seriam capazes de entender perfeitamente estas necessidades, sem nenhuma ambigüidade e sem deixar nada de fora. A fase de testes não revelaria muitos defeitos, apenas um número suficiente deles, capaz de encher os dias previstos pelo cronograma original para os testes. Não haveria nenhum problema de hardware, nenhum vírus apareceria, nenhum arquivo desapareceria. Depois, ninguém entendia porque os planos e cronogramas do projeto nunca davam certos [BELLOQUIM, 2006].
A maioria dos especialistas em TI acreditam que sendo um bom técnico e conhecendo todos esses componentes, os riscos de erros nos sistemas a serem desenvolvidos são mínimos ou até mesmo quase inexistentes.
No entanto, essas mesmas pessoas esquecem de diversos fatores que podem influenciar positivamente ou não os sistemas desenvolvidos hoje em dia, que são justamente as disciplinas apontadas no PMBoK. E é devido à essa falha já de conhecimento da maioria dos profissionais de informática que existe uma grande necessidade não só da presença e atuação 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 participação ativa e decisória para que o resultado esperado fosse alcançado com sucesso. Projeto que poderia alavancar a minha carreira, com grande probabilidade de, ao término do mesmo, sair
da minha área de atuação – 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 importância de praticar a sua gestão dentro de projetos, abordando os principais processos definidos no PMBoK relativos ao gerenciamento desta área de conhecimento. Práticas que fundamentam alguns destes processos serão apresentadas, visando consubstanciar o que está sendo exposto.
1.2.2 Justificativa e Importância
Muito importante para a compreensão do problema apresentado, é a disciplina TI nas empresas. Como ela é ainda vista, por muitos gestores, como uma grande consumidora de recursos, que não é uma inverdade, empresários relegam a segundo plano os gastos ditos não necessários para a operação das atividades desta área. Estes empresários assumem os riscos de TI sem o mínimo de conhecimento da sua extensão e impacto [GALVES, 2006].
Para conhecimento de todos os riscos de TI é importante que esta área tenha uma metodologia básica e cada gestor e equipe estejam preparados para validar Riscos; entender a extensão das perdas e impactos e habilitados a elaborar e manter Planos de Contingência. É imprescindível também que as Gerências operacionais e os técnicos estejam, além de preparados para apontar estes Riscos, definir ações preventivas e corretivas a serem aprovadas pelos órgãos superiores.
1.2.3 Objetivo Específico
- Realizar um estudo de caso sobre o Projeto de Movimentação de Servidores (transição de ambientes críticos) de uma grande empresa no ramo de telecomunicações (a qual será denominada como CLIENTE) para o CT (Centro Tecnológico), da empresa em que trabalho, cuja localização é Hortolândia – SP (a empresa prestadora de serviços – será denominada como FORNECEDOR);
- Fazer uma análise crítica focada na área de conhecimento de riscos e, se cabível, sugerir melhorias baseadas nas lições aprendidas, que sirvam para futuros projetos de TI com escopos similares.
1.3 Descrição do Problema
Devido a um aditivo de contrato; transicionar, no período de 1 de junho de 2005 a 31 de janeiro do ano seguinte, 26 ambientes críticos localizados nos Data Centers do CLIENTE (RJ e SP) para o CT do FORNECEDOR, em Hortolândia. Entretanto, alguns ambientes poderiam ter a data de cutover (migração) independente ou coincidente com outros ambientes – em alguns casos, essa “coincidência” foi obrigatória.
1.4 Hipóteses
- Transicionar os 26 ambientes de forma a garantir o cumprimento da restrição tripla (escopo, tempo e custo) e a qualidade das mudanças acordadas com o CLIENTE;
- Transicionar menos ambientes devido a futuras reduções no escopo por parte do CLIENTE, mas sem redução de prazo;
- Cancelamento do projeto, em dado momento, pelo CLIENTE com pagamento de multa rescisória para o FORNECEDOR;
- Pagamento de multa, ao CLIENTE, por atraso no cutover de cada ambiente.
1.5 Estrutura do Trabalho
Além desta introdução, o trabalho compreende os seguintes capítulos:
O Capítulo 2 contempla uma revisão básica e sintetizada do aprendizado obtido em gerenciamento de projetos, ou seja, a revisão literária. No Capítulo 3, foram abordados assuntos específicos sobre o gerenciamento de riscos em projetos de TI sobre o prisma de duas metodologias: PMI e CobiT. No Capítulo 4, foram colocadas algumas informações sobre as empresas CLIENTE e FORNECEDOR, na qual se realizou o estudo de caso, passando em seguida para o Capítulo 5 aonde foi estabelecida a metodologia da pesquisa. Na sequência, este Capítulo aponta para o Apêndice A cujo detalhamento do projeto objeto do estudo e suas análises são realizadas. À conclusão (Capítulo 6), a bibliografia e o Anexo I, encerram este trabalho.
2
GERENCIAMENTO DE PROJETOS
Este capítulo é baseado na idéia de fazer uma revisão dos principais conceitos de gerenciamento de projetos utilizados pelo PMI, os quais foram passados ao longo do Curso de Pós-graduação em Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ.
2.1 O que é Gerenciamento de Projetos?
Segundo o PMI [2004], o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento. O gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto.
Gerenciar um projeto inclui:
- Identificação das necessidades;
- Estabelecimento de objetivos claros e alcançáveis;
- Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo; e
- Adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas.
Por que devemos gerenciar projetos
Podemos destacar alguns motivos para que as mudanças sejam bem administradas [POSSI, 2004]:
- Para evitar surpresa durante a execução dos trabalhos, antecipando riscos e situações desfavoráveis que poderão ser encontradas. Projetos bem geridos reduzem os riscos de surpresas e situações desfavoráveis. Caso essas surpresas ou situações apareçam, o profissional sabe como contorná-las sem ter que parar o andamento de um projeto;
- Para agilizar as decisões, já que as informações estão estruturadas e disponíveis. Sem a organização dessas informações (andamento do projeto, riscos que estão surgindo e resultados já obtidos) não há também a agilização
dessas decisões (como a captação de recursos, alocação de pessoal), retardando ou parando o projeto e dificultando a chegada ao resultado proposto inicialmente;
- Para facilitar e orientar as revisões do projeto. Com as informações (citadas no ponto anterior) disponíveis, tem-se um maior controle sobre o projeto, podendo revisá-lo sempre que necessário e redirecioná-lo de uma forma simples e viável;
- Para otimizar a alocação 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 redução de riscos e aumentando as probabilidades de sucesso de um projeto. Também se pode aproveitar essas informações/conhecimentos para replanejar o projeto.
Conforme argumentação do PMI [2004:8]; os gerentes de projetos freqüentemente falam de uma “restrição tripla” — escopo, tempo e custo do projeto — no gerenciamento de necessidades conflitantes do projeto. A qualidade do projeto é afetada pelo balanceamento desses três fatores. Projetos de alta qualidade entregam o produto, serviço ou resultado solicitado dentro do escopo, no prazo e dentro do orçamento. A relação entre esses fatores ocorre de tal forma que se algum dos três fatores mudar, pelo menos um outro fator provavelmente será afetado. Os gerentes de projetos também gerenciam projetos em resposta a incertezas. Um risco do projeto é um evento ou condição 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 organização executora e o público.
É importante observar que muitos processos dentro do gerenciamento de projetos são interativos devido à existência, e necessidade, de uma elaboração 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 nível 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 operações já em andamento, que podem ser redefinidas como projetos, o que também é chamado “gerenciamento por projetos””.
2.2 Áreas de Conhecimento em Gerenciamento de Projetos O PMI [2004], descreve nove áreas de conhecimento; sendo elas:
Gerenciamento de integração do projeto, descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projetos, que são 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 declaração do escopo preliminar do projeto, Desenvolver o plano de gerenciamento do projeto, Orientar e gerenciar a execução do projeto, Monitorar e controlar o trabalho do projeto, Controle integrado de mudanças e Encerrar o projeto.
Gerenciamento do escopo do projeto, descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário, para que seja concluído com sucesso. Ele consiste nos processos de gerenciamento de projetos: Planejamento do escopo, Definição do escopo, Criar EAP, Verificação do escopo e Controle do escopo.
Gerenciamento de tempo do projeto, descreve os processos relativos ao término do projeto no prazo correto. Ele consiste nos processos de gerenciamento de projetos: Definição da atividade, Seqüenciamento de atividades, Estimativa de recursos da atividade, Estimativa de duração da atividade, Desenvolvimento do cronograma e Controle do cronograma.
Gerenciamento de custos do projeto, descreve os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que o projeto termine dentro do orçamento aprovado. Ele consiste nos processos de gerenciamento de projetos: Estimativa de custos, Orçamentação 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.
Gerenciamento das comunicações do projeto descreve os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e adequada. Ele consiste nos processos de gerenciamento de projetos: Planejamento das comunicações, Distribuição das informações, Relatório de desempenho e Gerenciar as partes interessadas.
Gerenciamento de riscos do projeto descreve os processos relativos à realização do gerenciamento de riscos em um projeto. Ele consiste nos processos de gerenciamento de projetos: Planejamento do gerenciamento de riscos, Identificação de riscos, Análise qualitativa de riscos, Análise quantitativa de riscos, Planejamento de respostas a riscos e Monitoramento e controle de riscos.
Gerenciamento de aquisições do projeto descreve os processos que compram ou adquirem produtos, serviços ou resultados, além dos processos de gerenciamento de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar compras e aquisições, Planejar contratações, Solicitar respostas de fornecedores, Selecionar fornecedores, Administração 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.
Figura 1 – Visão 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 são realizados por pessoas e normalmente se enquadram em uma das duas categorias [POSSI, 2004]:
- Processos do gerenciamento de projetos se relacionam com a descrição e a organização do trabalho do projeto. Os processos de gerenciamento de projetos, que são aplicáveis à maioria dos projetos.
- Processos orientados ao produto se relacionam com a especificação e a criação do produto do projeto. Os processos orientados ao produto são
definidos pelo ciclo de vida do projeto e variam de acordo com a área de aplicação.
Figura 2 – Diagrama de Processos dos Projetos Fonte: POSSI [2004:36]
Na figura acima, para os processos de Planejamento, Execução e Controle, pode ser utilizado o Ciclo PDCA (método que se baseia no controle de processos visando melhoria contínua) em alguns projetos – como por exemplo – na área de P&D para a criação de um novo produto ou tecnologia. Entretanto, esse loop (repetição) 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]:
- Iniciação, é a fase inicial do projeto, quando uma determinada necessidade é identificada e transformada em um problema estruturado a ser resolvido por ele. Nessa fase, a missão e o objetivo do projeto são definidos, bem como as melhores estratégias são identificadas e selecionadas.
- Planejamento, é a fase responsável por detalhar tudo aquilo que será realizado pelo projeto, incluindo cronogramas, interdependências entre atividades, alocação de recursos envolvidos, análise de custos etc, para que, no final dessa fase, ele esteja suficientemente detalhado para ser executado
sem dificuldades e imprevistos. Nessa fase, os planos auxiliares de comunicação, qualidade, riscos, suprimentos e recursos humanos também são desenvolvidos.
- Execução, é a fase que materializa tudo aquilo que foi planejado anteriormente. Qualquer erro cometido nas fases anteriores fica evidente durante esse processo. Grande parte do orçamento e do esforço do projeto é consumida nessa fase.
- Controle, é a fase que acontece paralelamente ao planejamento operacional e à execução do projeto. Tem como objetivo acompanhar e controlar aquilo que está sendo realizado pelo projeto de modo a propor ações corretivas e preventivas no menor espaço de tempo possível após a detecção de anormalidade. O objetivo do controle é comparar o status atual do projeto com o status previsto pelo planejamento, tomando ações corretivas em caso de desvio.
- Encerramento, é a fase quando a execução dos trabalhos é avaliada através de uma auditoria interna ou externa (terceiros), os livros e documentos do projeto são encerrados e todas as falhas ocorridas durante o projeto são discutidas e analisadas para que os erros similares não ocorram em novos projetos.
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 condição 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, não pode ser parametrizada – existe ou não existe. Projetos trabalham com incerteza, porém só é possível 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 possível, quantificado.
É importante ressaltar que os riscos são referentes ao empreendimento – basicamente coisas que afetam o retorno de capital. Sendo assim, outros tipos de “riscos” – como saúde, meio ambiente e segurança – podem ser analisados, mas sempre pelo prisma do negócio.
3.2 O que é Risco de TI?
O risco de TI é mais do que simplesmente a segurança de TI e inclui risco de projeto, risco de arquitetura, risco com fornecedor, satisfação do cliente, dentre outros fatores. A execução de projetos de TI, em especial, é bastante diferente da maioria dos demais tipos de projetos , devido à complexidade do empreendimento, a constante dificuldade de visualização do produto a ser desenvolvido ou do serviço a ser entregue; além das dificuldades de comunicação entre o executor e o solicitante. Portanto, nada mais natural, que a ocorrência de eventos que impactem os objetivos do projeto que não foram identificados durante a fase de planejamento. Este assunto vem requerendo, por parte das empresas prestadoras de serviços ou desenvolvedoras de softwares, maior estruturação de suas fontes de riscos, face aos fracassos anteriores em seus projetos.
3.2.1 Classes de Risco de TI
São definidas sete classes de riscos de TI, onde, em cada caso, ocorrendo algum erro em TI, gera consequências negativas para o negócio [JORDAN; SILCOCK, 2005]:
1. Projetos – falhando na entrega quanto a implementação de novos sistemas, atualizações ou melhorias dos existentes;
2. Continuidade nos Serviços de TI – quando operações de negócios saem do ar, gerando indisponibilidade ou queda de performance que impactam os usuários e o negócio;
3. Recurso da Informação – falhando em proteger e preservar, seja por uma estrutura inadequada de backup incidindo na não recuperação de dados perdidos ou seja por falta de segurança da informação (vulnerabilidades que permitam a espionagem industrial ou fraude) ;
4. Provedores de Serviços e Vendedores – quebra na cadeia de valores de TI. Aplicações de terceiros que são críticas para o negócio apresentam falhas constantes e o suporte é inadequado para a correção destas (ponto cuidadosamente tratado em contratos de outsourcing);
5. Aplicações – sistemas falhando por manutenção inadequada dos desenvolvedores internos;
6. Infraestrutura – fundações abaladas – nome genérico para computadores centralizados e distribuídos, e recursos de rede os quais as aplicações estão hospedadas. Problemas diversos como sistemas operacionais com bugs, cabeamento não estruturado, queda de energia não contingenciada etc.; e
7. Estratégico e Emergente – desativado por TI. Quando ocorre um desalinhamento estratégico e tecnológico, impossibilitando a atualização do parque tecnológico para gerar oportunidades e manter a concorrência no mercado.
3.3 Por que Muitas Empresas Não Praticam a Gerência de Riscos?
Alencar & Schmitz [2005, p.48] comentam “A despeito dos enormes benefícios que a gerência de risco pode trazer em termos de um aumento significativo no número de projetos que terminam com sucesso, muitas organizações têm dificuldade em adotar a sua prática”.
Muitas organizações desenvolvem, ao longo do tempo, uma cultura na qual aqueles que ousam apontar as incertezas a que todo projeto está, naturalmente, exposto são taxados de pessimistas ou derrotistas. Esse tipo de organização tende a valorizar os esforços dos “heróis de última hora”, que trabalham ininterruptamente para finalizar aquilo que deveria ter sido feito dentro do calendário de atividades acordado com o cliente.
Ao se negarem a reconhecer a contribuição que a análise destas incertezas podem trazer para a gerência dos projetos que desenvolvem anualmente, estas organizações acabam condenando a atividade de análise de risco ao ostracismo.
Em consequência, as estimativas de custo, tempo e fluxo de caixa gerados por seus gerentes de projetos dificilmente corresponde à realidade. Os projetos que estes gerentes executam estão, frequentemente, atrasados, criando um ambiente propício para o surgimento dos “heróis de última hora”, que a organização tanto valoriza”.
Para se ter uma noção real do impacto que este tipo de cultura pode causar, a figura abaixo demonstra uma correlação entre o risco e o custo no projeto.
Alto
Baixo
Inicio Encerramento
Ciclo de Vida do Projeto
Risco Custo
Probabilidade de ocorrência de Risco
Custo para corrigir um evento de Risco
Alto
Baixo
Inicio Encerramento
Ciclo de Vida do Projeto
Risco Custo
Probabilidade de ocorrência de Risco
Custo para corrigir um evento de Risco Custo para corrigir um evento de Risco
Figura 3 – Gráfico 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 ocorrência de risco; porém, o custo para a correção deste evento é inversamente proporcional à sua probabilidade de ocorrência. Na medida em que o projeto se aproxima da fase de encerramento, esta inversão proporcional volta a acontecer. Ou seja, existe uma baixa probabilidade de ocorrência de risco, mas caso este evento ocorra, o custo para a correção do mesmo é elavado e pode comprometer o projeto – impacto na restrição tripla.
3.4 Metodologias Praticadas no Mercado
Atualmente, existem diversas metodologias que são utilizadas em Gerenciamento de Projetos e em Governança de TI. Dentre estas, as mais conhecidas e praticadas pelas organizações são: PMI, MSF, CobiT, ITIL, CMM, ISO17799 etc.
PMI-RS Journal, Edição 9 [2005:2], através de um artigo desenvolvido por Adilson Pize, afirma que: “Um estudo de benchmarking realizado no Brasil em 2004, com 73 organizações dos mais diferentes setores, entre eles construção, consultoria, tecnologia da informação, telecomunicações, petróleo, gás e energia, demonstrou o seguinte quadro:
Quadro 1 – Número de Metodologias Utilizadas pelas Organizações.
Fonte: Adaptado de http://www.pmirs.org.br/PMI-RSJournal/PMI-RSJournalNro09.pdf acessado em 21/05/06.
Como podemos observar pelo gráfico acima, apenas 11% das organizações pesquisadas não possuem e não estão implantando metodologias para o gerenciamento de seus projetos.
Este mesmo estudo detectou que os setores de tecnologia e telecomunicações são 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:
50% (2) 16% (1) (1) (2) (3) (4) 11% (4) 23% (3)
- Planejamento do Gerenciamento de Riscos, decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um priojeto;
- Identificação de Riscos, determinação dos riscos que podem afetar o projeto e documentação de suas características;
- Análise Qualitativa de Riscos, priorização dos riscos para análise ou ação adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto;
- Análise Quantitativa de Riscos, análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto;
- Planejamento de Respostas a Riscos, desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto;
- Monitoramento e Controle de Riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto.
3.4.2 Sobre Governança de TI
O Gerenciamento de Riscos sobre o prisma da metodologia do CobiT [2000c], apresenta o seguinte processo:
- Avaliação de Riscos, contendo os seus objetivos sobre o assunto, conforme descrito no Anexo I, baseia-se em Fatores Críticos de Sucesso, Indicadores Chaves de Objetivos e de Desempenho e um Modelo de Maturidade para auxiliar na identificação de importantes fatores de decisão.
Para melhor compreensão, de uma forma geral, esses Fatores, Indicadores e Modelos de Maturidade são aplicados em todos os Processos do CobiT e podem ser genericamente explanados da seguinte forma:
Fatores Críticos de Sucesso, definem as mais importantes questões ou ações para o gerenciamento alcançar controles sobre e dentro dos processos de TI. Eles devem ser gerenciados orientados em guias de implementação e identificadas as
coisas mais importantes a serem feitas, estrategicamente, tecnicamente, organizacionalmente e proceduralmente;
Indicadores Chaves de Objetivos definem métricas que dizem ao gerenciamento – após o fato – se um processo de TI foi alcançado em seus requisitos de negócios, geralmente expressados em termos de critério de informação:
- Disponibilidade da informação necessária para suportar as necessidades de negócio;
- Ausência de riscos de integridade e confidencialidade; - Eficiência de custos em processos e operações;
- Confirmação de fidedignidade, eficácia e conformidade.
Indicadores Chaves de Desempenho definem métricas para determinar o quão bom estão as performances dos processos de TI em relação aos objetivos a serem alcançados; são indicadores de pistas se um objetivo será desejavelmente alcançado ou não; e são bons indicadores de potencialidade, práticas e habilidades.
Modelos de Maturidade, em resumo:
- Referem-se aos requisitos de negócios e os aspectos permitidos em diferentes níveis de maturidade;
- Escalas utilizadas em comparações pragmáticas;
- Escalas onde a diferença pode ser mensurável de um modo fácil;
- São reconhecíveis como um “perfil” de empresa relativa para governança de TI, segurança e controle;
- Ajuda a definir as posições de “Como é” e “Para ser” relativas à governaça de TI, segurança e controle de maturidade;
- Permitem, quando possível, níveis discretos que criam pontos iniciais que são difíceis de cruzar;
- Se aplicam cada vez mais aos fatores críticos de sucesso;
- Não são específicos à indústria e nem sempre aplicáveis, o tipo de negócio define o que é apropriado.
3.5 Comentários Sobre Gerenciamento de Riscos (Apêndice A)
Para melhor entendimento do documento de trabalho do projeto – referenciado no Apêndice A, mais especificamente no Capítulo 5 deste Apêndice –, faz-se necessária a explanação sobre dois conceitos básicos, porém fundamentais, em gerenciamento de riscos, que é a Probabilidade do Risco (chance de ocorrência de um risco) e o Impacto do Risco (determina o impacto que causará o risco em caso de ocorrência). Estes conceitos geram a Matriz de Severidade de Riscos (P x I), classificando-os como altos, médios, baixos ou indeterminados.
A partir desta matriz são sugeridas ações como: tratar preventivamente, tratar com planos de contingência ou monitorar.
O Rank classifica a Severidade de acordo com a avaliação técnica e de negócio, sendo número 1 o mais crítico.
Os riscos estão agrupados em duas categorias: Riscos para o Negócio 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
Rank NR Tipo Risco Imp Prob Sev Estratégia Plano de Mitigação Plano de
Contingência Observação 1 1 E Atraso no projeto em decorrência da Indisponibilidade das equipes de desenvolvimento para definição dos cenários de homologação e na elaboração em conjunto do plano detalhado do projeto, análise de impacto e plano de “Fallback”. A A A Contenção do Risco Negociação junto ao CLIENTE para aumentar a prioridade deste projeto (responsável pela negociação: GP FORNECEDOR e GP CLIENTE). Planejamento detalhado das necessidades de recursos das áreas de desenvolvimento. Negociação junto a área de desenvolvimento dos recursos necessários para as atividades (responsável GP CLIENTE). Não Aplicável. Não há observa-ções adicionais. Fonte: O autor
Este risco impactaria diretamente no cronograma, ou seja, em atraso dos
deliverables previstos no escopo do projeto. Consequentemente resultaria em
4 AS EMPRESAS 4.1 Cliente
4.1.1 Perfil da Empresa
A Empresa está completando 40 anos e seu quadro de funcionários conta com cerca de quatorze mil empregados – entre funcionários e terceiros.
A empresa oferece soluções completas de telecomunicações a todo mercado brasileiro, incluindo telefonia local, longa distância nacional e internacional, transmissão de dados, televisão e internet, além de assegurar atendimento em qualquer ponto do território nacional através de soluções via satélites. Seja em telefonia, dados ou internet, os serviços da Empresa oferecem um mix ideal entre tecnologia, qualidade, segurança e rentabilidade, tanto para o mercado corporativo quanto para o residencial e também para o setor público.
A Empresa possui a maior rede de telecomunicações do Brasil, reunindo fibras ópticas, cabos submarinos e satélites e profissionais altamente qualificados.
Dados
A Empresa fornece a mais completa solução em comunicação digital (dados, voz e vídeo) para empresas, com diferentes velocidades e abrangência nacional, atingindo até mesmo áreas onde não se encontram redes convencionais.
Redes Multiserviços
Para manter interconectadas as unidades de negócios, fornecedores e parceiros espalhados pelo Brasil e pelo mundo, a Empresa disponibiliza serviços corporativos que utilizam as mais avançadas tecnologias do setor (X25, Frame Relay, ATM e IP).
Internet
Do simples acesso até a formação de provedores de serviços de internet (ISP), a Empresa oferece o maior Backbone da América Latina para que as empresas naveguem pela Internet em Banda Larga. As soluções da Empresa suportam diversas tecnologias internet - protocolo e multiprotocolo internet (IP e MPLS), por exemplo.
Valor Adicionado
Empresa oferece para o mercado corporativo soluções completas de hospedagem de software e hardware, proteção de sistemas - através de elaborados processos de segurança -, realização de reuniões e treinamentos à distância, comércio eletrônico e muito mais.
Televisão & Rádio
Através de sua estrutura de centros de TV espalhados pelas principais cidades brasileiras, a Empresa disponibiliza para empresas serviços de transmissão de sinais digitais e analógicos de Rádio e TV, em âmbito nacional, utilizando a mais alta tecnologia terrestre e via satélite.
Soluções de Relacionamento
A Empresa oferece soluções completas para empresas, com a tecnologia da Rede Inteligente e Atendimento Automático: conexão à rede 100% digital da Empresa; formação de rede privativa virtual de voz; realização de videoconferências; disponibilidade de canais de comunicação com o mercado e terceirização do atendimento.
Telefonia Local
Ao mercado corporativo, a Empresa oferece um serviço completo de telecomunicações, 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á disponível em todo País, sendo uma opção para as empresas que desejam maior qualidade, confiabilidade e preço para o serviço de telefonia fixa.
Telefonia de Longa Distância
Ligações interurbanas, nacionais e internacionais, planos de tarifas corporativos e residenciais de acordo com o perfil de cada cliente e cartões pós-pagos e pré-pagos. O cliente residencial ou corporativo da Empresa conta com todas essas soluções, podendo falar com o Brasil e o mundo com mais qualidade e pagando menos.
Internet Residencial
Para o mercado residencial, a Empresa oferece a internet gratuita da Empresa, que garante qualidade de conexão e serviços, através de chamada telefônica local. Entre os benefícios oferecidos estão a conexão rápida, sem sinal de ocupado; suporte 24 horas; duas contas de e-mail por usuário, com até 30 Mb de armazenamento cada uma; antivírus; anti-spam; e links para os melhores sites disponíveis na Internet.
Satélites
Os satélites da Empresa podem receber e transmitir sinais de televisão, rádio, telefone, internet e dados para aplicações de entretenimento, telemedicina, teleducação, negócios, serviços essenciais para as comunidades distantes e atividades militares. Hoje, por exemplo, mais de 15 milhões de residências brasileiras assistem TV via satélite Empresa, de forma gratuita. Como serviços complementares para criação de redes ou emissoras independentes de TV e outros grupos de comunicação, a Empresa oferece as mais variadas opções de contratação, larguras de banda e tecnologias.
4.1.2 Estrutura Organizacional do CLIENTE
Figura 4 – Organização matricial fraca Fonte: PMI [2004:30]
Apesar de estar em fase de restruturação – devido a sua “recente” compra pela atual Empresa Controladora –, o CLIENTE ainda pode ser considerado como uma organização matricial fraca. Entretanto, para o Projeto de Transição dos Ambientes Críticos para o CT do FORNECEDOR, foi montada uma estrutura mais projetizada para facilitar o gerenciamento deste projeto e da integração 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 informação. Em 2004, foi considerada a nona maior corporação dos Estados Unidos e no final de 2003, o FORNECEDOR possuía mais de 319.000 funcionários atendendo os seus clientes em 160 países ao redor do mundo.
O FORNECEDOR chegou no Brasil em 1917. Montou sua primeira fábrica, em Benfica (RJ), em 1939 e, posteriormente, em Sumaré (SP), em 1971. Hoje, a Empresa no Brasil, possui cerca de 15.000 funcionários.
Principais linhas de Negócio:
- Serviços de Consultoria de Negócios - Serviços de Tecnologia Integrada - Serviços de Outsourcing Estratégico - Serviços de Gerenciamento de Aplicação
- Serviços de Hospedagem de Negócios Eletrônicos (e-Business Hosting) - Venda e Manutenção de Hardware Proprietário
4.2.2 Estrutura Organizacional do FORNECEDOR
Figura 5 – Organização composta Fonte: PMBOK [2004:31]
O FORNECEDOR sempre trabalhou de forma composta e projetizada no que tange aos clientes da área de Outsourcing Estratégico. Desta forma, é possível maior sinergia entre as equipes e gerentes – de transição e ongoing – durante a fase de transição de ambientes críticos para o CT, bem como a posterior manutenção e garantia da qualidade de continuidade do que foi efetivamente migrado.
4.3 Contrato de outsourcing do CLIENTE com o FORNECEDOR
Visando à redução dos custos com TI, em abril de 2003, o CLIENTE fechou com o FORNECEDOR Brasil, um contrato de outsourcing com duração de dez anos, com compra de ativo – servidores, storages, equipamentos de rede etc. Em junho de 2003, todos os funcionários de TI do CLIENTE foram submetidos a uma entrevista com o FORNECEDOR, sendo que parte deles não foi aproveitada – nem pelo CLIENTE nem pelo FORNECEDOR –, parte foi terceirizada e apenas uma pequena parte foi admitida pelo FORNECEDOR – obviamente funcionários-chave que foram apontados pelo CLIENTE, para a plena continuação dos serviços de TI, devido à senioridade e profundo conhecimento do ambiente.
4.3.1 Resumo do Escopo do Contrato - Transferência de ativos
- Atualização do parque tecnológico - Serviços de Data Center
- Serviços “Mainframe”
- Gerência de Servidor Mainframe - Gerência de Storage Mainframe
- Gerência de Banco de Dados Mainframe - Gerência de Infra-Estrutura de Data Center
- Especificação das Métricas de Níveis Base (volumetria) - Métricas de Níveis Base (volumetria)
- Especificação das Métricas de Níveis de Serviços - Métricas de Níveis de Serviços
- Serviços “Midirange”
- Gerência do Servidor Midirange - Gerência de Storage Mainframe
- Gerência de Banco de Dados Midirange - Gerência de Infra-Estrutura de Data Center
- Especificação das Métricas de Níveis Base (volumetria) - Métricas de Níveis Base (volumetria)
- Especificação das Métricas de Níveis de Serviços - Métricas de Níveis de Serviços
- Serviço de Manutenção de Hardware
- Manutenção de Hardware de Servidores - Manutenção de Hardware de Storage
- Manutenção de Hardware de Equipamentos de Rede - Serviços de Gerência de Rede
- Métricas de Níveis Base (volumetria)
- Especificação das Métricas de Níveis de Serviços - Métricas de Níveis de Serviços
- Controle do Gerenciamento de Sistemas (SMC) - Gerência de Problemas
- Gerência de Situações Críticas - Gerência de Mudanças
- Gerência de Capacidade e Performance - Gerência de Configuração
- Gerência de Segurança
- Gerência de Níveis de Serviços
- Suporte de Infra-Estrutura de TI a Demandas Adicionais - Especificação das Métricas de Níveis Base (volumetria) - Métricas de Níveis Base (volumetria)
- Especificação das Métricas de Níveis de Serviços - Métricas de Níveis de Serviços
- Interação com o Help-Desk do CLIENTE - Gerência de Chamados
- Administração de Usuários
- Matrizes de Criticidade de Sistemas e Severidades - Matriz de Criticidade de Sistemas
- Matriz de Severidades
- Matriz de Escalonamento de Problemas - Projeto Migração dos Servidores (Ambientes Críticos)
- Projeto Absorção de Produções
No final de 2004, o CLIENTE – já controlada por uma empresa multinacional – negociava um aditivo de contrato com redução de escopo, visando insourcing (retomada) de algumas áreas.
4.3.2 Estrutura Hierárquica do FORNECEDOR para o CLIENTE
Figura 6 – Organograma de On-Going Fonte: O Autor
Descrição dos Cargos apresentados na Figura 5 (estrutura hierárquica do FORNECEDOR dentro do CLIENTE) :
Project Executive (PE) – Posto maior da estratura hierárquica do
FORNECEDOR dentro do CLIENTE. O PE é o Executivo responsável pela parte financeira do contrato.
Delivery Project Executive (DPE) – Executivo responsável pela entrega do
produto ao CLIENTE, garantindo as métricas e SLA’s de acordo com o contrato de
outsourcing vigente.
Human Resource Manager – Gerente de recursos humanos dentro do
CLIENTE. Os usuários do FORNECEDOR podem ter um gerente de recursos humanos diferente do seu gerente funcional ou esses papéis podem ser acumulados numa única pessoa.
Project Managers – Gerentes de projetos responsáveis pelo gerenciamento
dos projetos internos demandados pelo CLIENTE. Respondem diretamento ao DPE e intereragem com os gerentes funcionais para alocação de recursos.
Production Manager – Gerente responsável pela produção do cliente que foi
absorvida pelo FORNECEDOR, garantindo que todos os processos sejam controlados
Project Executive Project Executive Delivery Project Executive Delivery Project Executive Production Manager
Production Manager Support ManagerSupport Manager
Support Coordinator Support Coordinator
Paulo Toledo Windows Team Leader
Paulo Toledo Windows Team Leader Unix Team Leader
Unix Team Leader Oracle Team LeaderOracle Team Leader
Notes Team Leader
Notes Team Leader Mainframe Team LeaderMainframe Team Leader Human Resource Manager Human Resource Manager Field Service Coordinator Field Service Coordinator Project Managers Project Managers Project Executive Project Executive Delivery Project Executive Delivery Project Executive Production Manager
Production Manager Support ManagerSupport Manager
Support Coordinator Support Coordinator
Paulo Toledo Windows Team Leader
Paulo Toledo Windows Team Leader Unix Team Leader
Unix Team Leader Oracle Team LeaderOracle Team Leader
Notes Team Leader
Notes Team Leader Mainframe Team LeaderMainframe Team Leader Human Resource Manager Human Resource Manager Field Service Coordinator Field Service Coordinator Project Managers Project Managers
e documentados. Normalmente, é o responsável pelo controle de acesso físico ao
Data Center do CLIENTE.
Support Manager – Gerente responsável pela áreas de suporte técnico e
serviço de campo. Responsável também pela confecção do Book (documento entregue mensalmente ao CLIENTE com todas as métricas, avaliações e dados estatísticos para o devido acompanhamento do que foi e do que deve ser melhorado; além das reflexões financeiras associadas a essas mudanças).
Field Service Coordinator – Responsável por coordenar o atendimento aos
usuários (incluindo os VIP’s) e pela atualização tecnológica do parque computacional do CLIENTE.
Support Coordinator – Responsável por coordenar as diversas equipes de
suportes (nível 3: servidores e situações críticas). Garantir que todos os processos de mudanças sejam documentados e aprovados (através de gerência de mudanças) antes de serem executados e que todos os chamados sejam atendidos de forma a manter o SLA acordado.
Team Leader – Líder do seu time de suporte. Responsável pelo planejamento
e soluções técnicas para melhoria do ambiente, e soluções corretivas, em casos de situações críticas. Acompanhamento e orientação nas atividades desempenhadas por sua equipe.
5
O PROJETO DE TRANSIÇÃO
5.1 Compreensão do Ambiente do Projeto
Em maio de 2005, foi emitido e assinado um apêndice do termo aditivo ao contrato de prestação de serviços com o CLIENTE – celebrado em março de 2003 – que trata especificamente do Projeto de Movimentação 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 idéia é 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 Hierárquica do FORNECEDOR para o Projeto de Transição
Figura 7 – Organograma de Transição Fonte: O Autor
Descrição dos Cargos apresentados na Figura 6:
Transition Manager – Gerente de projeto responsável pelo projeto como todo.
Atua em nível executivo e operacional, se relacionando com o CLIENTE, com o DPE da conta e com a gerência do CT (na qual receberá e será responsável pela manutenção dos ambientes migrados).
Project Executive Project Executive
Transition Manager Transition Manager
Project Managers
Project Managers PMO & QAPMO & QA Support ManagerSupport Manager
Paulo Toledo Intel Solution Architect
Paulo Toledo Intel Solution Architect Unix Solution Architect
Unix Solution Architect Logistic SupportLogistic Support
Backup Solution Architect Backup Solution Architect Technical Manager Technical Manager Delivery Project Executive Delivery Project Executive Production Manager Production Manager Project Executive Project Executive Transition Manager Transition Manager Project Managers
Project Managers PMO & QAPMO & QA Support ManagerSupport Manager
Paulo Toledo Intel Solution Architect
Paulo Toledo Intel Solution Architect Unix Solution Architect
Unix Solution Architect Logistic SupportLogistic Support
Backup Solution Architect Backup Solution Architect Technical Manager Technical Manager Delivery Project Executive Delivery Project Executive Production Manager Production Manager
Project Managers – Gerentes de projetos exclusivos para o gerenciamento
dos ambientes a serem migrados. Cada ambiente pode ser considerado como um projeto.
PMO & QA – Responsável por auxiliar os gerentes de projetos. Compartilha a
execução das tarefas de planejamento e acompanhamento.
Logistic Support – Responsável pelo suporte logístico de todos os projetos de
migração. Atua diretamento com os GP’s e com o Gerente Técnico.
Technical Manager – Responsável pelo revisão técnica das soluções dadas
pelos Arquitetos de Solução; auxílio na resolução de pendências técnicas e gerenciamento de alocação dos recursos técnicos para os GP’s, de forma a não impactar as atividades de projetos que estejam acontecendo paralelamente.
Solution Architect – Responsável técnico pelo planejamento e desenho da
solução a ser adotada para a migração do ambiente, devendo prever os riscos técnicos e suas mitigações, elaborar a estratégia de migração (contemplando contingência), especificar os equipamentos a serem comprados e confeccionar documentos técnicos (detalhamento técnico das atividades, plano de movimentação, plano de comuniacação) para auxiliar a migração e confecção/revisão de SOW junto ao GP.
5.3 Ambientes Críticos
Relação dos ambientes que fazem parte do Projeto de Transição:
Tabela 1 – Ambientes Contemplados na Transição
ILR1 CACTRE SITEF
BILT0 SIEBEL PRD COPROG
CDS SIEBEL CCE CORPORATIVO SP INTEL (SD2000 e SVA
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, porém adaptada para a realidade de cada ambiente. Para
a maioria dos ambientes, este documento foi elaborado contendo a seguinte abordagem:
Capítulo 1 – Informações sobre o Documento Fonte do Documento
Propósito
Histórico das Atualizações Aprovações
Distribuição
Capítulo 2 – Identificação, Objetivo e Premissas do Projeto Identificação do Projeto
Gerente FORNECEDOR do Projeto Gerente CLIENTE do Projeto Objetivo
Premissas
Estrutura de Decisão do Projeto Capítulo 3 – Solução
Descrição da Solução
Arquitetura do Ambiente Atual Arquitetura do Ambiente Final
Mecanismos de Comunicação Intersistemas
Componentes Liberados após a Movimentação dos Ambientes Solução de Backup para o Ambiente
Abordagem
Fases da Movimentação dos Servidores
Estratégia de Cópia do Ambiente Produtivo para “Bolha” – Homolog.
Estratégia de Cópia do Ambiente Produtivo para “Bolha” –
Pré-Cutover
Contingência nos Casos de Desastre
Estratégia para Recuperação de Processamento Retido Etapas de Implementação da Solução
Elaboração e Validação do Planejamento Detalhado de Movimentação dos Servidores
Contrução do Ambiente Bolha
Instalações e Configurações no Ambiente Bolha
Cópia de Dados no Ambiente Biolha para Homologação Transporte dos Equipamentos
Homologação Final e Migração da Produção (Cutover)
Fallback – Recuperação do Ambiente de Produção Original
Capítulo 4 – Planejamento
Datas-objetivo de Início e Término do Projeto Macro-Cronograma
Observações Complementares Capítulo 5 – Gerenciamento de Risco
Introdução sobre os Riscos
Resumo da Estratégia de Movimentação Legenda e Nomenclatura
Critério para Avaliação da Severidade Estratégia para Tratamento de Riscos Riscos para o Negócio
Riscos para o Projeto
Após ter dado início 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 APÊNDICE A, explora detalhadamente a estrutura acima mencionada.
6
CONCLUSÕES E PROPOSIÇÕES
Após análise 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, porém nem todas as ferramentas; tendo em vista um grande aproveitamento das lições aprendidas de projetos mais complexos anteriormente realizados. Dentre as ferramentas que não foram utilizadas, pode-se destacar duas técnicas: Delphi (utilizada na Identificação de Riscos), devido a pouca quantidade de especialistas envolvidos e poucas divergências de opiniões; e a Árvore de Decisão (utilizada na Análise Quantitativa de Riscos e Técnicas de Modelagem).
Baseado na metodologia do CobiT – em Governança de TI –, pode-se dizer que este projeto utilizou quase todos os tópicos apresentados nos Fatores Críticos de Sucesso e nos Indicadores Chaves de Objetivos. Porém, fez utilização parcial dos Indicadores Chaves de Desempenho. Quanto à Maturidade, considero que o projeto tenha alcançado o nível 5 (Otimizado), mas em função da aplicação da Metodologia do PMI.
É notório, porém convém salientar que o gerenciamento de riscos quando bem realizado é fator crítico e decisivo para a obtenção do sucesso de qualquer projeto.
Esse trabalho de conclusão objetivou não somente a análise de riscos do estudo de caso de um determinado projeto realizado com sucesso, através da aplicação da metodologia do PMI para gerenciamento de projetos; mas despertar e ressaltar, para as organizações, suas gerências e demais stakeholders, especialmente na área de TI, a importância do conhecimento – mesmo que básico – da utilização de, pelo menos, uma metodologia cujo gerenciamento de riscos seja bem aplicado. Não discriminando e sim dando valor à importância das demais áreas de conhecimento dessa metodologia, mas ao meu ver, o Gerenciamento de Riscos é uma das mais difíceis e importantes áreas de conhecimento, pelo simples fato de lidar com as incertezas; apesar de todas as técnicas e ferramentas atualmente disponíveis para identificar e minimizar os riscos.
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 Múltiplos Projetos; - Maturidade em Gerenciamento de Projetos.
Um estudo mais detido de livros como “Risk Management Tricks of the Trade” – de Rita Mulcahy, “Project Manager’s 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 auxílio para pesquisadores de Gerenciamento de Riscos e Gerenciamento de Riscos em TI, tendo em vista seu forte conteúdo técnico.
REFERÊNCIAS BIBLIOGRÁFICAS
ALENCAR, Antonio Juarez; SCHMITZ, Eber Assis. Análise de Risco em Gerência de Projetos. São 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. Capacitação em Gerenciamento de Projetos: Guia de Referência Didática. Rio de Janeiro: Brasport, 2004. Cap.1, p.9, Cap. 3, p. 35 – 37.
REFERÊNCIAS ELETRÔNICAS
BELLOQUIM, Átila. Riscos de Projetos. O que fazer com eles? Disponível em http://www.gnosisbr.com.br/artigos/AB0009.html. Acessado em 25/02/06.
GALVES, José Wanderlei Gava. Planos de Contingência em TI. Disponível 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. Disponível 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 Organização. Disponível em
http://www.pmirs.org.br/PMI-RSJournal/PMI-RSJournalNro09.pdf. Acessado em 21/05/06.
RIBEIRO, Marco Antônio Kappel. Palestra do PMI-RS. Disponível 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. Disponível em
http://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/
Projeto Movimentação do
Ambiente TELACORE para o CT
Especificação do Projeto
APÊNDICE A
Gerente do Projeto: Charles Leal Departamento: Strategic Outsourcing Telefone: +55 21 99XX -9999 Internet: [email protected]
Versão: 1.0 Última Revisão em: 29/jun/2005 Impresso em: 29/jun/2005
CAPÍTULO 1 – INFORMAÇÕES SOBRE O DOCUMENTO Fonte do Documento
Este documento é mantido como um documento online. Contate o autor para ter acesso à última versão atualizada.
Histórico das Atualizações
# Versão Data da Versão Conteúdo Atualizado
1.0 29/06/2005 Criação do documento
Aprovações
Nome Função Data
Aprovação E-Mail Telefone
Arnaldo Machado Gerente de Projeto CLIENTE [email protected] (21) 20XX 2020 Débora Cardoso Gerente de Projeto CLIENTE [email protected] (21) 20XX 2021 Joaquim Cruz Gerente de Projeto FORNECEDOR [email protected] (21) 88XX 8888 Mário Gomes Gerente Técnico FORNECEDOR [email protected] (21) 78XX 1414 Charles Leal Gerente de Projeto FORNECEDOR [email protected] (21) 99XX 9999 Distribuição
Este documento foi distribuído para todas as pessoas relacionadas abaixo.
Nome Função E-Mail Telefone
Arnaldo Machado Gerente de Projeto
CLIENTE [email protected] (21) 20XX 2020 Débora Cardoso Gerente de Projeto
CLIENTE [email protected] (21) 20XX 2021 Joaquim Cruz Gerente de Projeto
FORNECEDOR [email protected] (21) 88XX 8888 Mário Gomes Gerente Técnico
FORNECEDOR [email protected] (21) 78XX 1414 Charles Leal Gerente de Projeto
FORNECEDOR [email protected] (21) 99XX 9999 Lima Duarte Gerende de Produção
FORNECEDOR [email protected] (19) 87XX 1234 Paulo Toledo Arquiteto de Solução
FORNECEDOR [email protected] (21) 99XX 2299 Rômulo Arantes PMO & QA
FORNECEDOR [email protected] (21) 22XX 4455 Moacyr Franco Executivo de Delivery
Livia Santana Gerente de Suporte
FORNECEDOR [email protected] (21) 31XX 3334 Gisele Castro Especialista de Sistemas
FORNECEDOR [email protected] (19) 23XX 4567 Laerte Lima DBA FORNECEDOR [email protected] (19) 77XX 6534
