Monitorizar as Datas de Deadline em P6 Professional

Praticar com a formatação de Barras

Traduzido e adaptado de Ten Six
Os projetos chegam com prazos; É um fato da vida. E o mais provável é que queira que o prazo seja exibido no gráfico de Gantt, juntamente com a data de conclusão da programação projetada. Sim, isto é possível no Primavera P6 Professional.

Se quiser que o prazo perdido possa gerar flutuação total negativa na tabela de atividades, deve consultar o blog Monitoração de Datas Previsíveis e de Conclusão de Contrato no Primavera P6.
Por outro lado, se tudo o que você quer é um marcador passivo do prazo no gráfico de Gantt continue a ler lendo. É possível no Primavera P6 Professional inserir um marcador de prazo passivo no gráfico de Gantt que não está ligado ao total float.

Neste Post descrevo como inserir um marcador de prazo passivo no gráfico de Gantt no Primavera P6 Professional.

Inserir um prazo passivo no gráfico Gantt exige um pouco de engenho com o diálogo Bars. Começamos na Figura 1 a definir três Campos Definidos pelo Utilizador (UDFs): UDF intitulado 'Deadline' e tipo de dados Texto; Um UDF intitulado 'Deadline Start' e tipo de dados Start Date; E um UDF intitulado ‘Deadline Finish' e o tipo de dados Finish Date.

Figura 1

Uma vez criados, queremos associar cada um com a Milestone de projeto completo, Figura 2, que é a data de fim atualmente agendada da programação do projeto.

Figura 2

Na tabela de atividades, adicione três colunas: deadline star, deadline finish e deadline. Nas duas primeiras colunas, insira o fim de prazo 2018-Jan-24 e fim de prazo. Sim, temos apenas uma data limite, mas precisamos digitar duas datas para definir uma barra de deadline. Na última coluna do prazo, insira o seu marcador preferido ou 'DEADLINE'.
Continuamos e vamos criar uma nova definição de barras, Figura 3.

Figura 3

Primeiro, observe as definições de pilha de barras. Para que isto funcione corretamente, a nova definição de barras de deadline precisa estar abaixo do milestone na pilha. Desta forma, as linhas de relação se conectam ao rótulo da milestone e não ao rótulo do prazo. As linhas de relacionamento mais altas na pilha têm precedência. O nome é Deadline, a escala de tempo é User Dates', a data de início do utilizador é Deadline Start UDF, a data de fim do usuário é Deadline Finish UDF. Defina o filtro como All Activities. Em seguida, o estilo de barra é como na Figura 4.

Figura 4

As formas finais são triângulos. A forma da barra do meio é nenhuma. Escolha cores e padrões apropriados para os triângulos. Na Figura 5, Inserimos dois rótulos de barras à direita: Deadline, que é o rótulo de texto e Deadline Finish.

Figura 5

Para que a rotulagem funcione corretamente, coloque o rótulo da barra de referência, Figura 6, para posicionar à esquerda e digite 'nome da atividade'.

Figura 6

Finalmente, na Figura 7, definimos o padrão 'atual barra rótulo' filtro para o normal, o que exclui milestones e atividades Level of Effort.

Figura 7

Com estas configurações, a tabela de atividades e o gráfico de Gantt associado são semelhantes à Figura 8.

Figura 8

Nota no diagrama de Gantt o triângulo azul claro com a indicação 'DEADLINE' e a data associada, 2018-Jan-24. Ótimo! Agora podemos facilmente observar que estamos à frente do plano; A data de conclusão do projeto é 2018-Jan-19 e a data limite é 2018-Jan-24. Observe também que o prazo é exibido na legenda.

As legendas funcionam bem quando a data de conclusão do projeto vem antes do prazo. No entanto, precisamos fazer alguns ajustes das legendas quando o prazo é ultrapassado. Conforme a figura 9 para um prazo passado, defina os marcos para exibir os nomes das atividades à direita.

Figura 9

