Para mim, uma boa gestão de riscos em projetos não deveria depender apenas de uma matriz preenchida no início da iniciativa. Ela precisa acompanhar a execução e observar se o comportamento real do projeto continua compatível com aquilo que foi planejado. O objetivo não é tentar adivinhar o futuro, mas perceber com antecedência quando o projeto começa a caminhar em uma direção perigosa.

Um estudo acadêmico chamado Dynamic Prediction of Delays in Software Projects using Delay Patterns and Bayesian Modeling, disponível também em uma versão aberta no arXiv, parte exatamente dessa ideia.

O estudo demonstra como modelos atualizados continuamente podem prever atrasos ainda nas fases iniciais do projeto. Em vez de depender apenas da estimativa feita no início, o risco é recalculado conforme surgem novos dados de execução e de desempenho da equipe. Essa abordagem me parece muito mais próxima da realidade, porque nenhum projeto continua exatamente igual depois que começa.

1. O prazo previsto começa a se afastar da baseline

A baseline do projeto é a referência que mostra como ele deveria evoluir. Ela reúne as datas, os marcos, as durações e as entregas que foram aprovadas no planejamento. Quando a previsão atual começa a se afastar dessa referência, temos um dos primeiros sinais de que a execução não está acompanhando o plano original.

Esse afastamento pode aparecer de diferentes formas. A data final projetada pode ser constantemente empurrada para frente, os marcos podem começar a ser concluídos depois do previsto ou a equipe pode entregar menos trabalho do que deveria em determinado período. Na gestão do valor agregado, o Schedule Variance indica uma variação desfavorável quando o valor do trabalho realizado fica abaixo do que estava planejado, enquanto o Schedule Performance Index, ou SPI, abaixo de 1 indica que o projeto está avançando em um ritmo inferior ao esperado. O guia do Departamento de Energia dos Estados Unidos sobre Earned Value Management explica esses indicadores com mais detalhes.

Eu não considero que um único resultado desfavorável seja suficiente para declarar que um projeto está atrasado. O que me preocupa é a tendência. Se o SPI permanece abaixo de 1, se o Schedule Variance continua desfavorável e se a previsão de término é revisada várias vezes, o projeto está produzindo evidências de que o plano original deixou de representar a realidade da execução.

No Saint Jude, o Módulo de Projeto permite verificar continuamente o que foi planejado em relação ao que realmente foi entregue. Essa comparação entre planejado versus realizado ajuda a entender quais atividades estão contribuindo para o desvio, quais entregas estão ficando para trás e em que momento a diferença entre o plano e a execução começa a ameaçar o prazo final.

2. A folga do caminho crítico começa a diminuir

Nem todas as atividades atrasadas possuem o mesmo impacto. Uma tarefa pode atrasar alguns dias e ainda existir folga suficiente para que o projeto termine na data prevista. Outra atividade, aparentemente pequena, pode fazer parte do caminho crítico do projeto e determinar diretamente quando uma entrega será concluída.

É por isso que eu não gosto de analisar o cronograma apenas contando quantas tarefas estão atrasadas. Dez atividades com atraso podem ter pouco impacto se possuírem margem suficiente. Uma única atividade crítica, por outro lado, pode bloquear outras equipes, consumir toda a folga disponível e alterar a data final do projeto.

O Schedule Assessment Guide do Government Accountability Office mostra a importância de estruturar corretamente as dependências, as durações e as atividades que controlam o término do projeto. Eu também aprofundei esse assunto no artigo Método do caminho crítico: como identificar dependências que podem atrasar seu projeto.

Para mim, o ponto mais importante é entender que o caminho crítico não é uma fotografia tirada no início do projeto. Uma atividade que possuía folga pode começar a consumi-la. Uma dependência pode se tornar mais arriscada. Uma alteração de duração pode fazer com que outro caminho passe a controlar a entrega. O cronograma precisa acompanhar a realidade, porque a realidade continua mudando.

No Saint Jude, o Módulo de Cronograma ajuda a acompanhar as relações entre atividades, os marcos e as possíveis consequências de um atraso. Assim, o gestor consegue direcionar sua atenção para aquilo que realmente pode alterar a data final, em vez de tratar todas as tarefas como se tivessem a mesma importância.

