basicmethodware-110301131921-phpapp01

75
UNIVERSIDADE ESTADUAL DE GOIÁS Unidade de Pirenópolis Disciplina: Eventos / Prof.: Gedson e Carlos Alberto 1 Introdução ao BASIC METHODWARE® Em um mercado cada vez mais globalizado e competitivo, que tem levado as organizações a viverem em permanente estado de mudança, temos presenciado nos últimos anos, especialmente no Brasil, uma busca incessante das empresas no uso de melhores práticas de gerenciamento de projetos. Essa busca tem sido incentivada e facilitada pelo PMI – Project Management Institute organização referência mundial em Gerenciamento de Projetos (www.pmi.org). Essa instituição divulga “o que” é necessário para o gerenciamento de projetos, sem entrar no mérito de “como” esses processos devem ser realizados e em que seqüência. A metodologi a de gerenciam ento de pr oj etos Method wa re®, desenvo lvida pela Bew ar e Consultoria Empr es ar ial (www.beware.com.br), é direcionada para empresas e instituições que precisam aumentar a chance de sucesso de seus projetos, através do estabelecimento de métodos para iniciar , planejar , executar , monitorar e controlar e finalizar projetos. Totalmente alinhada com o PMBOK® 4a edição (publicação do PMI), apresenta de forma objetiva “como” o gerenciamento de projetos deve ser realizado. Essa metodologia foi publicada no livro “Metodologia de Gerenciamento de Projetos – Methodware ”, de Carlos Magno da Silva, Flávio Vivacqua, Otualp Macedo e Luiz Xavier, que recebeu em jun ho de 2010 o prêmio "Melh or Livro Brasileiro de Gerenciamento de Projetos da Década". Esta premiação foi organizada pelo PMI-Rio como parte do 8º Encontro Nacional de Profissionais de Gerenciamento de Projetos, considerado um dos eventos anuais mais importantes nessa área no Brasil. Mais de mil profissionais de gerenciamento de projetos, de todo o Brasil, participaram da votação. A Basic Methodware® é uma versão simplificada da Methodware®, de utilização prática, para estudantes e gerentes de projetos de pequeno e médio porte, utilizando o projeto de um treinamento para exemplificar os procedimentos de cada processo. Ela também BASIC METHODWARE (www.methodware.com.br)

Transcript of basicmethodware-110301131921-phpapp01

Page 1: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 1/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto1

Introdução ao BASIC METHODWARE® 

Em um mercado cada vez mais globalizado e competitivo, que tem levado as organizações a viverem em permanente estado de

mudança, temos presenciado nos últimos anos, especialmente no Brasil, uma busca incessante das empresas no uso de melhores

práticas de gerenciamento de projetos. Essa busca tem sido incentivada e facilitada pelo PMI – Project Management Institute –

organização referência mundial em Gerenciamento de Projetos (www.pmi.org). Essa instituição divulga “o que” é necessário para o

gerenciamento de projetos, sem entrar no mérito de “como” esses processos devem ser realizados e em que seqüência.

A metodologia de gerenciamento de projetos Methodware®, desenvolvida pela Beware Consultoria Empresarial

(www.beware.com.br), é direcionada para empresas e instituições que precisam aumentar a chance de sucesso de seus projetos,

através do estabelecimento de métodos para iniciar , planejar , executar , monitorar e controlar  e finalizar  projetos. Totalmente

alinhada com o PMBOK® 4a edição (publicação do PMI), apresenta de forma objetiva “como” o gerenciamento de projetos deve ser 

realizado.

Essa metodologia foi publicada no livro “Metodologia de Gerenciamento de Projetos – Methodware”, de Carlos Magno da

Silva, Flávio Vivacqua, Otualp Macedo e Luiz Xavier,  que recebeu em junho de 2010 o prêmio "Melhor Livro Brasileiro de

Gerenciamento de Projetos da Década". Esta premiação foi organizada pelo PMI-Rio como parte do 8º Encontro Nacional de

Profissionais de Gerenciamento de Projetos, considerado um dos eventos anuais mais importantes nessa área no Brasil. Mais de mil

profissionais de gerenciamento de projetos, de todo o Brasil, participaram da votação.

A Basic Methodware® é uma versão simplificada da Methodware®, de utilização prática, para estudantes e gerentes de projetos

de pequeno e médio porte, utilizando o projeto de um treinamento para exemplificar os procedimentos de cada processo. Ela também

BASIC METHODWARE (www.methodware.com.br)

Page 2: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 2/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto2

será útil para aqueles que estiverem iniciando na área de gerenciamento de projetos, que vão verificar que é possível gerenciar sem

burocratizar o trabalho, trazendo como benefício uma maior previsibilidade do projeto, aumentando a chance de seu sucesso.

Para utilizar a Basic Methodware® , veja abaixo cada processo do Mapa de Processos “Roadmap”:

MAPA DE PROCESSOS “ROADMAP”

I - INICIAR P - PLANEJAR “PLAN” E - EXECUTAR “DO” M - MONITORAR “CHECK” F - FINALIZAR

I - Autorizar o Iníciodo Projeto

P.1 – Identificar os Envolvidos E – Gerenciar a Execução doPlano de Projeto

M – Checar o Trabalho do Projeto F - Encerrar o Projeto

Termo de Abertura (D1) P.2 – Escopo e a Qualidade Autorização do Trabalho (D3) Relatórios de Desempenho (D5) Aceite Final (D7)

P.3 – Respostas aos Riscos Equipe de Trabalho (D4) C – CONTROLAR “ACT”

P.4 – Comunicações C – Agir para Corrigir Distorções

P.5 – Tempo e Recursos Pedidos de Mudança (D6)

P.6 – Aquisições

P.7 – Custo

P.8 – Aprovar Plano de Projeto

Plano do Projeto (D2)

BASIC METHODWARE (www.methodware.com.br)

Page 3: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 3/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto3

1º MODULO: I – Autorizar o Início do Projeto

 Verificamos no dia-a-dia que diversas idéias, são denominadas de projetos, mas sucumbem antes mesmo de nascer. O objetivo

de se formalizar o início de um projeto é definir alguns parâmetros que servirão de base para desenvolvê-lo. Além disso, se o projeto

não tiver um "responsável" corre-se o risco de duplicidade ou ausência de comando e, conseqüentemente, grandes transtornos

esperados em sua condução.

Consideramos que uma vez decidido que o projeto será feito devemos comunicar esta decisão internamente. Essa comunicação

deve ser feita pelo patrocinador do projeto. Muitas vezes usamos um documento que pode ser denominado de Termo de Abertura do

Projeto, onde é formalizado a existência do projeto designando seu gerente do projeto ou coordenador, e autorizando-o a utilizar recursos humanos, materiais e financeiros na execução do mesmo. Esta autorização pode ser este termo de abertura do projeto, uma

proposta de projeto autorizada por um cliente interno ou externo, uma ordem de serviço ou até mesmo uma mensagem de correio

eletrônico. Mais importante do que a forma ou o nome do documento é a sua funcionalidade.

Nesta metodologia, como o intuito é de simplificação, vamos considerar uma mensagem eletrônica como a autorização para o

início do projeto, a ser enviada para o gerente do projeto com cópia para outros interessados como, por exemplo, o superior imediato do

gerente, caso este não seja o emissor da mensagem. Vale à pena ter nessa mensagem, pelo menos, os seguintes tópicos:

1. Justificativa

Descrição da necessidade ou do problema existente (Por quê?

), com o histórico e, eventualmente, o público-alvo dos benefícios

do projeto (Para quem?

).

BASIC METHODWARE (www.methodware.com.br)

Page 4: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 4/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto4

2. Objetivos e Metas

Descrição da contribuição ou auxílio que o projeto visa trazer para a solução do problema, ou benefícios que o projeto visa gerar 

(Para quê?

). O ideal é quantificarmos os objetivos, o que chamamos de "metas". O sucesso de um projeto está associado ao alcance

dos seus objetivos.

3. Escopo do Projeto

Quais produtos e serviços são esperados pelo patrocinador e onde será realizada a execução do projeto. Neste momento da

autorização a descrição do escopo é resumida, pois fará parte do planejamento do projeto o detalhamento do escopo.

4. Gerente do Projeto e Nível de Autoridade

Identifica o gerente do projeto (também podemos usar "líder" ou "coordenador") e, eventualmente, estabelece seus poderes e

limitações de autoridade.

5. Limites de Prazo e Custo (Restrições)

Identifica os limites orçamentários e de prazo que o gerente do projeto deve considerar no planejamento do projeto. O emissor da mensagem não deve ser o próprio gerente do projeto, pois não seria uma boa prática ter algo como "eu me designo gerente do

projeto". O fato de ter um patrocinador (sponsor, padrinho), com um alto nível hierárquico, dá mais importância para o projeto na

BASIC METHODWARE (www.methodware.com.br)

Page 5: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 5/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto5

empresa e o gerente do projeto sabe a quem se dirigir em caso de decisões fora de sua alçada.

O gerente do projeto ao receber a mensagem deve gerar um arquivo com extensão pdf desta mensagem, e arquivá-lo em um

diretório do projeto, para gerar histórico e permitir futuras consultas.

Ao longo dos processos desta metodologia nós iremos exemplificar a aplicação das técnicas e ferramentas em um projeto de

um "Treinamento em Gerenciamento de Projetos". O texto abaixo exemplifica um e-mail de autorização do início desse projeto.

PROJETO EXEMPLO

Termo de Abertura do Projeto – E-mail (D1)

De : Diretor ExecutivoPara : José das CouvesCC: Nélio Vieira (Gerente do José das Couves)Assunto: Autorização para início do projeto.

1. Justificativa:No momento atual, em que várias organizações estão passando por mudanças estruturais em direção a uma orientação por projetos, torna-se maisevidente a necessidade de se estabelecerem metodologias de gestão que conduzam ao sucesso ou que, pelo menos, aumentem a probabilidade deatingir o sucesso em seus projetos. Para tal, torna-se necessária a capacitação de profissionais das organizações em ferramentas e técnicas para ogerenciamento desses projetos.A nossa empresa possui um portfolio de projetos de cerca de R$ 15 milhões / ano. Pesquisa realizada em 2003 pelo Meta Group com executivos de TImostra que as empresas que vêm investido em treinamento em gerenciamento de projetos têm registrado uma melhora contínua na eficiência de seus

projetos, reduzindo seus custos em até 30%.2. Objetivos e Metas:Objetivo qualitativo: Otimização dos recursos físicos e financeiros da empresa, por meio de um melhor gerenciamento dos projetos.Meta: Obter uma redução de, no mínimo, 10% nos custos dos projetos no próximo ano.

BASIC METHODWARE (www.methodware.com.br)

Page 6: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 6/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto6

3. Escopo:Este projeto tem como escopo a realização de uma turma de treinamento em gerenciamento de projetos (GP), tendo como público alvo os profissionaisque trabalham em projetos de Tecnologia da Informação e de Engenharia. Esse treinamento deve ter como base a metodologia "basic methodware" degerenciamento de projetos.

4. Gerente do Projeto e Nível de Autoridade:O Sr. José das Couves do Departamento de Administração será o gerente deste projeto. Sua escolha foi realizada em razão de sua experiência anterior em outros treinamentos e por sua participação em diversos projetos da empresa.

5. Limite de Prazo e Custo:O projeto deverá estar concluído em até 60 dias.O orçamento para o projeto é de R$18.000,00. 

Se você já tem um projeto para iniciar, prepare agora a mensagem de autorização de início do mesmo e solicite ao patrocinador 

para divulgá-la na organização, tendo como destinatários os setores envolvidos / interessados no projeto. Também podem ser utilizadas

outras formas de divulgação do início do projeto: Intranet; newsletter etc.

Agora que o projeto já foi autorizado, você já pode começar a elaborar o planejamento do mesmo. Nesta metodologia, o

planejamento será consolidado em um "Plano do Projeto". Veja o modelo de plano do Projeto no Anexo 2 desta apostila. Transcreva

para a "Introdução" do mesmo os itens da mensagem do patrocinador, com exceção do texto referente ao escopo, que será utilizado

como ponto de partida para o texto a ser colocado no subitem 3.1.1 do plano, a ser preenchido durante o processo P2 da metodologia.

BASIC METHODWARE (www.methodware.com.br)

Page 7: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 7/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto7

2º MODULO: P.1 – Identificar os Envolvidos

Um dos fatores críticos do sucesso em projetos é o comprometimento dos principais envolvidos “stakeholders” com o projeto.

Ninguém compromete ninguém, o que fazemos é criar as condições para que as pessoas se sintam comprometidas. Além de entender 

