projeto físico e lógico de rede

Projeto Físico e Lógico de Rede

Professor [email protected]

Um pouco sobre o PMI

PMI - Project Management Institute

PMI

• Instituição internacional sem fins lucrativos criada em 1969

• Desenvolve normas, programas educacionais e certificação profissional

• Visa profissionalizar e expandir o conhecimento na área de Project Management: www.pmi.org

Novos critérios a partir de 24/set/05:

• Total de 200 questões: 25 aleatórias não participam do resultado. Das 175 deve-se acertar pelo menos 143. Acerto de 81,7 %.

• Para ser elegível é pré-requisito informar tarefas que foram lideradas e conduzidas pelo candidato

• Informar contato para que o PMI possa verificar a autenticidade da informação

• No máximo 3 tentativas dentro de 1 ano para obter a certificação PMP. Se não passar, deve aguardar um ano para candidatar-se novamente

Introdução

• - Apenas 16 % terminam no Prazo e dentro do orçamento previstos;

• - 94 % tem pelo menos 1 reinício• - Os projetos excedem em até 188 % os Custos

previstos• - Os projetos excedem em até 222 % o

cronograma original• - Apenas 16 % são concluídos com o Escopo

original

É importante saber que: Fonte Standish Group “Chaos Report”

• Em projetos de sistemas de informação:– De 30 % a 45 % dos projetos falham antes

de seu final previsto– Acima de 50 % dos Projetos superam o

orçamento inicial e seu cronograma– Estes custos estão estimados como sendo

acima de US$ 100 bilhões por ano

É importante saber que: Dados estatísticos “ComputerWorld Magazine”

• Causas que conduzem a esta situação:– Falta de um “project office” – 42 %– Métodos integrados de gestão – 41 %– Treinamento e coaching – 38 %– Procedimentos e Políticas Organizacionais –

35 %– Planos de Implementação – 23 %– Suporte Executivo – 22 %

É importante saber que: Dados estatísticos “ComputerWorld Magazine”

• - A área de TI não possui metas tão claras quanto as de outras áreas

• - A complexidade é maior do que inicialmente analisado

• - O Escopo dos projetos de TI não possuem limites bem definidos

• - Aumento de riscos de TI com a utilização de tecnologias novas e pouco conhecidas

Os projetos da área de TI:

• - A falta de domínio pela alta direção leva a falsas expectativas e consequente impacto nos projetos

• - Projetos de TI geram dependência entre outros projetos em andamento

• - A falta de conhecimento pela equipe que está implementando o projeto, do impacto do projeto na empresa

Os projetos da área de TI:

• US$ 10 trilhões são investidos anualmente no mundo em Projetos, o que equivale a 25 % do PIB mundial

• 16,5 milhões de profissionais estão diretamente envolvidos com a gestão de projetos no mundo.

Estimativas do PMI:

Objetivo do módulo de gerenciamento de projetos

• Desenvolver os conceitos básicos de gerência de projetos, em termos de melhores práticas, para que os participantes do treinamento possam entender e ter conhecimentos de forma a poder gerenciar um projeto

• Introdução • Iniciação• Planejamento • Execução e Controle• Finalização

Fundamentos em gerência de projetos

O que é um Projeto?

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

Introdução

• TI:– Segurança em TI– Aumento da capacidade de processamento– Mudança de aplicações– Implantação de aplicações– Desenvolvimento de uma aplicação

• P&D:– Desenvolvimento de novos produtos / serviços– Inovação nas diversas áreas de conhecimento

• Construção:– Expansão de uma indústria– Implantação de uma refinaria– Construção de estrada, etc.

Tipos de projeto:

• Mudança Administrativa:– Alteração de processos– Mudança cultural

• Marketing:– Lançamento de novos produtos

• Qualidade:– Projetos de melhoria em processos

Tipos de projeto:

• Hardware x Software• Longa duração x Curta duração• Baixo risco x Alto risco• Pequenos projetos x Grandes

projetos• Projetos simples x Projetos

complexos• Um único projeto x Múltiplos projetos

Algumas variações em projetos:

? ? ?? ??

O que é gerenciamento de projetos?

• 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

Definição do PMBOK

