Implantação de um Data Warehouse Oceanográfico

CORTINOVIS, Ana Paula de Oliveira Santos ^[1]

CORTINOVIS, Ana Paula de Oliveira Santos. Implantação de um Data Warehouse Oceanográfico. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 03, Ed. 08, Vol. 01, pp. 5-91, Agosto de 2018. ISSN:2448-0959

Resumo

CORTINOVIS, Ana Paula de Oliveira Santos. Implantação de um Data Warehouse Oceanográfico. 2016. 100 f. Projeto final (Especialização em Tecnologia da Informação, Gestão de Negócios e de Projetos) – Instituto de Matemática e Estatística, Universidade do Estado do Rio de Janeiro, Rio de Janeiro, 2016.

A presente monografia tem como objetivo propor uma solução de Business Intelligence – BI, para armazenamento, processamento e qualificação de dados oceanográficos, contidos em planilhas de dados disponibilizadas pelos sites do Instituto Nacional de Pesquisas Espaciais – INPE, pelo Banco Nacional de Dados Oceanográficos – BNDO e por arquivos fornecidos pelos equipamentos utilizados nas coletadas em pesquisa em navios e estações oceanográficas e meteorológicas. Neste trabalho propomos a implantação de um Data Warehouse para análise dos dados oceanográficos coletados por pesquisadores através de projetos em conjunto com a Marinha do Brasil e empresas privadas a fim de ser realizado análise dos dados para projetos e pesquisas específicas.

Este trabalho visa apresentar todas as etapas que devem ser seguidas para o desenvolvimento e implantação de um Data Warehouse Oceanográfico, desde o planejamento até a governança da operação. O Data Warehouse Oceanográfico terá como principal objetivo a propagação e compartilhamento de informações para estudos mais aprofundados sobre os dados existentes. O Plano de Projeto foi construído de acordo com as boas práticas preconizadas no guia PMBOK® 5ª Ed.

Palavras-chave: Data Warehouse, Gestão de Projetos, PMBOK.

Introdução

Com a grande aceleração da globalização, a cada dia se tem a necessidade de entender melhor o comportamento do ambiente que vivemos a fim de tentar prever as grandes mudanças ambientais que possam vir a ocorrer.

A área de oceanografia tem como um dos propósitos estudar o comportamento dos oceanos, rios, lagos e estuários. Através de realização de pesquisas e estudos, poderem traçar um comportamento de mudança e possíveis evoluções de espécies e organismos vivos e não-vivos. São diversas áreas de atuação: oceanografia física, química, biológica e geológica.

A oceanografia é um exemplo de ciência multidisciplinar e interdisciplinar. Cada feição oceanográfica tem uma “assinatura” física, química, biológica e geológica. Por isso é necessário ter uma abordagem múltipla e articulada. Isto tem levado a que cientistas, curiosos e ávidos por entender mais e melhor, conscientes dessa multidisciplinaridade colaborem para responder à importantes questões. (Jorge P. Castello).

Baseados nesta demanda de se conhecer, analisar e estudar os dados que são obtidos pelos pesquisadores, teve-se a motivação de implantar um Data Warehouse Oceanográfico a fim de ajudar a tentar responder algumas perguntas e também descobrir algo novo a partir de padrões que vão sendo formados a partir da mineração dos dados.

O Brasil é um país com vocação e patrimônio marítimo, que tem no seu Mar Territorial e na sua Zona Econômica Exclusiva recursos naturais incomensuráveis, vivos e não-vivos, conhecidos ou por serem descobertos, em exploração ou ainda intocados, que precisam ser protegidos e racionalmente utilizados. (Luiz Carlos Krug).

Um Data Warehouse (DW) é um banco de dados não-relacional capaz armazenar dados de diversas formas e possibilitar analises rápidas e proveitosas sobre o dado armazenado.

1. Caracterização do cenário e ambiente onde se desenvolve o projeto

O presente trabalho trata da Divisão de Tratamento de Dados da organização OceanoBR. O principal objetivo é disponibilizar toda estrutura física, lógica e intelectual para o desenvolvimento do Data Warehouse Oceanográfico a fim de consolidar dados de oceanografia e de proporcionar à comunidade científica dados brutos frutos de coletas feitas por equipamentos hidrográficos, possibilitando assim a flexibilidade de utilização dos dados para análise que desejar.

1.1. Motivação

A tecnologia de DW é de suma importância em uma organização, porém, torna-se imperativo que as informações fornecidas por esses sistemas sejam consistentes e confiáveis, ou seja, não se trata de uma simples “armazenagem de dados”, os dados devem ser obtidos cuidadosamente a partir de várias fontes de dados da empresa ou em alguns casos, externamente a ela, e esses dados antes de serem difundidos devem ser filtrados, submetidos a um controle de qualidade e liberados quando estiverem prontos para serem utilizados. O trabalho apresentado não está pautado em uma empresa, tampouco existe uma fonte única de dados, eis o primeiro grande desafio e o maior motivador, a consolidação dos dados ambientais, gerando uma aplicação para comparação dos valores em relação ao tempo e para análise dos dados para diversas situações. No tocante ao aspecto legal e normativo às informações foram extraídas do site do INPE (Instituto Nacional de Pesquisas Espaciais) e do BNDO (Banco Nacional de Dados Oceanográficos)

1.2. Justificativas

O objetivo desse trabalho é a implementação de um DW para disponibilizar dados ambientais, destinados a estudantes, pesquisadores e a gerencia dos projetos para tomada de decisão.

Em linhas gerais, o escopo do trabalho se baseará coletar dados ambientais e divulga-los para todas as comunidades cientificas e empresas do ramo ambiental, para que o analista possa identificar a potencialidade de investimentos em pesquisas, instalação de novos equipamentos, proliferação de elementos não comuns em oceanos, possíveis desastres naturais com o objetivo de maximizar os ganhos e minimizar os riscos na operação.

1.3. Expectativas e resultado esperado

• Escolher os kits de desenvolvimento para o Data Warehouse;
• Identificar melhor as configurações de hardware e software;
• Buscar informações e treinamentos para cada tipo de desenvolvimento;
• Criar multiplicadores de conhecimento;
• Disponibilizar toda a estrutura física, lógica e intelectual para cada desenvolvimento realizado no projeto;

1.4. Benefícios

Ao final do projeto esperamos formar e capacitar os profissionais da organização no desenvolvimento e manutenção do banco de dados e nos sistemas de carga de dados, utilizando as ferramentas atualmente mais usadas no mercado e mitigar, consideravelmente, os custos com licenças de softwares.

Com o intuito de padronizar e gerenciar os projetos de TI, essa metodologia adaptou os processos descritos no guia Project Management Body of Knowledge (Guia PMBoK®) 5ª edição, contemplando:

• Seleção de processos apropriados e necessários ao cumprimento dos objetivos do projeto;
• Cumprimento dos requisitos para atender às necessidades e expectativas das partes interessadas;
• Busca de equilíbrio entre demandas concorrentes de escopo, tempo, qualidade, recursos e riscos, para gerar o produto, serviço ou resultado especificado.

2. Referencial teórico

Atualmente, a competitividade no mercado de trabalho e nos cargos de direção, estão tão acirrados que surge a necessidade da busca pela melhor organização, planejamento estratégico e melhores prática na execução das diversas atividades e tarefas que ocorrem quase de forma simultâneas. Para isso, vem crescendo a demanda de se especializar em novas técnicas, habilidade de como fazer da melhor forma e possuir ferramentas capazes de facilitar e proporcionar o resultado esperado no gerenciamento das atividades do projeto.

Para atendermos a essas novas demandas do ambiente globalizado e concorrente, iremos explanar mais à frente os aspectos que são importantes para se atingir ao nível de exigência que está sendo desejado pelas organizações. Abordaremos alguns conceitos que são de suma importância e desdobraremos cada item do gerenciamento de projeto.

2.1. Projeto

É de suma importância que o profissional de projeto, gerente de projetos, tenha de forma clara e solida os conceitos de projeto, tais como: O que é projeto?; o que constitui um projeto; quais os componentes de um projeto, a fim de poder aplicar e difundir para a equipe a qual está envolvida no projeto.

Um projeto é concebido a partir de uma ideia. Essa ideia é fragmentada em atividades e após conclusão das mesmas, o conjunto das atividades são materializadas e formam um produto.

“Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.” (Guia PMBOK® 5a edição)

Conforme citado no Guia PMBOK® 5ª edição, o projeto é temporário por estar ligado ao tempo, ou seja, tem início e fim e os mesmos são bem definidos. O projeto também produz resultado exclusivo, ou seja, é único. Por mais que tenhamos projetos parecidos, cada um deles é único, exclusivo, por possuis atores, ambiente, data e entre outros diferente de projetos já executados anteriormente.

“Projeto é um processo único, consistido de um grupo de atividades coordenadas e controladas, com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos.” (NBR 10006)

O Guia PMBOK (“A Guide to the Project Management Body of Knowledge”), é uma das ferramentas muito utilizadas em projetos e pelos gerentes de projetos. Neste guia é encontrado uma vasta gama de conhecimentos e técnicas baseadas em melhores práticas em que o gerente de projeto poderá aplicar no seu projeto.

O Guia do conhecimento em Gerenciamento de Projetos (Guia PMBOK) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é um documento formal que descreve normas, métodos, processos e práticas estabelecidas. Assim como em outras profissões como advocacia, medicina e contabilidade, o conhecimento contido nesse padrão evoluiu a partir de boas práticas reconhecidas de profissionais de gerenciamento de projetos que contribuíram para o seu desenvolvimento. (Guia PMBOK 4ª edição)

No guia PMBOK também é abordado as 10 (dez) área de conhecimento da gerência de projeto juntamente com os seus processos, conceitos, técnicas e ferramentas. Ao longo do capítulo 3 abordaremos cada área de conhecimento, como elas serão tratadas dentro do gerenciamento de projeto e, será apresentado os seus planos.

2.2. Projetos, programas e portfólio

Projeto é um esforço temporário para realização de um produto ou serviço único. O projeto é temporal, possui um início e um fim.

Programa é um grupo de projetos que são agrupados para serem gerenciados de maneira coordenada a fim de obter benefícios que fossem tratados individualmente não seria obter os mesmos benefícios.

Portfólio é um conjunto de projetos e/ou programas que são agrupados para facilitar o gerenciamento eficaz a fim de atingir objetivos estratégicos de negócios.

2.3. O Guia PMBOK, um pouco sobre a história

O guia PMBOK foi criado pelo Project Management Institute (PMI). O PMI é uma entidade internacional sem fins lucrativos, que concentra profissionais do mundo inteiro, que são atuantes em atividades relacionadas a gerenciamento de projetos.

O PMI lançou pela primeira vez o guia PMBOK no ano de 1987 na revista PM Network. Esta primeira versão do guia PMBOK possuía apenas 2 (duas) áreas de conhecimento: risco e aquisições.

No ano de 1996, o PMBOK tornou-se uma publicação independente e foi incluído o tópico Integração.

No ano de 2000, o PMBOK Guide 2000, foi liberado para publicação.

Cronologia de lançamento das edições do guia PMBOK:

2.4. O que é gerenciamento de projetos?

Gerenciamento de projetos é o ato de gerenciar projeto e, gerenciar projetos, é a ação de aplicar os conhecimentos, habilidades e técnicas adquiridas partir de estudos e de experiências vividas em projetos com objetivo de atender as expectativas dos clientes finais.

A gerência de projetos é a aplicação de conhecimento, habilidades, técnicas e ferramentas em atividades do projeto, a fim de satisfazer ou exceder às necessidades e expectativas dos stakeholders.” (Guia de Gerenciamento de Projetos e Certificações PMP)

Para o gerenciamento de projetos, o guia PMBOK sugere a aplicação e integração de 47 processos que estão grupados logicamente em 5 (cinco) grupos de processos. São os cincos grupos de processos: Iniciação; Planejamento; Execução; Monitoramento e controle; e Encerramento.

Para obter sucesso no gerenciamento de projeto é necessário buscar o equilíbrio entre os seguintes fatores: Escopo, Prazo e Custo. O equilíbrio entre esses três fatores, resultam um quarto que é a qualidade.

O gerenciamento de projetos é baseado nos seguintes contextos: Competição crescente; Forte exigência por qualidade; Redução sistemática na margem de lucro; Pressão por resultados financeiros; Necessidade de atualização tecnológica; Atendimento a aspectos legais; Responsabilidade social crescente; Cenário político e econômico estável; e Crise mundial.

Devido à grande probabilidade e frequência de mudanças ocorridas durante a execução do projeto, o desenvolvimento de um plano de gerenciamento do projeto é imprescindível e é uma atividade iterativa elaborada de forma progressiva ao longo do ciclo de vida do projeto. A elaboração deste plano é constituída de melhoria continua e possui detalhamento de um plano conforme obtiver informações mais detalhadas, específicas e estimativas mais exatas sobre as atividades.

Um projeto sofre diversas influências e o gerente de projetos precisa estar atento a elas a fim de mitigar os problemas que possam vir ocorrer proveniente de influências externas e internas. Podemos citar como grupo de influências socioeconômicas: Padrões e regulamento; Internacionalização; e Influências Culturais.

Podemos citar alguns conhecimentos gerais que facilitam no gerenciamento de projetos. O domínio dos conhecimentos listados são de grande valia para o gerente de projeto quando se depara com uma crise dentro do projeto, por exemplo. São eles: Liderança; Comunicação; Negociação; Resolução de Problemas; e Influências da Organização.

2.4.1. Influências organizacionais no gerenciamento de projetos

A maneira com que os projetos são gerenciados e executados varia de acordo com a empresa, estrutura organizacional, situação econômica e cultural. O nível de maturidade que a organização possui em gerenciamento de projetos também podem influenciar o projeto. Os itens a seguir descrevem características, fatores e ativos dentro da organização que provavelmente influenciarão o projeto.

2.4.1.1. Culturas e estilos organizacionais

As organizações são constituídas por diversas pessoas e departamentos com o objetivo de alcançar um resultado. O fator crítico são as diversas culturas e estilos de se fazer ou proceder determinadas ações e com isso resulta diversos conflitos dentro do projeto. O gerente de projetos precisa desenvolver a habilidade em gerenciar os conflitos neste nível e, uma das ferramentas que pode ser utilizada é identificar os tomadores de decisões ou influenciadores e trabalhar de perto para aumentar as chances de sucesso do projeto.

