Os 20 Maiores Erros de Cronograma em Obra

Ordenados aproximadamente pelo dano que causam às decisões tomadas a partir do arquivo. Os cinco primeiros respondem pela maior parte do que dá errado.

Os cinco que quebram o cronograma

1. Tarefas sem predecessora ou sem sucessora

Tarefa sem sucessora não empurra nada. Tarefa sem predecessora não é empurrada por nada. De um jeito ou de outro ela saiu da rede, e quando a realidade escorrega, aquela tarefa fica onde está.

Correção: toda tarefa, exceto a primeira e a última, precisa das duas. Filtre por vínculos ausentes antes de cada emissão.

2. Restrição rígida no lugar de lógica

Deve Iniciar Em, Deve Terminar Em, Não Terminar Depois De — cada uma prende um trecho da rede a uma data fixa e impede o atraso de se propagar.

Normalmente aplicada por quem tenta fazer o cronograma exibir uma data que foi pedida, não calculada.

Correção: O Mais Breve Possível como padrão. Restrições leves (Não Antes De) servem para datas externas reais — entregas, licenças, liberação de frente. Toda restrição rígida precisa de motivo escrito.

3. Vincular tarefas-resumo

Dependência em tarefa-resumo corrompe o cálculo do CPM e produz caminho crítico passando por barras de consolidação em vez de serviço real.

Correção: vincule apenas tarefas de detalhe. Tarefa-resumo existe para consolidar, não para sequenciar.

4. Nunca definir a data de status

As datas reais são lançadas, o serviço restante nunca é reprogramado e a data de status fica em branco. O MS Project então mantém serviço previsto no passado e informa uma data-fim que assume que nada atrasou.

Correção: defina a data de status e reprograme o serviço não concluído para começar depois dela. Os dois passos, toda atualização.

5. Não testar se o caminho crítico funciona

Todo arquivo tem um caminho crítico. Se atrasar uma tarefa dele atrasa a obra é outra pergunta, e quase ninguém confere.

Correção: some 600 dias a uma tarefa crítica, recalcule, confirme que o término andou aproximadamente 600 dias, e desfaça. Se não andou, alguma coisa está absorvendo o atraso.

Os cinco que tornam o cronograma irrealista

6. Lag negativo para forçar sobreposição

Lag negativo puxa a sucessora para trás criando sobreposição que nunca foi modelada. Distorce o caminho crítico e esconde a decisão real de sequenciamento.

Correção: modele a sobreposição de verdade, com vínculo Início-Início mais lag positivo, ou quebre a predecessora em etapas.

7. Lag positivo fazendo o papel de atividade

Dez dias de lag entre concretagem e desforma representam cura. Ninguém é dono, nenhum recurso é consumido, nenhum relatório mostra. Quando precisar virar quatorze, ninguém percebe.

Correção: se o tempo representa serviço real ou restrição real, vire atividade. Guarde o lag para espera genuinamente passiva, e use pouco.

8. Atividades longas demais

Uma tarefa de 120 dias não pode ser medida mensalmente. Ela fica em "uns 40%" por um trimestre.

Correção: duração alvo igual ou menor que o intervalo de medição. Acima de aproximadamente 44 dias úteis, exige justificativa individual.

9. Ignorar folga negativa

Folga negativa significa que o cronograma está declarando uma data impossível. Deixada no arquivo entre revisões, significa que alguém viu um número vermelho e desviou o olhar.

Correção: rastreie até a restrição ou o prazo de origem a cada revisão. Resolva ou documente por que permanece.

10. Folga altíssima tratada como conforto

Duzentos dias de folga não é margem. É quase sempre lógica frouxa — a tarefa tem vínculo, mas vínculo que não a prende a nada relevante.

Correção: analise tudo acima de aproximadamente 44 dias de folga. Pergunte o que de fato restringe aquela tarefa.

Os cinco que vêm do plano, não do software

11. Falta de atividades

Comissionamento, ensaios, ciclos de licença, ligações de concessionária, previsão de retrabalho, prazo de fabricação. O cronograma pode estar tecnicamente impecável e ainda assim prever uma data que nunca foi possível.

