Para reduzir o Caminho Crítico

Os Gestores de Projeto estão constantemente sob grande pressão para concluir o projeto no menor espaço de tempo possível. É, portanto, imperativo quese familiarizem com as técnicas básicas para encurtar o caminho crítico e as muitas e diferentes formas de fazer isso.

Um dos principais benefícios dos gráficos de Gantt é que eles apresentam todas as atividades que estão ao longo do caminho crítico (mostradas em vermelho). Estas são atividades cuja duração não pode ser adiada sem o efeito negativo de atrasar todo o projeto. Existem situações em que uma atividade crítica, devido talvez a alguma restrição, não está no caminho mais longo e, portanto, não vai atrasar todo o projeto.

Por conseguinte, o caminho crítico determina o comprimento total do projeto. Se puder encontrar uma maneira de encurtar o caminho crítico o projeto vai acabar mais cedo e as partes interessadas no projeto ficarão mais felizes. Daí o esforço para encurtar o caminho crítico não possa ser ainda mais enfatizado.

Quando começamos o esforço para encurtar o caminho crítico é preciso manter o foco o impacto possível sobre a qualidade, o âmbito e a duração do projeto. O ideal é que a qualidade e o âmbito sejam iguais ou aumentem e o tempo e para concluir diminua. A vida, no entanto, no mundo da programação em geral não é tão ideal. O encurtamento do caminho crítico decorrerá com trade-offs e você terá que determinar tanto os efeitos positivos como negativos sobre o projeto. Acompanhe este blogue conforme discutimos as técnicas de encurtamento do caminho crítico e aperfeiçoamos nossas capacidades neste importante esforço de gestão de projetos.

Os efeitos dos métodos para encurtar o caminho crítico são apresentados na Tabela 1.

	Método	Qualidade	Âmbito	Tempo
1	Torne paralelas atividades sequenciais	-	-	¯
2	Torne as dependências sequenciais em dependências parciais	-	-	¯
3	Adicione recursos	?	_	?
4	Diminua as estimativas de duração	?	-	¯
5	Diminua os intervalos (lags)	?	-	¯
6	Decomponha as atividades de longa duração	-	-	¯
7	Diminua o âmbito	¯	¯	¯

Tabela 1 - Efeitos dos Métodos de Encurtar o Caminho Crítico

Observe a legenda. O símbolo '?' na legenda significa que o efeito é desconhecido, e você terá de analisar a situação particular para determinar o impacto. Estes métodos não estão, necessariamente, listados por ordem de preferência. Apesar de um, dois, e seis serem definitivamente as abordagens mais favorecidas.

 

Criar caminhos paralelos a partir de caminhos sequenciais (Fast Tracking)

Muitas vezes o maior resultado decorre de mudar atividades em série para atividades em paralelo. Portanto, procure as relações sequenciais que não são necessárias. Muitas vezes os programadores irão definir duas atividades numa relação de fim para início (FS) porque assumem que a atividade sucessora é realizado pela mesma equipa que trabalha na atividade predecessora. Isso pode de fato não ser assim, caso em que pode ter uma dependência suave no máximo. E pode agendar as duas atividades concorrentemente, e assim que são realizadas em paralelo.

Realização de atividades de dependência suave em paralelo em vez de as realizar sequencialmente pode ser uma enorme poupança de tempo. Isto é conhecido como tracking da programação rápida. Um exemplo simples, a Figura 1, é que instalar as Janelas e Instalar as portas são atividades que não precisam ser sequenciais, executando numa dependência início com início (SS) faz sentido.

Particularmente, se houver, as equipes de recursos separadas para as duas atividades e não houver problemas com as equipes de recursos competindo por espaço de trabalho.

Aqui, a qualidade e o âmbito de aplicação não serão afetados e a possível redução de tempo é significativa.

 

Torne as dependências sequenciais em dependências parciais (Fast Tracking)

Alterar uma dependência sequencial para uma dependência parcial só é possível se você não tem uma rígida relação FS entre as duas atividades. Num relacionamento rígido FS você afirma que a atividade sucessora não pode começar até a conclusão total da atividade predecessora. Um exemplo clássico é a sua atividade antecessora ser Fazer Fundação e a atividade sucessora ser Instalar Cofragens nas paredes, Figura 3.

Deve ter terminado com as Fundações antes que possa começar a instalar cofragens das paredes. Mas então o que se passa com as atividades Cavar Vala e Instalar Tubagem para uma instalação de tubulação subterrânea. Cavar Vala é o antecessor óbvio e colocar a tubulação é o sucessor. Agora sabemos que deve completar escavação de valas antes de concluir a Instalação da tubagem. Mas deve a atividade Cavar Vala ser completamente feita antes do início da atividade Instalar Tubagem? A resposta é não. Pode então alterar as dependências sequenciais em dependências parciais. Isto, mais uma vez, é referido como fast tracking do cronograma.

A recomendação é que coloque uma relação de início-a-início entre o predecessor cavar trincheiras e sucessor estabelecer instalar tubos com um desfasamento positivo sobre o sucessor Instalar Tubagem, Figura 4.

Aqui, o desfasamento é o tempo de espera (3D - três dias) entre o início de uma atividade de antecessora e o início da sucessora. Usando o lag permite atrasar a atividade Instalar Tubagem vários dias até que haja espaço suficiente na trincheira para prosseguir com a instalação dos tubos. Note que há um problema de rede aberta com a dependência parcial SS, que é discutida aqui.

Outros recomendam mudar a relação FS pela adição de um lag negativo. (Outro nome para lag negativo é lead.) Então você ajustar seu relacionamento FS, adicionando um atraso ou lead negativo, figura 5.

Se prefere usar desfasagens negativas, deve usá-las com moderação. E devo adverti-lo de que muitas agências governamentais e empresas de engenharia proíbem o uso de desfasagens negativas e, portanto, não aprovarão o plano se os incluir.

