Termo de abertura do projeto

DICAS PARA A ELABORAÇÃO DE TERMOS DE ABERTURA DE PROJETOS

22/122011Carlos Sérgio Mota Silva, PMP – Diretor da P4Pro ConsultoriaHá uma unanimidade sobre a importância dos Termos de Abertura na iniciação dos projetos, como forma de sintetizar os objetivos do projeto, estabelecer as expectativas e designar o Gerente de Projetos e o Patrocinador. Há, entretanto, muita confusão na hora de elaborá-los, pois, nem sempre os conceitos envolvidos são claramente compreendidos. Nesse artigo, buscaremos dar algumas dicas com base na vivência prática, que podem ser úteis para os profissionais da área.Quando envolvidos em um novo e desafiador projeto, a elaboração do Termo de Abertura é a primeira atividade na qual podemos contribuir: mesmo sendo da competência do Patrocinador, que é quem assina o Termo, é muito comum que nós, Gerentes de Projetos, sejamos chamados a participar na sua elaboração.Teoricamente o Termo de Abertura é atribuição do patrocinador, e nele o gerente de projetos deveria ser nomeado. Entretanto a realidade aponta para um cenário bem diferente: nós, Gerentes de Projetos, somos comumente chamados para participar da elaboração do termo mesmo em suas versões iniciais, o que não é de todo mal.Nesse momento, em boa parte das metodologias implantadas, precisamos elaborar um documento que sintetiza a visão do projeto, contendo, total ou parcialmente, as seguintes sessões:Justificativa;Objetivos;Requisitos (visão inicial);Riscos (visão inicial);Cronograma de Marcos;Orçamento resumido;Designação do Gerente de Projetos e do Patrocinador;Premissas e Restrições.Vejamos em maior nível de detalhes, as dificuldades mais comuns e as dicas para a composição de cada uma delas:

A) JUSTIFICATIVA OU COMO CHEGUEI ATÉ AQUI

A justificativa para o projeto deve ser, em linhas gerais, a sequência de fatos, conclusões e opiniões que resultaram no projeto ser escolhido como um dos focos da atenção (e dos investimentos) da organização.Um dos erros mais comuns é a confusão entre a Justificativa e os Objetivos do Projeto. A dica aqui é considerar que as Justificativas devem servir para responder à questão por que estou fazendo esse projeto ?, enquanto os Objetivos explicam o que projeto irá entregar.É comum que, antes de chegar ao Termo de Abertura, o projeto já tenha sido discutido em outros momentos e haja registros que possam ser aproveitados na Justificativa. Assim, para evitar retrabalhos, procure verificar se:O projeto foi resultado do Planejamento Estratégico e há registros dos critérios pelos quais ele foi escolhido;Existe um Plano de Negócios, elaborado previamente, que contém argumentos em prol do projeto;Existem atas de reuniões anteriores, onde o projeto foi discutido e defendido pelo Patrocinador;Existem resoluções (normas internas ou externas) que obrigam ou incentivam a realização do projeto.Caso algum ou alguns desses documentos existam, há uma boa chance de que seu conteúdo possa ser aproveitado por você.Se esse não for o caso, converse com o Patrocinador e busque obter dele os motivadores do projeto, as crenças relacionadas a ele e as diversas opiniões existentes. Uma compilação dessas informações deverá ser suficiente para a captura das Justificativas.

B) OBJETIVOS OU ONDE QUERO CHEGAR

Os Objetivos de um projeto devem traduzir sinteticamente os produtos que o projeto irá gerar para a Organização. Recomendo geralmente que seja feito um esforço para imaginar um momento futuro, em que o projeto tenha sido concluído, e então destacar o que foi realizado.Outra dica importante é fazer um paralelo entre os objetivos a serem expressos no Termo de Abertura é o primeiro nível da EAP (considerando que o nível 1 representa produtos e não fases). Se interessar, veja também as dicas para a elaboração de EAPs em dois artigos publicados anteriormente:http://www.p4pro.com.br/conteudo/dicasEAPehttp://www.p4pro.com.br/conteudo/polemicas.Observação: alguém pode dizer que, na visão estrita do padrão PMBOK, só teríamos a EAP em um momento posterior, mas, lembre-se: o planejamento é uma atividade cíclica e nada impede de termos uma versão inicial da EAP, mesmo quando ainda estamos elaborando o Termo de Abertura.Assim, considerando um projeto hipotético de Implantação de uma Nova Escola, poderíamos ter os seguintes Objetivos:Construção de Infraestrutura de ensino;Construção de Infraestrutura de esportesEspaço de convivência para alimentação e lazer;Construção de infraestrutura administrativa, contemplando sala da diretoria, sala de secretaria e sala de reuniões;Contratação de funcionários e professores;Estabelecimento das rotinas de funcionamento.Vejamos como seria o nível 1 da EAP desse projeto:Primeiro Nível da EAP e sua Correlação com os Objetivos do ProjetoNotem que existe uma correlação direta entre os objetivos e esse nível da EAP – mesmo que possam existir diferenças na nomenclatura, pois os termos da EAP devem ser bem resumidos e diretos. A qualquer um que contemple um ou outro, fica claro o que está sendo proposto e o que deve ser entregue pelo projeto. Essa objetividade permite à equipe entender exatamente onde se quer chegar e possibilita as críticas sobre a corretude e/ou completude do projeto (será que não falta alguma coisa ? Isso fica como exercício ...).Nesse ponto, gostaria de discorrer sobre algumas das confusões mais comuns na elaboração desse tópico:Não confunda os Objetivos do Projeto com os Objetivos Estratégicos da Organização: no projeto acima, alguém poderia ser tentado a inserir Objetivos como melhorar a educação do município (caso de ser uma escola governamental) ou, indo ainda mais longe, Atingir a Melhor nota na Avaliação do ENEM. Esses Objetivos poderiam bem fazer parte de um Plano Estratégico para a Organização, mas não ajudariam se fossem registrados como Objetivos do Projeto, pois não são verificáveis no tempo de vida do projeto e desviam a atenção do que realmente o projeto propõe entregar. Assim, com o perdão do trocadilho, no estabelecimento dos Objetivos do Projeto, seja objetivo !Busque não pecar pelo excesso nem pela falta: o dia-a-dia do funcionamento da escola não deve fazer parte do projeto (poderia sim, fazer parte de um programa, mas isso é outro artigo). Por outro lado, a escola não vai funcionar se nos preocuparmos apenas com a infraestrutura física. Podemos destacar outros casos: não adianta desenvolver (ou adquirir) um sistema e não implantar, comprar equipamentos e não contemplar a distribuição e instalação deles nos locais onde serão realmente necessários, instalar um novo sistema de comunicação e não estabelecer a rotina de gerenciamento que irá garantir que não pife ...

