4ª Conferência da

Associação Portuguesa de Sistemas de Informação

Gestão da Cadeia Crítica: Uma Nova Abordagem à Gestão de Projectos de

Software

António Soares Gomes Miguel

Universidade Moderna, Lisboa, Portugal
antonio.miguel@umoderna.pt
 Gestão da Cadeia Crítica: Uma Nova Abordagem à Gestão de
Projectos de Software

Resumo
Este artigo centra-se na mais recente mudança de paradigma da gestão de projectos que
está interessar a comunidade científica e de profissionais de gestão de projectos: a Gestão
da Cadeia Crítica.
Trata-se de uma filosofia de gestão e melhoria baseada na Teoria das Restrições e no
Pensamento Sistémico que trata, numa disciplina unificada, a componente algorítmica e a
componente humana da gestão de projectos.
A Teoria das Restrições é uma filosofia de gestão e melhoria baseada no facto de que,
assim como uma cadeia tem o seu elo fraco, em qualquer sistema complexo em qualquer
ponto no tempo existe quase sempre um aspecto desse sistema que limita a sua capacidade
em atingir o seu objectivo da forma mais eficaz. Para que esse sistema alcance uma
melhoria significativa, essa restrição deve ser identificada e o sistema global deve ser
gerido tendo isso em mente.
A Gestão da Cadeia Crítica de Projectos permite concluir projectos em tempos
significativamente mais curtos que com a gestão tradicional baseada no Caminho Crítico.
Igualmente importante, a gestão da Cadeia Crítica é de uso mais simples e requer menos
trabalho à equipa de projecto, quer na fase de planeamento quer na fase de monitorização.
Nesta comunicação são apresentados e exemplificados os pressupostos desta abordagem
inovadora e suas diferenças em relação à gestão do Cadeia Crítico.

Palavras chave: cadeia crítica, caminho crítico, buffers de tempo, teoria das restrições

1. Introdução

É um facto incontroverso que a forma como gerimos a incerteza nos projecto é fundamental
para a melhoria do desempenho do projecto, definindo-se esta melhoria como a realização dos
projectos mais rapidamente (que a data final exigida) e com melhor qualidade. A Gestão da
Cadeia Crítica de Projectos1 (GCCP) está chamar a atenção da comunidade científica e dos
profissionais de gestão de projectos. O PMBOK 2000 já incorpora uma referência a este novo
paradigma [PMI Standards Committee 2000]. Esta metodologia baseia-se no paradigma do
Pensamento Sistémico2 e na Teoria das Restrições3.
A Teoria das Restrições é uma filosofia de gestão e melhoria desenvolvida inicialmente por
Eliyahu M. Goldrat nos seu livros The Goal [Goldrat 1984] e Critical Chain [Goldrat 1998] ,
que se baseia no facto de que, à semelhança de uma cadeia com o seu elo mais fraco, em
qualquer sistema complexo em qualquer ponto no tempo existe, quase sempre apenas um
aspecto desse sistema que restringe a sua capacidade de melhorar a consecução do seu
objectivo. Para que esse sistema alcance qualquer melhoria significativa, é necessário identificar
essa restrição e gerir o sistema total tendo-a em linha de conta.

1
Critical Chain Project Management (CCPM).
2
Systems Thinking.
3
Theory of Constraints (TOC).

1
A obra Project Management in the Fast Lane [Newbold 1998] detalha a metodologia que se
tornou conhecida como GCCP e fornece linhas de orientação e sugestões para implementação
daa novas ideias em projectos. O processo de planeamento e controlo de projectos da GCCP
trata directamente a incerteza e variabilidade na duração das actividades do projecto, ajudando a
eliminar comportamentos nocivos alimentados pelo uso de datas calendarizadas e marcos
(milestones) no interior de um plano de projecto. A GCCP concentra-se na gestão do
desempenho do projecto com o objectivo de reduzir as durações das actividades reduzindo,
deste modo, a duração global do projecto.

2. Os Projectos de Software