Qualidade

Custo

Tempo

O trinômio do gerenciamento de projetos

Governo Fornecedores

Usuários externos

Sub contratados

A EMPRESAObjetivos organizacionais

Diretoria Patrocinadores GerenteGerente do projeto

Equipe do projeto ColegasGerentes controlando recursos internos

Usuários internos

O meio em que ocorre um projeto

• - Altamente burocrático• - Não são focados em objetivos de lucratividade- Difícil de medir a produtividade- Operação afetada pela política- Auditoria constante- Rotação constante de equipe- Projetos de vários anos- Poucos incentivos à realização de um bom

trabalho- Ambiente de aquário

Um projeto no governo

• Em projetos, os gerentes de projeto tem controle direto sobre poucas coisas, no entanto sua habilidade em influenciar os outros – ser um bom político – é muito importante e pode definir o sucesso de um projeto

Política em gerenciamento de projetos

- Um projeto é um empreendimento único direcionado para o atendimento de um resultado; é temporário, com um início e fim

- Gerenciamento de projetos é o processo de obter a realização do projeto de uma forma bem sucedida

- O trinômio limitante que afeta o sucesso de um projeto é: custo, prazo e qualidade

- As fases principais do gerenciamento de projetos são: iniciação, planejamento, execução, controle e finalização

- O meio de um projeto envolve uma faixa larga de contribuintes, tais como, clientes, sub contratados e pessoal organizacional

- Gerentes de projeto devem conhecer o efeito que a política exerce sobre seus projetos

Mensagens

Áreas de conhecimento do PMBOK

- Escopo- Prazo- Qualidade- Custo- Comunicação- Riscos- Aquisições- Recursos Humanos- Integração


- 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


- 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

- 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



- 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

- 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



- 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


- 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


- 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


- 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

Atividades nas fases do ciclo de vida do projeto

- Fase de iniciação:- Obtenção de dados- Identificação das necessidades e

alternativas- Estabelecer objetivos, riscos, viabilidade,

estratégias- Estimar recursos- Desenvolver o “ project charter”- Apresentar a proposta

- Fase de Planejamento:- Desenvolver o escopo do projeto- Definir equipe a ser alocada- Desenvolver wbs- Estabelecer orçamento- Avaliar os riscos- Obter aprovação para prosseguir- Apresentar a proposta


- Fase de Execução e Controle:- Controlar e monitorar o escopo,

prazo, custo, qualidade, comunicação, recursos humanos e aquisições

- Analisar periodicamente os riscos- Controlar as mudanças de escopo,

custo, qualidades, recursos humanos e aquisições


- Fase de Finalização:- Obter a aceitação do projeto- Documentar e avaliar os resultados

mediante “lessons learned”- Transferir as responsabilidades- Desmobililizar os recursos


Nível de atividade

Tempo

início

Execução e controle

fechamento

planemanento


Superposição de processos

Iniciação do projeto

Iniciação do projeto

- Processo de reconhecimento formal da existência de um novo projeto em função de:

- Requisitos legais- Demanda de mercado- Necessidade do negócio- Solicitação do cliente- Mudança de tecnologia- Fusão de empresas - Fusão de departamentos- Outros

- São os indivíduos ou organizações ativamente envolvidos com o projeto cujos interesses podem ser positiva ou negativamente impactados como resultado da execução ou conclusão do projeto, ou ainda impactar o mesmo.

- Sponsors – patrocinadores –- Investidores, diretores, supervisores de alta gerência, clientes

(internos ou externos)- Participantes

- Equipe participante em alguma fase do projeto, fornecedores, agências reguladoras, especialistas

- Externos- Familiares dos participantes do projeto, ambientalistas, líderes de

comunidades, mídia, sindicatos, órgãos de classe

Iniciação do projeto Stakeholders do projeto

- É quem garante o patrocínio financeiro do projeto e tem interesses no seu desenvolvimento.

- Nomeia um responsável pelo projeto que aceita formalmente o produto do projeto durante as fases de verificação dos entregáveis e no seu encerramento.

Iniciação do projeto O patrocinador – sponsor – do projeto

- É o indivíduo nomeado formalmente para gerenciar o projeto.

