CCPM - Quelhas e Barcaui 2004

8/10/2019 CCPM - Quelhas e Barcaui 2004

1/21

Revista Pesquisa e Desenvolvimento Engenharia de Produo

n.2, p. 1 21, jul 2004

CORRENTE CRTICA: UMA ALTERNATIVA GERNCIA DE PROJETOSTRADICIONAL

Prof. Andr B. BARCAUIMestrando em Sistemas de Gesto

Laboratrio de Tecnologia, Gesto de Negcios e Meio Ambiente LATEC/UFFCaixa Postal: 100.175 CEP: 24001-970 - Niteri-RJ

[email protected]

Prof. Osvaldo QUELHAS, D.Sc.Coordenador do Mestrado em Sistemas de Gesto

Laboratrio de Tecnologia, Gesto de Negcios e Meio Ambiente LATEC/UFF

Caixa Postal: 100.175 CEP: 24001-970 - [email protected]

RESUMO

Este artigo procura examinar e sintetizar o que pode ser considerado um dos maiores avanos einovaes na rea de gerncia de projetos dos ltimos 30 anos: a chamada Corrente Crtica. Desdesua origem na Teoria das Restries, essa metodologia tem despertado o interesse de diversospesquisadores da rea e gerentes de projeto que buscam novas opes para a forma com quegerenciam seus projetos tradicionalmente. A razo por trs desta busca analisada no texto, bem

como a alternativa proposta atravs da Corrente Crtica. Toda a metodologia revisitada desde suasrazes. Sua aplicao em projetos isolados, tcnica de construo da corrente, o planejamento deprojetos em ambientes multi-projeto, e tambm a forma proposta de gerenciamento e controleatravs de pulmes adotada pela metodologia.

Palavras-chave: Gerncia de projetos; Teoria das restries; Gerenciamento.

ABSTRACT

This article deals with and synthesizes what could be called one of the most advances andinnovations on the project management area for the last 30 years: the so-called Critical Chain. Since

its origin with the Theory of Constraints, this methodology has aroused the interest of several fieldresearchers and project managers seeking new options for the way they manage their projectstraditionally. The reason behind this search is analyzed thru the text, as well as the alternativeproposed by Critical Chain. The whole methodology is revisited from its roots. The application onsingle projects, the chain building technique, the multi-project environment planning, as well as theproposed way of managing and controlling through the use of buffers adopted by the methodology.

Keywords: Project management; Theory of constraints.

Copyright 2004 1
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/21


n.2, p. 1 21, jul 2004

INTRODUO

Desde a sua publicao em 1984, o livro The Goal (A Meta), do fsico israelense Eliyahu Goldratt

tem despertado o interesse de gerentes e diretores de empresas das mais diversas reas de atuao.

Em especial no ambiente de manufatura, onde o contexto do livro se situa, e onde primeiramente a

filosofia gerencial chamada de Teoria das Restries (TOC -Theory of Constraints) foi apresentada.

A proposta, apoiada em um romance como pano de fundo, acabou fazendo tanto sucesso que virou

leitura obrigatria de cursos de engenharia de produo e administrao em universidades de todo o

mundo.

fato que as organizaes cada vez mais vem sendo foradas a otimizar processos, minimizar seus

custos, e aumentar sua produtividade, sob pena de se no o fizerem, perderem mercado em um

mundo cada vez mais competitivo e sem fronteiras. Como atingir estes objetivos tem sido na

verdade o grande desafio enfrentado por seus gestores. A TOC oferece uma alternativa bastante

interessante para esta equao, visualizando a empresa no em partes isoladas, mas como um

sistema integrado. Mais especificamente, um conjunto de elementos entre os quais h algum tipo de

ligao. O desempenho global do sistema depende dos esforos conjuntos de todos os seus

elementos. Assim como em uma corrente, a empresa to forte quanto o seu elo mais fraco. Logo,

se quisermos melhorar o desempenho do sistema, precisamos conhecer sua principal restrio e

atuar nela, de forma a promover um processo de melhoria contnua.

Copyright 2004 2


3/21


n.2, p. 1 21, jul 2004

65%

70%

49%

44%

63%

73%

Tempo de Produo:

Reduo Mdia

Ciclo do Produto:

Reduo Mdia

Nvel de Inventrio:

Reduo Mdia

Entrega no Prazo:

Melhoria Mdia

Variveis Financeiras

Combinadas:

Aumento Mdio

Renda/Produtividade:

Aumento Mdio

Resumo de um estudo independente:

Exemplo de Empresas usando TOC

65%

70%

49%

44%

63%

73%

Tempo de Produo:

Reduo Mdia

Ciclo do Produto:

Reduo Mdia

Nvel de Inventrio:

Reduo Mdia

Entrega no Prazo:

Melhoria Mdia

Variveis Financeiras

Combinadas:

Aumento Mdio

Renda/Produtividade:

Aumento Mdio

Resumo de um estudo independente:

Exemplo de Empresas usando TOC

Figura 1. Exemplo de Empresas usando a filosofia TOC. Fonte: The World of the Theory of Constraints,Vicky Mabin e Steven Balderstone, St.Lucie Press, 1999.

A ESSNCIA DA TOC

A restrio de um sistema nada mais do que qualquer coisa que impea o sistema de atingir um

desempenho maior em relao a sua meta (Goldratt, 1990). Para tanto, fundamental conhecer a

meta do sistema em questo e as medidas que vo permitir o julgamento do impacto de qualquer

ao local nessa meta. De acordo com a teoria, e com base na premissa que a principal meta de uma

empresa normalmente seu resultado financeiro, se a empresa no possusse uma restrio, seu

lucro seria infinito. Partindo deste princpio, so consideradas dois tipos de restries: fsicas e no-

fsicas (polticas e emocionais). A TOC procura tratar estas restries atravs do seu Processo de

Pensamento (Thinking Process) e respondendo as seguintes perguntas:

Como provocar a mudana ?

O que mudar ? Mudar para o que ?

Figura 2. TOC Thinking Process e suas trs perguntas-chave.

Copyright 2004 3


4/21


n.2, p. 1 21, jul 2004

A interpretao do Processo de Pensamento proposto pela TOC de que para uma lista de sintomas

observveis, deve ser feita uma anlise de causa-e-efeito com objetivo de identificar a causa

principal do problema. Nas organizaes, o problema principal inevitavelmente um conflito no

resolvido, chamado pela teoria de Core Conflict ou Conflito Principal. Desafiando as premissas

lgicas por trs do conflito principal, sua restrio identificada, permitindo assim traar estratgias

para melhoria de desempenho. Como cada organizao apresenta sua prpria cultura, um plano

especfico para implementao das estratgias elaborado, incluindo as aes a serem tomadas, por

quem e quando.

Os processos envolvidos na TOC, e apoiados nas perguntas acima, reconhecem que a performance

da cadeia de valor de um sistema ditada por sua restrio principal e o algoritmo resultante para

maximizar a performance desta cadeia :

1. Identificar a restrio2. Decidir como explorar a restrio3. Subordinar e sincronizar todo a resto deciso acima

4. Elevar a performance da restrio5. Se em qualquer um dos passos anteriores, a restrio principal for alterada, volte ao passo 1

Estes so os chamados 5 Passos da TOC, que promovem a fundao para as mais diversas

solues, incluindo inventrio, cadeia de suprimentos, contabilidade, desenvolvimento de produtos e

gerncia de projetos. Na aplicao da TOC em gerncia de projetos, dois tipos de sistemas podem

estar envolvidos. O primeiro o sistema de um projeto nico (standalone). O segundo o sistema

de uma empresa, em um ambiente onde diversos projetos so conduzidos (multi-project

environment).

OS CONFLITOS INERENTES GERNCIA DE PROJETOS

O objetivo de todo o projeto entregar todo o escopo acordado, com a qualidade esperada pelo

cliente, dentro do prazo e do custos orados (Lewis, 1995, pg 49). A satisfao do cliente est

Copyright 2004 4


5/21


n.2, p. 1 21, jul 2004

diretamente ligada aos benefcios proporcionados pelo projeto. Logo, quanto antes estes produtos

forem entregues, mas rpido os benefcios potenciais do projeto podem ser reconhecidos, pelo

menos na maioria dos casos. O fator limitante (ou restrio), na habilidade de tirar vantagem do