C) REQUISITOS (VISÃO INICIAL) OU QUAIS AS PRINCIPAIS CARACTERÍSTICAS DOS PRODUTOS DO PROJETO

A função desta seção é capturar as características dos produtos que provavelmente foram expressas pelas principais partes interessadas e que servirão de guia para a Declaração do Escopo. Em alguns casos, quando há a expectativa de trabalhar na Declaração do Escopo logo em seguida ao Termo de Abertura, algumas organizações optam por até suprimir essa seção do Termo de Abertura para evitar a duplicação de esforços.Se esse não for o caso, procure ater-se aos requisitos fundamentais, tais como capacidades a serem alcançadas, padrões a serem seguidos ou localização geográfica aproximada.Para o nosso exemplo, alguns exemplos de requisitos de alto nível poderiam ser:Ser situada em um bairro de classe média alta (não sabemos ainda onde será, mas esse requisito ajudará na determinação posterior do local);A estrutura das salas de aula deverá ser vertical (prédio com diversos andares), enquanto as demais estruturas deverão ser destacadas e horizontais;Possuir 30 salas de aula, 5 laboratórios, 2 quadras, salão de jogos, 2 cantinas e salão de eventos (não tenho detalhes ainda de como serão, mas já tenho ideia de qual a estrutura disponível);Quadro funcional deve contemplar 3 turnos de aulas (essa informações servirá, entre outras coisas, para dimensionar o quadro de funcionários).O único cuidado é procurar realmente destacar os requisitos essenciais e evitar que o Termo de Abertura fique muito técnico e inadequado ao público mais executivo (Patrocinadores). Lembrar sempre que existirá a Declaração do Escopo para capturar esses detalhes mais técnicos e que esse novo documento terá também o seu momento de apreciação e validação.

D) RISCOS (VISÃO INICIAL) OU O QUE MAIS NOS PREOCUPA NESSE MOMENTO

No ciclo de Planejamento, sabemos que o Gerenciamento de Riscos é um dos últimos tópicos a serem abordados, pois para bem identificar e analisar os riscos, é necessária a análise de diversas informações do projeto que devem ter sido detalhadas anteriormente.Por que devemos então registrá-los no Termo de Abertura, onde devemos ainda possuir informações mínimas sobre o projeto ? A resposta é simples: proatividade com aqueles riscos que saltam aos olhos e que não devem esperar a elaboração de todo o planejamento para serem tratados. Muito desses riscos podem afetar o próprio processo de planejamento e alguns podem ser facilmente tratados pelo Patrocinador, desde que alertemos sobre a percepção da equipe sobre eles.O problema nesse momento é, mais uma vez, exercitar o bom senso sobre aqueles pontos mais relevantes. Procure fugir de obviedades que já são naturalmente tratadas no decorrer do projeto.As dicas aqui são as mesmas que recomendamos para os processos de Identificação e Análise de Riscos:Formule os riscos no formato Causa-Risco-Efeito (Devido a <causa>, há a possibilidade de <risco>, que leva a <efeito>);Lembrar que riscos são possibilidades (há a possibilidade de ...). Problemas conhecidos devem ser contemplados no plano do projeto;Seja um catequizador sobre o que é o Gerenciamento de Riscos: nossa cultura tem a tendência de rejeitar o Gerenciamento de Riscos por considerá-lo como um “negativismo” no projeto – talvez por isso tenhamos tanta dificuldade em implementá-lo.

E) CRONOGRAMA DE MARCOS OU QUAIS AS EXPECTATIVAS DE PRAZO

Sim, nesse momento o que podemos ter são as expectativas oriundas muitas vezes do Patrocinador. Isso porque o planejamento detalhado ainda não foi concluído e muito do escopo e dos riscos ainda é desconhecido.Dessa forma, a primeira dica é que essa imprecisão deve ser claramente reconhecida pela organização. Podemos também mencionar:Faça uma primeira versão do cronograma para auxiliá-lo com as estimativas;Destaque apenas as grandes fases ou entregas do projeto;Trabalhe com estimativas em meses ou trimestres, ao invés de dias. Haverá maior flexibilidade se a estimativa for de conclusão do projeto em 6 meses ao invés de 5 meses e 15 dias, por exemplo;Utilize estimativas Top-Down ou verifique o histórico de projetos similares para dar maior precisão às estimativas;Procure defender o projeto de estimativas excessivamente otimistas, sem que haja base sólida para esse otimismo;Estipule uma reserva de tempo para riscos.

F) ORÇAMENTO RESUMIDO OU QUAIS AS EXPECTATIVAS DE CUSTOS

Cabem as mesmas observações e dicas que fizemos em relação ao tópico anterior, com um detalhe adicional: pode ser que o orçamento tenha sido previamente determinado para o projeto como parte do Planejamento Estratégico da Organização. Nesse caso, a estimativa pode também ser uma restrição ao Planejamento do projeto: você “terá” que encaixar o projeto no orçamento. Caso isso seja gritantemente impossível, cabe alertar imediatamente – quanto mais tarde isso for reconhecido e tratado, mais tempo e investimentos poderão ser perdidos.