2.4.1.2. Comunicações organizacionais

O elemento comunicação é um dos fatores mais críticos em um projeto, pois a falta deste o a condução de maneira não eficiente influencia a forma com os projetos serão conduzidos.

Atualmente existem diversos meios de comunicações, tais como: e-mail, mensagens instantâneas de texto, telefone, redes sociais, videoconferência, conferência pela internet, entre outros. Esses meios de comunicações podem ser utilizados podem ser utilizados formalmente ou informalmente. O gerente de projetos possui estas ferramentas e deve utilizar da melhor forma para mitigar influencias negativas ao longo do projeto.

2.4.1.3. Estruturas organizacionais

A estrutura organizacional da empresa é um fator de grande influência no projeto e pode afetar a disponibilidade de recursos e a também a forma com que o projeto será conduzido.

A tabela 1 apresenta as principais características do projeto relacionadas aos principais tipos de estruturas organizacionais.

Conforme apresentado no quadro 1, existem organizações com características diversas. Para uma melhor gerencia, é importante que o gerente de projetos identifique a característica da organização que está atuando para conseguir desenvolver um melhor trabalho. São características organizacionais: Organização funcional; Organização matriz fraca; Organização matriz balanceada; Organização matricial forte; Organização projetizada; e Organização composta.

Quadro 1 – Vantagens e desvantagens das Estruturas Organizacionais

Projetizada
Vantagens	Desvantagens
• Organização de projetos eficiente • Lealdade ao projeto • Comunicação mais efetiva que a funcional	• O recurso é deslocado quando o projeto é completo • Falta de profissionais qualificados nas disciplinas • Duplicação das facilidades e funções de trabalho • Menos eficiência no uso de recursos
Matricial
Vantagens	Desvantagens
• Alta visibilidade nos objetos do projeto • Melhor controle do gerente do projeto sobre os recursos • Maior suporte das organizações funcionais • Máxima utilização de recursos escassos • Melhor coordenação • Melhor disseminação horizontal e vertical das informações que a funcional • Equipe de recursos se mantém alocada	• Não há custo efetivo por causa da administração do pessoal extra • Mais de um chefe para a equipe de projetos • Mais complexidade para monitorar e controlar • Mais problemas com alocação de recursos • Necessidade extensiva de politica e procedimento • Gerentes funcionais podem ter diferentes prioridades daquelas dos gerentes de projeto • Alto potencial para conflitos e duplicação de espaço
Funcional
Vantagens	Desvantagens
• Facilidade no gerenciamento de especialistas • Membros da equipe reportam somente para um supervisor • Recursos similares são centralizados, empresas são agrupadas por especialistas • Plano de carreira claramente definido nas áreas de trabalho especializada	• Pessoas enfatizam mais a especialidade funcional em detrimento do projeto • Não há plano de carreira no gerenciamento de projetos • Gerente de projetos não tem autoridade

Fonte: Guia de Gerenciamento de Projetos e Certificação PMP

2.4.1.4. Ativos de processos organizacionais

Os ativos de processos organizacionais são todos os artefatos utilizados durante a execução do projeto a fim de auxiliar e aperfeiçoar os processos e as atividades executadas pelos participantes do projeto.

Ativos de processos organizacionais são os planos, processos, políticas, procedimentos e as bases de conhecimento específicas da organização e por ela usados. (Guia PMBOK 5ª edição)

Os ativos podem ser agrupados em duas características: processos e procedimentos, e base de conhecimento corporativo.

Na categoria Processos e procedimentos para condução do trabalho incluem, mas não se limitam: Iniciação e Planejamento; Execução, monitoramento e controle; e encerramento.

Na categoria Base de conhecimento, os itens que o compõem são importantes para os participantes do projeto terem um histórico de ocorridos a fim orientar de como proceder em determinada situação.

2.4.1.5. Fatores ambientais da empresa

Os fatores ambientais se referem às condições que fogem do controle da equipe de projeto que gerenciam o projeto. São, muitas das vezes, fatores externos que influenciam positivamente ou negativamente no resultado esperado.

2.5. Ciclo de vida do projeto

O ciclo de vida do projeto é um conjunto de fases pelas quais o projeto percorre, desde o início até o fim. As fases geralmente são sequenciadas são desmembradas por objetivos funcionais ou parciais, resultados ou entregas intermediárias, marcos específicos no escopo geral do trabalho, ou disponibilidade financeira. O ciclo de vida do projeto pode ser definido de acordo com aspectos específicos e exclusivos da organização, setor ou tecnologia empregada, ou seja, podem variar muito de acordo com o projeto que está sendo executado.

Embora todos os projetos tenham um início e um fim definidos, as entregas e atividades específicas conduzidas neste ínterim poderão variar muito de acordo com o projeto (Guia PMBOK® 5ª edição)

2.5.1 Características do ciclo de vida

Cada projeto, por mais parecido que seja, sempre serão diferentes e podem variar em tamanho e complexidade, mas independente da diferença, todos podem ser mapeados para uma estrutura genérica do ciclo de vida a seguir.

Esta estrutura genérica de ciclo de vida é frequentemente referenciada na comunicação com a alta administração ou outras entidades menos familiarizadas com os detalhes do projeto. (Guia PMBOK® 5ª edição)

Na estrutura genérica do projeto, os níveis de custo e pessoal são baixos na fase do início do projeto e mais alto na fase da execução.

Com relação aos risco e incertezas, na fase da inicialização, os níveis são maiores e vão reduzindo conforme o andamento do projeto e for progredindo nas fases. Essa redução ocorre à medida que as decisões são tomadas e as entregas são aceitas.

3. Gerenciamento do projeto

O projeto de implantação de um DW oceanográfico foi idealizado e desenvolvido para facilitar e orientar as fases do processo de implantação de uma nova estrutura física, lógica e intelectual para esse fim, estabelecendo assim toda uma mudança de paradigma.

Este projeto baseia-se na criação de um banco de dados OLAP (Online Analytical Processing). Os fatores que levaram a escolha deste modelo de banco de dados foram a grande disseminação deste banco no mercado atual, a facilidade de obter informações e o custo para implantação, ou seja, o grande custo benefício para implantação de toda infraestrutura.

Conforme preconizado no Guia PMBOK® 5ª edição, para o gerenciamento de projeto, são identificados 47 processos que estão agrupados em 10 áreas de conhecimento distintas. São áreas de conhecimento: Gerenciamento de integração do projeto; Gerenciamento do escopo do projeto; Gerenciamento do tempo do projeto; Gerenciamento dos custos do projeto; Gerenciamento da qualidade do projeto; Gerenciamento dos recursos humanos do projeto; Gerenciamento das comunicações do projeto; Gerenciamento dos riscos do projeto; Gerenciamento das aquisições do projeto; e Gerenciamento das partes interessadas do projeto.

Na figura 6, podemos observar que todas as áreas de conhecimentos possuem processos de planejamento e as áreas de conhecimento Gerenciamento da Integração dos projetos e Gerenciamento das Partes Interessadas no Projeto, possuem processos em todos os grupos de processos de gerenciamento de projetos.

Neste capítulo abordaremos o que é o gerenciamento de cada área de conhecimento e no capítulo 4 os seus planos.

3.1. Gerenciamento de integração do projeto

Esta área de conhecimento possui processo e atividades para identificar, definir, combinar, unificar e coordenar os vários processos e atividades existentes em um projeto. Possui processos que são necessários para garantir que os diversos elementos e fatores do projeto estejam corretamente coordenados e que toda as partes funcionem em conjunto.

No contexto de gerenciamento de projetos, integração inclui características de unificação, consolidação, comunicação e ações integradoras que são essenciais para a execução controlada do projeto até a sua conclusão, a fim de gerenciar com sucesso as expectativas das partes interessadas, e atender aos requisitos. (Guia PMBOK® 5ª edição)

Para sucesso do gerente de projetos no gerenciamento de integração, é exigido que se tenham habilidades em negociação e gerenciamento de conflitos de interesses e também uma boa comunicação, organização e familiaridade técnica com o produto ou serviço a ser gerado pelo projeto.

3.1.1. Desenvolvimento do termo de abertura do projeto

Este processo é do grupo de processo Iniciação. Neste processo serão desenvolvidos documentos que formalmente autorizam a existência de um projeto e dá ao gerente a autoridade necessária para aplicar os recursos organizações às atividades definidas no projeto.

São itens do processo 4.1. Desenvolver o termo de abertura do projeto: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 2 – Processo 4.1. Desenvolver o termo de abertura do projeto

Grupo de processo: Iniciação

Área de conhecimento: INTEGRAÇÃO

4.1.  Desenvolver o termo de abertura do projeto

Entradas

1. Especificação do trabalho do projeto 2. Business case 3. Acordos 4. Fatores ambientais da empresa 5. Ativos de processos

Ferramentas técnicas

1. Opinião especializada 2. Técnicas de facilitação

Saídas

1. Termo de abertura do projeto

 

3.1.1.1. Termo de abertura do projeto

O termo de abertura do projeto é o documento emitido pelo responsável inicial ou patrocinador do projeto que autoriza formalmente a existência de um projeto e concede ao gerente do projeto a autoridade para aplicar os recursos organizacionais nas atividades do projeto. (Guia PMBOK® 5ª edição)

No TAP (Termo de Abertura do Projeto) é documentando toda as necessidades, finalidade e justificativas do projeto, as premissas, as restrições, resumo do cronograma, resumo dos custos, os riscos de alto nível, as partes interessadas, os participantes do projeto entre outros itens que contribuam para a autorização do projeto junto a quem é de responsabilidade.

3.1.2. Desenvolvimento do plano de gerenciamento do projeto

O processo Desenvolver o Plano de Gerenciamento do Projeto é do grupo de processo Planejamento e nele são definidos, preparados e coordenados todos os planos subsidiários e integrá-los a um plano de gerenciamento de projeto abrangente.

São itens do processo 4.2. Desenvolver o plano de gerenciamento do projeto: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 3 – Processo 4.2. Desenvolver o plano de gerenciamento do projeto

Grupo de processo: Planejamento

Área de conhecimento: INTEGRAÇÃO

4.2. Desenvolver o plano de gerenciamento do projeto

Entradas

1. Termo de abertura do projeto 2. Saídas de outros processos 3. Fatores ambientais da empresa 4. Ativos de processos

Ferramentas técnicas

1. Opinião especializada 2. Técnicas de facilitação

Saídas

1. Plano de gerenciamento do projeto

 

3.1.2.1. Plano de gerenciamento do projeto

Desenvolver o plano de gerenciamento do projeto é o processo de definir, preparar e coordenar todos os planos auxiliares e integrá-los a um plano de gerenciamento de projeto abrangente. (Guia PMBOK® 5ª edição)

O Plano de Gerenciamento de Projeto é um documento central que define uma base para todos os trabalhos que serão realizados no projeto. Ele possui como uma das entradas o TAP (Termo de Abertura do Projeto). Que servirá como base para criar o plano de projeto.

3.1.3. Orientação e gerenciamento do trabalho do projeto

O processo orientar e gerenciar está contido no grupo de processos Execuções. Neste processo algumas entregas e solicitação de mudanças são realizadas. É importante ressaltar que todas as solicitações de mudanças sejam documentadas e atualizadas nos documentos de projeto.

São itens do processo 4.3. Orientar e gerenciar o trabalho do projeto: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 4 – Processo 4.3. Orientar e gerenciar o trabalho do projeto

Grupo de processo: Execução

Área de conhecimento: INTEGRAÇÃO

4.3. Orientar e gerenciar o trabalho do projeto

Entradas

1. Plano de gerenciamento do projeto 2. Solicitações de mudanças 3. Fatores ambientais da empresa 4. Ativos de processos organizacionais

Ferramentas técnicas

1. Opinião especializada 2. Sistema de Informações do gerenciamento de projetos 3. Reuniões

Saídas

1. Entregas 2. Dados de desempenho do trabalho 3. Solicitações de mudança 4. Atualizações no plano de gerenciamento do projeto 5. Atualizações nos documentos do projeto

 

3.1.4. Monitoramento e controle do trabalho do projeto

Neste processo é intensificado o acompanhamento, revisão e registro do progresso do projeto afim de atender aos objetivos de desempenho que foram definidos no plano de gerenciamento.

São itens do processo 4.4. Monitorar e controlar o trabalho do projeto: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 5 – Processo 4.4. Monitor e controlar o trabalho do projeto

Grupo de processo: Monitoramento e Controle

Área de conhecimento: INTEGRAÇÃO

4.4. Monitorar e controlar o trabalho do projeto

Entradas

1. Plano de gerenciamento do projeto 2. Previsões de cronogramas 3. Previsão de custos 4. Mudanças validadas 5. Informações sobre o desempenho do trabalho 6. Fatores ambientais da empresa 7. Ativos de processos organizacionais

Ferramentas técnicas

1. Opinião especializada 2. Técnicas analíticas 3. Sistema de Informações do gerenciamento de projetos 4. Reuniões

Saídas

1. Solicitações de mudança 2. Relatório de desempenho do trabalho 3. Atualizações no plano de gerenciamento do projeto 4. Atualizações nos documentos do projeto

 

3.1.5. Realização do controle integrado de mudanças

Neste processo será realizado a revisão em todas as solicitações de mudança, aprovação das mudanças e o gerenciamento das mesmas nas entregas, ativos de processos organizacionais, documentos do projeto e no plano de gerenciamento de projetos a fim de comunicar a decisão dobre os mesmos.

São itens do processo 4.5. Realizar o controle integrado de mudanças: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 6 – Processo 4.5. Realizar o controle integrado de mudanças

Grupo de processo: Monitoramento e Controle

Área de conhecimento: INTEGRAÇÃO

4.5. Realizar o controle integrado de mudanças

Entradas

1. Plano de gerenciamento do projeto 2. Relatório de desempenho do trabalho 3. Solicitações de mudança 4. Fatores ambientais da empresa 5. Ativos de processos organizacionais

Ferramentas técnicas

1. Opinião especializada 2. Reuniões 3. Ferramentas de controle de mudanças

Saídas