Geralmente fazer dependências sequenciais dependências parciais não terá impacto sobre a qualidade ou o escopo, mas vai reduzir tempo. Ótimo! Isto é o que queremos.

 

Adicionar Recursos (Crashing)

Adicionar recursos adicionais a uma atividade, que é denominado como ‘crashing’, é uma maneira de reduzir o tempo da atividade sem sacrificar o âmbito. Este processo irá aumentar o custo, porque a economia de tempo de uma atividade encurtada geralmente não resulta numa economia de custos de recursos comparáveis para compensar o custo adicional de recursos adicionais. Assim, com ‘crashing’ seu tempo supostamente vai para baixo, mas o seu custo, muito provavelmente, irá aumentar.

Outros argumentam que você pode até não obter a economia de tempo que você esperava. Eles dizem isso porque os recursos adicionais podem não ser tão proficientes, exigirão a formação de trabalhadores mais qualificados. Portanto, há uma curva de tempo inicial para novos e / ou desconhecidos trabalhadores para se tornarem produtivos. Isso resulta numa inicial desaceleração na esperança de ganhar tempo, mais tarde, e isto pode não acontecer.

Outra consideração importante antes de fazer ‘crashing’ a uma atividade é o espaço de trabalho. Será que tem espaço de trabalho suficiente para todos os trabalhadores adicionais para serem produtivos e, realmente, aumentar a produtividade da equipa?

Considere também cuidadosamente o que é conhecido como a lei dos rendimentos decrescentes quando se faz a adição de recursos. Este é a situação onde adicionando mais e mais recursos resulta em cada vez menos e menos impacto no projeto e chega a um ponto em que adicionar mais recursos pode não melhorar a produtividade pode até reduzir. Isso pode ser causado por problemas de comunicação aumentadas com equipas maiores ou outros fatores, como espaço de trabalho acima descrito.

Aqui a economia de tempo é questionável. O efeito do uso de recursos sem formação faz com que a qualidade seja questionável. O âmbito de aplicação, no entanto, não deve ter nenhum impacto. Muitas vezes a reação instintiva de um gestor de projeto é adicionar recursos para comprimir o cronograma, mas isso simplesmente não é a primeira melhor opção, como descrito acima.

 

O que mais procurar?

Em vez de adicionar recursos olhar para estas possibilidades economia de tempo adicionais:

Reveja as durações estimadas de atividades críticas. Talvez, o planeador tenha "acolchoado" a duração prevista da atividade. Padding é quando o estimador acrescenta tempo extra para uma atividade, porque não tem informações suficientes para fazer uma estimativa precisa. Diminuindo as estimativas de duração beneficia o tempo de planeamento, mas pode afetar a qualidade e, talvez, até mesmo âmbito.

Reveja as durações estimadas de desfasagens no caminho crítico. Mais uma vez, desfasagens são tempos de espera entre as atividades, tais como o tempo para deixar uma cura de concreto na fundação antes de instalar as paredes na fundação. Talvez, não precisa de uma semana para o seu concreto curar antes de iniciar sua atividade sucessora. A vantagem é a redução do tempo, mas, talvez, à custa da qualidade. O âmbito não é afetado.

Olhe para tarefas críticas com duração extremamente longa. Estes podem ser divididos em tarefas menores e algumas destas atividades resultantes mais pequenas podem ser otimizadas, realizando-as em paralelo. Idealmente, isso não deve afetar a qualidade e âmbito, mas, possivelmente, reduzirá o tempo.

Olhe para o âmbito do caminho crítico do projeto. São todos os resultados necessários ou alguns produtos podem ser removidos e, por conseguinte, as atividades eliminadas do caminho crítico? Naturalmente, o que reduz o âmbito e, por conseguinte, a qualidade, a economia de tempo, mas pode ser significativo e de importância primordial. O processo difícil de tomar a decisão de cortar ramos de árvores, mas se eles são um peso morto têm que ir. E isso só pode salvar a árvore e / ou projeto.
 

Em suma

Encurtar o tempo do plano, uma das três variáveis da restrição tripla do Tempo-Custo-Qualidade, é uma grande responsabilidade do gestor do projeto. Sim, o tempo é uma das principais variáveis a partir do qual medimos o sucesso do projeto. Um gestor de projeto que é hábil em compressão de cronograma vai ter sempre trabalho.

Em geral, a melhor maneira de reduzir a programação é ajustar atividades realizadas em série, de modo que eles serão executadas em paralelo. Se isto não pode ser feito na totalidade, pelo menos pode ser bom para fazer isso em parte.

Tornar dependências sequenciais em dependências parciais é também uma técnica favorável de compressão do cronograma. Com este objetivo em mente, pode querer olhar para dividir atividades de duração particularmente longa em várias atividades. Você pode determinar que algumas dessas atividades mais curtas podem ser executadas em paralelo, no todo ou em parte.

Embora o crashing do cronograma adicionando recursos seja um método popular de compressão de cronograma não é uma das melhores abordagens. Os custos, muito provavelmente, aumentarão. A qualidade pode deteriorar-se e pode nem sequer obter qualquer economia de tempo. Portanto, recomendamos que você se familiarize com algumas das outras abordagens de compressão do cronograma.

Pontos negativos do Lag Negativo

Procura maneiras de acelerar o cronograma? Para acelerar o cronograma - «crashing» - pode empregar vários métodos, mas normalmente usam-se atividades que estão agendadas em série e executam-se todas ou algumas em paralelo para encurtar o ciclo de vida planeado para o resto do projeto.

Se quiser encurtar o cronograma de acompanhamento - «fast tracking» -, então deve considerar a utilização de atrasos ou desfasamentos negativos, estes últimos também conhecidos como 'leads'.