G) DESIGNAÇÃO DO GERENTE DE PROJETOS E DO PATROCINADOR OU QUEM VAI TOCAR ESSE BARCO

Essa seção serve para registrar a equipe mínima inicialmente designada para elaborar o Planejamento do Projeto e para determinar sua autoridade. O fundamental é que sejam pessoas designadas, nunca setores da Organização. Projetos cujo Patrocinador e/ou Gerente de Projetos são identificados simplesmente como TI ou RH correm sérios riscos de não acontecerem, por falta de uma “paternidade claramente reconhecida” .Outra confusão comum em projetos multidisciplinares (vários setores envolvidos) é a tendência de atribuir mais de uma pessoa para os mesmos cargos. O raciocínio é inerente às organizações funcionais: cada setor cuida da sua parte, assim, cada setor teria seu Gerente de Projetos e seu Patrocinador. Entretanto, esse raciocínio tem levado a ações descoordenadas entre setores e o Gerenciamento de Projetos é exatamente a ferramenta para aglutiná-las em um todo coerente. Dessa forma, deve-se escolher um e apenas um Gerente de Projetos, o mesmo valendo para o Patrocinador, escolhidos entre os que tenham maior conhecimento e poder de influência que possam ser capitalizados para o projeto. Podemos então resumir assim:Identifique pessoas, não setores, como responsáveis pelo projeto;Apenas uma pessoa por cargo para garantir que o projeto “tem dono”;As pessoas identificadas devem ser as que melhor poderão contribuir com o projeto.Esse tópico é um dos mais importantes no Termo de Abertura, pois a sua essência é a atribuição de responsabilidades claras, para que o projeto realmente aconteça e traga os benefícios esperados.

H) PREMISSAS E RESTRIÇÕES OU O QUE QUERO DESTACAR SOBRE ESSE PLANO INICIAL

Em tom de brincadeira, poderiamos também rebatizar esse tópico de como conceitos tão simples se tornam tão confusos quando aplicados na prática. O fato é que encontramos, ao analisar o que os profissionais registram em seus Termos de Abertura, muitas Premissas que são, de fato, Restrições e vice-versa. Também Premissas e Restrições registrados como Riscos ou Requisitos.Para bem praticar esses conceitos, verifique se suas Premissas e Restrições se enquadram nas definições abaixo:Premissas: verdades assumidas, que, se não forem verdadeiras, irão afetar o Plano do Projeto. Por exemplo, você pode estar assumindo que o fornecedor de um determinado produto entregará sua encomenda em 10 dias, mas você ainda não sabe quem será o fornecedor nesse momento inicial. Se o projeto requer a compra de um equipamento importado, uma Premissa importante será o valor do dólar para o orçamento, mas esse valor somente será confirmado quando a compra for realizada. Como existe uma dúvida, as Premissas levam geralmente a Riscos que devem ser monitorados;Restrições: fatores que limitam as minhas escolhas. Limitadores de prazos, custos e qualidade que fazem com que as decisões do plano sejam restritas em algum aspecto. Um exemplo pode ser um limite de orçamento, datas que têm que ser obedecidas rigorosamente ou atendimento a normas mandatórias.

ESTRUTURA ANALÍTICA DE PROJETO – CONCEITO

O conceito de Estrutura Analítica de Projeto (em Inglês, Work Breakdown Structure – WBS) remonta ao tempo em que a Marinha Americana, durante o Projeto Polaris, criou a técnica denominada Program Evaluation Review Technique (PERT). O diagrama PERT, denominado também Diagrama ou Rede de Precedências, vincula e sequencia as atividades do Projeto. Porém, antes de criar a lógica sequencial das atividades, é necessário decompor o Projeto em unidades cada vez menores e mais detalhadas, para que posteriormente se possa estabelecer a rede de precedências. O menor nível da EAP é denominado Pacote de Trabalho.A Estrutura Analítica de Projeto (EAP) consiste no desdobramento do Projeto em unidades menores, até chegar aos Pacotes de Trabalho, elementos discretos (discreto aqui entendido obviamente como o oposto de contínuo, ou seja, discreto significa pacotes enumeráveis), e mutuamente exclusivos,  o que significa que não deve haver elementos de escopo contidos em mais de um pacote de trabalho.A Estrutura Analítica de Trabalho fornece o adequado arcabouço para a estimativa de custo de cada item, bem como possibilita a adequada construção do cronograma.O detalhamento pode ser por Sistemas, Especialidades ou mesmo uma Divisão Geográfica (por áreas):Estrutura Analítica de Projeto, por especialidadeEstrutura Analítica de Projeto, por sistemas Estrutura Analítica de Projeto, por área

ESTRUTURA ANALÍTICA DE PROJETO – PRINCÍPIOS BÁSICOS

