METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM NETWORK · A declaração do escopo do projeto também fornece um entendimento comum do escopo do projeto a todas as partes interessadas no

Página 1

METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM NETWORK

Agosto de 2009

Página 2

Sumário

1 CONCEITOS ......................................................................................................................................... 4

1.1 Ciclos de vida do projeto e do produto ..................................................................................................4 1.1.1 Grupos de processos de gerenciamento de projetos ..................................................................4 1.1.2 Fases do projeto e processos de gerenciamento de projetos .....................................................5

1.2 Coordenação de Projetos ......................................................................................................................6

1.3 Elaboração Progressiva .........................................................................................................................6

1.4 Áreas de conhecimento envolvidas no projeto ......................................................................................7

1.5 Identificação de entregas e Escopo do Projeto .....................................................................................8

1.6 Criando a Estrutura Analítica do Projeto .............................................................................................10

1.7 Declaração do escopo do projeto ........................................................................................................11

2 Estrutura Escritório de Projetos. ....................................................................................................... 16

2.1 Escritório de Projetos...........................................................................................................................16

2.2 Objetivos do Escritório de Projetos:.....................................................................................................16

3 FLUXO DE PROCESSOS ...................................................................................................................... 17

3.1 Fases de Projeto ..................................................................................................................................17

3.2 Fluxo – Nível 1 .....................................................................................................................................18 3.2.1 Fluxo Nível 1 – (Página 1) ...........................................................................................................18 3.2.2 Fluxo Nível 1 – (Página 2) ...........................................................................................................19 3.2.3 Fluxo Nível 1 – (Página 3) ...........................................................................................................20

3.3 Fluxo – Nível 2 .....................................................................................................................................21 3.3.1 Fluxo Nível 2 – Pré-Projeto (Página 1) .......................................................................................21 3.3.2 Fluxo Nível 2 – Planejamento (Página 2) ...................................................................................22 3.3.3 Fluxo Nível 2 – Análise (Página 3) ..............................................................................................23 3.3.4 Fluxo Nível 2 – Construção (Página 4) .......................................................................................24 3.3.5 Fluxo Nível 2 – Testes (Página 5) ...............................................................................................25 3.3.6 Fluxo Nível 2 – Treinamento (Página 6) .....................................................................................26 3.3.7 Fluxo Nível 2 – Promoção à Produção (Página 7) ......................................................................27

4 METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM ............................................................................. 29

4.1 Termo de abertura do projeto. ............................................................................................................29

4.2 Levantamento de Requerimentos do Projeto. .....................................................................................30

4.3 Plano de Projeto. .................................................................................................................................31

4.4 Reunião de Kick-Off .............................................................................................................................34

4.5 Levantamento detalhado de requerimentos. ......................................................................................35

4.6 Requisitos para customização. ............................................................................................................36

4.7 Entrega de customização ....................................................................................................................39

4.8 Integridade da Base de Dados. ............................................................................................................40

4.9 Resumo e Aceite dos Testes. ...............................................................................................................41

Página 3

4.9.1 Testes Operacionais ...................................................................................................................41 4.9.2 Testes Funcionais .......................................................................................................................41

4.10 Treinamento. ..................................................................................................................................42

4.11 Promoção à Produção (Go-Live) e Aceite Final. ..............................................................................42

Página 4

1 CONCEITOS 1.1 Ciclos de vida do projeto e do produto

1.1.1 Grupos de processos de gerenciamento de projetos

As fases do ciclo de vida de um projeto são altamente dependentes do produto ou serviço criado

por esse projeto. Obviamente, as fases de um projeto de pesquisa de uma nova droga

medicamentosa nada tem a ver com a criação de um sistema de contabilidade com fases como

levantamento de requisitos, desenho de estrutura de dados, desenho lógico, físico, testes,

implantação. Essas, chamadas FASES DO CICLO DE VIDA do projeto são denominadas e utilizadas

da melhor forma que um a organização enxerga como fazer.

Mas, segundo o PMBOK®, nessas fases do ciclo de um projeto podem acontecer vários processos

dos GRUPOS DE PROCESSOS DO GERENCIAMENTO DO PROJETO, estes sim, tratados em suas

práticas e descritos na Figura abaixo.

Grupos de processos de gerenciamento de projetos

Grupo de processosde iniciação

Define e autoriza o

projeto ou uma fase

do projeto.

Grupo de processos de planejamento

Define e refina os

objetivos e planeja a ação

necessária para alcançar

os objetivos e o escopo

para os quais o projeto foi

realizado.

Grupo de processos de

execuçãoIntegra

pessoas e

outros

recursos para

realizar o

plano de

gerenciamento

do projeto

para o projeto.

Grupo de processos de monitoramento e controle

Mede e monitora

regularmente o progresso

para identificar variações

em relação ao plano de

gerenciamento do projeto,

de forma que possam ser

tomadas ações corretivas

quando necessário para

atender aos objetivos do

projeto

Grupo de processos de encerramento. Formaliza

a aceitação do produto,

serviço ou resultado e

conduz o projeto ou uma

fase do projeto a um final

ordenado.

Página 5

1.1.2 Fases do projeto e processos de gerenciamento de projetos

Fases do projeto e processos de gerenciamento de projetos

Ciclo de vida do projeto

Fases do ciclo de vida do projeto

Ciclo de vida de gerenciamento

do projeto

Projeto

1.2 Coordenação de Projetos

Coordenação ou gerenciamentoferramentas e técnicas nas atividades do projeto a fim de atender os seus requisitos.

1.3 Elaboração Progressiva

Integrando conceitos de temporário e com produto ou serviço exclusivos,

elaboração progressiva é o desenvolvimento em etapas, com incrementos

sucessivos.

Os grupos de processos podem acontecer em cada fase do ciclo de vida do projeto. O

Planejamento de uma fase não é um novo Planejamento, mas com incrementos e retificação ou

ratificação do definido anteriormente, assim como todos os outros grupos de processo. Após o

Plano de Projetos estar aprovado por todos os interessados, as mudanças devem seguir um Plano

Integrado de Mudanças, que pode, em cada organização

diferenciadas.

Coordenação de Projetos

Coordenação ou gerenciamento de Projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto a fim de atender os seus requisitos.

Elaboração Progressiva

Integrando conceitos de temporário e com produto ou serviço exclusivos,

ão progressiva é o desenvolvimento em etapas, com incrementos

s grupos de processos podem acontecer em cada fase do ciclo de vida do projeto. O

Planejamento de uma fase não é um novo Planejamento, mas com incrementos e retificação ou

ratificação do definido anteriormente, assim como todos os outros grupos de processo. Após o

Plano de Projetos estar aprovado por todos os interessados, as mudanças devem seguir um Plano

Integrado de Mudanças, que pode, em cada organização, ser especificad

Página 6

de Projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto a fim de atender os seus requisitos.

s grupos de processos podem acontecer em cada fase do ciclo de vida do projeto. O

Planejamento de uma fase não é um novo Planejamento, mas com incrementos e retificação ou

ratificação do definido anteriormente, assim como todos os outros grupos de processo. Após o

Plano de Projetos estar aprovado por todos os interessados, as mudanças devem seguir um Plano

ser especificado de formas

Página 7

1.4 Áreas de conhecimento envolvidas no projeto

