Quando devemos aplicar constrangimentos rígidos a um plano? Esta a questão principal a que se junta outras questões sobre que constrangimentos a aplicar e que efeitos têm no plano?
Muitos planos apresentam um aspeto similar a uma agenda de eventos, na qual os responsáveis entendem fixar as entregas ou as aberturas de forma aleatória e mais ou menos rígida. Para esse efeito utilizam de forma pouco competente e exagerada os constrangimentos, em atividades e por vezes em milestones. Esta orientação não é a melhor, mas isso não significa que não devamos usar constrangimentos, antes o seu uso deve ser entendido e utilizado da melhor forma em resposta às circunstâncias particulares de cada projeto.
Muitas vezes o plano do projeto é influenciado por constrangimentos e estes devem refletir-se no projeto. Os constrangimentos podem ser contratuais, externos ou internos. Alguns exemplos:
Constrangimentos contratuais têm tipicamente a forma de acordo legais estabelecidos no contrato. Sendo um exemplo disso, a data de conclusão do contrato – deve ser cumprida e se atrasarmos poderá resultar em penalidade financeira ou de outro tipo.
Constrangimentos externos são aqueles sobre os quais o gestor de projeto tem pouco ou nenhum controlo, tal como os constrangimentos meteorológicos ou ambientais de que são exemplos os períodos de fecho no Inverno ou as regras ambientais para execução de trabalhos em zonas protegidas, etc.
Constrangimentos internos são aqueles sobre os quais o gestor de projeto pode ter algum controlo, como, p0or exemplo os limites dos recursos. Para podermos perceber as diferenças na utilização de constrangimento vamos ver o que se passa quando definimos os constrangimentos Finish On e Mandatory Finish num plano.
Constrangimento flexível – Soft Constraint
Na figura abaixo vemos um projeto com 4 atividades designadas de forma alfabética. Este plano tem Um constrangimento Finish On para 13 de Fevereiro de 2015 para descrever a importância de ser completado nesta data. Note o aviso de folga total negativa já que o projeto não vai conseguir alcançar a data de conclusão a não ser que seja ajustado o plano. Contudo, o Gantt Chart dontinua a mostra a sequência correta das atividades de acordo com a lógica de predecessor / sucessor. A atividade D não pode começar antes da conclusão das atividades C e B.
Figure 1 - Constrangimento de Fim
Constrangimento rígido – Hard Constraint
A Figura 2 mostra o mesmo projeto com um constrangimento mandatório (Mandatory Finish). Este plano tem um constrangimento de fim mandatório em 13 de Fevereiro de 2015, para descrever a necessidade de completar o projeto antes dessa data. Note que a atividade D aparece a começar antes da conclusão da atividade C. esta é uma violação da lógica que especifica que as atividades B e C devem estar concluídas antes de iniciar a atividade D. O perigo é que a equipa de projeto inicia a atividade D quando esta só pode ser realizada com sucesso co m o requisito das atividades B e C.
Figure 2 - Constrangimento Mandatório
Sumário
Muitas vezes os constrangimentos no plano do projeto estão quer fora da esfera de influência do gestor do projeto como são criticamente importantes. O problema com estes constrangimentos que apoiando-se neles podemos ter a lógica de planeamento violada. Isto põe em questão toda a exatidão do plano do projeto.
Quando possível utilize os constrangimentos Start On, Finish On, etc. que são preferíveis aos constrangimentos rígidos e mandatórios. Se uma data de conclusão é absolutamente essencial, então considere se não será preferível rever o seu plano do fim para o princípio.
Sem comentários:
Enviar um comentário