produto de um projeto o reconhecimento da existncia de uma enorme quantidade de trabalho para

a realizao do mesmo. Isso envolve as tarefas para realizao do trabalho, as pessoas envolvidas,

bem como o tempo relativo a cada tarefa. Desta forma, quanto maior a durao do projeto, mais

tempo ser necessrio para que possam ser sentidos os seus benefcios. A definio de caminho

crtico em um projeto a do caminho de menor folga em todo o diagrama de rede (PMBOK

ed.2000, pg.75), e consequentemente uma das maiores preocupaes do gerente de projeto. Em

sntese, o tamanho do caminho crtico define o tempo de durao do projeto. Logo, pode serconsiderado como a sua principal restrio.

Estes desafios se multiplicam em um cenrio onde vrios projetos so executados ao mesmo tempo.

Este o caso da maioria das grandes empresas de consultoria, empreiteiras, operadoras de

telecomunicaes e todas as demais que tem em seu cotidiano a misso de entregar valor para seus

clientes internos e externos atravs de projetos bem conduzidos. Cada vez mais e mais empresas

estaro trabalhando por projetos e dando menos importncia aos chamados departamentos

funcionais (Meredith, Jack, 2000, pg. 139-169). Em tese, no importa de onde vem o recurso, com

tanto que esteja desempenhando seu papel no projeto para o qual foi designado.

Em um ambiente assim, o portflio de projetos da organizao depende diretamente do seu conjunto

de recursos, sejam estes internos ou externos. O problema que normalmente este nmero finito.

A primeira vista, a competncia e a capacidade destes recursos podem ser interpretadas como

principal fator restritivo. At porque, sempre existiro recursos que sero comumente mais

utilizados do que outros, sendo em funo disso, considerados como restries melhor

performance do sistema.

Copyright 2004 5


6/21


n.2, p. 1 21, jul 2004

Porm outra perspectiva desempenha papel predominante neste sistema. A forma como estes

recursos so utilizados deve ser analisada com muito cuidado. Em outras palavras, os processos e

polticas da empresa em relao a alocao de seus recursos so de fundamental importncia no

contexto da restrio. Em um ambiente multi-projeto, o que normalmente limita estes recursos de

serem mais efetivos em seu trabalho uma combinao de diversas tarefas no-sincronizadas, aliada

a uma falta de direo clara em relao s prioridades, resultando em perda de foco e na tentativa de

fazer vrias coisas ao mesmo tempo (a chamada multitarefa). Para muitas organizaes envolvidas

com projetos mltiplos, a verdadeira restrio so suas prticas internas de lanamento de diversos

projetos ao mesmo tempo sem preocupao com a capacidade do sistema e sem mecanismos de

estabelecimento de priorizao de recursos.

A CORRENTE CRTICA

Conforme explicado anteriormente, a gerncia de projetos enfrenta conflitos fundamentais em duas

reas. A primeira relacionada a projetos singulares, onde o gerente de projeto tem que entregar no

menor tempo possvel, mas dentro da especificao tcnica e oramento esperados, garantindo a

satisfao do cliente. A segunda em ambientes onde vrios projetos so executados em paralelo, e

onde o desejo de comear novos projetos (visando obter seus benefcios mais rapidamente), tem que

ser administrado em funo do foco em completar os projetos j existentes.

Figura 3. Exemplo da rvore de representao de conflitos de Goldratt.Conflito em gerncia de tempo em projetos.

Copyright 2004 6


7/21


n.2, p. 1 21, jul 2004

A Corrente Crtica ou CCPM (Critical Chain Project Management), a aplicao da TOC aoambiente de projetos. Pode ser definida como uma abordagem gerencial e de diagramao de rede,

que leva a uma significativa melhora na performance de projetos, buscando resolver seus conflitos

principais. Como na Teoria das Restries, a CCPM busca obter esta melhora desafiando diversas

premissas existentes hoje na maneira tradicional de planejamento e controle de cronogramas.

A primeira premissa quebrada que o melhor lugar para insero de segurana no projeto dentro

de cada tarefa individualmente. Existe uma tendncia natural das pessoas de passarem estimativasde tempo extremamente superestimadas em funo de possveis futuras cobranas e tambm da