Os grupos de processos de gerenciamento de projetos – Iniciação, Planejamento, Execução,

Monitoramento e Controle, Encerramento, podem ter processos qualificados como parte de uma

das nove áreas de conhecimento, como na Figura abaixo:

Áreas de Conhecimento de um projeto

Integração

Comunicação

Escopo

Qualidade

Risco

Contratos e Aquisições

Recursos Humanos

Tempo

Custo

Página 8

1.5 Identificação de entregas e Escopo do Projeto

O conceito de entrega para a construção de um plano de projeto é bastante útil para a formação

da principal ferramenta de planejamento e comunicação junto aos clientes, a EAP (Estrutura

Analítica de Projeto) ou WBS (Work Breakdown Structure). Essa estrutura utiliza a entregas que

devem ser feitas para ou do projeto para que ele, sim, possa fazer a entrega de produtos ou

serviços acordada com o cliente. Além da construção da EAP baseada em entregas é possível

construir essa estrutura à partir do ciclo de vida do projeto, normalmente utilizado quando existe

um padrão estabelecido pela organização.

Vamos partir do princípio que não existe nenhum processo auxiliar para a construção dessa

estrutura e criá-la, para fins educacionais, a partir de entregas. Pense primeiro nas entregas. Crie

uma estrutura de decomposição dessas entregas para que seja possível a criação do produto final.

O fundamental quando estamos pensando em entregas é não ter a preocupação de se elas devem

acontecer em uma determinada ordem. Ordenar trabalhos que serão responsáveis por gerar essas

entregas é uma questão a ser tratada posteriormente.

Quando o assunto a ser tratado pelo projeto não é de conhecimento total da equipe de projeto, a

recomendação é a utilização de opinião especializada (expert judgement) ou de informações

históricas contidas nos ativos de processos organizacionais (Historical Information) como

ferramentas para a construção do plano de gerenciamento do projeto (project management plan).

Para exemplificar os conceitos que serão tratados durante o curso, vamos utilizar um caso de

planejamento e execução de um filme.

Entregas para definição da EAP ou WBS

Hierarquia

(codificação)

Entregas e sub entregas

1 História

1.1 Definição de Roteiro

1.1.1 Roteiro inicial

1.1.2 Roteiro estruturado

1.2 Definição de Texto

1.2.1 Diálogos

1.2.2 Marcações

Página 9

1.2.3 Indicações de interpretação

2 Pessoal

2.1 Produtor e diretor definidos

2.2 Seleção e contratação de Elenco principal

2.2.1 Elenco principal definido

2.2.2 Elenco principal contratado

2.3 Demais Atores e figurantes contratados

2.4 Contratação de Técnicos

2.4.1 Maquiadores contatados

2.4.2 Figurinistas contratados

2.4.3 Técnicos de som, luz e filmagem contratados

3 Produção

3.1 Cenas detalhadas

3.2 Tomadas determinadas na “ordem do dia”

3.3 Finalização

3.4.1 Cenas editadas

3.5.2 Efeitos especiais adicionados

3.6.3 Falas sincronizadas

4 Gestão do Projeto

4.1. Plano de projeto

4.2 Orçamento

4.2.1 Orçamento Aprovado

4.2.2 Controle orçamentário

4.3 Cronograma

4.3.1 Cronograma Geral Aprovado

4.3.2 Controle do cronograma

4.3.3 Cronograma diário revisado

4.4 Acompanhamento Integrado

4.5 Riscos

4.5.1 Identificação

4.5.2 Resposta planejada ou de contorno

4.6 Encerrramento

4.6.1 Reunião de Informações históricas

4.6.2 Encerramento de contratos e do projeto

Página 10

1.6 Criando a Estrutura Analítica do Projeto

Com as entregas definidas (Entregas para definição da EAP ou WBS - Work Breakdown Structure) a

EAP está praticamente montada. A decomposição do trabalho a ser executado para que o projeto

possa ser completado é feita a partir das entregas. A estrutura pode ser criada a partir do ciclo de

vida do projeto ou fases do ciclo de vida do projeto (Fases do projeto e processos de

gerenciamento de projetos). Provavelmente será, caso na organização já exista uma estrutura

padrão ou que a equipe de projeto domine profundamente o ciclo de vida do produto.

A EAP ou WBS pode ser representada na forma do “Entregas para definição da EAP ou WBS” mas,

freqüentemente é apresentada em forma gráfica, hierárquica, como a demonstrada a seguir:

Estrutura Analítica do Projeto Filme

O último nível de cada braço da EAP denomina-se PACOTE DE TRABALHO (WORK PACKAGE) e será

decomposto em atividades, ou seja, todo o trabalho necessário para criar a entrega que, de

alguma forma, será parte ou colaborará para ao entrega final do projeto.

Filme

Gestão do ProjetoProduçãoPessoalHistória

Definição de Roteiro

Roteiro

inicial

Roteiro estruturado

Definição de Texto

Diálogos

Marcações

Indicações de

interpretação

Seleção e Contratação do

Elenco principal

Elenco principal definido

Elenco principal contratado

Contratação de Técnicos

Maquiadores

contratados

Figurinistas contatados

Técnicos de som,

luz e filmagem contratados

Produtor e diretor definidos

Demais Atores e figurantes

contratados

Cenas detalhadas

Tomadas determinadas na “ordem do dia”

Orçamento

Orçamento Aprovado

Controle orçamentário

Plano de projeto

Acompanhamento

integrado

Cronograma

Cronograma Geral Aprovado

Controle do Cronograma

Cronograma Diário Revisado

Riscos

Identificação

Resposta planejada ou de controle

Finalização

Cenas editadas

Efeitos especiais adicionados

Falassincronizadas

Encerramento

Reunião informações históricas

Encerramento contratos e projeto

Página 11

1.7 Declaração do escopo do projeto

A declaração do escopo do projeto descreve, em detalhes, as entregas do projeto e o trabalho

necessário para criar essas entregas. A declaração do escopo do projeto também fornece um

entendimento comum do escopo do projeto a todas as partes interessadas no projeto e descreve

os principais objetivos do projeto. Além disso, permite que a equipe do projeto realize um

planejamento mais detalhado, orienta o trabalho da equipe do projeto durante a execução e

fornece a linha de base para avaliar solicitações de mudanças ou trabalho adicional e verificar se

estão contidos dentro ou fora dos limites do projeto.

O gerenciamento do escopo do projeto, por sua vez, pode determinar e eficácia com que a equipe

de gerenciamento de projetos poderá planejar, gerenciar, e controlar a execução do projeto. A

declaração do escopo detalhada do projeto inclui, diretamente ou referenciando outros

documentos:

Objetivos do projeto. Os objetivos do projeto incluem os critérios mensuráveis do sucesso do

projeto. Os projetos podem possuir uma ampla variedade de objetivos técnicos, de negócios,

custo, cronograma e qualidade. Os objetivos do projeto também podem incluir metas de custo,

cronograma e qualidade. Cada objetivo do projeto possui atributos como custo, uma métrica

como dólares e um valor absoluto ou relativo como inferior a 1,5 milhão de dólares.

Descrição do escopo do produto. Descreve as características do produto, serviço ou resultado

para cuja criação o projeto foi realizado. Essas características terão normalmente menos detalhes

nas fases iniciais e mais detalhes nas fases posteriores, conforme as características do produto