1. Solicitações de mudanças aprovadas 2. Registro das mudanças 3. Atualizações no plano de gerenciamento do projeto 4. Atualizações nos documentos do projeto

 

3.1.6. Encerramento do projeto ou fase

O processo, encerrar o projeto ou fase, e um processo de finalização de todas as atividades que visa o encerramento formal o projeto ou fase.

São itens do processo 4.6. Encerrar o projeto ou a fase: Entradas; Ferramentas e técnicas; e Saídas.

Quadro 7 – Processo 4.6. Encerrar o projeto ou a fase

Grupo de processo: Encerramento

Área de conhecimento: INTEGRAÇÃO

4.6. Encerrar o projeto ou a fase

Entradas

1. Plano de gerenciamento do projeto 2. Entregas aceitas 3. Ativos de processos organizacionais

Ferramentas técnicas

1. Opinião especializada 2. Técnicas analíticas 3. Reuniões

Saídas

1. Transição do produto, serviço ou resultado final 2. Atualizações nos ativos de processos organizacionais

 

3.2. Gerenciamento do Escopo do Projeto

O plano de gerenciamento do escopo tem como finalidade descrever o plano, estabelecendo os meios pelo qual será definido o escopo, critérios de mudança de escopo e como será realizada a documentação do escopo

Gerenciar o escopo do projeto requer um plano de gerenciamento do escopo aprovado englobando os principais processos de escopo definidos abaixo. O plano de gerenciamento do escopo é desenvolvido e aprovado durante a fase de planejamento do projeto para orientar a equipe do projeto sobre como os processos de escopo serão executados de modo a garantir que o projeto inclua todo o trabalho necessário, e apenas o trabalho necessário, para que seja terminado com sucesso.

Para o gerenciamento do escopo do projeto, o Guia PMBOK® 5ª edição preconiza 6 processos, são eles a saber:

• Processo 5.1 Planejar o gerenciamento do escopo: Neste processo será criado o plano de gerenciamento do escopo para documentar como tal escopo será definido, validado e controlado;
• Processo 5.2 Coletar os requisitos: Processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de atender aos objetivos do projeto;
• Processo 5.3 Definir o escopo: Processo de desenvolvimento de uma descrição detalhada do projeto e do produto;
• Processo 5.4 Criar a EAP: Processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis;
• Processo 5.5 Validar o escopo: Processo de formalização da aceitação das entregas concluídas do projeto;
• Processo 5.6 Controlar o escopo: Processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanças feitas na linha de base do escopo.

3.3. Gerenciamento de Tempo do Projeto

O gerenciamento do tempo no projeto tem como objetivo gerenciar o término pontual do projeto.

Para gerenciar o tempo no projeto, existem vários processos que auxiliam o gerenciamento, são eles: Planejar o gerenciamento do cronograma; Definir as atividades; Sequenciar as atividades; Estimar os recursos das atividades; Estimar as durações das atividades; Desenvolver o cronograma; e Controlar o cronograma.

3.4. Gerenciamento de Custo do Projeto

O gerenciamento de custo no projeto tem como objetivo estimar, orçar, financiar, gerenciar e controlar os custos envolvidos no projeto de modo que possa ser concluído dentro do orçamento previsto e aprovado.

Para auxiliar o gerenciamento de custo, o guia PMBOK 5ª edição sugere 4 processos que apoiarão o gerente de projetos neste gerenciamento, são eles: Planejar o gerenciamento dos custos; Estimar os custos; Determinar o orçamento; e Controlar os custos.

3.5. Gerenciamento de Recursos Humanos

O gerenciamento dos recursos humanos tem como objetivo organizar e guiar a equipe de projeto e para apoiar o gerente de projeto, o guia PMBOK® 5ª edição cita 4 (quatro) processos chaves para o gerenciamento, são eles: Desenvolver o plano dos recursos humanos; Mobilizar a equipe do projeto; Desenvolver a equipe do projeto; e Gerenciar a equipe do projeto.

A equipe de gerenciamento de projetos é um subconjunto da equipe do projeto e é responsável pelas atividades de gerenciamento do projeto e liderança, como iniciação, planejamento, execução, monitoramento, controle e encerramento das várias fases do projeto. Este grupo também pode ser chamado de equipe principal, equipe executiva, ou equipe de liderança. Em projetos menores, as responsabilidades de gerenciamento do projeto podem ser compartilhadas por toda a equipe ou administradas exclusivamente pelo gerente de projetos. (Guia PMBOK® 5ª edição)

3.6. Gerenciamento de Comunicações do Projeto

Para auxiliar o gerente de projetos no gerenciamento das comunicações, o guia PMBOK® 5ª edição sugere 3 processos, são eles: Planejar o gerenciamento das comunicações; Gerenciar as comunicações; e Controlar as comunicações.

3.7. Gerenciamento de Riscos do projeto

O gerenciamento de riscos do projeto tem como objetivo planejar, identificar, analisar e planejar respostas e controlar os riscos de um projeto.

Os objetivos do gerenciamento dos riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o impacto dos eventos negativos no projeto.” (Guia PMBOK® 5ª edição)

Para auxiliar no gerenciamento dos riscos em um projeto, o guia PMBOK® 5ª edição sugere 6 (seis) processos, são eles: Planejar o gerenciamento dos riscos; Identificar os riscos; Realizar uma análise qualitativa dos riscos; Realizar uma análise quantitativa dos riscos; Planejar as respostas aos riscos; e Controlar os riscos.

O risco do projeto é um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do projeto tais como escopo, cronograma, custo e qualidade. Um risco pode ter uma ou mais causas e, se ocorrer, pode ter um ou mais impactos.  (Guia PMBOK® 5ª edição)

4. Planos de gerenciamento do projeto

4.0.1. Título do projeto

O título do projeto a ser desenvolvido é Implantação de um Data Warehouse Oceanográfico 

4.0.2. Gerente do projeto

A funcionária que ficará responsável em gerenciar o projeto desde o início até o seu término é a Ana Paula de Oliveira Santos Cortinovis.

4.0.3. Patrocinador: OceanoBR

Os principais clientes do projeto são: Comunidade cientifica, oceanógrafos e estudantes universitário.

4.0.4. Documentos anexados

Os seguintes documentos, listados abaixo, serão anexados ao plano de gerenciamento do projeto.

• Termo de abertura do projeto
• Plano de Gerenciamento do Escopo do Projeto
  • Declaração de Escopo do Projeto
  • Estrutura Analítica do Projeto (EAP)
• Plano de Gerenciamento do Tempo do Projeto
  • Rede de Atividades
  • Cronograma
• Plano de Gerenciamento do Custos do Projeto
  • Orçamento
• Plano de Gerenciamento da Qualidade do Projeto
• Plano de Gerenciamento dos Recursos Humanos do Projeto
• Plano de Gerenciamento das Comunicações do Projeto
• Plano de Gerenciamento dos Riscos do Projeto
  • Análise dos Riscos
• Plano de Gerenciamento das Aquisições do Projeto
• Plano de Gerenciamento das Partes Interessadas do Projeto
• Documentos de Encerramento
  • Lições Aprendidas
  • Fechamento de Contratos (Notas Fiscais, Verificações e Aceitações formais)
  • Fechamento Administrativo (Relatório Final do Projeto)

4.0.5. Observações

O Gerente do Projeto é responsável pela elaboração, revisão e aprovação deste Plano de Gerenciamento de Projeto.

A distribuição deste Plano será feira de acordo com o Plano de Comunicações.

4.1. Termo de abertura do projeto

4.1.1. Nome do projeto

Implantação de Data Warehouse Oceanográfico

4.1.2. Justificativa

Promover a propagação e distribuição dos dados oceanográfico entre as comunidades científicas e colaboradores que necessitam das informações para realização de suas atividades e pesquisas.

4.1.3. Objetivos

O objetivo do projeto é disponibilizar toda estrutura física, lógica e intelectual para a implantação do Data Warehouse Oceanográfico. Para isso, serão identificadas as ferramentas mais utilizadas no mercado para que se tenha uma grande gama de informações para consultas, a utilização de todo tipo material disponível, tais como livros, tutoriais, páginas de internet para passagem de conhecimento. O projeto terá duração de seis meses e ao final a equipe de banco de dados e desenvolvimento deverá ser capaz de criar novos recursos que atendam às necessidades usando o que há de melhor.

O projeto será considerado um sucesso se atender a todos os critérios de aceitação das entregas, respeitar as restrições e cumprir o cronograma de execução.

4.1.4. Descrição resumida do projeto

Este projeto destina-se a detalhar a implantação de um Data Warehouse Oceanográfico que tem como objetivo principal a propagação de dados oceanográfico para a comunidade cientifica de oceanógrafos, meteorologistas e biólogos, ou qualquer profissional ou empresa de qualquer área que desejam ter os dados para realizar análises e pesquisas acerca do dado disponibilizado.

4.1.5. Partes interessadas

Tabela 1 – Lista das partes interessadas

Stakeholders	Representante	Relacionamento com o projeto
OceanoBR	Diretor executivo	Responsável pelo apoio e autorizações
BNDO	Oceanógrafo	Colaboradores de dados para o DW
Comunidade científica	Pesquisadores	Clientes finais do projeto
Equipe de Desenvolvimento	Analista de Sistemas	Responsável por criar uma interface para visualização dos dados
Equipe de Banco de Dados	Adm. De Banco de Dados	Responsável por planejar, criar e manter o banco de dados
Equipe de ETL	Programador ETL	Responsável por criar e manter os programas e carga dos dados para o banco de dados
Gerente do Projeto	Gerente de Projeto	Responsável por conduzir o projeto até o seu término.
Equipe de infraestrutura	Analista de Infraestrutura	Responsável por criar e manter toda a infraestrutura para o projeto
Empresas de Treinamento	Instrutor da empresa	Responsável por dar o treinamento para as equipes do projeto

 

4.1.6. Principais entregas do projeto (escopo)

– Fazer parcerias com instituições públicas em busca de especialistas;

– Modelo OLAP do Data Warehouse;

– Protótipo do programa de carga;

– Carga dos dados;

– Dashboard para visualização dos dados; e

– Interface web para download dos dados.

4.1.7. Não faz parte das entregas (escopo)

– Obtenção original dos dados;

– Mineração dos dados; e

– Qualificação dos dados conforme preconizado na NOAA.

4.1.8. Como limitações ao projeto temos

O prazo de implementação do projeto é até o dia 30/09/2016.

4.1.9. Prazo estimado para conclusão do projeto

O prazo estimado para conclusão do projeto é de 6 (seis) meses.

4.1.10. Cronograma de marcos das principais entregas do projeto

Quadro 8 – Cronograma de marcos

Módulo	MESES
	01	02	03	04	05	06
Parcerias	——-
Modelagem		——-
Protótipo			——-
Carga de Dados				——-	——-
Dashboard				——-	——-
Interface Web					——-	——-

 

4.1.11. Orçamento estimado

A diretoria disponibilizou para o projeto de implantação do Data Warehouse o investimento de R$ 300.000,00 (trezentos mil reais).

4.1.12. Restrições do projeto

Todo treinamento interno ou externo, deverá ser realizado dentro do horário de expediente dos funcionários;

4.1.13. Premissas para o desenvolvimento do projeto

– Formar uma equipe dedicada exclusivamente para o projeto;

– Catalogar e obter os dados oceanográficos;

– Os materiais e documentos digitais do projeto serão arquivados em um diretório específico fornecido pela empresa;

– A comunicação entre as partes interessadas do projeto deverão ser realizadas por e-mail corporativo da empresa;

4.1.14. Patrocinador do projeto

O patrocinador do projeto será a empresa OceanBR

4.1.15. Gerente do projeto

Fica determinado o cargo de gerente de projetos Ana Paula de Oliveira Santos Cortinovis, com autoridade total para definição, planejamento, controle, acompanhamento e finalização de todas as fases e etapas do projeto.

4.2. Plano de gerenciamento do escopo do projeto

4.2.1. Objetivo do plano de gerenciamento do escopo

Esse documento tem como finalidade descrever o plano de gerenciamento de escopo, estabelecendo os meios pelo qual será definido o escopo, critérios de mudança de escopo e como será realizada a documentação do escopo.

4.2.2. Gerenciamento do escopo

Gerenciar o escopo do projeto requer um plano de gerenciamento do escopo aprovado englobando os principais processos de escopo definidos abaixo. O plano de gerenciamento do escopo é desenvolvido e aprovado durante a fase de planejamento do projeto para orientar a equipe do projeto sobre como os processos de escopo serão executados de modo a garantir que o projeto inclua todo o trabalho necessário, e apenas o trabalho necessário, para que seja terminado com sucesso.

4.2.3. Processos do Gerenciamento do Escopo

• Coletar os requisitos: Processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de atender aos objetivos do projeto.
• Definir o escopo: Processo de desenvolvimento de uma descrição detalhada do projeto e do produto.
• Criar a EAP: Processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
• Validar o escopo: Processo de formalização da aceitação das entregas concluídas do projeto.
• Controlar o escopo: Processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanças feitas na linha de base do escopo.

4.2.4. Documentos padronizados de escopo

Todos os documentos listados nesta seção encontram-se na Intranet da empresa, na área de documentação. Os documentos para uso do contratante (indicados por um asterisco) encontram-se na Internet, área de documentação.

Quadro 9 – Documentos do projeto

Documento	Descrição	Template
Ata de Reunião	Template que será usado na documentação das reuniões do projeto, tanto as reuniões da equipe do projeto como as reuniões com o contratante.	Ata de reuniao.docx
Declaração do Escopo do Projeto	Template de Declaração de Escopo em conformidade com a metodologia de gerenciamento de projetos. O documento baseia-se nas entregas principais, premissas, restrições e critérios de aceitação e deverá conter a descrição do escopo do produto e as exclusões do projeto.	Declaração do escopo do Projeto.docx
Termo de recebimento provisório *	Formalização ou Aceita de Entrega Parcial do Projeto. Será usada no processo validar o escopo.	Termo de Recebimento Provisório.docx
Termo de recebimento definitivo *	Formalização ou Aceita da Entrega Final do Projeto. Será usada no processo validar o escopo.	Termo de Recebimento Definitivo.docx
EAP	Processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.	EAP – DW Oceanográfico.wbs
Dicionário da EAP	Documento que fornece informações detalhadas sobre entregas, atividades e agendamento de cada componente da estrutura analítica do projeto (EAP).	Dicionário da EAP.docx
Solicitação de Mudança de Escopo *	Documento para solicitação de mudança de escopo, utilizado também para resposta ao solicitante.	Solicitação de Mudança do Projeto.doc

 