Regra dos 100%:A Estrutura Analítica de Projeto deve conter 100% do trabalho. O que não está na EAP não deve ser feito, e tudo que está na EAP DEVE ser feito. A soma de todas Atividades-filha deve perfazer 100% da Atividade-mãe.Elementos mutuamente exclusivos:Não deve haver superposição de atividades. Um item do escopo NÃO pode estar simultaneamente em dois Pacotes de Trabalho.Nível de detalhamento:Um aspecto importante é quando se deve parar o detalhamento. Não há uma regra definida para isto, mas existem algumas diretrizes, ou, “rule of thumbs”:Apenas um recurso deve ser responsável pela atividade (pode haver mais de um executante, porém apenas um responsável); por exemplo, ao analisar “Zona de Radiação do Forno”, esta atividade pode ser subdividida, pois haverá atividades sob a responsabilidade do Encarregado de Solda (tubos da radiação) e outras sob a responsabilidade do Encarregado de Refratários (paredes refratadas). Já “Soldar serpentina de processo” pode ser considerado um Pacote de Trabalho, uma vez que, ainda que sejam diversos soldadores, esta atividade está sob responsabilidade de uma única pessoa, o Encarregado de Solda.Cada pacote de trabalho não deve exceder 80 Homens-Hora.A duração de cada pacote de trabalho não deve exceder a periodicidade do acompanhamento. Ou seja, se o nosso acompanhamento é semanal, os pacotes de trabalho não devem exceder uma semana.  Em uma parada de manutenção, onde o acompanhamento é diário (por vezes até por turno) cada pacote de trabalho não deve exceder um dia.Os pacotes de trabalho devem ser de porte suficiente a que se possa estimar duração, recurso e custos de forma adequada.E, finalmente, a regra do bom senso: devemos avaliar quando não vale mais a pena subdividir o pacote.

ESTRUTURA ANALÍTICA DE PROJETO – ERROS COMUNS

A Estrutura Analítica de Projeto NÃO é um cronograma, e nem os pacotes de trabalho estão dispostos em ordem cronológicaA Estrutura Analítica de Projeto NÃO é um Organograma. Haverá pessoas responsáveis pelos pacotes, mas a colocação destas pessoas não determina subordinação funcional.Utilização inadequada de componentes na estrutura Analítica de Projeto. Por exemplo, Desenhos não são um pacote de trabalho, são os entregáveis de um pacote de trabalho. Elaborar os documentos de construção da convecção do forno é um pacote de trabalho. Iniciação, Controle, são fases do projeto, não são pacotes de trabalho. Suporte de TI não é um pacote de trabalho.

ESTRUTURA ANALÍTICA DE PROJETO – FORMAS DE APRESENTAÇÃO

A Estrutura Analítica de Projeto pode ser apresentada na forma de um diagrama, conforme ilustrado nos exemplos anteriores, ou pode ser colocada na forma de uma lista itemizada.A apresentação conforme diagrama facilita o entendimento da hierarquia entre elementos da Estrutura Analítica de Projeto, mas pode ocupar muito espaço para desenhá-la, principalmente em grandes projetos.A forma de lista itemizada é muito utilizada pois permite construir uma planilha em Excel, atribuindo valores ou percentuais aos pacotes de trabalho, fazendo o acúmulo em cada nível imediatamente superior, o que facilita o pagamento de Contratos por Preço Global, conforme realização de itens da EAP. Esta forma também é útil porque pode ser representada nos softwares de Gerenciamento de Projetos, tais como MS Project e Primavera.Para ser notificado dos próximos artigos, cadastre seu e-mail no topo da página, à direita, em Assine o Blogtek! SEU E-MAIL NÃO SERÁ USADO POR TERCEIROS.
fonte blogtek

Método do Caminho Crítico (CPM)