forem progressivamente elaboradas. Embora a forma e o conteúdo das características variem, a

descrição do escopo deve sempre fornecer detalhes suficientes para dar suporte ao planejamento

posterior do escopo do projeto.

Requisitos do projeto. Descreve as condições ou capacidades que devem ser atendidas ou

possuídas pelas entregas do projeto para satisfazer um contrato, norma, especificação ou outros

documentos formalmente impostos. As análises das partes interessadas de todas as suas

necessidades, desejos e expectativas são convertidas em requisitos priorizados.

Limites do projeto. Normalmente identifica o que está incluído dentro do projeto. Declara de

forma explícita o que está excluído do projeto, para evitar que uma parte interessada possa supor

que um produto, serviço ou resultado específico é um componente do projeto.

Entregas do projeto. As entregas (Fig.5.2) incluem tanto as saídas que compõem o produto ou

serviço do projeto, como resultados auxiliares, como documentação e relatórios de

Página 12

gerenciamento de projetos. Dependendo da declaração do escopo do projeto, as entregas podem

ser descritas de forma sumarizada ou detalhada.

Critérios de aceitação de produtos. Define o processo e os critérios para aceitar os produtos

terminados.

Restrições do projeto. Lista e descreve as restrições específicas do projeto associadas ao escopo

do projeto que limitam as opções de planejamento da equipe. Por exemplo, normalmente são

incluídos um orçamento predefinido ou datas impostas (marcos do cronograma) por alguém

externo à equipe do projeto. Quando existir um contrato designando caminhos para solução, suas

cláusulas podem significar restrições.

Premissas do projeto. Caso as premissas, que são, em planejamento, consideradas verdades ou

questões reais, não aconteçam, todo o planejamento e execução do projeto ficam

comprometidos. As premissas como parte do processo de planejamento são menos detalhadas e

numerosas do que as que estão aqui, que tratam questões mais específicas de escopo.

Organização inicial do projeto. São identificados os membros da equipe do projeto e as partes

interessadas. A organização do projeto também é documentada.

Riscos iniciais definidos. Identifica os riscos conhecidos.

Marcos do cronograma. O cliente ou a organização executora podem identificar marcos e colocar

datas impostas no cronograma. Essas datas podem ser consideradas como restrições.

Limitação de fundos. Descreve qualquer limitação dos recursos financeiros do projeto, uma

limitação do valor total ou uma limitação imposta em prazos especificados.

Estimativa de custos. A estimativa de custos do projeto indica o custo total esperado do projeto e

é normalmente precedida de um modificador que fornece alguma indicação de exatidão como,

por exemplo, conceitual ou definitiva.

Requisitos do gerenciamento de configuração do projeto. Descreve o nível de gerenciamento de

configuração e controle de mudanças que será implementado no projeto.

Especificações do projeto. Identifica os documentos de especificação com os quais o projeto deve

estar de acordo.

Requisitos de aprovação. Identifica os requisitos de aprovação que podem ser aplicados a itens

como objetivos, entregas, documentos e trabalho do projeto.

Página 13

Declaração de Escopo do Projeto Filme Objetivos do projeto. Este filme tem por objetivo alcançar o mercado americano e europeu com

exibição em, pelo menos, 100 salas. O seu retorno deve ser de, no mínimo, 200% do montante investido.

Descrição do escopo

do produto.

Um filme de duração entre 100 e 120 minutos, retratando a visão dos jovens de hoje (que tenham idade entre 13 e 20 anos), sobre a questão da preservação dos recursos naturais e do planeta versus a visão que os jovens das décadas de 1960 e 1970, que viveram os movimentos estudantis, militarismo e viram surgir a pílula, a possibilidade do uso de drogas, cigarro e álcool mias facilitados, tem da preservação da vida para a geração atual.

Requisitos do projeto. Segundo contrato firmado com a agência patrocinadora, toda a ambientação do filme deverá ser no Brasil, com exceção de possíveis personagens que possam ter seu depoimento necessário e estejam vivendo no estrangeiro. Apesar de não ter sido ainda definido o formato de documentário, alguns depoimentos serão colhidos de pessoas de projeção no país.

Limites do projeto. A distribuição não fará parte do escopo do projeto.

Entregas do projeto. Definidas na Fig. 7.1 Estrutura Analítica do projeto Filme

Critérios de aceitação

de produtos

OS critérios de aceitação serão definidos durante o processo de planejamento da Qualidade do projeto.

Restrições do projeto. O tempo de execução, após a aprovação do orçamento, não pode ultrapassar 13 meses, segundo acordado com as empresas financiadoras do projeto. Os atores devem ser brasileiros e a língua falada será o português. O orçamento não pode exceder o acordado com as empresas financiadoras. (serão mais detalhadas ao longo do grupo de processos Planejamento)

Premissas do projeto. O orçamento deverá ser aprovado na íntegra. Caso contrário, esse plano deverá ser revisto para atestar a sua viabilidade. O diretor e gerente do projeto Filme terá a liberdade de escolha dos atores principais. (serão mais detalhadas ao longo do grupo de processos Planejamento)

Organização inicial do

projeto.

Patrocinador (Produtor), Ger. Projeto (Diretor), Roteiristas.

Riscos iniciais

definidos.

A agência financiadora não concede a verba necessária, quebra de contrato de um dos atores principais, não haver identificação entre atores e roteiro, ou atores e diretor, a distribuição não alcançar objetivos de atendimento dos objetivos do projeto (pelo menos 100 salas no mercado americano e europeu).

Página 14

Declaração de Escopo do Projeto Filme – continuação Marcos do

cronograma.

Julho de 20xx - aprovação do orçamento; Agosto de 20xx - início das filmagens; De 30 3m 30 dias – revisão do planejamento; Outubro de 20xx – cenas históricas Filmadas e editadas; Janeiro de 20xy – depoimentos atuais finalizados; Março de 20xy - depoimentos atuais editados; Abril de 20xy – primeira cópia com 300 minutos apresentada Maio de 20xy – cópia com 120 min. Aprovada; Junho de 20xy – cópia final apresentada.

Limitação de fundos Após o valor aprovado, eles serão liberados mensalmente de acordo com fluxo de caixa aprovado pela agência financiadora, após a finalização do plano do projeto.

Estimativa de custos Os custos estimados são cerca de 5.000.000

Requisitos do

gerenciamento de

configuração do

projeto.

Tanto o projeto quanto o produto terão sua documentação indexada e de acesso aos interessados. Tratando-se de um produto que exige controle igual ou até maior que o próprio projeto, a sua documentação fará parte de uma filmoteca organizada e mantida por profissional especializado. Qualquer alteração de versão de plano, seja do produto ou do projeto, deve ser adequada a versão do outro plano.

Especificações do

projeto.

Os documentos de especificação que devem estar sempre de acordo entre si, são: plano de projeto, plano de produto, contrato com fornecedores e documentos com as fontes financiadoras.

Requisitos de

aprovação.

Qualquer aprovação de mudança no projeto ou produto do projeto devem estar com o “de acordo” do comitê de mudanças do projeto (que inclui a empresa financiadora, o produtor, diretor e principais interessados). O e de projeto tem como limite de aprovação pré-determinado no valor máximo de 50.000. Qualquer alteração entre os valores de 50.000 e 100.00 pode ser aprovada pelo patrocinador ou produtor do projeto.

