Administração por Projetos

Revisão - Projeto Físico e
Lógico de Rede
Professor Kleber
[email protected]
Introdução
Definição do PMBOK
• Um empreendimento temporário, com um início
e fim definidos, para criar um produto ou serviço
com objetivos específicos que quando atingidos
significam que está finalizado
• Em geral:
• É direcionado para atingir um resultado específico
- Envolve a coordenação do empreendimento de atividades
inter relacionadas
- Tem uma duração limitada – um início e fim
- É único
Definição do PMBOK
• A aplicação de conhecimento, habilidades,
ferramentas e técnicas nas atividades do
projeto de forma a atingir ou exceder as
necessidades e expectativas dos
stakeholders do projeto
• O que dizem os gerentes de projetos:
• Gerenciamento de projetos relaciona-se
em obter o trabalho realizado:
- De acordo com o cronograma
- Dentro do orçamento previsto
- De acordo com as especificações
O trinômio do gerenciamento de
projetos
Custo
Tempo
Qualidade
Áreas de conhecimento do
PMBOK
- Escopo
- Deve assegurar que no projeto estejam as tarefas
necessárias, e somente as necessárias para
completá-lo de uma forma bem sucedida. O
gerenciamento do escopo significa definir e
controlar o que será incluído ou não no projeto.
- PMBOK – Project Scope Management:
-
Iniciação
Planejamento do escopo
Definição do escopo
Verificação do escopo
Controle de mudanças do escopo
Áreas de conhecimento do
PMBOK
- Prazo
- Determina os processos necessários para
assegurar o andamento e a conclusão do
projeto no tempo planejado
- PMBOK – Project time management:
-
Definição de atividades
Sequenciamento de atividades
Estimativa de duração das atividades
Desenvolvimento de cronograma
Controle do cronograma
Áreas de conhecimento do
PMBOK
- Qualidade
- Determina os processos necessários
para assegurar que o projeto atinja a
qualidade planejada
- PMBOK – Project quality
management:
- Planejamento da qualidade
- Asseguramento da qualidade
- Controle da qualidade
Áreas de conhecimento do
PMBOK
- Custo
- Determina os processos necessários para
assegurar que o projeto seja conduzido e
concluído dentro do orçamento aprovado.
- PMBOK – Project Cost management:
-
Planejamento de recursos
Estimativa de custos
Orçamento dos custos
Controle dos custos
Áreas de conhecimento do
PMBOK
- Comunicação
- Determina os processos necessários para assegurar
a edição, coleta, divulgação, armazenamento e
disposição de informações do projeto a tempo e de
forma adequada.
- PMBOK – Project Communications
management:
-
Planejamento de comunicação
Distribuição da informação
Performance dos relatórios
Fechamento administrativo
Áreas de conhecimento do
PMBOK
- Riscos
- Determina os processos necessários para assegurar
a identificação, análise e respostas aos riscos do
projeto.
- PMBOK – Project Risk management:
-
Planejamento do gerenciamento dos riscos
Identificação dos riscos
Análise qualitativa dos riscos
Análise quantitativa dos riscos
Planejamento de resposta aos riscos
Monitoração e controle dos riscos
Áreas de conhecimento do
PMBOK
- Aquisições
- Determina os processos necessários para assegurar
a obtenção de bens e serviços de terceiros.
- PMBOK – Project Procurement management:
-
Planejamento das aquisições
Planejamento das solicitações
Solicitações
Seleção de fornecedores
Administração de contratos
Finalização dos contratos
Áreas de conhecimento do
PMBOK
- Recursos Humanos
- Determina os processos necessários
para assegurar a administração
eficiente do pessoal disponível alocado
ao projeto.
- PMBOK – Project HR management:
- Planejamento organizacional
- Alocação da equipe
- Desenvolvimento da equipe
Áreas de conhecimento do
PMBOK
- Integração
- Determina os processos necessários para
assegurar que os vários componentes do
projeto sejam devidamente coordenados.
- PMBOK – Project Integration
management:
- Desenvolvimento do plano de projeto
- Execução do plano de projeto
- Controle de mudanças integrado
Iniciação do projeto
Iniciação do projeto
Project Charter
- É o documento que reconhece
formalmente a necessidade de um projeto
- Exemplo de um formulário ou sistema
para o registro do início de um projeto:
-
Nome do projeto:
Patrocinador:
Gerente alocado:
Cliente:
Contato:
Posição do contato:
Escopo:
Metas:
Restrições:
Riscos:
Prazo:
Investimento:
Recursos
Iniciação do projeto
Reconhecendo as necessidades do cliente
- Requer uma análise em profundidade das
necessidades reais do cliente
- Serve de base para o desenvolvimento de
especificações funcionais
- Cinco passos para esta articulação:
- Solicite ao cliente para definir suas necessidades tão
claramente quanto possível
- Examine todos os aspectos da necessidade
- Pesquise a necessidade para assegurar-se que está
totalmente entendida
- Descreva a necessidade tão precisamente quanto for possível
- Solicite ao cliente para avaliar a descrição do entendimento da
necessidade e revisá-la caso seja necessário
Iniciação do projeto
Especificações do projeto
- Após determinar as necessidades do
cliente, construa as especificações
- Funcionais:
- Descreva as características do deliverable em
linguagem clara
- Utilize gráficos ou diagramas para tornar isto
mais claro
- Técnicos
- Emergem dos requerimentos funcionais
- São escritos pela equipe técnica
Controle e execução do
projeto
Objetivos
-
Desenvolvimento da equipe
Controle do gerenciamento de mudanças
Monitorar o progresso do projeto
Examinar evolução de custos e
cronograma
- Usar técnicas: fast tracking e crashing
- Controlar e monitorar os recursos
Importância da documentação:
• Boa documentação é frequentemente um
componente crucial de sucesso nos projetos
• Documentação é necessária para controle, análise
do histórico e coordenação dos esforços do projeto
entre os membros da equipe
• Documentação é vital para a manutenção do sistema
• Documentação é frequentemente um elemento de
resistência nas equipes de projeto, que a vêem
como falta de criatividade e excessivamente
burocrática
• Os documentos do projeto deverão estar definidos
no plano de projeto como entregáveis
Crashing Tarefas:
• Requer a adição de recursos ao projeto para acelerar o
cronograma ou para lutar contra escorregamento do
cronograma
• Invariavelmente requer custos adicionais
• Crashing é feito nas tarefas que estão no caminho crítico
• Significa diminuir o tempo de execução de uma tarefa
adicionando-se recursos.
• Ex: A instalação física de equipamentos requer 5 dias com 1
recurso. Com a adição de dois recursos o seu tempo de
execução pode baixar para 2 dias
• Regras para crashing:
– Crash somente as tarefas que estão no caminho crítico
– Escolha as tarefas com o menor custo
Fast tracking:
• Significa fazer em paralelo atividades
que antes estavam em série de forma a
acelerar a execução do cronograma
• Ex: projeto e construção
• Deve ser acompanhado por um
controle de mudanças de forma a
analisar os riscos envolvidos com esta
forma de execução do projeto
O que monitorar em um projeto:
• Periodicamente deve-se monitorar:
– Recursos humanos – compromisso e disponibilidade
– Custos do projeto – mdo e materiais
– Cronograma – cumprimento das tarefas e entrega
dos deliverables
– Terceiros – seus contratos e suas atividades
– Riscos – monitorar regularmente os riscos
– Mudanças sutis que lentamente alteram o escopo
– Mudanças aprovadas e não aprovadas
– Periodicidade dos relatórios de avanço
– Controle dos contratos que fazem parte do projeto
Avaliação do projeto:
• É realizada periodicamente
• Está preocupada se os objetivos básicos
do projeto estão sendo realizados
• O resultado da avaliação pode conduzir a:
– Manutenção dos objetivos do projeto
– Mudanças leves na direção do projeto
– Reavaliação dos objetivos do projeto
– Abandono do projeto
Avaliação x Controle:
• Controle
– Foco na atingimento dos elementos individuais do
plano de projeto
– Monitoração contínua no cronograma e orçamento
– Cada um dos controles é relativamente barato
• Avaliação
– Revisão periódica do projeto
– Foco no atingimento dos objetivos básicos do projeto
Pontos a considerar:
• Controle do projeto é o processo de monitorar o projeto
e determinar o quanto efetivo estamos sendo no
seguimento do plano de projeto
• Gerenciamento do controle de mudanças fornece um
processo formal de identificar pedidos de mudança,
processá-las e determinar o curso da ação da mudança
• O progresso do projeto deve ser feito efetivamente
utilizando a documentação, indicadores e ferramentas
de medida
• Fast tracking e crashing são duas formas de acelerar o
cronograma
• Earned value é um conceito chave de determinar a
variância e projeções futuras do cronograma e custo do
projeto
Planejamento do projeto
Objetivos:
- Responder às questões mais críticas ao realizar
o planejamento do projeto
- Identificar o escopo do projeto
- Desenvolver uma WBS
- Avaliar os riscos do projeto
- Desenvolver o custo estimado do projeto
- Alocar os recursos do projeto
- Elaborar o plano do projeto
Planejamento:
- Processo de planejar e programar o como
e quando implantar o projeto
- Esforço contínuo / dinâmico ao longo do
ciclo de vida do projeto
- Para um projeto ser bem sucedido, é
imprescindível ter um bom planejamento
Principais processos:
-
Planejamento do escopo
Detalhamento do escopo
Definição das atividades
Planejamento dos recursos
Sequenciamento das atividades
Estimativa de duração das atividades
Estimativa de custos
Planejamento de riscos
Desenvolvimento de cronogramas
Orçamento de custos
Desenvolvimento do plano do projeto
Processos auxiliares:
-
Planejamento da qualidade
Planejamento organizacional
Formação de equipe
Planejamento das comunicações
Identificação de riscos
Análise qualitativa dos riscos
Análise quantitativa dos riscos
Desenvolvimento de resposta aos riscos
Planejamento de aquisições
Declaração do escopo:
- A declaração do escopo é uma base
documental para análises e discussões futuras e
para confirmar o entendimento comum entre os
stakeholders do projeto.
- Deve incluir:
-
Descrição do produto do projeto
Todos os deliverables do projeto
Recursos necessários para o atendimento do deliverable
Atividades a serem desenvolvidas para cada deliverable
Ferramentas utilizadas para a realização do deliverable
Responsabilidades do cliente e do fornecedor
Premissas específicas para o deliverable
Critério de aceitação do deliverable
WBS – Work Breakdown Structure
-
Uma organização hierárquica de atividades necessárias e suficientes para desenvolver os
produtos do projeto.
-
O tamanho e o número de níveis da WBS varia com a natureza do projeto.
-
A WBS é a fundação para o planejamento do projeto e para o seu controle.
-
“Work packages” são o nível mais baixo da WBS onde os recursos são designados e o progresso
é medido.
-
O WBS é o elemento mais crítico para fazer o orçamento do projeto
-
Se os “work packages” forem omitidos, o cronograma será otimista e de uma forma não realista e
o orçamento do projeto será inadequado.
-
Recomenda-se que os “work packages” não sejam maiores do que 40 horas (uma semana de
trabalho)
-
Work packages maiores de 40 horas. Ex: Operação assitida por 30 dias.
WBS
• A WBS é um agrupamento dos elementos do
projeto orientado pelos produtos, que organiza e
define o escopo total do projeto.
• Trabalho não incluso na WBS está fora do
escopo do projeto.
• É representativa do trabalho, com resultado
tangível
• • É uma estrutura hierárquica
• • Os objetivo (resultados tangíveis) se referem
aos Deliverables
WBS – Orientado a Tarefas
-
-
Revisar a declaração de escopo do projeto
Identificar as maiores atividades do projeto que devem ser
completadas para alcançar os objetivos do projeto
Identificar todas sub-atividades que devem ser completadas para
finalizar cada atividade maior
Dividir cada sub-atividade em tarefas que devem ser realizadas
para completar as atividades
Continuar neste processo até que os nível requerido de detalhes é
alcançado
Reunir-se com o cliente e stakeholders para validar a WBS
Buscar pontos que foram esquecidos e ajuste se necessário
WBS
Edifício
Planejamento
Levantamento de
dados
Projetos
Construção
Plantas
Sistemas
Acabamento
Limpeza
Hidráulico
Revestimento
Serviço Final
Limpeza
Gerenciamento
Controles
Legislação
Estrutural
Canteiro de Obra
Elétrico
Pintura
Acompanhamento
Estudo de
Viabilidade
Elétrica
Infra-Estrutura
Telecomunicações
Arremates Finais
(Ajustes)
Entrega
Telecomunicação
Estrutura
Som
Alvenaria
Imagem
Hidráulica
Documentações
Habite-se
Alvará
Aprovação
Esquemas técnicos
gráficos
Esquadrias
Cobertura
Termo de Aceite
O Linha de Base ou Baseline do
projeto
• O Baseline deve ser
utilizado como
referência para
acompanhamento do
avanço e para todas as
reprogramações.
• Ajustes, incrementos,
atrasos nas atividades
devem ser relacionadas
ao Baseline
Cronograma Inicial
Nivelamento dos recursos
Cronograma Final
Baseline do projeto
Gerenciamento de Riscos
• É o processo de identificar, analisar e
responder aos riscos do projeto.
• Inclui maximizar os resultados de eventos
positivos e minimizar as conseqüências
dos eventos adversos.
• A resposta aos riscos pode ser:
– Mitigar
– Evitar
– Aceitar
– Transferir
O impacto de um risco (às vezes chamado de conseqüência) é definido em
termos de uma escala discreta: 1 = muito baixo, 2 = baixo, 3 = médio, 4= alto
e 5 = muito alto.
1
Muito baixo
2
Baixo
3
Médio
Custo
Insignificante
aumento de
custos
< 5% o
5 – 10 %
aumento de aumento de
custos
custos
Cronogram
a
Atraso
insignificante
< 5% de
atraso
Funciona
lidades
Decréscimo
imperceptível
Qualidade
Degradação
imperceptível
4
Alto
5
Muito alto
10 – 20 %
aumento de
custos
> 20 %
aumento de
custos
5 – 10 % de
atraso
10 – 20 % de
atraso
> 20 % de
atraso
Diminuição
em áreas
de menor
relevância
Áreas
importantes
são afetadas
Redução de
funcionalidade
s inaceitável
para o cliente
Produto do
projeto não
tem
utilidade
para o
cliente
Somente
Redução
Redução
requer
inaceitável
aprovação do para o cliente
cliente
Produto do
projeto não tem
utilidade para o
cliente
Probabilidade de ocorrência de um risco. Podemos definir o impacto em uma
escala de cinco níveis: 1 = muito improvável, 2 = pouco provável, 3 =
provável, 4 = muito provável e 5 = praticamente certo
Nível
Probabilidade de
ocorrência
Dificuldade de intervenção
1
Você ficará surpreso
se ocorrer
O processo normal de gerência facilmente assegurará
um resultado aceitável
2
Mais provável que
não ocorra
3
Igual chance de
ocorrer ou não
Uma supervisão adicional no processo de
gerenciamento provavelmente trará um resultado
aceitável
Tempo e esforço adicional deverá ser empregado para
que o resultado seja aceitável
4
Mais provável que
ocorra
Seus recursos e autoridade não são suficientes para
impedir que o resultado seja impactado
5
Você ficará surpreso
Sua chance para alterar o resultado é praticamente
se o risco não ocorrer zero
Revista PM Network – Out – 2000 pag 61 - 63
Estimativa de custos
• Elementos de custos na vida de um projeto:
• Custos associados às tarefas, como custos do
trabalho e serviços contratados, locomoção,
estadia, refeições
• Custos administrativos que são demandados
pelo projeto tais como: PMO, compras,
secretárias, equipamentos, etc.
Desafios na estimativa de
custos
• Más estimativas técnicas em tempo e custos
• Estimativas realizadas por pessoas inexperientes ou
otimistas
• Mudanças no projeto durante a implementação
– superação de problemas técnicos
– ajuste nas condições mutantes do mercado
– acomodação de mudanças do cliente nas especificações do
produto
• Fatores do ambiente
• Fatores psicológicos
• Fornecimento de um valor baixo para ganhar o contrato
– obtêm-se prejuízo ou longos dias de trabalho sem
compensação financeira para a equipe
• Pressões políticas
Estimativa de duração de
tarefas usando PERT
•
•
•
•
•
•
•
•
•
PERT = Program Evaluation Review Technique
e(t) = otimista + 4 x mais provável + pessimista
6
Melhores práticas:
desenvolva o melhor possível a WBS em work packages
< 40 horas
consulte o histórico de outros projetos anteriores
consulte os especialistas na área
valide as premissas para obter as estimativas
permita work packages > 40 hs somente para atividades
em que não há incertezas. Ex: operação assistida de 30
dias
Qualidade
• Inclui um conjunto de processos exigidos para assegurar
que o projeto satisfará as necessidades para o qual ele
foi criado.
• Deve estar declarado no plano do projeto quais serão os
processos para garantir a qualidade do produto e a
qualidade da condução do projeto
• Exemplo de texto que pode constar no plano de
qualidade do projeto: A fim de garantir a qualidade dos
projetos gerenciados pela nossa companhia, este
projeto será submetido a Revisão (ões) de Garantia da
Qualidade, elaborado pelo nosso Escritório de Projetos,
de acordo com a nossa metodologia. O produto deste
trabalho será sintetizado em relatório.
Comunicação
• Inclui os processos requeridos para garantir a
geração apropriada e oportuna, a coleta, a
distribuição, o armazenamento e o controle
básico das informações do Projeto.
• O Plano de Comunicação, também, identifica o
nível da informação, o formato e a freqüência da
comunicação necessária para todos envolvidos
do Projeto.
Comunicação
•
Formato - Os formatos dos documentos a serem gerados no decorrer do
Projeto deverão atender aos níveis organizacionais, sendo:
– Comitê Executivo: apresentações de avanço do projeto;
– Comitê do Projeto: cronogramas, planilhas e atas de reuniões
•
Frequência - A freqüência da comunicação também está relacionada com
os níveis definidos, onde:
– Comitê Executivo: a cada período de ..... semanas/meses
– Gestão do Projeto: a cada período de...... dias
•
Conteúdo – Especificar o conteúdo de acordo com o destino:
– Comitê Executivo: progressos, necessidades e problemas
– Gestão do Projeto: atas, progressos, cronogramas e comunicados diversos.
•
•
Importante: Todas as Atas devem ser assinadas ou aprovadas
eletrônicamente, por e-mail, pelos Gerentes de Projeto ou seu
representante designado;
As Atas de Reunião deverão estar identificadas com números seqüenciais:
1, 2, 3…
Aquisições (procurement)
• Processo para adquirir bens e serviços de terceiros
• Para projetos de maior complexidade há necessidade de
ter recurso exclusivo para a administração dos contratos
de terceiros
• Um ponto muito importante é que os T&C sejam back to
back com os terceiros:
• - Um contrato T&M com nosso cliente deve ter um T&M
com o terceiro
• Um contrato de escopo fechado com nosso cliente deve
ter o escopo fechado com o terceiro
• Escopo fechado com o cliente e T&M com o terceiro é
uma armadilha que deve ser evitada
Plano de projeto
• O Plano de Projeto é uma série de documentos ou uma
coletânea lógica de documentos compilados pelo
Gerente de Projetos para planejar, controlar, executar e
encerrar um projeto com sucesso.
• Quanto maior e mais complexo for o Projeto, mais
estruturados serão os processos e exigências para
gerenciá-lo.
• O PP é necessário para assegurar que todas as
atividades serão desenvolvidas para satisfação da
expectativa do cliente e que todos os serviços do projeto
atinjam as exigências estabelecidas, bem como os
planos adicionais necessários para o desenvolvimento
da solução e os mecanismos de entrega e aceitação
Plano de projeto
Informações sobre o Documento
Nome do Projeto:
Gerente de Projeto:
<<Nome PM>>
Versão do
Documento:
Fase do Projeto:
Data da
Versão:
Revisão de Qualidade:
Data da
Preparação:
Preparado Por:
Revisado Por:
<<Nome PM>>
Data da
Revisão:
Plano de projeto
Data
Fone/Fax
De
<<Nome PM>>
Para
Ver.
Nº.
1.0
2.0
Ação:
Aprovar /
Revisar
Versão
Data
Revisado
Por
Descrição
Data
Esperada
Fone/Fax
Nome do Arquivo
Plano de projeto
• Aviso de Propriedade do plano de projeto
• Este documento é de propriedade da ABC. As informações
contidas são confidenciais e não devem ser copiadas ou
divulgadas sem antes o consentimento formal, por escrito, da
ABC, podendo somente ser utilizada dentro do (a) <<Nome
Cliente>>, para os seus empregados e terceiros que estejam
envolvidos nas tarefas do projeto, o qual este documento
relata.
• <<Nome Cliente>> será responsável por garantir que todos
seus empregados e terceiros envolvidos estejam de acordo e
acatem estas condições e ainda, está autorizada para usar as
informações contidas neste documento, somente para
propósitos de avaliação e acompanhamento.
Plano de projeto
• Introdução
• O Plano de Projeto é um documento ou uma coletânea
lógica de documentos elaborados pela equipe do projeto
para planejar, executar, controlar e encerrar o projeto
com sucesso.
• O Plano de Projeto incorpora as melhores práticas de
mercado quanto ao gerenciamento de atividades, sendo
estruturado de acordo com a metodologia da ABC,
baseada nas melhores práticas adotadas pelo “PMI –
Project Management Institute ” , dos Estados Unidos,
reconhecido mundialmente como formulador dos mais
altos padrões de qualidade na gestão de projetos e, de
acordo com a ISO 9001 – versão 2000.
Amplitude do Plano de
Projeto
•
•
•
•
•
•
•
•
•
•
Missão e Objetivo do Projeto;
Premissas Gerais;
Declaração de Escopo;
Principais Resultados;
Work Breakdown Structure;
Cronograma do Projeto;
Plano de Recursos;
Plano de “Entregas”;
Plano de Gerenciamento de Mudanças;
Plano de Garantia;
Amplitude do Plano de
Projeto
•
•
•
•
•
•
•
•
•
•
Plano de Comunicação;
Plano de Gerenciamento de Riscos;
Plano de Qualidade;
Plano de Testes;
Plano de Escalação;
Fatores Críticos para o Sucesso do Projeto;
Exclusões;
Glossário;
Anexos; e
Aceitação do Plano de Projeto.
Premissas Gerais
• As seguintes premissas foram consideradas pela ABC
na preparação dos custos, tempo, “Principais
Resultados” e nas estimativas de recursos contidos
neste Documento:
• A XYZ deverá nomear uma equipe de trabalho, com um
gerente do projeto e especialistas previamente
determinados. Esta equipe será responsável pela
facilitação do trabalho da ABC, disponibilização de
informações necessárias e a absorção de
conhecimento.
• A XYZ deverá disponibilizar as informações requeridas
pela ABC no prazo previsto no cronograma, de modo a
não impactar os prazos propostos para o projeto.
Principais resultados:
deliverables do projeto
Deliverable 1:
»
»
»
»
»
»
»
»
»
Nome do deliverable
Descrição do deliverable
Recursos
Atividades
Ferramentas
Responsabilidades da ABC
Responsabilidades da XYZ
Premissas Específicas
Critério de Aceitação
• Deliverable 2:
»
»
»
»
Nome do Deliverable
Descrição do deliverable
.
.
Plano de Gerenciamento de
Mudanças
•
No contexto deste Projeto, “Mudanças” podem ocorrer por diversos
motivos. Os fatores que originam estas “Mudanças” podem ser:
•
•
Mudanças na legislação;
Mudanças solicitadas pela XYZ para incrementar ou reduzir
funcionalidades na solução desenvolvida;
Mudanças solicitadas pela XYZ para responder às necessidades ou
direcionamento de negócios;
Mudanças propostas pela ABC a fim de atender as particularidades
técnicas que podem surgir durante o desenvolvimento do projeto;
Para introduzir/alterar um novo componente (software ou hardware) a
fim de atender as necessidades do negócio.
Estas alterações impactam diretamente no escopo, tempo e qualidade
do Projeto. A fim de estabelecer procedimentos claros e formais, se
faz necessário a criação do processo de Gerenciamento de Mudanças.
•
•
•
•
Plano de Gerenciamento de Mudanças:
Pedido de Mudança.
• É o processo utilizado quando se identifica uma
“Mudança”, a qual necessita de aprovação para ser
executada.
• O Pedido de Mudanças é usado sempre que se
identifica uma “Mudança” e, que pode ser
incorporada ao Projeto.
• O propósito é registrar a totalidade da “Mudança”,
identificar o impacto, tempo, custos, determinar a
melhor alternativa para efetuar a mudança e, obter a
aprovação das partes implicadas previamente, antes
de iniciar qualquer ação associada.
Plano de Gerenciamento de Mudanças:
Processo de uma mudança
• Preenchimento formal do formulário de
pedido de mudança
• Avaliação da mudança solicitada
• Aprovação da mudança
• Implantação da mudança
• Verificação do aceite da mudança
• Registro do processo
Plano de Garantia
• Deverá ser reportado no plano de projeto as
informações sobre a garantia dos serviços ou
produtos desenvolvidos no projeto. Deve constar ao
mínimo as seguintes informações:
–
–
–
–
–
–
Início e encerramento da Garantia de cada deliverable
Cobertura da Garantia de cada deliverable
Processo de solicitção de Garantia
Exclusões de Garantia
Processo de escalação durante o período de garantia
Processo para extensão de Garantia de cada deliverable
Finalização do projeto
Objetivos:
• Diagnosticar o projeto e determinar se ele
deve ser finalizado
• Avaliar a finalização do projeto
• Documentar e registrar as lições
aprendidas
Finalização do projeto:
- Finalização envolve levar o projeto à sua
conclusão de uma forma ordenada
- Com a finalização das tarefas, o trabalho
de maior interesse já foi realizado
- Os membros da equipe podem encontrar
dificuldades em focar na finalização das
tarefas restantes e finalizar o projeto de
forma adequada
Tarefas na finalização:
-
Desalocação dos membros da equipe
Retorno dos recursos materiais
Análise das obrigações contratuais
Avaliação com o cliente se o objetivo do projeto
foi atingido
- Exercício de lições aprendidas
- Preparação para manutenção
- Transição para operação
Avaliação da finalização do
projeto:
- Apresenta um problema fundamental
- Como podemos nos assegurar que as
lições são comunicadas e utilizadas por
outras equipes de trabalho?
- Como podemos conseguir que as lições
aprendidas sejam bem documentadas e
postas em uso?
Finalização prematura:
- Algumas causas de finalização prematura:
-
A avaliação pode demonstrar que o projeto desviou-se
demasiado dos objetivos iniciais
Os objetivos iniciais do projeto podem não ser mais válidos
Recursos podem ter se extinguido ou não serem mais
disponíveis
Morte do “sponsor” do projeto
Fusões de empresas mostram redundância de projetos
Por decisão corporativa ou mudança de direção
Finalização prematura:
- Quando uma decisão é feita em terminar um
projeto, o evento mais perceptível é que toda
atividade na substância do projeto cessa.
- Um grande esforço administrativo ainda
necessita ser realizado.
- Atividades devem ser desenvolvidas para uma
finalização ordenada: revisão de contratos,
liberação de equipe, devolução de materiais,
instalações e equipamentos.
Decisão: go/no-go:
Custos já gastos são vistos como
despesas já realizadas e que por isso são
irrelevantes no processo decisório de
continuidade do projeto
Caso em
Análise
Custo até a presente
data
Custo adicional
estimado para
finalizar o projeto
Benefício Esperado
Tempo 0
0
100.000
200.000
Tempo 1
60.000
80.000
120.000
Tempo 0  BCR = 2,0
Tempo 1  BCR = 1,5
Decisão: Terminar o projeto
BCR = Benefit-cost ratio
Finalização com integração:
-
-
-
Esta é a forma mais comum de finalizar um projeto bem sucedido.
A propriedade, equipamentos, materiais, pessoal e funções do
projeto são distribuídos entre os elementos existentes da
organização.
O produto do projeto passa a ser parte integrante da operação do
cliente.
Em alguns casos o problema de transição para produção é pequeno
em outros casos é grande.
O time de projeto que instalou, desenvolveu e instruiu o cliente na
sua operação e manutenção partiu e uma nova equipe deve realizar
a operação do sistema no dia-a-dia.
Finalização por falta de
recursos:
-
Trata-se de um “slow-down” devido à falta de orçamento suficiente
para dar continuidade ao projeto na velocidade projetada
Projetos de média e longa duração podem sofrer deste problema
conforme cortes no orçamento são realizados
São comuns e frequentemente visam mascarar o fim de um projeto
Razões possíveis para isto:
-
Politicamente perigoso admitir que um projeto falhou. Terminar um
projeto mal sucedido ou obsoleto é admitir a falha. Em tal caso, o
orçamento do projeto recebe um corte – ou uma série de pequenos cortes
– grande o suficiente para impedir avanços no projeto e forçar a alocação
de muitos componentes da equipe em outros projetos.