Os profissionais de TI lutam diariamente para manter os projectos nos prazos e custos e para
satisfazer os compromissos estabelecidos com os clientes. Os chefes de projecto lutam por
recursos, os gestores de recursos lutam com necessidades conflitantes e os membros das equipas
de projecto saltam de fogo em fogo na tentativa de vencer a última crise. Apesar dos enormes
esforços para satisfazer as necessidades em competição, as estatísticas dizem-nos que o sucesso
é a excepção, não a regra.
As seguintes estatísticas, compiladas pelo Standish Group [Standish Group 1996] e confirmadas
pela ACM-Association for Computing Machinery [Neuman 2000] reflectem a nossa capacidade
em realizar projectos com sucesso:
ƒ 30% dos projectos são cancelados antes de concluídos.
ƒ 75% dos projectos concluídos ultrapassam os prazos.
ƒ Os custos são, em média, 189% superiores ao planeado.
ƒ As derrapagens dos prazos são, em média, de 222%.
Embora estas estatísticas tenham alguns anos, não existem indicações de que as coisas estejam
substancialmente melhor [Norman 2002] [Weinstein 2002]. Assim, porque é que existem tantas
dificuldades na conclusão dos projectos de software. Muitas das causas apontadas na literatura
sugerem que as características únicas dos projectos de software têm muito a ver com a nossa
incapacidade em gerir resultados com sucesso [Ewusi-Mensah 1997] [Higuera et al. 1994]
[Yourden 1999]. Salientam-se as seguintes características chave que distinguem os projectos de
software:
ƒ Requisitos pouco claros e mutáveis.
ƒ Tarefas pobremente definidas.
ƒ Dependências complexas.
ƒ Dependência de recursos chave escassos.
ƒ Culturas reactivas.
Embora todos os projectos sofram, em certa medida, com estes problemas, os projectos de
software são especialmente afectados. Se é difícil lidar cada um destes problemas, por si,
quando eles se combinam o projecto pode transformar-se num pesadelo. O resultado é um
ambiente de trabalho caótico em que as prioridades são simultaneamente obscuras e instáveis,
originando um regime multitarefa, o qual, embora pouco reconhecido, constitui um problema
crónico em organizações de gestão de projectos [Leach 2000].

2
3. O Lado Humano da Gestão de Projectos

Os projectos são planeados e executados por pessoas, não por programas de computador. A
metodologia da Cadeia Crítica baseia-se num conhecimento da natureza humana e no que
acontece quando uma disciplina de gestão de projectos é aplicada a pessoas. Goldratt diz que, se
não formos cuidadosos, muitas vezes obtemos o oposto daquilo que pretendemos. Vamos olhar
para algumas dessas consequências inesperadas
3.1. Elaboração das Estimativas
Quando nos pedem para estimar uma tarefa, pensamos acerca da tarefa e do esforço e decidimos
que a podemos realizar, por exemplo, em 5 dias. Em seguida, pensamos um pouco mais:
ƒ Talvez haja algo desconhecido nesta tarefa.
ƒ É muito possível que hajam interrupções não planeadas ao trabalho.
ƒ Finalmente, queremos assegurar-nos que não nos atrasamos na nossa estimativa, porque
não queremos atenção negativa sobre nós.
Baseados em todas estas incertezas, anunciamos que podemos realizar a tarefa em 10 dias.
Como é mostrado na Figura 1, escondemos 5 dias de segurança na nossa estimativa de 10 dias.
Dizemos que a segurança está escondida, porque a tarefa é registada no projecto como durando
10 dias – os 5 dias de segurança são o nosso factor de contingência pessoal.

Segurança Escondida

Figura 1 – Segurança escondida

Não é errado estabelecer um factor de segurança na estimativa de uma tarefa; é perfeitamente

razoável considerar os factores envolvidos e o ambiente de gestão do projecto em que
trabalhamos. No fim de contas, não queremos ser um dos que falham uma data comprometida
para uma tarefa!
Dado um projecto que é composto por tarefas com segurança escondida, vamos olhar para o que
acontece quando a tarefa é realmente executada.
3.2. Síndroma do Estudante
No seu livro Critical Chain, Goldratt conta a história do que acontece quando um professor dá
um trabalho à turma, o qual tem de ser entregue no prazo de duas semanas. Os estudantes
queixam-se que o prazo é apertado e exigem mais tempo. O professor concorda e dá-lhes tempo
adicional. Mais tarde, quando os estudantes reflectem sobre o modo como realmente realizaram
o trabalho com o tempo adicional, notam que todos pensaram que tinham muito tempo, com
segurança, para realizar o trabalho, de modo que só o iniciaram no último minuto.
Vamos ver como a síndroma do estudante pode afectar a nossa tarefa e o projecto inteiro.
Em virtude da síndroma do estudante, só começamos realmente a trabalhar no 5º dia da tarefa,
como é mostrado pelo 1º marco da Figura 2 (▲). Este começo deve estar bem, porque temos
uma segurança adequada na nossa estimativa. Infelizmente, na Quinta Feira assinalada pelo 2º
marco encontramos um problema inesperado no trabalho. De repente, tomamos consciência de
que a nossa segurança se esgotou e que vamos ultrapassar a estimativa, independentemente do
tempo que dediquemos ao trabalho. Gastamos os próximos cinco dias a trabalhar o mais rápido
que conseguimos com uma derrapagem de 30% sobre a nossa estimativa original.