3. O volume de trabalho em andamento cresce acima da capacidade

Existe uma situação que vejo com frequência em projetos: o board está cheio de atividades em andamento, mas poucas estão sendo concluídas. À primeira vista, isso pode parecer produtividade. Afinal, muitas pessoas estão ocupadas e várias tarefas foram iniciadas. Na prática, porém, o excesso de trabalho em progresso pode indicar que a equipe está sobrecarregada e com dificuldade para finalizar o que começou.

O WIP, ou Work in Progress, representa o volume de trabalho que está aberto ou em execução. Quando ele cresce acima da capacidade real da equipe, aumentam a troca de contexto, as interrupções e a espera entre etapas. As pessoas começam muitas atividades, mas demoram mais para concluir cada uma delas. O guia da Kanban University apresenta a limitação do trabalho em progresso como uma prática importante para melhorar o fluxo.

O que me interessa não é simplesmente saber quantas tarefas estão abertas. Eu quero entender quantas estão realmente avançando, quantas dependem das mesmas pessoas, quais estão paradas e se o volume de trabalho cresce mais rápido do que a capacidade de conclusão. Quando existe uma fila de tarefas acumuladas, o atraso pode ainda não ter aparecido no cronograma, mas já está sendo formado no fluxo de trabalho.

O limite de WIP não deve ser tratado como uma regra burocrática. Ele existe para proteger o fluxo e impedir que a equipe comece mais trabalho do que consegue terminar. Quando o volume de atividades ativas cresce continuamente, os indicadores de produtividade ajudam a entender se o time está realmente entregando mais ou apenas mantendo mais tarefas abertas.

No Saint Jude, o Módulo de Desempenho e Capacidade da Equipe permite comparar o volume de trabalho em andamento com a capacidade observada de execução. Essa análise ajuda a identificar sobrecarga, concentração de atividades em determinados profissionais e situações em que a equipe parece ocupada, mas não está conseguindo transformar esforço em entregas concluídas.

4. O tempo de ciclo e o lead time ficam mais longos e imprevisíveis

O lead time mostra quanto tempo uma solicitação leva desde o momento em que entra no fluxo até ser concluída. O tempo de ciclo, também conhecido como cycle time, observa o período entre o início efetivo do trabalho e sua finalização. Eu gosto desses indicadores porque eles mostram o comportamento real das entregas, e não apenas aquilo que foi estimado no planejamento.

Quando o lead time e o tempo de ciclo começam a aumentar, a equipe está levando mais tempo para concluir atividades semelhantes. Quando eles também ficam mais imprevisíveis, o problema é ainda maior: mesmo que a média pareça aceitável, algumas tarefas passam a demorar muito mais do que outras. A Kanban University apresenta o lead time como um importante indicador de previsibilidade.

Uma equipe pode continuar entregando e, ainda assim, estar perdendo previsibilidade de entregas. As sprints terminam, mas as atividades levam cada vez mais tempo. As estimativas precisam ser revisadas com frequência e as próximas datas passam a depender de uma capacidade que já não se comporta como antes. Para mim, esse é um sinal que aparece antes de o atraso se tornar oficialmente visível.

No Módulo de Projeto do Saint Jude, validamos a produtividade a cada sprint e observamos como o comportamento das entregas evolui ao longo do tempo. Essa análise ajuda a perceber quando o fluxo está ficando mais lento, quando a equipe está entregando menos do que planejou e quando as próximas previsões já não deveriam usar os mesmos parâmetros do início do projeto.

5. Requisitos e escopo continuam mudando depois do início

Mudanças de escopo fazem parte da realidade de muitos projetos. Um novo requisito pode surgir porque o cliente aprendeu algo durante a execução, porque uma restrição técnica foi descoberta ou porque uma prioridade estratégica mudou. O problema não está necessariamente na existência da mudança, mas na falta de visibilidade sobre o impacto que ela provoca.