suas necessidades e expectativas, devemos gerenciá-las a fim de assegurar um projeto bem-sucedido.

O primeiro passo no planejamento consiste, portanto, em identificar quais são esses envolvidos no projeto. Com isso

poderemos trazê-los para participar do planejamento e criar uma comunicação que os mantenham alinhados e motivados durante todo

o projeto.

Envolvidos “Stakeholders” são as pessoas, grupos de pessoas e organizações que estão ativamente envolvidas no projeto ou,então, cujos interesses possam ser afetados de forma positiva ou negativa como resultado da execução ou conclusão do projeto. Eles

podem também exercer influência sobre o projeto e seus resultados. Os envolvidos “stakeholders” principais são:

Tabela dos Envolvidos “Stakeholders”

Gerente do Projeto Pessoa responsável pelo gerenciamento do projeto

Cliente Pessoa ou organização que solicitou ou contratou o produto ou serviço do projeto

Membros da equipe Pessoas que compõem a equipe do projeto

Representantes de áreas da Organização executora Pessoas de áreas da empresa em que o projeto está sendo executado

Patrocinador “sponsor” Pessoa ou grupo, dentro ou fora da organização executora, que provê recursos financeirose/ou apoio institucional para a execução do projeto

BASIC METHODWARE (www.methodware.com.br)

Page 8: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 8/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto8

Usuário Pessoa ou organização que irá utilizar o produto ou serviço do projeto

Fornecedores Organizações que irão fornecer produtos ou serviços para o projeto

Os principais envolvidos devem participar do planejamento do projeto. Um bom projeto começa pelo consenso entre todos os

envolvidos no sentido de trabalharem em prol de um objetivo comum.

Esta relação dos envolvidos, assim como qualquer documento de planejamento deve ser atualizada no decorrer da execução do

projeto, pois novos “stakeholders” serão identificados.

Organize agora uma reunião de partida do projeto (kick off meeting) . Podemos ter, a critério do gerente, várias reuniões de

partida ao longo do projeto: partida do projeto; partida da execução; partida de uma fase; partida do trabalho de uma subcontratada etc.O objetivo dessas reuniões é sempre divulgar o projeto para os principais stakeholders do projeto, da execução, da fase, do contrato

etc.

A reunião de partida pode ser feita na própria empresa ou em um hotel. Devem ser convocados os principais envolvidos no

projeto, com antecedência para que eles possam comparecer, não enviando outros para representá-los. A convocação deve partir,

preferencialmente, do patrocinador do projeto.

Após as palavras de abertura do patrocinador , enaltecendo a justificativa (importância) e objetivos do projeto, o gerente deve

discorrer sobre o escopo e o envolvimento dos stakeholders no planejamento e, caso disponível a informação, na execução do projeto.A tabela abaixo apresenta a relação dos envolvidos para o projeto exemplo de treinamento em gerenciamento de Projetos:

BASIC METHODWARE (www.methodware.com.br)

Page 9: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 9/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto9

PROJETO MODELO

RELAÇÃO DOS ENVOLVIDOS NO PROJETO (2)ID Nome Organização / Cargo Telefone / E-mail Envolvimento

1 José das Couves Beware / Gerente de Projetos 21 3027 0456 / [email protected] Gerente do Projeto

2 João das Neves Beware / Engenheiro 21 3027 0456 / [email protected] Dep. de engenharia

3 Maria da Silva Beware / Analista Sistemas 21 3027 0456 / [email protected] Dep. de T.I.

4 Glória Santos Beware / Analista RH 21 3027 0456 / [email protected] Apoio acadêmico

Esta relação dos envolvidos, assim como qualquer documento de planejamento deve ser atualizada no decorrer da execução doprojeto, pois novos “stakeholders” serão identificados.

Elabore agora a relação dos envolvidos do seu projeto, preenchendo, no Plano do Projeto, o item 2.

Organize agora uma reunião de partida do projeto “kick off meeting” . Podemos ter, a critério do gerente, várias reuniões departida ao longo do projeto: partida do projeto; partida da execução; partida de uma fase; partida do trabalho de uma subcontratada etc.O objetivo dessas reuniões é sempre divulgar o projeto para os principais “stakeholders” do projeto, da execução, da fase, do contratoetc.

Para a reunião de partida devem ser convocados os principais envolvidos no projeto, com antecedência para que elespossam comparecer, não enviando outros para representá-los. A convocação deve partir, preferencialmente, do patrocinador do projeto.

Após as palavras de abertura do patrocinador, enaltecendo a importância (justificativa) e objetivos do projeto, o gerente devediscorrer sobre o escopo e o envolvimento dos “stakeholders” no planejamento e, caso disponível a informação, na execução do projeto.

BASIC METHODWARE (www.methodware.com.br)

Page 10: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 10/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto10

3º MODULO: P.2 Planejar o Escopo e a Qualidade

Quando da autorização do projeto (processo I), já foram identificados a justificativa (Por quê?) e os objetivos e metas (Para

quê?).

Agora está na hora de planejar o trabalho necessário (O quê? e Como?) para que o projeto atinja os seus objetivos, cumprindo

as metas estabelecidas. O trabalho do projeto é o que chamamos de escopo, e consiste na geração de produtos e serviços, cujas

características e qualidade são definidas pela especificação de seus requisitos.

É fundamental que comecemos pela definição do escopo do cliente / patrocinador , ou seja, que produtos, serviços ou

resultados, relacionados aos objetivos do projeto, serão entregues ao(s) solicitante(s) do projeto. São exemplos: desenhos conceituais,estudos de viabilidade, manual do equipamento, testes, equipamentos, treinamento de pessoal, relatórios de desempenho etc.

A primeira definição do escopo do cliente / patrocinador é a constante do documento que autorizou o início do projeto, e foi visto

no processo I desta metodologia. Porém, devemos detalhar mais esse escopo. A equipe de planejamento, antes de sair detalhando o

escopo do cliente / solicitante, precisa fazer com ele uma validação do entendimento do mesmo. É necessário, portanto, levantar e

validar quais são os produtos e serviços que terão de ser produzidos para o cliente, gerando um texto descritivo desse entendimento.

Além disso, a equipe precisa escolher, dentre as possíveis alternativas de condução do projeto, aquela que deve ser utilizada para a

entrega desses produtos, o que chamamos de estratégia de condução do projeto. É o que veremos a seguir.

P2.1 - Definição do Escopo

O primeiro passo na definição do escopo é elaborar uma descrição do escopo do projeto, deixando claro, se necessário, o que

BASIC METHODWARE (www.methodware.com.br)

Page 11: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 11/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto11

não faz parte deste escopo. A idéia é limitar o trabalho que será realizado.

Esse texto deve ser validado com o cliente / solicitante antes de prosseguir no planejamento.

Para o nosso projeto o, o escopo seria, preenchendo os itens 3.1.1 e 3.1.2 do Plano do Projeto:

PROJETO EXEMPLO

Descrição do Escopo combinado com cliente (3.1.1)

Este projeto tem como escopo a realização de um treinamento em gerenciamento de projetos (GP), utilizando a metodologia Methodware®, para30 profissionais que trabalham em projetos nos Departamento de TI e Engenharia. O treinamento, com uma carga horária de 32 horas, deve conter os seguintes módulos: Importância do GP, Conceitos básicos do GP; Iniciando o projeto, Planejando o projeto, Executando o projeto, Controlando o

projeto e encerrando o projeto. Para sedimentação dos conhecimentos deve ser utilizado um exercício prático durante o treinamento em que osalunos tenham condições de, pelo menos, elaborar o planejamento de um projeto. Os alunos deverão receber como material didático uma apostila,cópia dos slides da apresentação e o exercício prático. Devem ser providenciados dois coffee breaks para cada dia de treinamento. Será aplicadauma prova para avaliação do grau de aprendizado dos alunos.

Escopo não incluído (3.1.2)

a) A divulgação e convite às pessoas para o evento, assim como controlar a presença dos participantes e a emissão de certificados, que estará acargo do Departamento de Recursos Humanos.

b) O fornecimento de almoço para os participantes.

Em seguida, valide esse texto com o cliente / solicitante do projeto:

P2.2 Estratégia de condução do projeto

Com o escopo validado com o cliente / solicitante do projeto, a equipe de planejamento do projeto deve montar a estratégia para ageração do mesmo. Uma das decisões acerca da estratégia consiste na divisão do projeto em fases.

BASIC METHODWARE (www.methodware.com.br)

Page 12: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 12/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto12

Para melhor planejar, executar e controlar um projeto, nós o dividimos em "pedaços" menores, que denominamos fases, cujos nomes equantidades são determinados pelas necessidades de controle da organização ou organizações envolvidas no projeto. O ciclo de vidado projeto consiste no conjunto de fases do projeto, geralmente em ordem seqüencial de execução.

A definição das fases do ciclo de vida de um projeto está diretamente ligada ao tipo de produto a ser gerado. Não existe uma únicamaneira de definir o ciclo de vida de um projeto.

Para o nosso projeto exemplo do Treinamento em Gerenciamento de Projetos, as fases do projeto seriam duas: Preparação eTreinamento. E a estratégia para a geração do escopo do cliente seria:

PROJETO EXEMPLO

Estratégia de condução do projeto (3.1.3)

a) O ciclo de vida do projeto será dividido em duas fases: preparação e treinamento.b) Para acompanhamento do projeto será realizada uma reunião do gerente do projeto com a equipe, cinco dias úteis antes do início dasaulas.c) O treinamento deverá ser realizado em 4 dias úteis e consecutivos, sendo ministrado por um dos profissionais da empresa que já possua acertificação PMP (Project Management Professional).d) O próprio instrutor designado deverá preparar o material didático, que será reproduzido na gráfica da empresa.e) O coffee break será contratado externamente.f) A avaliação do treinamento (conteúdo, instrutor, recursos audiovisuais e acomodações) será feita no último dia de aula, após a conclusão doúltimo módulo.g) A prova será aplicada uma semana depois do término das aulas.

Defina agora, com a sua equipe, a estratégia de condução do projeto e lance no subitem 3.1.3 do Plano do Projeto.

P2.3 - A Estrutura Analítica do Projeto (EAP)

BASIC METHODWARE (www.methodware.com.br)

Page 13: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 13/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto13

A ferramenta utilizada para a representação do escopo detalhado do projeto é a Estrutura Analítica do Projeto (EAP), traduçãopara o português de Work Breakdown Structure (WBS). Essa representação é fundamental para que possamos gerar o cronograma

do projeto, o que será visto no processo "P5 - Planejar o Tempo e os Recursos".

Na EAP deve ser representado tanto o escopo combinado com o cliente como também o escopo decorrente da estratégia

estabelecida (vide P2.1 e P2.2 acima). Por exemplo, fará parte da EAP (embora o cliente não tenha solicitado), a elaboração do plano

do projeto, a realização de reuniões de acompanhamento, a preparação para que a execução do projeto ocorra e a emissão de um

relatório de encerramento do projeto.A EAP é uma estrutura hierárquica, podendo ser representada como uma lista ou na forma gráfica. Para o nosso projeto modelo

vamos optar pela representação de uma lista. Veja abaixo como seria a EAP (no nível macro) de um projeto nas duas formas de

representação.

1. Projeto de implantação de um novo projeto

1.1. Mapeamento do processo atual

1.2. Proposta do novo processo

1.3. Infraestrutura

1.4. Piloto

1.5. Implantação

1.6. Acompanhamento inicial da operação

BASIC METHODWARE (www.methodware.com.br)

Page 14: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 14/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto14

Você deve ter percebido que no formato em lista o nome do projeto ficou com a numeração 1 e os itens subordinados receberam

numerações de 1.1 a 1.6.

Para usar a forma gráfica, que é de melhor visualização, o gerente do projeto necessita utilizar uma ferramenta que auxilie o

desenho. Para a maioria dos gerentes que utilizam o software MS-Project, que não tem esse recurso, é útil usar uma ferramenta de

apoio (add-interface), como, por exemplo, o "WBS Chart Pro®" da Critical Tools Corporation (www.criticaltools.com) ou o Microsoft

Visio®. Porém, a lista disponível no MS-Project, Project Builder, ou em qualquer outro software de gerenciamento de projetos, editor de

textos ou planilha eletrônica, também pode ser utilizada para representar a EAP.

P2.3.1 - Passos para a Elaboração de uma EAP

Veremos a seguir uma abordagem [Xavier, 2009] para a elaboração da EAP, utilizando a técnica de decomposição (de cima para

baixo) e utilizando o nosso projeto exemplo.

P2.3.1.1- Colocar no primeiro nível (nível 0) da EAP o nome do projeto.