- Será o responsável pela gestão do projeto- Responsável pelo sucesso ou fracasso do

projeto- Não é mandatório que tenha um domínio das

questões técnicas do projeto- O nível de autoridade irá depender da

estrutura organizacional da empresa

Iniciação do projeto O gerente do projeto

- Liderança- Habilidade de incentivar e influenciar os membros

da equipe e os stakeholders a agirem em uma determinada direção para poder alcançar os objetivos estabelecidos

- Comunicação- Habilidade de comunicar-se formal e

informalmente, realizar apresentações, redigir atas de reunião, relatórios de questão, controle de mudanças, transformar informações em mensagens, aumentar a satisfação da equipe

Iniciação do projeto Habilidades gerenciais do gerente do projeto

- Negociação- Habilidade em perceber mudanças ou tendências no projeto

que necessitam que uma negociação seja iniciada. Ter a habilidade de buscar argumentos e obter sucesso nas negociações em que se envolve.

- Resolução de problemas- Habilidade de análise de problemas e busca de alternativas

na sua solução- Influência na organização

- Habilidade em entender as estruturas formais e informais envolvidas. Entendimento dos mecanismos de poder e política (positivos e negativos). Utilizar os diferentes interesses para o benefício do projto

Iniciação do projeto Habilidades gerenciais do gerente do projeto

- É o comitê de patrocinadores ou conselho do projeto constituído para o recebimento de comunicação da evolução do projeto e para a análise e solução de questões que ultrapassam a alçada da equipe do projeto.

- É um grupo decisório e deliberativo.

Iniciação do Projeto Comitê de direção do projeto

- É 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 projetoProject Charter

Os clientes sabem o que não precisam após ver o produto

- Mesmo quando os clientes dizem que sabem exatamente o que precisam, eles provavelmente não sabem

- Conforme vai-se desenvolvendo o produto que toma uma forma tangível, os clientes vêem novas possibilidades e tentam mudar o projeto de acordo com esta nova visão

- Devemos levar os clientes a sério – um projeto falha se o deliverable não é utilizado, é sub-utilizado ou mal utilizado pelo cliente

Iniciação do projeto Clientes sabem o que querem?

- 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 Reconhecendo as necessidades do cliente

- 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

Iniciação do projeto Especificações do projeto

- Especificações incorretas baseadas em necessidades mal definidas- Endereçam necessidades do cliente errado- Falha na enunciação clara das necessidades

- Especificações imprecisas ou ambíguas- Problemas relacionados com a linguagem- Imprecisão deliberada para permitir flexibilidade- Conflito que impede o consenso- Falta de conhecimento do cliente- Omissão de planejamento

- Especificações em constante mudança- Planejamento pobre- Cliente inconstante – muda de opinião- Projeto de natureza dinâmica

Iniciação do projeto Armadilhas das especificações do projeto

Controle e execução do projeto

- 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

Objetivos

• Aumento da capacidade de contribuição individual dos membros, assim como o aumento da capacidade para funcionar como equipe de alta performance voltada à execução das tarefas do projeto

Desenvolvimento da equipe

- Um plano de comunicação da equipe e um para a comunidade do projeto

- Feedback contínuo sobre o desempenho individual e coletivo

- Criação de uma atmosfera de colaboração e confiança no processo e no atingimento dos resultados

Fatores chave de sucesso da equipe

Fatores chave de sucesso da equipe:

- O GP deve ser um facilitador para o alto rendimento da equipe. É necessário:

- Ser um comunicador eficaz- Permitir um ambiente estável de trabalho, filtrando todo

nervosismo que ocorre na direção do projeto- Evitar bloqueios de comunicação- Obter recursos que permitam o atingimento de uma alta

performance da equipe: ex: war room- Fazer reuniões eficazes.

Fatores chave de sucesso da equipe:

- A equipe escolhida decide o sucesso do projeto:- O sucesso do projeto é baseado na qualidade

da equipe- Compromisso da equipe em realizar as tarefas

do projeto é essencial- GP lidam com um problema fundamental: a

equipe do projeto é “emprestada” das estruturas funcionais da empresa

Final do projeto. Desfazendo a equipe do projeto. A Produtividade é Oscilante e a Moral também é Oscilante.