4.2.5. Responsabilidades do escopo da equipe do Projeto

As responsabilidades pelas atividades relacionadas a Escopo estão estabelecidas na Matriz de Responsabilidades.

4.2.6. Ferramentas

Entrevistas: A definição do escopo do projeto será conduzida pelo gerente de projetos e a reunião, com entrevista com os representantes da empresa cliente, incluirá a equipe de projetos e patrocinador do projeto. Estas reuniões serão registradas em atas, que deverão passar por aprovação desses participantes.

Opiniões Especializadas: Tal opinião especializada pode ser oferecida por qualquer grupo ou pessoa com formação, conhecimento, habilidade e experiência em Oceanografia.

4.2.7. Coletar os requisitos

Os requisitos são coletados em entrevista com os representantes da empresa cliente. Estes requisitos obtidos devem ser analisados e registrados em detalhes suficientes para serem medidos durante a execução do projeto.

4.2.8. Definir o escopo

O escopo será definido em reunião entre cliente, patrocinador e equipe do projeto e, se necessário, contratação de consultoria especializada. É necessário que todos saibam e entendam qual o objetivo do projeto e que haja consenso sobre o resultado final do mesmo.

Nesse momento deve ficar claro o que deve ficar fora do escopo do projeto e o que será necessário para que o projeto seja atingido, definindo os pressupostos para que todos saibam de antemão quais as necessidades básicas do projeto.

Qualquer solicitação de mudança de escopo, quando aceita, deve passar por igual processo a fim de minimizar riscos ao projeto.

4.2.9. Criar a EAP

Será usada a técnica de decomposição para dividir e subdividir o escopo do projeto e suas entregas em partes menores e mais facilmente gerenciáveis. A decomposição do trabalho completo do projeto em pacotes de trabalho envolve as seguintes atividades:

1. Identificação e análise das entregas e seu trabalho relacionado;
2. Estruturação e organização da EAP;
3. Decomposição dos níveis mais altos da EAP em componentes detalhados em menor nível;
4. Desenvolvimento e designação de códigos de identificação aos componentes da EAP;
5. Verificação de que o grau de decomposição das entregas é apropriado.

A Opinião Especializada será utilizada para analisar as informações necessárias para decompor as entregas do projeto até as menores partes dos componentes a fim de criar uma EAP eficaz. Tal opinião e conhecimento especializado em dados oceanográficos são aplicados aos detalhes técnicos do escopo do projeto e usados para reconciliar diferenças de opinião sobre a melhor maneira de decompor o escopo geral do projeto.

4.2.10. Validar o escopo

O documento de Recebimento Provisório é disponibilizado para a empresa ao se oficializar o término da fase.

O escopo do projeto será validado em um prazo máximo de 3 (três) dias úteis após o término oficial da fase, onde será analisado se todos os critérios de aceitação foram atingidos e os possíveis desvios.

Ao final da análise será formalizada a aceitação da entrega, junto ao patrocinador, de forma a comprovar que todos os critérios de aceitação foram atingidos utilizando o documento de Recebimento Definitivo.

4.2.11. Controlar o escopo

As informações geradas sobre o desempenho do trabalho incluem informações correlacionadas e contextualizadas sobre o desempenho do escopo do projeto em comparação à linha de base do escopo.

Elas podem incluir as categorias das mudanças recebidas, as variações do escopo identificadas e suas causas, o impacto que elas causam no cronograma ou custo, e a previsão do desempenho do escopo futuro.

O controle do escopo será realizado a partir do início de cada fase com base nos documentos mencionados no item 3.2.1.4. (Documentos padronizados de escopo) e reportados nas reuniões de controle.

4.2.12. Mudança de escopo

Toda mudança deverá ser solicitada através dos documentos mencionados no item 3.2.1.4 (Documentos padronizados de escopo) e atender a critérios estabelecidos neste plano de gerenciamento de escopo.

A implantação da mudança fica condicionada à aprovação por parte da equipe de projeto e à aceitação do cliente quando houver alterações nas condições iniciais do projeto.

4.3. Declaração do escopo do projeto

4.3.1. Objetivo deste documento

Descrever de forma clara qual trabalho deverá ser realizado e quais entregas serão produzidas.

4.3.2. Descrição do projeto

O projeto consiste na implantação de toda uma nova infraestrutura para a criação de um Data Warehouse Oceanográfico, a partir do levantamento das ferramentas mais utilizadas no mercado, suas configurações e utilização. Serão utilizados hardwares e softwares já utilizados pela empresa e durante o projeto serão fornecidas as ferramentas necessárias ao andamento do projeto que serão softwares livres. A cada entrega, deverá ser feita a passagem de conhecimento e entrega de documentação relativa ao que foi aprendido. Será indicado curso externo para nivelamento de conhecimento, não sendo necessária a realização do curso durante o projeto. Na última fase do projeto será realizada revisão completa da infraestrutura e performance dos processos com indicação de melhorias se necessário. O projeto será realizado e acompanhado através das seguintes fases preestabelecidas:

• Fase de Recursos Humanos: fase que se busca a obtenção de parcerias intelectuais nos órgãos públicos, universidades e nas comunidades cientificas e também de especialistas na área de TI para compor o time da equipe do projeto;
• Fase de Aquisição: fase que serão levantados todos os materiais necessários para a execução do projeto. Desde material de escritório até material de TI; e
• Fase de Construção do DW: nessa fase serão levantados e executados todos os procedimentos para criação do ambiente para a implantação do Data Warehouse Oceanográfico;

4.3.3. Escopo do produto

Disponibilizar toda infraestrutura física, lógica e intelectual para o Implantação do Data Warehouse Oceanográfico.

4.3.4. Exclusões do projeto / Fora do Escopo

Não faz parte do escopo à iniciação e/ou conclusão de cursos externos como pré-requisitos ao andamento do projeto.

Não faz parte do conteúdo programático a orientação sobre criação de um DW.

Não faz parte do escopo à realização de qualquer atividade, por exemplo: cursos e treinamentos, fora do horário de expediente dos funcionários envolvidos no projeto.

4.3.5. Entregas e Critérios de Aceitação

As entregas e seus critérios de aceitação estão descritas na EAP e no seu dicionário.

4.3.6. Estrutura Analítica do Projeto (EAP)

4.3.7. Dicionário da EAP

Quadro 10 – Dicionário da EAP: Recursos Humanos

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.1	Recursos Humanos		Gerente do projeto
Prazo estimado:	12 dias	Custo estimado:	R$ 5.280,00
Descrição: Planejar os recursos humanos necessários para o planejamento e execução do projeto.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação os recursos humanos e parcerias necessárias para a execução do projeto.
Riscos associados ao pacote: Dificuldade em buscar recursos humanos especializado para a execução do projeto devido a especificidade do profissional alvo e dificuldade em fechar parcerias com empresas públicas, privadas e instituições de ensino.
Outras informações:

 

Quadro 11 – Dicionário da EAP: Especialistas

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.1.1	Especialistas		Gerente do projeto
Prazo estimado:	12 dias	Custo estimado:	R$ 5.280,00
Descrição: Planejar os recursos humanos necessários para o planejamento e execução do projeto.
Principais tarefas: ü Definir a quantidade de especialistas; ü Definir a quantidade de pessoas necessárias a equipe de TI; e ü Elaborar contrato de fornecimento de serviço.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação os recursos humanos necessários para a execução do projeto
Riscos associados ao pacote: ü  Dificuldade em buscar recursos humanos especializado para a execução do projeto devido a especificidade do profissional alvo
Outras informações:

 

Quadro 12 – Dicionário da EAP: Parceria

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.1.2	Parceria		Gerente do projeto
Prazo estimado:	5 dias	Custo estimado:	R$ 2.200,00
Descrição: Obter parcerias de empresas públicas, privadas e instituições de ensino para execução do projeto.
Principais tarefas: ü Obter parceria intelectual com universidades, empresas privadas e públicas.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação de relatório com a lista de empresas e instituições de ensino superior que tem interesse em participar do projeto e os recursos intelectuais que poderão apoiar o projeto.
Riscos associados ao pacote: ü Dificuldade em obter parcerias com empresas privadas, públicas e nas instituições de ensino superior devido as demandas internas que as mesmas possuem.
Outras informações:

 

Quadro 13- Dicionário da EAP: Aquisições

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.2	Aquisições		Gerente do projeto
Prazo estimado:	43 dias	Custo estimado:	R$ 18.920,00
Descrição: Definir, cotar e solicitar a aquisições de materiais de escritório e de TI necessários para a execução do projeto.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação os materiais de escritório e TI necessários para a execução do projeto.
Riscos associados ao pacote: Dificuldade na realização de cotação do material de TI com as empresas devido as suas especificidades.
Outras informações:

 

Quadro 14 – Dicionário da EAP: Material de escritório

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.2.1	Material de escritório		Gerente do projeto
Prazo estimado:	16 dias	Custo estimado:	R$ 2.200,00
Descrição: Definir, cotar e solicitar a aquisições de materiais de escritório necessários para a execução do projeto.
Principais tarefas: ü Definir material de escritório necessário; ü Fazer cotação de material para aquisição; e ü Elaborar solicitação de compra dos materiais.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação da lista dos materiais de escritórios que foram definidos como necessário para a execução do projeto, juntamente com as cotações das empresas e o pedido de solicitação de compra.
Riscos associados ao pacote: ü Dificuldade em realizar as cotações com as empresas; e ü Dificuldade na elaboração da solicitação de compra devido o tipo de aquisição que será definidor pelo setor de compras.
Outras informações:

 

Quadro 15 – Dicionário da EAP: Materiais de TI

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.2.2	Materiais de TI		Gerente do projeto
Prazo estimado:	43 dias	Custo estimado:	R$ 18.920,00
Descrição: Definir, cotar e solicitar a aquisições de materiais de TI (software e hardware) necessários para a execução do projeto.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação os materiais de TI (software e hardware) necessários para a execução do projeto.
Riscos associados ao pacote: Dificuldade na realização de cotação do material de TI com as empresas devido as suas especificidades.
Outras informações:

 

Quadro 16 – Dicionário da EAP: Software

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.2.2.1	Software		Gerente do projeto
Prazo estimado:	18 dias	Custo estimado:	R$ 7.920,00
Descrição: Definir, cotar e solicitar a aquisições de softwares necessários para a execução do projeto.
Principais tarefas: ü Definir software necessário; ü Fazer cotação com empresas; e ü Elaborar solicitação de compra ou aluguel.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação da lista dos softwares que foram definidos como necessário para a execução do projeto, juntamente com as cotações das empresas e o pedido de solicitação de compra ou aluguel.
Riscos associados ao pacote: ü Dificuldade em realizar as cotações com as empresas; e ü Dificuldade na elaboração da solicitação de compra ou aluguel devido o tipo de aquisição que será definidor pelo setor de compras.
Outras informações:

 

Quadro 17 – Dicionário da EAP: Hardware

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.2.2.2	Hardware		Gerente do projeto
Prazo estimado:	16 dias	Custo estimado:	R$ 7.040,00
Descrição: Definir, cotar e solicitar a aquisições de hardwares necessários para a execução do projeto.
Principais tarefas: ü Definir hardware necessário; ü Fazer cotação com empresas; e ü Elaborar solicitação de compra ou aluguel.
Recursos previstos: Gerente do projeto
Critérios de Aceitação: Apresentação da lista dos softwares que foram definidos como necessário para a execução do projeto, juntamente com as cotações das empresas e o pedido de solicitação de compra ou aluguel.
Riscos associados ao pacote: ü Dificuldade em realizar as cotações com as empresas; e ü Dificuldade na elaboração da solicitação de compra ou aluguel devido o tipo de aquisição que será definidor pelo setor de compras.
Outras informações:

 

Quadro 18- Dicionário da EAP: Construção do DW

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3	Aquisições		Coordenador de equipe
Prazo estimado:	141 dias	Custo estimado:	R$ 56.400,00
Descrição: Definir e criar a estrutura para o Data Warehouse Oceanográfico; coletar, processar e visualizar todos os dados oceanográficos que foram obtidos e carregados no banco de dados.
Recursos previstos: Gerente do projeto, equipe de desenvolvimento, equipe de DBA e oceanógrafos.
Critérios de Aceitação: Apresentação de toda a estruturação, carregamento e visualização dos dados no Data Warehouse Oceanográfico
Riscos associados ao pacote: ü  Dificuldade na realização carga dos dados devido a sua diversidade e formato do arquivo; e ü  Dificuldade no entendimento do dado em si.
Outras informações:

 

Quadro 19 – Dicionário da EAP: Definição da Estrutura

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3.1	Definição da Estrutura		Coordenador de equipe
Prazo estimado:	6 dias	Custo estimado:	R$ 5.520,00
Descrição: Definir quais dados serão armazenados no Data Warehouse e quais tabelas deverão ser criadas para atender os requisitos para execução do projeto.
Principais tarefas: ü Definir os dados que serão armazenados; e ü Definir as tabelas para armazenamento dos dados.
Recursos previstos: Equipe de DBA e Oceanógrafos.
Critérios de Aceitação: Apresentação dos requisitos de dados a ser implementado no Data Warehouse e as informações das tabelas necessárias para implementar no banco.
Riscos associados ao pacote: Não identificado
Outras informações:

 

Quadro 20 – Dicionário da EAP: Criação da Estrutura

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3.2	Criação da Estrutura		Coordenador de equipe
Prazo estimado:	8 dias	Custo estimado:	R$ 2.240,00
Descrição: Definir quais dados serão armazenados no Data Warehouse e quais tabelas deverão ser criadas para atender os requisitos para execução do projeto.
Principais tarefas: ü Definir os dados que serão armazenados; e ü Definir as tabelas para armazenamento dos dados.
Recursos previstos: Equipe de DBA e Oceanógrafos.
Critérios de Aceitação: Apresentação dos requisitos de dados a ser implementado no Data Warehouse e as informações das tabelas necessárias.
Riscos associados ao pacote: Não identificado
Outras informações:

 