Também definimos as legendas de Deadline para aparecer à esquerda, Figura 10.

Figura 10

O Deadline ultrapassado é visto assim na Figura 11

Figura 11

Em suma

Para criar um marcador de deadline passivos no Primavera P6 Professional, usamos os UDFs e a escala de datas das 'user dates' no diálogo de barras. Tanto o início do prazo como o fim do prazo foram definidos para a mesma data, já que nosso prazo é um único momento no tempo. Da mesma forma, o nosso estilo de barra de marcador de prazo não tem forma de barra média, apenas formas de extremidade, e triângulos, que são equivalentes.

Conforme demonstrado, é também possível marcar o deadline de prazo com um tipo de dados de texto UDF. Este texto UDF é atribuído ao marco ou atividade que tem o prazo. Outra maneira simples de rotular o marcador de prazo é inserir um anexo de texto clicando com o botão direito do mouse no gráfico de Gantt e selecionando Attachments | Text do menu pop-up. A rotulagem do marcador deadline não é dinâmica, e pode exigir ajustes, em conformidade, para os planos que batem o prazo ou planos que perdem o prazo.

Este método de exibição de prazos no gráfico de Gantt suporta a marcação de prazos múltiplos num único cronograma, embora a legendagem de vários prazos possa tornar-se mais complicada do que se preferiria. Além disso, no cenário improvável em que é especificado um intervalo de datas de prazo, é possível marcar esse intervalo de datas no gráfico de Gantt. Nesta situação, você vai querer definir um barra de estilo meio barra de conexão. Consulte o nosso blog Apresentação de uma barra de gráficos de Gantt no Primavera P6 para exibir um intervalo de datas aceitável no gráfico de Gantt.

Monitorizar as datas de conclusão prevista e de contrato

Adaptado para português de TenSix
O plano em Primavera P6 tem uma data vinculativa de constrangimento contratual externa que não coincide com a data prevista para a conclusão do projeto no seu plano. Devido a isso, precisa monitorizar a data de conclusão estimada do projeto e a data de conclusão vinculativa contratual no cronograma. Eis a melhor maneira de descrever ambas as datas no plano.

Planear é semelhante a escrever uma história sobre como um projeto será realizado. O início e a conclusão do cronograma também são um pouco como descrever o início e paragem de um comboio. Temos várias tarefas ou marcos que devem ter lugar para levar o comboio a obter velocidade. E várias tarefas ou marcos que descrevem o comboio a chegar a estações. O início pode ser descrito por um aviso de data para proceder à adjudicação do contrato seguido de um marco de início do projeto. Descrever o final, especialmente se você tem uma data de constrangimento de contrato que não coincide com a data estimada de conclusão do projeto pode ser um pouco mais importante.

Este artigo demonstra a melhor maneira de mostrar e monitorizar tanto a data estimada de conclusão do projeto como a data de conclusão vinculativa do contrato num plano em Primavera P6.

A situação ideal, que vamos modelar, é quando a data de conclusão do contrato fica mais tarde do que a data de conclusão do projeto. Na Figura 1 temos o um cronograma de demonstração em Primavera P6.

Figura 1

Este plano em P6 tem dois caminhos: o caminho experimental crítico e o caminho de modelagem não-crítico. Presentemente, definimos atividades críticas como aquelas que têm zero como folga total.
Queremos que o cronograma destaque tanto a data de conclusão estimada do projeto quanto a data de conclusão do contrato vinculativo. Para fazer isso, primeiro mudamos a designação 'project complete' para ‘project completion date’. Em segundo lugar, inserimos o marco de conclusão da atividade ‘contract completion date’, Figura 2.

Figura 2

Observe que modificámos a relação de fim (FF) entre ‘project completion date’. e ‘contract completion date’ adicionando um lag, Figura 2. Também ajustamos o lag (cinco dias), de acordo, de modo que a ‘contract completion date’ é concluída exatamente na data de conclusão específica do contrato. O atraso foi inserido porque, caso contrário, teríamos perdido o caminho crítico ou o caminho mais longo dependendo das opções de agendamento selecionadas.

