plano de gerenciamento de projeto

Processo Organizacional

CBA EM GESTO DA TI - GERNCIA DE PROJETOS

Aloha :: Service Center Plano de Gerenciamento do ProjetoPalavras-chave: tecnologia, empresa,plano,gerenciamento, projetoFormaliza o desenvolvimento do plano de gerenciamento do projeto

INTEGRANTES DO GRIPO:

ANDRE PIAZI

CLAUDIO BAIL

JOO FELLIPE

LEANDRO MOREIRA

MARCELO MONTEIRO

Histrico do Template

VersoDataEscopoAutorRevisor

2.007/12/2010Segunda verso do documentoMarcelo MonteiroCludio Bail

Histrico do Documento

VersoDataEscopoAutorRevisor

Contedo

71.INTRODUO

71.1.Objetivo do Documento

71.2.Escopo do Documento

82.TERMO DE ABERTURA DO PROJETO

93.PLANOS DE GERENCIAMENTO DE PROJETO

93.1.PLANO DE GERENCIAMENTO DE ESCOPO

93.1.1.Objetivo do Projeto

93.1.2.Justificativas do Projeto

93.1.3.Produto do Projeto

93.1.4.Expectativa do Cliente

93.1.5.Fatores de Sucesso do Projeto

103.1.6.Descrio dos Processos de Gerenciamento de Escopo

103.1.7.Verificao e Aceite das Entregas do Projeto

103.1.7.1.Resumo

103.1.7.2.Verificao

113.1.8.Responsabilidades

123.1.9.Priorizao das mudanas de escopo e respostas

123.1.10.Procedimento de Gerncia de Mudanas

143.2.PLANO DE GERENCIAMENTO DO TEMPO

143.2.1.Descrio dos processos de gerenciamento de tempo

143.2.2.Priorizao das mudanas nos prazos

143.2.3.Sistema de controle de mudanas de prazos

153.2.4.Mecanismo adotado para o conciliamento de recursos

153.2.5.Buffer de tempo do projeto

153.2.6.Freqncia de avaliao dos prazos do projeto

163.2.7.Alocao financeira para o gerenciamento de tempo

163.2.8.Outros assuntos relacionados ao plano e no previstos no projeto

163.3.PLANO DE GERENCIAMENTO DE CUSTO

163.3.1.Objetivo

163.3.2.Restries de Custo

163.3.3.Estimativa de Custo

173.3.4.Custo dos Envolvidos

173.4.PLANO DE GERENCIAMENTO DA QUALIDADE

173.4.1.Objetivo

173.4.2.Planejamento da Qualidade

183.4.3.Garantia da Qualidade

183.4.4.Padres e Mtricas de Qualidade

193.4.5.Controle da Qualidade

193.4.6.Procedimentos e Processos

193.5.PLANO DE GERENCIAMENTO DE RISCOS

193.5.1.Descrio dos processos de gerenciamento de riscos

203.5.2.RBS Risk Breakdown Structure para a identificao dos riscos

203.5.3.Anlise Swot

213.5.4.Riscos Identificados

213.5.5.Qualificao dos riscos

233.5.6.Quantificao dos riscos

233.5.7.Respostas planejadas aos riscos

253.5.8.Sistema de controle de mudanas de riscos

253.5.9.Alocao financeira para o gerenciamento de riscos

263.6.PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS

263.6.1.Organograma do projeto

263.6.2.Diretrio do time do projeto

273.6.3.Matriz de responsabilidades

273.6.4.Novos recursos, re-alocao e substituio de membros do time

273.6.5.Treinamento

273.6.6.Avaliao de resultados do time do projeto

283.6.7.Freqncia de avaliao consolidada dos resultados do time

283.6.8.Alocao financeira para o gerenciamento de RH

283.6.9.Outros assuntos relacionados ao plano e no previstos no projeto

283.7.PLANO DE GERENCIAMENTO DE COMUNICAES

283.7.1.Descrio dos processos de gerenciamento das comunicaes

293.7.2.Eventos de Comunicao

313.7.3.Intranet

313.8.PLANO DE GERENCIAMENTO DE AQUISIES

313.8.1.Objetivo

313.8.2.Gerenciamento e tipos de contratos

313.8.3.Critrios de avaliao de cotaes e propostas

323.8.4.Avaliao de fornecedores

323.8.5.Freqncia de avaliao dos processos de aquisies

323.8.6.Alocao financeira para o gerenciamento das aquisies

324.DOCUMENTOS AUXILIARES

324.1.Declarao de Escopo do Projeto

324.1.1.Objetivo do Projeto

334.1.2.Designao do Gerente do Projeto

334.1.2.1.Responsabilidades

334.1.2.2.Autoridades

334.1.3.Riscos Iniciais do Projeto

344.1.4.Limites de Projeto

344.1.5.Premissas

344.1.6.Restries

344.1.7.Stakeholders

354.2.Levantamento de Requisitos

354.2.1.Viso Geral do documento

354.2.2.Identificao dos requisitos

354.2.3.Prioridades dos requisitos

364.2.4.Critrios de Aceitao

364.2.5.Requisitos Funcionais

404.2.6.Requisitos No Funcionais

434.2.7.Migrao de dados

434.2.8.Operao assistida

444.3.EAP e Dicionrio

444.3.1.Estrutura Analtica do Projeto (EAP)

444.3.2.Dicionrio da EAP

504.4.Cronograma Sumarizado

504.5.Modelo de Cronograma de Gantt

514.6.Matriz de Rastreabilidade

514.7.Gerenciamento de Partes Interessadas

524.8.Declarao de Trabalho

55APROVAES

1. INTRODUO

Objetivo do Documento

A finalidade deste documento coletar as informaes bsicas de uma solicitao de uma rea cliente da TI da empresa Aloha que permita a abertura, consulta, direcionamento e fechamento de tickets de solicitaes de demandas de suporte TI permitindo que toda e qualquer solicitao seja criada, monitorada e finalizada de acordo com a estrutura de atendimento definida para tal.

Este documento passar por vrios status, at que seja possvel a deciso final de seleo e priorizao do projeto.

Escopo do Documento