Quadro 21- Dicionário da EAP: Coleta de dados

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3.3	Coleta de dados		Coordenador de equipe
Prazo estimado:	27 dias	Custo estimado:	R$ 17.280,00
Descrição: Definir os tipos de dados serão armazenados no Data Warehouse, sua origem e como serão classificados.
Principais tarefas: ü Definir os tipos de dados; ü Definir origem de dados; ü Classificar os dados para o carregamento; e ü Obter os dados.
Recursos previstos: Oceanógrafos.
Critérios de Aceitação: Apresentação dos metadados e dados que serão implementados no Data Warehouse.
Riscos associados ao pacote: ü  Dificuldade no entendimento dos dados e da sua origem
Outras informações:

 

Quadro 22- Dicionário da EAP: Processo ETL

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3.4	Processo ETL		Coordenador de equipe
Prazo estimado:	55 dias	Custo estimado:	R$ 85.800,00
Descrição: Criar todo o processo para carregamento dos dados no banco de dados DW Oceanográfico e também carregar os dados no banco
Principais tarefas: ü Extrair os dados; ü Transformar os dados; e ü Carregar os dados.
Recursos previstos: Equipe de DBA, Oceanógrafos e equipe de desenvolvimento
Critérios de Aceitação: Apresentação dos metadados e dados carregados no Data Warehouse Oceanográfico.
Riscos associados ao pacote: ü  Dificuldade no entendimento dos dados; ü  Demora no carregamento dos dados devido à grande quantidade de informação; e ü  Validação eficiente do dado carregado no banco de dados.
Outras informações:

 

Quadro 23- Dicionário da EAP: Visualização dos dados

Código da EAP	Nome do Pacote de Trabalho		Responsável:
1.3.5	Visualização dos dados		Coordenador de equipe
Prazo estimado:	48 dias	Custo estimado:	R$ 11.520,00
Descrição: Definir ferramentas necessárias para a criação de um protótipo e um dashboard para visualização dos dados do DW Oceanográfico e criar dashboard para visualização dos dados para o usuário do DW.
Principais tarefas: ü Definir ferramentas a ser utilizada; ü Criar um protótipo; e ü Criar um dashboard.
Recursos previstos: Equipe de Desenvolvimento.
Critérios de Aceitação: Apresentação um protótipo o dashboard para visualização dos dados implementados no Data Warehouse Oceanográfico.
Riscos associados ao pacote: ü  Dificuldade em criar uma interface amigável e com boa performance para visualização
Outras informações:

 

4.4. Plano de gerenciamento de tempo e cronograma

4.4.1. Objetivo

O Plano de Gerenciamento do Cronograma e seus anexos têm por objetivo formalizar o cronograma definido e aprovado para o Projeto Implantação de um Data Warehouse Oceanográfico e estabelecer as diretrizes para garantir as métricas de controle, acompanhamento do cronograma e controle de mudanças no cronograma oficial do projeto.

4.4.2. Funções e Responsabilidades

4.4.3. Descrição dos processos de Gerenciamento do Tempo do Projeto

O gerenciamento de tempo do projeto inclui os processos necessários para concluir o projeto no prazo estabelecido.

4.4.4. Definição das atividades

As atividades foram definidas de acordo com a EAP, o Dicionário da EAP e a Declaração de Escopo.

4.4.5. Sequenciamento das atividades

A lista de atividades definidas no processo anterior foi utilizada como entrada para essa etapa. Será realizada através da identificação e documentação de relações de dependência lógica entre as atividades de acordo com seu tipo de precedência.

4.4.6. Estimativa de recursos da atividade

Foram determinados os recursos de acordo com a necessidade do projeto, com a experiência adquirida em projeto anterior semelhante, com a participação de especialistas nos assuntos referentes a cada atividade, e de acordo com o recurso financeiro disponível.

4.4.7. Estimativa de duração da atividade

A estimativa de duração da atividade ocorreu com base em três técnicas:

• Opinião especializada
• Estimativa análoga (atividades similares de projetos anteriores): Atividades das fases de ‘Gerenciamento Projeto’, ‘Encerramento’ e atividades de planejamento e controle das demais fases.
• Estimativa paramétrica: em todas as decisões em que as atividades do Data Warehouse fosse uma variável, como dados dos equipamentos para realização de carga no banco ou em que a quantidade de analistas fosse a variável.

4.4.8. Desenvolvimento de Cronograma

Para desenvolvimento do cronograma, foram criados os pacotes de atividades do projeto de acordo com o padrão adotado pela companhia, sendo posteriormente detalhado em atividades através de opiniões especializadas de cada disciplina. O Ms-Project foi utilizado como ferramenta de apoio ao planejamento.

4.4.9. Listas de marcos

Os principais marcos são:

Item	Data
Levantamento da origem dos dados
Definição da modelagem de dados
Captação de recursos humanos
Parcerias estabelecidas
Carga dos dados
Protótipo do visualizador de dados

 

4.4.10. Linhas de Base

Concluídas as tarefas de planejamento das atividades, desenvolvido e aprovado o cronograma, foi salva a linha de base estando registrada nas colunas início e término linha de base.

4.4.11. Controle do Cronograma

O controle do cronograma fica sob responsabilidade do Gerente do Projetos, devendo este monitorar e atualizar o status das atividades conforme o avanço. O cronograma será atualizado todo primeiro dia útil da semana com as informações da semana anterior. Itens fora do prazo ou com possibilidade de atraso serão levados para a reunião semanal de análise crítica, onde estará presente o gerente de projeto. Caso a reunião aponte mudanças na baseline do cronograma, será preenchida uma requisição de mudança.

4.4.12. Avanço físico

Para padronização dos percentuais de avanço de projeto, fica estabelecido o seguinte critério de avanço físico das tarefas:

Status	Atividade
0%	Não iniciada
20%	Iniciada
40%	Com razoável evolução após o início
60%	Ligeiramente acima da metade do trabalho
80%	Faltando pequenos ajustes para a conclusão
100%	Concluída

 

4.4.13. Formatação de cores das tarefas dos cronogramas

Para o controle visual do status das atividades do projeto, fica estabelecido o seguinte critério:

Status	Cor
Atividade não iniciada	Cinza
Atividade iniciada	Azul claro
Atividade iniciada e com razoável evolução após o início	Vermelho
Atividade ligeiramente acima da metade do trabalho	Azul escuro
Atividade faltando pequenos ajustes para conclusão	Amarelo
Atividade concluída	Verde

 

4.4.14. Evolução Física do Projeto (CURVA S)

A curva de avanço físico mostra o desempenho previsto para execução do projeto e tem como finalidade comparar, ao longo do projeto, o desempenho real com o planejado possibilitando a visualização de desvios e, consequentemente, a tomada de ações necessárias.

4.4.15. Tarefas Atrasadas

As tarefas atrasadas do Projeto serão visualizadas através do cronograma, identificadas na cor vermelho, a qualquer momento usando como ferramenta de apoio o Ms-Project. Sua atualização será realizada conforme o item Controle do Cronograma. Serão definidas reuniões extras emergenciais para tratamento e acompanhamento das mesmas, até readequação do prazo estipulado.

No caso de tarefas ligadas ao caminho crítico do projeto, deverá ser feita uma reunião extraordinária para direcionar as ações de contorno a fim de evitar ou minimizar os impactos negativos.

4.4.16. Planos de Ação para Tarefas Atrasadas (REAGENDAMENTO)

Essas ações deverão ser analisadas na reunião da equipe do projeto, adotando um plano de ação de acordo com a situação de cada atividade.

4.4.17. Cronograma do projeto

4.4.18. Diagrama de Rede do Projeto

4.5. Plano de gerenciamento de custo do projeto

4.5.1. Objetivo

A finalidade deste Plano de Gerenciamento de Custos é definir uma metodologia pela qual os custos associados com o projeto “Implantação de um Data Warehouse Oceanográfico” será gerido ao longo do ciclo de vida do projeto. Para garantir a conclusão bem-sucedida do projeto dentro do orçamento estipulado, este plano define o formato e os padrões pelos quais os custos do projeto serão medidos, relatados e controlados. Vários componentes de custos estão associados com este projeto. Métricas, considerações sobre variação de custo e relatórios de atividades são apresentadas neste plano. Para concluir este projeto com sucesso, todos os membros-chave do projeto e as partes interessadas devem aderir e trabalhar dentro deste Plano de Gerenciamento de Custos e de todos os planos do projeto que este documenta suporta ou é suportado.

Este Plano de Gerenciamento de Custos irá:

• Delinear uma abordagem de gerenciamento de custos do projeto;
• Descrever como serão determinados o custo, orçamento e fonte de financiamento do projeto;
• Identificar quem é responsável pela gestão de custos, incluindo quem tem a autoridade para aprovar alterações no projeto, no orçamento ou nas fontes de financiamento;
• Agregar os custos estimados das atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos.
• Identificar os métodos a serem utilizados para a medição quantitativa e relatórios sobre desempenho de custo; e
• Identificar o formato do relatório, a frequência e para quem eles serão apresentados.

4.5.2. Funções e Responsabilidades

4.5.3. Abordagem de gestão de custos do projeto

A abordagem do Plano de Gerenciamento de Custo para o projeto “Implantação de um Data Warehouse Oceanográfico” requer que os recursos do projeto auxiliem em estabelecer e gerenciar o custo total atribuído ao projeto. Isso inclui a elaboração do orçamento estimado e medir as despesas reais em relação ao orçamento previsto para os seguintes itens, não se limitando:

• Os empregados da equipe do projeto e todos os custos associados a estes;
• Contratos com prestadores de serviços;
• Custos de infraestrutura; e
• Outros recursos externos.

O Plano de Gestão de Custos estabelece as atividades e os critérios para o planejamento, estruturação e controle de custos do projeto. Os custos reais e as variações de custo devem ser comunicados regularmente ao sponsor e as partes interessadas do projeto. Qualquer alteração nos custos em um valor superior 10% (dez por cento) ao longo do projeto requer aprovação do comitê integrado de mudança.

4.5.4. Estimativa de Custo

O Plano Gerenciamento de Custo para o projeto “Implantação de um Data Warehouse Oceanográfico” documenta os métodos a serem utilizados para gerir e controlar os diversos componentes internos e externos de custo. Métricas e análise de variação devem ser aplicadas a estes componentes de custo durante todo o ciclo de vida do projeto para acompanhamento, com o objetivo, se necessário, reestimar e ajustar o orçamento do projeto. Estes componentes de custos incluem:

• Interno
  • Gerenciamento de projetos / recursos da equipe do projeto;
  • Recrutamento e contratação de pessoal adicional;
  • Hardware e outros equipamentos;
  • Software e licenciamento;
• Externo
  • Custo de contrato com fornecedores;

A abordagem ‘bottom-up‘ será utilizada para a preparação de uma estimativa detalhada de cada componente de custo envolvido com cada atividade de projeto. Estimativas de custos serão preparadas usando a melhor informação disponível no momento da estimativa. A base para a estimativa deve ser devidamente documentada de forma que esteja disponível em qualquer momento posterior ao projeto. A estimativa de custo pode ser ajustada.

4.5.5. Alternativas de custeio

Para as fases do projeto será usado exclusivamente o custeio vindo de verbas do sponsor/cliente.

4.5.6. Determinação do Orçamento

Assim que as necessidades do projeto “Implantação de um Data Warehouse Oceanográfico” forem determinadas e que o gerente do projeto finalize a Estrutura Analítica de Projetos – EAP – interna e externa, a equipe do projeto finalizará os requisitos necessários para a conclusão bem-sucedida de recursos e de pessoal do projeto.

Contas de controle e a categoria de recursos (Estrutura Analítica de Recursos) serão criadas para cada pacote de trabalho da EAP.

Custos dos pacotes de trabalho da EAP serão totalizados, com base nos custos do trabalho e na duração prevista de cada pacote, e validados com o orçamento alocado para o projeto. Uma vez aprovado pela fundação, o orçamento do projeto será transformado em linha de base de custo, e, esta linha de base, somente poderá ser alterada com autorização da fundação que é o patrocinador do projeto.

4.5.7. Processo de Pagamento das Atividades

O pagamento das atividades poderá ocorrer em dois momentos:

• Ao término da atividade: neste caso serão pagos os fornecedores e/ou quaisquer outros recursos externos ao projeto.
• Somatório das despesas acumuladas até dia 25 de cada mês: onde serão pagos salários da equipe de projeto, parcelas devidas aos prestadores de serviço, além das contas administrativas internas mensais.

Todo processo de pagamento deve seguir o fluxo demonstrado a seguir.

Os custos salariais da equipe serão calculados a partir das informações do timesheet fornecido e aprovado pelo Gerente de Projeto em um período regular.

Os custos de contratos, fornecedores, equipamentos, materiais e administração serão documentados através do Formulário de Despesas que está descrito no processo a seguir.

O Formulário de Despesas e o timesheet encontram-se como anexos deste documento.

Mesmo para despesas que não estiverem no orçamento inicial, o processo será o mesmo já que somente serão realizados tais serviços caso tenham sido aprovados previamente no processo de Autorização de Mudança (exibido a seguir), que já lhes forneceria despesas conhecidas.

4.5.8. Medição do Desempenho de Custo

O Gerente de Projetos deverá construir um modelo de custo total apropriado para o projeto “Implantação de um Data Warehouse Oceanográfico”. Este modelo irá capturar todos os custos internos de pessoal, custos administrativos, custos de infraestrutura, recursos (humanos e materiais) e outras necessidades. Ele irá estabelecer a linha base do orçamento total do projeto e uma linha base do orçamento para cada fase por mês e para o ano fiscal. As entradas são os pagamentos das entregas contratadas, os custos de desenvolvimento de pessoal, os valores orçados para os custos de infraestrutura e todos os outros custos previstos para o projeto.

4.5.9. Processo de Resposta a Variação de Custo

As medidas mostradas no quadro a seguir serão usadas como base para medir a variação de custo no projeto.

Quadro 24 – Resposta a variação de custo