Na Figura 3, inserimos uma restrição "Concluir Ligado" na "data de conclusão do contrato", de forma que seremos alertados pelo flutuador negativo quando a "data de conclusão do projeto" estimada for deslizada.

Figura 3

Definimos o caminho crítico como o caminho mais longo. Figura 4.

Figura 4

Fazemos isso para alinhar o plano com a preferência de algumas diretrizes de programação que funcionam como melhores práticas. Depois de recalcular o cronograma, vemos na Figura 5 que o nosso caminho mais longo apareceu.

Figura 5

Finalmente, na Figura 6, mostramos o que acontece quando introduzimos dados de progresso que atrasam a nossa "project completion date" estimada em três dias.

Figura 6

Bem, no gráfico de Gantt o atraso deslocou-SE simplesmente para a direita a "project completion date" e a "contract completion date". Assim, a partir do gráfico de Gantt não podemos dizer que há um problema. No entanto, a coluna de folga total da tabela de atividades exibe três dias de flutuação total negativa tanto na "project completion date" como na "contract completion date"", por isso sabemos que há um problema. A questão é até que ponto é mau o nosso atraso? A melhor maneira de dizer é mudando mentalmente a data de conclusão do contrato 'por três dias até sua data original, e observar que ainda temos dois dias entre a data atualizada de conclusão do projeto e a ‘contract completion date'. Portanto, ainda estamos no alvo.

É também possível reduzir o lag na ‘contract completion date' por três dias para ver o calendário com a original ‘contract completion date', Figura 7.

Figura 7

Agora podemos ver claramente no gráfico de Gantt a separação de dois dias entre ‘project completion date' e ‘contract completion date', porém também perdemos o aviso de flutuação total negativo. Mas tudo bem, sabemos que ainda estamos na frente do cronograma do contrato em dois dias.

Em suma

No Primavera P6, é possível apresentar tanto a ‘project completion date' prevista quanto a ‘contract completion date', de forma a fornecer um aviso quando a data estimada de conclusão do projeto for ultrapassada.

Quando inserir a ‘contract completion date' com um constrangimento ‘Finish On’, lembre-se de inserir uma quantidade adequada de atraso entre a ‘project completion date' estimada e a ‘contract completion date'. Desta forma, não perderá o caminho mais longo e / ou caminho crítico.

Mais uma reflexão, se quiser redefinir a ‘contract completion date' e ainda ver um deslizamento estimado ‘project completion date', pode colocar um constrangimento "Finish On" sobre a previsão de ‘project completion date'. Isto para além do constrangimento "Finish On" da ‘contract completion date'. Embora, inserindo esse constrangimento pode afastar o plano em P6 para longe das diretrizes de agendamento comuns, que tendem a ser muito particulares sobre a adição de constrangimentos.

Porque falha o uso do plano num projeto?

Os planos de caminho crítico são requisitos essenciais em qualquer projeto. Mas tornam-se errados invariavelmente quando, apesar das melhores práticas, a equipe não os usam na a sua atividade. A integridade do cronograma pode não ter nada a ver com o motivo pelo qual se tornou inútil ou sem sentido, ou como eu gostaria de dizer, um registrador mais do que um preditor do caminho crítico e do progresso. Se o projeto é grande e tem vários empreiteiros principais, a programação é tanto mais suscetível de degradação.

Muitas vezes, a falha da programação é previsível. Mesmo assim, pode parecer inevitável. No entanto, para cada obstáculo ao sucesso, há uma solução ou um caminho alternativo. Às vezes é mau remédio e difícil de tomar. Cabe ao planeador fazer tudo o que puder para manter a integridade do cronograma do projeto. O plano destina-se a destacar os obstáculos mais desafiadores para programar o sucesso e oferecer soluções.

