Gráfico de Gantt: o que ele mostra e o que ele esconde (2026)

Você abriu um gráfico de Gantt, achou-o claro e nunca mais o abriu. O problema não é o gráfico em si, mas sim o que ele não mostra.

O que é um gráfico de Gantt e o que ele não é.

Um gráfico de Gantt representa as tarefas de um projeto como barras horizontais em uma linha do tempo. A posição de cada barra indica quando a tarefa começa, seu comprimento indica sua duração e barras sobrepostas indicam que duas tarefas estão sendo executadas simultaneamente. Simples assim. Essa simplicidade é sua maior força: um cronograma de projeto pode ser lido em segundos, sem precisar abrir uma planilha ou contar linhas.

Essa simplicidade também é a origem de todos os mal-entendidos. Um gráfico de Gantt não é um plano de projeto. Ele não explica por que uma tarefa existe, quem a solicitou, o que ela deve produzir ou como você saberá quando ela estiver concluída. Tampouco indica se as durações exibidas são realistas: uma barra de três semanas terá exatamente a mesma aparência, seja baseada em uma estimativa sólida ou em um palpite feito em uma reunião. O gráfico dá uma forma visual aos dados que alguém inseriu e lhes confere uma aparência de precisão que nem sempre possuem.

Portanto, o gráfico de Gantt deve ser visto pelo que é: uma representação de datas, não uma garantia de que essas datas serão cumpridas. Um gráfico de Gantt com aparência impecável pode descrever um projeto fadado ao fracasso, simplesmente porque as durações inseridas são otimistas. Por outro lado, um gráfico com aparência confusa, com barras sobrepostas por toda parte, pode descrever um projeto perfeitamente gerenciado, onde várias pessoas estão de fato trabalhando em paralelo. O formato do gráfico não diz nada sobre a saúde do projeto.

O que o diagrama realmente oferece é algo que nenhuma lista proporciona: uma visão simultânea da duração e da sobreposição. Em uma lista, duas tarefas agendadas para a mesma semana são lidas uma após a outra, como se fossem sequenciais. Em um diagrama, elas aparecem uma acima da outra, na mesma coluna de datas, e fica imediatamente claro que ocuparão as mesmas semanas. Essa é a única informação que o formato realmente adiciona, e já é significativa quando uma pequena equipe precisa decidir o que pode manter.

Diferenciando-a de uma linha do tempo reversa e de uma simples lista de tarefas

Três documentos descrevem o mesmo projeto e são frequentemente confundidos, embora não respondam à mesma pergunta. A lista de tarefas responde à pergunta "o quê": o que precisa ser feito, em qualquer ordem, sem qualquer noção de tempo. O cronograma reverso responde à pergunta "quando começar": começa com a data de entrega imposta e trabalha de trás para frente, tarefa por tarefa, até encontrar a data de início para cumprir o prazo. O gráfico de Gantt, por outro lado, responde à pergunta de simultaneidade: mostra o que está acontecendo ao mesmo tempo.

Essa distinção não é acadêmica; ela tem uma consequência prática imediata. Se você tem um prazo imposto por um cliente e não sabe quando começar, isso é um problema. agenda retrô O que você precisa é de um diagrama, não de um gráfico. Se você já sabe quando tudo começa e sua verdadeira dúvida é se sua equipe conseguirá lidar com a carga de trabalho em março, então um gráfico é o que você precisa. Usar um em vez do outro resulta em um documento bonito, mas inútil.

Os três documentos podem coexistir no mesmo projeto, e este é, na verdade, o cenário mais conveniente. A lista alimenta o diagrama, já que representa as mesmas tarefas. O cronograma reverso é usado apenas uma vez, no início, para definir a data de início. Cabe ao reunião de lançamento Este cronograma é apresentado à equipe e torna-se a referência comum. O diagrama é então utilizado ao longo de todo o projeto, sempre que for necessário decidir se uma solicitação adicional pode ser aceita sem interromper o restante do projeto.

Os quatro elementos que compõem um gráfico de Gantt.

Um gráfico de Gantt consiste em quatro elementos, e qualquer um deles pode estar ausente sem que o gráfico deixe de ser exibido. É exatamente isso que torna o formato enganoso: um gráfico incompleto não indica que está incompleto; ele simplesmente exibe menos informações.

A escala de tempo