manuteno da estabilidade de seu prprio nvel de conforto. Como exemplo, se uma tarefa leva em

mdia 13 dias para ser completada, a estimativa normalmente oferecida pelo responsvel da tarefa

de no mnimo 40% mais alta do que a essa mdia. Isso ocorre em funo da insero de uma

margem de segurana embutida na tarefa especfica. E a experincia mostra que quanto mais

experiente o recurso, maior a insero de segurana.

Figura 4. mbito das estimativas de tempo para uma tarefa.

Copyright 2004 7


8/21


n.2, p. 1 21, jul 2004

Este fenmeno, se multiplicado por todas as tarefas do diagrama de rede de um projeto, leva

inevitavelmente ao aumento desnecessrio do tempo para realizao do mesmo. A Corrente Crtica

sugere uma diminuio agressiva na estimativa de tempo por tarefa. Especificamente, essa

estimativa reduzida ao ponto onde as pessoas responsveis por cada tarefa acreditam que seja uma

estimativa agressiva, porm no impossvel de ser realizada. Normalmente isso resulta em uma

estimativa baseada na mdia da durao de uma tarefa, no lugar de uma estimativa com grande

margens (90-95%) de segurana. Em alguns casos isso pode significar uma reduo de mais de 50%

na estimativa originalmente obtida.

Uma vez considerando essa margem de segurana que os profissionais envolvidos em projetos

normalmente embutem em seus cronogramas, como explicar os constantes atrasos a que os projetos

so submetidos ? So vrias as causas, dentre elas:

Sndrome do Estudante: caracterstico da natureza humana esperar at que uma tarefa fiquerealmente urgente para realiza-la;

Lei de Parkinson: o trabalho se expande para preencher todo o tempo disponvel. Mesmo queuma tarefa seja completada antes do tempo, o recurso gasta todo o tempo que resta paraterminar de completa-la. Esta inclusive uma das razes da metodologia da Corrente Crticaeliminar os marcos de entrega (milestones) como so conhecidos. O que passa realmente aimportar a data final do projeto.

Desperdcio da folga nos caminhos da rede:

o Em caminhos seqenciais: supondo a tarefa B, que tem durao de 10 dias e uma relaode fim-incio (finish-to-start)com a tarefa A que por sua vez tem durao de 5 dias. De

acordo com o cronograma, se a tarefa A acabar no quinto dia, a atividade B devercomear no sexto consecutivo. O que se observa que se a atividade A terminar aps 6dias, a atividade B s comear no stimo dia, levando a um atraso de 1 dia. Mas mesmoque a atividade A termine com 4 dias (indicativo inclusive de relativo sucesso parcial), oque se verifica na prtica que esse trmino mais cedo no reportado para oresponsvel pela atividade B. O que significa que mesmo terminando a tarefa A maiscedo, a atividade B continuar a iniciar no dia 6 conforme previsto originalmente. Ouseja, a folga desperdiada.

Copyright 2004 8


9/21


n.2, p. 1 21, jul 2004

o Em caminhos paralelos: Supondo atividades A,B,C, e D imediatamente antecessoras aatividade X e todas com 10 dias de durao, conforme figura 5. No importa que 3 destas

atividades terminem com 5 dias a menos, se uma delas terminou com 15 dias a mais. AAtividade X s comear aps todas as atividades terem terminado. Ou seja, as possveisfolgas sero igualmente desperdiadas.

Figura 5. No caso de atividades em paralelo, o maior atraso sempre passado para a prxima atividade.

Multitarefa: supondo a situao da figura abaixo, onde o caminho crtico do projeto composto por 3 atividades de 3 dias de durao cada e com um mesmo recurso associado. Seas atividades forem realizadas em sequencia, o projeto durar 9 dias. Se forem realizadas noformato multitarefa, o projeto sofreria um atraso de, no mnimo, o dobro do necessrio. Naprtica, considerando o tempo necessrio de reposicionamento do mesmo recurso entre cadatarefa, esse tempo final pode ficar pior ainda.

Figura 6. A multitarefa atrasando a realizao do projeto e servindo tambm como base para estimativas maispessimistas das mesmas tarefas em prximos planos.

Copyright 2004 9


10/21


n.2, p. 1 21, jul 2004