• 1 Projeto "Treinamento Gerenciamento de Projetos"

P2.3.1.2 - Colocar no segundo nível (nível 1, também chamado de primeiro nível de decomposição) as fases que estabelecem o ciclo

de vida do projeto.

BASIC METHODWARE (www.methodware.com.br)

Page 15: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 15/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto15

• 1 Projeto "Treinamento Gerenciamento de Projetos"

• 1.1 Gerenciamento do Projeto

• 1.2 Preparação

• 1.3 Treinamento

• 1.4 Fechamento do Projeto

P2.3.1.3 - Acrescentar no terceiro nível, (nível 2) à esquerda das fases, um elemento para conter os subprodutos necessários ao

gerenciamento do projeto (GP), e à direita para o encerramento.

• 1 Projeto "Treinamento Gerenciamento de Projetos"

• 1.1 Gerenciamento do Projeto

• 1.1.1 Reunião de Partida do Projeto (Kick off)

• 1.1.2 Plano do Projeto

• 1.1.3 Reuniões de Acompanhamento

• 1.2 Preparação

1.2.1 Verificação e Reserva da Sala• 1.2.2 Material Didático

• 1.2.2.1 Apostila

BASIC METHODWARE (www.methodware.com.br)

Page 16: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 16/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto16

• 1.2.2.2 Slides

• 1.2.2.3 Exercício prático

• 1.2.2.4 Prova

• 1.2.2.5 Reprodução e montagem material

• 1.2.3 Contratação coffee break

• 1.2.4 Questionário de avaliação

• 1.3 Treinamento

• 1.3.1 Aulas

• 1.3.2 Coffee break

• 1.3.3 Avaliação do treinamento pelos alunos

• 1.4 Fechamento do Projeto

• 1.4.1 Avaliação dos alunos (prova)

• 1.4.2 Relatório do projeto

Em relação ao gerenciamento, devemos identificar os subprodutos que serão necessários ao planejamento, monitoramento econtrole, execução e encerramento do projeto.

Para cada subproduto, verificar se as estimativas de custo e tempo, assim como a identificação de riscos e a atribuição de

BASIC METHODWARE (www.methodware.com.br)

Page 17: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 17/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto17

responsabilidade para a execução do mesmo podem ser desenvolvidas neste nível de detalhe. Se a resposta for negativa, deve ser 

decomposto o elemento da EAP, subdividindo-o em componentes menores, mais manejáveis, até que os subprodutos estejam definidos

em detalhe suficiente para suportar o desenvolvimento dos processos de gerenciamento do projeto.

A profundidade (número de níveis) da EAP depende do tamanho e complexidade do projeto, e da necessidade de detalhe

necessário para o seu gerenciamento. Atenção que não é necessário que a EAP seja simétrica, ou seja, que todos os subprodutos

sejam decompostos até o mesmo nível.

Essa EAP só estará finalizada após chegarmos ao processo P8 da metodologia, pois em função dos próximos passos de

planejamento podemos necessitar acrescentar na EAP alguns produtos e serviços.

Elabore agora, com a sua equipe, a EAP do seu projeto e lance no subitem 3.1.4 do Plano do Projeto. Lembre-se, porém, que elapossivelmente sofrerá alterações ao longo dos próximos processos.

PROJETO MODELO

Estrutura Analítica do Projeto - EAP (3.1.5)

Cod. EAP Descrição

1 Projeto "Treinamento Gerenciamento de Projetos"

1.1 Gerenciamento do Projeto

1.1.1 Reunião de Partida do Projeto (Kick off)

1.1.2 Plano do Projeto

1.1.3 Reuniões de Acompanhamento

BASIC METHODWARE (www.methodware.com.br)

Page 18: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 18/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto18

1.2 Preparação

1.2.1 Verificação e Reserva da Sala1.2.2 Material Didático

1.2.2.1 Apostila

1.2.2.2 Slides

1.2.2.3 Exercício prático

1.2.2.4 Prova

1.2.2.5 Reprodução e montagem material

1.2.3 Contratação coffee break

1.2.4 Questionário de avaliação1.3 Treinamento

1.3.1 Aulas

1.3.2 Coffee break

1.3.3 Avaliação do treinamento pelos alunos

1.4 Fechamento do Projeto

1.4.1 Avaliação dos alunos (prova)

1.4.2 Relatório do projeto

P2.3.2 - Descrição das Entregas (Produtos e Serviços)

Para ficar claro o que será entregue pelo projeto, devem ser especificados os produtos e serviços nos níveis mais baixos da

EAP (aqueles que não foram decompostos), também chamados de pacote de trabalho.

BASIC METHODWARE (www.methodware.com.br)

Page 19: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 19/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto19

Defina agora, com a sua equipe, a descrição das entregas do projeto e lance no subitem 3.1.5 do Plano do Projeto:

PROJETO MODELO

Descrição das Entregas (3.1.5)

Cód. EAP Nome Produto / Serviço Descrição

1 Projeto "Treinamento Gerenciamento de Projetos"

1.1 Gerenciamento do Projeto

1.1.1 Reunião de Partida do Projeto (Kick off) A reunião de partida deve ser feita na própria empresa e ser aberta pelopatrocinador. Devem ser convidados os principais envolvidos no projeto,com antecedência mínima de dois dias. Após a palavra do patrocinador,enaltecendo a importância do projeto, o gerente deve discorrer sobre a suaestratégia para a elaboração do plano.

1.1.2 Plano do Projeto Documento em Word contendo o planejamento do projeto. Deve seguir omodelo da metodologia "Lean Methodware" e ter a logomarca da empresa.

1.1.3 Reunião de Acompanhamento Reunião com a equipe, cinco dias úteis antes do início das aulas,coordenadas pelo gerente do projeto, que reportará em seguida oandamento para o patrocinador do projeto, por e-mail.

1.2 Preparação

1.2.1 Verificação e Reserva da Sala Solicitação de reserva da sala de aula para o dia agendado para otreinamento, devendo constar a relação de equipamentos audiovisuaisnecessários. Antes da reserva deve ser verificado se a sala apresenta

BASIC METHODWARE (www.methodware.com.br)

Page 20: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 20/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto20

condições para que o treinamento seja realizado com qualidade.

1.2.2 Material Didático

1.2.2.1 Apostila Com os conceitos a serem apresentados em 1.3.1, deve ser entregue emarquivo eletrônico Word, fonte Times New Roman 12 e ter em média 60páginas, com logomarca da empresa.

1.2.2.2 Slides Ter conteúdo resumido da apostila (1.2.2.1), dimensionado para a cargahorária das aulas (1.3.1);Ter o título "Treinamento em Gerenciamento de Projetos" e a logomarca daorganização promotora no rodapé de cada slide;

Deve ser entregue em arquivo eletrônico Power Point, fonte Arial 18 e ter 

em média 100 slides.

1.2.2.3 Exercício prático Simulação ou estudo de caso que conduza a turma da teoria à prática. Osalunos devem exercitar, no mínimo: TAP, EAP, cronograma, orçamento,mapa de comunicação e Registro de riscos. Para a execução do exercício,não deve ser necessário o uso de computador;Deve ser entregue em arquivo eletrônico Word, fonte Times New Roman 12.

1.2.2.4 Prova Deve envolver o conteúdo mais relevante da apostila e slides (1.2.2.1 e1.2.2.2), com duração máxima prevista de 2 h, ser discursiva e ter nomáximo 5 questões, totalizando 10 pontos;Ter a logomarca da organização promotora na parte superior do papel; Deveser entregue em arquivo eletrônico Word, fonte Times New Roman 12.

1.2.2.5 Reprodução e montagem material Reprodução do material gerado em 1.2.2.1, 1.2.2.2, 1.2.2.3 e 1.2.2.4;Deve ser impresso em preto e branco e colorido, só frente, usando folha A 490g/m2 e, no caso da apostila, encadernada em espiral preto com capa

BASIC METHODWARE (www.methodware.com.br)

Page 21: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 21/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto21

transparente;

A impressão da tiragem completa só será autorizada após a aprovação donúmero zero (teste);

Nº de cópias igual ao número de alunos previstos, mais o instrutor, comuma margem de 10% de reserva.

1.2.3 Contratação coffee break Seleção e contratação de empresa para o serviço de coffee break de 1.3.2;

A empresa deve deixar o local limpo ao término de cada coffee break,responsabilizando-se por qualquer dano causado na área utilizada para oserviço;

A fornecedora deverá apresentar, no mínimo, 5 referências de ter executadoserviço semelhante com qualidade.

1.2.4 Questionário de avaliação Questionário para medição do nível de adequação do treinamento àsexpectativas dos participantes, a ser aplicado em 1.3.3;Deve ter a logomarca da organização promotora na parte superior do papele ser entregue em arquivo eletrônico Word, fonte Times New Roman 12.

1.3 Treinamento

1.3.1 Aulas Deve abordar os seguintes itens: Importância do GP, Conceitos básicos doGP; Iniciando o projeto, Planejando o projeto, Executando o projeto,Monitorando e Controlando o projeto e Encerrando o projeto.

Público alvo: gerentes de projetos dos Departamentos de TI e Engenharia;O treinamento será aberto pelo diretor executivo e fechado pelo presidenteda empresa;

As aulas devem ser distribuídas em 4 dias consecutivos, com duração de 8h

BASIC METHODWARE (www.methodware.com.br)

Page 22: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 22/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto22

em cada;

O material didático deve ser entregue no início da 1ª aula;Utilizar os slides (1.2.2.2) e o exercício prático (1.2.2.3), mantendo a diretrizde unir a teoria à prática.

1.3.2 Coffee break Servido para 31 pessoas (30 participantes e o instrutor), por empresacontratada, constando de 2 coffee breaks de 15 minutos em cada dia deaula (1.3.1), servindo bebidas quentes e frias não alcoólicas, além depetiscos doces e salgados.

1.3.3 Avaliação do treinamento pelos alunos Aplicação de questionário paramedição do nível de adequação do treinamento às expectativas dosparticipantes (conteúdo, instrutor, recursos audiovisuais e acomodações).

1.4 Fechamento do Projeto

1.4.1 Avaliação dos alunos (prova) Aplicar a prova elaborada em 1.2.2.4.:Deve ser feita individualmente;

Deve ser corrigida pelo instrutor e entregue ao gerente do projeto até 7 diasapós ter sido aplicada.

1.4.2 Relatório do projeto Deve ter como objetivo a documentação do histórico do projeto, sob umaperspectiva crítica, procurando documentar também as lições aprendidas(pontos fortes e fracos);

Deve ser feito e assinado pelo gerente do projeto e entregue impresso aopatrocinador 

Maiores detalhes acerca da elaboração da EAP e da descrição de produtos e serviços podem ser vistos no livro "Gerenciamento

BASIC METHODWARE (www.methodware.com.br)

Page 23: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 23/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto23

de Projetos - Como definir e controlar o escopo do projeto" [Xavier, 2009].

Defina agora, com a sua equipe, a descrição das entregas do projeto e lance no subitem 3.1.5 do Plano do Projeto.

P.2.4 - Planejar a Qualidade

O conceito de Qualidade, no gerenciamento de projetos, é definido como o grau em que as características de um produto ou

serviço atendem aos desejos e necessidades dos dos envolvidos “stakeholders”. Existem dois aspectos de qualidade a serem

considerados no projeto. O primeiro é a qualidade dos produtos ou resultados e o segundo a qualidade do gerenciamento do projeto.

O primeiro está relacionado com as características e especificações às quais o produto deve atender, enquanto o segundo estárelacionado aos aspectos da qualidade de gerenciamento do projeto.

Devemos incluir em nosso projeto as necessidades para garantir e controlar a qualidade das entregas definidas conforme o

subitem 2.3.2 (Descrição das entregas). Quando estamos planejando uma auditoria estamos realizando uma ação para a garantia da

qualidade. Quando estamos realizando um teste estamos realizando uma ação para o controle da qualidade.

Como resultados deste processo são acrescentados à EAP produtos ou serviços para Garantia e Controle de Qualidade. Por 

exemplo, na EAP do nosso exemplo do Treinamento, foi colocada a avaliação do treinamento pelos alunos e a prova como instrumentos

de controle da qualidade.

Planeje agora, com a sua equipe, a garantia e o controle da qualidade do Projeto, refletindo na EAP os produtos e serviços

necessários para tal.

BASIC METHODWARE (www.methodware.com.br)

Page 24: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 24/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto24

4º MODULO: P3 - Planejar as Respostas aos Riscos

Normalmente quando se pensa em riscos o que nos vem à cabeça são eventos de ameaça ao projeto, mas quando vemos a