Este documento marca o incio do projeto, apresentando uma identificao, descrio inicial do projeto (objetivos, justificativas e principais envolvidos), identificao os membros do Comit de Gesto e o estudo de viabilidade para o projeto, caso tenha sido elaborado. Apresenta ainda uma descrio inicial do produto, um macro-planejamento no que toca ao oramento liberado, os marcos desejados e recursos previamente alocados, bem como as premissas e restries do projeto.2. TERMO DE ABERTURA DO PROJETO

3. PLANOS DE GERENCIAMENTO DE PROJETO

3.1. PLANO DE GERENCIAMENTO DE ESCOPO3.1.1. Objetivo do Projeto

Este projeto tem por objetivo a instalao de uma mquina Extrusora PEBD para empresa Plsticos Ltda, visando adequar s polticas e diretrizes da empresa garantindo maior qualidade ao produto acabado oferecido pela empresa.3.1.2. Justificativas do Projeto

Foram identificadas as seguintes justificativas aderentes a este projeto:

Melhorar a linha de produo Realizar Gesto Integrada de TI alinhada com negcios

Aumentar a satisfao dos clientes Economizar tempo de produo Maximizar a produtividade com a utilizao de melhores prticas

Solucionar chamados de sistemas de vrios fornecedores3.1.3. Produto do Projeto

Mquina extrusora para fabricao de filme PEBD, proporcionando melhoria na qualidade do filme para fabricao de seus produtos. O que, por sua vez, resulta em sinergia entre reas de produo e apoio ao setor comercial da empresa.3.1.4. Expectativa do Cliente

Projeto em conformidade com o termo de abertura, dentro do prazo e do oramento previsto.

3.1.5. Fatores de Sucesso do Projeto

Comunicao efetiva dentro do time e suporte permanente do patrocinador.

3.1.6. Descrio dos Processos de Gerenciamento de Escopo

O gerenciamento do escopo do projeto ser realizado com base em dois documentos especficos: Declarao de escopo para o escopo funcional do projeto e EAP para o escopo das atividades a serem realizadas pelo projeto, com suas devidas entregas.

Todas as mudanas no escopo inicialmente previsto para o projeto devem ser avaliadas e classificadas dentro do sistema de controle de mudanas de escopo.

Todas as solicitaes de mudana no escopo devem ser feitas por escrito ou atravs de e-mail, conforme descrito no plano de comunicaes do projeto.3.1.7. Verificao e Aceite das Entregas do Projeto

3.1.7.1. Resumo

Cada um dos Marcos descritos, conforme item Declarao de Escopo, deve estar associado ao aceite formal por parte da CONTRATANTE, emitida pelo Gerente do Projeto Marcelo Monteiro.

A aceitao formal, item Calendrio das Datas de Entrega se realizar atravs da reviso das funcionalidades e performance.

de responsabilidade da CONTRATANTE proporcionar os recursos necessrios para a realizao conjunta com a CONTRATADA das provas de aceitao, de acordo com o planejamento, cronograma e requerimentos especificados no documento de aceitao que se elabore para cada Marco.

Todos os Marcos descritos neste documento sero considerados aceitos aps assinatura do formulrio de Aceitao dos Principais Resultados pela CONTRATANTE. Este aceite dever ocorrer em at 10 (dez) dias teis; findo este prazo ser considerado, para todos os efeitos, como trabalho realizado e aceito.3.1.7.2. VerificaoUma vez efetuada a apresentao do Principal Resultado (Entrega), revisada a documentao associada (se aplicvel) e efetuadas as provas, deve ser formalizado o Aceite, mediante assinatura por parte da CONTRATANTE no(s) documento(s) de aceite(s) correspondente(s).Aps este Aceite, por escrito, ficam cumpridas todas as obrigaes da CONTRATADA relacionadas a este Principal Resultado. Se no prazo de 3 (trs) dias teis, uma vez realizada a entrega, a CONTRATANTE, no expressar sua No-Conformidade com o Marco, a CONTRATADA considerar aceita a entrega para todos os efeitos, no cabendo nenhum tipo de reclamao por parte da ALOHAA falta do Aceite ou No-Conformidade implicar em atraso das atividades dependentes programadas. A sua falta implica que nenhuma outra atividade poder ser desenvolvida. O Cronograma do Projeto dever ser reprogramado em funo da falta deste Aceite ou No-Conformidade, bem como todas as demais atividades relacionadas. Eventuais prejuzos em funo deste atraso sero cobrados da CONTRANTANTE.3.1.8. ResponsabilidadesCONTRATADATem as seguintes responsabilidades no processo de aceitao:

Garantir a disponibilidade dos elementos necessrios para a realizao das provas de aceitao e reviso dos Marcos nos prazos acordados conforme planejamento neste Plano de Projeto.

Elaborar os documentos de especificao das provas de aceitao.

Executar em conjunto com a CONTRATANTE as provas de aceitao;

Apresentar os documentos de aceitao dos Principais Resultados;

Apresentar os documentos de Gerncia de Mudanas; e

Participar na reviso, em conjunto com CONTRATANTE dos documentos entregues, quando aplicvel.ALOHA

Tem as seguintes responsabilidades no processo de aceitao:

Garantir a disponibilidade dos elementos necessrios para a realizao das provas de aceitao e reviso dos Principais Resultados nos prazos acordados conforme planejamento neste Plano de Projeto.

Executar, em conjunto com a CONTRATADA, as provas de aceitao apresentadas.

Revisar os documentos entregues pela CONTRATADA no prazo definido no planejamento.

Revisar e assinar os documentos de aceitao dos Principais Resultados.

Revisar e assinar os documentos de Gerncia de Mudanas.

Intermediar entre a Equipe da CONTRATADA e os membros de todos os outros departamentos/setores da CONTRATANTE que estejam diretamente ou indiretamente relacionados ao projeto, para a soluo de dvidas, se existentes.

Ter autoridade para tomar decises sobre algum ponto do projeto quando requisitado pela CONTRATADA.

Aceitar o projeto.3.1.9. Priorizao das mudanas de escopo e respostas