Os cronogramas na construção são negligenciados, desconsiderados, mal entendidos e inúteis.

Voto de desconfiança

Muitos profissionais de construção troçam dos cronogramas, talvez como resposta a experiências passadas, ou mais frequentemente, o voto de não confiança é apenas destinado a mascarar a inexperiência que pode comprometer a sua imagem.

Reconheça que a programação é uma ciência que geralmente não é bem compreendida por não-planeadores. Ignore a crítica desconstrutiva, ou tome-a como uma oportunidade para um momento de formação.

Lapsos no Reporting

Muitos contratantes pensam que podem obter tudo com um plano de base e, posteriormente, o mínimo possível de atualizações. Eles não estão simplesmente a ser compelidos o suficiente pelo cliente.

Mantenha a o foco todos os meses para a atualização adequada do plano, mesmo que possa não estar disponível. Saliente junto do empreiteiro a importância de manter atualizações mensais, especialmente quando isto está diretamente ligado à capacidade de reclamação. Quando há falhas nos relatórios é mais provável a não aceitação de reclamações.

Erros de Reporting e omissões

Muitos empreiteiros gerais não mantêm registos precisos dos progressos e são forçados a adivinhar as datas atualizadas. Essas suposições podem mais tarde, se o cliente tem datas diferentes, voltar para os perseguir. Outros simplesmente não seguem as instruções básicas. Finalmente, acredite que é verdade, pelo menos é necessário um plano base em caminho crítico.

Todas questões acima podem ser evitadas com a um pouco de trabalho. Reforce junto do cliente a importância de manter o cronograma corretamente atualizado, mesmo que mais não seja para estar preparado em caso de uma reclamação.

Falta de liderança no nível executivo

Apesar de seus poderosos MBAs, graus de engenharia e certificações exaltadas, muitos grandes executivos nunca viram um gráfico de GANTT detalhado. Eles podem considerar-se pessoas “terra-a-terra" mas isso não mostra a sua competência com cronogramas CPM. Não.

O planeador será sempre mantido (pelo Empreiteiro Geral ou CM) tão longe quanto possível dos executivos do projeto, porque o conhecimento não contaminado é um passivo. De fato, os resumos executivos do plano não parecem chegar ao público-alvo pretendido antes de ficarem desatualizados e obsoletos. Essas circunstâncias estão fora do controle do planeador.

Política

Não é raro que os Empreiteiros gerais e os CMs desviem indevidamente relatórios de progresso para sua vantagem ou para ofuscar alguma outra realidade. Eles também irão manipular e procurar influenciar os relatórios de acordo com seus gostos, ou com a adaptação ao stakeholder final. Finalmente, podem simplesmente não emitir os relatórios para as partes interessadas.

Quanto ao primeiro ponto, é a integridade em questão quando se tornar consciente desta discrepância. Tem que fazer o que sente que é certo, e comunicar à parte interessada. Quanto ao último, não há nada que o planeador possa fazer para forçar o problema com as partes interessadas, ou até mesmo induzi-lo a publicar os resultados, como ele deveria.

Incompreensão

A gestão da construção e os membros desta equipe ignoram propositadamente o plano e o caminho crítico, o que pode ser prejudicial para o processo quando eles mostram a sua relutância em aprender - muito orgulhosos para aprender. Eles também carecem de visão técnica e analítica. Por exemplo, à medida que um projeto vai para o fim, o cronograma é, muitas vezes, referido como sendo "inútil, obsoleto", ou pior, como se a integridade do cronograma dependesse da oportunidade.

Novamente, aqui também tem que educar o seu público sobre a diferença entre o progresso projetado e o progresso real, e como a informação é disseminada através de um plano de progresso.

Falta de intenção declarada

Muitos empreiteiros pensam que o plano é uma exigência desnecessária do projeto. Como tal, eles planeiam apenas para percorrer os movimentos do trabalho de execução, com o mínimo esforço, e obrigando a um maior esforço de planeamento.