Correção: olhe especificamente o fim do arquivo. Entrega e comissionamento são as fases mais comprimidas em uma barra só.

12. Durações sem base

Números que vieram de reunião, não de índice de produtividade, histórico ou quantidade dividida por produção de equipe.

Correção: registre a base junto com a duração. Quantidade ÷ produtividade ÷ tamanho da equipe. Onde for julgamento, diga que é.

13. Ignorar chuva e sazonalidade

Terraplenagem no período chuvoso, concretagem em calor extremo, acabamento externo em época de chuva — planejados como se o calendário fosse uniforme.

Correção: use calendários com períodos não trabalhados realistas, ou aplique fatores de produtividade sazonais nas atividades afetadas.

14. Conflito de recursos que ninguém olhou

A mesma equipe alocada em três atividades na mesma semana, num cronograma que ninguém nivelou nem inspecionou.

Correção: mesmo sem carregamento completo, confira se equipes-chave e equipamentos principais não estão duplicados nos picos.

15. Contingência escondida dentro das durações

Toda atividade inflada em 20% "por segurança". A gordura é invisível, então não pode ser gerenciada, e a Lei de Parkinson a consome em silêncio.

Correção: estime com durações realistas e mantenha a contingência como reserva declarada, visível, com um responsável.

Os cinco que destroem confiança e auditoria

16. Nomes duplicados

Três tarefas chamadas "Concretagem". Custo não se apropria, pleito não se rastreia e nenhuma comparação de revisão funciona.

Correção: nomes únicos, prefixados por local ou EAP. "Concretagem — Bloco B, pavimento 3".

17. Nomes genéricos ou truncados

"Serviços", "Etapa 2", "Diversos". Quem lê não consegue saber o que foi escopado.

Correção: verbo mais objeto mais local. Cinco palavras é um piso razoável.

18. Marco com duração

Marco com três dias de duração não é marco. Entregas contratuais e gatilhos de medição deixam de ser legíveis.

Correção: marco tem duração zero. O que tem duração é atividade.

19. Rebaselinar para esconder desvio

A previsão escorrega, então a linha de base se move e o desvio desaparece. Agora nada mais é comparável entre revisões e todo o histórico de controle reinicia.

Correção: rebaseline apenas por mudança de escopo ou prazo aprovada. Registre toda rebaseline com data e motivo, e guarde a baseline anterior.

20. Emitir sem comparar com a revisão anterior

O cronograma é emitido todo mês e ninguém compara. Tarefas são excluídas, durações mudam, lógica é refeita, e quem recebe não tem como saber.

Correção: uma comparação de revisões a cada emissão — o que mudou, o que foi incluído, o que foi excluído. E atenção: se a sua ferramenta de comparação casa tarefas só pelo ID, ela vai produzir bobagem; o pareamento precisa considerar também a descrição da atividade.

A verificação única que pega mais

Se você só puder rodar um teste antes de emitir: filtre as tarefas sem sucessora.

É rápido, não precisa de suplemento, e pega o defeito mais danoso da lista. Um cronograma em que 30% das tarefas não empurram nada não está prevendo nada, por melhor que as barras pareçam.

Perguntas frequentes

Sobre quais desses o MS Project avisa? Praticamente nenhum. 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.

É aceitável usar restrição rígida alguma vez? Raramente, e sempre com motivo escrito. Um marco contratual que precisa ser testado contra a realidade é mais bem modelado como prazo final (deadline), que mostra folga negativa quando descumprido em vez de congelar a rede em silêncio.

Quantos desses dá para verificar automaticamente? Dezesseis dos vinte são mensuráveis mecanicamente a partir do arquivo. Falta de escopo, base das durações, premissas de clima e conflito de recursos exigem julgamento humano.

Qual a forma mais rápida de revisar o cronograma de terceiro? Quatro números, nessa ordem: percentual de tarefas sem lógica, percentual com restrição rígida, quantidade com folga negativa, e se existe data de status. Se o quarto não existe, os três primeiros estão descrevendo um arquivo que nunca foi atualizado.

A BaselinePlan desenvolve suplementos de baixo custo de qualidade e comparação de revisões para MS Project. Dezesseis das vinte verificações acima rodam automaticamente sobre a exportação XML.