A pergunta que devemos responder é se os desfasamentos de ligações «leads» são um método correto de encurtar o projeto?
Ambos os métodos, tanto leads como os lags podem ter um impacto significativo sobre a dimensão do cronograma. Um lag é um tempo de espera entre as atividades predecessoras e sucessoras. As aplicações típicas de lag incluem relacionamentos Finish-to-Finish, Start-a-Start e, Finish-to-Start. As ligações são a quantidade de tempo que um segundo (sucessor) da atividade pode começar antes da conclusão da primeira (antecessor) atividade. Leads são geralmente aplicados entre as atividades com uma relação Finish-to-Start. A intenção de leads é colocá-lo à frente do cronograma ou para encurtar o cronograma.

Contudo por mais bem-intencionada que seja a inserção de um lead na programação, estes são muitas vezes desencorajados pela maioria das orientações de agendamento, nomeadamente, a da Defense Contract Management Agency (DCMA) nas suas diretrizes de avaliação de 14 pontos. A questão permanece, quais são as desvantagens de usar leads e por que razão muitos profissionais e especialistas desencorajam o seu uso?

 

Leads e Resultado

Os leads são particularmente úteis para as atividades com longa duração. A pergunta a fazer é se uma rígida ligação em FS é requerida entre duas atividades ou se a segunda tarefa pode começar antes da primeira tarefa terminar? Um exemplo simples é a instalação de tubagem de água no subsolo.

Quando, faltam ainda fazer 7 dias de escavação da vala os montadores de tubagens podem começar a instalar da tubagem. A principal questão neste caso é a certeza de que a duração da equipa de montagem é menor que a da equipa de escavação. Uma equipa de montagem de tubagem com uma produção mais rápida criaria uma situação ilógica, onde a segunda atividade no relacionamento FS realmente se concluiria antes da primeira. Claro, isso é completamente irracional e não vai acontecer. O que vai acontecer é que a equipa de montagem da tubagem terá de suspender o trabalho e ter tempo de inatividade enquanto a escavação da vala se esforça para ir em frente. Isto resulta assim num ineficiente resultado do agendamento.

 

A Natureza preditiva do Lead

Um lead ou lag negativo indica que uma atividade sucessora pode iniciar-se num período de tempo antes da atividade antecessora estar completa. Com leads começa-s uma atividade com base no final previsto da conclusão de outra atividade. Portanto, estamos a decidir a conclusão prevista de um âmbito de trabalho predecessor para iniciar uma atividade sucessora.

O problema é que na realidade é muito difícil ser capaz de prever o efeito de uma atividade ou extensão de trabalho, a ligação do início de outra atividade com base nesta previsão de final não é uma boa prática de programação. Novamente, para o relacionamento Finish-to-Start com lag negativo estamos a dizer que a atividade sucessora pode começar um período de tempo antes da predecessora estar 100% concluída.

Para clarificar o problema deve olhar para ele desta forma; está a ligar e iniciar atividades com base no futuro e previu para isso o 100% de conclusão do predecessor. Então está a decidir iniciar uma atividade com base numa situação de atividade futura, o que não é o ideal.

 

Lags ou esperas

É muito mais simples compreender um desfasamento do que uma ligação negativa a uma predecessora. É mais fácil dizer que uma atividade sucessora começa 4 dias após o predecessor. Dizer, como no caso de ligações lead que uma atividade sucessora começará um número estimado de 7-dias antes da conclusão de uma atividade antecessora é confuso, no mínimo. Isso não quer dizer que desfasamentos – lags - correm sem problemas. O Start -to- Start com desfasamento positivo entre antecessora e sucessora, em particular, tem problemas. Dizer que 4 dias após o início da escavação de valas os montadores de tubos podem começar a instalação do tubo também traz problemas.

A base para iniciar a instalação da tubagem não depende da conclusão total de um âmbito de trabalho da escavação de vala, que é o que você pretende com o desfasamento. E se a equipe de escavação não é muito produtiva e, portanto, depois de 4 dias de escavação eles não criaram espaço suficiente para os montadores de tubagens trabalharem na instalação? É melhor dizer que uma vez que as escavadoras concluíram um escopo conhecido de trabalho, por exemplo, a escavação de 30 metros de vala, de seguida, os montadores de tubagens poderão iniciar a instalação dos tubos. Neste caso, escavar 30 metros de vala é a antecessora e os sucessores em paralelo são a escavação restante e instalar a tubagem.

Os lags funcionam bem quando descrevem um absoluto. O desfasamento mais usado "cura de betão" funciona bem num cronograma por que o betão toma uma quantidade conhecida de tempo para curar; e é aplicada após a finalização da atividade de betonagem, um âmbito de trabalho conhecido. A instalação de betão é um relacionamento Finish-to-Start com um desfasamento positivo. Mais uma vez, trabalha bem porque o desfasamento e a atividade sucessora são dependentes da conclusão de um âmbito de trabalho conhecido.

A relação Finish-to-Finish com um desfasamento positivo também funciona bem, porque o lag e a atividade sucessora são dependentes da conclusão de um âmbito de trabalho conhecido. Portanto, criar o cronograma de tal forma que a atividade sucessora é associada a uma área conhecida e concluída de trabalho está bem, pois não é o futuro estimado de conclusão de um âmbito de trabalho, mas um âmbito completo de trabalho.
 

Em Suma

É simples entender os desfasamentos, mas ambos lags e leads podem não ser a melhor maneira de definir as relações entre as atividades num plano. É melhor para as atividades sucessoras basearem-se na conclusão de uma atividade de trabalho conhecida.

Em seguida, pode prosseguir com o trabalho de suas atividades em paralelo para acelerar a sua programação. Mas, para iniciar uma atividade sucessora após um período de tempo de trabalho na predecessora não vai garantir que tenha sido feito progresso suficiente com sucesso para permitir prosseguir com a atividade sucessora. E certamente não quer basear a atividade sucessora numa futura conclusão estimada de âmbito predecessor de trabalho. Isto não oferece a transparência que é requerido para um cronograma eficiente.