REFORMINGDesformando

Não há questões e a equipe se encontra em alta performance. A Produtiviade é Alta e a Moral é Alta

PERFORMINGDesempenho

Os compromissos e funções estão definidos. A Produtividade é Alta e a Moral é Alta

NORMINGNormal

Fase onde há os conflitos iniciais, busca de consenso e de controle da equipe. A Produtividade é baixa e a Moral é Baixa

STORMINGConflito

Estado inicial onde os membros buscam entendimento, inclusão e procuram sua função. A Produtividade é baixa e a Moral é média

FORMINGFormando

Fases de progresso da equipe:

• Questões a discutir:• Em que formas as equipes de projeto são

semelhantes ou diferentes das equipes de esportes: futebol, basquete, etc?

• O que podemos fazer para aumentar o compromisso dos membros emprestados de outras áreas da companhia?

Importância da equipe

Comunicação entre pessoas:

MeioLinguagemExperiênciaEducação

CulturaCrençasReligião

Percepção

EMISSOR RECEPTOR

2 pessoas, 1 canal

4 pessoas, 6 canais

3 pessoas, 3 canais

5 pessoas, 10 canais

Tamanho da equipe e canais de comunicação:

Como uma equipe de projeto se parece?

• Ex 1: construindo um grande edifício:– Equipes muito grandes e muitas funções diferentes– Equipes são sub contratadas– A tarefa do GP é coordenar as atividades dos membros da equipe

• Ex 2: desenvolvendo e implementando uma aplicação de SW:– Equipes de tamanho menor e poucas funções– Equipes são sub contratadas ou próprias– O GP pode ser um membro ativo envolvido em atividades de

código ou análise

Equipes: sucesso e fracasso

• Os projetos falham frequentemente devido a falhas humanas – muito raramente os projetos falham devido à quebra de um sistema de controle

• Da mesma forma: os projetos atingem o sucesso porque estão ligados à persistência e dedicação humana no atingimento dos resultados esperados do projeto

• A maior preocupação do gerente de projetos deve ser com as PESSOAS. Elas em equipe é que garantem o sucesso.

Pirâmide deAbraham Harold Maslow

Necessidades fisiológicas. As mais importantes são a necessidade de alimentos e elementos que permitamsua sobrevivência

Sobrevivência

A necessidade de sentir-se seguro do perigo, ameaças e privações

Segurança

A necessidade de associar-se com outras pessoas, ter amigos e vida amorosa

Aceitação Social

A necessidade de auto estima e apreço pelos colegas; status

Auto Estima

A necessidade de desenvolvimento de habilidades e ter oportunidade de usar sua criatividade

Auto Realização

Características de um bom GP• Habilidade de entender o comportamento das pessoas• Detalhista• Forte compromisso com o projeto• Hábil em lidar com ambigüidade, contrariedades e desapontamentos• Ciente dos objetivos da organização• Orientado a resultados• Consciente dos custos • Astuto politicamente – sabe como influenciar os demais• Boas habilidades de negociação• Competente

• Nota: O GP não é necessariamente a pessoa mais inteligente ou com maior conhecimento técnico da equipe do projeto

• Fonte: J.Davidson Frame – Managing Projects in Organizations – How to make the best use of time, techniques, and people

Autoridade de um GP• Algumas formas mais comuns de autoridade:• Formal – cargo na empresa• Técnica - expert• Carismática - personalidade• “Purse string” – autoridade baseada no controle

dos recursos monetários do projeto• Burocrática – conhece os processos da

empresa• Recompensa – pode recompensar alguém e

com isso obtêm-se reconhecimento• Punição – pode produzir punição

Estilos de um GP

• Cada abordagem tem seus prós e seus contras – um gerente de projetos eficaz utiliza elementos de cada estilo de acordo com as circunstâncias

• Autocrático – também chamado ditatorial• Laissez-faire – também chamado hands off• Democrático – também chamado participativo

Gerenciamento Autocrático

• Prós:– Pode ser eficaz quando há necessidade de tomar

decisões com agilidade– Pode ser eficaz quando os projetos são

altamente rotineiros