Com base nas causas apresentadas acima, a CCPM prope uma reduo em mdia, de 50% na

estimativa de cada tarefa inserida no cronograma. No entanto, essa diminuio da segurana

colocada em cada tarefa, torna o projeto bem mais vulnervel possveis atrasos derivados das

mudanas e incertezas a que todo o projeto submetido. A CCPM gerencia este fato com a

colocao de parte da segurana removida das tarefas individuais em pulmes (buffers) ao final de

cada caminho da rede.

Outro paradigma quebrado pela CCPM a reduo significativa da multitarefa, que s degrada o

projeto conforme exemplificado anteriormente. A CCPM consegue isso atravs da eliminao da

conteno de recursos durante o desenvolvimento do diagrama de rede. Uma vez que a conteno de

recursos eliminada, a corrente crtica (principal restrio do projeto) definida como o maior

caminho atravs da rede, considerando as dependncias de atividades e de recursos. Este

procedimento difere do caminho crtico proposto pelo tradicional mtodo CPM (Critical Path

Method) e inventado em 1958, que s considera as dependncias entre tarefas.

Tambm no necessrio comear todos os caminhos no-crticos em sua data mais cedo (earlystart date) conforme sugerido pelo CPM. A CCPM usa a data mais tarde de incio (late start date)

para todos os caminhos do projeto. Apesar de parecer imprudente do ponto de vista do risco, as

vantagem desta quebra de paradigma so claras. No s so reduzidos os impactos de mudanas em

trabalhos j realizados, como evita-se incorrer em investimentos mais cedo do que o necessrio, e

tambm a perda de foco por comear simultaneamente vrios caminhos ao mesmo tempo.

Um dos buffers apresentados acima colocado ao final da corrente crtica e chamado de Project

Buffer(PB). A corrente crtica mais o PB formam a data final de entrega do projeto. Outros buffers

so inseridos em caminhos que se unem a corrente crtica para garantir que no se tornem crticos

tambm. Estes buffers so chamados de pulmes de convergncia ouFeeding Buffers(FB), uma

vez que so inseridos justamente na convergncia entre esses caminhos e a corrente crtica. Sua

Copyright 2004 10


11/21


n.2, p. 1 21, jul 2004

utilidade de proteger a corrente crtica de possveis problemas que venham a ocorrer nesses

caminhos que se unem a ela.

Em geral, os buffers so calculados com 50% do total da segurana removida no caminho em

questo, ou como resultado da raiz da soma dos quadrados da segurana retirada de cada tarefa

daquele caminho. utilizado o valor que produzir um buffer mais robusto.

Passos para a criao de um diagrama de rede com base em CCPM:

1. Criar a rede.

Supondo um diagrama de rede feito da maneira tradicional, observa-se 2 possveis caminhos

conforme exemplificado na figura 7 abaixo. Da maneira tradicional (CPM), teramos um projeto

com 22 dias de durao. As cores em cada tarefa representam os recursos associados. O primeiro

passo seria usar os tempos mdios por atividade conforme explicado anteriormente. A seguir, devemser utilizados os tempos mais tarde de incio para os caminhos no crticos, seguindo a lgica da

rede.

Copyright 2004 11


12/21


n.2, p. 1 21, jul 2004

Figura 7. Criao da rede com base nos tempos mdios por tarefa.

2. Identificar a Corrente Crtica.

Uma vez criada a rede, toda conteno de recursos deve ser eliminada para facilitar a identificao

da corrente crtica. No caso da figura 8 a seguir, o recurso A (rosa) e o recurso D (verde) teriam que

estar realizando duas atividades paralelas ao mesmo tempo, o que impossvel. A corrente crtica

definida como sendo o maior caminho atravs da rede, levando-se em conta as dependncias entre

tarefas e tambm de entre recursos.

Figura 8. Identificao da Corrente Crtica.

3. Proteger a corrente crtica.

Uma vez identificada a corrente crtica, e a fim de evitar uma vulnerabilidade indesejvel em relao

ao tempo de durao do projeto, inserido um buffer de projeto ao final da corrente crtica,

calculado normalmente com 50% do total da segurana retirada de cada tarefa. No caso do exemplo

da figura 9, o PB foi calculado com 6.5 dias. Aps a insero do PB, so inseridos tambm os