3
Este exemplo simples não é invulgar. Acontece vezes sem conta durante os projectos. Somos
todos humanos e quando estabelecemos um prazo para uma tarefa com uma margem de
segurança escondida, a maioria de nós cai na armadilha da síndroma do estudante.

1 2

Figura 2 – Síndroma do estudante

3.3. Lei de Parkinson

O trabalho expande-se de modo a preencher o tempo atribuído [Parkinson 1958].
A maioria de nós já ouviu falar da Lei de Parkinson e já a viu em acção nos projectos. Se uma
tarefa é estimada durar 10 dias, regra geral não demora menos. Este ajustamento do esforço para
preencher o tempo atribuído pode acontecer de várias formas. Os projectos de software exibem
frequentemente a tendência para um aumento da “elegância” quando os elementos da equipa
sentem que têm mais tempo que o realmente necessário para executar a tarefa. Noutros casos, as
pessoas simplesmente ajustam o nível do esforço de modo a manterem-se ocupados durante o
período estimado da tarefa.
A gestão de projectos tradicional enfatiza a necessidade de não haver atrasos, mas não promove
a antecipação dos prazos. Este ambiente encoraja a segurança escondida, a síndroma do
estudante e os efeitos da lei de Parkinson.
3.4. Regime Multitarefa
Os chefes de projecto são responsáveis perante um cliente – interno ou externo à organização –
pelo sucesso do projecto. Os clientes têm a tendência para serem exigentes, pensando que o seu
projecto tem a mais elevada prioridade e querendo ver frequentes relatórios de progresso. Os
recursos tendem a migrar entre projectos, em resposta à última e mais sonora exigência de um
cliente, numa tentativa de manter o maior número possível de clientes satisfeitos. Este enfoque
em mostrar progresso em tantos projectos activos quanto possível é a principal causa da
execução de múltiplas tarefas e provoca a diminuição do desempenho global dos projectos da
organização.
Consideremos os efeitos perniciosos de realizar múltiplas tarefas, num exemplo simples
multiprojecto. Assumamos que temos quatro projectos, A, B, C e D, e que cada um é estimado
demorar quatro semanas a completar. O nosso ambiente de projecto é de caos organizado. Os
recursos migram de um projecto para o próximo, de modo a mostrar o maior progresso
simultâneo possível aos clientes dos projectos. Para manter este exemplo simples, assumamos
que os recursos trabalham uma semana em cada projecto e depois migram para o projecto
seguinte.

Task Name Jan Feb Mar Apr

f Project A
f Project B

f Project C

f Project D

Figura 3 – Execução intermitente de vários projectos

4
Neste ambiente, os projectos são executados em períodos intermitentes, como é mostrado na
Figura 3. A data de conclusão de cada projecto é evidenciada por um marco. Note-se que este
exemplo assume uma perda de eficiência nula devido à mudança entre tarefas, minimizando
assim os efeitos perniciosos da execução de tarefas múltiplas no mundo real.
Os incentivos à multitarefa têm diversas origens. Primeiro, os gestores não conhecem as
verdadeiras prioridades, as quais dependem de dois factores:
1) Se a tarefa está no caminho crítico, e
2) Quanta folga e/ou segurança (protecção contra a incerteza) foi usada e quanta ainda
existe em todos os caminhos.
As ferramentas de planeamento e controlo correntemente usadas não se ajustam bem ao
fornecimento dos dois tipos de informação. O caminho crítico raramente é conhecido dos
gestores de recursos e, para além disso, a folga remanescente em caminhos não-críticos não é
monitorada. Finalmente, a segurança que é escondida nos tempos das tarefas não é visível para
os gestores (e é utilizada se os membros da equipa são encorajados a cumprir os prazos, em vez
de passarem as tarefas logo que as tenham concluído). Deste modo, os gestores não sabem
quanta protecção ainda resta, ou quais são as tarefas que influenciam decisivamente a conclusão
do projecto.
O resultado é que as prioridades são estabelecidas de acordo com a intuição dos gestores ou, o
que é mais frequente, não são de todo estabelecidas [Leach 2000]. Quando as prioridades não
são claras para a equipa de projecto, os seus membros preenchem o vazio com regras de decisão
próprias: qual a tarefa que prefiro executar, qual aparenta ser mais importante (isto é, quem grita
mais alto), qual é mais difícil/fácil, etc.
De acordo com Leach [Leach 2000], o regime multitarefa provoca:
1) um aumento significativo do tempo necessário para concluir uma tarefa e
2) uma diminuição significativa da produtividade das equipas.
O primeiro efeito provoca o aumento da duração dos projectos. Embora esteja a ser realizado o
mesmo volume de trabalho, esse trabalho cobre um tempo de calendário muito superior. Esta é o
principal motivo porque temos projectos que demoram 12 meses, mas em que a nossa intuição
nos diz que não deveriam ter demorado mais do que metade desse tempo.
O segundo efeito, a quebra de produtividade, é o resultado do tempo necessário para o arranque
de tarefas extra. Um arranque refere-se ao tempo necessário para organizar e guardar a tarefa em
que se está a trabalhar actualmente, e preparar a tarefa em que se vai trabalhar a seguir. Trata-se
de um problema especialmente significativo quando estamos a lidar com tarefas criativas (em
oposição a produtivas), como é o caso do ambiente de desenvolvimento de software [Miguel
2003]. Quando um técnico pára a meio de uma tarefa criativa, ele necessita de algum tempo para
organizar e guardar aquilo que está a fazer, de modo a saber onde começar quando voltar a
ocupar-se novamente da tarefa. Quando inicia a nova tarefa, o arranque envolve a análise do
trabalho-em-curso, a recordação daquilo em que estava a pensar quando trabalhou na tarefa da
última vez, a direcção que estava a seguir, etc. O tempo necessário para abandonar uma tarefa e
iniciar outra é significativo e completamente desperdiçado, quando acumulado ao longo de uma
organização afectada de forma crónica pela multitarefa.
Para que haja alguma esperança de eliminar o regime multitarefa que tanto contribui para os
problemas de desempenho dos projectos, é necessário que os projectos de software passem a
estabelecer prioridades claras e estáveis. Isto tem sido sempre o âmbito do mundo do
planeamento e calendarização – ao fim e ao cabo, o objectivo do calendário é dizer aquilo que é
mais importante fazer em qualquer momento.