Lembre ao empreiteiro que manter o cronograma é como manter qualquer ativo que melhore o valor, na proporção de sua integridade, e que no caso de uma interrupção em que é considerada uma reclamação, será essencial um cronograma devidamente mantido e este será suficiente.

Ceder o Controlo do Projeto

Os planeadores e estimadores são o controlo de projeto. Ninguém mais, independentemente do seu título. Apesar desse fato, os gestores de projeto muitas vezes erroneamente tentam micro-gerir o desenvolvimento da programação, em vez de a facilitar. Noutras palavras, eles estão a assumir o "controlo" do "projeto": o que é o trabalho do planeador. Os resultados são muitas vezes desastrosos.
Lembretes frequentes, geralmente, induzem os gestores de projeto a ser mais proativos com os planos em CPM. Diga-lhes quando cruzam a linha, ou quando eles pensam fora da caixa, e devemos esforçar-nos para os educar nas melhores práticas.

Rejeição

Muitos revisores que analisam planos apresentados, deliciam-se em rejeitar e proceder ao reenvio do plano. Às vezes, por uma questão de atitude legalista: ou seja, eles acreditam que, ao rejeitar qualquer plano determinado ganham alguma alavancagem contratual por considerar o empreiteiro em não conformidade.

Se a integridade da programação está intacta e você tem passado através de todos os passos das especificações, simplesmente não é apropriado para um revisor rejeitar um cronograma com base em questões técnicas mínimas, ou exigir um cronograma de recuperação, quando há atrasos compensáveis.

Se este é o padrão, você tem que perceber que o revisor está contra o pedido de interrupção. Pode até ser em seu detrimento emitir um cronograma de recuperação ou cronograma de reclamação antes de tempo – mostrando a intenção.

Negligência intencional

Até pode estar tudo bem ... e um empreiteiro geral pode não ter nenhuma intenção de manter a programação a partir do lançamento da obra. Esta condição é uma em que o planeador pouco pode fazer para mudar, além de ser persuasivo da melhor maneira que ele pensa que pode fazer, sem hostilizar o cliente. Além disso, pode até ser que ninguém no nível executivo se oponha à ausência de atualizações de plano e de relatórios, como não parecem entendê-los ou, pelo menos, revê-los em tempo útil, até se percebe!

Constrangimentos dos projetos e o Caminho mais longo

Tradução de post de Ten Six

Se quer otimizar a programação é vantajoso olhar como diminuir a duração de atividades que estão ao longo do caminho crítico. Mas o que fazer se tem um constrangimento de projeto que faz com que seu software de agendamento em qualquer caso mostre caminhos críticos múltiplos ou esconda completamente o verdadeiro caminho crítico?

Declara-se geralmente que uma atividade é fundamental, se não puder ser adiada sem afetar a data de fim do plano. Bem, existem exceções para cada regra. E neste caso, a exceção é que a atividade não pode ser adiada sem afetar a data de constrangimento da atividade, como um 'Finish on or Before’ como data de constrangimento. Aqui, a atividade crítica não causa o escorregar da data de fim do projeto, mas sim uma data de atividade constrangimento intermédio.

Assim, uma atividade crítica pode não estar, necessariamente, sobre o caminho mais longo através da rede. Consulte o blog para uma discussão detalhada sobre o caminho mais longo, para discussões adicionais sobre como Primavera P6 lida com os dois distintos métodos de cálculo do cronograma.

O Project Management Institute do (PMI) “The guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition” define o caminho crítico como "a sequência de atividades que representa o caminho mais longo através de um projeto, que determina a duração mais curta possível. As atividades críticas não têm necessariamente de cair ao longo do caminho crítico, ou seja, o caminho mais longo.

Note-se que os termos "caminho crítico" e "caminho mais longo" são muitas vezes utilizados alternadamente. Tecnicamente, no entanto, eles não podem ser o mesmo. O caminho crítico irá mostrar todas as atividades com zero ou menos de folga total, que normalmente contém um caminho através de toda a rede. No entanto, o caminho mais longo é o caminho mais direto ininterrupto desde a primeira atividade no plano até à última, e como tal pode não exibir as mesmas atividades críticas como no caminho crítico.