• Contra:– Fatores insuficientes podem ser tomados em

consideração quando as escolhas são feitas– Pode conduzir a decisões arbitrárias– Pode desmoralizar a equipe se os membros não

puderem participar da tomada de decisões

Gerenciamento Laissez-faire • laissez-faire. Doutrina defendida principalmente por Adam Smith, e

que teve origem na França e na Grã-Bretanha, segundo a qual os produtores diziam ao governo laissez-nous faire, isto é, deixe-nos agir, o que implicava a não interferência governamental. De acordo com a doutrina, o governo deve limitar-se à manutenção da ordem e da lei, removendo todas as barreiras por ele impostas ao comércio e aos preços. Essa diretriz permite maior liberdade individual, melhor uso dos recursos e crescimento econômico. A responsabilidade do governo seria principalmente a de controlar as condições de concorrência, a oferta de moeda e certas atividades da previdência social (social security).

• Fonte: Dicionário Michaelis

Gerenciamento Laissez-faire• Prós:

– Pode ser eficaz em projetos de tecnologia de ponta– Pode conduzir a um nível alto de moral entre os membros

mais criativos que não gostam de supervisão constante

• Contra:– Pode conduzir à síndrome de navio à deriva– Pode reduzir a moral se houver a sensação de ausência de

objetivo– Pode ser desastroso em situações onde decisões rápidas

necessitam ser tomadas

Gerenciamento Democrático• Prós:

– É uma maneira eficaz de obter consenso– Permite considerar uma variedade de pontos de vista– Pode resultar em alta moral se os membros sentirem que

seus pontos de vista são levados em consideração

• Contra:– Pode conduzir à tirania da maioria– Pode não ser eficaz quando houver necessidade de serem

tomadas decisões rápidas– Pode não ser eficaz se a votação contemplar os votadores

errados

Mensagens chave• A formação da equipe do projeto é uma função importante do

gerente de projeto• Uma equipe mal formada aumenta a probabilidade de

insucesso no projeto• Os links de comunicação crescem exponencialmente com o

crescimento da equipe• O gerente de projeto deve entender a dimensão humana de

gerenciar uma equipe• Isto implica em aplicar teorias de motivação e entendimento da

dinâmica dos diferentes estilos de gerenciamento• Gerentes de projeto vivem em um meio de contradições: eles

são responsáveis pelo sucesso do projeto mas tem pouca autoridade sobre a equipe

• Um bom gerente de projetos deve utilizar uma variedade de habilidades, conhecimento, e talentos para gerenciar o projeto de forma bem sucedida

Conflitos em projetos

• Qual técnica utilizar:

- Retirada estratégica- Panos Quentes- Negociação- Colaboração- Força

Quanto utilizar a Retirada Estratégica:

• Quando não se pode vencer a disputa• Para ganhar tempo para analisar a

questão• Para preservar a neutralidade ou a

reputação• Decisão de nível superior

Quanto utilizar a Panos Quentes:

• Para atingir um objetivo extremamente difícil

• Para manter a harmonia• Quando vai-se perder de qualquer jeito

Quanto utilizar a Negociação:

• Quando as duas partes precisam vencer

• Quando não se tem a certeza de estar com a razão

• Quando há interesses opostos em disputa

Quanto utilizar a Colaboração:

• Quando as habilidades se complementam

• Quando há confiança na capacidade técnica do outro

• Para reduzir custos

Quanto utilizar a Força:

• Na presença de altos riscos• Em situações de urgência• Em situações de “ou ele ou eu”• Quando estamos seguros que temos

razão

Medida de progresso:

• Variância = Planejado – Real• Não há porque perguntar se houve

variância no mês. A resposta é sempre: sim

• A pergunta correta é: A variância deste mês está dentro de uma faixa aceitável?

Projetos que demandam variância zero:

• Não são executáveis• Irão falsear o plano• Vão encorajar cortes de atividades

necessárias

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

• Alguns termos utilizados:• BCWS – budgeted cost of work scheduled = custo

planejado• ACWP – actual cost of work performed = custo real• BCWP – budgeted cost of work performed = earned

value