Prioridade 0 (zero) Mudanas de prioridade zero requerem uma ao imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador, uma vez que se trata de mudana urgente, de alto impacto no projeto e em outras reas sobre as quais o gerente de projeto no tem autonomia.

Prioridade 1 (um) - Mudanas de prioridade um requerem uma ao imediata por parte do gerente do projeto, independente das reunies de controle previstas devido urgncia, acionando imediatamente o patrocinador no caso de necessidade de autorizaes financeiras fora da alada do gerente de projetos.

Prioridade 2 (dois) Mudanas de prioridade dois requerem um planejamento da ao atravs de terceiros ou de equipes que, a princpio, tenham disponibilidade, uma vez que agregam valor ao sucesso do projeto e so urgentes, porm no tm impacto significativo nos custos e nos prazos do projeto.

Prioridade 3 (trs) Mudanas de prioridade trs podem ser implementadas por terem influncia no sucesso do projeto, porm no requerem uma ao imediata por no serem impactantes ou urgentes.3.1.10. Procedimento de Gerncia de MudanasCaso seja necessrio solicitar alguma mudana ao projeto, esta solicitao dever ser encaminhada em forma de uma Necessidade de Mudana ao Gerente do Projeto, o qual ser o responsvel por dar o andamento apropriado para avaliao e implementao da mudana, em caso de aprovao.

3.2. PLANO DE GERENCIAMENTO DO TEMPO3.2.1. Descrio dos processos de gerenciamento de tempo

Todas as solicitaes e correes de mudanas sero informadas atravs da Intranet.

Todas as alteraes de artefatos do projeto deveram ser disponibilizadas ao final de cada dia na Intranet.

Uma vez por semana, ser realizada uma baseline do projeto.

3.2.2. Priorizao das mudanas nos prazos

As mudanas nos prazos so classificadas em quatro nveis de prioridade:

Prioridade 0(Zero) Atrasos de prioridade zero requerem uma ao imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador para discusso e anlise, uma vez que um problema urgente, de alto impacto no projeto e com solues inicialmente no identificadas.

Prioridade 1(Um) Atrasos de prioridade um requerem uma ao imediata por parte do gerente do projeto, independente das reunies de controle previstas devido urgncia, acionando as medidas de recuperao de prazos disponveis, tais como o Fast Tracking, o Crashing, o trabalho em horas-extras, banco de horas e mutiro. Os custos que por ventura decorrerem dessas aes dever ser alocado nas reservas gerenciais, conforme descrito a seguir.

Prioridade 2(Dois) Atrasos de prioridade dois requerem um replanejamento das atividades futuras, uma vez que o projeto ainda no completou 25% de concluso.

Prioridade 3(Trs) - Atrasos de prioridade trs so atrasos pequenos se comparados com a durao do projeto e podem ser remanejados sem necessariamente ser preciso planejar novamente ou acionar algum tipo de mecanismo de recuperao.

3.2.3. Sistema de controle de mudanas de prazos

A verificao da utilizao do recurso ser realizada aps terem sido concludos os clculos da durao das atividades, da alocao de recursos e os inter-relacionamentos entre as atividades. O processo ir verificar se nenhum recurso est alocado em quantidade superior ao limite Maximo disponvel para aquele perodo.

3.2.4. Mecanismo adotado para o conciliamento de recursos

Utilizaremos de mecanismos prprios para conciliamento de recursos, de forma que como base para determinarmos a prioridade de um dado recurso em relao a outros ser devido a necessidade do projeto, neste caso a escolha dos recursos ser avaliada por todos os principais integrantes para caso seja ou no includa no escopo deste projeto.

3.2.5. Buffer de tempo do projeto

O projeto prev a criao de uma margem de atraso no trmino do projeto de 10% do tempo total do projeto (previsto para quatro meses).

3.2.6. Freqncia de avaliao dos prazos do projeto

Os prazos do projeto devero ser atualizados e avaliados semanalmente, sendo os resultados publicados na intranet.

3.2.7. Alocao financeira para o gerenciamento de tempoDependendo do nvel de influncia da mudana, poder refletir tambm no custo total do projeto, de forma que isso ser validado pelo nvel de 0 (zero) a 5 (cinco) como foi apresentado antes.

3.2.8. Outros assuntos relacionados ao plano e no previstos no projetoTodas as solicitaes no previstas neste plano devem ser submetidas s prximas reunies pr-estabelecidas no calendrio do projeto para sua devida apreciao e aprovao. Caso haja sua aprovao, deve ser atualizada no plano de gerenciamento do tempo com seu devido registro de alterao.

3.3. PLANO DE GERENCIAMENTO DE CUSTO3.3.1. Objetivo

Este plano tem por objetivo definir as diretrizes gerais para o acompanhamento dos custos do projeto Service Center.3.3.2. Restries de Custo

Os funcionrios da contratante no podero atuar em tempo integral no projeto, to pouco efetuarem horas extras para trmino ou auxlio de tarefas, conforme restries descritas no termo de abertura do projeto.3.3.3. Estimativa de Custo

Para o clculo de custos desta etapa do projeto esto sendo levados em considerao os funcionrios que iro participar e dias trabalhados.Estimativas de custos das atividades:Fase: Contratao

Levantamento de Necessidades R$ 3.354,54 Licitao R$ 19.336,36

Seleo Prvia R$ 5.181,82

Seleo Final R$ 11.359,09

Fechamento do Contrato R$ 5.113,64

Critrios de reviso das estimativas de custos:

O Gerente do Projeto dever revisar as estimativas de custos 2 dias antes de cada nova etapa.

A faixa de variao da estimativa:

Podemos considerar aproximadamente quando a estimativa calculada no processo de iniciao um intervalo de -50% a +100%. Posteriormente durante o projeto, a estimativa pode ser refinada at aproximadamente um intervalo de -5% a +10%.3.3.4. Custo dos EnvolvidosCargosSalrioCusto dirioDiasCusto no Projeto

Diretor de TIR$ 22.500,00R$ 1.022,738R$ 8.181,82

Gerente de TIR$ 12.300,00R$ 559,0944R$ 24.599,96

Coordenador de Infra EstruturaR$ 6.000,00R$ 272,7328R$ 7.636,36