Isto é importante notar, porque para otimizar ou encurtar sua programação pretende encurtar as atividades que estão no caminho mais longo através da rede. A maioria dos programadores deseja exibir todas as atividades críticas se eles estão no caminho mais longo ou não. Assim, cada atividade que não pode ser adiada sem afetar datas intercalares do projeto definidas ou a data de conclusão do projeto será sinalizada.
Esta é a configuração padrão na maioria dos programas de software de programação, e, em particular, do Primavera P6 Professional. Mas se você esperar para otimizar a programação, então quer se concentrar sozinho no caminho mais longo.

Este artigo descreve como isolar o caminho crítico na Primavera P6 Professional em apoio aos esforços de otimização da programação.

Começamos com um plano de exemplo na Figura 1:

Figura 1

Temos aqui dois caminhos: um seguindo testes experimentais e o outro seguindo modelagem analítica. Estes dois caminhos convergem para análise do modelo, onde os dados experimentais e analíticos são comparados. A configuração de folga total normal em P6 Professional define as atividades críticas como tendo zero ou folga total negativa.
À luz disto, notar aqui que as atividades ao longo do caminho da modelagem analítica têm cada 3 dias de folga total e, por conseguinte, não são críticas. Além disso, as atividades ao longo do caminho experimental cada um tem 0 dias de folga total e são críticos. Mais importante ainda, é evidente que o caminho experimental é o caminho mais longo através da rede, e deve ser onde se concentrar os nossos esforços de otimização.

Efeitos dos Constrangimentos

Veja o que acontece ao nosso plano quando introduzimos um constrangimento que fica fora da lógica natural da data de fim. Figura 2.

Figura 2

De repente, todas as nossas atividades são críticas e parece que temos dois caminhos críticos. Então, como vamos saber onde concentrar a otimização da programação?
Note que não ativámos a opção Multiple Float Path na caixa de diálogo Opções avançadas de agendamento.
Vamos dar mais um constrangimento ao projeto. Veja o que acontece quando se aplica uma constrangimento de projeto que cai para além da lógica de rede, Figura 3.

Figura 3

Desta vez, todas as nossas atividades têm float, e o caminho crítico fica escondido. Mais uma vez, é difícil ver como encurtar o cronograma?

Em ambas as situações, podemos encontrar o caminho mais longo (ou caminho crítico), alternando as opções de agendamento "definem atividades críticas como ..." configuração padrão para a configuração caminho mais longo, a Figura 4.

Figura 4

Demasiados Caminhos

Agora quando parece que temos demasiados caminhos podemos procurar e mostra o verdadeiro caminho mais longo, utilizando a configuração de Longest Path.

Figura 5

Observe na figura que todas as atividades ao longo do caminho mais longo (mostrado em vermelho) têm folga total de menos de 3 dias. Atividades com folga zero total, que normalmente são definidas como atividades críticas por padrão, não são exibidos em vermelho porque eles não estão ao longo do caminho mais longo. Aqui apenas as atividades do caminho mais longo são definidas como críticos, independentemente de folga total.

Caminhos Escondidos

Quando todas as atividades têm fo9lga e o caminho mais longo (ou o caminho crítico) fica escondido, use a configuração de longest path para mostrar o caminho mais longo.

Figura 6

Neste exemplo, a folga total de atividades ao longo do caminho mais longo é 1-dia. Usando o padrão de folga total para definir essas atividades com folga total de 1 dia elas seriam normalmente definidas como não-críticas. Mas, sob o caminho mais longo definido eles são críticos, independentemente da sua folga total. Outras atividades não relacionadas com o caminho mais longo tem folga total de 4 dias. Mais uma vez, o fator determinante é o seu caminho e não a sua folga total.