Se for possível criar o cronograma de tal forma que as atividades sucessoras são iniciadas com base no âmbito antecessor de trabalho concluído, como no caso de um Finish-to-Start com desfasamento positivo ou com um desfasamento positivo em Start-to-Start. Assim o cronograma irá oferecer a transparência e a eficácia necessárias para uma bem-sucedida Implementação. Vai evitar as ineficiências das equipas mobilizadas a ter que esperar que as atividades predecessoras sejam concluídas com margem suficiente de trabalho para a execução de sua atividade sucessora.

Baseado em TenSix Consulting

Medir o Progresso: os 6 métodos que deve conhecer

Por Reshma Sadhu, traduzido para português

Medir o progresso de um projeto com precisão é sempre um desafio. Há muitos fatores para ter em atenção numa atualização de progresso - tipo de medição, a precisão dos dados, a frequência da recolha e o sistema de registo são todos fatores importantes para medições precisas de progresso.
E os pacotes de software como Primavera P6 nem sempre nos ajudam. Claro que há 3 escolhas para a Percentagem de Conclusão, mas como decidimos qual delas funciona melhor e em que condições?
O progresso impreciso vai frustrar a capacidade de detetar os sinais precoces de problemas à frente, assim para evitar isso aqui estão os 6 métodos comuns para medir o progresso do projeto que irão ajudá-lo a ter um melhor desempenho na medida da performance do trabalho e sua conclusão. Os métodos abaixo são resumidos a partir de “Project Control: Integrating Cost and Schedule in Construction,” by Wayne Del Pico.

 

Unidades Concluídas

As unidades concluídas de trabalho (Labor) prestam-se bem para o acompanhamento de atividades que são feitas repetidamente, onde cada iteração pode facilmente ser medida. Normalmente, uma atividade que é feita repetidamente tende a ter aproximadamente a mesma quantidade de tempo, recursos e esforço, de modo que rastrear as unidades concluídas é bem fácil. Um exemplo simples pode ser a instalação de luminárias padrão. Cada equipamento leva aproximadamente o mesmo período de tempo; se tivéssemos 100 luminárias para instalar então poderíamos simplesmente contar as unidades instaladas. Neste caso, não há envolvido nenhum julgamento subjetivo baseado na experiência.

 

Milestones incrementais

Também conhecido como o método dos "passos", o método de milestones incrementais é predominantemente utilizado para contas de custos que envolvem sub-atividades que precisam ser concluídas de forma ordenada. Um exemplo desta técnica é a formação e colocação de uma parede de fundação de betão.

Então, como calcular esses dados? O cálculo é construído em cada etapa item único e valor orçado de tempo (horas de trabalho), que é necessário para completar a atividade, a equipe de construção. À medida que cada passo esteja concluído, é documentada como uma mini-marco que representa uma percentagem do processo de instalação total. O percentual determinado para cada sub-atividade pode variar de acordo com o projeto e este progresso é geralmente acordado para ser usado como uma medida de antemão. Uma boa maneira de implementar este método em Primavera P6 está usando Activity Steps.

 

Início / Fim

Este método só está focado em capturar o ponto de partida e o ponto de chegada da atividade e nada entre estes pontos. Este método é melhor para as atividades que são de curta duração. Implementará esse método se as estimativas de trabalho da atividade não estão disponíveis ou se os dados de progresso completo em percentagem são muito difíceis de recolher.

Usando a técnica de Início / Fim ganha uma percentagem do progresso quando a atividade começa e a outra metade é ganha quando a atividade estiver concluída. Essas percentagens são determinadas pelo proprietário e contratante do projeto.
Muitas vezes, as empresas comprometem-se a usar a Regra padrão 50/50 ou outras regras:

Regra 50/50 - uma vez iniciada a atividade é marcada como 50% concluída, e a outra metade é ganha à conclusão final do trabalho.

Regra 20/80 - usada para controlar atividades de maior valor que toma mais tempo para chegar a conclusão.

Regra 0/100 - a regra ilustra que só quando 100 por cento da atividade estiver concluída, o valor é ganho.

 

Rácio de Custo

O método Rácio Custo é normalmente implementado num projeto que tem atividades que tendem a ocorrer ao longo de uma longa fase ou durante todo o projeto. Muitas vezes usada para despesas gerais, esta técnica é medida com base na alocação orçamentada em dólares contra as horas de trabalho de produção. Este método dá ao empreiteiro a capacidade de ganhar valor correspondente à percentagem global de conclusão do projeto.

No Primavera P6 é obtido pela utilização de atividades do tipo Level of Effort.

 

Experiência / Opinião

Ao contrário dos métodos acima que dependem de dados definitivos, este método baseia-se na experiência e subjetividade do gestor de projeto. Não é geralmente recomendado e tende a ser visto como o último recurso, porque as experiências e opiniões de cada indivíduo variam entre si e podem causar conflito entre proprietários, empreiteiros e arquiteto.
 

Unidades Ponderadas ou equivalentes

Este método foi destacado como a melhor técnica e é o que exige mais esforço, mas também se estende a uma gama mais ampla de dados. As atividades que estão sendo calculadas tendem a ocorrer ao longo de um tempo de duração mais longa e incluem várias sub-atividades, que podem ter diferentes unidades de medidas.
A fim de concluir este projeto que exige várias unidades, horas de trabalho, recursos e sub-atividades e, para calcular as sub-atividades, é ponderada um nível estimado de esforços em horas de trabalho ou em valor monetário que é específico de cada sub-atividade. Uma vez que o valor ponderado é determinado, este é convertido para refletir o valor em unidades de medida específicas para a atividade. Após o que se atribui unidades equivalentes de percentagem de conclusão do projeto global.