Analista de TI PlenoR$ 4.500,00R$ 204,5528R$ 5.727,27

Analista AdministrativoR$ 3.200,00R$ 145,457R$ 1.018,18

Gerente JurdicoR$ 10.000,00R$ 454,555R$ 2.272,73

Analista JurdicoR$ 2.200,00R$ 100,005R$ 500,00

Analista de RequisitosR$ 4.400,00R$ 200,0028R$ 5.600,00

TotalR$ 52.181,82

Informaes adicionais:- O oramento deve ser gerenciado de acordo com a linha de base de custos;

- Recalcular periodicamente a estimativa para o trmino do projeto;

- Considerar reserva para contingncias e reserva de gerenciamento.3.4. PLANO DE GERENCIAMENTO DA QUALIDADE3.4.1. Objetivo

Este documento visa estabelecer os modelos de qualidade utilizados como referncia para Projeto Service Center, tendo como objetivo principal definir e listar todas as atividades do controle da qualidade executadas neste projeto.3.4.2. Planejamento da Qualidade

Este documento se aplica em todo o ciclo de vida do projeto e obriga a todas as partes a respeitar as disposies nele descritas. Caso ocorram desvios no cumprimento das disposies aqui descritas, o fato dever ser relatado em reunio, seguindo as regras de escalonamento, para que seja discutido e acertado o ponto em questo.3.4.3. Garantia da Qualidade

Este documento ser utilizado durante todo o ciclo de vida do projeto e deve garantir que: Nenhum outro plano de qualidade ou nenhuma norma ou regra que entre em contradio com este plano, seja utilizada. Que os controles de qualidade se efetuem, primeiro, em relao a este documento, e a partir deste, com outros planos especficos.

Qualquer modificao necessria dever ser discutida em reunio e aprovada pelas partes envolvidas. Nenhuma alterao poder ser efetuada sem o conhecimento do responsvel pelo processo.

Toda solicitao de alterao deve ser informada ao Gerente do Projeto Caso seja identificado algo problema em qualquer fase do projeto, o mesmo dever ser informado ao Gerente de Projetos.

Realizar reunies dirias para verificar o andamento do projeto.3.4.4. Padres e Mtricas de QualidadeFaseRequisitosPadres

SOFTWAREO software a ser utilizado dever baixa necessidade de suporte tcnico. Suporte deve ser comprovado pelo fabricante de software do produto. Manual do usurio deve ser disponibilizado eletronicamente pelo fornecedor para todos os usurios.

SOFTWARESoftware dever ser de fcil e direta utilizao pelos usurios. Aps o treinamento, 100% dos funcionrios devem conseguir utilizar a soluo de Service Center para abertura e registro de chamados, e 75% dos usurios do sistema devem operar o mesmo, sem a necessidade de suporte.

SOFTWAREO software permite a escalabilidade futura da soluo. O software deve ser utilizado em menos de 20% do seu limite tcnico estabelecido.

HARDWAREO preo do hardware compatvel ao oramento disponibilizado. O custo do hardware no pode ultrapassar 70% do oramento total do projeto.

HARDWAREOs hardwares permitem a escalabilidade futura da soluo. O hardware deve ser utilizado em menos de 20% do seu limite tcnico estabelecido.

TREINAMENTOEquipe de suporte envolve todos os tcnicos que iro trabalhar com a soluo. Toda a equipe de TI alocada no projeto deve participar do treinamento.

PADRONIZAOSoftwares so de fcil e direta utilizao pelos usurios. Aps o treinamento, 75% dos usurios dos sistemas devem operar, sem a necessidade de suporte.

PILOTOPiloto tem envolvimento total das partes interessadas. O gerente do projeto e o patrocinador devem participar diretamente do piloto. Participao dos usurios estratgicos no processo deve ser comprovada de ata de reunio.

3.4.5. Controle da Qualidade

Os Controles Peridicos do projeto sero realizados pelo Gerente de Projeto e consiste na verificao de cronogramas, grficos de andamento das atividades, gesto de alerta, dificuldades tcnicas imprevistas, solicitaes de alterao de requisitos e riscos levantados.

Os objetivos de uma reviso de qualidade so: verificar se esto sendo aplicadas as orientaes estipuladas neste plano, se as metas e objetivos do projeto esto sendo cumpridos, se o cronograma est sendo cumprido e se os produtos esto sendo entregues conforme estipulado.3.4.6. Procedimentos e Processos

Durante o projeto poder surgir a necessidade de alguma alterao nos requisitos definidos e acordados. Estas alteraes podem ocorrer por solicitao dos principais Stakeholders (Cliente, Gerente de Projeto etc.).

Qualquer alterao de requisitos dever ser tratada por procedimento definido no plano de gerenciamento de escopo, no item relativo Controle de Mudanas.

O tempo para anlise de uma Solicitao de Alterao de Requisitos de cinco dias podendo variar conforme a complexidade da solicitao. Ultrapassado o prazo de cinco dias o Gestor de Requisitos dever repassar o caso ao Comit Diretor para que o mesmo faa o acompanhamento deste requisito.3.5. PLANO DE GERENCIAMENTO DE RISCOS3.5.1. Descrio dos processos de gerenciamento de riscos O gerenciamento de riscos do projeto ser realiazado atravs de um monitoramento e controle dos riscos identificados, e cujo impacto no projeto seja classificado como mdio ou alto.

Os riscos a serem identificados sero os riscos internos ao projeto e legislao vigente.

As respostas possveis aos riscos identificados pelo projeto sero aceitao ativa atravs de contingncias, mitigao e eliminao.

A identificao, avaliao e monitoramento de riscos sero efetuados atravs de reunies mensais entre o gerente de projeto, diretor de TI e Gerente de TI (Comit de Gesto de Riscos).3.5.2. RBS Risk Breakdown Structure para a identificao dos riscos3.5.3. Anlise SwotPontos Fortes

Software pronto, dependendo apenas de ajustes e adaptaes;

Software que atenda plenamente as necessidades da empresa, devido processo licitatrio;

Documentao do sistema.

Plataforma tecnologicamente moderna;

Interface grfica

