7 dicas essenciais para um cronograma confiável

O cronograma é uma ferramenta que modela o “mundo real” das atividades e etapas de execução do projeto.

Se o cronograma for bem feito , ele será um excelente apoio à tomada de decisão, pois permitirá analisar antecipadamente potenciais riscos/problemas do projeto, possibilitando o replanejamento ou a realização de ações para evitar que eles ocorram.

Por outro lado, um cronograma mal elaborado será inútil para o projeto ou, ainda pior, será uma fonte errada de informações para a tomada de decisão. Se não for para ajudar, que pelo menos não atrapalhe, não é mesmo?

Neste artigo, serão apresentadas 7 dicas essenciais para gerarmos cronogramas confiáveis:

1. Por que é fundamental criar uma rede fechada com predecessoras e sucessoras em todas as atividades;
2. Como a ausência de dependências em níveis altos da EAP pode gerar antecipações no projeto;
3. A importância do monitoramento dos marcos intermediários  do projeto;
4. Como eliminar a subjetividade das estimativas de duração;
5. Uma regra prática para o nível mínimo de detalhamento das atividades;
6. O risco oculto da definição de restrição de datas as atividades;
7. A importância da atualização correta de cronogramas para a análise e tomada de decisão.

1- Estabeleça relações de predecessoras e sucessoras em todas as atividades

Uma das funções principais de um cronograma é nos ajudar a estimar a data para a conclusão do projeto e de seus marcos intermediários.

No entanto, no planejamento inicial das atividades do projeto, é possível que nos esqueçamos de criar algumas relações que pareçam menos óbvias ou até pouco relevantes.

A figura abaixo exibe um exemplo de cronograma inicial para o projeto fictício de implantação de uma nova loja de livros (usei o Microsoft Project neste artigo):

Alguns pontos a serem observados:

• A loja está prevista para ser inaugurada em 17/01 . Lembre-se que cada dia de atraso representa vendas e faturamento perdido . Tempo é dinheiro!
• Depois da atividade de construção da loja, são abertas duas frentes em paralelo: (1) instalação dos sistemas informatizados de vendas e (2) mobília da loja e recebimento dos livros.
• O cronograma está mostrando em vermelho as atividades que fazem parte do caminho crítico do projeto , ou seja, aquelas que, se atrasarem, atrasam o projeto como um todo.
• A atividade de instalação dos sistemas de venda não é crítica (está em azul). Isso significa que ela tem folga , ou seja, pode atrasar alguns dias sem atrapalhar a data de término do projeto.

Mas quantos dias de folga tem a tarefa de instalação dos sistemas de venda? Será que ela pode atrasar indefinidamente ?

Na figura abaixo, foi exibida a coluna que indica a folga de cada atividade:

Repare que a atividade de instalação dos sistemas de vendas tem uma folga de 30 dias, o que indica que ela pode atrasar essa quantidade de tempo sem impactar na data de término do projeto .

Mas será que essa informação é confiável ?

Antes da inauguração da loja, há uma atividade de treinamento dos funcionários. Para que isso ocorra, no nosso exemplo, é necessário que os sistemas de venda já estejam instalados, senão a equipe não vai saber como processar as vendas.

Dessa forma, precisamos indicar no nosso modelo que o treinamento de funcionários depende da instalação dos sistemas de vendas.

Quando crio essa relação, perceba que a folga da instalação dos sistemas é reduzida para 15 dias (metade do tempo anterior).

Um outro ponto de reflexão é que o caminho crítico não é imutável durante todo o projeto. Nesse caso, por exemplo, se a atividade de instalação dos sistemas atrasar 20 dias, ela passa a estar no caminho crítico, conforme ilustrado abaixo:

Em resumo, é importante que todas as atividades do seu cronograma tenham predecessoras e sucessoras . Pense o que pode impactar o início de cada atividade e o que outras atividades podem ser impactadas pelo seu atraso.

E se, depois de analisar, você verificar que não há nenhuma dependência?

