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:
- Retained Logic
- Progress Override
- 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
