SÉRIE: DCMA X P6 - 14 PONTOS DE VERIFICAÇÃO - RELACIONAMENTOS

Estamos iniciando uma Série de postagens sobre DCMA X P6, que são os 14 itens de verificação do DCMA, que estão no Primavera P6, para tem mais consistência e solidez em seus cronogramas. Neste primeiro da Série vamos falar sobre RELACIONAMENTOS e sua verificação.

BLOG

Joyce Gomes da Silveira

4/10/20265 min ler

Já mostramos em outro post (https://www.sosimplificar.com.br/14-pontos-de-verificacao-no-cronograma) que os 14 itens do DCMA e do P6 são diferentes em 3 deles, pois existem alguns itens que o DCMA analisa e o P6 já faz isso desde sempre, como a análise do caminho crítico e atividades ausentes (em relação a linha de base), então o P6 inseriu novos itens em substituição, conforme mostramos abaixo:

Nesta série aqui no Blog vamos analisar os 14 itens de verificação do P6. Não faremos 14 posts 1 para cada item.... vamos juntar itens que falam sobre o mesmo tema, como no caso deste post aqui.

  • Post 1 – Relacionamentos (itens 1 e 4 itens da lista acima)

  • Post 2 – Lags – Negativo, Positivo, Longos (itens 2, 3, 11)

  • Post 3 – Constraints/Restrições – Hard e soft (itens 5, 12)

  • Post 4 – Floats/Folgas – longas e negativas (itens 6 e 7)

  • Post 5 – Durações e Datas – Durações Longas, Datas inválidas, (itens 8 e 9)

  • Post 6 – Atividades atrasadas e BEI – Aderencia a linha de base (itens 13 e 14)

Então nas próximas semanas falaremos de todos esses 14 pontos de verificação distribuídos na ordem acima apresentada.

ITEM 1 – RELACIONAMENTOS

Os dois itens que falam diretamente de relacionamentos na lista do DCMA são:

  • Missing Logic /Logica Ausente (Atividades que estão sem predecessora ou sucessora)

  • Tipos de Relacionamentos

1- Missing Logic/Logica Ausente (Atividades que estão sem predecessora ou sucessora)

Este é o primeiro item da lista. Importantíssimo para a rede lógica, tudo começa aqui, no sequenciamento das atividades! Sem lógica da programação, você não tem um cronograma sólido.

Sempre falo em meus cursos de Primavera P6: NÃO deixem atividades sem relacionamento! Nem mesmo com apenas um relacionamento, só predecessora ou só sucessora.

Então vem uns e justificam... “ah, é porque esta atividade não liga com mais nada, acaba aí”. Em se tratando de lógica, essa não é uma resposta plausível. Se não liga com mais nada, ainda assim, faça a ligação com o marco de término desta fase e pronto, questão resolvida!

Outra justificativa “esta atividade não precisa de nenhuma outra pra iniciar”, então coloque o vínculo predecessor com o marco de início do projeto ou desta fase e pronto!

O que não pode é deixar a atividade sem relacionamentos, fica como se estivesse sem início ou sem fim. Chamamos isso de “Relacionamento aberto ao infinito”, pois não tem início ou fim definidos. Fazer isso, deixar sem relacionamento, afeta bastante a lógica da programação e MASCARA a realidade do seu planejamento e caminho crítico. Fica irreal! Depois quer que o cronograma esteja factível, sólido.... como???

Esse item no Check Schedule Report vai exibir em um filtro exatamente estas atividades para que você arrume isso!

Como corrigir: Vá em cada atividade que apareceu no filtro e coloque relacionamento.

Enfatizamos que todas as atividades deverão estar inseridas na lógica da programação! Todas deverão ter predecessora e sucessora, exceto a primeira atividade (a qual não terá predecessora) e a última (a qual não terá a sucessora). Qualquer outra atividade faltando um dos dois relacionamentos entra na lista de verificação do Check Schedule Report.

É para isto que existe esta ferramenta, te auxiliar a encontrar rapidamente e corrigir o que for possível. A intenção dessa verificação é examinar quão bem (ou mal) o cronograma está logicamente vinculado.

“Missing Logic” ou ‘Lógica ausente’ resulta em um cronograma estático que não reage bem a mudanças ou situações do projeto; as datas das atividades não são atualizadas automaticamente. Os cronogramas devem ser dinâmicos, tendo lógica bem definida para se ajustar às atualizações, isso o torna em um cronograma mais sólido.

Bom falar neste momento do uso de restrições/constraints: Evite o uso disto!

Restrição é uma data digitada no cronograma, isso engessa a rede lógica e torna o cronograma estático.

Restrições contratuais podem ser inseridas cuidadosamente. E você terá uma limitação para um percentual aceitável.

2- Tipos de Relacionamentos

Veja na tabela no início do texto que este é o quarto item da lista de verificação.

Uma coisa é falar de sequenciamento em qual atividade precede ou sucede. Outra coisa é mostrar como elas devem estar ligadas. Lembro que temos 4 tipos de relacionamento: FI (Fim a Início), FF (Fim a Fim), II (Início a Início) ou IF (Início a Fim).

Regra clara: A maioria dos relacionamentos deve ser FI ou FS (Fim Início ou Finish to Start).

  • FI: a maioria dos relacionamentos

  • FF ou II: aceitáveis

  • IF: evitar ou uso raro (DCMA não proíbe, mas saiba utilizar justificando bem o seu uso)

E essa maioria de FI deve ser 90% das atividades. O que passar deste percentual deve ser cuidadosamente analisado forma de alterar início-início, fim-fim... Imagina que apenas 10% será dos tipos II e FF e raro o IF!!!

Se seu cronograma está em andamento (in progress), uma fórmula seria:

= % de relacionamentos FI x 100

% de todos os links lógicos

II e FF: Este tipo de relacionamento não deve ser usado apenas para simplesmente fazer de qualquer jeito um “Fast Track” no cronograma (encurtar o cronograma colocando atividades em paralelo). Pois nem sempre estas atividades estão de fato em paralelo e entre elas deveria indicar um relacionamento mais transparente de sequenciamento. É neste momento que muito planejador “enrola” no planejamento mostrando um encurtamento que não deveria existir na prática, tornando este paralelismo inviável ou não factível.

É por esta maneira que o DCMA prefere relacionamentos em sua maioria FI, para mostrar de forma transparente o que está terminando para poder iniciar a próxima.

Para evitar inconsistências, seja extremamente cauteloso e questione a sua equipe de projeto na escolha correta do tipo de relacionamento e porque está sendo inserido um IF. E lembre-se sempre que II e FF são apropriados onde uma verdadeira dependência está realmente presente.

Sem contar que em II e FF poderá ter lags (veremos em outro post) e essa quantidade do lag pode não ter transparência em sua necessidade técnica ou com escopo desconhecido do lag.

Resumo: Para simplicidade e transparência use FI em 90% das atividades.

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

Leia também no blog ...