chamados FBs em cada caminho convergente com a corrente crtica. A frmula do calculo dos

FBs equivalente a do PB.

Copyright 2004 12


13/21


n.2, p. 1 21, jul 2004

Figura 9. Proteo da corrente crtica com a colocao doProject Buffer(PB) e dosFeeding Buffers(FB).

O GERENCIAMENTO DOS BUFFERS

Os buffers envolvidos na CCPM (em especial o buffer do projeto), funcionam como uma base de

sustentao para gerenciar e medir o progresso do projeto em relao a data de trmino esperada.

Em geral, essa gerncia dos buffers feita, dividindo-se o buffer em trs diferentes nveis conforme

exemplificado na figura abaixo. Cada nvel representa 1/3 do tempo calculado ao buffer.

Figura 10. Exemplo clssico de gerenciamento de Buffers

Copyright 2004 13


14/21


n.2, p. 1 21, jul 2004

Uma vez que a as estimativas por tarefa so de 50%, aproximadamente metade do tempo as tarefasterminaro mais cedo e metade do tempo mais tarde. esperado que o tempo de buffer seja

consumido e tambm recuperado, na medida em que as tarefas vo terminando mais cedo ou mais

tarde do que determinado. Se uma atividade permanecer na parte verde do buffer do projeto,

nenhuma ao requerida ao gerente do projeto.

Se o consumo do buffer entrar na sua segunda metade (amarela), o gerente do projeto deve tomar

cuidado com as atividades envolvidas na corrente crtica e desenvolver um plano de recuperao emassociao com os gerentes que alocam recursos para as atividades em andamento e que esto por

vir na corrente crtica. O objetivo voltar para a rea verde do buffer. Este plano de recuperao

pode passar por horas extras, alocao extra de recursos, aumento de prioridades,fast-tracking, etc.

Se o buffer entrar no seu terceiro nvel (vermelho), o gerente de projeto dever por em prtica o

plano de recuperao desenvolvido anteriormente e segui-lo at que o buffer esteja recuperado de

volta em seu primeiro tero (verde).

Vrias so as ferramentas de softwares hoje que suportam tanto CCPM quanto a gerncia de buffers.

Atravs destes programas possvel obter relatrios precisos sobre o andamento do projeto,

consumo do PB e dos FBs, quais as tarefas que esto consumindo mais ou menos os buffers, e qual

o tempo restante por tarefa no caminho que est alimentando um dado buffer. Estes relatrios

ajudam o gerente de projeto na deciso de onde focar esforos e o que ou no realmente

importante.

interessante observar que os buffers no devem ser confundidos com as tradicionais folgas (floats)

do CPM. As folgas por definio existem em todos os caminhos no-crticos de uma rede. Os

gerentes de projeto aprenderam a usar a medio das folgas para gerenciar os problemas que os

Copyright 2004 14


15/21


n.2, p. 1 21, jul 2004

FBs tentam evitar. Porm as folgas resultam da lgica de um cronograma determinstico. Por

exemplo, um caminho muito menor do que o caminho crtico tem uma folga relativamente grande.

Como o caminho pequeno, a variao na sua durao tambm dever ser pequena (em relao a

variao do caminho crtico). Por outro lado, um caminho quase to grande quanto o caminho

crtico, apresenta uma folga muito pequena. Normalmente o caminho que mais representa perigo

para o caminho crtico e portanto, o caminho que requer a maior proteo contra incertezas. Sendo

assim, a quantidade de folga disponvel em um cronograma do tipo CPM inversamente

proporcional ao necessrio para proteger o caminho crtico.

O tamanho dos buffers na CCPM variam diretamente em funo dos caminhos a que esto

associados. Logo, quanto maior o caminho em questo e maior a sua incerteza, maior dever ser o

buffer associado a ele. Como na CCPM esperado que haja um certo consumo de buffer, um

oramento tem que ser alocado para cobrir este tipo de tratamento. Existem vrias formas de

alocao de oramento para cobertura de buffers que no so objetivos deste artigo. S cabe

salientar que da mesma forma que existe um buffer de tempo, natural que exista tambm um

buffer proporcional de oramento.

