Atividades (exceto o marco de término) que não possuem sucessoras são referenciadas como atividades pendentes. Elas por estarem soltas no projeto, tornam seu monitoramento difícil. Entretanto, possui mais de uma forma de “amarrar” estas atividades no cronograma.
Os relacionamentos definem a ordem de interação entre as atividades. O mais comum é do tipo (TI) Término-Início, onde a atividade sucessora não pode começar enquanto a predecessora completar. Uma aplicação típica é a relação entre “fundação baldrame” e “fechamento de paredes”. A relação (TI) conecta estas duas atividades e nos orienta que a atividade de “fechamento de paredes” só poderá iniciar quando a “fundação baldrame” estiver completamente finalizada.
Às vezes, algumas atividades aparentam não ter uma sucessora lógica em primeira análise. O que fazer nestas situações? Deixará a atividade solta na programação sem sucessora? A resposta é claro que não. Considere as seguintes alternativas ao longo do artigo.
Este artigo explica abordagens alternativas para lidar com atividades pendentes no cronograma. O cronograma apresentado foi gerado no Primavera P6 da Oracle.
Nós temos na Figura 01 a apresentação do nosso projeto.
Note, em particular, a atividade “Install fence” – Instalação de cerca. Esta atividade não possui uma sucessora definida. Esta está solta no cronograma sem conexão com atividade sucessora. Observe também que os 31 dias de “total float” para “Install fence” é considerado muito alto. Isso se dá, pois esta atividade não possui sucessora, portanto o “total float” é medido levando em consideração a data final do projeto.
Isto significa que, no nosso exemplo, a atividade “install fence” pode atrasar até 31 dias, que em nada impactará a data final do projeto. As atividades com alto “total float” são discutidas no blog no artigo com título de “The DCMA 14-Point Assessment e High Float Tasks”.
Enquanto as diretrizes da Agência de gerenciamento de contratos de Defesa dos EUA (DCMA) dizem que atividades com alto “total float” são aquelas que possuem esta variável acima de 44 dias, muitos especialistas consideram 31 dias de “total float” um valor alto. Porém, aqui temos uma atividade sem sucessora e ainda com um “total float” alto.
Mas por que isso pode ser um problema? A atividade “Install fence”, por não possuir sucessora, não fornece nenhum aviso prévio que seu atraso pode se tornar um atraso para o progresso do projeto. Nós não saberemos que há um problema no projeto por conta desta atividade até que os 31 dias de “total float” sejam consumidos, e comece a empurrar a data final do projeto. Quando isto acontecer, já é muito tarde. Você terá um incêndio em suas mãos que terá que arrumar para minimizar o atraso do projeto. E observe, que este incêndio poderia ter sido evitado, pois nós tivemos 31 dias de folga para tomar uma atitude e não fizemos. A luz do que foi falado, como podemos evitar este incêndio venha ocorrer?
Em primeiro lugar, as diretrizes de cronograma, em particular da DCMA consideraria a falta de uma sucessora como uma “falta de lógica” na rede do cronograma. Consulte no blog o artigo “The 14-Point Assessment and Schedule Missing Logic” para ver uma discussão sobre “lógica ausente”.
Portanto, “Install fence” necessita de uma sucessora para aderir às diretrizes de cronograma da DCMA. No intuito de cumprir as diretrizes, a primeira resposta da maioria dos planejadores é conectar esta atividade pendente ao marco de término do projeto. Isso satisfaz a diretriz de “lógica perdida”, mas ainda não fornece nenhum aviso prévio de que os atrasos nas instalações das cercas irão ameaçar a data de conclusão do projeto.
Nós queremos que o subcontratado complete a atividade “install fence” muito antes do marco de término do projeto. Então, por que não colocar uma restrição do tipo “FOOB” – Finish on or Before – na atividade? Inserir uma restrição é uma forma de enfatizar a importância de uma data para realização de uma atividade no cronograma. Na figura 02, colocamos este tipo de restrição.
Observe que o “total float” diminui para 2 dias quando aplicamos essa restrição na atividade “install fence”, figura 03.
Ótimo ! Então, a instalação da cerca está programada para concluir muito mais cedo do que a data final do projeto. Isto é o que queremos. Mas há inconvenientes em usar restrições.
As restrições devem ser usadas com moderação nas programações. Uma das razões é que elas não atualizam automaticamente com as mudanças em andamento. Portanto, um cronograma com muitas restrições exige atenção muito mais tediosa. Estas também devem vir com uma nota explicando o seu propósito. Seu uso deve ser exceção.
Um ex-aluno queria esconder o “total float” de seus subcontratados porque estes tendiam a atrasar o trabalho até o último momento possível. As restrições podem até ocultar o “total float”, porém não é uma boa prática em programação. Então, existe alguma solução melhor?
É melhor pensar em sua situação de programação e tentar encontrar uma sucessora lógica para a tarefa em questão. No nosso cronograma, seria lógico “amarrar” a instalação da cerca na tarefa “substantial Conpletion”. A tarefa de instalação da cerca é um indicador que o projeto está próximo do término. Na figura 04 nós conectamos ‘Install fence” em “Substantial completion” num relacionamento do tipo (TI).
Isso funciona bem para resolver os problemas da perda de lógica e da restrição. Mas o “total float” total de 21 dias ainda é considerado um alto valor. Diante disso, como poderíamos reduzir este “total float” para números mais baixos?
Vamos examinar mais a situação. Considere a atividade “Install fence”. Qual é o propósito desta?
A cerva fornece segurança para o local, correto? E quando podemos querer que esta segurança seja fornecida no local de trabalho? – Antes da chegada de qualquer equipamento perigoso de alta tensão. À luz da função de segurança das cercas, teríamos como sucessora lógica a atividade “install bus and jumpers” – Instalação de barramentos e jumpers. Com isso, o “total float” da nossa atividade em questão terá o valor reduzido para 13 dias, o que é muito mais razoável.
RESUMO
As diretrizes de programação sinalizarão que o cronograma possui uma lógica aberta toda vez que houver atividades sem sucessora (exceto o marco de término). Geralmente, os planejadores para resolverem esta pendência, resolvem ligar a atividade solta no marco de término do projeto. Isso atende apenas a diretriz de falta de lógica, mas ainda falha na outra diretriz de alto valor para folga total. “total float”.
Os planejadores podem recorrer para restrições externas para reduzir o “total float”. Isso só resolve um dos problemas, além de ser menos honesto. Lógica fechada é uma característica de cronogramas de qualidade. A melhor solução é verificar qual atividade pode ser sua sucessora, pois desta forma você estará fornecendo um sucessor lógico e mantendo uma programação dinâmica e responsiva. Portanto, considerando o propósito ou a função dos entregáveis em questão, apenas poderá ajudar a solução que vise encontrar uma sucessora lógica e ao mesmo tempo mantenha o “total float” o mais baixo possível.
Este artigo original está disponibilizado no site https://tensix.com/2017/03/how-to-tie-up-those-dangling-loose-end-activities/. A Lugão Consultoria apenas traduziu o conteúdo para os usuários brasileiros do Primavera P6 que não possuem facilidade com a língua inglesa.