Página 15

Embora exista um conjunto de formulários, como a declaração de escopo ou a WBS, que podem ser de ajuda para o levantamento de informações eles podem se transformar, quando juntos em um plano de projeto nada atrativo. Um plano de projeto deve ser algo agradável de ler, não pode ser “engavetado” pelos principais interessados no projeto. Portanto, não pode ser um amontoado de formulários, com informações repetitivas.

Para fins didáticos, eles estão apresentados neste material em forma de formulários. Ao criar-se

um plano de projeto eles precisam ser utilizados como parte de um texto coeso, em linguagem

suficientemente clara para os que vão lê-lo. Além disso, contento as informações necessárias para

cada grupo representado no plano de comunicações.

Página 16

2 Estrutura Escritório de Projetos.

2.1 Escritório de Projetos.

É uma estrutura formada, inicialmente, por profissionais com características, experiências e conhecimentos complementares (produtos Millennium, melhores práticas em gerenciamento de projetos, monitoramento e controle de projetos) com o objetivo de: - Apoio à equipe de pré-venda. - Suporte ao gerente de projetos. - Criar e manter os documentos auxiliares. - Aferir métricas de controle da saúde do projeto.

2.2 Objetivos do Escritório de Projetos:

- Suportar implantações de projetos, criando fluxos de processos e documentação necessária para seu devido funcionamento.

Missão: Prover os profissionais da Millennium com informações e métodos padronizados para gestão de projetos e processos, visando a melhoria do desempenho na criação de soluções para nossos clientes. Valores: - Orientar pela informação. - Valorizar pessoas. - Elevar conhecimento. - Buscar excelência.

Página 17

3 FLUXO DE PROCESSOS

3.1 Fases de Projeto

Página 18

3.2 Fluxo – Nível 1

3.2.1 Fluxo Nível 1 – (Página 1)

Página 19

3.2.2 Fluxo Nível 1 – (Página 2)

Página 20

3.2.3 Fluxo Nível 1 – (Página 3)

Página 21

3.3 Fluxo – Nível 2

3.3.1 Fluxo Nível 2 – Pré-Projeto (Página 1)

Processos que Antecedem o Início do Projeto

Divulga Projeto, Equipe e Cliente

para toda a empresaForma EquipeDesigna Gerente de Projeto

Analisa Requerimentos e

Customizações Identificadas

Analista de Negócios

analisa e dimensiona risco,

custo e tempo de

Implantação

Requerimentos do

Projeto

Há customizações?

Desenvolvimento

estima: Horas

(Levantamento,

Desenv., e

Homologação); e

Prazo

Requerimentos do

Projeto Atualizado

SN

EP analisa conhecimento

do Gerente de Projeto

Informações sobre

Cursos, Conhecimento,

e Projetos anteriores

dos GPs

EP verifica disponibilidade

do Gerente de Projeto

M3 – Agenda de

disponibilidade dos

GPs

EP sugere Gerente para

Projeto

Comitê / Diretoria

aprova alocação?

N

EP comunica GP e

apresenta prospect do

cliente

S

GP analisa complexidade /

perfil do projeto

M3 – Agenda de

disponibilidade dos

Consultores

Informações sobre

Cursos, Conhecimento,

e Projetos anteriores

dos Consultores

GP analisa conhecimento

do Consultor

GP verifica disponibilidade

do Consultor

GP comunica Consultor e

apresenta prospect do

cliente

EP valida equipe e aloca

Consultor

GP reúne informações da

equipe e do projeto

Termo de Abertura

GP envia Termo de

Abertura para Escritório de

Projetos

Escritório de Projetos

divulga projeto para toda a

empresa via E-mail

Inicia

Fase

PLAN.

Página 22

3.3.2 Fluxo Nível 2 – Planejamento (Página 2)

Página 23

3.3.3 Fluxo Nível 2 – Análise (Página 3)

Página 24

3.3.4 Fluxo Nível 2 – Construção (Página 4)

Página 25

3.3.5 Fluxo Nível 2 – Testes (Página 5)

Página 26

3.3.6 Fluxo Nível 2 – Treinamento (Página 6)

Página 27

3.3.7 Fluxo Nível 2 – Promoção à Produção (Página 7)

Página 28

Página 29

4 METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM

4.1 Termo de abertura do projeto.

O termo de abertura do projeto é um documento que autoriza formalmente o projeto. Ele concede ao gerente a autoridade para utilizar os recursos da organização na execução das atividades do projeto, além de divulgar o projeto para toda a organização. Os principais pontos a serem abordados neste termo são:

- Contexto do Projeto Deve apresentar o cenário atual da empresa que está contratando o projeto. Deve mencionar o horizonte, próximos eventos importantes relacionados ao projeto, e fatores que sejam relevantes sobre o cliente. - Objetivos do Projeto Deve especificar os principais objetivos do projeto, de forma realista, sucinta e - Equipe do Projeto Deve apresentar o gerente de projeto, suas atribuições e autoridade. - Necessidades básicas Descreve as necessidades básicas do trabalho a ser realizado. - Descrição do Projeto:

- Produto a ser entregue.

Descrição dos entregáveis acordados. - Restrições.

São os fatos que limitam a equipe do projeto e sobre a qual não se tem autonomia. - Premissas.

É uma teoria / hipótese que ajuda a chegar numa conclusão.

- Riscos iniciais.

Identificar e avaliar os riscos envolvidos e possíveis impactos organizacionais do projeto em questão.

Página 30

4.2 Levantamento de Requerimentos do Projeto.

Os requerimentos do projeto definem e documentam as necessidades das partes interessadas no que diz respeito ao cumprimento dos objetivos do projeto.

Esta fase deve ser realizada pelo analista de negócios da Millennium Network, que deve “ouvir” as necessidades do cliente e através dos mecanismos (templates / entrevistas / questionários) deve assegurar quais são as necessidades do cliente e como elas serão atendidas através dos nossos produtos.

Ainda neste mesmo processo, é preciso identificar e destacar:

- Estrutura de produtos, matérias-primas, materiais de consumo e serviços. - Processos de logística e estoques. - Processos de pedidos de venda. - Processos de faturamento. - Processos de compras. - Processos de bancos. - Processos de contas a pagar. - Processos de contas a receber. - Processos fiscais. - Processos de consignação. - Processos de produção. - Processos de varejo. - Processos de CRM. - Processos de BI. - Processos contábeis. - Processos de planejamento. - Infra-estrutura (servidores, links, desktops, impressoras, etc ...). - Processos de conversão de dados (documentação da base a ser convertida). - Possíveis customizações.

Com estas informações o analista de negócio deve formatar um documento com base no template “LEVANTAMENTO DE REQUERIMENTOS”.

Este documento deve ter uma breve descrição de cada item citado acima, suficiente para deixar claro para o cliente e para a Millennium como um todo, quais os requerimentos devem ser atendidos e em que abrangência.

O levantamento de requerimentos, também, balizará o fechamento comercial, portanto nele devem existir também os parâmetros de horas necessárias para a implantação do escopo levantado.

Em casos em que haja conversões de dados ou customizações, o analista de negócios, deve encaminhar essas necessidades para o departamento de desenvolvimento da Millennium, que por sua vez deve estimar prazos e custos para o fechamento comercial.

Página 31