• Interpretação de BCWP: Uma tarefa X que estava planejada para terminar hoje e com custo planejado de $100. Estou com 75% realizado desta tarefa. Portanto eu fiz $75 em valor do trabalho, o qual é considerado o BCWP – earned value

Earned Value

Indicadores:

• CV = Cost variance• CV = BCWP – ACWP• Interpretação: Completei $75 em valor do

trabalho (BCWP), mas na realidade me custou $95 para fazer o trabalho (ACWP). Custou-me $20 a mais que eu havia inicialmente planejado (CV) para fazer o que fiz.

Indicadores:• SV = Schedule variance• SV = BCWP – BCWS• Interpretação: Hoje deveria ter terminado a

tarefa cujo valor é $100 (BCWS). Na realidade completei somente $75 em valor da tarefa (BCWP). Então estou atrasado no cronograma em $25 (SV)

• Nota: Ambos “cost e schedule” variância são informados em valores monetários: Reais ou Dólares.

Indicadores:

• Cost performance index CPI = BCWP/ACWP• Interpretação: Completei $75 em valor de

trabalho (BCWP) que me custou $95 (ACWP). Para cada unidade monetária gasta foi gerado 0,79 em valor de trabalho (cost performance index)

• Ou seja: CPI > 1 estou gastando menos do que o planejado e CPI < 1 estou gastando mais do que o planejado para execução da tarefa

Indicadores:

• Schedule performance index SPI = BCWP/BCWS

• Interpretação: Completei $75 em valor de trabalho (BCWP) que estava planejado em $100 (BCWS). Assim o SPI resulta em 0,75

• Ou seja: SPI > 1 estou adiantado nas tarefas e SPI < 1 estou atrasado nas tarefas

Indicadores:

• A técnica de Earned Value é considerada pelo PMI Performance College o estado da arte em medição de desempenho de projetos. Entretanto, observa-se que essa técnica ainda é pouco utilizada na prática no Brasil. Apesar de sua excelência.

Projetando o custo e cronograma:

• BAC = budget at completion = quanto é o orçamento do projeto no total?

• ETC = Estimated to complete = Com as informações disponíveis quanto mais custará para completar o projeto?

• EAC = Estimated at completion = Dado o que sabemos hoje, quanto custará o projeto no total?

Controle de Projetos• Planejado = BAC ou BCWS• Custo Real = ACWP• Earned Value = BCWP• CV = Cost Variance ou Variância de Custo• SV = Schedule Variance ou Variância de Cronograma• CPI = Cost Performance Index ou Indicador de Custo• SPI = Schedule Performance Index ou Indicador de Cronograma• BAC = budget at completion = quanto é o orçamento do projeto no

total?• EAC = Estimated at completion = Dado o que sabemos hoje,

quanto custará o projeto no total?• ETC = Estimated to complete = Com as informações disponíveis

quanto mais custará para completar o projeto?

Cálculos• Actual = ACWP = EAC - (BAC - BCWP)• EAC = (BAC - BCWP) + ACWP• CV = BCWP – ACWP• CPI = BCWP / ACWP• SPI = BCWP / BCWS• SV = BCWP - BCWS

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

Exercício:

- Para o seu projeto que está em andamento ou para algum projeto que já participou, desenvolva um deliverable com os seguintes tópicos:

- Descrição do deliverable- 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- Responsabilidade 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

Exercício:

• Crie o WBS para um deliverable do projeto que está envolvido ou de um projeto que já executou ou está executando na sua empresa.

• Procure seguir o modelo do slide anterior

O Linha de Base ou Baseline do projeto

Cronograma Inicial

Cronograma Final

Baseline do projeto

Nivelamento dos recursos

• 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

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 (seguro, contrato, garantias)– Evitar – Aceitar (fundos de contingência)– 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.

Produto do projeto não tem utilidade para o cliente

Redução inaceitável para o cliente

Redução requer aprovação do cliente

SomenteDegradação imperceptível

Qualidade

Produto do projeto não tem utilidade para o cliente

Redução de funcionalidades inaceitável para o cliente

Áreas importantes são afetadas

Diminuição em áreas de menor relevância

Decréscimo imperceptível

Funcionalidades

> 20 % de atraso

10 – 20 % de atraso