inShare2Em que consiste o CPM?CPM é uma técnica utilizada para identificar o caminho crítico de um projeto, através da determinação de datas de início e término mais cedo e de início e término mais tarde de cada atividade existente, sem considerar quaisquer limitações de recursos.Os diferentes caminhos (paths) possíveis no diagrama de rede do projeto permitem com que uma atividade possua um range de datas possíveis de início e término (datas mais cedo e mais tarde de início e término).Através destas datas, é possível determinar a folga livre e a folga total de uma atividade. A folga livre informa quanto tempo uma atividade pode atrasar sem que haja impacto no início da atividade sucessora. Já a folga total informa quanto tempo uma atividade pode atrasar sem que haja impacto no término do projeto.Ao identificarmos o caminho que contém as atividades com folga total igual a zero ou ainda o caminho que contém a maior duração na soma das durações parciais das atividades, estaremos determinando assim, o caminho crítico do projeto.As atividades que residem no caminho crítico são denominadas atividades críticas e são aquelas que necessitam ser mais bem gerenciadas sob o risco de comprometerem o prazo do projeto.CPM na prática com MS ProjectVamos agora entender como o método do Caminho Crítico funciona na prática. Considere o seguinte diagrama de rede do projeto abaixo.Vamos identificar o caminho crítico do projeto seguindo alguns passos.1º Passo: Identifique todos os caminhos possíveis no diagrama. Observando a rede acima, temos 3 caminhos possíveis:- Caminho 01: Início-D-E-G-H-C-Término - Caminho 02: Início-D-F-B-Término - Caminho 03: Início-A-F-B-Término2º Passo: Some as durações parciais das atividades em cada caminho possível:- Caminho 01: Início-D-E-G-H-C-Término = 0d+4d+8d+5d+7d+8d+0d = 32 dias- Caminho 02: Início-D-F-B-Término = 0d+4d+7d+5d+0d = 16 dias - Caminho 03: Início-A-F-B-Término = 0d+6d+7d+5d+0d = 18 diasO caminho crítico é aquele que possui a maior soma dentre os caminhos possíveis. Sendo assim, o caminho crítico é representado pelas atividades críticas em vermelho.Qualquer mudança de prazo nessas atividades impacta a data de término do projeto.Outro propósito do caminho crítico do projeto é determinar as datas de início e término mais cedo e mais tarde de cada atividade. Com a determinação dessas datas, é possível obter as folgas livre e total.Observe a representação esquemática de uma atividade e a disposição de suas datas mais cedo (early start ou início mais cedo e early finish ou término mais cedo) e mais tarde (late start ou início mais tarde ou late finish ou término mais tarde).- ES = Early Start ou Início mais cedo ou início antecipado - EF = Early Finish ou Término mais cedo ou término antecipado - A = Atividade A - (d) = Duração d da atividade A - LS = Late Start ou Início mais tarde ou início atrasado - LF = Late Finish ou Término mais tarde ou término atrasadoPara a determinação das datas de início e término mais cedo e mais tarde é preciso percorrer na ida e na volta respectivamente, os caminhos possíveis identificados no 1º passo.Ao percorrermos os caminhos na ida, estaremos determinando as datas de início e término mais cedo. Na volta, determinamos as datas de início e término mais tarde.Forward pass (IDA): cálculo do mais cedo (início e término). Se tiver 2 atividades a serem analisadas para determinar o início mais cedo de uma terceira, eu pego sempre o MAIOR valor de término mais cedo entre as 2 predecessorasBackward pass (VOLTA): cálculo do mais tarde (início e término). Se tiver 2 atividades a serem analisadas para determinar o Término mais tarde de uma terceira, eu pego sempre o MENOR valor de início mais tarde entre as 2 predecessoras.Vamos ver como isto funciona.3º Passo: Executar o Forward pass (caminho de ida) para determinação das datas de início e término mais cedo das atividades do diagrama de rede do exemplo.Dica importante: Ao percorrermos na ida um caminho, poderemos nos deparar com a seguinte situação: a atividade a ser analisada possui duas predecessoras. A maior data de término mais cedo de suas predecessoras deverá ser considerada. Veja o exemplo abaixo. 4º Passo: Executar o Backward pass (caminho de volta) para determinação das datas de início e término mais tarde das atividades do diagrama de rede do exemplo.Dica importante: Ao percorrermos na ida um caminho, poderemos nos deparar com a seguinte situação: a atividade a ser analisada possui duas predecessoras. A menor data de início mais tarde de suas predecessoras deverá ser considerada. Veja o exemplo abaixo.5º Passo: Com as datas calculadas, obter as folgas livre e total.Folga livre é o tempo permitido para atraso de uma atividade do cronograma sem atrasar o início mais cedo das atividades do cronograma imediatamente subsequentes (sucessora).- FL| B (Folga livre da atividade B) = ES(Término) – EF (B) = 32-18 = 14. Ou seja, a atividade B pode atrasar 14 dias que não impactará no marco de término do projeto (sua sucessora) - As demais atividades possuem Folga livre zero.Folga Total é tempo permitido para atraso de uma atividade do cronograma sem atrasar o término total do projeto.- FT|A = LS|A – ES|A = LF|A – EF|A = 14 – 0 ou 20 – 6 = 14 - FT|B = 27 – 13 ou 32 – 18 = 14 - FT|C = 24 – 24 ou 32 – 32 = 0 - FT|D = 0 – 0 ou 4-4 = 0 - FT|E = 4-4 ou 12-12 = 0 - FT|F = 20-6 ou 27-13 = 14 - FT|G = 12-12 ou 17-17 = 0 - FT|H = 17-17 ou 24-24 = 06º Passo: Representação final da rede com datas e folgas determinadas7º Passo: Verificação do método CPM no MS ProjectObserve e faça o download da rede do exemplo e verifique as datas mais cedo e mais tarde obtidas pela ferramenta. Observe as folgas (Total Slack ou folga total e Free Slack ou folga livre)Supondo que o marco de início do projeto esteja em 06/12, teremos as seguintes datas calculadas:O MS Project para esta rede e as datas podem ser verificadas no arquivo abaixo(download do arquivo em MS Project)Observando o arquivo MS Project anexo, fique atento aos seguintes pontos:1) O MS Project soma +1 quando passa de uma atividade para outra pois ele entende que a atividade D será concluída no dia 09/12 consumindo as 8 horas do dia (default), fazendo com que a atividade E inicie no dia seguinte. É por isto que algumas pessoas calculam o ES de uma atividade somando +1 ao EF de sua predecessora. Observando D e E, teremos EF para D igual a 4 e ES para E seria 5.2) Considerar que finais de semana e feriados são dias não úteis. O prazo de 32 dias definido pela ferramenta e pelo método considera DIAS ÚTEIS, desconsiderando dias não úteis (finais de semana e feriados).3) O MS Project assinala de vermelho os atividades que estão no caminho crítico. Observar as colunas de inicio e termino antecipado e atrasado, margem de atraso total e livre e as datas geradas.8º Passo: Utilizando o PERT Chart EXPERT (Critical Tools) para reproduzir a rede, teremos:

Software para desenvolver processos e fluxogramas grátis