4.3 Plano de Projeto.

Em posse do Termo de Abertura, e do Prospect fornecido pelo Comercial, o Gerente de Projeto designado para este projeto deve reunir as informações pertinentes ao projeto, para que seja possível planejar a execução do mesmo.

O Gerente de Projeto designado deve criar a WBS (Estrutura Analítica do Projeto), tomando por base as necessidades e expectativas do cliente em relação ao produto final.

Tendo em vista o contexto do projeto, o Gerente de Projeto designado deve planejar todas as fases do projeto (em ordem: Planejamento; Análise; Construção; Testes; Treinamento; e Produção), onde deve incluir qual o escopo de cada fase, documentos entregáveis por fase, pessoas envolvidas. Se estas fases se repetirão, descrever quando isto ocorrerá e por que.

Desenvolver o cronograma do projeto, seguindo as fases descritas e planejadas, incluindo marcos importantes do projeto, e datas de entrega de documentos.

Criar matrizes de Plano de Comunicação, Riscos, Stakeholders, Papéis e Responsabilidades, criar organograma do projeto, e todos os outros tópicos listados no Template Plano de Projeto.

O Documento “Plano de Projeto” deve ser criado pelo Gerente de Projeto, com auxílio de um Consultor de Implantação e com suporte do Escritório de Projetos. Este documento deve incluir todos os tópicos listados em seu template, seguindo a mesma ordem disposta, salvo exceções as quais devem ser aprovadas pelo Escritório de Projetos.

Representando papel de suporte, o Escritório de Projetos deve validar o Documento Plano de Projeto criado pelo Gerente de Projeto em sua totalidade, a fim de garantir a qualidade do material a ser entregue ao cliente. O Escritório de Projetos tem autonomia para sugerir alterações, inclusões e exclusões no Documento de Escritório de Projetos, porém o Escritório de Projetos nunca irá criar ou editar o documento, de responsabilidade do Gerente de Projeto. Este documento pode sofrer alterações durante a evolução do projeto, porém uma versão final deve ser assinada antes do início das fases seguintes do projeto.

O Gerente de Projeto designado deve apresentar o documento Plano de Projeto impresso para o cliente, incluindo seus stakeholders e sponsors. O Plano de Projeto poderá ser entregue em formato eletrônico somente a título de informação, porém com o intuito de ter uma via assinada, este documento deve ser impresso. O cliente deve ler e concordar com os tópicos e termos descritos no Plano de Projeto. Caso haja ressalvas por parte do cliente, estas devem ser analisadas, discutidas e incluídas no Plano de Projeto.

Uma vez que o Plano de Projeto foi conferido e acordado por parte do Cliente, este deve ser assinado.

Em posse do documento Plano de Projeto assinado, o Gerente de Projeto deve retornar o documento à Millennium, onde o mesmo deve ser arquivado, segundo as normas de arquivamento de documentos impressos e assinados.

• Estrutura do Documento “Plano de Projeto”:

O Plano de Projeto é uma composição de diversos tópicos complementares, ferramentas de controles, e documentos auxiliares. Segue abaixo a lista com estes tópicos, e uma breve explicação para cada item.

o Requerimentos do Projeto: Levantamento inicial executado pelo Analista de Negócios, antes do envolvimento da área de Consultoria de Implantação.

Página 32

o Estrutura Analítica do Projeto (WBS): Estrutura montada a partir das entregas requeridas pelo projeto.

o Declaração de Escopo do Projeto: A declaração do escopo do projeto descreve, em detalhes, as entregas do projeto e o trabalho necessário para criar essas entregas. Também descreve os principais objetivos do projeto.

o Premissas: Premissas são, em planejamento, consideradas verdades ou questões reais, que podem comprometer todo o projeto caso não aconteçam. As premissas como parte do processo de planejamento são menos detalhadas e numerosas.

o Restrições: Restrições específicas do projeto associadas ao escopo que limitam as opções de planejamento. Por exemplo, normalmente são incluídos um orçamento predefinido ou datas impostas por alguém externo à equipe do projeto.

o Cronograma: Deve ser planejado com base em datas reais, seguindo restrições impostas pelo cliente, e seguindo disponibilidade de agenda dos recursos. Deve ser distribuído por fase de projeto, e deve ser seguido e atualizado com freqüência estipulada.

o Estrutura Organizacional do Projeto: Corresponde à estrutura das pessoas ou grupo de perfis necessários para empreender todo o serviço necessário para completar o produto ou serviço do projeto. Não pode ser confundida com a estrutura de organograma da organização em questão.

o Papéis e Responsabilidades: Matriz em que os papéis envolvidos no projeto têm suas atribuições definidas para cada tarefa (ou pacote de tarefas) através de uma legenda informando qual sua responsabilidade.

o Plano de Comunicação: Determinação das necessidades de informações e comunicações das partes interessadas no projeto. Um quadro simples pode ser formado contendo “o que” deve ser informado; “para quem”; “com que freqüência”; e “através de que meio”.

o Matriz de Stakeholders: Lista com os principais envolvidos no projeto por parte do cliente, contendo os principais meios de contato.

o Matriz de Riscos: Inclui os processos que tratam da realização de identificação, análise, respostas, monitoramento e controle e planejamento do gerenciamento de riscos em um projeto; a maioria desses processos é atualizada durante todo o projeto.

o Gerenciamento de Mudanças: Durante todo o projeto, é possível que haja alterações das necessidades, levando a desvios no escopo do projeto e afetando custos, tempos e recursos. Estes casos devem ser solicitados através de Solicitações de Mudança (Template anexo), que devem passar

Página 33

por aprovação de um comitê que envolva tanto o cliente quanto a Millennium. Todas as solicitações de mudança devem ser controladas através do documento Acompanhamento de Mudanças (anexo).

o Estimativa e Controle de Custos / Orçamento: Desenvolvimento de uma estimativa dos custos dos recursos necessários para terminar as atividades do projeto, e agregação dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos.

o Questões em Aberto: São questões levantadas durante as fases iniciais do projeto, que devem ser respondidas sempre que haja risco envolvido.

o Lições Aprendidas: Lista das execuções e planejamentos malsucedidos durante todo o projeto. Esta lista deve ser arquivada para base de conhecimento, e deve ser evitada em projetos futuros.

Página 34

4.4 Reunião de Kick-Off

O gerente de projetos deve criar um documento com auxílio de um consultor de implantação e com suporte do escritório de projetos. Este documento deve incluir todos os tópicos listados em seu template, seguindo a mesma ordem disposta, salvo exceções as quais devem ser aprovadas pelo escritório de projetos. Este documento é um entregável, e deve ser apresentado em caráter oficial para o cliente.

O gerente de projeto designado deve apresentar a reunião de Kick-off, com uma duração média de duas horas, podendo ser encurtada ou agregada caso necessário. O público alvo de uma reunião de Kick-off são:

- por parte do cliente

Os usuários chave

Os stakeholders

Os sponsors

O dono / presidente / maior acionista ou semelhante.

- por parte da Millennium

Representante da área comercial que vendeu o projeto e/ou fechou o contrato

Gerente de Projeto

Consultores de Implantação

Demais membros da equipe quando houver.

A presença de um sponsor por parte da Millennium é altamente recomendada.

Pontos importantes a serem mencionados no Kick-off.

