Por que evitar restrições no cronograma com apoio do MS Project 2013
Este assunto – uso de restrições em cronogramas – é muito debatido e questionado. Vejo muitos cronogramas contendo restrições em diversas atividades e isto já é um indicativo de que o Project pode estar sendo usado de forma equivocada. Quando o tema é restrição eu costumo dizer o seguinte: “Olha, use com moderação!”. E aí você deve estar se perguntado: “ por quê?”
É muito simples, pessoal. As restrições, como o próprio nome já diz, restringem o agendamento das atividades e engessam o modelo.
E é fácil sair colocando restrições no cronograma. Tudo por que o Project tem o "jeitão" de Excel, com as colunas de Início e Término quase que implorando para que o usuário “martele” ali uma data qualquer. E isto, minha gente, vai na contramão do conceito que devemos sempre ter em mente quando contruímos modelos para controle, como é o caso do cronograma. Ou seja; o seu modelo precisa ser dinâmico. Representar as mudanças de forma automática, sem ter a necessidade de intervenções e manutenção constante em cada linha do plano.
Mas pera lá… vamos entender melhor como o uso das restrições engessam o cronograma? Quando inserimos uma restrição no cronograma do projeto, o cálculo das folgas fica comprometido. Explico. Utilizando o método do Caminho Crítico iremos determinar as datas de início e término mais cedo através do caminho de ida. Teoricamente chegaríamos a data de término mais cedo do projeto e, percorrendo o caminho de volta utilizando esta data de término mais cedo como referência, encontraríamos as datas de início e término mais tarde. Acontece que, ao definirmos tal restrição, todo o cálculo do caminho de volta passa a levar em consideração agora esta restrição e não mais a data de término mais cedo. Vamos entender melhor através de um exemplo muito simples. Considere a rede abaixo com 3 atividades dependentes entre si e um marco representando o término do projeto.
Vamos aplicar uma restrição no marco de término do projeto do tipo NÃO TERMINAR DEPOIS DE e definir a data da restrição para 1 dia antes do término previsto para o marco que era 27/11/2013. Ou seja, definiremos uma restrição NTDD em 26/11/2013.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb35.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb36.png
Vamos observar agora o comportamento da rede e os cálculos produzidos. [
](http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/SNAGHTML24539135.png)http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/SNAGHTML24539135_thumb.png Opa. Pera lá. Ao inserirmos a data de restrição, as datas de início mais tarde (início atrasado no Project) e término mais tarde (término atrasado no Project) das atividades são todas alteradas para levar em consideração agora a restrição que foi colocada. Em outras palavras, a data de restrição passa a ser o ponto de partida no Caminho de Volta para o cálculo das datas mais tarde. Observe que o esquema abaixo e veja como o Project interpretou o cálculo com a restrição no plano.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb37.png
E o resultado disto é que as atividades passaram a ter folga total negativa.
FT(C)=IMT(C)-IMC(C) = TMT(C)-TMC(C) = 26-27 = –1 dia
Ora, mas o que significa então dizer que a folga total de uma atividade é negativa em 1 dia? Simples! Isto significa que a previsão do seu cronograma está completamente furada. Significa que seu plano como um todo não vai funcionar. Ou seja, eu precisaria devolver 1 dia para o modelo proposto de tal forma que consiga garantir o mínimo de consistência nos cálculos e, consequentemente, que as datas calculadas sejam factívies. E isto só seria possível iniciando ou terminando mais cedo aquelas atividades que apresentassem folga negativa. Outro ponto importante: seu caminho crítico não é mais composto por atividades com folga total zero. Agora, as atividades críticas serão aquelas que possuem as maiores folgas negativas. Resumindo, seu modelo foi totalmente alterado e comprometido. Com isto, volto a repetir, use restrições com moderação. Bom, e quando devemos usar restrições no plano? Ou melhor; quando não devemos usar restrições.
Indisponibilidade/disponibilidade temporária de recursos
Muita gente sugere o uso de restrições para dizer que o fulano só pode começar a trabalhar em uma determinada em função de outros compromissos, etc. Ora bolas, se ele está indisponível em um determinado período e só pode começar a trabalhar na atividade a partir de uma determinada data, é no CALENDÁRIO DO RECURSO que este cenário precisa estar modelado. Muito simples, dá mais trabalho, mas é o correto. Se este recurso, por exemplo, é de um pool de recursos e está compartilhado em outros projetos, é mais uma razão para agir corretamente. Veja o exemplo abaixo retratando o cenário acima sob 2 óticas (o uso indevido e o uso correto)
Uso indevido
O usuário definiu, através de uma restrição do tipo NÃO INICIAR ANTES DE, que Maria só pode iniciar a atividade B no dia 29/11. pois ela estaria fora da empresa no mês de Novembro até o dia 28/11.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb38.png
Uso correto
Maria disse que estaria fora da empresa no mês de Novembro e só retornaria no dia 29/11. Vamos modelar esta indisponibilidade da Maria no seu calendário e verificar o resultado disto no modelo.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb39.png
Clique em Alterar Período Útil
**
**
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb28.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb29.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb30.png
Vamos ver nosso plano agora. [
](http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image40.png)http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb40.png
Perceba que, através do calendário, resolvemos este problema e potenciais problemas futuros como, por exemplo, o uso da Maria em outro projeto no período em que ela esteja indisponível.
Janela de execução de uma determinada atividade
Esta situação também é muito recorrente e quase sempre o uso de restrição é a saída que muitos gerentes de projeto pegam para resolver este problema. Um exemplo interessante, e que acabei vivendo durante a mudança que fiz para um novo endereço é que a convenção do novo prédio determina que as mudanças só podem ser realizadas de segunda à quarta. É a janela estipulada pelo condomínio para a execução da atividade Mudança. Ora, muita gente se vê tentada a forçar uma data de início e término nestes casos, não? Pois bem, vou-lhes mostrar o uso indevido e correto nestes casos.
Uso Indevido
Inserir datas diretamente na atividade para forçar o início e término da mesma nos dias possíveis. No exemplo abaixo, a atividade B de realizar mudança está caindo em 28/11 (uma quinta-feira). Entretanto, a mudança só poderá ser realizada entre segunda e quarta-feira. Logo, eu “martelo” a data de início agendando para 2/12 que representaria a próxima segunda-feira disponível para realizar a mudança e, com isto, crio uma restrição
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb41.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb42.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb43.png
Não repitam isto em casa, ok! Uso correto Crie um calendário que considere apenas segundas, terças e quartas como dias úteis. Nomeie este calendário para Mudança e depois aplique este calendário na atividade B. Vamos ver como funciona.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb44.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb45.png
O resultado pode ser visto abaixo. Perceba os dias úteis e não úteis de trabalho no calendário Mudança.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb46.png
Agora o que faremos é definir que este calendário será utilizado pela atividade B (Realizar Mudança). Com isto aplicamos o cenário desejado sem criar uma restrição na atividade.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb47.png
E o resultado final no plano seria:
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb48.png
A atividade Realizar Mudança agora só acontecerá às segundas, terças e quartas, pois o calendário da tarefa garante isto. Perceba que não há restrição rígida criada no cronograma. Tá, Alexandre. Então quando devemos utilizar restrições? Muito simples. Para os casos em que existam datas extremamente rígidas. 1- Dependências externas ao projeto, tais como, por exemplo, a obtenção da licença do IBAMA para a realizar de uma obra. Neste caso teríamos um marco com uma restrição do tipo NÃO INICIAR ANTES DE. 2- Reuniões ou outras atividades que requerem um grupo de pessoas cuja data tenha sido acordada. Para estes casos, uma restrição do tipo DEVE INICIAR EM ou DEVE TERMINAR EM é a melhor forma para modelar tal situação. Para outros casos, minha sugestão é sempre utilizar DEADLINES ou DATAS LIMITES. E por que? Por que as deadlines não geram alertas de agendamento constantes e permite visualizar o desvio total da data de término do projeto, por exemplo.
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb49.png
http://gerentedeprojeto.net.br/wp-content/uploads/2013/11/image_thumb50.png
Bom pessoal, era isto. Vejo muita gente martelando datas no Project sem necessariamente ser uma restrição realmente. E pelo simples fato de que é “convidativo” ajustar a data nas colunas de início e término. Mas vejam, esta não é uma boa prática e é preciso tomar cuidado. Você pode estar construíndo um modelo que simplesmente não funciona. Repetindo mais uma vez: “use restrição com moderação, ok?” Um grande abraço e até o próximo post de Project.