Registro de todas as atividades desenvolvidasPontos Fracos

Maior burocracia na aquisio, devido aprocesso licitatrio e avaliaes tcnicas do software;

Menor poder de gesto das modificaes nosoftware, visto que o rgo possui diversas peculiaridades;

Tempo no acerto do software com fases deimplantao, testes e ajustes;

Possibilidade de desclassificar alguma empresa no qual possui software conhecido e confivel por no atender algum requisitodo edital;

Oportunidades

Possibilidade de integrao com outras aplicaes;

Possibilidade de disponibilizao de informaes pela internet;

Possibilidade de ampliar e sustentar novosservios;

Possibilidade de atendimento a novosrequisitos de negcios.

Ameaas

Possibilidade de contratao de empresa compouca experincia, devido a processo licitatrio;

3.5.4. Riscos Identificados

Os riscos identificados no projeto, segundo o WBS do projeto e a RBS anteriormente apresentada esto apresentados na estrutura a seguir

CONTRATADA

Mau planejamento, monitoramento e controles inadequados.TI

Identificao de requisitos que no atendam as necessidades do sistema

Atraso na disponibilizao da infra-estrutura para implantao da soluo adquirida

Aprovao total nos testes e homologaes da soluo contratadaADMINISTRATIVO

Extenso no prazo do projeto

Perda de recursos da equipe3.5.5. Qualificao dos riscos

Os riscos identificados sero qualificados na sua probabilidade de ocorrncia, impacto nos resultados e Perdas Esperadas de acordo com as duas qualificaes mencionadas anteriormente:

Probabilidade

Alta: Riscos evidentes ao projeto, cuja ocorrncia esperada curto prazo ou que possuam probabilidade de ocorrncia maior ou igual 50% em algum momento durante o projeto.

Mdia: Riscos identificados, para os quais esperado a ocorrncia em algum momento do projeto ou cuja probabilidade igual ou maior que 15% e menor que 50% ou desconhecida.

Baixa: Risco cujo impacto no tempo ou custo seja menor que 5% do tempo total do projeto respectivamente.

ProbabilidadeBaixaMdiaAlta

< 15%>= 15% e < 50%>= 50%

Impacto

Alto: Risco cujo impacto no tempo ou custo seja igual ou maior que 10% do tempo total do projeto respectivamente.

Mdio: Risco cujo impacto no tempo ou custo seja maior que 5% e menor que 10% do tempo total do projeto respectivamente. Baixo: Risco cujo impacto no tempo ou custo seja menor que 5% do tempo total do projeto respectivamente.ImpactoBaixaMdiaAlta

Tempo ou custo< 5%>= 5% e 10%

Perda Esperada dos Riscos

Alta: Riscos de alta prioridade, para os quais devem ser elaborados planos de mitigao e contingncia ao risco.

Mdia: Riscos de prioridade moderada, para os quais devem ser elaborados, pelo menos, planos de contingncia ao risco.

Baixa: Riscos de baixa prioridade, para os quais no so necessrios planos de resposta ao risco.

Perda EsperadaProbabilidade

BaixaMdiaAlta

ImpactoAltoMdiaAltaAlta

MdioBaixaMdiaAlta

BaixoBaixaBaixaMdia

3.5.6. Quantificao dos riscos

Os riscos identificados sero mensurados atravs do mtodo de Valor Monetrio Esperado (VME), o qual visa a multiplicao da probabilidade do evento ocorrer, com seu grau de impacto estabelecido, gerando assim a quantificao do risco identificado.

O VME para cada risco encontra-se descrito no prximo item do nosso plano de gerenciamento de risco

3.5.7. Respostas planejadas aos riscos

Para todos os riscos identificados no projeto, a estratgia de resposta ser definida seguindo os critrios abaixo:

Riscos de perda esperada baixa no demandam o planejamento de respostas, sendo assim so classificados como estratgia de aceitao passiva;

Riscos de perda esperada mdia demandam, pelo menos, o planejamento de aes de contingncia, portanto so classificados como estratgia de aceitao ativa;

Riscos de perda esperada alta, devido a sua prioridade, demandam de, pelo menos, aes de mitigao e contingncia, portanto so classificados como estratgia de mitigao, transferncia ou eliminao;

Perda EsperadaEstratgia

BaixaAceitao Passiva

MdiaAceitao Ativa ou Transferncia

AltaMitigao ou Eliminao

Para os riscos identificados e qualificados, optou-se por estratgias diferenciadas para cada necessidade, conforme quadro a seguir.

RiscoProbabilidadeImpactoResposta / EstratgiaDescrioCustoCom o tempo

Mau planejamento, monitoramento e controle inadequados14%10%TransfernciaUtilizar mtricas e monitoramento da empresa contratanteR$ 4,650.00

Identificao de requisitos que no atendam as necessidades do sistema55%60%EliminaoRealizar reviso e validao dos requisitos levantados junto todos os envolvidos do projeto.R$ 28,000.00[Agrava, atenua, etc.]

Atraso na disponibilizao da Infraestrutura10%8%Aceitao AtivaUtilizao de ambiente externo at viabilidade da Infra da empresaR$ 3,720.00[Agrava, atenua, etc.]

Perda de Recursos15%10%MitigarCriao de Plano de Cargos e Salarios;

Ampliao de benefcios;

R$ 2,330.00

Extenso no prazo do projeto30%20%MitigarAlocar mais recursos no projeto utilizando reserva de contignciaR$ 9,300.00[Agrava, atenua, etc.]

Aprovao total nos testes e homologaes da soluo contratada

20%10%Aceitao AtivaReduo no prazo do projetoR$ 4,650.00

O clculo do VME do projeto com riscos foi feito da seguinte forma:

RiscoProbabilidadeImpactoVME

Mau planejamento, monitoramento e controle inadequados14% R$4,650.00 R$651.00

Identificao de requisitos que no atendam as necessidades do sistema55% R$28,000.00 R$15,400.00

Atraso na disponibilizao da Infra-estrutura10% R$3,720.00 R$372.00

Perda de Recursos15% R$4,650.00 R$698.00

Extenso no prazo do projeto30% R$9,300.00 R$2,790.00

