Crashing - Spider Project Team

The Spider Team
Reference Library
Artigo:
Reduzindo a duração de projeto com “crashing” em atividade não crítica
(tópico abordado na E-Plan)
Por Peter Mello, PMP, PMI-SP, SpS
Crashing
O “Crashing” é uma técnica de aceleração de cronogramas através da redução da duração de
atividades mediante a colocação de recursos extras ou uso de horas extras.
Se uma atividade de alvenaria leva 6 dias para ser realizada com uma produtividade de 1m2
por hora e um pedreiro, podemos aumentar as horas de trabalho diárias ou somar um novo pedreiro a
equipe para reduzir o prazo.
A noção que temos derivada da aplicação do Método do Caminho Crítico é de que só adianta
reduzir a duração de atividades que estejam no caminho crítico. Isso de fato é verdade em
cronogramas que não estejam levando em consideração o uso de recursos, mas a transposição da
regra para cronogramas baseados em corrente crítica é uma falácia.
Quando falamos em corrente crítica, não importa se estamos falando da aplicação do Método
da Corrente Crítica ou do Success Driven Project Management ou de qualquer cronograma baseado
em restrições (aplicação do RCP – Resource Critical Path).
O “Crashing” em cronogramas adequadamente construídos com a aplicação do RCP e a
adequada distribuição dos recursos disponíveis pode ser feito tanto em atividades críticas como em
atividades não-criticas, podendo resultar em redução da duração do projeto em ambos os casos.
Nota: não confundir redução da duração do projeto e da atividade com carga de trabalho.
Eventualmente a troca de recursos de maior produtividade por recursos de menor produtividade irá
significar um aumento no total de horas realizadas pelos recursos, sem necessariamente significar
aumento na duração da atividade (Um recurso que produz 1m2 por hora realiza 48m2 de alvenaria
em 6 dias; um recurso que produz 0,8m2 por hora e realiza 4 horas extras diárias realiza o mesmo
trabalho em 5 dias. No entanto, o recurso mais produtivo tem uma carga total de 48 horas e o de
menor produtividade tem uma carga total de 60 horas).
Na ilustração acima, o recurso A trabalha um total de 180 horas distribuídos em pouco mais de
5 semanas. O recurso C totaliza 240 horas e o recurso B totaliza 130 horas. Nas primeiras duas
semanas, todos os recursos trabalham praticamente o mesmo número de horas (as horas
acumuladas de A,B,C tem a mesma distribuição no tempo).
[email protected] - +55 61 3244-2510
(1)
The Spider Team
Reference Library
As horas acumuladas acima são resultado do seguinte cronograma:
Os recursos A,B,C estão distribuídos em atividades críticas (em vermelho) e não-críticas (em
verde). O objetivo do exercício é demonstrar que o “crashing” em uma única atividade não-crítica
pode proporcionar uma redução no tempo total do projeto.
Neste exercício, A e B são recursos do mesmo tipo, mas eventualmente em um tipo de
atividade o recurso B tem menor produtividade (o recurso A possui maior especialização na atividade
e por isso é capaz de realizá-la com maior produtividade).
Para demonstrar o crashing, vamos alterar o calendário de uma atividade (Atividade 14) para
permitir que se possa realizar horas-extras.
Na programação original, 60 unidades eram realizadas em 8 dias. A atividade em relação a outras
atividades do cronograma tinha uma folga total de 30 horas e não pertence ao caminho crítico.
Na nova programação, a carga diária de trabalho é aumentada de 8 para 14 horas e o trabalho e
então concluído em 5 dias. Como o cronograma foi otimizado em função da nova situação de
planejamento, a atividade continua fora do caminho crítico, mas sua folga total foi reduzida de 30 para
16 horas.
Nota: A folga total não depende neste caso da duração da atividade (ou teria aumentado a folga ao
invés de reduzir), mas sim da nova seqüência de atividades que foi criada em função da entrega
antecipada daquela atividade.
[email protected] - +55 61 3244-2510
(2)
The Spider Team
Reference Library
O novo cronograma criado em função do “crashing” em atividade não crítica é o seguinte:
A antecipação de três dias em uma atividade não-crítica reduziu o projeto em três dias.
Comparando o cronograma com a linha de base (atividades em laranja), podemos perceber que a
redução da duração da atividade 14 proporcionou alterações no seqüenciamento e duração das
atividades 4, 5, 6, 12 e 15.
Pelo gráfico de horas de trabalho acumulada, podemos perceber que o Recurso A trabalhou
mais nas duas primeiras semanas que o restante da equipe pois estava executando horas extras. O
novo cronograma reduziu a carga total de horas de trabalho para o recurso B (redução de 130 para 20
horas) e também do recurso A (redução de 180 para 170 horas).
Resultados:

A carga horária total de todos os recursos foi reduzida em 20 horas, embora o Recurso
A tenha feito horas extras durante cinco dias;

O tempo total do projeto foi reduzido em 3 dias;

Se a empresa tiver banco de horas, o custo final do projeto com o “crashing” foi
reduzido;

Se a empresa não trabalhar com banco de horas, o custo final do projeto deverá ser
calculado em função do custo extra dos 5 dias com carga de trabalho expandida (20
horas extras) e da economia global (10 horas do Recurso B e 10 horas do Recurso A)
[email protected] - +55 61 3244-2510
(3)
The Spider Team
Reference Library
Como isso é possível?
Em cada situação, diversos eventos podem acontecer para favorecer situações em que um
cronograma tem reduções por conta da aplicação do “crashing”, seja em atividades críticas ou nãocríticas.
No caso particular deste cronograma, utilizamos um recurso especial encontrado em softwares
de aplicação profissional como o Primavera e o Spider: Nivelamento de Recursos por HABILIDADE.
O segredo da redução deste projeto em função do tempo total de horas trabalhadas e da
duração total do projeto está no fato de que o Recurso A é capaz de realizar a atividade 3 com uma
produtividade de 1.3 unidades por hora e o Recurso B é capaz de realizar a atividade 3 com uma
produtividade inferior (0.8 unidades por hora).
No cenário original, o Recurso A estava ocupado na realização de atividades de projeto que
não lhe permitiam trabalhar na atividade 3. Ao antecipar a entrega da atividade 14, o recurso estava
então “livre” para realizar a atividade 3 no lugar do recurso B e todo o reagendamento das atividades
subseqüentes foi otimizado para aproveitar a maior produtividade de A.
Isso fica visível se compararmos o cronograma individual de cada recurso em ambos os
cenários:
Nota: O campo Duração Horas [Restante] acumulado não é o somatório da carga individual de cada
recurso e sim a carga diária acumulada entre o primeiro e último dia do projeto. Podemos perceber na
carga individual de cada recurso uma redução de 20 horas (10h em A e 10h em B).
[email protected] - +55 61 3244-2510
(4)