Quando requisitos continuam mudando depois que o trabalho começou, as atividades podem perder clareza, as estimativas deixam de representar o esforço real e a equipe passa a trabalhar em algo diferente daquilo que foi originalmente planejado. Muitas vezes, uma tarefa parece pequena, mas precisa ser reaberta diversas vezes porque o objetivo ou o critério de aceite ainda não está bem definido.

A documentação da NASA sobre volatilidade de requisitos mostra como mudanças frequentes podem afetar a estabilidade do desenvolvimento. Na minha experiência, esse também é um dos sinais mais difíceis de perceber, porque o cronograma pode continuar sendo atualizado e, mesmo assim, o projeto pode estar acumulando trabalho que não estava previsto.

No Módulo de Projeto do Saint Jude, analisamos se as atividades possuem clareza suficiente e se suas estimativas estão de acordo com tarefas parecidas já realizadas. Essa comparação ajuda a identificar atividades genéricas, estimativas de esforço fora do padrão e situações em que mudanças de escopo estão aumentando o esforço necessário sem que isso seja claramente percebido pela gestão.

6. Dependências e bloqueios aumentam o risco de atraso

Nem toda atividade atrasada está atrasada porque a equipe deixou de trabalhar. Muitas vezes, ela está esperando uma aprovação, uma informação, outra equipe, um fornecedor, um ambiente técnico ou uma decisão do cliente. Quando esse tempo de espera não é visível, ele pode ser interpretado como baixa produtividade individual, embora o problema esteja na forma como o trabalho está conectado.

Uma dependência, por si só, não é necessariamente um risco. Se a equipe da qual dependemos está avançando normalmente, possui capacidade suficiente e ainda existe folga no cronograma, talvez a dependência esteja sob controle. O risco muda quando a estimativa começa a ser revisada, a atividade fica bloqueada, a pessoa responsável está sobrecarregada ou a entrega seguinte já não possui margem para esperar.

O material do GAO sobre interdependências e caminho crítico mostra como as relações entre atividades podem afetar o cronograma. Uma pequena espera em uma atividade pode se propagar para várias outras, especialmente quando existe uma sequência de tarefas dependentes ou quando diferentes equipes precisam trabalhar em uma ordem específica.

Esse é também o ponto em que o risco de atraso precisa ser reavaliado continuamente. A estimativa inicial pode ter sido adequada quando o projeto começou, mas novos bloqueios, mudanças de desempenho e esperas acumuladas alteram a probabilidade de conclusão. Não faz sentido olhar para o risco apenas porque ele foi registrado no início. Precisamos observar o que está acontecendo agora.

No Módulo de Riscos do Saint Jude, os riscos são avaliados constantemente de forma proativa por nossa Inteligência Artificial. Quando um possível problema é identificado, as possíveis mitigações são designadas automaticamente para o usuário responsável na plataforma. O objetivo é permitir que a equipe trate o risco enquanto ainda existe tempo para agir, antes que uma dependência se transforme em atraso concreto.

7. Retrabalho, defeitos e problemas de qualidade aumentam

Um projeto pode continuar registrando atividades concluídas e, mesmo assim, estar se aproximando de um atraso. Isso acontece quando parte do trabalho precisa ser refeita. Uma tarefa é encerrada, mas retorna para desenvolvimento. Uma entrega é enviada para validação, mas volta com novos problemas. Uma alteração provoca uma regressão e obriga a equipe a corrigir algo que já deveria estar pronto.

O retrabalho em projetos consome capacidade que não estava prevista na estimativa original. A equipe continua ocupada, mas uma parte cada vez maior do esforço é direcionada para correções, revisões e reaberturas. Com o tempo, as novas atividades começam a acumular, o tempo de ciclo aumenta e o projeto passa a entregar menos valor do que o volume de trabalho executado faria parecer.

O Software Engineering Institute destaca a importância de utilizar dados do fluxo de desenvolvimento para compreender a qualidade e a eficiência das entregas. Pesquisas sobre os fatores que influenciam a entrega dentro do prazo, como o estudo publicado pela IEEE, também reforçam que problemas de qualidade e retrabalho podem comprometer a previsibilidade.