o O cliente deve ter ciência da quantidade de horas contratadas;

o O cliente deve acompanhar atentamente o uso das horas;

o A Ordem de Serviço (O.S.) é um documento emitido pelo Consultor da Millennium, todos os

dias em que prestarmos serviços à sua empresa.

o Este documento tem como objetivo registrar todas as tarefas desenvolvidas em sua empresa,

o horário em que elas foram executadas e o tempo de duração. Sua assinatura é muito

importante na Ordem de Serviço, pois demonstra que você está ciente dos serviços prestados

e concorda com os mesmos;

o Sua empresa adquiriu um pacote de horas para treinamento e implantação que pode ou não

ser suficiente para a implantação total do software, portanto, caso essas horas não sejam

suficientes, sua empresa precisará de horas adicionais, que deverão ser pagas mediante a

apresentação da relação das Ordens de Serviços devidamente assinadas pelo responsável da

empresa;

Página 35

o Qualquer tipo de customização ou novos desenvolvimentos solicitados exclusivamente por sua

empresa terão seus custos, prazos de entrega e homologação estabelecidos após a análise do

departamento técnico da Millennium para a aprovação de sua empresa;

o Na hipótese da Millennium prestar serviços no ambiente de trabalho de sua empresa ou

atendê-la de forma remota, via telefone, fora do horário de atendimento contratado, das 8:00

horas às 18:00 horas de segunda-feira a quinta-feira e das 8:00 às 17:00 às sextas-feiras, estes

serviços serão cobrados conforme nossa tabela de preços vigente com acréscimo se 60%

(sessenta por cento) no valor do serviço;

o As visitas técnicas realizadas pela Millennium relativas à re-treinamento, novas configurações,

ajustes e criação de layouts de documentos, orientações gerais, esclarecimentos de dúvidas

operacionais, reuniões para ajustes da implantação inicial, atualização de versão entre outros

serviços serão cobrados a parte, conforme nossa tabela de preços vigente; e

o Atente-se a quantidade de licenças de uso do programa de processamento eletrônico de

dados.

4.5 Levantamento detalhado de requerimentos.

Uma vez que o cliente tenha fechado negócio com a Millennium, o projeto tenha sido divulgado para toda a empresa, uma das primeiras atividades do gerente de projetos é detalhar os requerimentos levantados inicialmente, com a finalidade de validar o levantamento inicial e aprofundar o entendimento da solução que o cliente está aguardando receber. Neste momento, o gerente de projetos, deve levar em consideração:

- As prioridades de entregas do projeto. - O de/para do que foi levantado inicialmente para as ferramentas disponíveis nos produtos da Millennium Network. - O impacto das entregas, conversões de dados e customizações previstas no projeto.

A base para o detalhamento é o documento de requerimentos realizado pelo analista de negócios e caso haja qualquer dúvida, o GP deve consultá-lo, sanar a dúvida e então dar continuidade.

Página 36

4.6 Requisitos para customização.

Os requisitos para customização definem e documentam as necessidades de desenvolvimentos para cumprimento dos objetivos do projeto. Há dois tipos de templates para o analista de requisitos usar, sendo que um deve ser usado em situações mais simples e outro em situações mais específicas, a saber: - Template de requisitos – simplificado: Visão Geral do Requisito Descreve o objetivo do requisito, suas respectivas funcionalidades, qual o público alvo do sistema, qual a necessidade de implementar o produto, o impacto do sistema e sucesso que a solução irá trazer.

Usuários Discriminar todos os usuários envolvidos no requisito.

Descrição do Problema (Motivação) Descreve qual o problema enfrentado atualmente, e que gerou a necessidade de uma customização.

Parâmetros Utilizando Notação BPMN, desenhar o processo a ser beneficiado com o requisito.

Entradas Descreve quais parâmetros e configurações são necessárias para que o processo possa ser realizado.

Saída Qual o produto do processo, o que ele produziu ao final de sua execução.

Validações Como pode ser analisado se o requisito desenvolvido está correto, como ele pode ser validado.

Premissas Descreve as premissas que estarão sendo adotadas durante a descrição do requisitos:

Requisitos Funcionais Descreve os requisitos funcionais a ser implementado. Na prática o que deverá ser programado.

- Template de requisitos – completo: Visão Geral do Requisito Descreve o objetivo do requisito, suas respectivas funcionalidades, qual o público alvo do sistema, qual a necessidade de implementar o produto, o impacto do sistema e sucesso que a solução irá trazer.

Usuários Discriminar todos os usuários envolvidos no requisito.

Descrição do Problema (Motivação) Descreve qual o problema enfrentado atualmente, e que gerou a necessidade de uma customização.

Desenho do processo Utilizando Notação BPMN, desenhar o processo a ser beneficiado com o requisito.

Parâmetros Descreve quais parâmetros e configurações são necessárias para que o processo possa ser realizado.

Página 37

Entradas Qual o caminho a ser seguido para executar o processo depois do requisito desenvolvido.

Saída Qual o produto do processo, o que ele produziu ao final de sua execução.

Validações Como pode ser analisado se o requisito desenvolvido está correto, como ele pode ser validado.

Premissas e restrições Descreve as premissas que estarão sendo adotadas durante a descrição dos requisitos:

° <premissa 1>:<descrição>

° <premissa 2>:<descrição>

Requisitos Funcionais

São descritos os requisitos funcionais do sistema a ser implementado. Na prática o que deverá ser programado.

Requisito funcional 1.

Descreva nesta seção o requisito funcional 1.

Requisito funcional 2.

Descreva nesta seção o requisito funcional 2.

Análise de Risco. Através de alguns índices procura-se identificar o risco do requisito, basta preencher a tabela abaixo para identificar o grau de risco do requisito.

Página 38

Risco do Requisito:

No. QuestionamentoSIMNÃO

Valor Padrão Valor Peso Colunas1

1

Cliente já tem processo no sistema atual e pretende implementar

exatamente igual 30 0 1 0

2

Cliente já tem processo no sistema atual e pretende implementar com

pequenas alterações 50 0 1 0

3

Cliente já tem processo no sistema atual e pretende implementar com

muitas alterações 80 0 1 0

4 Cliente não tem o processo atual e quer implementar 80 0 1 0

5

Cliente já tem processo em sistema paralelo e pretende implementar

exatamente igual 30 0 1 0

6

Cliente já tem processo em sistema paralelo e pretende implementar com

pequenas alterações 50 0 1 0

7

Cliente já tem processo em sistema paralelo e pretende implementar com

muitas alterações 80 0 1 0

8 O usuário não tinha dúvidas em relação ao processo descrito 30 0 1 0

9 O usuário tinha poucas dúvidas em relação ao processo descrito 50 0 1 0

10 O usuário tinha muitas dúvidas em relação ao processo descrito 80 0 1 0

11 O usuário tem dominio da operação que está realizando 30 0 1 0

12 O usuário não tem dominio da operação que está realizando 80 0 1 0

13

Este processo interfere diretamente em outro(s) processo(s) que serão

customizados 80 0 1 0

14

Este processo não interfere diretamente em outro(s) processo(s) que

serão customizados 30 0 1 0

15 O processo é demasiadamente importante para o cliente 80 0 1 0

16 O processo não é demasiadamente importante para o cliente 30 0 1 0

17 O processo é de pequeno porte / tamanho 30 0 1 0

