SERIE DCMA x P6: 2 - LAGS

LAGS NEGATIVOS, POSITIVOS E LONGOS (itens 2, 3 e 11 da lista de 14 itens de verificação no cronograma)

LAGS

Vamos começar com alguns conceitos importantes.

O que é?

O termo Lag vem do inglês e significa atraso.

É uma quantidade de tempo, duração, em que a atividade sucessora deverá iniciar em relação a atividade em evidência.

Em gerenciamento de projetos, os termos "lead" (Antecipações) e "lag" (atraso ou espera). Há pessoas que usam bastante o termo Espera (como no Primaverar P6 em português), há também o termo Latência (como no MS Project em português).

Estas ferramentas adotaram termo único para não ter que colocar 2 campos (um para lead e outro para lag).

Vou usar aqui apenas o tempo LAG, pois no Primavera P6 este é o termo usado neste campo quando o software está em inglês. Em português está Espera, mas na comunidade de gerenciamento de projetos o termo mais usado é Lag mesmo.

O Lag é utilizado para auxiliar a definir com exatidão o relacionamento lógico entre atividades do cronograma, seja antecipando, seja uma espera, ou postergação, o que será indicado pelo sinal de – ou + nas ferramentas de cronograma como Primavera P6 ou MS Project.

IMPORTANTE: O uso dos lags deveria ser documentado e justificado, a sugestão é de que se faça através do Notebook do P6, no nível da atividade. Mas infelizmente esta documentação pouco acontece.

Quem verifica o cronograma sem ser quem o criou fica um pouco perdido, sem saber o porquê das durações dos lags, pois não é óbvio identificar durações ao olhar para o gráfico de Gantt ou ao analisar as datas de um cronograma e saber que ali possui um lag de x dias.

Um planejador simplesmente insere um lag (positivo ou negativo), não documenta porque fez isto, pra quê... e quando outras pessoas vão analisar o cronograma, o uso daquele lag fica de difícil interpretação. Pra quê? Ou Porquê inseriram nesta quantidade de tempo? Isto evidencia a falta de visibilidade dos atrasos no cronograma do projeto, e também que o uso indiscriminado de lag representa um risco para o cronograma.

Por isto enfatizo a necessidade de documentar os lags como um notebook de atividade no Primavera P6.

Lag x Folga

É importante também não confundir Lags com folgas pois possuem conceitos diferentes!

O Lag nós atribuímos esta quantidade de tempo.

A folga é calculada pela rede lógica, ou seja, em como você ligou uma atividade com a outra.

Positivo (+) ou Negativo (-)

Nas ferramentas (Primavera P6, MS Project,...), para ficar positivo ou negativo basta indicar o sinal de – (menos) e a duração parar indicar antecipação da duração da atividade subsequente. Ou sem sinal algum, para o lag positivo, indicando a duração em que a atividade subsequente terá de espera ou será postergada.

1- LAGS NEGATIVOS (Leads)

Este é o 2º item da lista de 14 itens de verificação do DCMA e do Primavera P6 Check Schedule.

O que é?

São Atividades que tenham relacionamento com a duração do lag menor que 0: Lag Negativo.

Mas vamos por partes.... pois este é um assunto que “dá pano pra manga!”

Há empresas que não permitem o uso de lag negativo de jeito nenhum.

Há empresas que permitem com um percentual mínimo no cronograma.

No Primavera permite que seja usado e você configura se não quer usar (0% de tolerância) ou se quer usar algum percentual mínimo de tolerância, na configuração do Check Schedule.

Apesar do Primavera permitir que você insira Lag Negativo no cronograma, o DCMA não encoraja esta prática, estando aqui listado como um dos 14 pontos de verificação. E não somente o DCMA, tenho visto ao longo dos últimos 20 anos muitas empresas abandonando o uso do Lag Negativo como prática em seus cronogramas.

Portanto, se você usar Lag Negativo em cronogramas em que o cliente usa os 14 pontos do DCMA, seu relatório ficará vermelho neste item, e você deverá alterar os relacionamentos de maneira que use apenas lags positivos.

Oriento para usar Lag Negativo somente em projetos cujo contrato não faça objeção a esta prática.

Caso contrário, adote você também esta prática: Não use lag negativo.

Entendendo porque não usar Lag negativo

O uso Lag Negativo é desencorajado pela verificação de 14 pontos do DCMA porque, na melhor das hipóteses, eles podem interromper o fluxo de atividades do começo ao fim. E, se usados ​​incorretamente, os Lag negativos podem facilmente gerar lógica de rede não realista. Afinal de contas, o tempo não retroage... “não volta pra trás”.

Sei que talvez você possa argumentar: Ah, mas não é voltar no tempo, é antecipar atividades!

Mas na prática, não é assim que acontece no uso de uma “calculadora de tempo”. E também poderá haver possíveis conflitos de recursos potenciais devido a lags.

Os lags negativos também indicam que, possivelmente, o cronograma não esteja fornecendo detalhes suficientes.

Soluções Possíveis:

1- Adicionar atividades ao invés de lag: Neste caso, seria melhor adicionar atividades mais curtas e melhor definidas e relacionamentos FS, mas sem atraso, sem lag, e as atividades subsequentes sejam melhor definidas também.

2- Mudar o tipo de relacionamento: Outra solução é mudar o “jeito de pensar o relacionamento”.

Por exemplo:

A atividade A tem 4 dias de duração e a atividade sucessora B precisa iniciar no último dia da atividade A:

O que seria feito para antecipar B, seria inserir um lag negativo no último dia da atividade.

Mas para não usar Lag negativo, muda a forma de pensar essa antecipação, mudando o tipo de relacionamento de FS (Finish to Start) para SS (Start to Start), porem com agora com um lag positivo, ao iniciar A, espera 3 dias e inicia B também, como demonstro no quadro a seguir:

FIG.1

Acima, na Fig. 1, representamos a situação inicial, e à direita a situação sem o lag negativo. Ou seja, alteramos o tipo de relacionamento para não precisar usar lag negativo.

Mas cuidado para não sair da alteração de um item de lag negativo e acabar aumentando demasiadamente o número de ligações do tipo SS e FF, que não devem ultrapassar 10% do cronograma, como vimos no post Passado sobre Relacionamentos.

Se o contrato do seu projeto não solicita o uso dos 14 pontos do DCMA, e se a política de planejamento de projetos da empresa permitir o uso de Lag Negativo, Use!

Muitos planejadores gostam de usar Lag Negativo para ajudar a fazer compressão da duração do cronograma do projeto, ou consideram que ajuda a criar uma melhor modelagem, na visão deles, porém, na prática, na melhor das hipóteses, eles interrompem o fluxo da programação e, na pior, podem violar a lógica da rede e até mesmo alterar o caminho crítico.

RESUMINDO: Se no contrato do seu projeto pede que use DCMA, esqueça o uso de Lag Negativo, pois a tolerância para este item é zero, ou seu cronograma vai ficar com este item vermelho no Check Schedule do Primavera P6 e vai cair na auditoria do contrato.

Além do DCMA, o uso de Lag Negativo (Leads) não é conhecido como uma boa prática. Uma alternativa melhor são tarefas mais curtas e bem definidas e relações FS, mas sem atraso (sem lag), onde o gatilho para as atividades subsequentes é um escopo de trabalho claramente definido e conhecido, gerando um melhor fluxo.

Isso é inclusive o melhor caminho inclusive em relação ao uso de lag positivo, que veremos a seguir.

2- LAGS POSITIVOS

Este é o 3º item da lista de 14 itens de verificação do DCMA e do Primavera P6 Check Schedule.

Enquanto o Lag Negativo deve ser evitado, o Lag Positivo tem um pequeno percentual de 5% de permissão ou menos no check schedule do Primavera P6. Ou seja é aceitável, porém não encorajado.

Por isso, uma sugestão seria substituir as esperas (lags positivos) por atividades de mesma duração que seria o Lag.

Indicar uma nova atividade estática, com um tempo de espera é mais claro do que simplesmente informar lag +5d. Temos maior clareza do escopo, ainda que nesta atividade não tenha recursos, o que também é desencorajado pelo DCMA, mas neste caso é melhor ter uma atividade sem recurso do que um lag positivo.

O uso de atividades menores é encorajado pois evita a necessidade de justificativa do lag, comunica melhor o que é este tempo de espera. Uma qualidade de bons cronogramas é que eles são claros e compreensíveis. E criando novas atividades com um melhor detalhamento do escopo evita inclusive o uso de Lags Longos que é o próximo item de análise.

3- LAGS LONGOS

Este é o 11º item da lista de 14 itens de verificação, mas apenas da lista do Check Schedule do Primavera P6. Não existe este item na lista dos 14 do DCMA. Pois o Primavera alterou 3 itens que ele já faz normalmente por outros que considera também importantes.

Long Lags entrou como verificação no Primavera P6 no lugar de Missed Tasks/Atividades que sumiram no cronograma (11o item do DCMA) , sumiram em relação a linha de base. Como o Primavera já possui esta verificação por exemplo no Schedule Comparison (Menu Tools, último item), não colocaram novamente no Check Schedule, mas colocaram outra verificação no lugar: LONG LAGS, como pode ver no item 11.

O que fazer: Se no seu relatório do Check Schedule do Primavera P6 indicar que você ultrapassou o limite, tendo este item em vermelho, as Atividades com lags longos deverão ser quebradas em menores, com lags igualmente menores. Há um parâmetro de que a duração do lag seja menor que 352h (ou 44 dias de 8h) e que isso represente no máximo 5% do cronograma.

Ou seja, pode ter, mas pouco e o que passar disto, deve virar uma nova atividade.

OBS: Para quem faz o meu curso online individual (com videoaulas gravadas), este assunto está no Módulo 1 - Planejamento, no tópico 20, em forma de livro, para consulta ou impressão.

Por Joyce Gomes da Silvera

Veja também no Blog ...