Aprovao total nos testes e homologaes da soluo contratada20% R$(4,650.00) R$(930.00)

VME TOTAL: R$18,981.00

Anlise dos custos

Valor base custo do projeto R$46,500.00

Riscos - Ameaas R$19,911.00

Riscos - Oportunidades R$(930.00)

VME do projeto com risco R$65,481.00

VME do projeto - Melhor caso R$45,570.00

VME do projeto - Pior caso R$96,820.00

3.5.8. Sistema de controle de mudanas de riscos

Os riscos do projeto sero reavaliados em reunies do comit de gesto de riscos com periodicidade semanal, toda quinta-feira das 10:00 s 12:00. Este comit ser composto pelo Gerente do Projeto (Marcelo Monteiro), Diretor de TI (Claudio Bail) e Gerente de TI (Leandro Henriques).

Aps cada reunio, o Gerente de TI ficar responsvel por documentar as possiveis mudanas de riscos. A aprovao do documento ficar sob responsabilidade do Diretor de TI.

Todos os membros da equipe do projeto podero sinalizar um risco dentro do mesmo, porm caber ao comit de gesto de risco a sua anlise e aceitao dentro do projeto. 3.5.9. Alocao financeira para o gerenciamento de riscos

O plano de gerenciamento de risco utilizar 18% do custo total do projeto, tendo como base as reunies do comit de gesto de riscos para anlise dos mesmos, bem como o custo utilizado nas respostas planejadas para os riscos identificados.

3.6. PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS3.6.1. Organograma do projeto

3.6.2. Diretrio do time do projeto

NoNomereae-mailTelefone

1Marcelo MonteiroGerente de [email protected]

2Leandro HenriquesGerente de [email protected]

3Andr [email protected]

4Joo FelipeAnalista de Suporte [email protected]

5Claudio BailDiretor de [email protected]

6Claudio ClinkGerente [email protected]

7Jorge BenGerente [email protected]

3.6.3. Matriz de responsabilidadesNoNomereaLevantamento de NecessidadeSeleo PrivaFechamento do ContratoPlanos

LicitaoSeleo FinalEscopoTempoCustoQualidadeRHComunicaoRiscosSuprimentos

1Marcelo MonteiroGerente AAAAARAARARAR

2Leandro HenriquesTIRCRR--RCCIAA-

3Andre PiazziTI C------------

4Joo FelipeTIC-------I----

5Claudio BailTIC---- A-- A C I R-

6Claudio ClinkAdministrativoIRRR---AR---

7Jorge BenGerente JuridicoIRRR---RC---

R Responsvel A Reportar-se C Consultoria I - Informar

3.6.4. Novos recursos, re-alocao e substituio de membros do timeO Gerente do Projeto deve coordenar os recursos humanos e materiais, manter a equipe concentrada no processo de desenvolvimento do sistema, estar atento aos possveis riscos que possam ocorrer, bem como, fazer uma anlise dos resultados alcanados.

3.6.5. Treinamento

O Treinamento ser feito pela empresa contratada, sendo da Gerncia de TI a escolha dos participantes do treinamento, os quais sero os responsveis por manipular e administrar o sistema de Service Desk

3.6.6. Avaliao de resultados do time do projeto

Os resultados sero avaliados atravs do envio dos relatrios de atividades concludas, e de reunies entre os membros do projeto e o Patrocinador.

Em cada reunio ser elaborado um documento contendo as informaes sobre o andamento do projeto, possveis ajustes e avaliaes individuais de cada membro da equipe, e principalmente a opinio e avaliao do GP frente ao que j foi executado.3.6.7. Freqncia de avaliao consolidada dos resultados do timeOs resultados da freqncia de avaliao sero apresentados em reunies com o time, e divulgadas na intranet da empresa para que todos fiquem cientes dos resultados obtidos pela equipe.

3.6.8. Alocao financeira para o gerenciamento de RH

Os gastos de recursos humanos adicionais devem ser alocados dentro da reservas gerenciais do projeto, desde que seja de responsabilidade do gerente do projeto. Caso no exista mais reserva gerencial o patrocinador do projeto ou cliente deve ser comunicado para arcar com as despesas

3.6.9. Outros assuntos relacionados ao plano e no previstos no projetoTodas as mudanas no quadro de gerenciamento de Recursos Humanos devem ser comunicadas em reunio ao gerente do projeto, sendo os mesmos o responsvel pela avaliao e aprovao das mudanas propostas.3.7. PLANO DE GERENCIAMENTO DE COMUNICAES3.7.1. Descrio dos processos de gerenciamento das comunicaes O gerenciamento de comunicaes do projeto ser feito por e-mail e sistema de troca de mensagens interna da empresa, os quais sero considerados no documento do projeto. O andamento do projeto estar disponvel na intranet. As solicitaes de mudana devem ser formalizadas por e-mail, mediante preenchimento de formulrio de solicitao de mudanas, e aprovadas pelo gerente de projetos e pelo gerente de mudanas.

3.7.2. Eventos de Comunicao

O projeto ter os seguintes eventos de comunicao: Reunio de Kick-Off

Objetivo Discutir os objetivos do projeto, definir as entregas do projeto e colher informaes para definio de prazos, custos e outros envolvidos.

Responsvel Marcelo Monteiro, Gerente de Projetos

Envolvidos Marcelo Monteiro (Gerente de Projeto); Claudio Bail (Diretor de TI); Carlos Dias (Diretor Executivo).

Data e hora 11/10/2010 s 09 horas.

Durao 2 horas.

Local Sala de Reunio da empresa aloha; Avaliao do Plano de Gerenciamento de Projeto

Objetivo Avaliar o andamento do projeto. Fazer as atualizaes de cronograma e de custos, se necessrias, assim como as atualizaes das mudanas. Apresentar Status Report das atividades desenvolvidas; Gerar relatrio de lies aprendidas.

Responsvel Leandro Henriques, co-responsvel pelo plano de gerenciamento de comunicaes.

Envolvidos Marcelo Monteiro (Gerente de Projeto); Claudio Bail (Diretor de TI); Leandro Henriques (Gerente de TI);