5
Assumamos agora que, na situação dos projectos mostrados na Figura 3, nos organizámos de
acordo com o objectivo simples de realizar o trabalho com base nos projectos considerados mais
importantes para a nossa organização. É uma mudança importante – estamos a mover-nos de um
caos organizado baseado em decisões sub-optimizadas de nível micro para uma organização
optimizada baseada em decisões de nível macro.
Para o nosso exemplo, vamos assumir que a prioridade dos projectos é, da mais elevada para a
mais baixa, A, B, C e D. Ao eliminar a multitarefa e executar os projectos de acordo com a
prioridade, obtemos os resultados ilustrados na Figura 4.

Task Name Jan Feb Mar Apr

f Project A
f Project B

f Project C

f Project D

Figura 4 - Execução dos projectos de acordo com as respectivas prioridades

Repare-se como o projecto de menor prioridade, D, ainda é concluído na mesma data que no
exemplo de multitarefa. No entanto, olhemos para o projecto de prioridade mais elevada, A.
Este projecto é concluído nove semanas mais cedo – isto representa 225% de melhoria. Os
projectos B e C são igualmente concluídos em muito menos tempo que no ambiente multitarefa.
A mensagem é clara – se eliminarmos o ambiente multitarefa e efectuarmos decisões de
atribuição de recursos baseadas na prioridade dos projectos, obtemos um melhor desempenho
nos nossos projectos.
A eliminação do ambiente multitarefa também se aplica a um projecto individual. Os clientes
exigentes podem ser gestores de pacotes de trabalho que exigem progresso de recursos
limitados. Se forem atribuídos recursos para calar esses gestores, o projecto pode sofrer atrasos
desnecessários na medida em que as tarefas são realizadas numa sequência sub-óptima.
Veremos adiante como o método da Cadeia Crítica nos fornece uma forma simples de eliminar
este ambiente multitarefa entre projectos, com regras claras e concisas sobre qual o trabalho a
realizar primeiro.
3.5. Ausência de Antecipações
Regra geral, as tarefas parecem acabar a tempo, ou atrasadas, mas raramente mais cedo. Embora
já se tenha referido como a síndroma do estudante e a lei de Parkinson podem contribuir para
este resultado vulgar, existe um outro factor a assinalar. Os nossos métodos de gestão de
projectos, que incluem recompensas e punições, raramente recompensam antecipações nos
prazos. Na realidade, muitas vezes punem antecipações. Porque é que se procede assim?
Se concluirmos uma tarefa mais cedo que o planeado, podemos ser acusados de ter empolado as
estimativas ao invés de recompensados pela conclusão antecipada. Neste ambiente,
preocupamo-nos com a possibilidade de as nossas estimativas futuras serem cortadas com base
no historial, de modo que gozamos a calma que a nossa conclusão antecipada nos proporciona e
acabamos oficialmente na data aprazada. Neste caso provavelmente obteremos aprovação pela
boa estimativa, embora saibamos que podíamos ter acabado mais cedo.
Se acabarmos mais cedo e anunciarmos os resultados, então iremos defrontar-nos com o
próximo problema. A tarefa que está dependente da nossa conclusão poderá não conseguir
começar mais cedo em virtude dos recursos necessários estarem indisponíveis a fazer qualquer
outra coisa. É bom recordar que o calendário do projecto deu uma data de início clara para a
tarefa seguinte e, com base nesse calendário, os recursos foram atribuídos a outro trabalho.