5 – 10 % de atraso

< 5% de atraso

Atraso insignificante

Cronograma

> 20 % aumento de custos

10 – 20 % aumento de custos

5 – 10 % aumento de custos

< 5% o aumento de custos

Insignificante aumento de custos

Custo

5Muito alto

4Alto

3Médio

2 Baixo

1 Muito baixo

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

Sua chance para alterar o resultado é praticamente zeroVocê ficará surpreso se o risco não ocorrer

5

Seus recursos e autoridade não são suficientes para impedir que o resultado seja impactado

Mais provável que ocorra

4

Tempo e esforço adicional deverá ser empregado para que o resultado seja aceitável

Igual chance de ocorrer ou não

3

Uma supervisão adicional no processo de gerenciamento provavelmente trará um resultado aceitável

Mais provável que não ocorra

2

O processo normal de gerência facilmente assegurará um resultado aceitável

Você ficará surpreso se ocorrer

1

Dificuldade de intervençãoProbabilidade de ocorrência

Nível

Revista PM Network – Out – 2000 pag 61 - 63

Exercício• Para o projeto que está desenvolvendo ou para o projeto que está

alocado na sua empresa, desenvolva uma lista de 5 riscos.

– Identifique os riscos– Identifique a causa dos riscos– Identifique o Impacto: Muito baixo, Baixo, Médio, Alto ou Muito Alto– Identifique o valor do risco – custo total do evento -– Identifique a probabilidade do risco em % – Calcule o custo da resposta: valor x probabilidade– Identifique a resposta ao risco– Identifique o responsável pela resposta

– Usualmente: Impacto baixo = 3%, médio = 8%, Alto = 15%

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

PertID T a s k N a me

1 IT S M - F A S E 1 A2 In íc io d o P ro je to3 G e re n c ia me n to d o P ro je to4 P la n o d e P ro je to5 E d iç ã o d o p la n o d e p ro je to6 R e v is ã o d o p la n o p e lo c lie n te7 E d iç ã o fin a l d o p la n o d e p ro je to8 A c e ite d o p la n o d e p ro je to9 C o n tro le

1 0 C o n tro le d o P M1 8 P ro c e s s o s IT IL1 9 R e v is ã o d a G e s tã o d e In c id e n te s e d e fin iç ã o d o C MD B b á s ic o2 0 D o c u me n to d e s c ritiv o d o P ro c e s s o L ó g ic o2 1 E la b o ra r u m p la n o d e e n tre v is ta s p a ra a té 5 p e s s o a s2 2 Id e n tific a r a té 0 5 p ro fis s io n a is a s e re m e n tre v is ta d o s2 3 R e a liz a r a s e n tre v is ta s2 4 P la n e ja r w o rk s h o p2 5 R e a liz a r w o rk s h o p2 6 D e fin ir g a p s e n e c e s s id a d e s e s p e c ífic a s2 7 D e fin ir a s p o lític a s2 8 D e s e n h a r o flu x o d o p ro c e s s o ló g ic o2 9 D e fin ir o s p a p é is , re s p o n s a b ilid a d e s e mé tric a s3 0 D e fin ir C MD B B á s ic o3 1 E n tre g a r d o c u me n to p a ra v a lid a ç ã o3 2 R e a liz a r re u n iã o d e re v is ã o d o p ro c e s s o ló g ic o fin a l3 3 D e s e n h a r p ro c e s s o ló g ic o fin a l3 4 A c e ite mo d e lo lo g ic o e C M D B b a s ic o

2 4 A p r '0 50 1 Ma y '0 50 8 M a y '0 51 5 M a y '0 52 2 M a y '0 52 9 Ma y '0 50 5 J u n '0 51 2 J u n '0 5

Estimativa bottom-up

ID Re s o u rc e Na me Wo rk

Group: ITSM 8 2 0 hrsTe x t3 0 : G7 6 9 6 hrs

2 Arq u ite to d e So lu ç ã o 4 0 h rsPla n o d e Pro je to 4 0 h rs