definição de riscos segundo o PMBOK [PMI, 2008] vemos que risco é "um evento ou condição incerta que, se ocorrer, provocará um

efeito positivo ou negativo nos objetivos de um projeto". Portanto, devemos identificar ameaças ou oportunidades para o projeto.

Todo projeto está exposto a riscos. O nível desta exposição é influenciado pela sua natureza, tamanho, complexidade e pelo

ambiente no qual está inserido. Todos os aspectos que constituem um projeto, ou seja, tecnologia, recursos humanos e materiais,

aspectos legais, políticos, ambientais e financeiros, podem ser fontes de riscos.

Os riscos do projeto devem ser efetivamente gerenciados, de modo a garantir que os objetivos do projeto sejam atendidos,

através da minimização dos impactos negativos (ameaças) e da maximização dos positivos (oportunidades).

A equipe de gerenciamento do projeto deve dimensionar adequadamente o gerenciamento dos riscos de modo a balancear 

seu custo com os benefícios proporcionados para o projeto. No decorrer do projeto, todos os membros da equipe devem ser 

responsáveis por identificar novos riscos, em função do progresso do projeto ou de mudanças em seu ambiente.

P3.1 - Identificar os Riscos

O objetivo principal agora é identificar os riscos que podem afetar o projeto. O Gerente deve conduzir o trabalho de

identificação dos riscos, disponibilizando para os envolvidos nesta tarefa a documentação do planejamento do projeto atual e

informações sobre projetos anteriores. As informações e a análise dos resultados obtidos contra os planejados, relativos ao escopo,

tempo, qualidade, custos, contratação, comunicações, recursos humanos, integração, bem como a avaliação sobre os riscos previstos,

BASIC METHODWARE (www.methodware.com.br)

Page 25: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 25/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto25

eventos ocorridos e as soluções adotadas podem ser de grande valia para a identificação de riscos, no planejamento de um projeto.

Caso não existam informações históricas internamente à organização, pode se recorrer a outras fontes de informação (periódicos,estudos acadêmicos, empresas de consultoria) para auxiliar nesta atividade.

O gerente do projeto deve planejar uma reunião de trabalho para realizar a identificação de riscos. Para que consigamos o

comprometimento dos stakeholders, é fundamental que verifiquemos quais deles devem participar desta reunião. A técnica mais

utilizada é o brainstorming (tempestade de idéias), que consiste na geração de idéias sem restrições. Qualquer pensamento

relacionado aos riscos do projeto deve ser coletado.

O principal resultado desta atividade é o preenchimento da coluna "Riscos" do Registro de Riscos constante do subitem 3.4 do

Plano do Projeto. Durante a identificação de riscos pode ser diagnosticado que alguns itens do planejamento precisam ser revistos.Por exemplo, a EAP pode precisar ser mais detalhada para permitir uma correta avaliação de riscos.

Para o nosso projeto exemplo da Festa de Aniversário Infantil, alguns riscos podem ser elencados: Salões de festa não

disponível; Salão de festa não possuir os recursos necessários para o treinamento; Problema de saúde da criança ou parentes

próximos.

P3.2 - Analisar os Riscos

Após a identificação, os riscos devem ser analisados de modo a determinar a sua exposição ao risco, que depende de dois

aspectos: a sua probabilidade de ocorrência e o impacto que ele pode causar ao projeto. A abordagem simplificada desta

BASIC METHODWARE (www.methodware.com.br)

Page 26: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 26/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto26

metodologia considera a análise qualitativa dos riscos para a determinação do grau de exposição ao risco, sendo sugerida a

utilização da tabela abaixo:

Tabela de Exposição ao Risco

Probabilidade Impacto Exposição ao Risco

Baixa Baixa Baixa

Baixa Média Baixa

Baixa Alto Média

Média Baixo Baixa

Média Média Média

Média Alto Alta

Alta Baixo Média

Alta Médio Alta

Alta Alto Alta

P3.3 - Definir as Respostas aos Riscos

BASIC METHODWARE (www.methodware.com.br)

Page 27: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 27/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto27

Tabela das Estratégias para riscos negativos ou ameaças

Prevenir Técnica que consiste em alterar o plano do projeto para eliminar a ameaça ou proteger os objetivos do projeto de seus impactos oupara flexibilizar o objetivo que está sendo ameaçado, como extensão do cronograma ou redução do escopo. Nem sempre épossível, mas alguns riscos podem ser prevenidos. Adotar uma abordagem tradicional ao invés de uma inovadora é um exemplo.Outro seria a redução do escopo do projeto.

Transferir  Técnica que consiste em transferir para terceiros as conseqüências de um impacto negativo, porém não os elimina. Um exemploseria a adoção de um contrato por preço global, onde o fornecedor arca com os custos de eventos inesperados.

Mitigar 

Técnica que busca reduzir o impacto e/ou a probabilidade dos eventos de risco. Um sistema de servidores redundantes é umexemplo de mitigação. O servidor de backup pode não ter a mesma capacidade do oficial, porém em caso de falha deste, émantida a disponibilidade de um dado serviço, mesmo com a ocorrência de slow-time. O esclarecimento dos requisitos, obtençãode informações, melhoria da comunicação ou aquisição de especialização podem mitigar alguns riscos que surgem no início doprojeto.

Aceitar  Esta técnica indica que o time de projeto resolveu não alterar o plano do projeto para lidar com um risco ou foi incapaz deidentificar outra estratégia aplicável. A Aceitação Ativa indica que o time desenvolveu um plano de contingência, enquanto que aAceitação Passiva indica que o mesmo decidiu tratar dos riscos se estes ocorrerem. A resposta de aceitação de riscos maiscomum é a determinação de uma margem ou reserva de contingência, seja em termos financeiros ou de tempo.

Tabela das Estratégias para riscos positivos ou oportunidades

Explorar 

Técnica que visa garantir que a oportunidade seja concretizada. Tenta eliminar a incerteza associada a um risco positivo específicofazendo com que a oportunidade definitivamente aconteça. A exploração de forma direta das respostas considera a designação de

recursos mais qualificados para o projeto a fim de minimizar o tempo de conclusão e obter uma qualidade maior do que aoriginalmente planejada.

Compartilhar Técnica utilizada quando se percebe que um terceiro é capaz de aproveitar melhor as vantagens do risco, em prol do projeto. Fazer alianças através de parcerias, ou até mesmo joint-ventures, permite compartilhar os riscos visando gerenciar oportunidades.

BASIC METHODWARE (www.methodware.com.br)

Page 28: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 28/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto28

Melhorar 

Técnica que visa modificar o "tamanho" de uma oportunidade aumentando a probabilidade e/ou os impactos positivos de um risco,

identificando e maximizando os principais acionadores desses riscos de impacto positivo. A probabilidade de êxito pode ser aumentada quando atuamos proativamente para o risco positivo acontecer.

Aceitar Esta técnica indica que o time de projeto resolveu não alterar o plano do projeto para lidar com um risco ou foi incapaz de identificar outra estratégia aplicável.

Tabela das Estratégia para respostas contingenciadas

Preparar acontingência

Resposta planejada para fazer frente à ocorrência de um evento específico. Neste caso, por exemplo, a equipe receberá um alertase marcos intermediários não foram cumpridos. Se um fornecedor atrasou uma entrega, a equipe deverá preparar a contingênciapara os impactos deste atraso.

Calcular Reservade Contingência

A reserva de contingência pode abranger os fundos, o orçamento ou o tempo necessário, além da estimativa, para reduzir o riscode ultrapassar os objetivos do projeto a um nível aceitável para a organização.

Desta forma, para o nosso projeto exemplo do Treinamento em Gerenciamento de Projetos, o Registro de Riscos seria:

PROJETO MODELO

Registro de Riscos (3.4)

ID Riscos (ameaça / oportunidade) Exposiçãoao Risco

Respostas aos Riscos Responsável

1 Sala de aula não disponível Médio Fazer reserva da sala com antecedência Apoio Acadêmico

2Sala de aula não possuir os recursosnecessários para o treinamento

BaixoVisitar a sala para verificar se a ela possui osrecursos necessários

Apoio Acadêmico

BASIC METHODWARE (www.methodware.com.br)

Page 29: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 29/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto29

3 Problema de saúde do Instrutor Baixo Alterar data do treinamento Gerente do Projeto

4 Aulas não atenderem à qualidade desejada Médio Selecionar instrutor com experiência didática;Validar material didático com antecedência

Gerente do Projeto

Elabore agora o Registro de Riscos do seu projeto, preenchendo, no Plano do Projeto, o subitem 3.4.

O planejamento das respostas aos riscos deve ser refletido nas demais áreas de gerenciamento, de forma a ser mantida a

integração do projeto. Por exemplo: A EAP terá um pacote de trabalho "Verificação e Reserva da Sala".

BASIC METHODWARE (www.methodware.com.br)

Page 30: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 30/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto30

5º MODULO: P4 Planejar as Comunicações

O objetivo deste processo é planejar as comunicações com as partes envolvidas (stakeholders) no projeto.

A gestão da comunicação é também uma gestão de expectativas. Como normalmente essas expectativas diferem de pessoa

para pessoa, é importante utilizar as técnicas disponíveis de maneira apropriada para evitar as falhas e barreiras de comunicação, bem

como as suas indesejáveis conseqüências.

As informações devem ser precisas em conteúdo, concisas, sem deixar de abordar os aspectos relevantes, sendo

suficientemente claras para não causar dúvidas quanto ao seu objetivo. Deve ser estabelecido o método ou a tecnologia de

comunicação adequada para cada parte envolvida. Pode ser que um cliente, diretor ou outra importante parte envolvida, tenha

preferência ou facilidade por um determinado meio ou canal para receber as informações.

Deve-se ter cuidado para não saturar o gerente, ou outra pessoa de nível gerencial, com informações desnecessárias ou sem

valor agregado. Uma vez definidas quais serão as informações a serem distribuídas, deve ser estabelecido quem será o responsável

pela sua produção, e qual a periodicidade da mesma.

Os relatórios são ferramentas de monitoramento e as reuniões são para controle, ou seja, tomada de decisão. Tome cuidado

para não programar reuniões desnecessárias ou que possam ser substituídas por outro meio de comunicação eficaz. Planeje a agenda

da reunião e divulgue-a com antecedência para que os participantes possam se preparar para a mesma. Utilize técnicas de condução

de reuniões para torná-las produtivas e faça a ata da reunião. Veja abaixo um modelo de ata de reunião:

O Mapa das Comunicações determina como as atividades relacionadas à comunicação serão implementadas ao longo do

projeto ou de uma fase deste, definindo quem precisa das informações, quando as informações são necessárias, como elas serão

BASIC METHODWARE (www.methodware.com.br)

Page 31: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 31/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto31

fornecidas às partes envolvidas e por quem.

A tabela abaixo apresenta o Mapa das Comunicações para o projeto exemplo de treinamento em gerenciamento de Projetos.

Elabore agora o Mapa de Comunicações do seu projeto, preenchendo, no Plano do Projeto, o subitem 3.5.

PROJETO MODELO

Mapa das Comunicações (3.5)

Evento Periodicidade Documento Meio Responsável Envolvidos

Reunião de Abertura doProjeto

Uma vez Ata Reunião Gerente do Projeto Todos da relação

Reunião deAcompanhamento

Uma vez, cinco dias úteis antes do inícioda Festa de Aniversário

Ata Reunião Gerente do Projeto Equipe

Relatório deEncerramento do

ProjetoUma vez Relatório E-mail Gerente do Projeto Diretor Executivo

O planejamento das comunicações deve ser refletido nas demais áreas de gerenciamento, de forma a ser mantida a integraçãodo projeto. Por exemplo, as reuniões e relatórios previstos devem ser inseridos na Estrutura Analítica do Projeto - EAP.

Atualize agora a EAP do seu projeto com os eventos previstos no Mapa das Comunicações.

BASIC METHODWARE (www.methodware.com.br)

Page 32: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 32/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto32

6º MODULO: P.5 - Planejar o Tempo e os Recursos

A Estrutura Analítica do Projeto (EAP) é a base para a elaboração do cronograma do projeto. Queremos colocar no tempo,

"quando" e "por quem" os produtos e serviços (entregas) serão desenvolvidos e entregues ao longo do projeto.

Vimos no processo P2 que a EAP é uma estrutura hierárquica, podendo ser representada como uma lista ou na forma gráfica.

Para o cronograma precisamos da forma em lista. Assim sendo, vamos transformar a EAP gráfica gerada em P2.3 em um lista.

Começamos numerando o nome do projeto (1º nível) como 1. No 2º nível numeramos como 1.1, 1.2, 1.3 e assim por diante. No caso

