Porque cronogramas do Ms Project falham

Cronograma de obra quase nunca falha porque alguém errou uma duração. Falha porque a rede para de responder à realidade — e ninguém percebe, porque o gráfico de Gantt continua desenhando as barras do mesmo jeito.

Esse é o ponto central. Um cronograma com lógica quebrada é visualmente idêntico a um cronograma com lógica sólida. As barras têm a mesma cor, o resumo consolida, a data-fim aparece no canto da tela com uma precisão que ela não tem. A falha é silenciosa.

Abaixo estão os cinco modos de falha que respondem pela maior parte do que dá errado em obra, em ordem aproximada de dano.

1. O cronograma nunca foi de fato atualizado

A falha mais comum e a menos discutida, porque admiti-la é constrangedor.

Atualizar um cronograma exige três coisas: lançar as datas reais, reprogramar o trabalho restante para depois da data de status, e definir a data de status. Quem pula a terceira deixa o MS Project sem ponto de referência — ele mantém tranquilamente atividades previstas no passado e continua informando uma data-fim que assume que nada atrasou.

Como identificar: procure tarefas com 0% concluído cujo início previsto é anterior a hoje. Procure tarefas com 100% concluído e término real no futuro. Qualquer uma das duas significa que a data de status não foi aplicada — e, a partir daí, todo número derivado do arquivo (caminho crítico, folga, previsão de término) está descrevendo uma obra que não existe mais.

Um cronograma que reporta avanço e não tem data de status não é instrumento de controle. É uma fotografia do dia em que foi montado.

2. Restrições rígidas congelam a rede

Cada restrição do tipo Deve Iniciar Em, Deve Terminar Em, Não Iniciar Depois De e Não Terminar Depois De prende um trecho do cronograma a uma data fixa. Quando a predecessora atrasa, a tarefa restrita não anda. O atraso para de se propagar ali.

O dano é o mesmo da falta de lógica, com a diferença de ser deliberado — em geral aplicado por alguém tentando fazer o cronograma exibir a data que a diretoria queria ver.

As restrições leves (Não Iniciar Antes De, Não Terminar Antes De) são muito menos danosas e frequentemente legítimas: data de entrega de material, emissão de licença, liberação contratual de frente de serviço. A distinção importa, e a maioria das revisões de cronograma ignora completamente — porque o MS Project exibe os dois tipos do mesmo jeito.

Como identificar: exiba a coluna Tipo de Restrição. Qualquer coisa diferente de O Mais Breve Possível precisa de justificativa escrita. Tarefas em modo Agendada Manualmente entram na mesma conta: elas ignoram a rede por completo.

3. O caminho crítico não é funcional

Todo cronograma tem um caminho crítico. Se ele funciona é outra pergunta.

Caminho crítico funcional é aquele em que atrasar uma tarefa dele atrasa a obra. O teste é direto: some 600 dias de duração a uma tarefa do caminho crítico, recalcule e confira se o término do projeto andou aproximadamente 600 dias. Se não andou, o caminho crítico é decorativo.

Os culpados de sempre:

• Tarefas-resumo com dependência. Vincular tarefa-resumo corrompe o cálculo do CPM e produz um caminho crítico que passa por barras de consolidação em vez de serviço real.
• Restrição travando o fim. Um Não Terminar Depois De em um marco absorve o atraso em vez de transmiti-lo.
• Pontas soltas. Tarefa sem sucessora não empurra nada, então absorve atraso infinito sem consequência.

O caminho crítico é o resultado do qual se tomam mais decisões. É também o menos testado.

4. Erros de modelagem da lógica

Mesmo com tudo vinculado, os vínculos em si podem estar errados.

Antecipação (lag negativo) comprime o cronograma puxando a sucessora para trás. Esconde uma sobreposição que nunca foi modelada e distorce o caminho crítico. Na prática é quase sempre um atalho para "essas duas coisas se sobrepõem de algum jeito" — o que é um problema de modelagem, não uma técnica de planejamento.

Lag positivo é atraso sem dono. Dez dias entre "concretagem" e "desforma" representam cura, mas ninguém é responsável por aquele tempo, nenhum recurso é consumido e nenhum relatório mostra. Quando os dez dias precisarem virar quatorze, ninguém vai perceber.

Excesso de vínculos — tarefa amarrada a doze predecessoras — normalmente significa que alguém ligou tudo a um marco em vez de modelar a sequência real.

Tipos de relação importam menos do que a maioria dos padrões sugere. Término-Início deve dominar, mas Início-Início e Término-Término são legítimos e frequentemente corretos em obra linear: pavimentação, dutos, túneis, tabuleiro de ponte. Penalizá-los mecanicamente é um erro comum de análise.

5. Falta de atividades

O cronograma pode estar tecnicamente perfeito e ainda assim falhar porque alguma coisa não está nele.

Comissionamento. Testes e ensaios. Previsão de retrabalho. Ciclos de aprovação de projeto e licenças. Ligações definitivas de concessionária. Serviços sensíveis a chuva planejados como se fossem em tempo seco. Período chuvoso. Prazo de fabricação de fornecedor tratado como instantâneo.

Escopo faltando produz o tipo mais perigoso de cronograma: o que passa em todos os testes técnicos, mostra caminho crítico saudável e prevê uma data que nunca foi possível.

Como identificar: compare a quantidade de atividades com o valor da obra. Um cronograma de trinta milhões com sessenta atividades não é cronograma, é resumo executivo. Depois olhe especificamente o fim do arquivo — comissionamento e entrega são as fases mais comprimidas em uma barra só.

O padrão por trás dos cinco

Todas as falhas acima compartilham uma propriedade: o cronograma continua produzindo resultado depois de deixar de ser válido. Não há mensagem de erro. Não há alerta vermelho. O arquivo abre, as barras desenham, a data aparece.

É por isso que qualidade de cronograma precisa ser medida, não avaliada no olho. Quem olha o Gantt está olhando exatamente o artefato que esconde o defeito.

O contra-ataque é um conjunto de verificações que rodam contra o próprio arquivo: percentual de tarefas sem lógica, percentual com restrição rígida, quantidade com folga negativa, atividades no passado que nunca foram atualizadas. Cada uma é um número. Números podem ser comparados entre revisões. Impressões não.

Perguntas frequentes

Um cronograma pode falhar mesmo com datas que parecem razoáveis? Sim — e esse é o caso normal. Datas de aparência tranquila são exatamente o que uma rede quebrada produz quando os atrasos param de se propagar. Está calmo porque nada está se movendo.

Folga negativa é sempre um problema? Folga negativa significa que o cronograma está se declarando impossível diante de um prazo ou restrição. Nem sempre é erro — pode ser um sinal honesto de que a data não cabe. Vira problema quando fica meses no arquivo sem ninguém tratar.

Quantas atividades um cronograma de obra deveria ter? Não há número universal, mas a granularidade precisa acompanhar o intervalo de controle. Se você mede mensalmente e suas tarefas duram 90 dias, não há como medir avanço com sentido. Durações acima de aproximadamente 44 dias úteis merecem análise individual.

O MS Project avisa sobre alguma dessas coisas? Não. O MS Project praticamente não valida qualidade de cronograma. Ele deixa você vincular tarefa-resumo, aplicar restrição que quebra o caminho crítico e manter serviço previsto no passado sem um único aviso.

A BaselinePlan desenvolve ferramentas de baixo custo para análise de cronogramas no MS Project. Todas as verificações acima rodam automaticamente sobre o XML, no seu navegador, sem o arquivo sair da sua máquina.