6
Quando integramos a síndroma do estudante com a lei de Parkinson e com a probabilidade de
não haver antecipações, obtemos o seguinte resultado. Os métodos tradicionais de gestão de
projectos atenuam os efeitos de antecipações e apenas propagam os atrasos no calendário. Por
outras palavras, o melhor que podem fazer é acabar na data estimada, e a probabilidade de tal
acontecer é muito reduzida.
Os métodos de gestão de projectos tradicionais usam normalmente factores de segurança das
tarefas da ordem de 3 a 4. A maioria deste tempo de segurança tende a ser desperdiçado.
A Figura 5 mostra os tipos de estimativas que se praticam vulgarmente na calendarização
tradicional de projectos. Os métodos tradicionais de gestão de projectos ajudam a converter uma
tarefa “just-in-time” de 2 semanas numa tarefa “just-in-case” de 7 semanas.
Para obter um resultado diferente, para ter uma entrega mais rápida ao mercado, necessitamos
uma diferente abordagem. É isso que a abordagem da Cadeia Crítica oferece. Vamos ver como é
que o Método da Cadeia Crítica possibilita um desempenho mais elevado.

50% de probabilidades de que a tarefa 90% de probabilidades de que a tarefa

demore 2 semanas, ou menos, a ser
concluída.
Pessoas pouco experientes ou com
optimismo pouco realista tendem a
estimar a duração da tarefa desta
forma.
2 Semanas
4 Semanas
demore 4 semanas, ou menos, a ser
Distribuição de Probabilidade concluída.
da Duração da Tarefa A distribuição está normalmente
inclinada para a direita em virtude de
existir um limite tecnológico para a
rapidez com que as coisas podem ser
feitas e nenhum limite para o tempo
que podem durar (algumas podem
90% + nunca ser concluídas).
50%
A pessoa que estima e cada nível da
gestão adicionam reservas para
prevenir incertezas, erros potenciais e a
Lei de Murphy.
Usa-se frequentemente a estimativa do
90% de probabilidade, quando os
recursos estão dedicados em exclusivo
a uma única tarefa.

7 Semanas
Quando não se podem atribuir recursos
dedicados exclusivamente a tarefas
individuais, adiciona-se uma reserva
extra para prevenir tempos de espera,
multitarefa, atrasos ou avanços dos
prazos, etc.

Figura 5 – Calendarização tradicional de projectos

4. O Método da Cadeia Crítica

A formula para o sucesso deve incluir os dois seguintes ingredientes [Leach 2000] [Newbold
1998]:
1) Melhor Planeamento: aumentar o tempo dedicado à especificação dos requisitos, ao
estabelecimento objectivos claros, ao planeamento de estratégias de redução dos riscos,
à criação de redes de projectos realistas e à obtenção de calendários fiáveis.
2) Melhor Monitorização: transformar o ambiente de trabalho num local em que as
prioridades são claras e relativamente estáveis. Minimizar a frequência de disrupção das
prioridades.