do nosso projeto modelo por exemplo teríamos (3º nível com a numeração 1.1.1, 1.1.2 e o 4º nível com 1.1.1.1, 1.1.1.2).

PROJETO MODELO

Estrutura Analítica do Projeto - EAP (3.1.5)

Código da EAP Descrição

1 Projeto "Treinamento Gerenciamento de Projetos"

1.1 Gerenciamento do Projeto

1.1.1 Reunião de Partida do Projeto (Kick off)

1.1.2 Plano do Projeto

1.1.3 Reuniões de Acompanhamento

1.2 Preparação

1.2.1 Verificação e Reserva da Sala

1.2.2 Material Didático

BASIC METHODWARE (www.methodware.com.br)

Page 33: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 33/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto33

1.2.2.1 Apostila

1.2.2.2 Slides1.2.2.3 Exercício prático

1.2.2.4 Prova

1.2.2.5 Reprodução e montagem material

1.2.3 Contratação coffee break

1.2.4 Questionário de avaliação

1.3 Treinamento

1.3.1 Aulas

1.3.2 Coffee break

1.3.3 Avaliação do treinamento pelos alunos

1.4 Fechamento do Projeto

1.4.1 Avaliação dos alunos (prova)

1.4.2 Relatório do projeto

P5.1 - Identificar Atividades e marcos

Nós decompomos uma entrega em atividades quando queremos planejar e/ou controlar melhor o tempo para a sua execução. A

decomposição em atividades não é obrigatória, ficando a critério da equipe realizá-la ou não. Desta forma, vamos até o nível mais baixo

que fizemos a decompomos na EAP e tomamos a decisão, em cada entrega, se necessitamos ou não decompor em atividades. Por 

exemplo, para um pacote de trabalho "Manual do Equipamento", em que já exista uma versão anterior pronta e que serão necessárias

BASIC METHODWARE (www.methodware.com.br)

Page 34: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 34/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto34

apenas cerca de 2 horas para elaboração do mesmo, não há a necessidade de decomposição em atividades.

Na EAP do nosso projeto exemplo, poderíamos decompor a entrega "1.4.1 Avaliação dos alunos (prova)" nas atividades:1.4.1.1 Aplicar a prova

1.4.1.2 Corrigir a prova

Enquanto as entregas são escritas como substantivos (ex.: Avaliação), as atividades devem ser escritas como verbo no infinitivo

(ex.: Aplicar).

Marcos “Milestones”

Marcos são pontos de controle que acrescentamos em um cronograma, normalmente uma conclusão de fase ou de uma

entrega importante do projeto. Os marcos devem ser escritos como substantivo + particípio passado do verbo. Alguns exemplos são:

"Fase de Preparação concluída"; "Material didático entregue"; e "Projeto Concluído". Os marcos não têm esforço associado e, portanto,

não têm duração, custo ou alocação de recursos.

Identifique agora a necessidade de acrescentar atividades e marcos à EAP do seu projeto.

P5.2 - Identificar as Dependências entre Atividades e marcos

Cabe agora a identificação dos relacionamentos lógicos entre as atividades, para que assim estabeleçamos a seqüência das

atividades.

BASIC METHODWARE (www.methodware.com.br)

Page 35: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 35/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto35

As atividades devem ser seqüênciadas corretamente para suportar o desenvolvimento de um cronograma realista e alcançável. O

seqüenciamento pode ser feito com o auxílio de um computador (utilizando software de gerência de projeto, por exemplo) oumanualmente.

Para o estabelecimento da seqüência de atividades é necessário o conhecimento de alguns conceitos:

Tipos de Atividade:

• Atividade Predecessora - É a atividade que começa ou termina antes de outra atividade.

• Atividade Sucessora - É a atividade que só pode começar depois do início ou término de outra atividade.

Tipos de relacionamento entre as atividades:

• TI - A atividade sucessora só se inicia após o término da atividade predecessora. O telhado só se inicia após o término das

paredes.

• II - A atividade sucessora só se inicia após o início da atividade predecessora. Os serviços de terraplanagem devem começar 

 junto com os de topografia.

• TT - A atividade sucessora só termina com o término da atividade predecessora. A homologação do produto depende da

assinatura do cliente no relatório.• IT - A atividade depende do termino para o início da atividade anterior. É inverso ao tipo TI. O computador antigo só pode ser 

desligado após o início do funcionamento do novo.

BASIC METHODWARE (www.methodware.com.br)

Page 36: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 36/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto36

Recomendações:• Usar término-início sempre que possível;

• Demais ligações são exceções;

• Faça as dependências somente no nível mais baixo de decomposição.

Veja abaixo as dependências no caso do nosso projeto exemplo:

Tabela de Dependências entre Atividades

ID Cod. EAP EAP com Atividades (Nome da Tarefa) Predecessora

1 1 Projeto: Treinamento Gerenciamento de Projetos

2 1.1 Gerenciamento do Projeto

3 1.1.1 Reunião de Partida do Projeto “Kick off”

4 1.1.2 Plano do Projeto 3

5 1.1.3 Reuniões de Acompanhamento 3

6 1.2 Preparação

7 1.2.1 Verificação e Reserva da Sala 4

BASIC METHODWARE (www.methodware.com.br)

Page 37: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 37/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto37

8 1.2.2 Material Didático

9 1.2.2.1 Apostila 410 1.2.2.2 Slides 9

11 1.2.2.3 Exercício prático 10

12 1.2.2.4 Prova 11

13 1.2.2.5 Reprodução e montagem material 12

14 1.2.3 Contratação “coffee break” 7

15 1.2.4 Questionário de avaliação 4

16 1.2.5 Fase de Preparação Concluída (marco) 7;13;14;15

17 1.3 Treinamento 1218 1.3.1 Aulas 16

19 1.3.2 “Coffee break” (1) 18 (I-I)

20 1.3.3 Avaliação do treinamento pelos alunos (2) 18 (T-T)

21 1.3.4 Treinamento concluído 19;20

22 1.4 Fechamento do Projeto 18 (I-I)

23 1.4.1 Avaliação dos alunos (prova) 18 (I-I)

24 1.4.1.1 Aplicar a prova 20

25 1.4.1.2 Corrigir a prova 2426 1.4.2 Relatório do projeto 25

27 1.4.3 Projeto concluído (marco) 5;26

BASIC METHODWARE (www.methodware.com.br)

Page 38: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 38/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto38

(1) O “coffee break” tem uma dependência de início-início com as aulas, pois vai ocorrer em paralelo. Não é relevante representar que

vai ser servido no meio da aula.(2) A avaliação será ao final das aulas.

Estabeleça agora as dependências no seu projeto.

P5.3 - Levantamentos dos recursos necessários e Estimativa da duração das atividades

Este processo tem como objetivo levantar os recursos (pessoas, equipamentos ou materiais) e a quantidade dos mesmos quedevem ser empregados para a realização das atividades do projeto, assim como estimar o tempo necessário para a execução de cada

atividade. São feitos em paralelo porque há uma dependência entre a duração de uma atividade e a quantidade de recursos a ser 

utilizada.

Devemos, primeiramente, levantar os recursos necessários para a execução das atividades, para então estimar a duração de

cada atividade. Uma pessoa ou grupo da equipe do projeto que estiver mais familiarizada com a natureza de uma atividade específica

deve fazer ou, no mínimo, aprovar a estimativa.

Na tabela abaixo apresentamos estimativas de duração do nosso projeto exemplo, associadas aos recursos necessários paracada entrega / atividade de nosso projeto exemplo, no nível mais baixo de decomposição. Para que haja aula é necessário ter 

disponível, além do instrutor, a sala de aula, que também deve estar alocada. Para simplificar, consideramos como unidade mínima de

BASIC METHODWARE (www.methodware.com.br)

Page 39: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 39/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto39

duração um dia. Porém, na prática, podemos utilizar frações do dia, horas, minutos etc.

Tabela de Recursos necessários e Estimativa da duração das atividades

ID Cod. EAP EAP com Atividades (Nome da Tarefa) Predecessora Recursos Duração

1 1 Projeto: Treinamento Gerenciamento de Projetos

2 1.1 Gerenciamento do Projeto

3 1.1.1 Reunião de Partida do Projeto “Kick off” GP (Gerente do projeto) 1 dia

4 1.1.2 Plano do Projeto 3 GP 2 dias

5 1.1.3 Reuniões de Acompanhamento 3 GP;Instrutor; Apoio Acadêmico 1 vez cada 3 dias

6 1.2 Preparação7 1.2.1 Verificação e Reserva da Sala 4 Apoio Acadêmico 1 dia

8 1.2.2 Material Didático

9 1.2.2.1 Apostila 4 Instrutor 2 dias

10 1.2.2.2 Slides 9 Instrutor 1 dia

11 1.2.2.3 Exercício prático 10 Instrutor 1 dia

12 1.2.2.4 Prova 11 Instrutor 1 dia

13 1.2.2.5 Reprodução e montagem material 12 Apoio Acadêmico 1 dia

14 1.2.3 Contratação “coffee break” 7 GP 1 dia

15 1.2.4 Questionário de avaliação 4 Apoio Acadêmico 1 dia

16 1.2.5 Fase de Preparação Concluída (marco) 7;13;14;15

17 1.3 Treinamento 12

BASIC METHODWARE (www.methodware.com.br)

Page 40: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 40/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto40

18 1.3.1 Aulas 16 Instrutor; Sala de aula 4 dias

19 1.3.2 “Coffee break” 18 (I-I) Buffet 4 dias20 1.3.3 Avaliação do treinamento pelos alunos 18 (T-T) Apoio Acadêmico 1 dia

21 1.3.4 Treinamento concluído 19;20

22 1.4 Fechamento do Projeto 18 (I-I)

23 1.4.1 Avaliação dos alunos (prova) 18 (I-I)

24 1.4.1.1 Aplicar a prova 20 Apoio Acadêmico 1 dia

25 1.4.1.2 Corrigir a prova 24 Instrutor 1 dia

26 1.4.2 Relatório do projeto 25 GP 1 dia

27 1.4.3 Projeto concluído (marco) 5;26

P5.4 - Gerar o Cronograma

O documento que representa o planejamento de tempo em um projeto é o cronograma. Ele apresenta a data planejada para início e a

data esperada para a conclusão de cada entrega / atividade. O cronograma aprovado, chamado de cronograma base ou referência,

é um dos componentes do plano do projeto e é usado para avaliação e acompanhamento do desempenho do projeto.

• Cronograma do Projeto: é um documento na forma gráfica ou tabular com as datas planejadas para o início e a conclusão das

atividades do projeto, podendo conter marcos (pontos de controle, normalmente as conclusões/entregas de subprodutos);

BASIC METHODWARE (www.methodware.com.br)

Page 41: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 41/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto41

• Cronograma de Marcos: um cronograma sumarizado que identifica os principais pontos de controle do projeto (marcos).

Temos então de definir as datas de início e término das atividades do projeto. É o processo que evidencia as seguintes etapas:

conciliar de forma eficiente o uso dos recursos a fim de aperfeiçoar a forma de utilização; determinar quais atividades fazem parte do

caminho mais longo do projeto (também chamado de caminho crítico) com objetivo de priorizá-las; e adequar o cronograma do

projeto às restrições de datas e prazos impostos ao projeto para que assim minimize os eventuais atrasos.

Vale ressaltar que o cronograma do projeto pode ser elaborado em diversos softwares dependendo apenas da complexidade do projeto.

Para o nosso projeto exemplo, Treinamento em Gerenciamento de Projetos, o cronograma seria o constante do final deste texto. Repare

que é necessário estabelecer a data de início do projeto e também verificar se a data em que o treinamento está planejado está

adequada para a empresa. Por exemplo, em uma primeira simulação o treinamento começaria em uma sexta-feira, o que não seria

interessante, sendo alterada a data de início para a próxima 2ª feira. Outra preocupação é com a super alocação de recursos (por 

exemplo, a alocação de uma pessoa da equipe para fazer duas tarefas ao mesmo tempo). Ocorreu no projeto exemplo que, na primeira

versão do cronograma, o Apoio Acadêmico estava em duas atividades no mesmo dia, o que foi resolvido alterando a data de uma das

tarefas para o dia seguinte.

Maiores detalhes acerca da elaboração do Cronograma podem ser vistos no livro "Metodologia de Gerenciamento de Projetos -

BASIC METHODWARE (www.methodware.com.br)

Page 42: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 42/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto42

Methodware" [Xavier e outros, 2009].

Elabore agora o cronograma do seu projeto.

PROJETO MODELO

Cronograma (3.2)

