A Importância das novas métricas “Drag” e o “Custo Drag” na Análise do Caminho Crítico
Nesta postagem, convido ao leitor a conhecer um pouco do trabalho de Stephen Devaux, criador do cálculo do Drag (Arrasto) no Caminho Crítico de um Projeto.
Embora o método tenha algumas décadas e com aplicações importantes em diversos projetos e trabalhos, ele não é ainda muito conhecido e há uma oportunidade de melhorias significativas em resultados de projeto que podem ser obtidos com o seu entendimento.
Ao ler este conteúdo pela primeira vez, achei que se tratava de um cálculo complexo e não pude compreender todos os seus benefícios, mas depois tive a oportunidade de verificar que: A) Não é tão complexo de ser calculado quando entendemos o princípio de sua aplicação. B) Uma vez que compreendemos sua aplicação, entendemos que vale o esforço de cálculo;
C) Hoje alguns softwares já realizam este cálculo de forma automática, bastando portanto que entendamos sua aplicação.
Em listas de discussão, as sugestões para o termo “Drag” foram de “Retardo” ou “Arrasto”, ficando a segunda palavra como a definição interpretada como mais adequada para o termo, até mesmo pois outras formas de aplicarmos a palavra “Drag”, como “Drag Equation” já vêm sendo traduzidas como “Arrasto” em outros contextos (Equação de Arrasto, Coeficiente de Arrasto, entre outros).
O texto a seguir está em sua tradução livre em Preto e o original – encaminhado pelo próprio sr. Devaux para sua divulgação – está em Vermelho.
The Importance of the New Metrics Drag and Drag Cost in Critical Path Analysis
by
Stephen A. Devaux, MSPM, PMP
(Tradução livre, por Peter Mello, PMP, PMI-SP, SpS)
Qual é a diferença entre a aplicação do Método do Caminho Crítico e Análise pelo Caminho Crítico (CPM)?
What is the difference between critical path method (CPM) scheduling and critical path analysis?
A aplicação do Método do Caminho Crítico é o processo de se desenvolver um cronograma com as atividades para o trabalho de um projeto tendo como base a sequência lógica entre estas atividades e suas durações. A sequência mais longa entre tais atividades e restrições irá determinar o caminho mais longo do projeto e este é então chamado de caminho crítico.
CPM scheduling is the process of developing a schedule of the activities of the project’s work on the basis of the logical sequence of those activities and their durations. The longest sequence of such activities and constraints determines the length of the project and is called the critical path.
Frequentemente, o cronograma desenvolvido com o método se torna a base para se determinar quando os recursos necessários a cada atividade deverão estar disponíveis de forma a cumprir com a duração agendada. No evento em que um dado recurso não está disponível (ou não está disponível no volume necessário) para atender aos requerimentos do cronograma, em termos tanto de duração como de momento, a atividade talvez tenha que ser postergada. Este processo de postergação de atividades até que todos os recursos necessários estejam disponíveis é chamado de nivelamento de recursos e é normalmente realizado por um processo automatizado e baseado em algoritmos que uma grande maioria de pacotes de software de gestão oferecem. Alguns destes algoritmos são mais robustos que outros, e os softwares competem no mercado tendo como base a sua habilidade de gerar cronogramas nivelados por recursos de maior ou menor duração. Por fim, um cronograma que é bem desenvolvido quase sempre exige que se considere a disponibilidade (ou indisponibilidade) de recursos e o atraso das datas necessárias. Se estes atrasos ocorrem no caminho mais longo, ou se são tão longos que fazem com que um caminho alternativo passe a ser o mais longo (ex. mais longo do que a folga do caminho atual), então a duração total de um projeto será alterada.
Frequently, the CPM schedule then becomes the basis for determining when the resources needed by each activity must be available in order to meet its CPM schedule duration. In the event that a needed resource is unavailable (or unavailable in the needed volume) to meet the schedule requirements of an activity in terms of both duration and timing, that activity may have to be delayed. This process of delaying activities until their needed resources become available is called resource leveling and is often an automated process based on algorithms that most project management software packages offer. Some of these algorithms are more robust than others, and software packages often compete in the marketplace on the basis of the ability to generate a longer or shorter resource-leveled schedule. Ultimately, a schedule that is well designed almost always requires taking into account the availability (and unavailability!) of resources and delaying activity dates accordingly. If such delays are on the longest path, or if they are so long as to cause a path that was not the longest to become the longest (i.e., longer than the path’s float), then the project’s duration will be increased.
O que descrevemos até o momento é o trabalho cuidadoso e adequado que deve ser executado no desenvolvimento de um cronograma de qualquer projeto com uma complexidade significativa, importância ou risco. No entanto, por ignorância ou mesmo inocência, muito projeto não tem seus cronogramas desenvolvidos com a atenção necessária. Em muitas situações um Diagrama de Gantt simples é desenhado (“Nós iremos fazer isso aqui, e então isso ali e então mais alguma coisa aqui e, talvez alguma coisa mais ali…); em algumas vezes o agendamento de um cronograma de trás para frente é utilizado (“Nós temos que terminar isso nesta data, então precisamos disso pronto aqui, e isso significa que isso tem que ser concluído aqui,..”); e algumas vezes apenas se decide dar uma corrida rápida da forma mais forte possível por um mês, de forma a se descobrir o que pode ser feito e então se pensar no que fazer como próximo passo.
What we have described so far is the due diligence that should be performed in scheduling any project of significant complexity, importance or risk. However, due to ignorance or simple unwillingness, many projects are not scheduled in the manner described above. Sometimes a simple Gantt chart is drawn (“We’ll do this here, and then we’ll do this, and then this, and perhaps this stuff here,..”); sometimes backward scheduling is used (“We’ve got to finish by this date, so we need to get this done by here, and that means this has to be done by here,..”); and sometimes it’s just decided to “sprint” as hard as possible for a month, see what gets done, and then then think about what we can do next.
No entanto, a chave é descobrir que nenhum destes métodos remove o caminho crítico ou faz com que sua análise seja menos valiosa!
However, the key is to recognize that none of these methods either removes the critical path or makes critical path analysis less valuable!
O primeiro princípio importante é que praticamente qualquer projeto tem uma vantagem/lucro se completado antes. Em noventa e nove por cento das vezes, o mais cedo que um projeto é concluído, é o mais cedo que o seu produto pode ser entregue e comece a gerar o valor intencionado. Em muitos casos como no desenvolvimento de novos produtos, o valor da aceleração de um cronograma pode ser enorme. Adicionalmente, projetos mais curtos normalmente exigem menos esforço críticos e custos de suporte. E finalmente, quando um projeto é concluído mais cedo, ele remove praticamente todo o risco relacionado ao término tardio! Estes fatores, muitas vezes são deixados sem uma quantificação do seu valor durante o planejamento de um projeto, normalmente representam uma parcela significativa do benefício em se obter um cronograma mais curto, muitas vezes sendo isso suficiente para justificar recursos adicionais necessários ao processo de se realizar a compressão deste cronograma.
The first important principle is that almost every project can profit by being completed sooner. Ninety-nine percent of the time, the sooner a project is finished, the sooner its product can be deployed to start generating its intended value. In many cases such as new product development or enabler projects upon whose deployment other value generators are relying, the value of schedule acceleration can be huge. Additionally, shorter projects often require less overhead and support costs. And finally, when a project finishes earlier, it retires almost all the risk of finishing later! These factors, often left unquantified in project planning, usually represent a very significant benefit to achieving a shorter schedule, often sufficient to more than justify additional resources needed to bring about such schedule compression.
Se um projeto mais curto poderia aumentar o valor do projeto, como é que podemos analisar a melhor forma de realizar esta compressão? A resposta é a Análise do Caminho Crítico, que pode ser executada em qualquer projeto, não importa de qual forma ele foi desenvolvido.
If a shorter schedule would increase a project’s value, how can we analyze how we might best bring about such schedule compression? The answer is critical path analysis, which can be performed on any project no matter how it has been scheduled.
Todo projeto é exatamente tão longo quanto o seu caminho mais longo, muitas vezes chamado de “as built critical path” (ABCP) na indústria da construção. Este caminho é constituído de todas as atividades, esforços, atrasos, retrabalhos, restrições (lógicas, de recurso ou calendário) que são combinadas para criar o caminho mais longo que determina a duração atual do projeto. A Análise do Caminho Crítico é o processo, realizado no início ou em qualquer momento durante a execução, de se determinar quais são os fatores que geram postergações e o que pode ser feito em relação a eles para serem eliminados caso a equipe do projeto ou pessoas chave no projeto assim o decidam.
Every project is exactly as long as its actual longest path, often called the as built critical path (ABCP) in the construction industry. This path will consist of all the activities, sprints, stumbles, delays, rework and constraints (logical, resource, and calendar) that combine to create the longest path which determines the project’s actual duration. Critical path analysis is the process, performed up front or at any point during execution, of determining the delaying factors and what might be done about them if the project team and key stakeholders so decide.
A Análise do Caminho Crítico está disponível há décadas. No entanto, nos últimos quinze anos, uma nova e importante ferramenta foi adicionada para a caixa de ferramentas desta análise. Esta nova ferramenta é chamada de “Critical Path Drag” (Arrasto do Caminho Crítico). Enquanto a análise tradicional mede as atividades que não estão no caminho mais crítico, determinando o quanto elas podem desviar sem se tornarem críticas (por exemplo, através de suas folgas), o “drag” mede os dados no caminho mais longo, de forma a verificar quanto tempo cada um está adicionando a duração do projeto (Arrasto). E o seu corolário é o “drag cost”: qual é o valor daquele tempo adicionado que está reduzindo o valor do investimento no projeto (Custo de Arrasto).
Critical path analysis has been around for many decades. But within the past fifteen years, an important new tool has been added to the toolbox of the analysis. This new tool is called critical path drag. Whereas traditional analysis measured activities that were not on the longest path, determining the amount they could slip before becoming critical (i.e., their float or slack), drag actually measures the things on the longest path, to see how much time each is adding to the project duration. And its corollary is drag cost: how much is that added time reducing the value of the project investment.
Em outras palavras, o “Drag” é crítico, a folga não é.
In other words, drag is critical, float is not.
Alguns pacotes comercialmente disponíveis como o Spider Projeto já começam a oferecer o cálculo do “drag”. Mas esta informação também é crucial para aquelas pessoas em projetos que não tem acesso a tais pacotes.
Commercially-available software packages such as Spider Project that perform drag computation have begun to appear. But the information is also crucial for project personnel who don’t have such packages.
Em redes em cronogramas compostas exclusivamente de atividades com relação Término-Início (TI), o cálculo do “drag” é relativamente simples e, se necessário, pode ser calculado manualmente.
On network schedules with exclusively finish-to-start (FS) relationships, computing drag is fairly straightforward and, if necessary ought to be computed manually:
1. Para uma atividade no caminho crítico que não tem nada em paralelo, o seu arraso é a própria duração.
-
For a critical path activity that has nothing else in parallel, its drag is its duration.
2. Para uma atividade no caminho crítico que tem outras atividades em paralelo, o seu arrasto é o que for menor: sua duração ou a folga da atividade que tem a menor folga.
-
For a critical path activity that has other activities else in parallel, its drag is whichever is less: its duration OR the float of the parallel activity that has the least total float.
Figure 1. Computing Drag in a Network with All Finish-to-start (FS) Relationships Figura 1. Calculando o Arrasto emu ma Rede com todas as relações do tipo Término-Início
Na Figura 1: 1. As Atividades do Caminho Crítico A & I não tem nada em paralelo, então o seu arraso é igual as suas durações (A=10 e I = 5)
In Figure 1:
-
Critical path Activities A and I have nothing else in parallel, so their drags are equal to their durations, 10 and 5 respectively.
2. A duração da Atividade B é 20, mas o seu Arrasto é limitado pela folga de 10 das atividades paralelas C & F.
-
Activity B’s duration is 20, but its drag is constrained by the float of 10 of parallel Activities C and F.
3. A Atividade E teria um Arrasto de 9, restrito pela folga da Atividade D. Mas a Duração de E é somente 8, por isso este é o tempo que está adicionando ao Caminho Crítico e assim este é o seu Arrasto.
-
Activity E would have drag of 9, constrained by the float of Activity D. But Activity E’s duration is only 8, so that is all the time it is adding and that is its drag.
4. A Atividade H é paralela com as Atividades D, com folga de 9 e com a Atividade T, com folga 6. O menor valor, 6, é portanto o Arrasto de D.
-
Activity H is parallel with Activities D with float of 9 and Activity G with float of 6. The lower number, 6, is therefore D’s drag.
As relações de Término-Início normalmente são responsáveis por 70% ou mais das relações lógicas de uma rede. A maioria das outras serão o Início-Início, com ou sem “lag” (retardo). O Arrasto de uma Atividade do Caminho Crítico que tem uma ou mais sucessoras início-início também é relativamente fácil de ser calculada, da seguinte forma:
Finish-to-start relationships often account for 70% or more of the logic relationships in a network. The vast majority of others are start-to-start (SS) relationships, with or without lag. The drag of a critical path activity which has one or more start-to-start successors is also relatively easy to compute in the following manner:
5. Se não há outra atividade em paralelo, o arraso será aquele que for menor: sua duração ou a folga total e o “lag”(retardo) para cada uma das atividades sucessoras Início-Início.
-
If it has no other activities in parallel, its drag will be whichever is less: its duration OR the lowest total of float PLUS lag for each of the SS-successor activities.
6. Se tem outras atividades e caminhos completamente em paralelo, o seu Arrasto será o menor deles: o produto do cálculo no item 3 acima ou a folga da atividade paralela completa que tem a menor folga.
-
If it has other activities and paths completely in parallel, its drag will be whichever is less: the product of the calculation in 3 above OR the float of the completely parallel activity that has the least total float.
Figure 2. Computing Drag in a Network with Start-to-start (SS) Relationships Figura 2. Calculando o Arrasto em uma rede com Relações Início-Início
Na Figura 2 (Calculando o Drag em uma rede com relacionamentos Início-Início), sem a Atividade X na figura, o drag da Atividade B seria a menor soma da folga total e o retardo das três relações Início-Início+Retardo da Atividade B.
In Figure 2, without Activity X in the picture, the drag of Activity B would be the lowest sum of lag and total float of Activity B’s three SS + lag successors:
7. C com retardo de 7 e folga total de 5 = 12;
-
C with lag of 7 and total float of 5 = 12;
8. D com retardo de 5 e folga total de 3 = 8; e
-
D with lag of 5 and total float of 3 = 8; and
9. E com retardo de 3 e folga total de 7 = 10.
-
E with lag of 3 and total float of 7 = 10.
Com a duração de 20, o arrasto da Atividade B é a menor de todos estes: 8.
With a duration of 20, the drag of Activity B is the least of these: 8.
Se a Atividade X é parte da rede, então totalmente paralelo com a Atividade B e o arrasto de B seria limitado a 5 pela folga de X.
If Activity X is part of the network, then it is entirely parallel with Activity B and the drag of B would be limited to 5 by the float of X.
Como mencionado, os tipos de cálculo simplificados para o arrasto serão suficientes para calcular o arrasto em 90% a 100% das atividades do caminho crítico na maioria das redes. No entanto, mesmo que o software de alguém não calcule o arrasto do caminho crítico, o arrasto pode ser calculado para todas as relações de dependência, mesmo no caso dos raros casos de relações Término-Término (TT) e Início-Término (IT), com ou sem retardos, simplesmente pelo rearranjo destas relações no caminho crítico para uma situação de Término-Início como vistos na Figura 3.
As mentioned, these relatively simple type of computations will typically be sufficient to compute the drag of 90% – 100% of the critical path activities in most network schedules. However, even if one’s software does not compute critical path drag, drag can be computed for all dependency relationships, even the relatively rare finish-to-finish (FF) and start-to-finish (SF) relationships, with or without lags, simply by re-modeling such relationships on the critical path to all-FS relationships in the manner shown in Figure 3.
Com atividades do Caminho Crítico que tem tais sucessoras, a atividade predecessora precisa ser decomposta com a quantidade da folga de seu sucessor. Se a folga é zero, então um marco (duração zero) deveria ser criado para representar o início daquela predecessora. E se o fim de seu sucesso é restrito pelos predecessores, como em relacionamentos Término-Término (TT) ou Início-Término (IT), então um marco representando o fim do seu sucessor deve ser criado.
With critical path activities that have such successors, the predecessor activity should be decomposed at the amount of the lag to the successor. If the lag is zero, then a milestone (duration zero) should be created to represent the start of the predecessor. And if the finish of the successor is constrained by the predecessor, as in a finish-to-finish (FF) or start-to-finish (SF) relationship, then a milestone representing the finish of the successor should be created.
Figure 3. Decomposing Complex Dependencies with and without Lags to all-FS Relationships Figura 4. Decompondo Dependências Complexas com e sem Retardos para Término-Início
O arrasto do caminho crítico é o tempo pelo qual o item do caminho crítico está atrasando o término de um projeto. Este tempo é dinheiro, reduzindo o valor do investimento do projeto e também do produto, bem como ocasionando um aumento nos custos excedentes do projeto e os custos de oportunidade. O valor deste tempo deve ser estimado e combinado com a funcionalidade ampliada do arrasto na análise do caminho crítico, para justificar mudanças no cronograma que possam ampliar o valor final do projeto. Se uma atividade tem três semanas de arrasto e a redução do tempo total de um projeto aumentaria o seu valor em $60M, $40M e $ 20M respectivamente para cada semana anterior, então aquela atividade tem um custo de arrasto de $120M. Se ampliarmos os recursos de uma atividade em $30M poderia eliminar três semanas de arraso, então o resultado para o projeto seria de $90M mais em lucratividade quando comparado com o cronograma original. Esta técnica pode ser utilizada tanto para justificar o custo adicional de recursos como também para auxiliar o aumento da lucratividade de um projeto.
Critical path drag is the time by which a critical path item is delaying project completion. That time is money, reducing the value of the project investment by reducing the value of the final product as well as by causing an increase in the project’s overhead costs and opportunity costs. The value of that time must be estimated and combined with the drag-enhanced functionality of critical path analysis to permit justification of schedule changes that enhance the final value-above-cost of the project. If an activity has three weeks of drag, and reducing the project duration would increase its value by $60,000, $40,000 and $20,000 respectively for each week earlier, then that activity has drag cost of $120,000. If increasing the activity’s total resource costs by $30,000 would eliminate its three weeks of drag, the result would be a project that is $90,000 more profitable than with the original schedule. This is the technique that can be used both to justify the cost of additional resources and to make projects more profitable.
Esta análise é desenvolvida para calcular o arrasto das atividades em um projeto através do CPM (Método do Caminho Crítico). Mas também irá funcionar de forma equivalente para todos os itens — atividades, “sprints”, atrasos, retrabalhos, restrições (lógicas, de recurso e de calendário) que combinadas irão criar o caminho mais longo de um projeto. E isso é a razão pela qual a análise do caminho crítico, incluindo o cálculo do arrasto e do custo do arrasto, deveria ser utilizada em todos os projetos.
This analysis is designed to compute the drag of work activities in a project scheduled through CPM. But it will work equally well for all items — activities, sprints, stumbles, delays, rework and constraints (logical, resource, and calendar) that combine to create the longest path of any project, however scheduled. And that is why critical path analysis, including drag and drag cost computation, should be used on every project.
Encaminhe sua sugestão de melhorias para esta tradução
(ou dúvidas e sugestões a respeito do próprio conteúdo!)
blogmundopm@peter.smello.email