Este é o eixo horizontal, graduado em dias, semanas ou meses. A escolha da granularidade não é meramente estética. Uma escala mensal em um projeto de seis semanas achata tudo: as tarefas se tornam linhas minúsculas e as sobreposições ficam ilegíveis. Uma escala diária em um projeto de dois anos produz um gráfico tão largo que ninguém rola até o final. A granularidade ideal é aquela que permite visualizar todo o projeto em uma tela, mantendo as barras claramente distinguíveis.

Barras de tarefas

Cada barra representa uma tarefa, seu início e fim. Este é o elemento central e o único estritamente necessário. Uma barra longa não significa que a tarefa seja difícil, apenas que ocupa um longo período: uma tarefa de uma hora distribuída ao longo de três semanas é representada por uma barra de três semanas, exatamente como uma tarefa que exige o trabalho em tempo integral de alguém durante três semanas. O diagrama mede o tempo, não o esforço.

Conquistas

Um marco indica um ponto de controle no tempo, sem duração definida. É uma data limite para a realização de algo: obtenção de uma validação, entrega de uma tarefa, tomada de uma decisão. No gráfico, ele não aparece como uma barra, mas como um marcador de ponto. A questão de o que se qualifica como um marco e o que é meramente uma tarefa importante precisa ser resolvida antes de qualquer elaboração do gráfico, e isso é abordado independentemente do diagrama, como demonstrado pelos critérios de conclusão do marco. marcos do projeto.

As relações de dependência

Uma dependência vincula duas tarefas e indica que a segunda não pode começar até que a primeira seja concluída. É o primeiro elemento que costuma ser omitido, e sua ausência também altera significativamente a natureza do documento. Discutiremos isso em detalhes mais adiante, pois é um dos dois principais equívocos sobre esse formato.

A regra das duas datas: por que uma tarefa sem data de início é invisível.

Eis a chave para entender gráficos de Gantt decepcionantes, e ela pode ser resumida em uma frase: uma tarefa só pode ser desenhada se tiver uma data de início e uma data de término. Uma barra precisa de um ponto inicial e um ponto final no eixo do tempo. Se algum deles estiver faltando, não há nada para desenhar e a tarefa não aparece.

Esse comportamento é perfeitamente lógico, e é justamente isso que o torna perigoso. O gráfico não indica o que foi omitido. Não exibe uma linha em branco, um aviso ou um contador para tarefas não representadas. Ele desenha o que pode desenhar e permanece em silêncio sobre o resto. Assim, você acaba com um cronograma que parece organizado, limpo e bem gerenciado, quando na verdade está cheio de lacunas. E como o que está faltando não é exibido, ninguém vê.

Inverta o raciocínio e você terá uma ferramenta de monitoramento gratuita. Se o seu diagrama parecer estranhamente vazio em comparação com o que você sabe sobre o projeto, se você estiver procurando por uma tarefa que tem certeza de que está em andamento e não conseguir encontrá-la, o problema não está no projeto em si, mas sim nas datas incompletas. O gráfico de Gantt não é, primordialmente, uma ferramenta de planejamento; ele revela a qualidade da sua entrada de dados.

Em uma organização pequena, tarefas sem prazo definido não são atribuídas aleatoriamente. Quase sempre são os mesmos tipos de tarefas que acabam sendo negligenciadas: aquelas criadas às pressas durante uma reunião, aquelas anotadas para não serem esquecidas sem que se saiba quando realizá-las, aquelas que aguardam contribuições externas com a data de término em branco, na expectativa de que seja adicionada posteriormente, e aquelas atribuídas a si mesmos fora dos canais usuais. Raramente são tarefas sem importância. Muitas vezes, são elas que causam problemas.

A correção é automática e rápida. Antes de cada revisão do cronograma, filtre as tarefas do projeto com base na ausência de data de início ou término e processe a lista resultante antes de analisar o diagrama. Dois cenários são possíveis: ou a tarefa possui uma data que não foi inserida e é adicionada; ou ela realmente não possui uma data porque depende de um evento externo e, nesse caso, é preciso tomar a decisão consciente de excluí-la do cronograma, ciente de sua ausência. A diferença entre as duas situações é enorme: em um caso, há uma lacuna não intencional; no outro, trata-se de uma decisão deliberada.

Dependências: o que o gráfico de Gantt mostra e o que ele não calcula.

O segundo mal-entendido é mais sutil, pois diz respeito ao que as pessoas pensam estar lendo. Diante de uma série de barras escalonadas, onde cada uma começa aproximadamente onde a anterior termina, o olho reconstrói espontaneamente uma sequência. Lemos uma cadeia: primeiro isto, depois aquilo; portanto, se a primeira barra se desloca, todas as outras também se deslocam. Essa é uma inferência humana, não uma propriedade do gráfico.