Freqncia Semanal, s teras-feiras.

Durao 2 horas, a partir das 18hs.

Local Sala de reunio da empresa Aloha. Reunio de Medio de Contrato

Objetivo Verificar atravs dos indicadores de qualidade a aplicabilidade do servio contratado com base nos termos definidos em contrato;

Responsvel Marcelo Monteiro, Gerente de Projeto

Envolvidos Marcelo Monteiro (Gerente de Projeto); Claudio Bail (Diretor de TI); Leandro Henriques (Gerente de TI);

Freqncia Mensal, s quintas-feiras

Horrio 10hs;

Durao 2 horas;

Local: Sala de reunio da empresa Aloha; Reunio do Time do Projeto

Objetivo Acompanhar os prazos e o andamento das atividades referentes ao projeto

Responsvel Marcelo Monteiro (Gerente de Projeto)

Envolvidos Marcelo Monteiro (Gerente de Projeto), Andre Piazzi (Desenvolvedor), Andria Abreu (Analista de Requisitos); Freqncia Semanal, s Segundas-feiras

Horrio 9hs;

Durao 3 horas;

Local Sala de reunio da empresa fornecedora; Reunio de Encerramento de Projeto

Objetivo Verificar se os objetivos foram alcanados e gerar documento de lies aprendidas.

Responsvel Marcelo Monteiro, gerente de projetos

Envolvidos Marcelo Monteiro (Gerente de Projeto); Claudio Bail (Diretor de TI); Carlos Dias (Diretor Executivo); Alberto Torres (Fornecedor da Soluo)

Data e Horrio A definir em Janeiro.

Durao 4 horas.

Local Sala de Reunio da Aloha.

3.7.3. Intranet

Ser utilizado atravs da Intranet o armazenamento de informaes do projeto e da equipe, bem como os documentos gerados de forma versionada. O andamento do projeto tambm ser registrado atravs desta forma de mdia.

3.8. PLANO DE GERENCIAMENTO DE AQUISIES3.8.1. Objetivo

Como meta principal deste Plano de Gerenciamento de Aquisies selecionar fornecedores qualificados para os bens e servios do projeto e control-los de maneira eficaz. Tambm visaremos neste plano a definio dos equipamentos a serem adquiridos para a execuo do Projeto de implantao do Service Center.

3.8.2. Gerenciamento e tipos de contratosOs contratos com fornecedores e prestadores de servio neste projeto sero todos do tipo Preo Global Fixo e Irreajustvel, visto o oramento ter carter restrito e as premissas serem bastante definidas.3.8.3. Critrios de avaliao de cotaes e propostasSero necessrios o recebimento de 3 cotaes para cada tipo de prestao de servio sendo adquirido. O critrio de seleo da proposta vencedora ser:

Atendimento integral as declaraes de trabalho

Referncias de clientes anteriores para nossa consulta sobre a qualidade dos servios prestados

Melhor preo que respeite as limitaes oramentrias do projeto3.8.4. Avaliao de fornecedoresOs fornecedores foram avaliados de acordo com:

Localizao geogrfica/acessibilidade;

Horrio de funcionamento do estabelecimento;

Certificaes3.8.5. Freqncia de avaliao dos processos de aquisies

O contedo deste plano de aquisies ser revisto caso haja alterao no plano de escopo, ou quando algum item, material ou equipamento previsto nesse plano estiver fora de linha de fabricao.3.8.6. Alocao financeira para o gerenciamento das aquisies

Os gastos previstos com compra de equipamentos estaro includos nos oramentos apresentados no processo de licitao;

Uma vez definido o vencedor da licitao, os valores so mantidos at o final do projeto estando includos na estimativa de custos;

Uma vez aprovados nos processos citados acima, ser firmado contratos com fornecedores e os valores no sero alterados at o final do projeto4. DOCUMENTOS AUXILIARES

4.1. Declarao de Escopo do Projeto

4.1.1. Objetivo do Projeto

Este projeto tem por objetivo inicial a implantao de um sistema de abertura e controle de chamados para a empresa Aloha, visando adequar as polticas e diretrizes da empresa garantindo maior qualidade ao atendimento de solicitaes de TI da mesma.4.1.2. Designao do Gerente do ProjetoFica definido que o Sr. Marcelo Monteiro ser o gerente do projeto, tendo o mesmo as seguintes responsabilidades e autoridades:4.1.2.1. Responsabilidades

Revisar a documentao formal do projeto e tomar uma deciso para aceitar, recusar ou aceitar as condies para a responsabilidade do projeto; Atuar como ponto central de contato para toda documentao formal do projeto entre nossa organizao e o cliente; Assegurar que os membros da equipe de projeto estejam cientes de suas responsabilidades e tambm, que todos os compromissos assumidos pelos indivduos sejam realizados; Gerenciar compromissos contratuais e realiz-los em tempo, dentro do oramento e com satisfao do cliente; Elaborar e atualizar o Plano de Projeto com a anuncia expressa do cliente; Controlar custos, cronograma, oramento e variaes tcnicas dentro das margens estabelecidas no projeto; Manter toda documentao atualizada nos sistemas, bem como na base de conhecimento; Seguir todos os processos e padres metodolgicos; Reportar formalmente o status do projeto gerncia;

4.1.2.2. Autoridades

Engajar e substituir o pessoal da equipe de projeto quando necessrio e dirigir as atividades da equipe; Para acessar os contatos com os clientes para todos os assuntos relativos a este projeto; Para acessar os gerentes de recursos em todos os assuntos relativos a este projeto; Para controlar o oramento do projeto; Para dirigir as aes de monitoramento referente a tempo, custo, risco, desempenho e qualidade de forma a garantir que todos os problemas so prontamente identificados, reportados e solucionados; Para contatar atravs de unidades funcionais e com todos os nveis de gerncia para realizar os objetivos do projeto;

Para delegar a responsabilidade e autoridade dos projetos dos membros de sua equipe;

4.1.3. Riscos Iniciais do ProjetoOs principais riscos identificados no projeto sero monitorados pelo Gerente. So eles: Mau planejamento e monitoramentos e controles inadequados