Em Conclusão

O que aprendemos com o caminho mais longo? Bem, quando está no processo de otimizar a programação deseja definir as opções de agendamento para caminho mais longo, porque isto é particularmente útil para encurtar as durações que têm muitas atividades.

Mais uma vez, a opção do caminho mais longo define todas as atividades críticas como sendo aquelas que estão ao longo do caminho mais longo. Mais tarde, quando a programação está otimizada pode definir as opções de agendamento para estabelecer as atividades críticas como tendo folga total de zero. Desta forma, irá marcar todas as atividades do caminho mais longo e todas as atividades acima de encontro a uma data de atividade constrangimento provisório. Assim, todas as atividades em perigo de atrasar, tanto datas de constrangimento intermediários ou a data de fim do projeto são sinalizadas.
Finalmente, certifique-se de documentar qual a opção de agendamento que escolheu (caminho mais longo ou folga total) para a sua programação antes de enviá-lo para as partes interessadas no projeto.

Será que a opção de Retained Logic é a melhor opção de agendamento?

Tradução de artigo por Amit Parmar

O P6 tem três opções de cálculo do agendamento (Schedule) para escolher quando calculamos o agendamento. A opção de Retained Logic é a opção padrão. Quando estamos a construir um Plano Base (Baseline), a opção padrão funciona muito bem. Mas as coisas mudam quando se começa a atualizar o progresso no projeto, atividades começam a ficar atrasadas e a não serem executadas conforme planeado. Nessa altura tem de tomar uma decisão se continua a usar Retained Logic ou escolhe Progress Override ou  Actual Dates como as opções de calculo do agendamento. Muito se discute em fóruns da internet sobre qual a opção que é melhor para um projeto e Retained Logic venceu com uma maioria esmagadora. Mas eu tenho uma opinião diferente.

Será que o projeto seguiu sempre a lógica exata que planeou plano de base?

Se o projeto seguiu a lógica exata como planeado no plano base, então é um planeador incrível e não precisa mais continuar a ler este post no blog. Mas, na minha experiência, a maioria das atividades dos projetos não são executadas exatamente como planeado no plano base. Algumas começam mais cedo do que o planeado, algumas começam mais tarde do que o previsto e algumas podem ficar atrasadas durante a execução. Este é onde as opções de agendamento em Primavera desempenham um papel importante. Escolhendo diferentes opções de programação mudamos a forma como mecanismo de agendamento do P6 a executa os cálculos das passagens para a frente passar e para trás. Isso, então, muda a forma como as datas são calculadas para as atividades no projeto e tem impacto sobre sua data de conclusão.

As três opções de agendamento disponíveis no P6 são:

• Retained Logic

• Progress Override

•  Actual Dates

Para ilustrar este post vamos assumir que temos 3 atividades: A, B e C. Estão ligadas por relações Finish to Start (FS). Vamos atualizá-las fora de sequência e calcular o agendamento com as três opções e vermos o impacto que tem no projeto.

1. Retained Logic – Assume que pretendemos reter a lógica das relações entre as atividades quando calculamos o projeto. Isto significa que a duração remanescente das atividades em progresso não são calculadas até todos os predecessores estarem concluídos.

Retained Logic – Retem a Lógica das relações durante o cálculo do projeto

Vamos ver o nosso exemplo e ver como trabalha. Atualizámos as nossas atividades fora da sequência nas seguintes datas:

Pode ver acima que a Atividade B foi atualizada fora de sequência, mas a Atividade A está ainda em andamento. Em seguida, escolha Retained Logic como a opção de agendamento e agendar o projeto. Devido à opção escolhida, o Primavera assume que estamos a manter a lógica das relações entre as atividades, embora as atividades estão a ser atualizados fora de sequência. Isto significa que o Primavera calcula o Início remanescente da Atividade C de acordo com a lógica Finish-to-Start com Atividade A (e não com a Atividade B). Isso faz que a Atividade C tenha um período de não-trabalho entre o período de 1-Feb-15-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 (Data de Dados) para o projeto é 1-Feb-15. O mecanismo de agendamento calcula que, para a Atividade A terminar mais cedo o tempo restante é 06-Feb-15, devido a isso, o início antecipado para Atividade C é calculado com 6-Feb-15. O mecanismo de agendamento tem como orientação para manter a lógica para os relacionamentos e escolhe o início antecipado restante para Atividade C depois do tempo mais cedo remanescente terminar da atividade A porque Atividade B já está concluída.

O período de não-trabalho calculado devido a Retained Logic pode ser mal interpretado como, nenhum trabalho será realizado na Atividade C entre o período de 01 de fevereiro-15 e 05-Feb-15. Este período de não-trabalho também adiciona de 5 dias extra 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 mudou realmente. Mas se as obrigações contratuais não permitem que você faça alterações no projeto corrente sem a aprovação do cliente, então pode forçá-lo a manter os relacionamentos fixos e diminuir a duração restante da atividade para ajustar o período de não-trabalho.

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

Progress Override - assume que a lógica de rede pode ser ignorada para atividades fora da sequência

Para o exemplo, isto significa que, a Atividade C não terá um período de não-trabalho e a duração restante da atividade será agendada a partir da data de dados do projeto, como visto na imagem abaixo.

Vamos rever os cálculos para este exemplo: a data dos dados para o projeto é de 1-Feb-15. O mecanismo de agendamento calcula que, para a Atividade A terminar mais cedo o tempo restante é 6-Feb-15 e a Atividade B está completamente concluída. Devido a isto o período remanescente da Activity C está prevista a partir de 1-Feb-15 e a relação lógica da Atividade A é ignorada. Como não há período de não-trabalho na Atividade C, esta termina em 19-Feb-15.

É evidente a partir do exemplo acima que o Progress Override reduz a duração do projeto por 5 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 trabalhando em Atividade 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 Actual Dates para os cálculos para a frente e para trás do agendamento.

Actual dates – Usa as datas reais para os cáculos

Quando escolher a opção de datas reais, o mecanismo de agendamento faz o passe para a frente e passe para trás 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 de Dados e o Primavera P6 irá agendar as atividades sucessoras com base nas datas reais da atividade. Para este exemplo vamos terminar a Atividade B após a data de dados do projeto.

Na imagem acima, podemos ver que a Data de Dados (linha azul) é 1-Feb-15, que é antes do início da Atividade A, mas a Atividade B terminou a 14-Feb-15, após a Data de Dados. A Atividade C é então programada após o terminar da atividade B e começa em 14-Feb-15.

Vamos rever os cálculos para este exemplo: A data de dados para o projeto é de 1-Feb-15. A Atividade B terminou a 14-Feb-15, mas tanto a atividade A e a atividade C não tem progresso. Quando agendar o projeto em 1-Feb-15, o motor de agendamento da Atividade A partir de 01-fev-15 (data de dados) como a atividade não tem predecessor, mas a Atividade C está prevista a partir de 14-fev-15 porque a atividade B tem um fim real em 14-Feb-15. Este método elimina a lógica de fora de sequência do projeto.

A opção de Actual Dates (datas reais) pode ser usada para fixar datas para as atividades que você sabe que vão acontecer com certeza no futuro. Ela pode ser usada em situações em que sabemos que uma atividade irá terminar com certeza em datas fixas 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 what-if.

Conclusão

Depois de olhar para os exemplos acima, sabemos agora que a Retained Logic e Progress Override são as duas principais opções que podemos utilizar para agendar os projetos. Eu prefiro usar Progress Override sobre Retained Loigic para o agendamento nos projetos porque eu sei que representa o cenário real. Esta opção não adiciona períodos sem trabalho a projetos que estendem potencialmente a sua duração. Eu sei que muitos vão pensar de outra forma, por favor, comente abaixo se não concordar com esta justificação.