Aqui demonstramos 3 resultados fundamentais para compreender o conceito de “caminho crítico” e desmantelar a crença camponesa que os gestores de projeto têm no mesmo.
O caminho crítico é definido como sendo a sequência de atividades de um projeto na qual nenhum atraso em qualquer atividade pode ser absorvido por outra atividde começar (proporcionalmente) mais cedo.
Quando uma atividade pode começar ou acabar num dado intervalo de tempo, em vez de num momento impreterível, a essa folga chama-se “float”.
Logo, o caminho crítico é uma sequência que começa em alguns dos primeiros deliverables a serem produzidos num projeto, que acaba em alguns dos últimos deliverables a serem produzidos no projeto, e na qual nenhuma das atividades tem float, ou seja tem float zero (medido em unidade de tempo).
Proposição 1: um projeto não tem necessariamente um caminho crítico.
Para o provar basta definir uma sequencia de atividades que verifica a proposição, ou seja na qual ou nenhuma atividade tem float zero, ou quando é o caso isso não impacta o float do caminho sucessor mais curto de atividades definido pela precedências entre as mesmas.
Este segundo caso particular vai ficar clarificado adiante, pelo que para já basta descrever um projeto em que nenhuma das atividades tem float zero.
Dado que o início possível de atividades intermédias depende do mesmo atributo das atividades imediatamente precedentes (fixada que esteja a duração), o float neste cenário é determinado apenas pelas primeiras e pelas últimas atividades a serem executadas. Há uma exceção a isto, quando uma atividade está internamente contrangida de forma a ter float inferior ao da predecessora, mas nesse caso para efeito desta demonstração consideramos ambas as atividades como uma só.
Se as precedências são um conjunto linear de atividades, isto é, em que cada atividade depende de apenas uma outra atividade para ser iniciada, então o float é constante em qualquer atividade e igual ao destas últimas. Logo, se este for não nulo, nenhuma atividade terá float nulo e logo não há caminho crítico.
Portanto, um projeto não tem necessariamente que ter um caminho crítico.
Proposição 2: o facto de uma atividade ter float zero não significa que exista um caminho crítico.
Para o provar basta descrever o cenário em que uma atividade tem float zero mas isso não impacta os últimos deliverables do projeto.
Isto acontece quando essa atividade com float zero é predecessora de uma atividade que tem pelo menos uma outra predecessora, e esta última pode terminar mais tarde do que a atividade com float zero.
Como é evidente, em nada afeta este float zero porque a tarefa que depende desta tem sempre o float correspondente à diferença entre a data de fim da tarefa sem float e a da tarefa predecessora adicional.
Portanto, para haver um caminho crítico não é suficiente que existam tarefas sem margem para re-schedule.
Proposição 3: o caminho crítico só existe quando o float de uma atividade é zero e esta atividade i) ou está no único caminho de precedências até aos deliverables finais do projeto, ou ii) está num caminho de precedências que contribui sempre com o maior earliest finish quando faz o join com outros caminhos numa mesma atividade.
Aqui definimos “caminho” como uma sequência de atividades com apenas 1 predecessor, caso em que faz todo o sentido falar de float de um caminho e não apenas de uma atividade.
O caso i) é um caso particular do cenário ilustrado na proposição 1, em que as primeiras e as últimas atividades no caminho de precedências não têm float.
O caso ii) é o mais expectável que ocorra em iniciativas que não são triviais e por isso é o mais representativo. Aqui, basta saber que o float de uma atividade que tem pelos menos duas predecessoras nunca pode ser superior ao float de qualquer destas, mas aqui apenas contribuem as predecessoras com o maior earliest finish pela mesma razão que referido na demonstração anterior. Ou seja, um caminho de precedências com float zero mas que não contribua com o maior earliest finish num join de precedências não resulta em float zero no caminho sucessor e logo não faz parte do caminho crítico do projeto.
QED
Tudo isto está provado ser verdadeiro, no entanto assume-se como pressuposto um cenário idealizado que raramente se verifica na vida real. Em particular, não é tido em conta que as dependências entre atividades podem alterar-se ao longo da excução do projeto, o que é frequente e normal acontecer, nem que podem surgir opotunidades a explorar com benefício para o projeto, muitas delas contra-intuitivas mas altamente eficazes se corretamente endereçadas conforme detalhado no excelente livro “The Principles of Product Development Flow” de Donald Reinertsen.
Logo, ou as circunstâncias reais do projeto não podem ser geridas porque não podem ser antecipadas, ou podem ser exploradas quando ocorrem em benefício do projeto.
Fica assim demonstrado que a maiorida dos gestores de projeto que falam de caminhos críticos não fazem a mínima ideia do que é que estão a falar.
Isto por sua vez reforça a tese da inutilidade deste job role para as organizações. Pior do que inutilidade, a natureza daninha da mesma.