Uma dica é sempre criar dois marcos nos seus projetos: (1) início do projeto e (2) término do projeto (no exemplo da loja, usei o marco “loja em operação”.

Se a atividade não depender de nenhuma outra para iniciar, estabeleça o início do projeto como sua predecessora. Analogamente, se nenhuma outra atividade for impactada pela tarefa em análise, defina o término do projeto como sua sucessora.

2- Não crie relações de dependência com tarefas resumo

Você deve estar achando que eu sou louco, certo? Acabei de escrever que todas as atividades devem ter predecessoras/sucessoras e agora sugiro não criar relações nas tarefas resumo…

Tarefas resumo são agrupamentos de trabalho e não atividades a serem efetivamente executadas.

Em alguns casos, pode ser muito prático sequenciar tarefas resumo, mas isso pode “esconder” a real relação de dependência existente e limitar nossa capacidade de realizar o projeto de maneira mais ágil. Veja o exemplo abaixo:

Sugiro atenção especial para os seguintes aspectos do cronograma acima:

• As atividades de resumo estão relacionadas diretamente: Requisitos, Parametrizações do sistema, Validação/Homologação e Implantação em Produção.
• A data prevista de término do projeto está para 01/12.

Ao detalhar as tarefas resumo, fica claro que o módulo Financeiro do sistema pode ter sua parametrização e validação realizadas de maneira independente do módulo de RH.

Retirando as relações entre as tarefas resumo e sequenciando-as diretamente nas atividades raiz do projeto, temos o resultado a seguir:

Com essa alteração nas dependências, conseguimos reduzir a data prevista de término do projeto do dia 01/12 para o dia 25/10.

Apesar de bastante simplificado, o objetivo desse exemplo foi demonstrar que a criação de relações de precedência em tarefas resumo pode “esconder” relevantes oportunidades de compressão na duração do projeto.

Em um exemplo simples, isso pode parecer óbvio, mas em projetos reais com centenas de atividades, podemos encontrar ótimas oportunidades para planos mais eficientes.

3- Separe os marcos relevantes (milestones) do cronograma do projeto

Em projetos mais complexos, monitorar somente a data de término do projeto pode não ser a melhor estratégia para garantir que o mesmo esteja “nos trilhos”.

Uma boa abordagem é a criação de marcos intermediários com entregas relevantes para o projeto. Isso permite identificar desvios relevantes no meio do caminho mais facilmente e ainda melhor a comunicação com os stakeholders .

Complementando o cronograma da implantação do ERP, vamos incluir alguns marcos intermediários.

Perceba que os milestones  têm como predecessoras as atividades do cronograma, o que significa que eles irão adiantar ou atrasar quando o mesmo ocorrer com as atividades de que dependem.

Sob o ponto de vista de comunicação, os marcos são muito eficazes, pois permitem uma fácil visão da “história” do projeto contada pelas suas principais etapas. Simplifica muito o entendimento de pessoas externas ao projeto.

Algumas ferramentas proporcionam visões elegantes sobre os marcos do projeto em relatórios na Web. Veja abaixo um exemplo utilizando o sistema AEVO Innovate, que importa as informações do cronograma do MS Project:

4- Estime a duração das atividades utilizando critérios claros

Estimar a duração das tarefas do cronograma nem sempre é um trabalho fácil.

Diferentes pessoas com experiências diversas podem ter visões discrepantes sobre a complexidade de cada atividade e, portanto, estimar durações diferentes .

Mas como é possível estimar a duração de uma atividade de forma objetiva e que facilite o consenso entre os membros da equipe do projeto?

Uma forma que reduz a subjetividade é por meio de índices de produtividade .

Para projetos de Engenharia , é comum que as empresas tenham histórico de realização de atividades e, portanto, possam ter uma base de suporte para estimar as próximas atividades. Por exemplo, uma construtora pode ter uma produtividade histórica de 0, 8 hora para colocar 1 metro quadrado de forma para concretagem. Assim, se é necessária a colocação de 100 metros quadrados de forma com 1 recurso, a duração estimada da atividade é de 80 horas.

Para projetos de Software , usualmente as empresas utilizam métodos para contagem da complexidade das funcionalidades a serem desenvolvidas, como pontos de função ou pontos de estórias ( story points ). Assim, por exemplo, uma desenvolvedora de software Java pode ter uma produtividade de 7 horas para desenvolver 1 ponto de função de aplicações. Caso uma funcionalidade tenha 20 pontos de função, estima-se que 1 programador a desenvolva em 140 horas.

É interessante que a memória do cálculo utilizado para a estimativa seja registrada no dicionário do cronograma , facilitando o acesso por outras pessoas do projeto e reduzindo a sua subjetividade.

5- Evite que a duração das atividades ultrapasse o tempo de 2 reuniões de coordenação

Uma dúvida comum no planejamento de cronogramas é: até que ponto precisamos detalhar as atividades?

Existem várias diretrizes que podem ser seguidas, como, por exemplo, detalhar até o nível que permita alocar trabalho para um recurso.

Sob o ponto de vista de monitoramento do projeto, no entanto, uma forma interessante é relacionar esse nível ao tamanho total do projeto.

Para um projeto de 2 anos de duração, detalhar as atividades até o nível de horas de duração pode ser muito mais do que o necessário . Já para um projeto de 1 semana (uma parada de fábrica, por exemplo), esse nível de detalhes é fundamental .

É provável que você tenha reuniões periódicas para avaliar o andamento dos projetos da sua área ou empresa. Assim, a fim de criar uma regra mais objetiva, podemos relacionar a duração máxima de cada atividade ao período entre 2 reuniões de acompanhamento do projeto.

Para exemplificar, vamos supor que haja reuniões de coordenação do projeto com frequência semanal . Nesse caso, uma atividade com 1 mês de duração pode não ser interessante, pois você pode realizar até 4 reuniões de coordenação com essa tarefa em andamento (e, teoricamente, dentro do prazo) para descobrir, somente na última semana, que ela atrasou.

Não seria melhor se essa tarefa tivesse sido detalhada em 2 ou mais atividades com até 2 semanas de duração?

Na primeira semana, você já teria uma informação importante: a tarefa iniciou conforme previsto ? Já na segunda semana, você pode questionar: a atividade terminou conforme previsto ?

Essa análise binária (1 ou 0 – sim ou não) é muito mais pragmática do que analisar percentuais potencialmente subjetivos de avanço (a atividade está com 27, 9% de avanço).

Dessa forma, uma regra simples para nível de detalhamento de atividades é: a duração não deve ser superior a 2 ciclos de reunião de monitoramento dos projetos.

6- Evite “cravar” datas nas atividades do cronograma

Conforme já discutido neste artigo, um dos principais objetivos de um cronograma é de nos apoiar na previsão de datas das atividades.

Para isso, o ideal é que o planejador do projeto estime a duração (e recursos) das atividades e defina relações de dependência (predecessoras e sucessoras) entre as mesmas, criando uma rede fechada de atividades.

Com uma rede fechada, devemos definir apenas a data de início do projeto e o cronograma irá programar as datas de todas as tarefas a partir de suas durações e sequenciamento. Ou seja, é o cronograma quem vai nos “dizer” a data das atividades.

No exemplo abaixo, apenas a data de início do projeto (17/08) foi definida manualmente. As demais datas foram calculadas pelo MS Project, gerando a sua programação.

O problema ocorre quando resolvemos definir datas diretamente nas atividades , pois isso gera restrições nas mesmas.

Para exemplificar o caso, vamos considerar o trecho abaixo, focando na atividade “14-Validar módulo financeiro”, que depende somente do término da “11-Parametrizar módulo financeiro” para iniciar.

Repare que a previsão de início da atividade “14-Validar módulo financeiro” está para o dia 28/09. Observe também que a atividade “11-Parametrizar módulo financeiro” tem uma duração estimada de 20 dias.

Como esse cronograma não tem datas “cravadas” , se a atividade “11-Parametrizar módulo financeiro” adiantar, esperamos que o cronograma antecipe o início da atividade “14-Validar módulo financeiro”.

Na figura abaixo, o cronograma foi atualizado e a atividade “11-Parametrizar módulo financeiro” teve a sua duração reduzida para 10 dias. Repare que, conforme esperado , a data de início da atividade “14-Validar módulo financeiro” foi adiantada para o dia 14/09.

Mas o que aconteceria se tivéssemos definido a data manualmente no MS Project?

No exemplo abaixo, eu escrevi manualmente a data 28/09 na atividade “14-Validar módulo financeiro”. Repare que o MS Project cria uma restrição do tipo “Não iniciar antes de” (eu abri a janela de Informações da Tarefa para verificar essa informação).

Isso significa na prática que, ao informar manualmente datas para o cronograma, ele entende que está sendo criada uma restrição que impede que a tarefa inicie antes da data informada, mesmo que todas as suas predecessoras já tenham sido concluídas.

O impacto que isso pode gerar é de o cronograma não ser atualizado corretamente . Na figura abaixo, eu reduzi a duração da atividade “11-Parametrizar módulo financeiro” para 10 dias. Dessa vez, a restrição impediu que a atividade “14-Validar módulo financeiro” fosse adiantada.

Obviamente que, dependendo da situação do projeto, essa situação possa ser desejável. Por exemplo, caso essa validação dependa da presença de um profissional externo com viagem agendada para essa data, não será possível adiantá-la mesmo que as suas predecessoras tenham terminado.

A ideia é que não criemos essa restrição por desconhecimento, mas somente quando for exatamente o comportamento que estamos buscando.

7- Atualize o cronograma respeitando passado e futuro

Cronogramas não são feitos apenas para o planejamento inicial do projeto, devendo ser atualizados periodicamente com o andamento realizado das atividades e eventuais replanejamentos das atividades futuras.

Para a atualização do cronograma, um conceito fundamental é o da Data de Status do projeto, que é a data de “corte” que separa o que já ocorreu (passado) e o que está previsto para ocorrer no projeto (futuro).

Além disso, a Data de Status é a referência para identificar quão atualizado está o cronograma. Se estivermos em agosto, avaliando um cronograma com Data de Status de maio, sabemos que não estamos analisando uma informação atual.

Como a Data de Status separa o passado e o futuro do projeto, uma regra simples a ser seguida é que atividades realizadas devem estar antes da Data de Status e atividades previstas devem estar após a Data de Status. Simples, não é mesmo?

Vamos ver como isso se aplica no cronograma do projeto Implantação do ERP.

Suponha que estivéssemos, no final do dia 20/09 , atualizando o andamento do projeto no cronograma. Suponha também que tenhamos as seguintes informações de andamento do projeto:

• A atividade “11-Parametrizar módulo financeiro” iniciou na data prevista, mas já foi concluída no próprio dia 20/09, adiantada em relação à sua previsão de 27/09.
• A atividade “12-Parametrizar módulo de RH” não iniciou na data prevista de 14/09, estando atrasada e prevista para iniciar no dia 21/09.

Com essas informações, conforme ilustrado na figura a seguir, atualizei o cronograma seguindo os passos listados:

• Defini a Data de Status (linha vertical vermelha) para o dia 20/09;
• Defini a Data de Término Real da atividade “11-Parametrizar módulo financeiro” para o dia 20/09.
• Reagendei o Início previsto da atividade “12-Parametrizar módulo de RH” para o dia 21/09.

Observe que, com essa atualização, conseguimos extrair várias informações relevantes do nosso cronograma, que está efetivamente nos apoiando como um modelo da realidade do projeto:

• No item 1 da figura, fica claro que o adiantamento no término da atividade 11 resultou na previsão de adiantamento também da atividade 14.
• No item 2 da figura, no entanto, é mostrado que o atraso do início da atividade 12 está potencialmente impactando no início da atividade 15 e até mesmo na data de término prevista para o projeto (vide seta destacando o atraso para o dia 01/11).

Enfim, a atualização do modelo nos entregou informações valiosas de impacto. Podemos, por exemplo, focar em maneiras para entregar a atividade 12 no prazo a fim de que a data final do projeto seja mantida .

Além disso, um cronograma bem atualizado gera uma Curva de Avanço Físico confiável.

Ótimo, correto?

Agora vamos olhar uma forma errada de atualização das atividades, que ainda é comumente encontrada em projetos.

Utiliza-se muito apenas definir o percentual concluído das atividades , sem impactar nas datas. Neste mesmo exemplo, uma atualização errada seria definir 100% para a atividade 11 e 0% para a atividade 12. Veja o que aconteceria:

Repare que, ao atualizar o cronograma simplesmente usando os botões de atualização do percentual concluído, NADA acontece com as datas do cronograma.

Isso significa que o cronograma não está nos ajudando a identificar o impacto previsto do estado atual de atualização do projeto. Ou seja, se for para atualizar dessa maneira, é melhor nem perder o tempo, não é mesmo?

Em resumo, este artigo mostrou como a utilização de algumas regras simples podem tornar o seu cronograma uma ferramenta eficaz para análise do andamento e antecipação de eventuais problemas/riscos . Desde as estimativas/sequenciamento até a atualização das atividades, o correto uso da ferramenta proporciona benefícios diretos para o alcance dos resultados esperados do projeto!