A SOLUO PARA AMBIENTES DE PROJETOS MLTIPLOS

O segundo grande conflito em gerncia de projetos diz respeito ao ambiente onde vrios projetos so

executados. A grande dvida como gerenciar eficientemente e garantir o trmino de projetos

existentes, em relao a tentao de comear novos projetos o mais rpido possvel. A maioria das

organizaes no observa com devido cuidado a sua real capacidade interna para conduo de

diversos projetos ao mesmo tempo.

Em funo disto, a preferncia por iniciar diversos projetos ao mesmo tempo, sob a crena de que

quanto mais cedo forem iniciados, mais cedo terminaro. De acordo com CCPM, esta prtica uma

das maiores causas da prejudicial multitarefa entre recursos de projetos diferentes. O que geralmente

Copyright 2004 15


16/21


n.2, p. 1 21, jul 2004

acaba levando a projetos que terminam mais tarde do que o esperado, desagregao de times, mais

horas extras, etc.

A soluo da CCPM para este tipo de conflito simples, e comea (assim como a maioria das

solues baseadas na TOC) com o uso do que pode ser chamado de puro bom senso. Ou seja,

necessrio que a organizao saiba priorizar sua carga de trabalho por projeto.

Existem diversas formas de estabelecer a priorizao: importncia do cliente associado, oramento e

benefcios relativos ao projeto, complexidade, estratgia da empresa, etc. Uma vez com a prioridade

estabelecida, os projetos podem ser considerados como projetos simples e gerenciados pelos

mesmos mecanismos de CCPM explicados anteriormente.

Neste cenrio, os recursos passam a desempenhar um papel de ainda maior destaque na metodologia

CCPM. A proposta trabalhar com os recursos comuns e de maior demanda aos diversos projetos

de uma forma sincronizada. Estes recursos sincronizados so escalonados entre os vrios projetos

empreendidos, atravs da reprogramao da rede e do cuidado para evitar possveis contenes.

Desta forma, possvel precaver conflitos por recursos em comum para mais de um projeto,

reduzindo significativamente a multitarefa.

Este cronograma montado atravs do sincronismo de recursos permite que organizao tome a

deciso de iniciar ou no novos projetos de maneira muito mais consciente. A idia permitir que os

projetos sejam completados em muito menos tempo em relao a capacidade da empresa, e ainda,

revelar novas capacidades adicionais anteriormente escondidas.

Nunca demais lembrar que o sistema no caso do ambiente multi-projeto tambm to forte quanto

o seu elo mais fraco. No caso, a capacidade do sistema pode ser medida pelo recurso e/ou

departamento que representa a maior restrio.

Copyright 2004 16


17/21


n.2, p. 1 21, jul 2004

O primeiro passo para trabalhar com CCPM em um ambiente de projetos mltiplos montagem dacorrente crtica de todos os projetos de forma simultnea. Em seguida, deve-se identificar de uma

maneira geral, qual seria o recurso que representa a restrio de capacidade do sistema, chamado de

tambor (drum). No exemplo da figura 11, so apresentados trs projetos concorrentes (A, B, C) e

similares. As cores representam os recursos a serem utilizados em cada projeto.

Figura 11. Exemplo de projetos concorrentes.

Supondo que a organizao escolheu o recurso vermelho como a maior restrio ao sistema, este

seria o recurso a ser sincronizado. A figura 12 mostra apenas o recurso vermelho sincronizado para

os 3 projetos.

Copyright 2004 17


18/21


n.2, p. 1 21, jul 2004

Figura 12. Recurso Drumidentificado.

Uma vez identificados os recursos que representam maior restrio ao sistema, o prximo passo a

eliminao da conteno de recursos entre projetos de acordo com a priorizao estabelecida pela

organizao. Desta forma, j possvel observar um escalonamento entre projetos (figura 13). Mas

muitas vezes, este escalonamento pode no ser suficiente para proteger um projeto das varincias de

um projeto anterior a ele, causando efeitos indesejveis.

Figura 13. Conteno eliminada segundo priorizao de projetos definida pela organizao.

A forma que a CCPM encontrou para evitar possveis atrasos causados por flutuaes entre projetos,

foi a criao de um outro buffer, chamado de pulmo de capacidade (capacity buffer), conforme

