METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM NETWORK

Transcrição

1 METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM NETWORK Agosto de 2009 Página 1

2 Sumário 1 CONCEITOS Ciclos de vida do projeto e do produto Grupos de processos de gerenciamento de projetos Fases do projeto e processos de gerenciamento de projetos Coordenação de Projetos Elaboração Progressiva Áreas de conhecimento envolvidas no projeto Identificação de entregas e Escopo do Projeto Criando a Estrutura Analítica do Projeto Declaração do escopo do projeto Estrutura Escritório de Projetos Escritório de Projetos Objetivos do Escritório de Projetos: FLUXO DE PROCESSOS Fases de Projeto Fluxo Nível Fluxo Nível 1 (Página 1) Fluxo Nível 1 (Página 2) Fluxo Nível 1 (Página 3) Fluxo Nível Fluxo Nível 2 Pré-Projeto (Página 1) Fluxo Nível 2 Planejamento (Página 2) Fluxo Nível 2 Análise (Página 3) Fluxo Nível 2 Construção (Página 4) Fluxo Nível 2 Testes (Página 5) Fluxo Nível 2 Treinamento (Página 6) Fluxo Nível 2 Promoção à Produção (Página 7) METODOLOGIA DE IMPLANTAÇÃO MILLENNIUM Termo de abertura do projeto Levantamento de Requerimentos do Projeto Plano de Projeto Reunião de Kick-Off Levantamento detalhado de requerimentos Requisitos para customização Entrega de customização Integridade da Base de Dados Resumo e Aceite dos Testes Página 2

3 4.9.1 Testes Operacionais Testes Funcionais Treinamento Promoção à Produção (Go-Live) e Aceite Final Página 3

4 1 CONCEITOS 1.1 Ciclos de vida do projeto e do produto 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. Grupo de processos de 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ção Integra 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. Grupos de processos de gerenciamento de projetos Página 4

5 1.1.2 Fases do projeto e processos de gerenciamento de projetos Projeto Ciclo de vida do projeto Fases do ciclo de vida do projeto Ciclo de vida de gerenciamento do projeto Fases do projeto e processos de gerenciamento de projetos Página 5

6 1.2 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. 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, ser especificado de formas diferenciadas. Página 6

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: Comunicação Custo Escopo Tempo Integração Qualidade Recursos Humanos Risco Contratos e Aquisições Áreas de Conhecimento de um projeto Página 7

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) 1 História Entregas e sub entregas 1.1 Definição de Roteiro Roteiro inicial Roteiro estruturado 1.2 Definição de Texto Diálogos Marcações Página 8

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 Elenco principal definido Elenco principal contratado 2.3 Demais Atores e figurantes contratados 2.4 Contratação de Técnicos Maquiadores contatados Figurinistas contratados 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 Cenas editadas Efeitos especiais adicionados Falas sincronizadas 4 Gestão do Projeto 4.1. Plano de projeto 4.2 Orçamento Orçamento Aprovado Controle orçamentário 4.3 Cronograma Cronograma Geral Aprovado Controle do cronograma Cronograma diário revisado 4.4 Acompanhamento Integrado 4.5 Riscos Identificação Resposta planejada ou de contorno 4.6 Encerrramento Reunião de Informações históricas Encerramento de contratos e do projeto Página 9

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: Filme História Pessoal Produção Gestão do Projeto Definição de Roteiro Produtor e diretor definidos Cenas detalhadas Plano de projeto Roteiro inicial Roteiro estruturado Definição de Texto Seleção e Contratação do Elenco principal Elenco principal definido Elenco principal contratado Tomadas determinadas na ordem do dia Finalização Orçamento Orçamento Aprovado Controle orçamentário Cronograma Cronograma Geral Aprovado Diálogos Marcações Indicações de interpretação Demais Atores e figurantes contratados Contratação de Técnicos Maquiadores contratados Figurinistas contatados Cenas editadas Efeitos especiais adicionados Falas sincronizadas Controle do Cronograma Cronograma Diário Revisado Acompanhamento integrado Riscos Resposta planejada ou de controle Identificação Técnicos de som, luz e filmagem contratados Encerramento Reunião informações históricas Estrutura Analítica do Projeto Filme Encerramento contratos e projeto 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. Página 10

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 11

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 12

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% Descrição do escopo do produto. do montante investido. 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. Entregas do projeto. Critérios de aceitação de produtos A distribuição não fará parte do escopo do projeto. Definidas na Fig. 7.1 Estrutura Analítica do projeto Filme 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 Patrocinador (Produtor), Ger. Projeto (Diretor), Roteiristas. projeto. 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 13