7
Vamos analisar a forma como a Gestão da Cadeia Crítica do Projecto se aplica às duas fases
conhecidas de qualquer chefe de projecto – planeamento e monitorização. A calendarização da
Cadeia Crítica opera de forma diferente nestas duas fases.
4.1. Calendarização da Frente para Trás
Ao invés do processo de gestão pelo Caminho Crítico, no modo de planeamento da Cadeia
Crítica desenvolve-se o plano do fim para o princípio, a partir de uma data de conclusão alvo
para o nosso projecto. Este enfoque na data de conclusão é natural. Quando nos é atribuído um
novo projecto, regra geral é-nos dito quando são necessários os resultados, ao invés da data de
início do projecto. É dever do chefe de projecto determinar quando tem de iniciar o trabalho
para satisfazer a data de conclusão.
Vamos falar um pouco sobre planeamento da-frente-para-trás. Isto significa que, à medida que
definimos o projecto com tarefas, durações e dependências, o software de planeamento
calendariza as tarefas para trás no tempo partindo da data de conclusão por nós definida.
Quando o plano estiver concluído, a data de início calculada para o projecto indica-nos a data
mais tarde em que podemos começar e que ainda permitirá satisfazer a data de conclusão alvo.
4.2. Calendarizar Tão-Tarde-Quanto-Possível
No planeamento tradicional do Caminho Crítico, as tarefas são calendarizadas tão-cedo-quanto-
possível (Data de Início Mais Cedo) a partir da data de início do projecto. Esta forma de
calendarização coloca o trabalho tão perto quanto possível do início do calendário. No
planeamento da Cadeia Crítica, as tarefas são calendarizadas tão-tarde-quanto-possível (Data de
Início Mais Tarde) a partir da data de conclusão alvo. Esta forma de calendarização coloca o
trabalho tão perto quanto possível do final do calendário.
O único inconveniente desta abordagem respeita à calendarização de todo o trabalho para tão-
tarde-quanto-possível. Na terminologia tradicional do Caminho Crítico, isto significa que todas
as tarefas são críticas quando estamos em modo de monitorização. Um aumento na duração de
qualquer tarefa atrasará a data de conclusão do projecto no mesmo valor do aumento da tarefa.
Felizmente, Goldratt apresenta uma solução elegante e simples para este problema [Goldrat
1998]. No planeamento da Cadeia Crítica, como iremos ver adiante, inserimos buffers em
pontos chave do plano do projecto, os quais irão funcionar como amortecedores para proteger a
data de conclusão do projecto contra aumentos na duração das tarefas. Com o método do buffer,
obtemos os benefícios da calendarização tão-tarde-quanto-possível com a adequada protecção
contra a incerteza.
4.3. O Processo de Estimação
Para ser eficaz, o processo de estimar tarefas no método da Cadeia Crítica exige uma alteração
no comportamento individual e organizacional. Como queremos remover a segurança escondida
na duração das tarefas, e porque essa segurança está oculta, temos de estabelecer uma cultura
organizacional que remova o receio de expor esta segurança e de a remover das estimativas das
tarefas.
Primeiro, temos de fazer compreender a toda a gente que não estamos a remover a segurança e a
lançá-la fora. Em vez disso, como veremos adiante, estamos a colocar esta segurança removida
como um recurso de todo o projecto, em oposição a um recurso escondido ao nível de cada
tarefa.
Seguidamente, temos de fazer com que os gestores e a equipa de projecto aceitem a incerteza, ao
invés de pensarem que a podem derrotar com melhores técnicas de estimação. Quando
removemos a segurança de uma tarefa, devemos aceitar que essa tarefa tem uma boa
probabilidade – digamos 50% – de exceder a estimativa. Isso não é mau; é normal. Não
podemos ter um ambiente em que as durações reais das tarefas são comparadas com estimativas
base e relatadas e tratadas como problemas. Se o fizermos, então a equipa irá ajustar o seu

8
comportamento às medidas e, nas próximas estimativas, irá colocar grandes quantidades de
segurança profundamente escondida, derrotando, deste modo, o método.
Após a obtenção de um acordo, por todos os envolvidos, para a aceitação do novo paradigma da
Cadeia Crítica, chegamos finalmente ao “como” da estimação. Existem duas abordagens básicas
– a primeira envolve o desenvolvimento de uma única duração estimada para cada tarefa; a
segunda requer o desenvolvimento de duas estimativas da duração para cada tarefa. A maioria
dos produtos de software de planeamento baseados no método da Cadeia Crítica suporta ambas
as abordagens; no entanto, o método da duração única é o que Goldratt propôs originalmente
[Goldrat 1998]. Iremos usá-lo aqui, porque é simples e eficaz.
O objectivo é obter uma estimativa da tarefa que tenha uma probabilidade de 50% de ser
satisfeita. Isto significa que existe igualmente uma probabilidade de 50% de a tarefa demorar
mais que a estimativa. E existe, evidentemente, alguma possibilidade de a tarefa ser concluída
num prazo mais curto que a estimativa. Agora, quando se trata de estimar uma tarefa, a maioria
das pessoas tem dificuldade em pensar em termos de probabilidade do resultado. Em vez de
pedir uma estimativa com 50% de probabilidade, devemos pedir à equipa que forneça
estimativas baseadas nos seguintes pressupostos positivos:
ƒ Ao calcular uma estimativa, devemos assumir que está disponível todo o material e
informação de que necessitamos.
ƒ Devemos assumir que somos capazes de nos concentrar na tarefa sem quaisquer
interrupções.
ƒ Finalmente, e de sobremaneira importante, devemos assumir que não existirão surpresas
que ocasionem trabalho adicional.
Se usarmos estes pressupostos, estaremos numa boa posição para derivar uma estimativa com
50% de probabilidade, sem nos preocuparmos com probabilidades.
4.4. Identificação da Cadeia Crítica
Goldratt define a Cadeia Crítica como sendo a mais longa cadeia de tarefas que considera as
dependências das tarefas e as dependências dos recursos. Isto é diferente da definição do
caminho crítico, o qual é definido como a mais longa cadeia de tarefas baseada nas
dependências entre estas. É uma diferença subtil, mas importante. A Cadeia Crítica reconhece
que um atraso na disponibilidade de um recurso pode atrasar um plano, do mesmo modo que um
atraso em tarefas interdependentes. Os produtos de software disponíveis no mercado fornecem
uma função destinada a encontrar o Caminho Crítico com base em ambas as dependências – de
tarefas e de recursos. A Figura 6 mostra um exemplo de Cadeia Crítica claramente evidenciada
pela cor vermelha das tarefas4.