Sem dependências explicitamente definidas, um gráfico de Gantt é simplesmente uma série de barras, não uma sequência. Cada barra foi posicionada manualmente por alguém que inseriu duas datas. O aparente intervalo entre duas tarefas não reflete nenhuma regra; simplesmente indica que a pessoa que inseriu as datas as escolheu dessa forma. Nada no gráfico sugere que uma tarefa deva esperar pela outra.

As consequências são diretas e custosas. Se você deslocar uma barra em duas semanas porque a tarefa está atrasada, nada mais muda. Tarefas que, na realidade do projeto, não podem começar antes daquela permanecem exibidas em suas datas originais, e o diagrama continua mostrando um calendário impreciso. Nenhum atraso se propaga automaticamente. E o conceito de caminho crítico — aquela sequência de tarefas em que o menor atraso atrasa a conclusão do projeto — simplesmente não existe: ele é calculado com base em dependências, e se não há dependências, não há nada para calcular.

Isso significa que você deve documentar todas as dependências? Em uma organização pequena, a resposta é quase sempre não, e por um motivo prático: inseri-las leva tempo, mantê-las leva ainda mais, e uma rede de dependências mal mantida é mais enganosa do que uma inexistente. A abordagem sensata é não afirmar ter o que você não tem. Se suas dependências não estão documentadas, então seu diagrama é um calendário, e você deve lê-lo como um calendário: ele informa o que está planejado e quando, e cabe a você, um ser humano, saber o que pode dar errado quando uma barra se move.

Esse conhecimento, em uma equipe pequena, raramente existe no papel. Ele reside na mente da pessoa que lidera o projeto e só se torna visível quando ocorre um atraso. É exatamente por isso que o trabalho separado para identificar o que ameaça o cronograma, independente do gráfico, é tão valioso, conforme descrito na abordagem do gerenciamento de riscos do projeto.

Marcos em um gráfico de Gantt: um ponto de referência, não um período.

Um marco não tem duração. É uma data limite para atingir um determinado estado, e não um período durante o qual o trabalho é realizado. Essa diferença de natureza explica por que os marcos são exibidos de forma diferente das tarefas: enquanto uma tarefa ocupa um intervalo de tempo, um marco ocupa um ponto específico.

A confusão surge quando você transforma algo que é, na verdade, uma tarefa em um marco. Preparar um arquivo de receita leva tempo, requer o envolvimento de alguém e, portanto, deve ser representado por uma barra de progresso. Obter a aprovação desse arquivo é um marco: é uma decisão, tem uma data específica e não exige trabalho contínuo. Se você registrar a preparação como um marco, perde justamente a função principal do gráfico — mostrar a carga de trabalho ao longo de um período — e acaba com um projeto que parece vazio entre dois marcadores.

O erro oposto também existe e é mais custoso. Transformar uma decisão em um gráfico de barras de três semanas dá a impressão de que a validação é um processo prolongado, quando na verdade se trata de um único momento. O resultado prático: ninguém sabe em que dia entrar em contato com o cliente, já que o gráfico exibe um intervalo em vez de um prazo final. Os marcos são justamente projetados para criar esses momentos em que paramos, revisamos e decidimos se devemos continuar ou não. É isso que os torna úteis para qualquer pessoa que esteja preparando um Comitê de direção, visto que estes são os únicos pontos do cronograma que exigem uma decisão, e não um simples reconhecimento de progresso.

O progresso exibido: por que uma barra parcialmente colorida não significa que o trabalho está pela metade.

Muitos diagramas preenchem parcialmente as barras para mostrar o progresso. Uma barra preenchida pela metade sugere naturalmente que a tarefa está pela metade. Raramente esse é o verdadeiro significado do preenchimento, e vale a pena entender a origem dessa porcentagem antes de confiar nela.

Existem apenas duas origens possíveis. Ou alguém inseriu manualmente uma porcentagem, caso em que a barra exibe uma opinião: a da pessoa que estimou seu próprio progresso, com o otimismo inerente a esse exercício. Ou a porcentagem é deduzida automaticamente do status da tarefa e, nesse caso, assume apenas alguns valores: vazia quando a tarefa não foi iniciada, pela metade quando está em andamento e preenchida quando está concluída.