14 Declaração de Escopo do Projeto Filme continuação Marcos do Julho de 20xx - aprovação do orçamento; Agosto de 20xx - início das filmagens; cronograma. De 303m 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 Requisitos do gerenciamento de configuração do projeto. Especificações do projeto. Requisitos de aprovação. 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. 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. 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 Qualquer alteração entre os valores de e pode ser aprovada pelo patrocinador ou produtor do projeto. Página 14

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 15

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 16

17 3 FLUXO DE PROCESSOS 3.1 Fases de Projeto Página 17

18 3.2 Fluxo Nível Fluxo Nível 1 (Página 1) Página 18

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

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

21 3.3 Fluxo Nível Fluxo Nível 2 Pré-Projeto (Página 1) Processos que Antecedem o Início do Projeto Analisa Requerimentos e Customizações Identificadas Designa Gerente de Projeto Forma Equipe Divulga Projeto, Equipe e Cliente para toda a empresa Analista de Negócios analisa e dimensiona risco, custo e tempo de Implantação Informações sobre Cursos, Conhecimento, e Projetos anteriores dos GPs GP analisa complexidade / perfil do projeto GP reúne informações da equipe e do projeto Requerimentos do Projeto EP analisa conhecimento do Gerente de Projeto Informações sobre Cursos, Conhecimento, e Projetos anteriores dos Consultores Termo de Abertura S Desenvolvimento estima: Horas (Levantamento, Desenv., e Homologação); e Prazo Há customizações? N M3 Agenda de disponibilidade dos GPs EP verifica disponibilidade do Gerente de Projeto EP sugere Gerente para Projeto M3 Agenda de disponibilidade dos Consultores GP analisa conhecimento do Consultor GP verifica disponibilidade do Consultor GP envia Termo de Abertura para Escritório de Projetos Escritório de Projetos divulga projeto para toda a empresa via Requerimentos do Projeto Atualizado Comitê / Diretoria aprova alocação? N EP valida equipe e aloca Consultor Inicia Fase PLAN. S EP comunica GP e apresenta prospect do cliente GP comunica Consultor e apresenta prospect do cliente Página 21

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

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

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

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

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

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

28 Página 28

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 29

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 30

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 31

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 32

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 33

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 34

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 35

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 36

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 37

38 Risco do Requisito: No. Questionamento SIM NÃO Valor Padrão Valor Peso Colunas1 Cliente já tem processo no sistema atual e pretende implementar 1 exatamente igual Cliente já tem processo no sistema atual e pretende implementar com 2 pequenas alterações Cliente já tem processo no sistema atual e pretende implementar com 3 muitas alterações Cliente não tem o processo atual e quer implementar Cliente já tem processo em sistema paralelo e pretende implementar 5 exatamente igual Cliente já tem processo em sistema paralelo e pretende implementar com 6 pequenas alterações Cliente já tem processo em sistema paralelo e pretende implementar com 7 muitas alterações O usuário não tinha dúvidas em relação ao processo descrito O usuário tinha poucas dúvidas em relação ao processo descrito O usuário tinha muitas dúvidas em relação ao processo descrito O usuário tem dominio da operação que está realizando O usuário não tem dominio da operação que está realizando Este processo interfere diretamente em outro(s) processo(s) que serão 13 customizados Este processo não interfere diretamente em outro(s) processo(s) que 14 serão customizados O processo é demasiadamente importante para o cliente O processo não é demasiadamente importante para o cliente O processo é de pequeno porte / tamanho O processo é de médio porte / tamanho O processo é de grande porte / tamanho 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 38

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 39

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 40

41 4.9 Resumo e Aceite dos Testes 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 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 executandoos, 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 41

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