ID EAP Nome da Tarefa Duração Início Término Predecessora 01

02

03

04

05

06

07

08

09

1

0

11

12

13

14

15

16

17

1 1 Treinamento Gerencia de Projetos 17 dias 01/02/2011 18/02/2011

2 1.1 Gerenciamento do Projeto 9 dias 01/02/2011 09/02/20113 1.1.1 Reunião de Partida do Projeto (2) 1 dia 01/02/2001 01/02/2011

4 1.1.2 Plano do Projeto 2 dias 02/02/2011 03/02/2011 3

5 1.1.3 Reuniões de Acompanhamento 5 dias 02/02/2011 06/02/2011 3

6 1.2 Preparação 6 dias 04/02/2011 09/02/2011

7 1.2.1 Verificação e Reserva da Sala 1 dia 04/02/2011 04/02/2011 4

8 1.2.2 Material Didático 4 dias 04/02/2011 07/02/2011

9 1.2.2.1 Apostila 2 dias 04/02/2011 05/02/2011 4

10 1.2.2.2 Slides 1 dia 06/02/2011 06/02/2011 911 1.2.2.3 Exercício prático 1 dia 07/02/2011 07/02/2011 10

12 1.2.2.4 Prova 1 dia 08/02/2011 08/02/2011 11

BASIC METHODWARE (www.methodware.com.br)

Page 43: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 43/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto43

13 1.2.2.5 Reprodução e montagem material(3) 1 dia 09/02/2011 09/02/2011 12

14 1.2.3 Contratação coffee break 1 dia 05/02/2011 05/02/2011 715 1.2.4 Questionário de avaliação 1 dia 04/02/2011 04/02/2011 4

16 1.2.5 Fase de Preparação Concluída (M) 09/02/2011 09/02/2011 7;13;14;15

17 1.3 Treinamento 8 dias 10/02/2011 17/02/2011 12

18 1.3.1 Aulas 4 dias 10/02/2011 13/02/2011 16 (I-I)

19 1.3.2 “Coffee break” 4 dias 10/02/2011 13/02/2011 18 (I-I)

20 1.3.3 Avaliação do treinamento alunos 1 dia 14/02/2011 14/02/2011 18

21 1.3.4 Treinamento concluído (M) 14/02/2011 14/02/2011

22 1.4 Fechamento do Projeto 3 dias 15/02/2011 17/02/2011 1823 1.4.1 Avaliação dos alunos (prova) 2 dias 15/02/2011 16/02/2011 18

24 1.4.1.1 Aplicar a prova 1 dia 15/02/2011 15/02/2011 20

25 1.4.1.2 Corrigir a prova 1 dia 16/02/2011 16/02/2011 24

26 1.4.2 Relatório do projeto 1 dia 17/02/2011 17/02/2011 25

27 1.4.3 Projeto concluído (M) 17/02/2011 17/02/2011

BASIC METHODWARE (www.methodware.com.br)

Page 44: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 44/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto44

7º MODULO: P6 - Planejar as Aquisições

A intensa competição global fez com que as empresas buscassem uma maior eficiência em seus processos, tendo obtido uma posição

de destaque o Gerenciamento das Aquisições em Projetos. A exemplo da tradução oficial do PMBOK®, utilizaremos nesta metodologia

o termo "Aquisição" como tradução de "Procurement", significando a compra ou contratação de produtos e serviços ou resultados

para atender às necessidades do projeto. Desta forma utilizaremos, sem fazer distinção entre eles, os termos "compra", "aquisição" e

"contratação".

O gerenciamento de aquisições do projeto passa pela decisão do que, quanto, quando e como será a contratação no projeto, incluindo

a administração e o encerramento de contratos.

Para planejar as aquisições, devemos identificar as necessidades do projeto que serão mais bem atendidas por meio da aquisição de

produtos, serviços ou recursos físicos (materiais, equipamentos e pessoas) de fora da equipe do projeto.

Nem sempre a organização irá executar a totalidade do escopo utilizando apenas sua experiência (recursos internos). Nessas

situações, seja pela falta de conhecimento e experiência sobre o serviço ou produto, seja por uma estratégia de compartilhamento ou

transferência de risco, ou apenas pela falta de recursos físicos, é necessário realizar processos de aquisições. Para isso, deverá ser 

definido o que será adquirido e como será conduzido o processo durante a execução do projeto. O primeiro passo, portanto, é decidir o

que será contratado e o que será feito internamente.

BASIC METHODWARE (www.methodware.com.br)

Page 45: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 45/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto45

A análise da EAP, do Cronograma e das Responsabilidades auxiliará a equipe a determinar os produtos e serviços a serem adquiridos,considerando as necessidades de recursos físicos (exceto pessoal) e a capacidade da organização de fornecê-los. Os recursos que não

estiverem disponíveis internamente devem ser obtidos externamente.

O Mapa das Aquisições é o documento que indica a relação das aquisições necessárias de bens e serviços para atender ao projeto,

adequando a contratação ao cronograma.

A tabela abaixo apresenta o Mapa das Aquisições para o projeto exemplo de treinamento em gerenciamento de Projetos. Repare quetemos um fornecedor interno (Setor de Administração), o que é comum em projetos.

Elabore agora o Mapa das Aquisições do seu projeto, preenchendo, no Plano do Projeto, o subitem 3.6.

PROJETO MODELO

3.6 Aquisições

Item Descrição Quantidade Código EAP Lista de Fornecedores Prazo Orçamento (R$)

01 Sala de Aula 1 1.3.2 Setor de Administração 10 a 13/02/2011 R$ 1.000,00

02 “Coffee break” 2 1.3.3 A&A Buffet 15 a 18/03/10 R$ 1.000,00

BASIC METHODWARE (www.methodware.com.br)

Page 46: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 46/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto46

Elabore agora o Mapa das Aquisições do seu projeto, preenchendo, no Plano do Projeto, o subitem 3.6.

Após decidirmos o que será contratado, para cada produto / serviço ou conjunto a ser adquirido, devemos acrescentar no planejamento

(EAP e cronograma) as entregas e atividades necessárias para a solicitação de propostas, contratação e administração do contrato. Por 

exemplo, no projeto exemplo de treinamento em gerenciamento de Projetos, já foram acrescentadas na EAP, no processo P2, as

entregas "Reserva da Sala" e "Contratação do Coffee Break",

Atualize agora a EAP e o cronograma do seu projeto com os processos necessários para a aquisição dos itens previstos no Mapa das

Aquisições.

BASIC METHODWARE (www.methodware.com.br)

Page 47: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 47/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto47

8º MODULO: P7 - Planejar o Custo

É o processo que desenvolve uma estimativa dos custos dos recursos necessários para a implementação das atividades do

projeto. Veja que o objetivo é estimar custo e não despesa. Por exemplo, a utilização de um profissional interno no nosso projeto tem

custo mas não tem despesa, pois ele já está na folha de pagamento da empresa.

O cálculo do custo do projeto é normalmente feito através do somatório do custo de geração de cada produto do projeto. Muitas

vezes é um processo iterativo porque exige decisões de gerenciamento quando as estimativas não estão condizentes com os recursos

financeiros disponíveis. É iterativo porque estas decisões de gerenciamento envolvem mudanças na definição de atividades, nos

recursos envolvidos e no cronograma do projeto.

As estimativas de custo podem ser baseadas em propostas de fornecedores, dados históricos e estatísticos ou em projetos

semelhantes.

Existem três formas de realizar as análises de custos que são: a Estimativa Análoga, que utiliza dados de projetos semelhantes;

a Estimativa Paramétrica, que busca informações estatísticas do projeto; e a Estimativa bottom-up, a mais acurada delas, que é

usada através da multiplicação do custo do recurso pela quantidade necessária deste recurso.

A estimativa bottom-up depende da identificação dos recursos e do tempo de sua utilização, comentada no processo P5, sendo

necessário o estabelecimento dos custos desses recursos. Digamos que no nosso projeto exemplo tenhamos os seguintes custos por 

recurso:

BASIC METHODWARE (www.methodware.com.br)

Page 48: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 48/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto48

RECURSO CUSTOGerente do Projeto R$ 600,00 por dia

Instrutor R$ 500,00 por dia

Apoio Acadêmico R$ 100,00 por dia

“Buffet” R$ 600,00 por dia

Sala de aula R$ 500,00 por dia

Com esses custos, orçamento do projeto exemplo seria (1):

PROJETO MODELO

3.3 Orçamento

Código EAP Descrição Valor (R$)

1 Projeto: Treinamento Gerenciamento de Projetos

1.1 Gerenciamento do Projeto

1.1.1 Reunião de Partida do Projeto “Kick off” R$ 600,00

1.1.2 Plano do Projeto R$ 1.200,00

1.1.3 Reuniões de Acompanhamento R$ 1.200,00

1.2 Preparação

BASIC METHODWARE (www.methodware.com.br)

Page 49: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 49/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto49

1.2.1 Verificação e Reserva da Sala R$ 100,00

1.2.2 Material Didático1.2.2.1 Apostila R$ 1.000,00

1.2.2.2 Slides R$ 500,00

1.2.2.3 Exercício prático R$ 500,00

1.2.2.4 Prova R$ 500,00

1.2.2.5 Reprodução e montagem material3 R$ 100,00

1.2.3 Contratação “coffee break” R$ 600,00

1.2.4 Questionário de avaliação R$ 100,00

1.2.5 Fase de Preparação Concluída (marco)

1.3 Treinamento

1.3.1 Aulas R$ 2.000,00

1.3.2 “Coffee break” R$ 2.000,00

1.3.3 Avaliação do treinamento pelos alunos R$ 100,00

1.3.4 Treinamento concluído (Marco)

1.4 Fechamento do Projeto

1.4.1 Avaliação dos alunos (prova)1.4.1.1 Aplicar a prova R$ 100,00

1.4.1.2 Corrigir a prova R$ 500,00

BASIC METHODWARE (www.methodware.com.br)

Page 50: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 50/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto50

1.4.2 Relatório do projeto R$ 600,00

1.4.3 Projeto concluído (Marco)Subtotal R$ 11.700,00

Reserva (10%) (2) R$ 1.170,00

Total R$ 12.870,00(1) Repare que as estimativas bottom-up são feitas no nível mais baixo de decomposição.

(2) É comum colocarmos uma reserva, que serve para atender aos impactos dos eventuais riscos do projeto.

Faça agora o planejamento dos custos do seu projeto e lance no item 3.3 do Plano do Projeto.

BASIC METHODWARE (www.methodware.com.br)

Page 51: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 51/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto51

9º MODULO: P8 - Aprovar o Plano do Projeto

O Plano do Projeto, algumas vezes chamado de Plano de Gerenciamento do Projeto (PGP), Plano Integrado do Projeto, Plano Geral

do Projeto ou Plano Global do Projeto, é o documento formal que consolida todo o planejamento, servindo como base para a gerência

do mesmo.

Conforme alerta o PMBOK® 4ª edição, "o conteúdo do Plano irá variar dependendo da área de aplicação e complexidade do projeto".

O plano do projeto é mais do que somente uma estimativa do que será feito, quando será feito, e os recursos exigidos para tal. É um

compromisso dos indivíduos e da organização envolvida para executarem o projeto de acordo com o plano. Então, é crítico que os

indivíduos responsáveis por fazer estes compromissos sejam participantes ativos no processo de planejamento e aceitem a sua parcela

de responsabilidade na execução do Plano.

O Plano deve ser um documento formal, consistente e aprovado pelo patrocinador ou cliente do projeto. Para que ele seja

consistente, é importante verificar se o planejamento de cada área foi refletido nas demais. Por exemplo, uma resposta ao risco de

chuva, no projeto de um churrasco, pode ser a contratação de um toldo, com os seguintes reflexos: acréscimo do toldo no Mapa de

Aquisições; acréscimo da contratação na EAP e no cronograma; assim como o acréscimo do valor correspondente ao aluguel no

orçamento.

Além do resultado do planejamento, que foi sendo feito ao longo dos processos P1 a P7, o Plano deve definir também como será feito o

BASIC METHODWARE (www.methodware.com.br)

Page 52: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 52/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto52

controle integrado de mudanças e o acompanhamento do projeto, respectivamente os itens 4 e 5 do modelo do Plano do Projeto. O

Planejamento do Controle Integrado de Mudanças tem como objetivo planejar como as mudanças no projeto poderão ser solicitadas,como será feita a avaliação de impacto e qual o mecanismo de autorização de mudanças, com o respectivo reflexo no planejamento do

projeto. O Acompanhamento do projeto deve ser feito por meio de relatórios e reuniões. Falaremos sobre este assunto nos processos