Vale a pena entender esse segundo mecanismo porque ele produz um efeito contraintuitivo. Uma tarefa iniciada esta manhã e uma tarefa com uma hora restante para ser concluída mostram exatamente a mesma barra de progresso: ambas estão em andamento, portanto, ambas estão na metade do caminho. O gráfico não faz distinção entre elas. Assim, você pode ter um projeto onde todas as barras estão pela metade, dando uma impressão reconfortante de progresso constante, mesmo que metade das tarefas tenha acabado de começar.

A conclusão prática é simples: não baseie suas decisões em barras de progresso. Baseie-as em datas, que não mentem. Uma tarefa cuja data de término já passou e cujo status não está concluído é um fato, não uma opinião. Uma tarefa cuja data de início já passou e cujo status não mudou também é um fato. Esses dois sinais são autoexplicativos e não exigem que você acredite na palavra de ninguém.

Criando seu primeiro gráfico de Gantt, passo a passo

O método a seguir não requer ferramentas especiais e pode ser concluído em cerca de uma hora para um projeto de tamanho médio. Sua principal vantagem é produzir um diagrama que permanece preciso por várias semanas, o que é a verdadeira medida do sucesso.

Comece listando as tarefas sem se preocupar com datas. O erro clássico é adicionar datas conforme você vai fazendo, o que leva a inventar datas para tarefas que ainda não foram definidas. Primeiro, anote tudo o que precisa ser feito, detalhando para que cada linha represente de um a dez dias de trabalho. Se for mais detalhado, o gráfico ficará ilegível. Se for mais granular, você terá cinco barras enormes que não dirão nada.

Em seguida, estime a duração de cada tarefa, separadamente da sua data. Duração e data são duas informações distintas que frequentemente são confundidas: uma tarefa pode levar dois dias úteis, mas se estender por três semanas porque uma resposta é esperada nesse meio tempo. Observe a duração no calendário, aquela que será efetivamente exibida, e não a carga de trabalho. Se a diferença entre as duas for significativa para muitas tarefas, sua verdadeira questão não é sobre agendamento, mas sim sobre a disponibilidade da tarefa. plano de carga, que trata da distribuição de esforços e não de datas.

Em seguida, insira as datas de início, começando pelo início do projeto e retrocedendo. Para cada tarefa, faça a si mesmo uma pergunta: o que precisa ser concluído antes que ela possa começar? Você não precisa inserir a dependência na ferramenta, mas deve se fazer essa pergunta, pois ela determina a data. Uma tarefa que você cria sem saber a resposta para essa pergunta é uma tarefa criada aleatoriamente.

Adicione os marcos por último e seja parcimonioso com eles. Um projeto de três meses com quinze marcos não tem quinze pontos de decisão; tem uma lista de tarefas disfarçada. De três a cinco marcos são suficientes para um projeto desse porte: esses são os pontos em que, se o resultado desejado não for alcançado, você para e discute o restante.

Por fim, verifique novamente se não está faltando nada. Essa etapa costuma ser ignorada, mas é a única que protege contra o cronograma incompleto descrito anteriormente. Compare o número de tarefas na sua lista com o número de barras no seu gráfico. Se os dois números forem diferentes, a diferença corresponde exatamente às tarefas que não têm data de vencimento.

Esta tabela merece uma leitura atenta, pois contém informações que o gráfico correspondente mostraria imediatamente: a validação do cliente e o desenvolvimento do primeiro lote começam no mesmo dia. Na realidade, desenvolver antes da validação das especificações é um risco. Em uma lista de tarefas, essa sobreposição passa despercebida. Em um diagrama, as duas barras se sobrepõem visualmente, e a pergunta surge naturalmente.

Com que frequência deve ser atualizado e quem deve mantê-lo?

Um gráfico de Gantt que não é atualizado rapidamente torna-se impreciso, e um gráfico impreciso é pior do que nenhum gráfico, porque força a tomada de decisões com base em datas desatualizadas. Portanto, a questão da frequência não se resume à conveniência, mas sim à confiabilidade.

A frequência ideal é semanal e não requer uma reunião. Basta que uma pessoa, uma vez por semana, abra o projeto e faça três coisas: marcar as tarefas concluídas como finalizadas, corrigir as datas de término daquelas que claramente sofreram atrasos e identificar aquelas cuja data de início já passou sem que nenhum trabalho tenha sido iniciado. Isso leva quinze minutos em um projeto de tamanho médio. Não precisa ser feito em grupo e, na verdade, é mais rápido e preciso quando feito individualmente.

