Quando um Gerente de Projetos monta um cronograma com a equipe, diversas variáveis são consideradas. Algumas delas por exemplo são a quantidade de recurso para cada atividade, o tempo de duração de cada atividade, a quantidade de dias, o valor do recurso entre muitos outros.

Por algum motivo que não estava no cronograma o projeto muitas vezes precisa ser entregue mais rapidamente, algumas vezes até por fenômenos da natureza. Imagine uma empresa que fica em uma região com frequentes enchentes no verão, por exemplo. Por conta clima, as chuvas passam a começar mais cedo. Caso exista um projeto de backup acordado para entregar em dezembro e precisa adiantá-lo para novembro, o cronograma precisará acelerar.

O conceito de Crashing significa efetuar “gastos” extras para fazer algo mais rápido. Isso significa, colocar mais recursos ou gastar com horas extras. Esses novos gastos são realizados para estancar ou minimizar algum problema grave que aconteceu no decorrer do projeto.

Alguns riscos precisam ser ponderados na hora de utilizar o crash. O mais difundido é aumentar o número de recursos no projeto, mas é bem difícil colocar mais recursos com os mesmos skill do time original. Caso seja necessário, quem entrar no projeto não estará familiarizado com o escopo, com o time, talvez com a tecnologia e o cliente. Além disso pode ter que “retirar” alguém full time do projeto para guiar os novos colaboradores em sua curva de aprendizagem.

Quando é preciso diminuir o tempo de entrega do projeto por algum motivo não mapeado no planejamento, muitas vezes os altos esforços acabam direcionando para o lado contrário e trazendo mais tempo de conclusão. Às vezes as boas intenções em ajudar podem acarretar problemas no futuro. O tempo curto para balancear os prós e contras do crash deve ser fundamental para o sucesso da ação. É preciso analisar o máximo de possibilidades para agregar valor na entrega final.