Estes 6 métodos para medir o progresso do projeto são comummente usados em gestão de projetos de construção e são filtro para um processo de determinar a percentagem de conclusão para o projeto como um todo com Earned Value Management.

Qual destes métodos usa mais nos projetos?

Opções de Schedulling em Primavera

A Opção Retained Logic será a melhor para usar com Primavera P6?

O Primavera P6 tem três opções de agendamento para selecionar quando você programa o projeto. Retained Logic é a opção de agendamento standard. Quando constrói o seu plano base, a opção standard funciona bem. Mas as coisas mudam quando começar a atualizar o projeto, as atividades começam a ficar atrasado e não são executados como planeado. Você então tem que tomar uma decisão sobre se quiser continuar a usar a Retained Logic ou escolher Progress Override ou Actual Dates como a opção de agendamento. Muito se tem discutido nos fóruns da internet sobre qual a opção é melhor para um projeto e a de Retained Logic ganhou com uma maioria esmagadora. Mas podemos ter uma opinião diferente. Ora vamos ver?

Será que o seu projeto seguiu alguma vez a lógica exata que foi planeada no plano base?

Se o projeto tem seguido a lógica exata como planeado no plano base, então você é um planeador incrível e você não precisa de continuar a ler. Mas, na minha experiência, na maioria das atividades dos projetos não são executados exatamente como planeado na baseline. Algumas começam mais cedo do que o planeado, algumas começa mais tarde do que o previsto e algumas podem ficar atrasadas durante a execução. É aqui onde as opções de agendamento no Primavera desempenham um papel importante. A escolha de diferentes opções de programação muda a forma como mecanismo de agendamento do Primavera executa os cálculos para a Forward Pass e Backward Pass. Isso, então, muda a forma como as datas são calculadas para as atividades no projeto e tem um impacto sobre a data de conclusão.

As 3 opções de Scheduling no Primavera são:

1. Retained Logic
2. Progress Override
3. Actual Dates

Utilizamos um exemplo em que temso 3 atividades com os nomes Activity A, Activity B e Activity C. Estão ligadas por relações de Finish to Start. Vamos atualizá-las fora de sequência e calculamos o projeto com todas estas 3 opções de scheduling e verificamos que impacto isto tem no projeto.

1. Retained Logic – assume que pretende reter a lógica das suas relações quando calcula o projeto. Isto significa que a duração remanescente de atividades em progresso não é calculada até o predecessor estar concluído.

Vamos ver o exemplo e ver como isto funciona. Atualizamos as atividades fora de sequência nas datas seguintes:

Pode ver acima que a Ativicty B foi atualizada fora de sequência, mas a Activity A ainda está em progresso. Escolhemos, então, Retained Logic como a opção de agendamento e calculamos o projeto. Devido a Retained Logic, o Primavera assume que estamos mantendo a lógica das relações entre as nossas atividades, mesmo que as atividades estejam a ser atualizadas fora de sequência. Isto significa que o Primavera calcula o Início Remanescente da Activity C por força da lógica Finish-to-Start com a Activity A (e não Ativity B). Isso faz que a Activity C em não-trabalho entre o período de 1-Fev-15 a 5-Feb-15. O período de não trabalho pode ser visto no gráfico de Gantt abaixo:

Vamos rever os cálculos para este exemplo; a data date para o projeto é de 1-Feb-15. O mecanismo de agendamento calcula que para Ativity A terminar mais cedo restante é 06-Feb-15, devido a isso o restante início antecipado para Atividade C é calculado com 6-Feb-15. O mecanismo de agendamento é programado para manter a lógica para as relações e pega o início remanescente mais cedo para a Ativity C depois de terminara Activity A, porque a Activity B já está completa.

O período de não-trabalho calculado devido ao Retained Logic pode ser entendido como nenhum trabalho será realizado em Activity C entre o período de 01 de fevereiro a 05-de Fevereiro Este período de não-trabalho também adiciona um extra de 5 dias para a conclusão do projeto. Agora, os puristas podem argumentar que, nesses casos, devemos mudar a lógica da atividade porque a lógica de fato mudou. Mas se suas obrigações contratuais não permitem que você faça alterações no projeto atual, sem a aprovação do cliente, pode então forçá-lo a manter as suas relações fixas e diminuir o remanescente da duração da atividade para ajustar o período de não-trabalho.

2) Progress Override – esta opção de agendamento assume que a rede lógica pode ser ignorada no caso de atividades fora de sequência e que a duração remanescente da atividade pode ser agendada de imediato. Isto significa que o motor de agendamento do Primavera irá ignorar a lógica das relações entre as atividades e agendar as atividades sem períodos de não trabalho.

Para o nosso exemplo isso significa que a Activity C não terá um período de não trabalho e que a duração remanescente da atividade será agendada desde a data date do projeto como vemos no gráfico abaixo.

Vamos rever os cálculos para este exemplo: a data date para o projeto é de 1-Feb-15. O mecanismo de agendamento calcula que para Activity A ta Data Remanescente de Fim mais cedo é 6-Feb-15 e a Activity B está completamente terminada. Devido a isso a duração remanescente da Activity C está prevista a partir de 1-Feb-15 e a relação lógica da Activity A é ignorada. Como não há período de não-trabalho na Activity C esta termina em 19-Feb-15.

É evidente a partir do exemplo acima que o Progress Override reduz a duração do projeto por cinco dias, não adicionando o período de não-trabalho. Isso parece lógico de acordo com o trabalho que está sendo feito no projeto, como pode estar a trabalhar na Activity C continuamente e ao contrário da Retained Logic não haverá período de não-trabalho.

3) Actual Dates – esta opção de agendamento usa as Datas Reais para os cáculos de Forward Pass e Backward Pass.