Uma atualização mensal cria uma ilusão de progresso. Em um projeto de três meses, uma atualização mensal produz três instantâneos, sendo o último gerado quando o projeto é concluído. Entre os instantâneos, o diagrama exibe datas com várias semanas de atraso, e a discrepância entre os dados exibidos e a realidade aumenta diariamente sem que ninguém perceba.

A resposta prática sobre quem deve manter o cronograma é: uma pessoa, de preferência aquela que gerencia o projeto no dia a dia. Um cronograma mantido por várias pessoas torna-se inconsistente porque cada pessoa faz correções com base em sua própria interpretação, e ninguém consegue ter uma visão geral. No entanto, essa pessoa não deve ter que adivinhar: quem executa o trabalho sabe em que ponto está, e o papel de quem mantém o cronograma é perguntar a eles, não fazer estimativas por eles.

Quando uma tabela simples ainda é suficiente e quando ela deixa de ser suficiente.

O gráfico de Gantt nem sempre é o formato ideal, e escolhê-lo muito cedo é uma perda de tempo. Uma tabela de quatro colunas — tarefa, responsável, data de vencimento, status — é perfeitamente adequada, desde que três condições sejam atendidas: as tarefas sejam sequenciais e não sobrepostas, apenas uma pessoa ou quase apenas uma pessoa esteja trabalhando no projeto e o prazo seja de algumas semanas.

Nessa configuração, a simultaneidade, a única informação que o diagrama adiciona, não tem relevância. Se as tarefas se sucedem sequencialmente, o gráfico exibirá uma escada de barras que não dirá nada além da lista ordenada por data. Você terá pago um custo de instalação e manutenção por absolutamente nenhuma informação.

A planilha torna-se insuficiente assim que uma destas três situações ocorre. Primeira situação: várias pessoas estão trabalhando simultaneamente e é preciso saber quem está ocupado em cada momento. Segunda situação: vários projetos disputam a atenção das mesmas pessoas e surge a questão de se o cronograma de março (o cronograma do projeto) pode ser mantido em todos os projetos. Terceira situação: um cliente ou a gerência solicita a apresentação do cronograma, e uma lista de datas não pode ser lida em uma reunião, enquanto um gráfico pode ser compreendido em segundos.

Esta terceira situação merece consideração séria, pois muitas vezes é a verdadeira razão para a criação de um diagrama. Isso não é uma falha. Comunicar um cronograma é uma prática legítima, desde que se entenda que é o cronograma que está sendo utilizado. Um diagrama criado para exibição e um diagrama criado para orientação não exigem o mesmo nível de detalhamento: o primeiro se beneficia da simplicidade, enquanto o segundo precisa ser detalhado para refletir a tarefa em si.

Um exemplo concreto: um deslizamento detectado graças à sobreposição de duas barras.

Vamos considerar o projeto na tabela acima, um serviço de três meses com treinamento de usuários agendado para o final de abril. Ao atualizar a semana de 23 de março, a pessoa responsável pelo cronograma percebe duas coisas aparentemente triviais, analisadas separadamente.

Primeiro, a validação das especificações pelo cliente, agendada para o período de 23 a 27 de março, ainda não começou: o cliente ainda não enviou seu feedback. Segundo, o desenvolvimento do primeiro lote, agendado para o período de 23 de março a 17 de abril, começou conforme planejado. Não há nada de alarmante nessas duas observações isoladas e, em uma lista de tarefas ordenada por prazo, elas aparecem em locais diferentes, sem sobreposição.

No diagrama, as duas barras se sobrepõem visualmente, e essa sobreposição levanta imediatamente a questão: estamos desenvolvendo enquanto aguardamos a validação do que estamos desenvolvendo. Contanto que a validação chegue em alguns dias, o risco é razoável. Se demorar três semanas, parte do desenvolvimento terá que ser refeita, e a barra de desenvolvimento não parará em 17 de abril.

O gerente de projeto, portanto, decidiu não esperar. Ele contatou o cliente novamente em 25 de março, explicando claramente o problema: cada dia de atraso na validação significava um dia de desenvolvimento feito às cegas. A validação chegou em 31 de março, quatro dias atrasada. A equipe de desenvolvimento, assim, trabalhou por quatro dias sem validação, o que ainda era administrável, e o treinamento agendado para o final de abril não foi comprometido.

O que tornou esse relançamento possível não foi um alerta automático, já que não existe um. Foi observar o gráfico, ver duas barras sobrepostas e entender o que essa sobreposição implicava. O gráfico não calculou nada. Simplesmente mostrou, na mesma coluna de datas, duas informações que já estavam lá, mas que ninguém havia colocado lado a lado. Esse é exatamente o serviço que ele oferece, e é também o único.