exemplificado na figura 14. Esse buffer tem o tamanho proporcional ao tamanho da atividade do

Copyright 2004 18


19/21


n.2, p. 1 21, jul 2004

recurso restritivo (drum), e seu objetivo o escalonamento com a devida proteo entre o fim do

projeto anterior e o incio do prximo. A figura 15 a seguir mostra o resultado final deste

escalonamento entre projetos.

Figura 14. Utilizao dos capacity buffersentre projetos.

A gerncia de buffers em um ambiente de projetos mltiplos facilita a viso geral da organizao em

relao a suas prprias restries e capacidade. Uma das questes mais importantes que tipo de

tarefa designar a cada recurso de forma a proporcionar uma maior flexibilidade e disponibilidade de

um nmero maior de recursos. Esta a principal causa que leva uma melhor performance em

relao ao tempo de projetos que utilizam CCPM. Ao mesmo tempo, a gerncia dos buffers

funciona como um alerta ao gerente de projetos sobre qual projeto apresenta maiores problemas e

que tipo de acertos entre recursos deve e pode ser realizado.

Figura 15. Projetos escalonados pela sincronizao do capacity buffer.

Copyright 2004 19


20/21


n.2, p. 1 21, jul 2004

CONCLUSO

Apesar de recente em sua criao, a metodologia da Corrente Crtica vem ganhando mais adeptos

em todo o mundo. Tambm so muitos os artigos publicados sobre o tema e/ou derivaes dele, at

porque as organizaes nos dias de hoje no podem mais se dar ao luxo da conduo de projetos de

maneira somente emprica. Tambm no parece lgico continuar insistindo somente no formato

tradicional de gerenciar projetos, que comprovadamente apresentam e podem induzir a limitaes de

performance conforme explicado anteriormente.

Apresentada como uma nova metodologia, a Corrente Crtica no complexa em sua essncia. Toda

a linha de pensamento por trs da CCPM , tem como base a observao e o bom senso apresentados

na Teoria das Restries. Apesar de no ser este o objetivo central deste artigo, vale a pena

comentar que o foco principal na implementao da CCPM muitas vezes no est na tcnica, mas

sim na fundamental mudana cultural necessria a sua aplicao.

No razovel negligenciar a incerteza inerente a todo projeto. Mas sim, reconhecer que ela existe

como ponto de ateno to importante quanto escopo, tempo, custos e qualidade. Conforme

sugerido pela Corrente Crtica, a estratgia e a forma de gerenciar esta incerteza pode significar a

diferena entre o sucesso e o fracasso de um projeto.

REFERNCIAS BIBLIOGRFICAS

[1]

[2]

[3]

CARDELLA, TONY. Delivering Project Benefits Faster using the Theory of Constraints.Goldratt Institute, 1998.

COX III, JAMES F.; SPENCER, MICHAEL S. Manual da Teoria das Restries. So Paulo: CRCPress LLC, 1997.

GOLDRATT, ELIYAHU. The Goal. Great Barrington: North River Press, 1992.

Copyright 2004 20


21/21


n.2, p. 1 21, jul 2004

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

GOLDRATT, ELIYAHU. Critical Chain. Great Barrington: North River Press, 1997.

LEACH, LAWRENCE P. Critical Chain Project Management. Boston: Artech House, Inc., 2000.

LEACH, LAWRENCE P. Simplified Critical Chain Project Management (S-CCPM). AdvancedProjects Institute, 2000.

LEWIS, JAMES P. The Project Managers Desk Reference: A comprehensive guide to projectplanning, scheduling, evaluation, control & systems. New York: McGraw-Hill, 1995.

MEREDITH, JACK R. Project Management: A Managerial Approach. New York: JohnWiley&Sons, 2000.

PATRICK, FRANCIS S. Getting Out from between Parkinsons Rock and Murphys Hard Place .PM Network Magazine 13, 1998.

PATRICK, FRANCIS S. Program Management Turning many projects into few priorities withTOC. Proceedings: PMI International Symposium, 1999.

PROJECT MANAGEMENT INSTITUTE (PMI). A Guide to the Project Management Body ofKnowledge (PMBOK). Upper Darby, 2000.

Documents

CCPM - Quelhas e Barcaui 2004