Em 2005, a Agência de Gerenciamento de contratos de Defesa dos EUA implementou um teste de avaliação de cronograma baseado em 14 pontos, para ajudar o Departamento de Defesa a analisar o enorme volume de contratos e cronogramas em que foram encarregados de gerenciar.
Anos mais tarde, o teste de avaliação destes 14 pontos do cronograma tornou-se uma diretriz amplamente utilizada em muitas ferramentas de software, como o Acumen Fuse, Primavera P6 EPPM e Primavera Risk.
Mas o que é exatamente este teste de verificação dos 14 pontos do DCMA?
Bem, essencialmente está avaliando se um cronograma está bem elaborado – se este adere a um conjunto de melhores práticas consideradas importantes para o sucesso do gerenciamento de um projeto. Estes “benchmarks” são divididos em uma lista de 14 verificações:
1.Verificação da Lógica
A lógica está completa? Existem atividades sem relacionamentos? Todos sabemos que um cronograma é uma rede, e se esta não está fechada devido à falta de lógica, não é possível ter um caminho crítico preciso. Só é permitido que 5% das atividades estejam com problemas de relacionamentos (sem predecessora ou sucessora). Lembrando também que atividade que teve o relacionamento perdido, estra na conta. Ex. Temos a atividade de escavação e concretagem “ligadas” por um relacionamento do tipo (II + 10) início-início mais 10. Passados estes 10 dias do início da escavação, a atividade de concretagem irá iniciar e ficará solta no cronograma, pois o relacionamento de início que a prendia na rede se desfez. A partir de agora, se a escavação atrasar 100 dias, não haverá influência na concretagem (o que é um absurdo no mundo real). Por este motivo, relacionamento do tipo (II) não conta para fechar a lógica.
2.Procurando por Leads (lags negativos)
Os lags negativos são referenciados por leads. Estes retardos negativos podem causar vários tipos de problemas no entendimento da rede. Para o guia a tolerância é zero para este tipo de lag.
3.Procurando por lags (postergações positivas)
O DCMA é um pouco mais tolerante com os lags positivos do que com os negativos, mas o objetivo é utiliza-los o mínimo possível em seu cronograma. O guia estabelece que apenas 5 % dos relacionamentos podem ter lags.
4.Tipos de relacionamentos corretos
O Primavera P6, MS-Project 2016 e outros softwares suportam 04 tipos de relacionamentos entre atividades, mas isso não significa que você pode sair utilizando aleatoriamente, conforme seu entendimento. O DCMA entende que um cronograma bem elaborado, possui 90% dos seus relacionamentos do tipo (TI) – Término início. Todos sabemos que (II) – início início como atividade sucessora não fecha lógica. Para saber mais, clique aqui.
5.Uso demasiado de Restrições fortes
A utilização de restrições sempre afeta a lógica do cronograma, e pode estatizar uma programação. Datas do cronograma são para serem obtidas e não determinadas. O DCMA diz que não pode haver mais de 5 % de restrições rígidas dentro de todas elas utilizadas. Restrição rígida é aquela que é primária a lógica de relacionamento, como por exemplo, “deve terminar em”. Eu seria até mais criterioso, ao ponto de só permitir o número de restrições igual ao número de dedos que possui nas mãos. E só depois da devida autorização da fiscalização.
6.Folgas totais muito altas
O valor máximo para o “total float” é de 44 dias úteis, ou 02 meses corridos. Caso haja atividades com folga total maior que 44, pode estar havendo erro de relacionamento e com isso comprometimento do caminho crítico. O objetivo é que menos de 5% das atividades possuam valores de “total float” altos – 44 dias. Claro, que isso depende da duração do seu cronograma, e deve ser adaptado para sua realidade.
7.Folgas negativas
Folga negativa significa dizer que seu cronograma já perdeu a data de término. É necessário criar um plano de ação para que a programação consiga recuperar a data acordada com o cliente.
8.Durações altas
De acordo com o DCMA, uma atividade com alta duração é aquela que possui 02 meses. Estas atividades não podem ser mais de 5% do total de atividades no cronograma. É mais auspicioso que o planejador “quebre” a atividade em menores para melhor gerenciá-las.
9.Datas inválidas
Programação com datas previstas para serem realizadas no passado, atividades iniciadas depois do “data date”. Erros deste tipo pegam muito mal e mostram ou falta de atenção ou a péssima qualidade de uma atualização do cronograma.
10.Atividades sem recursos e custos
Cronograma sem recursos não é programação, é apenas uma lista de atividades no tempo. Um bom planejador tem os custos integrados nas atividades do cronograma para ter um fluxo de caixa fiel e atualizado sempre.
11.Índice de Descolamento de datas
Este índice informa de forma bem primária o quanto sua previsão de datas no cronograma foi precisa. Este controle verifica em temos percentuais, quantas atividades terminaram na data prevista do baseline.
12.Integridade do caminho crítico
Esta 12ª verificação testa se a lógica de relacionamentos do cronograma permite obter um caminho crítico real. O DCMA verifica através de um teste de sensibilidade, onde é introduzido um atraso no caminho crítico de x dias. O resultado final deverá ser um atraso de x dias na data final do projeto (no caso do caminho crítico que possui folga zero).
13.Índice de cumprimento do Caminho Crítico (CPLI)
Este índice mede se os marcos de atividades presentes no caminho crítico estão sendo cumpridos no tempo. Este índice funciona como um buffer (pulmão) de fim de projeto. A medida que este pulmão vai sendo utilizado por causa dos atrasos no caminho crítico, seus dias de folga são gastos, e o índice vai piorando. Segue a fórmula CPLI:
CPLI = [Comprimento (dias) do caminho crítico + Total float] / [comprimento do caminho crítico]
Ou seja, índices maiores que 01, significa que o caminho crítico possui folga ainda para atrasos. No momento que o “total float” vai sendo consumido por atrasos no caminho crítico do cronograma, o índice vai se aproximando de 01. Neste momento, podemos dizer que o caminho crítico não pode mais atrasar, senão haverá atrasos no cronograma. Monitorar o andamento deste índice é uma tarefa interessante, mas o teste deste ítem apenas quer saber se o CPLI se encontra acima de 01 ou não. Só é permitido CPLI 95%. Abaixo disso, entende-se que a data final do projeto está perdida, ou irrecuperável.
14.Índice de Execução da Linha de base (BEI)
Este índice visa mostrar o quão bem o cronograma está cumprindo as datas estabelecidas no baseline.Numa linguagem simples, procura observar se o empreiteiro completa mais atividades do que estava planejado no período. Podemos dizer que é um índice semelhante ao SPI (schedule Performence Index) de análise do Valor agregado. Caso este índice esteja abaixo de 95%, o cronograma não passará neste quesito.
Resumo
Caso queira saber um pouco mais sobre as fórmulas que são utilizadas em cada quesito ou qualquer outra informação sobre estas diretrizes, clique aqui e tenha acesso direto ao documento da DCMA.
O Primavera P6 possui um relatório (schedlog – fig 01) que realiza a maioria destes testes e o Primavera RISK (Schedule check – Fig 02) um pouco mais completo. Se utilizarmos estas boas práticas, junto com a análise do valor agregado e corrente crítica, teremos não só um cronograma imbatível, mas uma área de planejamento e gestão impecável.
Sua empresa ainda não adota as melhores práticas em gerenciamento de projetos, então agende uma conversa com o consultor Thiago Lugão e saiba como adotar estes “benchmarks” seja por meio de consultoria ou treinamentos específicos. Para saber mais, visite o site www.engenheirolugao.com.br .
Fig 01 - Shedlog - PRIMAVERA P6
Fig 02 - Shedule Check - PRIMAVERA RISK