É importante registrar essas informações em algum lugar, pois, caso contrário, elas se perderão ao longo da semana. Anotar o que foi observado, o que foi decidido e qual foi o resultado constitui a essência do monitoramento efetivo de projetos, onde as decisões tomadas são refletidas em vez de apenas uma série de porcentagens. Isso também conecta o gráfico ao restante do processo. gerenciamento de projetosdo qual ele é apenas um instrumento entre outros.

Erros comuns e como corrigir cada um deles

As dificuldades encontradas com esse formato podem ser reduzidas a um pequeno número de causas, e cada uma delas pode ser corrigida sem a necessidade de trocar de ferramentas.

Um último erro merece ser mencionado separadamente, pois não é visível no gráfico: criar o gráfico uma única vez, no lançamento do projeto, e nunca mais abri-lo. Um gráfico de Gantt só é útil quando usado repetidamente. Um gráfico usado uma única vez é um documento de apresentação, o que é um uso legítimo, mas não se deve presumir que ele controle alguma coisa. A diferença entre os dois usos reside em um único comportamento: alguém o abre toda semana?

Para projetos que envolvem várias pessoas trabalhando simultaneamente, a revisão semanal deve ser feita consultando tanto o calendário da equipe quanto o calendário do projeto, já que os dois frequentemente se contradizem. Um projeto pode ser perfeitamente planejado, mas ainda assim ser insustentável se as pessoas envolvidas já estiverem comprometidas com outros projetos, algo que somente a equipe pode prever. planejamento de equipe destaques.

O gráfico de Gantt em Djaboo

O Djaboo é um software de gestão completo para microempresas e PMEs. Cada projeto tem sua própria aba de gráfico de Gantt, e também existe uma visualização de Gantt que agrupa todos os projetos em andamento e os ainda não iniciados. Cada tarefa é exibida como uma barra: sua data de início marca o começo da barra, sua data de vencimento marca o fim e a cor da barra reflete o status da tarefa. Os marcos do projeto aparecem na visualização do projeto, juntamente com suas datas de vencimento. Este gráfico também é acessível ao cliente através do seu portal.

Quatro limitações devem ser claramente definidas. Uma tarefa que não possui data de início e data de término não aparece no diagrama. Não há dependências entre as tarefas: o campo existe, mas permanece vazio, portanto, nenhum atraso se propaga e não há caminhos críticos. O progresso exibido não é uma porcentagem inserida, mas um valor derivado do status: uma tarefa concluída é exibida como totalmente concluída, uma tarefa em andamento como parcialmente concluída e todas as outras como vazias, o que significa que uma tarefa iniciada esta manhã e uma tarefa quase concluída aparecem exatamente da mesma forma. Por fim, um marco ocupa apenas um dia na tela, não um período.

Com essas limitações em mente, dois usos permanecem perfeitamente válidos. O primeiro é inserir sistematicamente as duas datas de cada tarefa, caso contrário ela ficará invisível: esse é o requisito de entrada para o gráfico, e não há exceções. O segundo é usar o gráfico de Gantt como uma ferramenta de controle de entrada de dados, em vez de um painel de controle. Uma tarefa que você sabe que está em andamento, mas não vê no gráfico, não é uma tarefa que a ferramenta esqueceu: é uma tarefa inserida incorretamente, e o gráfico acabou de alertá-lo sobre isso, sem custo adicional.

Interpretado desta forma, o diagrama deixa de ser um produto final e se torna uma ferramenta de verificação. Ele não lhe dirá se o seu projeto está no caminho certo — nenhum gráfico faz isso. Ele lhe dirá se seus dados estão completos, e esse é o pré-requisito para que todo o resto — revisões, arbitragem e acompanhamentos — seja baseado em algo concreto.

Um gráfico de Gantt mostra apenas o que possui duas datas. Portanto, ele não exibe nada que você tenha esquecido de inserir, e essa ausência não é mostrada em lugar nenhum: cabe a você encontrá-la, comparando o número de barras com o número de tarefas reais no projeto.

E sem links de dependência, ele mostra as datas lado a lado sem nunca explicar o que acontece quando uma delas atrasa. Mover uma barra não move nenhuma outra. O gráfico mostra a simultaneidade, o que já é valioso quando uma pequena equipe precisa alocar carga de trabalho, mas deixa você totalmente responsável por saber quais tarefas dependem de quais outras.