Figura 6 – Exemplo de cadeia crítica

4.5. Inserção de Buffers

4
Programa de gestão da cadeia crítica Scitor PS8.

9
A técnica de estimação usada removeu de forma eficaz a segurança das nossas tarefas. Vamos
agora constituir uma reserva desta segurança e colocá-la em buffers de absorção de choques em
pontos chave do nosso projecto. Estes buffers contraem-se automaticamente quando são
empurrados por tarefas que se atrasam e absorvem os atrasos sem afectar a Data de Conclusão
Alvo. Quando inserimos os buffers, necessitamos determinar a respectiva dimensão. Vamos
começar com o buffer mais simples – o do projecto.
O Buffer do Projecto protege a data de conclusão alvo contra atrasos nas tarefas da Cadeia
Crítica e é colocado no final do projecto, a seguir à última tarefa da Cadeia Crítica. Assim,
iremos dimensionar o buffer em 50% da dimensão das tarefas da Cadeia Crítica. Na realidade,
reduzimos a segurança total que ficaria escondida nas tarefas individuais da Cadeia Crítica e
colocámos no Buffer do Projecto esse valor reduzido. Esta redução na segurança total é baseada
na mesma teoria do fundo de risco usado no negócio de seguros.
No entanto, a Cadeia Crítica está exposta a atrasos em tarefas não críticas que se ligam a ela. No
exemplo mostrado na Figura 6, como a tarefa Document foi calendarizada como tão-tarde-
quanto-possível, qualquer aumento na sua duração durante a monitorização irá afectar a Cadeia
Crítica e o Buffer do Projecto. Goldratt protege a Cadeia Crítica contra atrasos destas cadeias de
alimentação através da inserção de um Buffer de Alimentação no ponto em que a cadeia de
alimentação se cruza com a Cadeia Crítica. Assim, dimensionar-se-á o Buffer de Alimentação
em 50% da duração da cadeia de alimentação [Goldrat 1998] [Leach 2000].
Os produtos de software de gestão da Cadeia Crítica existentes no mercado possuem uma
função de Inserir Buffer, a qual insere automaticamente os buffers e resolve qualquer conflito de
recursos causado pela inserção. Note-se na Figura 7 o Buffer de Alimentação e o Buffer do
Projecto (ambos a azul claro) que foram inseridos no calendário do projecto. Estes buffers
protegem a nossa Data de Conclusão Alvo de eventuais aumentos nas durações das tarefas.
Repare-se que o projecto de Cadeia Crítica, conforme planeado com buffers, é 25% mais curto
que o projecto equivalente de Caminho Crítico.

Figura 7 – Buffers adicionados ao projecto

4.6. Gestão dos Buffers

Na gestão de projectos pelo método da Cadeia Crítica, a chave da monitorização do desempenho
do projecto está na gestão dos buffers. Mais uma vez, como reconhecemos que as estimativas
são inerentemente incertas, não tentamos aplicar às tarefas técnicas de medição exactas como a
análise de variância e o valor ganho. Em vez disso, observamos os nossos buffers e agimos de
acordo com a profundidade da penetração no buffer devida a alterações no calendário das
tarefas.
Devemos tratar o buffer como se ele estivesse dividido em três regiões de igual dimensão – o
primeiro terço é a zona verde, o segundo terço a zona amarela e o terço final a zona a vermelho
(ver Figura 8).

10
 Figura 8 – Regiões dos buffers

Se a penetração estiver na zona a verde, não é necessário tomar nenhuma acção. Se a penetração
entrar na zona amarela, então é necessário avaliar o problema e pensar em possíveis acções de
contingência. Se a penetração entrar na zona a vermelho, então devemos agir imediatamente. Os
planos de acção devem incluir formas de terminar mais cedo tarefas não concluídas na cadeia ou
de acelerar o trabalho futuro na cadeia, de modo a fazer recuar a penetração da zona a vermelho.
4.7. Antecipar a Conclusão
Ao utilizar o método de gestão de projectos pela Cadeia Crítica, o nosso objectivo deve ser, não
apenas concluir o projecto no prazo estabelecido, mas concluí-lo mais cedo que o estabelecido,
como mostrado na Figura 9. De acordo com a figura, os buffers absorveram um aumento de
50% na duração das tarefas Develop 1 e Document, e como mesmo assim o projecto terminou
mais cedo com dois terços do buffer do projecto por gastar.