18 O processo é de médio porte / tamanho 50 0 1 0

19 O processo é de grande porte / tamanho 80 0 1 0

Uma vez que o template tenha sido preenchido com todas as informações acima, deve passar por aprovação dos usuários que fizeram a solicitação, devendo ser assinado por todos os envolvidos:

- Sponsor. - Gestor. - Usuários chave. - Usuário solicitante. - Gerente de projetos (Millennium). - Super visor de desenvolvimentos (Millennium). - Analista de requisitos (Millennium).

Página 39

4.7 Entrega de customização

O processo de entrega das customizações é evolutivo, e deve ter pelo menos dois pontos de iteração com o cliente para aferição dos desenvolvimentos em conformidade com os requisitos.

Desta forma, um desenvolvimento deve ter pelo menos 2 pontos de checagem antes da entrega definitiva e estes pontos de checagem, além de trazerem o cliente para mais perto da solução fundamentada, evita retrabalhos e desgastes futuros.

Ponto de verificação 01 – TESTE DE SISTEMA

Acontece durante o processo de desenvolvimento e tem a finalidade de manter alinhado o levantamento de requisitos, com o desenvolvimento e as expectativas do cliente.

Requer a presença do cliente, preferencialmente na Millennium, em conjunto o gerente de projetos, o consultor e o programador.

Neste momento serão feitas verificações específicas sobre a funcionalidade do processo customizado, em versão BETA (TRUNK) e o cliente dará seu parecer sobre o assunto.

Ao final, deve-se ter uma opinião comum dos envolvidos se o desenvolvimento está dentro do previsto e caso precise de algum ajuste, deve ser discutido e documentando neste momento.

Devemos documentar esse ponto de verificação com o aceite do cliente, para que a customização seja enviada para a versão de testes.

Ponto de verificação 02 – TESTE DE ACEITAÇÃO

Acontece durante o processo de desenvolvimento e tem a finalidade de manter demonstrar possíveis alinhamentos levantados na verificação inicial. Requer a presença do cliente, preferencialmente na Millennium, do gerente de projetos, do consultor e do programador.

Neste momento serão feitas verificações sobre a funcionalidade do processo customizado, suas validações e processos integrados à customização, em versão de testes (BRANCHES) e o cliente dará seu parecer sobre o desenvolvimento.

Ao final, deve-se ter uma opinião comum dos envolvidos se o desenvolvimento está como previsto e caso precise de algum ajuste, deve ser discutido e documentando neste momento.

Devemos documentar esse ponto de verificação com o aceite do cliente, dando ciência que a próxima etapa é colocar o desenvolvimento em uma versão de produção (congelada), acordando com o cliente a data em que o release com essa funcionalidade será entregue e, portanto não será possível fazer alterações no processo customizado doravante.

Entrega Final.

É quando a versão congelada é gerada e atualizada no ambiente de produção do cliente.

A partir deste momento, o cliente deve dar o aceite no desenvolvimento e colocá-lo em produção.

Eventuais necessidades e solicitações de alterações no processo entregue passarão por nova análise de requisitos.

Página 40

4.8 Integridade da Base de Dados.

Em alguns projetos, o cliente necessita de conversão de dados do sistema legado para os sistemas da Millennium e nestas situações algumas providencias precisam ser adotadas, para garantir que desde o início essa operação tenha sucesso.

Documentação da base de dados.

É fundamental que o cliente que deseja realizar uma conversão de dados de seu sistema legado para os sistemas da Millennium tenha a documentação de sua base de dados.

As informações sobre a base de dados a ser importada, devem ser claras, atualizadas e objetivas (tipo de banco de dados utilizado, nome da base de dados, nome e descrição das tabelas, nome, descrição, formato e aplicação dos campos).

Caso o cliente não tenha uma documentação da base de dados que será convertida, é possível enviar um layout da base de dados do produto da Millennium onde os dados serão convertidos e o cliente deve providenciar a preparação das informações no formato deste layout.

É preciso deixar claro para o cliente que a qualidade dos dados contidos na base que será convertida para o produto da Millennium é de inteira responsabilidade dele e que após a conversão ele também será o responsável pela validação destas informações na base de dados do produto da Millennium.

Conversão.

De posse da documentação da base de dados que será convertida, o gerente do projeto deve cadastrar uma solicitação de desenvolvimento no M3, avaliar com o responsável pelo desenvolvimento o prazo de conclusão desta tarefa e documentar.

É importante informar ao cliente que mesmo com a base documentada o desenvolvedor precisará de uma reunião para alinhamento e solução de dúvidas antes de iniciar o processo de conversão.

Entrega.

O processo de entrega se dá em duas etapas, a saber:

- Testes da conversão em ambiente paralelo (ambiente de testes).

Após estes testes o cliente deve se comprometer com a validação das informações convertidas. Após a validação deve-se documentar eventuais ajustes que serão feitos e validados ainda em ambiente de testes e o cliente deve dar o aceite para que a conversão seja feita em produção.

- Conversão em ambiente de produção.

Uma vez realizados os testes e ajustes, deve ser feita a conversão em ambiente de produção, lembrando ao cliente que esta somente será feita mediante seu parecer positivo, já que uma vez feita, é bastante improvável realizar ajustes, dadas as complexidades deste ambiente.

Página 41

4.9 Resumo e Aceite dos Testes.

4.9.1 Testes Operacionais

Após o sistema parametrizado com as customizações instaladas, e com o Termo de Aceite de Configuração do Sistema assinado pelo cliente, um Consultor de Implantação da equipe do projeto deve realizar a bateria de testes no sistema, com uma base de testes com massa de dados reais do cliente, seja por amostragem ou não, realizando todos os procedimentos implementados no ambiente do cliente.

Após realizar todos os testes, e caso não sejam apresentados erros, o consultor de implantação dará por encerrado a bateria de testes, e deve preencher o documento de Resumo dos Testes.

Caso sejam apresentados erros, o consultor de implantação deve configurar os parâmetros do sistema que geraram os erros, garantindo que o sistema esteja de acordo com o escopo definido.

O documento de Resumo dos Testes deve incluir a descrição de como os testes foram desempenhados, incluindo situação da base de dados, local dos testes, tempo decorrido, tipo de testes executados, erros apresentados e ações corretivas. Para facilitar, é sugerido que este documento seja preenchido em paralelo aos testes, para que não seja necessário tempo extra para sua criação, e para que haja garantia de que todos os passos executados estejam listados no documento.

4.9.2 Testes Funcionais

Após o sistema parametrizado com as customizações instaladas, e com o Termo de Aceite de Configuração do Sistema assinado pelo cliente, o Gerente de Projeto deve realizar a bateria de testes no sistema, com a base do cliente, na infra-estrutura do cliente, contanto com massa de dados reais do cliente, em sua totalidade, realizando todos os procedimentos implementados no ambiente do cliente.

Por parte do cliente, os usuários chave devem participar dos testes, não necessariamente executando-os, mas com a intenção de validá-los.

Após realizar todos os testes, e caso não sejam apresentados erros, o Gerente de Projeto dará por encerrado a bateria de testes, e deve solicitar que o consultor de implantação preencha o documento de Resumo dos Testes.