Para quem precisa modelar processos, criar fluxogramas, diagramas de rede, UML, mapas elétricos  e outros, mas não quer gastar uma fortuna nem apoioar a pirataria, segue minha indicação de software:O DIA é  um software livre, de código aberto, que pode ser utilizado para criação de diagramas de vários tipos. O download é gratuito, rápido, instalação fácil e uso intuitivo. Funciona em Windows, Mac e Linux. Ele separa cada diagrama em um arquivo diferente, não encontrei forma de ligá-los. Traz um recurso de “layer” (camadas” que permite a edição de um pedaço do diagrama enquanto outra parte fica congelada. Vale a pena.- See more at: http://www.elirodrigues.com/2011/02/01/dia/#sthash.7uHjmo9r.dpuf

Gerência de Projetos: A importância das lições aprendidas 

 

 

Grande parte do que aprendemos na vida foi adquiri

do vivenciando fracassos e

sucessos. Em gestão de projetos, essa máxima, mostr

ou ser uma eficiente ferramenta, de

amadurecimento da equipe e melhora da qualidade dos

serviços prestados.

É comum que no andamento dos projetos surjam situa

ções que exijam providências

imediatas. Problemas com fornecedores, escolhas de

tecnologia mal embasadas, conflitos de

relacionamento com o cliente ou com a equipe e estr

atégias mal elaboradas são bons

exemplos disso. A solução para estas situações traz

consigo a possibilidade real de

aprendizado, sobretudo para quem esteve envolvido n

a sua resolução. É fácil. Imagine um

projeto com cronograma seriamente comprometido, por

que o fornecedor de um insumo

importante deixou de entregá-lo dentro do prazo ace

rtado. É certo que nos próximos projetos o

fornecedor seja substituído, sobretudo porque o ger

ente de projetos não quer correr o risco se

ver de frente com o mesmo problema novamente. Este

é o conceito de Lições Aprendidas. É

interessante citar que, embora o exemplo relate uma

situação negativa, situações positivas

também possibilitam aprendizado e por isso também d

evem ser levadas em consideração.

Agora que o conceito de lições aprendidas foi apres

entado, fica uma pergunta no ar:

Que ganhos obterei ao registrá-las? A resposta é si

mples. Na maioria dos projetos, sobretudo

os de desenvolvimento de software, a equipe é desfe

ita com o fim do projeto, muitas vezes até

mesmo antes dele. Por isso, é fundamental que o con

hecimento que foi adquirido com as

lições aprendidas seja documentado, principalmente

para não ser esquecido. Por outro lado,

conforme as lições forem registradas, elas comporão

uma base de dados histórica, que servirá

de apoio para todos os demais projetos que surjam.

Possibilita-se com isso, a elaboração de

estratégias que coíbam os erros cometidos no passad

o, e que por sua vez, permitam a

repetição dos acertos no futuro.

Na prática, o registro das lições pode ser feito d

e muitas formas diferentes, sejam elas

fichas, planilhas eletrônicas ou sistemas de inform

ática desenvolvidos especificamente para

esta finalidade. O que interessa é que as informaçõ

es estejam disponíveis quando necessário,

e que para cada lição, sejam documentadas algumas i

nformações fundamentais, tais como

atividade, tipo, situação, lição aprendida, ações p

reventivas e ações corretivas. O

indispensável, é que, independente da forma como es

tejam registradas, elas sejam

organizadas de forma racional e prática. De nada ad

ianta registrar as lições e depois esquecê-

las dentro de uma caixa qualquer, ou inseri-las de

qualquer jeito em uma planilha eletrônica,

sem nenhuma ordem, impossibilitando que se faça alg

um uso inteligente dessas informações.

Embora o registro das lições aprendidas tenha demon

strado ser de grande valor, a

maioria dos gerentes de projeto simplesmente as ign

ora. Os fatores para isso são variados.

Em primeiro lugar, a pressão pelo cumprimento de pr

azos é muito grande, por isso o esforço

do gerente acaba se voltando para as atividades que

estão diretamente ligadas ao projeto. Por

outro lado, como o registro é uma atividade cujos b

enefícios não serão diretamente sentidos

alta gestão da empresa e sim pela equipe do projeto

, ela acaba não recebendo o apoio que

deveria receber. Colabora ainda, o fato de que, con

forme o projeto caminha para o fim, as

atenções da equipe, que deveriam estar voltadas par

a o seu correto encerramento, acabam se

voltando para o próximo projeto. Ademais, por incrí

vel que pareça, muitos gerentes de projeto,

embora conheçam o conceito na teoria, não acreditam

que registrar lições aprendidas traga

algum proveito para os seus futuros projetos.

Ao adotar o registro das lições aprendidas, o gere

nte está dando um passo importante

para o crescimento da equipe, que lidou com situaçõ

es difíceis, mas também com acertos e

sucessos. A base histórica crescerá, assim como a c

apacidade da equipe, com o registro das

boas e más experiências que, se estiverem organizad

as e estruturadas, servirão como

preciosa ferramenta para melhora dos serviços prest

ados e eficiência organizacional. 

 

Fonte

 

Rodrigo Zakarewicz

Líder de projetos e consultor em análise e desenvol

vimento de sistemas

Brasília - DF

INDICADORES DE CUSTO COM MS-PROJECT

O que é a análise de valor ganho?

Na raiz da análise de valor ganho existem três valores fundamentais calculados para cada tarefa:

• O custo orçamentado das tarefas, conforme agendado no plano de projecto, baseado nos custos dos recursos atribuídos a essas tarefas, acrescido de todos os custos fixos associados às tarefas. Denominado "o custo orçamentado do trabalho agendado", o BCWS (Budgeted Cost of Work Scheduled) é o custo do plano base até à data de estado escolhida. Por exemplo, o orçamento total planeado para uma tarefa de 4 dias é de €100 e começa segunda-feira. Se a data de estado estiver definida +ara a quarta-feira-seguinte, o BCWS é de €75.
• O custo real necessário para concluir todas ou parte das tarefas, até à data de estado. Trata-se do custo real do trabalho executado (ACWP, Actual Cost of Work Performed). Por exemplo, se a tarefa de 4 dias incorrer num custo total de €35 durante cada um dois 2 primeiros dias, o ACWP relativo a este período é de €70 (mas o BCWS continua a ser de €75).
• O valor do trabalho executado pela data de estado, medido em moeda. Este é, literalmente, o valor ganho pelo trabalho executado e é chamado de custo orçamentado do trabalho executado (BCWP, Budgeted Cost of Work Performed). Por exemplo, se após 2 dias tiver sido concluído 60% por cento do trabalho numa tarefa, poderá esperar ter gasto 60 por cento do orçamento total da tarefa ou €60.

Está a acompanhar, até agora? Prossigamos.
A análise de valor ganho é sempre específica de uma data de estado escolhida pelo utilizador. Poderá seleccionar a data actual, uma data no passado ou uma data no futuro. Na maior parte das vezes, a data de estado será definida como sendo a data da última actualização do progresso do projecto. Por exemplo, se o dia actual for terça-feira, 12/9, mas o projecto tiver sido actualizado pela última vez com progresso na sexta-feira, 8/9, a data de estado seria definida para sexta-feira, 8/9.
A seguir é apresentado um exemplo de como analisar o desempenho do projecto com a análise de valor ganho. Uma tarefa tem um custo orçamentado (BCWS) de €100 e, pela data de estado, está 40 por cento concluída. O valor ganho (BCWP) é de €40, mas o valor agendado (BCWS) na data de estado é de €50. Isto indica que a tarefa está atrasada, foi ganho um valor inferior ao planeado. O custo real da tarefa (ACWP) na data de estado é de €60, provavelmente porque foi atribuído à tarefa um recurso mais dispendioso. Isto indica que a tarefa também ultrapassa o orçamento, foram incorridos mais custos do que os planeados. É possível verificar como esta análise pode ser é poderosa. Quanto mais cedo identificar discrepâncias no ciclo de vida do projecto entre o ACWP, o BCWP e o BCWS, mais cedo poderá tomar medidas para rectificar o problema.
Uma forma comum de visualizar os valores-chave da análise de valor ganho é a utilização de um gráfico. Comece por um gráfico simples que mostra uma acumulação constante de custos ao longo da duração de um projecto:

O eixo vertical y mostra o custo acumulado projectado de um projecto.
O eixo horizontal x mostra o tempo.
O orçamento planeado para este projecto mostra uma despesa constante ao longo da duração do projecto. Esta linha representa o custo acumulado do plano base.
Depois de o trabalho no projecto começar, um gráfico dos valores-chave da análise de valor ganho poderá ter um aspecto semelhante ao seguinte:

A data de estado determina os valores calculados pelo Project.
O custo real (ACWP) deste projecto excedeu o custo orçamentado.
O valor ganho (BCWP) reflecte o valor real do trabalho executado. Neste caso, o valor do trabalho executado é inferior ao montante gasto para executar esse mesmo trabalho.

Que mais é que o valor ganho mede?

Além de medir o BCWS, o ACWP e o BCWP, a análise de valor ganho mede:

• Desvio de custos (CV): diferença entre o custo estimado de uma tarefa e o respectivo custo real (com a fórmula CV = BCWP - ACWP). No primeiro exemplo, o orçamento total planeado para uma tarefa de 4 dias é de €100 e começa numa segunda-feira. Quando a data de estado é definida para a quarta-feira seguinte, o BCWS é de €75, o ACWP para este período é de €70 e o BCWP é de €60. Nesse caso, o CV da tarefa é de -€10.
• Desvio Agendado (SV): a diferença entre o progresso actual e o progresso agendado de uma tarefa, em termos de custo (com a fórmula SV = BCWP - BCWS). No exemplo anterior, o SV da tarefa é de -€15.
• O índice de desempenho de custos (CPI): rácio de custos orçamentados em relação aos custos reais (com a fórmula CPI = BCWP / ACWP). No exemplo anterior, o CPI da tarefa é de cerca de 0,86 ou 86 por cento.
• O índice do desempenho agendado (SPI): rácio do trabalho executado em relação ao trabalho agendado (com a fórmula SPI = BCWP / BCWS). No exemplo anterior, o SPI da tarefa é de 0,80 ou 80 por cento.
• O índice de desempenho para conclusão (TCPI): rácio do trabalho restante a ser executado em relação aos fundos restantes para gastar a partir da data de estado ou orçamento na conclusão (com a fórmula TCPI = [BAC - BCWP] / [BAC - ACWP]).

Como posso interpretar o valor ganho?

Os indicadores do valor ganho que são desvios ou rácios podem ajudar a determinar se existe dinheiro suficiente no orçamento e se o projecto terminará no prazo.
Desvios, como, por exemplo, um desvio de custos (CV), podem ser positivos ou negativos:

• Um desvio positivo indica que o projecto está adiantado ou abaixo do limite de orçamento. Os desvios positivos poderão permitir realocar dinheiro e recursos de tarefas ou projectos com desvios positivos para tarefas ou projectos com desvios negativos.

• Um desvio negativo indica que o projecto está atrasado ou que ultrapassou o orçamento e que é necessário tomar medidas. Se uma tarefa ou projecto tiver um CV negativo, poderá ter de aumentar o orçamento ou aceitar margens de lucro reduzidas.

Os rácios, como, por exemplo, o índice de desempenho de custos (CPI) e o índice do desempenho agendado (SPI), podem ser maiores que 1 ou menores que 1:

• Um valor maior que 1 indica que o projecto está adiantado ou abaixo do limite de orçamento.

• Um valor menor que 1 indica que está atrasado ou que ultrapassou o orçamento. Por exemplo, um SPI de 1,5 significa que utilizou apenas 67 por cento do tempo planeado para concluir uma parte de uma tarefa num determinado período e um CPI de 0,8 significa que gastou 25 por cento mais de tempo numa tarefa do que o que tinha sido planeado.

De que forma a % concluída versus a % física concluída afecta o valor ganho?

É possível especificar se o Project deve utilizar o valor de percentagem concluída ou de percentagem física concluída de cada tarefa para cálculos de valor ganho relacionados com o BCWP. (Tenha em atenção que são calculados outros valores a partir do BCWP, pelo que a decisão afecta toda a análise de valor ganho.)

• A percentagem concluída pode ser calculada pelo Project ou directamente introduzida pelo utilizador, dependendo da forma como controla o trabalho real.

• A percentagem física concluída é sempre directamente introduzida pelo utilizador. Utilize a percentagem física concluída quando a percentagem concluída não for uma medição exacta do trabalho real executado ou restante.

Em seguida, é apresentado um exemplo simples de como os dois valores podem diferir: o projecto de construir uma parede de pedra composta por 100 pedras em pilhas de 5. A primeira linha de 20 pedras pode ser colocada em 20 minutos, mas a segunda linha demoraria 25 minutos porque e necessário levantar as pedras uma linha acima, pelo que demora um pouco mais. A terceira linha demoraria 30 minutos, a quarta 35 minutos e a última linha demoraria 40 minutos a colocar, num total de 150 minutos. Depois de colocar as três primeiras linhas, o projecto estaria 60 por cento fisicamente concluído (colocou 60 de 100 pedras). No entanto, só gastou 75 dos 150 minutos; em termos de duração, a tarefa só está 50 por cento concluída.
Dependendo da maneira como o trabalho é pago, a forma como o valor é ganho (por pedra ou por hora), poderá escolher o valor de percentagem concluída ou o valor de percentagem física concluída para reflectir de forma adequada esta situação na análise de valor ganho.

Que quantidades de valor ganho posso mostrar ou calcular no Project?

Com o Project, é possível mostrar:

• Custo real do trabalho executado (ACWP) mostra os custos reais incorridos por trabalho já executado por um recurso numa tarefa, até à data de estado do projecto ou a data actual. Normalmente, o Project relaciona os custos reais com o trabalho real. Só se introduzir custos reais independentes do trabalho real ou se alterar as taxas de pagamento dos recursos é que os custos reais estarão desfasados dos custos agendados.
• Orçamento na conclusão (BAC) mostra uma estimativa do custo total do projecto.
• Custo orçamentado do trabalho executado (BCWP) mostra quanto do orçamento deveria ter sido gasto, tendo em conta a duração real da tarefa. O BCWP também é referido como "valor ganho." Note que o Project calcula o BCWP ao nível da tarefa de forma diferente do que ao nível da atribuição. Para obter os melhores resultados, utilize os valores de BCWP ao nível da tarefa, que são os valores que o Project agrega para os valores de BCWP da tarefa sumário e da tarefa sumário do projecto. Este valor é calculado para cada tarefa individual mas analisado a um nível agregado (normalmente, ao nível do projecto).
• Custo orçamentado do trabalho agendado (BCWS) mostra quanto do orçamento deveria ter sido despendido tendo em conta o custo do plano base da tarefa, atribuição ou recurso. O BCWS é calculado como sendo os custos acumulados do plano base faseado em relação à data de estado ou à data actual. (Os valores de custo orçamentado são armazenados nos campos do plano base ou, se tiver guardado vários planos base, nos campos Plano Base1 a Plano Base10.)
• Desvio de custos (CV) mostra a diferença entre o custo orçamentado do trabalho executado (BCWP) numa tarefa e o custo real (custo real do trabalho executado ou ACWP). Se o CV for positivo, significa que o custo se situa actualmente abaixo do montante orçamentado (ou plano base); se o CV for negativo, significa que a tarefa está actualmente acima do orçamento.
• Desvio agendado (SV) mostra a diferença entre o custo orçamentado do trabalho executado (BCWP) e o custo orçamentado do do trabalho agendado (BCWS). Se o SV for positivo, significa que o projecto está adiantado em termos de custos; se o SV for negativo, significa que o projecto está atrasado em termos de custos.
• Desvio na conclusão (VAC) mostra a diferença entre o orçamento na conclusão (BAC) e a estimativa na conclusão (EAC). No Project, o EAC é o campo Custo Total e o BAC é o campo Custo do Plano Base do plano base associado.
• Índice de desempenho de custos (CPI) rácio dos custos do trabalho executado, orçamentado ou do plano base, em relação aos custos reais do trabalho executado (BCWP/ACWP).
• Índice de desempenho de custos acumulados (CPI) soma do BCWP para todas as tarefas, dividido pela soma dos custos reais de trabalho executado (ACWP) para todas as tarefas. O CPI acumulado é utilizado frequentemente para prever se um projecto ultrapassará o orçamento e em quanto.
• Índice do desempenho agendado (SPI) rácio do trabalho executado em relação ao trabalho agendado (BCWP/BCWS). O SPI é frequentemente utilizado para calcular a data de conclusão do projecto.
• Estimativa na conclusão (EAC) custo total esperado de uma tarefa ou projecto, baseado no desempenho a partir da data de estado. O EAC também é denominado previsão na conclusão e é calculado da seguinte forma: EAC = ACWP + (BAC - BCWP) / CPI.
• Índice de desempenho para conclusão (TCPI) rácio do restante orçamento disponível a ser gasto em relação ao restante custo agendado a partir da data de estado. O TCPI é calculado da seguinte forma: TCPI = (BAC - BCWP) / (BAC - ACWP). Um valor de TCPI maior que 1 indica um desempenho projectado bom para o restante trabalho; menor que 1 indica um desempenho projectado pobre.

Qual o local no Project para ver os dados do valor ganho?

As informações de valor ganho podem consultadas em qualquer vista de folha aplicando a tabela Valor Ganho ou a tabela Indicadores do Custo de Valor Ganho.

• A tabela Valor Ganho mostra o BCWS, o BCWP, o ACWP, o SV, o CV, o EAC, o BAC e o VAC. Utilize esta tabela para ver as informações consolidadas de valor ganho, incluindo os campos-chave de desvio. Utilize o EAC, o BAC e o VAC para avaliar a diferença entre os custos agendados e orçamentados. Compare o CV, que mostra a diferença entre o custo orçamentado e o custo real do trabalho, com o SV, que mostra a diferença entre o custo orçamentado do trabalho e o custo real do trabalho.
• A tabela Indicadores do Custo de Valor Ganho mostra o BCWS, o BCWP, o CV, a CV%, o CPI, o BAC, o EAC, o VAC e o TCPI. Utilize esta tabela para analisar os desvios de custos. Verifique o CPI e o TCPI para ver a forma como o projecto está a progredir em relação ao respectivo orçamento e a comparação entre a taxa de trabalho e a taxa esperada. Se o CPI for menor que 1, significa que está a obter menos trabalho por euro do que o planeado. O TCPI indica qual será o aumento de desempenho necessário nas restantes tarefas para respeitar o orçamento.

Fonte Microsoft