Medidas de desempenho	Condições de Atenção	Condições de Resposta Imediata
Índice de Desempenho de Cronograma (Schedule Performance Index – SPI)	Entre 0.9 e 0.8 ou Entre 1.1 e 1.2	Menor que 0.8 ou Maior que 1.2
Índice de Desempenho de Custo (Cost Performance Index – CPI)	Entre 0.9 e 0.8 ou Entre 1.1 e 1.2	Menor que 0.8 ou Maior que 1.2
Índice de Desempenho para Completar (To Complete Performance Index (TCPI)	Entre 0.9 e 0.8 ou Entre 1.1 e 1.2	Menor que 0.8 ou Maior que 1.2

 

4.5.10. Plano de Ação Corretiva para Variação de Custo

Para pacotes de trabalho que se encontrem em “Condição de Atenção”, caso tal condição permaneça por duas medições consecutivas passa a ser necessária medida (s) de ação (ões) corretiva (s).

Para pacotes de trabalho que se encontrem em “Condição de Resposta Imediata” medida (s) de ação corretiva devem ser imediatas.

A partir do momento que se identifique a necessidade de uma ação corretiva, o Gerente do Projeto terá um período de até 3 (três) dias úteis para propor soluções viáveis ao sponsor. Após a decisão de qual opção de ação corretiva, o Gerente de Projetos irá apresentar ao Patrocinador do Projeto (Sponsor), num prazo de até 3 (três) dias úteis, um custo formal do Plano de Ação Corretiva da Variação que deverá detalhar as ações necessárias para trazer o projeto de volta dentro do orçamento e os meios pelos quais será medida a eficácia das ações.

Após a aceitação, o Plano de Ação Corretiva da Variação de Custo se tornará uma parte do cronograma do projeto e este será atualizado para refletir as ações corretivas.

4.5.11. Processo de Controle de Mudança de Custo

O processo de controle de mudanças de custo seguirá o processo de solicitação de mudança estabelecido para o projeto. As aprovações para as mudanças no orçamento/custo do projeto deverão ser realizadas pelo patrocinador do projeto.

O processo está detalhado no fluxo a seguir.

4.5.12. Glossário

Índice de desempenho de custos (Cost Performance Index – CPI) mede o valor do trabalho concluído ou completado em comparação com o custo real do trabalho concluído ou completado. CPI é calculado como EV / AC.

• Se o CPI for igual a 1, o projeto é considerado dentro do orçamento.
• Se o CPI for maior que 1, o projeto é considerado abaixo do orçamento.
• Se o CPI for menor que 1, o projeto é considerado acima do orçamento.

Variação de Custo (Cost Variance – CV) é uma medida do desempenho do orçamento para um projeto. CV é calculado subtraindo custos reais (AC) do EV. Conforme explicado no parágrafo acima, EV é o valor real obtido no projeto. AC representa custos reais incorridos até à data. Subtraindo AC do EV fornece uma medida para indicar o status do projeto no que se refere ao orçamento e custo.

• Se CV for zero, o projeto é considerado dentro do orçamento.
• Se CV for maior que zero, o projeto está ganhando mais valor do que o previsto e é considerado abaixo do orçamento.
• Se CV for inferior a zero, o projeto está ganhando menos valor e é considerado acima do orçamento.

Custo real estimado no termino (Estimated Actual Cost at Completion – EAC) fornece uma previsão de custo real para completar o projeto com base em métricas de desempenho de custo. Há três maneiras de calcular EAC:

• Custo real acrescido orçamento total do projeto (Total Project Budget – TPB) menos Valor Agregado (AC + TPB – EV);
• Orçamento total do projeto dividido pelo Índice de Desempenho de Custos (TPB / CPI).
• Custo real mais o resultado da divisão da diferença entre o orçamento total do projeto e de Valor Agregado pelo produto do Índice de Desempenho de Custos e Índice de Desempenho Cronograma (AC + ((TPB – EV) / (CPI * SPI))).

Índice de Desempenho de Cronograma (Schedule Performance Index – SPI) é uma medida do progresso alcançado versus o que foi planejado. SPI é calculado como EV / PV. Se EV é igual a PV então o valor do SPI é 1.

• Se EV é menor do que o PV, o valor do SPI é menor que 1, o que significa que o projeto está atrasado.
• Se EV é maior do que o PV, o valor do SPI é maior que 1, o que significa que o projeto está adiantado.
• Um projeto com um bom desempenho deve ter o SPI tão perto de 1, quanto possível.

Variação do Cronograma (Schedule Variance – SV) é uma medida do desempenho do cronograma para um projeto, e é calculado subtraindo-se o valor planejado (Planned Value – PV) do Valor Agregado (Earned Value – EV). EV é o valor agregado auferido no projeto e PV é o valor a ferramenta cronograma do projeto indica deveria ter sido aferido no ponto de medição. Subtraindo PV de EV fornece uma medida para indicar o status do cronograma de linha de base de acordo com o plano do projeto.

• Se SV é zero, o projeto é considerado nas atividades previstas do cronograma.
• Se SV é maior que zero, o projeto está agregando mais valor do que o previsto e é considerado adiantado nas atividades previstas do cronograma.
• Se SV é inferior a zero, o projeto está agregando menos valor do que o previsto e é considerado atrasado nas atividades prevista do cronograma.

Índice de Desempenho para Completar (To Complete Performance Index – TCPI) mede a eficiência com que os recursos do projeto devem ser utilizados para o restante do projeto. TCPI é calculado com (Orçamento Total do Projeto – EV) / (Orçamento Total do Projeto – AC).

• Se TCPI é igual a 1, a utilização dos recursos no projeto pode continuar no nível atual.
• Se TCPI for maior que 1, a utilização dos recursos no projeto devem ser mais rigorosas do que o nível atual.
• Se TCPI é inferior a 1, a utilização dos recursos no projeto pode ser mais branda do que no nível atual.

4.6. Plano de gerenciamento de recursos humanos

4.6.1. Objetivo

Descrever como o processo de Gerenciamento de Recursos Humanos do projeto “Data Warehouse Oceanográfico” será estruturado e conduzido durante o seu ciclo de vida.

O Plano de Gerenciamento de Recursos Humanos descreve quando e como serão atendidos os requisitos de recursos humanos do projeto.

4.6.2. Funções e responsabilidades no gerenciamento de recursos humanos

Quadro 26 – Funções e responsabilidades no Gerenciamento de Recursos Humanos

	Participante	Funções e Responsabilidades de Recursos Humanos
1	Gerente do Projeto	Principal responsável pelo gerenciamento de recursos humanos dentro do projeto, focando o planejamento de recursos (efetivos e contratados), desenvolvimento da equipe, mobilização / desmobilização da equipe, avaliação de desempenho da equipe, realização de atividades para reconhecimento e recompensa e gerenciamento de conflitos.
2	Equipe de Gerenciamento do Projeto	Responsável por analisar os dados coletados, consolidar os documentos do projeto, produzir dados e informações para subsidiar o trabalho da coordenação e a tomada de decisão. Responsável também pela contratação e avaliação das equipes contratadas “por uso” devido ao caráter de evento do projeto.
3	Patrocinadores	Devem disponibilizar recursos para que o Plano de Treinamento seja realizado.

 

4.6.3. ESTRUTURA ANALÍTICA DE RECURSOS (EAR)

4.6.4. ESTRUTURA ANALÍTICA ORGANIZACIONAL (EAO)

4.6.5. Equipe do projeto

A equipe do projeto é composta de profissionais qualificados para o exercício da função.

Os recursos humanos do projeto estão distribuídos conforme apresentado no quadro abaixo.

Quadro 27 – equipe do trabalho

Nome	Função	Lotação	Ramal	Meses no projeto	Regime de Trabalho	Dedicação (Integral ou Parcial)
						Tipo	%
Ana Paula Cortinovis	Gerenciar o projeto	Escritório RJ	7979	8	Sócio	P	50
Jeane	Equipe do projeto	Escritório RJ	7970	8	Sócio	P	50
João	Equipe do projeto	Escritório RJ	7981	8	Sócio	P	50

 

4.6.6. Matriz de responsabilidade

Quadro 28 – Matriz de responsabilidade

MATRIZ DE RESPONSABILIDADES
Projeto: DW Oceanográfico	Coordenador: Ana Paula Cortinovis		Atualizada em: 05/08/16
Atividades	Participantes do Projeto
	Ana Paula Cortinovis	Jeane	João
Plano de gerenciamento de RH	R, A	Rv, P	P
Mobilizar a equipe do projeto	R, I	P	I
Desenvolver a equipe do projeto	R, I	S	P
Gerenciar a equipe do projeto	R, I	P	I

 

Legenda das Responsabilidades
R	Responsável	Somente um responsável pela entrega
Rv	Revisão	Responsável pela revisão
A	Aprovação	Responsável pela aprovação
C	Consultado	Pessoa a ser consultada antes que a decisão seja tomada
I	Informado	Pessoa a ser informada sobre a decisão tomada
P	Participante	Pessoa que suporta ou participa da execução
S	Supervisão	Pessoas que supervisiona e apoie o serviço

 

4.6.7. Recrutamento e seleção

Devido ao tipo de projeto que esse plano faz referência, a maior parte das atividades será executada pela equipe de construção do Data Warehouse. Para as tarefas em que haverá a especificação dos tipos de dados e especificação das informações referentes a oceanografia obtidas a partir de entrevistas, está previsto a contratação de especialistas temporário.

Há um banco de cadastros disponível que pode ser usado para alocação desse pessoal ao longo do projeto. O pessoal ficará disponível sempre no período pré-estabelecido e a disponibilidade deverá ser exclusiva para a atividade a qual foi direcionada.

4.6.8. Treinamento

Haverá treinamento técnico para a equipe de TI que manterá o sistema após a entrega do projeto e também treinamento operacional para os funcionários que são usuários do sistema. Serão passadas as informações gerais e especificas para cada equipe de trabalho (TI e operacional), o que se espera da equipe e quais atividades deverão ser realizadas.

4.6.9. Avaliação

O principal indicador usado para avaliação do pessoal contratado será o absenteísmo (faltas) e a capacidade de produtividade. A partir de 2 (duas) faltas sem justificativa abre precedente para a não contratação desse prestador de serviço no próximo projeto.

Além desse indicador será observado o relacionamento desses contratados com os funcionários da empresa e seus colegas de trabalho.

4.6.10. Reconhecimento e recompensa

Para o pessoal que estiver com suas avaliações positivas, será observada sua pró-atividade no dia a dia e a capacidade de resolução de problemas que surjam ao longo do projeto. Para as pessoas reconhecidamente capazes nesses itens, será possível oferecer o cargo de líder de equipe nos próximos contratos.

Para a equipe de gerenciamento de projeto não está prevista nenhuma recompensa em particular por todos serem sócios da empresa.

4.7. Plano de gerenciamento de comunicações do projeto

4.7.1. Objetivo do plano de gerenciamento da comunicação do projeto

O objetivo do plano de gerenciamento da comunicação é assegurar que as informações do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradas e dispostas de maneira oportuna e apropriada.

4.7.2. Gerenciamento das comunicações

O gerenciamento será realizado através de processos de comunicações utilizados pela empresa, tais como: e-mail corporativo, documentos impressos e reuniões com geração de atas.

Todas as informações geradas durante o projeto devem ser registradas em diretório disponibilizado para o projeto e cada alteração no conteúdo das informações deve ser gerado um backup da versão atual antes da alteração.

4.7.3. Eventos de comunicação

O projeto possuirá os seguintes eventos de comunicação:

4.7.3.1. Reunião inicial (Kick-off)

É uma reunião que formaliza o início do projeto, apresentando as informações quanto ao seu objetivo, sua importância e benefícios para a empresa.

• Objetivo: Comunicar a equipe o histórico do projeto, revisar o planejamento detalhado do projeto, criar o espirito de grupo e entusiasmar a equipe, comunicar os processos de autorização, informar a agenda e a frequência de reuniões, definir as responsabilidades dos membros da equipe, comunicar o método de acompanhamento e controle e esclarecer dúvidas da equipe.
• Metodologia: reunião com a utilização de projetor, computador e sistema de som.
• Responsável: gerente do projeto
• Envolvidos: todos os participantes do projeto, gerente executivo e convidados.
• Data e horário: dia 01/03/2016 às 13:30 hs
• Duração: 3 horas
• Local: Auditório
• Formalização: via convite do e-mail corporativo com solicitação de aceite.

4.7.3.2. Reunião de acompanhamento

São reuniões realizadas regularmente ao longo da implantação do projeto, a fim de avaliar a performance do projeto, corrigir eventuais desvios e definir alterações necessárias.

• Objetivo: revisão dos itens abordados na última reunião, atualização do andamento das atividades dos cronogramas, identificação de problemas e definição de ações corretivas, revisão dos pontos de atenção, identificação do status dos riscos do projeto e planejamento dos próximos passos.
• Metodologia: reunião com a utilização de projetor e computador conectado ao sistema de informação do projeto.
• Responsável: Gerente de projeto
• Envolvidos: equipe do projeto
• Frequência: semanalmente, às segundas-feiras, como início dia 06/03/16 e término em 17/10/2016.
• Reuniões extraordinárias: podem ser solicitadas reuniões extraordinárias para tratamento de assuntos específicos em relação ao andamento do projeto através de solicitação formal do Gerente do projeto.
• Duração: 1 hora, com início às 10hs
• Local: Sala de reunião
• Formalização: via convite do e-mail corporativo com solicitação de aceite.

4.7.3.3. Reunião de progresso

São reuniões para avaliação e comunicação a todos os stakeholders de como os recursos do projeto estão sendo utilizados, tendo por base o plano do projeto.

• Objetivo: Apresentar o status do projeto (onde o projeto se encontra), o progresso (o que a equipe do projeto já realizou), as previsões (status e progresso futuro), os principais riscos e as principais pendências.
• Metodologia: reunião com a utilização de projetor e computador conectado ao sistema de informação do projeto.
• Responsável: Gerente do projeto
• Envolvidos: Gerente executivo, gerente do projeto e coordenador da equipe do projeto.
• Frequência: Quinzenalmente com data e hora a serem definidas conforme disponibilização da agenda do executivo.
• Duração: 1 hora.
• Local: Sala de reunião
• Formalização: via convite do e-mail corporativo com solicitação de aceite.

4.7.3.4. Reunião de aceite e encerramento do projeto

Reunião que formaliza a entrega e finalização do projeto.

• Objetivo: Levantar o grau de satisfação do resultado do projeto, consolidar as lições aprendidas e divulgar os pontos relevantes realizados no projeto;
• Metodologia: reunião com utilização de projetor e computador conectado ao sistema de informação do projeto;
• Responsável: Gerente do projeto;
• Envolvidos: todo os envolvidos no projeto, gerente executivo e convidados;
• Frequência: final do projeto;
• Duração: 3 horas;
• Local: Auditório; e
• Formalização: via convite do e-mail corporativo com solicitação de aceite.

4.7.3.5. Relatório de status dos níveis de serviço

Relatório com informações do status dos níveis de serviço alcançados no projeto, contendo as informações solicitadas nos indicadores de qualidade. Será produzido mensalmente pelo Gerente do Projeto e enviado ao Coordenador da equipe do projeto para aprovação antes de ser apresentado nas reuniões executivas.

4.7.3.6. Termo de aceite de entregáveis

Documento que formaliza que cada entrega foi finalizada, o Coordenador da equipe do projeto é o responsável por emitir este documento assinado.

4.7.3.7. Atas de reunião

Todas as reuniões do projeto, com exceção do Kick-off e de encerramento, deverão apresentar ata de reunião com, no mínimo, os seguintes dados: lista de presença, pauta, decisões tomadas, pendências não solucionadas e aprovações.

As atas deverão ser encaminha para todos os integrantes da equipe do projeto para aprovação e após deverá ser arquivada e disponibilizada em diretório específico fornecido pela empresa.

4.7.4. Matriz de comunicação

Quadro 29 – Matriz de comunicação do projeto

Tipo de Comunicação	Finalidade	Periodicidade	Audiência Mínima	Documentos Gerados
Reunião Inicial	Realizada no início do projeto, apresenta ao cliente as diretrizes gerais do projeto e formaliza sua data de início.	Única, no início do projeto.	Cliente e Equipe do Projeto.	Apresentação de início do projeto e plano de comunicações.
Reuniões de Acompanhamento	Apresentar o andamento das atividades considerando o plano de trabalho aprovado.	Semanal	Gerente do Projeto e Chefes das equipes contratadas.	Relatório sobre a situação do cronograma de entregas.
Reuniões de Progresso	Apresentar tópicos desenvolvidos no período, com a finalidade de transmitir conhecimento ao longo de todo o projeto.	Quinzenal	Gerente do Projeto, Representantes dos Patrocinadores e Chefes de Equipe.	Documentação utilizada para apresentação dos tópicos.
Reunião de aceite e encerramento do projeto	Levantamento do grau de satisfação do Cliente, lições aprendidas e outros pontos relevantes do projeto.	Ao final do Projeto	Gerente do Projeto, Representantes dos Patrocinadores e Chefes de Equipe.	Termo de aceite e encerramento do projeto assinado.
Relatório de Status dos Níveis de Serviço	Relatório com informações do status dos Níveis de Serviço, contendo as informações solicitadas nos indicadores de qualidade.	Mensal	Gerente de Projetos envia para o Cliente.	Relatório de Status dos Níveis de Serviço.
Termo de aceite de entregáveis faturados	Cada fase será considerada finalizada após a emissão do termo de aceite por parte do Cliente	Na entrega de cada evento de faturamento	Gerente de Projetos envia para o Cliente.	Termo de aceite assinado.

4.7.5. Administração do plano de gerenciamento das comunicações

O responsável pelo plano de comunicação é o Gerente do Projeto sendo, caso necessário, substituído pelo Coordenador da equipe do projeto. A frequência de atualização do plano de comunicação será realizada conforme a necessidade solicitada por membro da equipe do projeto durante as reuniões de acompanhamento com aprovação dos participantes.

4.8. Plano de gerenciamento de riscos do projeto

4.8.1. Objetivo do plano de gerenciamento dos riscos

O Plano de Gerenciamento de Riscos busca em como objetivo aumentar a probabilidade e o impacto dos eventos positivos, reduzir a probabilidade e o impacto dos eventos negativos e orientar a equipe do projeto sobre como os processos de riscos serão executados.

4.8.2. Gerenciamento dos riscos

O gerenciamento de risco do projeto será realizado com base nos riscos previamente identificados, assim como no monitoramento dos novos riscos que possam ser identificados oportunamente na evolução do projeto.

A identificação e avaliação dos riscos do projeto serão realizadas, inicialmente, durante a fase de planejamento do projeto, contando com a presença de toda a equipe do projeto. Para isso serão utilizadas técnicas de brainstorming e a análise Strengths, Weaknesses, Opportunities e Threats (SWOT).

Todos os riscos não previstos neste plano devem ser incorporados ao projeto dentro do sistema de controle de mudança de risco.

As avaliações, identificações e monitoramento dos riscos devem ser realizados por escritos via ata de reunião conforme plano de comunicação do projeto.

4.8.3. Descrição do Processo de Gerenciamento de Riscos

O Processo de Gerenciamento de Riscos foi dividido nas seguintes etapas:

– Identificação: Consiste em determinar que riscos podem afetar o projeto e documentar suas características. Novos riscos podem ser identificados ao longo do ciclo de vida do projeto e serem incorporados a este plano.

– Análise: Consiste em atribuir um peso para cada risco identificado. A abordagem será baseada nas análises qualitativa e quantitativa de riscos.

– Planejamento de Respostas: Consiste no processo que visa a elaboração de um plano de opções e ações visando a redução das vulnerabilidades e o aproveitamento das oportunidades encontradas no projeto.

– Monitoramento e Controle de Riscos: Consiste no acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto.

4.8.4. Diretrizes para Identificação de Riscos

Serão realizadas reuniões, usando a técnica de brainstorming, de Identificação e Análise de Riscos com a equipe do projeto e, quando necessário, com participantes e convidados externos convocados.

Serão identificados riscos que afetem as seguintes disciplinas:

• Aspectos Financeiros
• Aspectos Legais e Contratuais
• Prazo
• Tecnologia Empregada
• Experiência e Capacidade

4.8.5. Diretrizes para Análise de Riscos

Todos os riscos identificados pela equipe do projeto devem passar pelo processo de Análise.

Informações históricas existentes sobre eventos de riscos similares que tenham sido identificados ou ocorridos em projetos anteriores devem ser utilizadas nas estimativas de probabilidade e impacto a serem realizadas, incrementando as estimativas.

4.8.6. Análise Qualitativa

Análise Qualitativa de Riscos consiste na priorização dos riscos para análise ou ação adicional subsequente através de avaliação e combinação de sua probabilidade de ocorrência e impacto. A análise qualitativa de riscos avalia a prioridade dos riscos identificados usando a probabilidade de ocorrerem, o impacto correspondente nos objetivos do projeto se os riscos realmente ocorrerem, além de outros fatores, como prazo e tolerância a risco das restrições de custo, cronograma, escopo e qualidade do projeto.

Os riscos identificados serão qualificados na sua probabilidade de ocorrência e impacto nos resultados do projeto conforme descrição a seguir:

a) Probabilidade