Caso sejam apresentados erros, o consultor de implantação deve configurar os parâmetros do sistema que geraram os erros, acompanhado pelo Gerente de Projeto, garantindo que o sistema esteja de acordo com o escopo definido. Uma nova bateria de testes deve ser executada juntamente com o cliente, a fim de concluir todos os processos implementados sem apresentação de erros de configuração.

O documento de Resumo dos Testes deve incluir a descrição de como os testes foram desempenhados, incluindo situação da base de dados, local dos testes, tempo decorrido, tipo de testes executados, erros apresentados e ações corretivas. Para facilitar, é sugerido que este documento seja preenchido pelo consultor de implantação em paralelo aos testes executados pelo Gerente de Projeto, para que não seja necessário tempo extra para sua criação, e para que haja garantia de que todos os passos executados estejam listados no documento.

Uma vez que todos os procedimentos implantados na infra-estrutura do cliente foram testados na presença dos usuários chave, os stakeholders devem concordar com a finalização dos testes, e firmar o documento Aceite do Usuário.

Página 42

Para a criação deste documento, deve ser utilizado o template Status Report. Este documento deve conter a descrição, em um nível macro, da realização dos testes operacionais e funcionais, do sucesso da execução e demais itens relevantes ocorrido durante esta fase. Este documento deve ser assinado em via impressa pelos stakeholders do cliente.

4.10 Treinamento.

Após o sistema parametrizado com as customizações instaladas, e com o Termo de Aceite dos Testes no Sistema assinado pelo cliente, o Gerente do Projeto deve encaminhar o Cliente (Usuários chave, gestor e demais envolvidos) para a fase de treinamento. Este treinamento deve ser realizado com a base do usuário, na mesma versão instalada, e com as customizações previstas.

Um Consultor de Implantação e/ou um Técnico de Treinamento da equipe Millennium deve verificar a base de dados e a versão do software do ambiente de treinamento, a fim de checar a compatibilidade com o sistema instalado no cliente a ser treinado.

O Consultor de Implantação e/ou um Técnico de Treinamento da equipe Millennium vigente no momento, seguindo o cronograma previsto na fase de planejamento. Este treinamento deve ser aplicado preferencialmente individual a cada projeto, ou seja, em um mesmo ambiente de treinamento é recomendado que não haja clientes diferentes. Este treinamento pode ser aplicado nas dependências do Centro de Treinamento Millennium, no cliente, ou ainda em ambiente externo (centro de convenção, etc.), desde que haja infra-estrutura adequada para tal, e que custos incorridos excedentes ao previsto (horas extras, aluguel de material, etc.) sejam repassados diretamente ao cliente.

4.11 Promoção à Produção (Go-Live) e Aceite Final.

O Gerente de Projeto deve conferir com o Centro de Treinamento Millennium, ou outro departamento responsável designado para o projeto, que todos os treinamentos dos usuários chave foram executados com sucesso, antes de dar início à fase de produção.

Este documento deve elencar todas as filiais e matrizes que passarão do ambiente de testes para ambiente de produção, em que data e horário, e executado por quem. Deve incluir plano de Fall Back (restauração do sistema antigo) caso haja problema durante o ligamento do sistema, processo de desligamento do sistema anterior, e a forma de acompanhamento do sistema em produção pela área de implantação, caso contratado. Deve ainda incluir premissas e restrições, como por exemplo, não executar o go-live em fins de semana, e preferir de segundas à quartas-feiras onde a movimentação do cliente é menor e facilita a execução do ligamento do sistema. Caso cliente deseje executar o go-live fora dos padrões pré-estabelecido em melhores práticas Millennium, isto implica em custos adicionais, que deve ser acordado entre o cliente e a área comercial, por ter de envolver técnicos de helpdesk, desenvolvimento, e outros recursos em horário deslocado.

O cliente deve ler e concordar com o documento de Estratégia de Promoção à Produção. Este documento deve ser assinado antes da execução da passagem para ambiente de produção, dada a sua criticidade.

Página 43

Com a finalidade de informar e envolver as demais áreas da Millennium, para que estas tomem as

ações cabíveis, o Gerente de Projeto deve comunicá-las de que o cliente em questão passará para

ambiente de produção na data especificada. As principais áreas a serem notificadas são

Desenvolvimento e Helpdesk, porém outras áreas podem ser notificadas caso haja relevância notada

pelo Gerente do Projeto.

A área de Desenvolvimento pode ser amplamente envolvida durante a passagem para produção do

sistema, pois os problemas que venham a ocorrer devem ser sanados em tempo hábil que não

impacte o cliente. Para isto, é possível que em determinados projetos, a ser definido pelo Gerente de

Projeto, um recurso da área de Desenvolvimento seja alocado durante a promoção à produção.

O HelpDesk deve ser notificado pois assim que o cliente entrar em ambiente de produção, o contato

deixará de ser executado através da área de implantação, e será realizado através do HelpDesk. O

HelpDesk deve receber informações da situação do ambiente do cliente, versão instalada, quantidade

de usuários a ser atendida, data do início do suporte, e outras informações relevantes e convenientes

que o HelpDesk venha a solicitar.

Ainda sim, demais áreas também devem ser notificadas, a fim de que estas realizem seus

procedimentos internos definidos por cada uma delas.

A execução da Promoção à Produção deve ser tratada como um evento, e com toda a sua importância,

deve contar com a presença dos principais responsáveis pelo projeto, tanto por parte da Millennium

quanto por parte do cliente – Gerente de Projeto, Consultores de Implantação, e o Gestor de TI do

cliente, são presenças obrigatórias. Outras pessoas podem ser envolvidas sempre que necessário.

Esta execução deve seguir à risca a estratégia de promoção à produção, para que haja o menor

impacto possível no ambiente do cliente.

Esta etapa deve ser executada logo após a passagem para a produção do sistema implantado. O

desligamento do sistema anterior pode ser executado de diversas formas diferentes, e devem ser

previstas na estratégia de promoção à produção. A título de exemplo, uma técnica simples de

desligamento do sistema anterior é feita através da passagem para a produção dos processos fiscais

ou contábeis do cliente.

Após a estabilização do ambiente de produção, o cliente deve concordar com o sistema em

funcionamento. Caso haja ressalva por parte do cliente, deverá ser revisto em contrato o que há de

dissonante, para que seja sanado no prazo mais curto possível. Caso o motivo da discordância não

esteja previsto em contrato, neste momento não cabe abrir uma solicitação de mudança, mas sim

encerrar o projeto, com a assinatura do Termo de Aceite Final, e iniciar um segundo projeto, com

novos prazos, cronogramas, planejamentos e afins. Nestes casos, poderá ser necessária a solicitação

de auxílio da área comercial no que diz respeito ao relacionamento do cliente perante o contrato.

Uma vez o cliente tendo aceitado o sistema em produção, o documento de Termo de Aceite Final deve

ser criado, contendo as disposições finais do projeto, relatando todos os produtos entregues, os

marcos principais do projeto, informações importantes para o cliente como ponto de contato,

solicitações e outros serviços. Este termo de aceite deve ser diferenciado por cada projeto, envolvendo

cada particularidade, contudo deve seguir o padrão contido no template de Termo de Aceite Final.

Página 44

Este documento deve ser impresso, apresentado ao cliente pelo Gerente de Projeto, e assinado pelo

sponsor do cliente. Sempre que possível um representante da área Comercial da Millennium deverá

estar presente.