quarta-feira, 6 de julho de 2016

Porquer devemos evitar constrangimentos mandatórios

Quando não conseguimos que o nosso plano se ajuste a uma milestone de prazo final importante podemos ser tentados a usar a solução «atómica» inserindo um constrangimento de Fim Mandatório numa milestone. Efetivamente vamos conseguir obter a data de fim desta forma, mas vão ocorrer danos colaterais. Vamos analisar a questão:
Se pretender que uma criança fique longe dum forno quente pode simplesmente dizer-lhe ‘Não toque’. Uma abordagem mais indireta será falar-lhe sobre o forno e dessa forma fornecer-lhes conhecimento que os alerta para ficarem longe. Numa abordagem aproximada com esta última, vamos tentar explicar constrangimentos mandatórios. Vamos dizer como é que funcionam para que não os utilize à sorte, para que então seja suficientemente cuidadoso para ou quando o usar.
Os gestores de projeto têm uma fixação com os seus deadlines que forçam os seus planos a corresponderem a estes prazos com Constrangimentos Mandatórios. Não sabem que ao fazer isto podem estar a comprometer a integridade de todo o plano. Vamos ver a aplicação e efeitos deste tipo de constrangimento.
Na figura 1 abaixo temos um plano de demonstração.
Figura 1
Este é um projeto simples para substituir a tubagem de um permutador de calor que consiste na demolição da tubagem, instalação de nova tubagem e atividades de inspeção e garantia de qualidade. Estes são os elementos da WBS. A data de conclusão do projeto de acordo com a lógica natural é sexta-f eira, 17 de Março de 2017. Essa data é visível na Milestone de fim - ‘project completion date’. Mas o sponsor do projeto informa que o deadline do projeto é terça-feira 14 de Março. Como deveremos fazer para ajustar o plano para cumprir essa data?
Existem dois tipos de constrangimentos em Primavera P6 Professional: constrangimentos soft e constrangimentos hard. Os constrangimentos soft são assim considerados porque podem ser ultrapassados pela rede lógica e não criam geralmente nenhuma folga negativa no plano. Já os constrangimentos hard podem potencialmente criar folga negativa no plano. Vamos proceder a aplicar, em primeiro lugar, um constrangimento soft e, se necessário incrementar o constrangimento até vermos o impacto desejado.
Na figura 2 aplicamos o constrangimento ‘Finish On or After’ 14 de Março de 2017.
Figura 2
 Depois de recalcularmos o plano vemos o efeito na figura. O que aconteceu? Absolutamente nada. A milestone ‘project completion date’ continua a estar a 17 de Março de 2017 e o total float das atividades continua a ser 0. Parece que o constrangimento ‘Finish On or After’ é impotente. Isso não é verdade, mas para a nossa situação particular não tem efeito. Vamos incrementar o efeito.
Desta vez aplicamos um constrangimento hard. Escolhemos o constrangimento ‘Finish On’ em vez do anterior. O ‘Finish On’ é bom porque gera Total Float positivo se termina antes da data constrangida e Float negativo se termina depois da data constrangida. Vamos em frente e introduzimos o constrangimento na Figura 3.

Figura 3
Qual foi o efeito deste constrangimento no plano? Bem, o gráfico de Gantt parece que está na mesma, portanto sem efeito. Portanto a milestone ‘project completion date’ continua a estar a 17 de Março de 2017. Isto não era o que esperávamos. Agora olhe para a coluna de float. O total float para todas as atividades está negativo em -3 dias. Assim o float está a dizer que o nosso plano está atrasado 3 dias.
Isto é bom, mas o sponsor do projeto disse especificamente que o projeto termina a 14 de Março de 2017. Queremos ver essa data quer na tabela de atividades quer no gráfico de Gantt. Bem para que isso possa acontecer temos de incrementar ainda mais o constrangimento. Desta vez, vamos usar o constrangimento mais rígido – o constrangimento de ‘Mandatory Finish’. Op resultado está na figura 4.
Figura 4
Vamos então examinar o efeito. A ‘project completion date’ na tabela de atividades tem um total float de 0 e uma data de fim de 14 de Março de 2017. Bom! É isto mesmo que queremos.
Contudo, quando verificamos o plano mais de perto encontramos uma história diferente. A milestone ‘project completion date’ está exatamente a 14 de Março de 2017. Isto é bom! Mas a atividade ‘quality assurance inspection’ ocorre mais tarde no tempo, bem como outras atividades. Isto não é bom e não faz nenhum sentido.
 Como vemos na figura 5, a relação que liga ‘quality assurance inspection’ e ‘project completion date’ é ‘finish-to-finish’ (FF).

Figura 5
Para que a relação possa ser considerada verdadeira a ‘quality assurance inspection’ deve terminar antes da ‘project completion date’, mas no Gantt char vemos claramente que a relação não aparece como verdadeira.
Em suma, o constrangimento ‘Mandatory Finish’ na atividade ‘project completion date’ causou uma violação da rede de ligações lógicas, em que o predecessor se completa antes do sucessor.
Vamos examinar os danos colaterais da aplicação do Constrangimento ‘ Mandatory Finish’. Temos a milestone ‘project completion date’ a terminar na data definida pelo sponsor. Contudo, a rede lógica é violada e há atividades que terminam depois da data de conclusão. A tabela de atividade continua a mostra o desejado resultado do total float relativamente a 14 de Março de 2017. Isto parece bom. Todas as outras atividades mostram um float negativo de -3 dias, o que está errado.

Sumário

Os gestores de projeto fixados nas datas de fim do projeto são suscetíveis aos encantos de constrangimentos rígidos como os mandatórios. O com strangimento ‘ mandatory finish’ vai 'aparecer' para satisfazer as suas datas de restrição contratuais, como prometido. Mas, um exame mais atento, no entanto, revela que trazem problemas.
O constrangimento mandatório pode e provavelmente violará a lógica da rede até certo ponto. Isso pode ser visto quando a milestone que constrange fica desligada do resto do plano e este não demonstra de forma significativa como é que a data de constrangimento mandatório é obtida. Assim este tipo de constrangimentos é normalmente desencorajado.

Normalmente, os planos apresentados com tais constrangimentos não oferecem confiança ao destinatário de que o cronograma do projeto é realmente viável. A restrição 'Finish On' é mais adequada. Ele não viola a lógica de rede, e, portanto, mostra a progressão das atividades até à realização da data de conclusão. Além disso, dá aviso na coluna total float das atividades quando está atrasado, e por quanto. Portanto, use restrição "Finish On 'em vez de um 'mandatory finish’. É mais precisa, e também, uma apresentação mais honesta do cronograma.

Sem comentários:

Enviar um comentário