Perda ou troca de recursos de equipe durante execuo do projeto

Atraso na disponibilizao da infra-estrutura necessria para implantao da soluo adquirida. Extenso no prazo do projeto

4.1.4. Limites de Projeto

Para o projeto em questo, podem so identificados os seguintes pontos:

No ser realizada qualquer tipo de manuteno e suporte ao produto, aps o vencimento do perodo de garantia (90 dias) do mesmo. Nenhuma funcionalidade diferentemente das citadas neste documento, poder ser implementada salvo comunicao em tempo de planejamento do projeto, pra fins de estudo de impacto (custo, tempo).

Todo e qualquer requisito de hardware necessrio e identificado como necessrio para este projeto, dever ser fornecido pela CONTRATANTE.4.1.5. Premissas

As seguintes premissas foram assumidas para este projeto:

Recursos estaro disponveis quando e onde forem necessrios

Recursos de hardware e software estaro disponveis quando necessrio

Usurios iro disponibilizar tempo para levantamento e validao dos requisitos.

Os artefatos de software submetidos a aprovao iro retornar em 72 horas.

Os processos de negcio no sero alterados durante o projeto.4.1.6. Restries

Este projeto possui as seguintes restries:

A equipe no poder atuar em tempo integral.

No permitido realizar trabalho fora do horrio normal de expediente.4.1.7. Stakeholders

Inicialmente, foram identificados os seguintes stakeholders para este projeto: Gerente de Projeto

Clientes da Aloha

4.2. Levantamento de Requisitos

4.2.1. Viso Geral do documento

Esta introduo fornece as informaes necessrias para fazer um bom uso deste documento, explicitando seus objetivos e as convenes que foram adotadas no texto. As demais sees apresentam a especificao dos novos requisitos do projeto de Service Center a serem implementados e esto organizadas como descrito abaixo.

Requisitos funcionais: lista os requisitos funcionais do sistema, especificando seus objetivos, atores e prioridades.

Requisitos no funcionais: especifica todos os requisitos no funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurana, distribuio, adequao a padres e requisitos de hardware e software.

4.2.2. Identificao dos requisitosPor conveno, a referncia aos requisitos feita atravs do nome da subseo onde eles esto descritos seguidos do identificador do requisito de acordo com o esquema abaixo:TermoDescrio

NFRequisito No Funcional

RFRequisito Funcional

4.2.3. Prioridades dos requisitosPara estabelecer a prioridade dos requisitos foram adotadas as denominaes essencial, importante e desejvel.

Essencial o requisito sem o qual o sistema no entra em funcionamento. Requisitos essenciais so requisitos imprescindveis, que tm que ser implementados impreterivelmente.

Importante o requisito sem o qual o sistema entra em funcionamento, mas de forma no satisfatria. Requisitos importantes devem ser implementados, mas, se no forem, o sistema poder ser implantado e usado mesmo assim.

Desejvel o requisito que no compromete as funcionalidades bsicas do sistema, isto , o sistema pode funcionar de forma satisfatria sem ele. Requisitos desejveis so requisitos que podem ser deixados para verses posteriores do sistema, caso no haja tempo hbil para implement-los na verso que est sendo especificada.

4.2.4. Critrios de Aceitao

Tcnico

Financeiro

Prazo

Negcio

4.2.5. Requisitos FuncionaisOs requisitos que descrevem as funcionalidades a serem implementadas so apresentados a seguir:RF-1. Registrar ChamadosDescrioOrigem:

O sistema dever permitir que cada usurio ao autenticar no sistema, consiga criar solicitaes/chamados contendo as informaes que deseja obter ou solicitaes que deseja realizar.

Prioridade: FORMCHECKBOX

Essencial FORMCHECKBOX

Importante FORMCHECKBOX

Desejvel

Aceitao Critrio de Aceitao

FORMCHECKBOX Aceito

FORMCHECKBOX No Aceito FORMCHECKBOX Tcnico FORMCHECKBOX Financeiro FORMCHECKBOX Prazo FORMCHECKBOX Negcio

RF-2. Consultar ChamadosDescrioOrigem:

O sistema dever permitir que cada usurio ao autenticar no sistema, consiga criar solicitaes/chamados contendo as informaes que deseja obter ou solicitaes que deseja realizar.




Desejvel


FORMCHECKBOX Aceito


RF-3. Criar Filas/Grupos de Atendimento de ChamadosDescrioOrigem:

O sistema dever permitir que sejam criados grupos/filas para atendimento dos chamados criados pelos usurios atravs da aplicao com base no tipo ou natureza da informaes descrita no chamado. Exemplo: Grupo Infra Windows, Grupo Infra Linux, .... etc




Desejvel

AceitaoCritrio de Aceitao

FORMCHECKBOX Aceito


RF-4. Criar Nveis de Severidade para ChamadosDescrioOrigem:

O sistema dever permitir que possam ser atribudos aos chamados criados pelo usurios atravs da aplicao, nveis de severidade que possuam tempos mximos de tratamento (contingenciamento ou soluo definitiva) com base severidade ou criticidade das informaes dispostas nos chamados. Os nveis de severidade devero ser classificados em: Alto, Mdio e Baixo.




Desejvel


FORMCHECKBOX Aceito


RF-5. Criar categorias de atendimento de chamadosDescrioOrigem:

O sistema dever permitir que sejam criadas categorias para atendimento dos chamados criados pelos usurios atravs da aplicao com base no tipo ou natureza da informaes descrita no chamado. Estas categorias sero: Incidente, Atividade Recorrente, Atividade de Orientao




Desejvel


FORMCHECKBOX Aceito


RF-6. Criar estados de atendimento dos chamadosDescrioOrigem:

O sistema dever permitir que sejam criados estados para atendimento dos chamados criados pelos usurios atravs da aplicao com base no tipo ou natureza da informaes descrita no chamado. Estes estados devero ser: Aberto, Fechado, Pendente, Contingenciado, Reaberto, Resolvido




Desejvel


FORMCHECKBOX Aceito


RF-7. Gerar Relatrios de Mtricas e Grficos de AcompanhamentoDescrioOrigem:

plano de gerenciamento de projeto

Documents