• Baixa: Riscos identificados, porém, cuja ocorrência não é esperada durante o projeto ou que possuam probabilidade menor que 15%.
• Média: Riscos identificados, para os quais é esperado a ocorrência em algum momento do projeto ou cuja probabilidade é igual ou maior que 15% e menor que 50% ou desconhecida.
• Alta: Riscos evidentes ao projeto, cuja ocorrência é esperada à curto prazo ou que possuam probabilidade de ocorrência maior ou igual à 50% em algum momento durante o projeto

Resultando em:

Probabilidade	Baixa	Média	Alta
	< 15%	>= 15% e < 50%	>= 50%

 

b) Impacto

• Baixo: Risco cujo impacto no tempo ou custo seja menor que 5% do tempo total do projeto respectivamente.
• Médio: Risco cujo impacto no tempo ou custo seja igual ou maior que 5% e menor que 10% do tempo total do projeto respectivamente.
• Alto: Risco cujo impacto no tempo ou custo seja igual ou maior que 10% do tempo total do projeto respectivamente.

Resultando em:

Impacto (Tempo ou Custo)	Baixo	Médio	Alto
	< 5%	>= 5% e < 10%	>= 10%

 

A partir desta análise, pode-se traçar a perda esperada do risco para o projeto, sendo esta a relação entre a probabilidade de ocorrência e o impacto do risco, segundo a tabela abaixo:

Perda Esperada do Risco		Probabilidade
		Baixa	Média	Alta
Impacto	Alto	Média	Alta	Alta
	Médio	Baixa	Média	Alta
	Baixo	Baixa	Baixa	Média

 

4.8.7. Análise Quantitativa

Análise Quantitativa de Riscos consiste na análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto. A análise quantitativa de riscos é realizada nos riscos que foram priorizados pelo processo de Análise Qualitativa de Riscos por afetarem potencial e significativamente as demandas conflitantes do projeto. Analisa o efeito desses eventos de risco e atribui uma classificação numérica a esses riscos. Ela também apresenta uma abordagem quantitativa para a tomada de decisões na presença da incerteza.

Por se tratar de um projeto onde somente os riscos internos serão considerados relevantes, chegou-se a um consenso de analisar os riscos somente sobre aspectos qualitativos, utilizando-se o conceito qualitativo de valor agregado. Ou seja, a análise quantitativa dos riscos, não será realizada neste projeto.

4.8.8. Diretrizes para Resposta ao Riscos

Com base na Perda Esperada do Risco, identificamos a prioridade de tratamento dos riscos. Esperam-se, no mínimo, os seguintes tratamentos:

Perda Esperada Alta: Riscos de alta prioridade, para os quais devem ser elaborados planos de mitigação e contingência ao risco, ou de eliminação quando possível.

Perda Esperada Média: Riscos de prioridade moderada, para os quais devem ser elaborados, pelo menos, planos de contingência ao risco.

Perda Esperada Baixa: Riscos de baixa prioridade, para os quais não são necessários planos de resposta ao risco ou planos de aceitação.

Embora, com base em informações históricas existentes sobre eventos de riscos similares, possam ser propostos outros tratamentos para essas perdas esperadas dentro das estratégias básicas de resposta, sendo elas:

Eliminação: Estratégia que procura, através de ações executadas com antecedência, a eliminação da probabilidade de ocorrência do risco (por exemplo, eliminando suas causas) ou a proteção dos objetivos do projeto em relação aos efeitos indesejados do risco. Tipicamente, deve ser utilizada para responder a riscos considerados muito altos ou estratégicos.

Mitigação: Estratégia que procura, através de ações executadas com antecedência, a diminuição da probabilidade de ocorrência ou das consequências do evento de risco a níveis aceitáveis para o projeto.

Transferência: Estratégia que procura, através de ações executadas com antecedência, a transferência legal de todo ou parte do risco para terceiros, através, por exemplo, da contratação de seguros ou de cláusulas contratuais.

Aceitação: Aceitar um risco significa não executar qualquer ação até que o risco aconteça. A aceitação é considerada ativa quando um plano de contingência é elaborado e registrado. Esse plano será colocado em ação se o evento de risco ocorrer. Opcionalmente, poderá ser elaborado um plano reserva (plano “B”), que será executado se o plano de contingência original não for efetivo na resposta ao risco. A aceitação é considerada passiva quando nenhum plano de contingência é cadastrado; esse tipo de aceitação só é indicado para riscos classificados como baixos e que não tenham caráter estratégico.

Para riscos que podem trazer um impacto positivo nos objetivos do projeto (oportunidades), devem ser planejadas ações de resposta que procurem aumentar a probabilidade de ocorrência do evento ou seu efeito positivo no projeto. No Planejamento de respostas a oportunidades, devem-se priorizar aqueles eventos que tragam maior benefício esperado para o projeto.

Ao se planejar respostas a riscos do projeto, deve-se observar a possibilidade de aparecimento de riscos secundários, que são eventos de risco originados em virtude da execução de ações de resposta. Esses riscos secundários deverão, por sua vez, seguir os processos de Gerenciamento de Riscos definidos para o projeto.

Todas as respostas propostas, independente da estratégia adotada, devem ser realistas dentro do contexto do projeto, inclusive em termos de custo, e devem ter um responsável designado para sua execução.

4.8.9. Diretrizes para Monitoramento e Controle de Riscos

O monitoramento e controle dos riscos do projeto são realizados durante as reuniões semanais de monitoramento e controle do projeto, conforme estabelecido no Plano de Comunicação do Projeto.

Durante as reuniões, são avaliadas as modificações dos atributos de situação, probabilidade de ocorrência e impacto dos riscos, bem como os valores para os gatilhos e a efetividade dos planos de resposta aos riscos.

4.9. Plano de gerenciamento da qualidade do projeto

4.9.1. Objetivo do plano de gerenciamento da qualidade do projeto

O plano de gerenciamento da qualidade define requisitos e padrões de qualidade que serão aplicadas no projeto e as suas entregas. Descreve como será verificado a conformidade das entregas respeitando a política de qualidade da empresa.

O gerenciamento da qualidade tem como objetivo satisfazer todos os requisitos funcionais e não-funcionais que perfazem o escopo deste projeto. Os procedimentos de qualidade deverão abranger toda infraestrutura construída e os treinamentos executados, bem como a adequação e melhoria do processo de desenvolvimento aplicado.

4.9.2. Processos do gerenciamento da qualidade

– Garantia de qualidade

Ao término de cada pacote de trabalho ou fase, serão levantados e demonstrados, a toda equipe alocada, os níveis de qualidade alcançados, os problemas existentes, os riscos identificados e as lições aprendidas, com previsto no plano de comunicação do projeto. Será realizado auditoria dos requisitos de qualidade e dos resultados das medições do controle da qualidade para garantir que sejam usados os padrões de qualidade e definições operacionais apropriados.

– Controle da qualidade

Modificações no plano de gerenciamento de qualidade devem ser solicitadas por e-mail corporativo ao gerente de projeto e coordenador da equipe do projeto. Quando aprovadas deverá ser enviado um comunicado por e-mail corporativo a todos os integrantes do projeto, conforme descrito no plano de comunicação do projeto.

O monitoramento e registro dos resultados da execução das atividades de qualidade são importantes para avaliar o desempenho e recomendar as mudanças necessárias.

4.9.3. Requisitos de sucesso do projeto

O projeto será considerado um sucesso se atender a todos os critérios de aceitação das entregas, respeitar as restrições e cumprir o cronograma de execução e principalmente atender os requisitos e padrões de qualidade detalhados nesse plano