Quando escolhe a opção de Actual Dates o mecanismo de planeamento faz o Forward Pass e Backward Pass com base nas datas reais. Isso significa que você pode atualizar uma atividade com um início real e conclusão real após a Data date e o Primavera irá agendar as atividades sucessoras com base nas datas reais da atividade. Para este exemplo vamos terminar Activity B após a data date do projeto.

Na imagem acima, podemos ver que a data date (linha azul) é de 1-Feb-15, o que é antes do início da Activity A mas a Activity B terminou em 14-Feb-15, após a data date. AActivity C é então programado após o fim da Activity B e começa em 14-Feb-15.

Vamos rever os cálculos para este exemplo: a data date para o projeto é de 1-Feb-15.A Activity B terminou em 14-Feb-15, mas tanto a Activity A e Activity C não progrediram. Quando calculamos o projeto em 1-Feb-15, a o algoritmo de programação calcula a Activity A partir de 01-fev-15 (data date) como a atividade não tem predecessor mas a Activity C está agendada a partir de 14-fev-15 porque a Activity B tem um fim real em 14-Feb-15. Este método elimina a lógica fora de sequência do projeto.

A opção de Actual Dates pode ser usada para fixar datas para as atividades que você sabe que vão acontecer no futuro com certeza. Pode ser usada em situações em que sabemos que com certeza uma atividade termina em datas fixa e queremos agendar as atividades sucessoras após essa data real. Embora este tipo de coisa não costume acontecer em projetos, podemos usar esta opção para preparar alguns cenários hipotéticos.

Depois de vermos os exemplos acima, agora sabemos que Retained Logic e Progress Override são as duas principais opções que podemos usar para agendar os projetos. Eu prefiro usar Progress Override sobre Retained Logic para agendamento em projetos, porque sei que este representa o cenário real. Ele não adiciona períodos de não-trabalho aos projetos dessa forma estendendo potencialmente a sua duração. Sei que muitos vão pensar de outra forma, por favor, comente abaixo se não concordar com a justificação.

Adaptação de texto de Amit Parmar em www.theprimaverablog.com

Acompanhar os Custos no Primavera P6

Está seguro que sabe como controlar os custos de agendamento em Primavera P6? Estamos familiarizados com o processo de atualização e acompanhamento de cronograma de atividades e seu progresso do ponto de vista do tempo, mas e então com o custo dessas atividades? Bem, o Primavera P6 tem funcionalidades disponíveis para realizar o controle do custo de mão de obra, equipamentos e recursos materiais. Também é possível acompanhar o custo das despesas específicas do projeto.

Neste post descreve-se o processo de acompanhamento do custo de recursos de trabalho num projeto. É considerado um programa em que todas as atividades estão no caminho crítico, portanto, um atraso em qualquer atividade resultará tanto num aumento de custos da atividade como nos custos de gestão de projeto. O exemplo também pressupõe que você quer saber o custo do trabalho de projeto real incorrido numa base semanal. Isso inclui a adição de custos de gerenciamento de projetos para a atualização semanal.

Na Figura 1 vemos o projeto em que vamos acompanhar os custos de trabalho (labor) de forma semanal.

Figura 1

Note que temos três atividades de 5 dias que estão ligadas por meio da relação padrão Finish-to-Start. Estas atividades estão todas no caminho crítico. Temos também uma atividade de nível de esforço de 15 dias para a gestão de projeto. O tipo de duração das atividades não é importante. Porque não estamos a adicionar recursos adicionais, a atribuição de tipos de duração não é importante, e pode ser deixado no padrão, o que para o nosso calendário é Fixed Duration and Units / Time. Além disso, a baseline foi definida. A baseline é apresentada como uma barra amarela no gráfico de Gantt. Além disso, observe a coluna BL Project Labor Cost na Figura 1. Esta é a baseline para os custos do trabalho, e é definida quando a baseline é atribuída.

Status da Semana Um

A Atividade A é progredida como se vê na Figura 2.

Figura 2

Ela é concluída durante os 5 dias de trabalho programados. Note que o custo do trabalho real é atualizado automaticamente na Figura 2. O Baseline Prtoject Labor Cost e o ãctual Labor Cost são os mesmos, de modo que a variação é zero. Na Figura 3, o nível de esforço de gestão de projeto é atualizado para refletir os 5 dias de esforço de gestão de projeto.

Figura 3

A data date é avançada uma semana como mostra a Figura 4.

Figura 4

Status da Semana Dois

A Figura 5 mostra a atualização da atividade B.

Figura 5

Esta atividade foi programada para ser completada em 5 dias, mas no final da semana a atividade foi progredida apenas em 60%. Isso reflete-se no custo do trabalho real e remanescente. Os valores do custo do trabalho real para a atividade B tem de ser introduzidos manualmente. Na Figura 6 atualiza-se o esforço de gestão de projeto para refletir 5 dias de trabalho adicional.

Figura 6

Depois de avançar a data date, na Figura 7, vemos que a duração At Complete do esforço de gestão de projeto é de 17 dias, mais dois dias dos que o esforço inicial de 15 dias.

Figura 7

Digitar manualmente o custo do trabalho remanescente para gestão de projeto, que é de 7 dias de trabalho que custam 5.320 dólares. A variação do cronograma é de 1.520 dólares na atividade de gestão de projeto, o que reflete a duração adicional de 2 dias. Além disso, observe a variação do cronograma de $ 3,648 para a atividade B, que também reflete a duração adicional atividade 2 dias.

Status da Semana Três

Na Figura 8 concluímos a atividade B.

Figura 8

Note, de novo, que a variância de agendamento de $ 3,648 para cobrir os dois dias adicionais requeridos para concluir a «atividade B. A atividade C é inciiada na Figura 9.

Figura 9