"C - Checar o Trabalho do Projeto" e "A - Agir para corrigir distorções".

Após aprovado, o plano passa a ser a base de referência (baseline) para a medição do progresso e o controle do projeto. Se estiver 

usando um software de gerenciamento de projetos, esta é a hora de salvar a base de referência.

O Plano deve ser continuamente atualizado de forma a traduzir a realidade do projeto.

BASIC METHODWARE (www.methodware.com.br)

Page 53: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 53/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto53

10º MODULO: E (EXECUTAR “DO”) - Gerenciar a Execução do Plano do Projeto

Este processo tem como objetivo colocar em prática o previsto no Plano do Projeto. O gerente do projeto orienta o desempenho das

atividades planejadas do projeto e gerencia as diversas interfaces técnicas e organizacionais que existem dentro do projeto.

Geralmente, a maior parte dos recursos (pessoas, materiais e equipamentos) estará dedicada a este processo, que será concluído após

terem sido entregues todos os produtos e serviços planejados para o projeto. Este trabalho deve ser feito de forma coordenada e com a

utilização otimizada dos recursos, gerando o escopo na qualidade prevista.

O gerente deve dar uma atenção especial para os produtos e serviços mais importantes do projeto. Para tal ele deve ter em mente a

regra 80/20 (também conhecida como princípio de Pareto). O princípio afirma, de uma maneira genérica, que 80% dos resultados que

obtemos estão relacionados com 20% dos nossos esforços. A relação 80/20 é apenas um referencial. O gerente de projeto deve então

identificar os 20% de produtos e serviços que serão responsáveis pela geração de 80% dos resultados. Para isso, deve usar como

parâmetro: importância do produto/serviço para o cliente; riscos envolvidos; custos envolvidos; e se o atraso da atividade

causará atraso no projeto. No projeto exemplo de treinamento em gerenciamento de Projetos, o gerente deveria estar mais atento à

seleção do instrutor para o curso, na validação do material didático e no acompanhamento da execução das Aulas.

Lembre-se que gerenciar projetos é gerenciar pessoas. É papel do gerente do projeto: desenvolver a qualificação dos membros daequipe, de modo a aumentar sua capacidade de concluir satisfatoriamente as atividades do projeto; e desenvolver a confiança e a

coesão dos membros da equipe para que a produtividade seja aumentada por meio de um melhor trabalho em equipe.

BASIC METHODWARE (www.methodware.com.br)

Page 54: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 54/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto54

E.1 - Mobilizar a Equipe do Projeto

Devemos mobilizar a equipe de execução do projeto, definida de acordo com o processo P5. Essa mobilização deve ser feita ao longo

do projeto, de acordo com as necessidades para a realização das tarefas e também quando for necessário substituir recursos da

equipe.

De um modo geral, são considerados os seguintes fatores na escolha dos membros da equipe: disponibilidade, qualificação, experiência

específica no trabalho a ser executado, interesse pessoal e o custo da mão-de-obra. O gerente do projeto deve atuar de modo aminimizar os riscos decorrentes de ausências ou abandonos por parte dos membros da equipe.

Quando ocorrer disputa por recursos da organização, o gerente do projeto deverá utilizar sua capacidade de negociação para trazer os

melhores recursos para a equipe.

O gerente do projeto (GP) deve garantir que:

(a) todos os membros da equipe sejam formalmente alocados ao projeto. Para tanto, as pessoas devem ser formalmente comunicadas

da sua alocação (por e-mail, por exemplo);

BASIC METHODWARE (www.methodware.com.br)

Page 55: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 55/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto55

(b) as informações sobre a equipe na "Relação dos envolvidos no projeto" (vide processo P1) sejam atualizadas;

(c) para cada pessoa alocada, esteja definido o quanto ela estará dedicada ao projeto (por exemplo, uma pessoa pode estar disponível

para o projeto apenas durante uma semana, em regime integral, em meio-expediente, ou especificamente para uma tarefa).

A tabela de alocação de recursos, vista em P5.3 deve ser atualizada no Plano do Projeto para contemplar os nomes dos recursos

alocados. Lembre-se que o Plano do Projeto é um documento dinâmico.

PROJETO MODELO3.1.3 Recursos necessários e Estimativa da duração das atividades

ID Cod. EAP EAP com Atividades (1) Predecessora Recursos Duração

1 1 Projeto: Treinamento Gerenciamento de Projetos

2 1.1 Gerenciamento do Projeto

3 1.1.1 Reunião de Partida do Projeto “Kick off” José das Couves 1 dia

4 1.1.2 Plano do Projeto 3 José das Couves 2 dias

5 1.1.3 Reuniões de Acompanhamento 3 GP;Instrutor; AA 1 vez cada 3 dias

6 1.2 Preparação7 1.2.1 Verificação e Reserva da Sala 4 (Apoio Acadêmico) AA 1 dia

8 1.2.2 Material Didático

BASIC METHODWARE (www.methodware.com.br)

Page 56: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 56/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto56

9 1.2.2.1 Apostila 4 Instrutor 2 dias

10 1.2.2.2 Slides 9 Instrutor 1 dia11 1.2.2.3 Exercício prático 10 Instrutor 1 dia

12 1.2.2.4 Prova 11 Instrutor 1 dia

13 1.2.2.5 Reprodução e montagem material 12 Apoio Acadêmico 1 dia

14 1.2.3 Contratação “coffee break” 7 GP 1 dia

15 1.2.4 Questionário de avaliação 4 Apoio Acadêmico 1 dia

16 1.2.5 Fase de Preparação Concluída (marco) 7;13;14;15

17 1.3 Treinamento 12

18 1.3.1 Aulas 16 Instrutor; Sala de aula 4 dias19 1.3.2 “Coffee break” 18 (I-I) Buffet 4 dias

20 1.3.3 Avaliação do treinamento pelos alunos 18 (T-T) Apoio Acadêmico 1 dia

21 1.3.4 Treinamento concluído 19;20

22 1.4 Fechamento do Projeto 18 (I-I)

23 1.4.1 Avaliação dos alunos (prova) 18 (I-I)

24 1.4.1.1 Aplicar a prova 20 Apoio Acadêmico 1 dia

25 1.4.1.2 Corrigir a prova 24 Instrutor 1 dia

26 1.4.2 Relatório do projeto 25 GP 1 dia

27 1.4.3 Projeto concluído (marco) 5;26

BASIC METHODWARE (www.methodware.com.br)

Page 57: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 57/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto57

Defina agora, com a sua equipe, a estratégia de condução do projeto e lance no subitem 3.1.3 do Plano do Projeto.

E.2 -Autorizar a Execução do Trabalho

O gerente deve autorizar o início da execução dos produtos e serviços e/ou de atividades do projeto. Isso garantirá que o trabalho

será realizado no momento correto e na seqüência adequada. A "Autorização do trabalho" é uma permissão e uma orientação, verbal ou

escrita, para iniciar o trabalho previsto no cronograma. A falta de coordenação das atividades e recursos é uma das principais fontes de

problemas no desempenho de um projeto. Em alguns casos, pode comprometer definitivamente o serviço ou produto que este irá

produzir.

Além das atividades originalmente planejadas, existem atividades decorrentes de solicitações de mudanças e ações corretivas ou

preventivas, que para serem executadas devem ser devidamente autorizadas pelo gerente do projeto. Trataremos do controle de

mudanças no projeto no processo "A - Agir para Corrigir Distorções".

Quando todos os serviços/produtos tiverem sido entregues e aceitos (segundo o processo de controle), este processos estará

concluído.

E.3 - Comunicar-se com os principais envolvidos

BASIC METHODWARE (www.methodware.com.br)

Page 58: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 58/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto58

O gerente utiliza as suas habilidades de comunicação para que as informações acerca do projeto sejam enviadas de forma clara

e completa às partes envolvidas. Problemas de comunicação são uma das principais fontes de insucesso em projetos. Portanto, umacomunicação adequada colabora muito para que o projeto seja bem sucedido em sua execução. Estatísticas mostram que cerca de

90% do tempo do gerente são gastos se comunicando com a equipe, cliente, fornecedores e outros stakeholders.

Para a divulgação das informações sobre o projeto podem ser utilizados diversos meios de comunicação, tais como: telefone,

relatórios impressos, e-mails, páginas na internet ou na intranet, vídeos, reuniões, apresentações em computador etc. Atenção que

devemos ter qualidade e não quantidade de comunicação. Muito cuidado para que não seja feito o gerenciamento do projeto pelo

correio eletrônico. Se o gerente passa boa parte do seu tempo lendo e escrevendo mensagens eletrônicas, alguma coisa está errada.

E.4 - Obter o Aceite dos produtos e serviços do Projeto

À medida que o trabalho do projeto avança e as entregas programadas são cumpridas, torna-se necessária a obtenção do aceite

do cliente. O gerente deve obter do(s) representante(s) do cliente um documento formalizando o aceite, e arquivá-lo no acervo do

projeto. Pode ser uma mensagem eletrônica, uma ata de reunião ou até mesmo um documento específico criado para essa

formalização. É importante não deixar somente para a última entrega do projeto esta formalização.uma coisa está errada.

BASIC METHODWARE (www.methodware.com.br)

Page 59: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 59/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto59

11º MODULO: M (MONITORAR “CHECK”) - Checar o Trabalho do Projeto

Checar ou monitorar o trabalho do projeto significa observar , coletar , disseminar  e avaliar  informações a respeito do

desempenho do projeto a cada período de tempo (por exemplo, a cada mês).

Para esse monitoramento, utiliza-se como base de referência o Plano do Projeto aprovado. É necessário:

• Coletar informações sobre o custo e as datas reais de execução do projeto;

• Comparar o desempenho real obtido com o Plano do Projeto;

• Monitorar os riscos do projeto;

• Prover informações para apoiar os relatos de status, medição de progresso e estimativas futuras;

• Monitorar a implementação das requisições de mudanças aprovadas de acordo com o processo "A - Agir para Corrigir 

Distorções".

O principal instrumento de representação do monitoramento de um projeto é o Relatório de Desempenho (D4). A periodicidade

de emissão desse documento deve ser acertada com o cliente, sendo estabelecida de acordo com o contexto de cada projeto. A seguir 

pode ser vista uma sugestão de conteúdo para esse documento.

BASIC METHODWARE (www.methodware.com.br)

Page 60: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 60/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto60

RELATÓRIO DE DESEMPENHO (D5)

Projeto:

Período: Data de emissão:

Elaborado por:

1. Atividades Realizadas:

 Atividades concluídas desde o último relatório

Dicas

Inclua o nome da atividade como está no cronograma, incluindo o código da EAP. Isso ajuda a facilitar a identificação das atividades.

Para facilitar a compreensão do relatório sempre que se julgar necessário deve ser incluído um pequeno parágrafo explicativo.

Se a atividade estava atrasada, mencionar desde quando.

Mencionar sempre quando uma atividade não estava programada no planejamento inicial. Por exemplo, atividades de replanejamento,

ou atividades resultante de ações para correção de desvios (item 6).

Para tarefas que agrupam atividades relacionadas, não é necessário listá-las, a não ser que seja considerado relevante.

2. Atividades Pendentes:

"Atividades que deveriam ter sido concluídas e não foram, utilizando as dicas de 1"

3. Pontos de Atenção:

BASIC METHODWARE (www.methodware.com.br)

Page 61: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 61/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto61

Liste os pontos de atenção e um breve parágrafo explicativo

4. Próximas Atividades:"Atividades que estarão em foco no próximo período de acompanhamento do projeto, utilizando as dicas de 1"

5. Posicionamento em Relação ao Cronograma Planejado:

Dica: Caso esteja utilizando o MS-Project, inserir o cronograma (Gantt de Controle) com o avanço físico até o momento.

6. Razões dos Desvios e Sugestões de Ações Corretivas:

"Lançar a motivação para os desvios em relação ao programado e as sugestões de ações corretivas que a ser implementadas"

7. Previsão de Término do Projeto:

"Prognóstico de custo e prazo para o término do projeto"

 ______________________________ 

ASSINATURA "gerente do projeto"

BASIC METHODWARE (www.methodware.com.br)

Page 62: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 62/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto62

12º MODULO: C (CONTROLAR “ACT”) - Agir para Corrigir Distorções

Este processo tem como objetivo corrigir as distorções detectadas pelo processo "C - Checar o Trabalho do Projeto" e,

também, controlar as mudanças aprovadas para o projeto.

C.1 - Corrigir as distorções

Uma distorção no projeto é um desvio em relação ao planejado. Pode ser em relação a qualquer área de conhecimento: escopo,