4.9.4. Métricas da qualidade

Os padrões de mercado ou da organização a serem atingidos estão descritos abaixo.

Padrão	Norma/Procedimento do SGQ
ISO 9001:2008	Esta norma define requisitos no âmbito da gestão empresarial, ela define quais características do seu produto ou qual o nível de ruído ideal no ambiente de trabalho, por exemplo.

 

4.9.5. Auditoria do processo

A Auditoria do Processo visa avaliar se o projeto está sendo realizado de acordo como definido e se os resultados do projeto certificam que o processo aplicado está adequado. Esta atividade será realizada pelo Gerente do Projeto ao final de cada iteração.

As não-conformidades serão registradas em formulário próprio e encaminhadas ao Coordenador da equipe do projeto. As readequações do processo que se fizerem necessárias serão comunicadas ao Gerente de Projetos, o qual determinará quando estas serão implementadas, promovendo, assim, uma constante melhoria nos processos.

4.9.6. Ferramentas de qualidade

Quadro 30 – Lista das ferramentas de qualidade

Ferramenta	Descrição da aplicação	Quando aplicar	Responsável
CheckList	Aplicável em todos as entregas deste projeto.	Ao término de cada etapa, conforme definido no cronograma do projeto.	Gerente do Projeto
Diagrama de cauda e efeito Ishikawa ou espinha de peixe	Identificação da causa raiz de um determinado problema (causas comuns e causas especiais)	Quando uma entrega não for aprovada na inspeção do controle de qualidade.	Gerente do Projeto
Gráfico de Pareto	Analisar os problemas e priorizar os mais críticos para tomada de decisões e melhoria de processos	Quando houver ocorrências de inconformidade na qualidade	Gerente do Projeto
Auditoria do Processo	Aplicável a todos os processos de execução do projeto.	Mensalmente	Auditor
Diagrama de controle	Permite verificar se os resultados estão sob controle ao longo de um período	Mensalmente	Gerente do Projeto

 

4.9.7. Processos de melhoria contínua

O processo de melhoria contínua é baseado no ciclo PDCA (Plan-Do-Check-Act) e detalha as etapas de análise de processos para identificar as atividades que aumentam o seu valor, possibilitando gerenciá-las de forma eficiente e eficaz ao aplicar a técnica de análise de processos durante a execução do projeto.

A cada ciclo concluído do projeto serão observados as lições aprendidas e o valor que cada processo agregou na qualidade das entregas e na melhoria dos indicadores monitorados. Os processos serão revisitados e monitorados a fim de garantir sua eficiência e evitar desvios das metas estipuladas.

O ciclo PDCA consiste em quatro fases, conforme a seguir:

• Plan (Planejamento) – responsável por estabelecer metas e objetivos para serem alcançados e padronização dos procedimentos que serão utilizados;
• Do (Execução) – fase de implementação do planejamento, momento responsável por coletar os dados, que serão avaliados posteriormente na fase de verificação;
• Check (Verificação) – esta fase é responsável por verificar se a meta planejada foi devidamente alcançada, nesta fase, utiliza-se de ferramentas que apoiam na verificação, exemplo: ferramenta de controle e acompanhamento, histogramas, folhas de verificação etc.;
• Act (Ação corretiva) – fase que consiste em buscar as causas e prevenir efeitos indesejados e adotar padrões de processos que apoiaram as próximas etapas do projeto.

Desta forma, além de promovermos a melhoria contínua dos processos, também buscaremos a satisfação gradativa do cliente.

4.9.8. Administração do plano de gerenciamento de qualidade 

O responsável pelo plano de gerenciamento de qualidade será o Gerente de Projetos, que terá o apoio caso seja necessário do Gerente de Divisão.

O acompanhamento do gerenciamento de qualidade será analisado durante as reuniões de finalização de fase ou reuniões de ponto de controle de etapa.

Os procedimentos de controle da qualidade do projeto serão realizados na conclusão de cada etapa antes de sua aprovação. O controle de qualidade será realizado através de inspeção nas entregas utilizando-se os checklists (folhas de anotações técnicas) e respectivamente, os seus indicadores, a fim de manter a qualidade do projeto e garantir o processo de melhoria contínua.

4.10. Plano de gerenciamento de aquisições do projeto

4.10.1. Objetivo do plano de gerenciamento das aquisições

O objetivo deste plano é descrever como os processos de aquisição serão gerenciados desde o desenvolvimento dos documentos de aquisições até o encerramento do contrato.

4.10.2. Gerenciamento das aquisições

O gerenciamento de aquisições em projetos é um aspecto vital para o sucesso do projeto. A racionalização leva a maior dependência de recursos externos e pode determinar o sucesso e fracasso do projeto.

O gerenciamento de aquisições envolve os processos necessários para obter bens e serviços do mercado, para atender às necessidades do projeto. Geralmente, a maior parcela do orçamento do projeto é consumida em aquisições/contratos.

4.10.3. Critérios de avaliação de propostas

Para contratação de serviços de treinamento externo será necessário à solicitação de proposta com a grade de cursos e tópicos a serem abordados, o processo de decisão para contratação será baseado na que melhor supra a necessidade de conhecimento e no preço. Levando-se, também, em consideração a observação para que não inflija às premissas e restrições do projeto.

4.10.4. Avaliação dos fornecedores

A avaliação dos fornecedores será realizada pela equipe de desenvolvimento durante a realização dos cursos contratados em reunião específica com o objetivo de verificar o cumprimento de prazos, qualidade do ensino e infraestrutura fornecidos.

Nos casos de não cumprimento dos itens de contrato por parte do contratado, as seguintes medidas podem ser tomadas:

• Advertência ao fornecedor: para desvios leves que não comprometam o sucesso no cumprimento dos prazos e escopo contratado;
• Suspensão do fornecedor: para desvios médios que comprometam parte do escopo do contrato ou para reincidência de advertência;
• Cancelamento do contrato: para desvios graves que comprometam o serviço contratado e que necessitem de intervenção direta do Gerente de Divisão ou para fornecedores já suspensos anteriormente.

4.10.5. Frequência de avaliação dos processos das aquisições

Os processos de aquisições devem ser avaliados semanalmente e apresentados na reunião de acompanhamento, prevista no plano de gerenciamento das comunicações.

4.10.6. Encerramento das aquisições

O processo de encerramento de contratos consiste em assegurar que todos os aspectos administrativos relativos a um contrato estão concluídos, após a entrega dos produtos ou serviços pelo fornecedor e a correspondente verificação de escopo pela empresa contratante.

Os contratos envolvidos neste projeto e contemplados neste plano devem ser conduzidos de forma que os serviços constantes no escopo do contrato sejam realizados e oficializados a conclusão e aceitação. Sendo assim os contratos também podem ser encerrados pelo termino das atividades estabelecidas contratualmente, pelo acordo mútuo entre as partes ou pela inobservância das obrigações contratualmente estabelecidas, denominada rescisão ou resolução, que ocorre de forma unilateral.

Para fins de formalização de realização e conclusão dos cursos contratados, deve ser fornecido pela contratada um certificado de conclusão com o nome do funcionário que participou.

4.10.7. Administração do plano de gerenciamento das aquisições

O responsável pelo plano de gerenciamento das aquisições é o Gerente do Projeto, sendo, quando necessário, substituído pelo Gerente de Divisão.

O plano de gerenciamento das aquisições será reavaliado mensalmente e atualizado durante a primeira reunião de acompanhamento do mês. Qualquer necessidade de atualização do plano, antes da primeira reunião de acompanhamento, deverá ser solicitada por e-mail corporativo ao Gerente de Projeto e com aceite do Gerente de Divisão.

4.11. Plano de gerenciamento das partes interessadas do projeto

4.11.1. Objetivo do plano de gerenciamento das partes interessadas do projeto

O objetivo deste plano é descrever como os processos das partes interessadas serão gerenciados desde a identificação das partes interessadas até o encerramento do projeto.

O gerenciamento de partes interessadas deve englobar o maior número de variáveis e informações de acompanhamento dos envolvidos como, por exemplo, o nível de influência, o envolvimento nas possíveis mudanças, a probabilidade de impactarem o projeto, a possibilidade de serem impactadas pelo projeto, os níveis de interesse, os níveis hierárquicos, os níveis de autoridade e os níveis de poder. Dessa forma a importância do levantamento de partes interessadas, e posteriormente do seu acompanhamento, para identificar qual tratamento deverá ser dado a cada parte interessada.

4.11.2. Identificação das partes interessadas

A identificação das partes interessadas do projeto constitui em determinar todas as pessoas ou organizações que estejam ativamente envolvidas no projeto, que possam afetar ou serem afetadas por uma decisão, atividade, ou resultado do projeto e possam influenciar no andamento ou resultado do projeto.

Conforme ilustrado na Figura 17, o organograma hierárquico das partes interessadas apresenta todos os envolvidos direta e indiretamente no projeto. Segue:

• Gerente do Projeto: é o responsável direto e máximo do gerenciamento do projeto e do controle macro de atividades;
• Coordenador de equipe: é o responsável em apoiar e auxiliar o gerente dos projetos em todas as fases do projeto. E na ausência do gerente do projeto, o coordenador é o substituto direto;
• Equipe de Desenvolvimento: são todos os funcionários integrantes da equipe de desenvolvimento de sistemas;
• Equipe de DBA: são todos funcionários integrantes da equipe de Administração dos bancos de dados; e
• Oceanógrafos: são todos os funcionários integrantes da equipe e possui especialidade em oceanografia.

4.11.3 Gerenciamento das partes interessadas

Para o gerenciamento das partes interessadas do projeto devem ser analisadas de que forma, positiva ou negativa, as partes interessadas impactam o projeto, realizando a análise de impacto através do levantamento do grau de interesse, das expectativas em relação ao projeto, sua importância, nível e grau de influência com o registro das partes interessadas.

Onde:

A primeira área, chamada de 2º quadrante, é apresentado os stakeholders (partes interessadas) que possuem interesse e importância negativa no projeto e a segunda área, chamada de 1º quadrante, é apresentado os stakeholders que possuem interesse e importância positiva no projeto, conforme exemplifica a figura 20.

4.114 Engajamento das partes interessadas

Para gerenciar o engajamento das partes interessadas deve ser mapeado o nível de engajamento atual para que seja possível analisar quais estratégias deverão ser utilizadas para quebrar a resistência e garantir seu engajamento.

4.11.5. Controlar o engajamento das partes interessadas

O controle do engajamento das partes interessadas deve ser realizado mensalmente através da comparação do nível de engajamento identificado com o desejado, conforme matriz de avaliação do nível de engajamento mostrada neste plano.

4.116 Administração do plano de gerenciamento das partes interessadas

O responsável pelo plano de gerenciamento das partes interessadas é o Gerente do Projeto, sendo, quando necessário, substituído pelo Coordenador de equipe.

O plano de gerenciamento das partes interessadas será reavaliado mensalmente e atualizado durante a primeira reunião de acompanhamento do mês. Qualquer necessidade de atualização do plano, antes da primeira reunião de acompanhamento, deverá ser solicitada por e-mail corporativo ao Gerente de Projeto.

CONSIDERAÇÕES FINAIS

O objetivo deste trabalho foi desenvolver um projeto que possibilite a propagação dos dados de oceanografia para a comunidade científica, universidades e pesquisadores. Para isso, foram aplicadas as boas práticas de gerenciamento de projetos do Guia PMBOK®, possibilitando uma melhor documentação dos processos utilizados e identificação e acompanhamento das atividades realizadas.

Mostrou-se muito importante, antes do início efetivo das atividades do projeto, a passagem de conhecimento, para todos os participantes do projeto, sobre como se realiza o gerenciamento de projetos do Guia PMBOK®. Possibilitando um maior comprometimento e engajamento de toda a equipe.

A implantação de padrões de projetos na criação, implementação e carga no banco de dados a partir de dados oriundos de comissões, possibilitou o reaproveitamento de códigos para a criação de processos ETL para o carregamento dos dados de diversos equipamentos. Pois, formou um vocabulário comum que permitiu uma melhor comunicação entre os desenvolvedores e uma documentação mais completa.

Para facilitar e reduzir o tempo de aprendizado de desenvolvedores e administradores de banco de dados novatos, toda documentação técnica e registro das lições aprendidas, principalmente da fase de treinamentos, mostrou-se como as principais tarefas do projeto a serem utilizadas para este fim.

A conclusão do projeto possibilitou para a empresa a visibilidade, na comunidade científica, de ser um centro de dados de oceanografia. Aumentando assim a possibilidade de capitar mais investimentos para melhoria e manutenção do DW Oceanográfico. Possibilitou a entrega de um visualizador web para o cliente consultar de forma online os dados que deseja obter, aumentando assim a satisfação do cliente final.

REFERÊNCIAS

TRENTIM, Mário Henrique. Manual do MS-Project 2010 e melhores práticas do PMI®. Editora Atlas. 2012

LINHARES, Jorge; QUARTAROLI, Cláudio Márcio. Guia de Gerenciamento de Projetos e Certificações PMP. Rio e Janeiro: Editora Ciência Moderna Ltda., 2004.

Roteiro Uerj para monografia. Disponível em: <http://www.bdtd.uerj.br/roteiro_uerj_web.pdf>. Acesso em 30/09/2016

Informações sobre oceanografia. Disponível em: <http://www.infoescola.com/ciencias/oceanografia/>. Acesso em 27/08/2016 às 10:23hs

Informações sobre as áreas de conhecimento do guia PMBOK®. Disponível em: <http://www.projectbuilder.com.br/blog-pb/entry/conhecimentos/o-que-e-pmbok>. Acesso em 28/08/2016 às 12:22hs

Tabela e quadro: diferenças. Disponível em: <https://bibliotecafea.com/tag/abnt/>. Acesso em 03/09/2016 às 16:34

Informações sobre Plano de gerenciamento da qualidade. Disponível em: <http://escritoriodeprojetos.com.br/plano-de-gerenciamento-da-qualidade>. Acesso em 30/10/2016 às 14:54h

^[1] Especialização em Tecnologia da Informação, Gestão de Negócios e de Projetos – Instituto de Matemática e Estatística da Universidade do Estado do Rio de Janeiro