Para mim, o principal sinal não é um defeito isolado. O que merece atenção é quando tarefas semelhantes começam a apresentar mais reaberturas, quando o número de correções aumenta ou quando o esforço necessário para concluir uma entrega cresce sem que o escopo tenha mudado. Nesse momento, a equipe pode estar produzindo muito movimento, mas pouco avanço real.

No Saint Jude, os indicadores de desempenho podem ser analisados em conjunto com os dados do projeto para identificar quando o esforço está sendo consumido por retrabalho, revisões ou atividades que não avançam para uma conclusão definitiva. Essa visão ajuda a entender não apenas quanto foi feito, mas quanto do trabalho realmente se transformou em uma entrega aceita.

O problema é a combinação dos sinais

Nenhum desses sinais, isoladamente, prova que um projeto irá atrasar. Um SPI abaixo de 1 pode representar uma variação temporária. Um aumento no tempo de ciclo pode estar relacionado a uma tarefa excepcionalmente complexa. Uma mudança de escopo pode ser necessária para proteger o resultado do projeto. O que me preocupa é quando vários desses sinais começam a aparecer ao mesmo tempo.

Quando o prazo previsto se afasta da baseline, a folga do caminho crítico diminui, o WIP cresce, as entregas ficam mais lentas, os requisitos continuam mudando e os bloqueios se acumulam, o projeto está contando uma história. Talvez o atraso ainda não tenha acontecido oficialmente, mas os dados já estão mostrando que a forma atual de execução pode não ser suficiente para cumprir o plano.

É por isso que eu não acredito em uma gestão de projetos baseada apenas em relatórios estáticos ou em reuniões de acompanhamento. O relatório mostra o que aconteceu. A reunião pode ajudar a discutir o que está acontecendo. Mas precisamos também interpretar o que os dados indicam sobre o que pode acontecer daqui a algumas semanas.

Gestão de riscos em projetos precisa ser contínua

Eu não acredito que exista uma plataforma capaz de eliminar todos os riscos de um projeto. Pessoas mudam, fornecedores atrasam, estimativas erram, clientes alteram prioridades e decisões importantes podem demorar mais do que o esperado. A incerteza sempre fará parte do trabalho de gestão.

A diferença está em quando percebemos que alguma coisa está saindo da direção planejada. Se descobrimos o problema no dia em que a entrega deveria acontecer, nossas opções são poucas. Se identificamos o risco algumas semanas antes, talvez ainda seja possível redistribuir capacidade, ajustar uma prioridade, dividir o escopo, negociar uma dependência ou criar uma mitigação.

Como a IA para gestão de projetos ajuda a prever atrasos

O Saint Jude não substitui ferramentas como Jira, Azure DevOps, ClickUp, Monday.com ou Asana. Essas plataformas continuam sendo fundamentais para organizar e executar o trabalho. O Saint Jude atua em uma camada diferente: utiliza os dados que os projetos já produzem para ajudar gestores, PMOs e lideranças a compreender a saúde dos projetos, identificar padrões e tomar decisões com mais antecedência.

Na prática, uma plataforma de inteligência de projetos precisa fazer mais do que reunir informações em um dashboard. Ela precisa ajudar a explicar o que está acontecendo, quais sinais merecem atenção e quais ações podem reduzir a exposição ao risco. É essa camada de gestão de projetos baseada em dados que permite transformar informações espalhadas em decisões mais rápidas.

Se você está procurando um software para gestão de riscos capaz de acompanhar a execução real e ajudar sua equipe a agir antes que os problemas se tornem atrasos, o Saint Jude foi criado para esse tipo de análise.

No final, prever atrasos não significa adivinhar o futuro. Significa observar o presente com atenção suficiente para perceber quando o comportamento do projeto começa a se afastar do esperado. Significa entender que uma tarefa atrasada pode ser apenas uma variação ou pode ser o início de um efeito em cadeia.

E talvez essa seja a pergunta mais importante: no seu projeto, você está esperando a data ser perdida para agir ou já consegue identificar os sinais que indicam que ela pode ser perdida?

Até mais!

Erik Scaranello