3 Cons ultor ITIL 6 5 6 hrsDo c u me n to d e s c ritiv o d o Pro c es s o Ló g ic o In c ide n te s 20 0 h rsWo rk s h o p d e Tra n s fe rê n c ia d e Tec no lo g ia (In c ide n te s , Pro b le ma s e Mu d a n ç a s )9 6 h rsDo c u me n to d e s c ritiv o d o Pro c es s o Ló g ic o Pro b le ma s 12 0 h rsDo c u me n to d e s c ritiv o d o Pro c es s o Ló g ic o Mu da nç as 12 0 h rsMa n a g e me n t o f Ch a n g e 12 0 h rs

Te x t3 0 : G8 1 2 4 hrs1 Ge re n te d e Pro je to 1 2 4 h rs

Pla n o d e Pro je to 4 0 h rsCo n tro le d o PM 1 1 2 h rsCo n tro le d o PM 2 1 2 h rsCo n tro le d o PM 3 1 2 h rsCo n tro le d o PM 4 1 2 h rsCo n tro le d o PM 5 1 2 h rsCo n tro le d o PM 6 1 2 h rsCo n tro le d o PM 7 1 2 h rs

De ta ils

Wo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rkWo rk

T F S S1 4 Se p '0 3 2 1 Se p '0 3

• Crie uma WBS detalhada e completa• Determine a estimativa de custo para cada elemento do

nível mais baixo da WBS: work packages. Ex: MS Project – visão: resource usage

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

Revisado Por:

Data da Revisão:

<<Nome PM>>Preparado Por:

Data da Preparação:

Revisão de Qualidade:

Data da Versão:

Fase do Projeto:

Versão do Documento:

<<Nome PM>>Gerente de Projeto:Nome do Projeto:

<<Nome PM>>

Fone/FaxDataDe

Fone/FaxData Esperada

Ação: Aprovar / Revisar

Para

2.0

1.0

Nome do ArquivoDescriçãoRevisado Por

VersãoDataVer.

Nº.

Plano de projeto

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.

Exemplo de Objetivo do projeto:

• O projeto consiste na realização de uma análise de impacto considerando os processos de negócios da empresa XYZ e os seus sistemas aplicativos, e a partir desses, estabelecer as alternativas de solução para a estratégia de recuperação de TI.

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

Fatores críticos para o sucesso do projeto

Deverá constar quais são os fatores críticos para o sucesso do projeto. Exemplo:

– Apoio formal da alta gerência da XYZ – Comprometimento de todos envolvidos no Projeto;– Os recursos de pessoal da XYZ envolvidos com o

Projeto, devem estar disponíveis para prover informações quando solicitados;

– Cumprimento dos prazos acordados com a XYZ;– Agilidade nas decisões;– Agilidade no processo de homologações dos

“Principais Resultados” pela XYZ.

Reuniões de Kickoff (direção, equipe, participantes)

• Objetivos

– O “sponsor” deve estar presente para demonstrar o compromisso da alta direção com o projeto e identificar o benefício esperado que a empresa deseja conseguir

– Obter apoio da direção da empresa no projeto– Apresentar o projeto aos stakeholders– Milestones principais devem ser apresentados– Identificação das equipes do projeto com definição

de papéis e responsabilidades

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

Finalização do projeto:

- 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

Tarefas na finalização:

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

Avaliação da finalização do projeto:

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

Finalização prematura:

• 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

Decisão: go/no-go:

120.00080.00060.000Tempo 1

200.000100.0000Tempo 0

Benefício EsperadoCusto adicional estimado para finalizar o projeto

Custo até a presente data

Caso em Análise

Tempo 0 BCR = 2,0

Tempo 1 BCR = 1,5

Decisão: Terminar o projeto

BCR = Benefit-cost ratio

- 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 com integração:

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

Finalização por falta de recursos:

- Finalização de um projeto é um processo e requer trabalho- Projetos podem ser prematuramente finalizados devido a:

- Falta de recursos- Objetivos não são mais válidos- Projeto desviou-se demasiado do seu objetivo inicial- Falhas graves no planejamento- Falhas graves na execução e controle

- No fechamento administrativo, o projeto deve ser avaliado e as lições aprendidas documentas formalmente para servir de uma base de informações para projetos semelhantes

Pontos a refletir:

projeto físico e lógico de rede

Documents