tempo, custo, recursos humanos, qualidade, comunicação, aquisições, risco ou integração. As decisões acerca do que fazer em relação

aos desvios são tomadas, normalmente, em "Reuniões de Acompanhamento" com o cliente, com a equipe, com o fornecedor ou outros

stakeholders. Essas reuniões podem acontecer com diferentes periodicidades e em diversos níveis (por exemplo: um projeto pode ter 

uma reunião semanal coma a equipe, outra quinzenal com os fornecedores e outra mensal com o cliente).

Lembre-se que o instrumento correto para apontar as distorções é o relatório, que deve ser enviado com antecedência aos participantes

da reunião para que, quando da realização da mesma, ela seja mais eficaz, focando na decisão a ser tomada.

C.2 - Controlar as Mudanças

As mudanças nos projetos ocorrem por vários motivos e não têm, a princípio, somente conseqüências negativas, como aumento de

BASIC METHODWARE (www.methodware.com.br)

Page 63: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 63/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto63

custo e de prazo. Elas podem gerar resultados positivos também. É importante gerenciar com atenção este processo, de modo a

assegurar que as mudanças: (a) sejam identificadas; (b) sejam adequadamente avaliadas quanto ao seu impacto sobre os objetivos erestrições do projeto; e (c) sejam formalmente autorizadas, pois o excesso de mudanças, ou até mesmo uma única mudança, podem

causar impacto inaceitável no cronograma, custo e qualidade.

O controle de mudanças deve ser feito de forma integrada, compreendendo o controle das mudanças de escopo, cronograma e

orçamento do projeto.

Uma mudança pode ser solicitada a qualquer tempo e por qualquer pessoa ou parte interessada (usuário, cliente, membros da equipe,

investidores) autorizada para tal. As mudanças no projeto podem ocorrer de forma indireta, como resultado de planos de contingência

ou outras alterações e favores prestados ao cliente por membros da equipe. Muitas vezes são mudanças mínimas as quais os

responsáveis não informam à equipe e muito menos ao gerente do projeto. Uma vez que não é recomendável desestimular as boas

relações profissionais entre a equipe e as partes interessadas, é conveniente assegurar que todas as mudanças sejam devidamente

autorizadas via um sistema de controle.

Uma maneira de estabelecer um sistema de controle de mudanças é adotar um formulário de requisição de mudança. Isso permitirá que

as informações relevantes sobre o que deve ser mudado, quem realizou a solicitação, o motivo da solicitação e quais os seus impactos

sejam identificados e utilizados no processo de tomada de decisão que determinará sua aprovação (ou não).

BASIC METHODWARE (www.methodware.com.br)

Page 64: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 64/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto64

O impacto da implementação da mudança deve ser analisado pela equipe de gerenciamento, sendo os resultados, juntamente com arequisição, submetidos à sistemática de controle de mudanças definida para o projeto. Uma vez aprovada, a mudança é refletida no

plano do projeto com a atualização da EAP, cronograma, orçamento e demais itens do plano do projeto, de acordo com a abrangência

da mudança, sendo estabelecida então a nova base de referência. O trabalho, relativo à mudança, incorporado ao plano do projeto

pode, portanto, ser realizado e controlado da mesma forma que o trabalho originalmente planejado.

A sistemática a ser utilizada para o controle de mudanças deve estar estabelecida no Plano de Projeto e divulgada para os principais

stakeholders. A seguir pode ser visto um exemplo de modelo de "Pedido de Mudança".

PEDIDO DE MUDANÇA (D6) PM nº

Projeto: Data:

Solicitado por:

Contato:

DETALHES DA MUDANÇA

Descrição:

Motivo:

AVALIAÇÃO DOS IMPACTOS

Escopo:

BASIC METHODWARE (www.methodware.com.br)

Page 65: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 65/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto65

Custo:

Prazo:Qualidade:

Solicitação Aprovada ( ) Solicitação Rejeitada ( )

Justificativa:

Gerente de projeto: Data:

Responsável pela aprovação: Data: 

BASIC METHODWARE (www.methodware.com.br)

Page 66: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 66/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto66

13º MODULO: F - Encerrar o Projeto

O encerramento do projeto pode ser iniciado quando o processo "C - Checar o Trabalho do Projeto" indicar que o escopo do

projeto foi totalmente entregue e aceito, ou quando o patrocinador ou a gerência da organização solicitar o cancelamento do mesmo

(caso seus objetivos não sejam mais pertinentes, necessários ou alcançáveis). Para que o projeto seja encerrado, todos os contratos

também devem ser encerrados. Devemos documentar os resultados e o conhecimento obtidos pela organização durante a execução do

projeto, formalizando o encerramento do projeto.

F.1 - Solicitar ao Cliente o aceite final e a avaliação do Projeto

O término do projeto para com o cliente deve ser formalizado por meio de e-mail, reunião ou termo formal de aceite (D7). A idéia

é documentar que o projeto e o cliente estão quites em relação às suas responsabilidades combinadas para o projeto. Na situação em

que o projeto tenha sido interrompido, ou seja, finalizado antes do término, recomenda-se identificar e documentar as causas que

ocasionaram este término não previsto. No caso de cliente externo, é conveniente neste momento solicitar ao mesmo uma declaração /

atestado de execução do trabalho, que poderá ser útil em futuros processos para fornecimento de produtos e serviços

semelhantes ao mercado.

Para que a equipe possa obter o feedback final do cliente em relação ao desempenho do projeto, pode ser solicitado ao mesmoque faça uma avaliação que indique o grau de satisfação em relação ao gerenciamento do projeto.

Em projetos para clientes internos, pode ser necessário realizar avaliação em relação aos resultados para o negócio. Por 

BASIC METHODWARE (www.methodware.com.br)

Page 67: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 67/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto67

exemplo, o retorno do investimento foi alcançado?

Os resultados da avaliação do cliente (interno ou externo) devem ser analisados pela equipe do projeto, sendo utilizados paraidentificar necessidades de melhorias. Uma boa prática, no encerramento do projeto, é a documentação das lições aprendidas,

capturando o conhecimento desenvolvido durante a execução do projeto. Se as informações sobre os problemas, os erros e acertos

cometidos no projeto não forem materializados em documentos e analisados pela organização, o conhecimento se perde e a

organização não se aprimora, repetindo erros passados.

E.2 - Fechar o Projeto

Este passo consiste na realização de algumas tarefas de cunho administrativo para que o projeto seja encerrado - por exemplo,

liberar recursos alocados ao projeto, atualizar os registros finais do projeto e fechar o projeto nos sistemas administrativos.

O encerramento administrativo do projeto só poderá ser efetivamente realizado quando todas as etapas e pendências tiverem

sido concluídas e sanadas, salvo por término antecipado do mesmo.

BASIC METHODWARE (www.methodware.com.br)

Page 68: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 68/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto68

BILBIOGRAFIA

PMI, Project Management Institute (Editor). PMBOK® (Project Management Body of Knowledge) Guide, Fourth Edition. USA: PMI,2008.

XAVIER, Carlos Magno da Silva; Vivacqua, Flávio; Macedo, Otualp; e Xavier, Luiz. Metodologia de Gerenciamento de Projetos -Methodware. Rio de Janeiro: Brasport. 2ª edição, 2009.

BASIC METHODWARE (www.methodware.com.br)

Page 69: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 69/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto69

ANEXO 1 – Mapa dos Processos

MAPA DE PROCESSOS “ROADMAP”

I - INICIAR P - PLANEJAR “PLAN” E - EXECUTAR “DO” M - MONITORAR “CHECK” F - FINALIZAR

I – Autorizar o Início doProjeto

P.1 – Identificar osEnvolvidos

E – Gerenciar a Execução doPlano de Projeto

M – Checar o Trabalho doProjeto

F - Encerrar o Projeto

Termo de Abertura (D1) P.2 – Planejar o Escopo e aQualidade

Autorização do Trabalho (D3) Relatórios de Desempenho (D5) Aceite Final (D7)

P.3 – Planejar as Respostasaos Riscos

Equipe de Trabalho (D4)C – CONTROLAR “ACT”

P.4 – Planejar asComunicações C – Agir para Corrigir Distorções

P.5 – Planejar Tempo eRecursos

Pedidos de Mudança (D6)

P.6 – Planejar as Aquisições

P.7 – Planejar o Custo

P.8 – Aprovar o Plano deProjeto

Plano do Projeto (D2)

BASIC METHODWARE (www.methodware.com.br)

Page 70: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 70/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto70

ANEXO 2 – Plano do Projeto

UEGUnidade de Pirenópolis

PLANO DO PROJETO

Projeto: Inicio:

Término:

Gerente: Versão: 01

1 INTRODUÇÃO (pag. 06)

1.1 Justificativa

1.2 Objetivos e Metas

1.3 Limite de Prazo e Custo (Restrições)

1.3.1 O projeto deverá estar concluído em até 14(quatorze) dias.

1.3.2 O orçamento para o projeto é de R$ 1.200,00 (um mil e duzentos reais)

2 RELAÇÃO DOS ENVOLVIDOS (pag. 08)

BASIC METHODWARE (www.methodware.com.br)

Page 71: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 71/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto71

ID Nome Organização / Cargo Telefone / E-mail Envolvimento1 Maria da Penha Mãe da Marta 9999 9999 / [email protected] Patrocinador 

2 Marta da Penha Avó 8888 8888 / [email protected] Patrocinador  

3 Carlos Alberto Só Festas / Gerente 7777 7777 Gerente

Márcia da Silva Bolos e Salgados / Gerente

Jonathan Mágico

3 PLANEJAMENTO

3.1 Escopo

3.1.1 Descrição do Escopo combinado com cliente

3.1.2 Escopo não incluído

3.1.3 Estratégia de condução do projeto

BASIC METHODWARE (www.methodware.com.br)

Page 72: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 72/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto72

3.1.4 EAP (Estrutura Analítica do Projeto)

3.1.5 Descrição das Entregas

Cód. EAP Nome Produto / Serviço Descrição Responsável

3.2 Cronograma

ID EAP Tarefa Duração Início Término Predecessor  

BASIC METHODWARE (www.methodware.com.br)

Page 73: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 73/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto73

3.3 Orçamento

Código EAP Descrição Valor (R$)

3.4 Riscos

ID Riscos (ameaça / oportunidade) Exposição ao RiscoA=Alta, M=Média, B=Baixa

Respostas aos Riscos Responsável

BASIC METHODWARE (www.methodware.com.br)

Page 74: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 74/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto74

3.5 Comunicação

Evento Periodicidade Documento Meio Responsável EnvolvidosReunião de Abertura

do ProjetoUma vez Ata Reunião Gerente do Projeto Todos da relação

Reunião deAcompanhamento

Uma vez, cinco dias úteis antes doinício da Festa de Aniversário

Ata Reunião Gerente do Projeto Equipe

Relatório deEncerramento do

ProjetoUma vez Relatório E-mail Gerente do Projeto Diretor Executivo

3.6 Aquisições

Item Descrição Qtd. Cod. EAP Lista de Fornecedores Prazo Orçamento (R$)

4 CONTROLE INTEGRADO DE MUDANÇAS

Com o objetivo de estabelecer um sistema de controle de mudanças que permita identificar as alterações e os impactos ocasionados,

principalmente, no escopo, cronograma e orçamento do projeto, os seguintes procedimentos devem ser seguidos pela equipe doprojeto:

4.1 Qualquer mudança de escopo deverá ser solicitada por e-mail ao Gerente do Projeto;

BASIC METHODWARE (www.methodware.com.br)

Page 75: basicmethodware-110301131921-phpapp01

8/4/2019 basicmethodware-110301131921-phpapp01

http://slidepdf.com/reader/full/basicmethodware-110301131921-phpapp01 75/75

UNIVERSIDADE ESTADUAL DE GOIÁSUnidade de Pirenópolis

Disciplina: Eventos / Prof.: Gedson e Carlos Alberto75

4.2 Só podem solicitar mudanças os envolvidos constantes da lista do item 2;4.3 Qualquer solicitação de mudança deve ser avaliada pelo Gerente do Projeto em relação ao seu impacto em custo e prazo;

4.4 A aprovação ou não das mudanças deve ser feita pelo Cliente.

5 ACOMPANHAMENTO DO PROJETO

O acompanhamento do projeto será realizado através de reuniões semanais, coordenadas pelo gerente do projeto, o qual irá prover asinformações necessárias para o monitoramento e controle do projeto, sendo reportado em seguida o andamento para o cliente, por e-mail.

APROVAÇÕES: DATA:

Gerente do Projeto: _____________________________________ 

Patrocinador:_________________________________________ 

BASIC METHODWARE (www.methodware.com.br)