Aqui vamos realizar 60% do esforço em três dias, o que mostra que esta atividade está dentro do orçamento. No entanto, está atrasada dois dias devido ao atraso no cronograma de 2 dias porque a atividade B levou mais tempo do que o planeado. Na Figura 10, atualiza-se o esforço de gestão de projeto.

Figura 10

Precisa inserir manualmente os custos de trabalho reais e remanescentes. Digite o custo real do esforço de $ 11,400 de gestão de projeto; o custo inicialmente previsto. Digite o custo de gestão de projeto remanescente de 1.520 dólares, o que representa a duração adicional de 2 dias. Na Figura 11 avança a data date uma semana para o início da semana de quatro.

Figura 11

Status da Semana Quatro

Na Figura 12 introduzimos o status para o fim do projeto.

Figura 12

A Atividade C, embora atrasada, conclui-se no orçamento depois de 5 dias de trabalho. A atividade de gestão de projeto é de 2 dias mais de orçamento devido ao atraso na Atividade B. Inserir manualmente o custo do trabalho real para gestão de projeto, Figura 13.

Figura 13

Este é o custo do trabalho orçamentado para o esforço de gestão de projeto, que é o custo original 11.400 dólares mais dois dias adicionais de trabalho para um custo de gestão de projeto real de $ 12.920. Avançar a data date pela última vez na Figura 14.

Figura 14

Observe na Figura 14 que a variância para o esforço de gestão de projeto é 1.520 $, Atividade A $ 0, Atividade B 3,648 $, e Atividade C $ 0. O projeto foi concluído com um custo adicional de trabalho de 5,168 $ como resultado dos dois dias adicionais necessários para completar a atividade B. Assim, o projeto completa-se com dois dias de atraso e 5,168 dólares acima do orçamento.

A vantagem deste tipo de processo de atualização do cronograma é que você pode ver o início de variação de custo a partir das duas semanas. Isso fornece um aviso antecipado para o gestor do projeto, que pode, então, procurar formas para realinhar a programação através de técnicas, tais como a compressão de cronograma de atividades.

Em suma

Logo que as atividades, as relações correspondentes e os recursos foram incorporados ao programa em P6, você está pronto para definir a baseline. Esta inclui tanto as atividades no gráfico de Gantt, bem como os valores em dólares nas colunas da vista da baseline.

As Baselines de custos disponíveis incluem: BL Project Labor Cost, BL Project Material Cost, BL Project Nonlabor Cost, BL Project Expense Cost e BL Project Total Cost. Ao definir a baseline congela-se os valores mostrados nestas colunas de atividade.
As colunas de custo da baseline, juntamente com as colunas de custo real e variância permitem controlar o custo do projeto. Note que quando uma atividade demora mais tempo do que o planeado tem que digitar manualmente o custo do trabalho real para a atividade. Além disso, as atividades se atrasaram terão um custo de trabalho equipe de trabalho para cada dia adicional.

Você também vai incorrer em custos de trabalho de gestão de projeto para cada dia adicional. O esforço de gestão de projeto expande-se contrai-se de acordo com a expansão e contração do caminho crítico. Vamos ter uma visão geral do custo do trabalho do projeto por meio de relatório de custos que inclui B BL Project Labor Cost, Actual Labor Cost, and Variance – BL Project Labor Cost Estes custos de labor podem ser atualizados e reportados numa base semanal, como feito neste post, o que deverá fornecer alerta antecipado suficiente quando o custo do trabalho do cronograma está a desviar do orçamento previsto.

As Datas Planeadas (Planned Dates) em Primavera P6

O Primavera P6 tem alguns campos de data que são muitas vezes incompreendidos. Não deve existir um campo mais estranho do que a data ´’planeada’. Ora vejamos, existirá sempre um início previsto e uma data de fim planeadas em associação com cada atividade.

Num cronograma sem progresso (ou o que tradicionalmente se chama de "plano base") o seguinte é sempre verdadeiro:

• Planned Start = Iniciar
• Planned Finish = Concluir

Mas quando o progresso é registado, no entanto, isto deixa de ser verdade. As datas previstas não irão refletir as datas reais. O Primavera P6 mostra datas reais nas colunas de início e fim, tornando mais fácil ver quais as atividades que tem progresso sem ter que adicionar colunas de início real e fim real.

Aqui é onde fica interessante. Alterar a data programada para o início ou fim planeados numa atividade sem progresso vai alterar as datas de início e fim e também mover a barra no gráfico de Gantt. As regras são:

• Alterar o Início Planeado altera a data de início, mesmo que o início planeado seja antes da data de início original
• Alterar o Fim Planeado move a data de fim e muda a duração original para adequar
• Mudando a Data de Início e Fim Planeadas irá mover o início e fim em conformidade
• Não há outras atividades que sejam afetados por alterações nas datas planeadas de uma atividade.

Nada disso vai acontecer, no entanto, se a opção “Schedule automatically when a change affects date” esteja selecionada. Isso ocorre porque o cronograma do projeto apaga as alterações feitas nas datas planeadas sempre que calcula. Estas não são restrições, apesar de tudo. A lógica nunca foi modificada. O que pode parecer que as Datas Planeadas são um truque cruel.

Criamos a lógica por uma razão. Mover barras numa folha não é programar. A lógica é suposta determinar datas. Alguns constrangimentos ficam bem - embora alguns Clientes sejam inflexíveis em não ter nenhum - contanto que eles não causem uma interrupção no caminho crítico. Adiar o início de uma atividade crítica, obviamente, não faz sentido.

Note que se alterar a Data Planeada de Início ou de Fim numa atividade com o progresso, nada acontece. As datas Planeadas não vão mudar.

A alteração das datas planeadas, realmente, é uma má ideia. Mas vamos assumir que todos concordamos que algumas das datas num plano não estão certas. Então vamos gerir as datas usando as colunas planeadas e, em seguida, criar um plano base. Usamos a baseline como um guia para, em seguida, modificar a lógica e as durações para cumprir as novas datas. Mais ou menos como traçar um desenho em papel vegetal.