Figura 9 – Conclusão antecipada do projecto

5. Conclusões

É essencial manter o enfoque na necessidade de ter prioridades claras e estáveis. A Gestão da

Cadeia Crítica do Projecto pode ser encarada como um conjunto de ajustamentos nas técnicas de
planeamento e controlo de redes normalmente utilizadas. As prioridades são fundamentadas
numa visão sistémica global do projecto, atribuindo-se a mais elevada prioridade às tarefas que
influenciam directamente o tempo de conclusão do projecto. As componentes da GCCP são:
ƒ Uma rede nivelada pelos recursos, composta por todas as tarefas do projecto e
respectivas estimativas de duração “mais prováveis” (isto é, sem segurança adicionada).
ƒ Uma cadeia crítica claramente identificada. A cadeia crítica é o caminho crítico nivelado
pelos recursos que reflecte as dependências de tarefas e recursos que determinam a
duração do projecto.
ƒ Buffers de tempo inseridos no calendário do projecto, destinados a proteger a data de
conclusão dos efeitos de disrupções. Os buffers determinam momentos de início de
caminhos baseados no risco das tarefas que compõem o caminho.
ƒ Um mecanismo de feedback (gestão dos buffers) que mantém toda a gente informada
acerca do volume de protecção que permanece no calendário do projecto.
ƒ Uma ênfase na redução/eliminação do regime multitarefa através do estabelecimento de
prioridades claras e estáveis produzidas pelos anteriores ingredientes.

11
O resultado são prioridades claras e estáveis. As tarefas do caminho crítico possuem sempre a
mais alta prioridade. As restantes tarefas são tratadas numa base first-come-first-served (FCFS).
Como os tempos de início de caminhos são estabelecidos com base no risco, esta forma de
tratamento traduz-se em tomar tarefas na verdadeira ordem de prioridade na ausência de
disrupções. Como as disrupções são inevitáveis, o respectivo impacto é monitorado mediante a
observação da situação dos buffers. Enquanto o remanescente do buffer for aceitável (critério
estabelecido pela gestão do projecto), as prioridades não serão alteradas. Quando os buffers
atingem limiares pré-determinados, são alteradas as prioridades dos poucos recursos
seleccionados que melhor podem recuperar o tempo do buffer. Após esta intervenção, as
prioridades regressam à definição inicial – 1) Caminho Crítico, 2) FCFS para todas as outras
tarefas.

6. Referências

Ewusi-Mensah, K., “Critical Issues in Abandoned Information Systems Development Projects”,

Communications of the ACM, Nr. 40, Vol. 9 (September 1997), pp. 74-80.
Goldratt, E.. Critical Chain. New York: North River Press, Croton-on-Hudson, 1998.
Goldratt, E.. The Haystack Syndrome. New York: North River Press, Croton-on-Hudson, 1990.
Goldratt, E..The Goal. New York: North River Press, Croton-on-Hudson, 1984.
Higuera, R., Gluch, D., Dorofee, A., Murphy, R., Walker, J., Williams, R., An Introduction to
Team Risk Management, Special Report CMU/SEI-94-SR-1, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh: PA, 1994.
Leach, L.. Critical Chain Project Management, Artech House Inc, London, 2000.
Miguel, A.. Gestão de Projectos de Software: Metodologias, Ferramentas e Práticas. FCA-
Editora de Informática, Lisboa, 2003.
Neuman, P., “Risks in Retrospect”, Communications of the ACM, 43:7 (July 2000), pp. 144-
146.
Newbold, R. Project Management in the Fast Lane: Applying the Theory of Constraints, St
Lucie Press/APICS Series on Constraints Management, 1998.
Norman, D. “Risks: Beyond the Computer Industry”, Inside Risks 145, CACM Nr. 45, Vol. 7
(July 2002).
Parkinson, C., Parkinson’s Law: The Pursuit of Progress, John Murray, London, UK, 1958.
PMI Standards Committee. A guide to the project management body of knowledge (PMBOK
guide). Upper Darby, PA: Project Management Institute, 2000.
Standish Group. Chaos Charting the Seas of Information Technology, The Standish Group
International , West Yarmouth, MA, 1996.
Weinstein, L. “Risks of Inaction”, Inside Risks 143, CACM Nr. 45, Nr. 5 (May 2002).
Yourden, E., “Tracking Defects to Help Monitor Project Progress”, CUTTER IT Journal, Nr.
12, Vol. 5 (1999), pp. 78-89.

12