Mais sobre as Atividades Level of Effort em Primavera P6

As atividades Level of Effort (LOE) são utilizadas normalmente para definir um esforço que por si só não gera um resultado final, mas incorre no uso de recursos / custos para o projeto. Itens como gestão, higiene e segurança realizam-se todos os dias e usam os respetivos recursos, mas não estão no caminho crítico. Estes custos indiretos geralmente não são irrelevantes. Estes esforços podem significar uma importante parte do projeto, ou mesmo de todo o ciclo de vida. Estão também associados a outras atividades no projeto.

A modelagem destes esforços e custos de forma individual através da atribuição de recursos para todas as atividade, é proibitivo. Então, como é que facilmente podemos definir o esforço destas tarefas ao longo do ciclo de vida do projeto? Bem, o Primavera P6 tem as atividades do tipo Level of Effort para ajudar a modelar este tipo de trabalho de uma forma sem grande necessidade de manutenção, e que não interfere com o caminho crítico.

Vamos ver como modelar custos indiretos e de gestão administrativa que estão associados com o projeto, e que podem abranger parte ou a totalidade da duração do projeto.
 

Contabilização de Custos

As empresas têm diferentes formas de contabilização de custos administrativos. Os Guias de estimativa de custos, como o RS Means, colocam o overhead e os custos de lucro diretamente na taxa de pagamento padrão para cada um destes recursos. O Primavera P6 permite que você faça um item de linha para os custos administrativos e de gestão do projeto utilizando atividades LOE.

O Primavera P6 também permite distribuir estes custos, quer igualmente entre as tarefas do projeto ou com algum tipo de curva definido. Os custos de gestão de projeto são geralmente uniformes ao longo do ciclo de vida do projeto, enquanto os custos administrativos podem seguir uma curva em forma de sino. Ambas estas formas de distribuição podem ser modeladas em Primavera P6.
 

Esforços de Gestão de projeto e administrativos

A figura 1 mostra um projeto com atividades dependentes quatro Tarefa A, B, C, e D com relações normais de Finish-to-Start. Cada uma destas atividades são mostradas nos gráficos Gantt como barras vermelhas, o que indica que estas atividades estão no caminho crítico. Além disso, também vemos na Figura 1 duas barras do gráfico de Gantt adicionais: uma especificando o esforço de gestão de projeto e a outra os indiretos administrativos. Observe que, embora tanto a gestão de projetos como os custos administrativos abranjam toda a extensão do projeto não estão no caminho crítico, que é mostrada em vermelho.

Figura 1

Quer as atividades de gestão de projetos como a de recursos administrativos são predecessores para a primeira atividade A com uma relação de Start-to-Start e ambos são sucessores para a última tarefa D com uma relação de Finish-to-Finish, ver Figura 1. O que distingue a gestão de projetos e recursos administrativos de outras atividades é que eles têm um tipo de atividade de Level of Effort. Isto indica que eles não produzem resultados diretamente e, por conseguinte, são custos indiretos. Eles são, no entanto, os esforços que de toda a forma geram custos que precisam ser contabilizados.

Porque estas atividades de Level of Effort estão ligadas tanto à primeira atividade A como à última D ambas irão aumentar e diminuir em correlação direta com a expansão e / ou contração do caminho crítico do cronograma de projeto. Esta conexão de cada atividade Level of Effort para a primeira atividade e última atividade levou à designação dessas atividades que estão sendo chamados de ‘hammocks’. Como um exercício, tente aumentar a duração de qualquer atividade no caminho crítico. Note-se que a duração das atividades Level of Effort aumenta automaticamente em correlação com a duração do caminho crítico quando o projeto é calculado.
 

Curva de Distribuição do Esforço

O que delineia o esforço de gestão de projetos do esforço administrativo, além da taxa de pagamento por hora, é que o custo de gestão de projetos é uniforme ao longo do projeto, enquanto, os custos administrativos, neste exemplo provavelmente, irão seguir uma curva em forma de sino. Como descrever a distribuição não uniforme dos custos administrativos? O Primavera P6 permite associar uma curva com o esforço. Observe na Figura 2, que o separador Recursos dos detalhes do fundo tem uma coluna de curva para definir a curva do esforço.

Figura 2

Faça um clique da esquerda na célula Curve para ver a lista das curvas disponíveis, Figura 3.

O Primavera P6 permite que defina a sua própria curva, mas para o propósito deste projeto vamos selecionar a Curva Bell Shaped.

Figura 3´

Para ver a curva de custos administrativos em distribuição em Bell, selecione o ícone de Resource Usage Profile para alterar o painel inferior de detalhes.

Figura 4

Assegure-se que estão definidos os recursos do projeto corrente. Selecione Administrative da lista de Recursos. Defina, também, a escala de tempo do gráfico de Gantt para Week / Day. Selecione depois Project Management da lista de nomes de recursos e verifique que a curva é uniforme, Figura 5.

Figura 5
 

Em conclusão

Descrever as atividades que não produzem diretamente resultados e que se expandem e contraem com o caminho crítico é difícil de fazer em alguns programas de software de gestão. O Primavera P6, no entanto, tem o tipo de atividade Level of Effort que permite modelar os custos indiretos que se estendem na vida útil do projeto. Ela também é capaz de mostrar a expansão e contração do esforço na etapa com o crescimento ou redução da duração do caminho crítico.

O tipo de atividade Level of Effort é uma aparentemente pequena característica que se torna muito importante. Esta é mais uma razão pela qual Primavera P6 é muitas vezes escolhido como o sistema de planeamento de escolha, especialmente quando se faz a integração com sistemas de EVM.

Traduzido de Tensix