gestão de múltiplos projetos por meio da metodologia da … · gestão de múltiplos projetos por...

Gestão de múltiplos projetos por meio da metodologia da Cadeia Crítica: Efeitos dos Buffers de capacidade

Nicole Suclla FernandezPontifícia Universidade Católica de Rio de Janeiro – Departamento de Engenharia IndustrialRua Marquês de São Vicente, 225, sala 950L - Rio de Janeiro, RJ - Brasil – CEP: 22451-900

[email protected]

Leonardo Junqueira LustosaPontifícia Universidade Católica de Rio de Janeiro – Departamento de Engenharia IndustrialRua Marquês de São Vicente, 225, sala 950L - Rio de Janeiro, RJ - Brasil – CEP: 22451-900

[email protected]

Madiagne DialloPontifícia Universidade Católica de Rio de Janeiro – Departamento de Engenharia IndustrialRua Marquês de São Vicente, 225, sala 950L - Rio de Janeiro, RJ - Brasil – CEP: 22451-900

[email protected]

RESUMO

A metodologia da Cadeia Crítica e Gestão de Buffers para gestão de projetos complexos sujeitos a grandes incertezas e recursos limitados tem sido recebida com entusiasmo por gerentes. Entretanto, além dos desafios da sua aplicação a projetos independentes, outros surgem quando se trata de projetos que compartilham recursos limitados e se desenvolvem simultaneamente. Para obter uma programação robusta, capaz de se manter coerente e estável ante os imprevistos da execução, a metodologia estabelece a inserção de buffers de tempo. Este artigo se concentra na análise dos buffers de capacidade (BC) que são “tempos de reserva” usados para evitar que atrasos em um projeto afetem outros. O objetivo é mostrar efeitos importantes da forma de dimensionamento dos BCs. Através da programação e simulação da execução de um exemplo, discute-se o método de dimensionamento mais popular, mostrando que, mesmo em casos simples, ele pode prejudicar o desempenho de alguns dos projetos.

PALAVRAS CHAVE. Gestão de múltiplos projetos. Cadeia Crítica e Gestão de Buffers. Dimensionamento de Buffer de capacidade. Outras aplicações ou outras metodologias.

ABSTRACT

The Critical Chain and Buffer Management (CC/BM) methodology has been enthusiastically welcome by managers for coping with complex projects subject to important uncertainties and limited resources. However, in addition to the difficulties of CC/BM application to independent projects, new challenges emerge when parallel projects sharing common resources are the matter. In order to obtain a robust schedule, capable of staying coherent and stable in face of uncertainties during the execution, the CC/BM requires insertion of time buffers. This paper focus on the analysis of the capacity buffers (CB) that constitute “safety times” for avoiding those delays in one project will affect others. The objective is to show important effects of CB sizing. By programming and simulating the execution of an example, the most popular CB sizing method is discussed, showing that, even in simple cases, its application may result in poor performance of some of the projects.

KEYWORDS. Multiple projects management. Critical Chain and Buffers Management. Sizing of Capacity Buffers. Other applications or methodologies.

XLI SBPO 2009 - Pesquisa Operacional na Gestão do Conhecimento Pág. 2343

mailto:[email protected]

1. IntroduçãoGerenciar eficientemente projetos complexos que compartilham recursos limitados e se

desenvolvem simultaneamente num ambiente incerto, é um desafio para os maiores talentos gerenciais. De inestimável valor seria uma metodologia que permitisse uma programação robusta (isto é, relativamente imune a imprevistos) e capaz de detectar as muitas iminências que surgem na etapa de execução. Com tal auxílio, gerentes poderiam contornar problemas imprevistos antecipando ações para correção de rumo antes que eles se avolumassem e exigissem ações emergenciais. Ações corretivas emergenciais provocam elevados custos e desestabilizam os programas criando novas dificuldades. É claro que isso compromete os objetivos e metas de tempo, custo e escopo dos projetos (CHEN, 2006; HANS et al., 2007). Certamente as técnicas existentes para auxílio à gerência de projetos isolados podem ser empregadas em ambientes de vários projetos simultâneos. Uma prática simples, mas não muito satisfatória, é a de tratar o conjunto de projetos como se fosse um único projeto que se começa com o(s) projeto(s) de início mais cedo e termina com o(s) projeto(s) de término mais tarde. Alguns aspectos tornam essa abordagem pouco atraente. Entre essas inconveniências estão: (a) a dificuldade para se especificar objetivos e metas para cada projeto individualmente e (b) o fato de as restrições de precedência das atividades e de capacidade dos recursos tornarem os projetos altamente interdependentes, dificultando a atribuição de responsabilidades e de latitude de ação entre os gerentes dos vários projetos (KURTULUS & DAVIS, 1982; NEWBOLD, 1998).

As metodologias tradicionalmente utilizadas para o planejamento e programação de projetos: PERT (Program Evaluation and Review Technique) e CPM (Critical Path Method), raramente podem sinalizar claramente desvios do orçamento e das datas de entrega. Esses são, talvez, os problemas mais antigos e ainda mais essenciais da gestão de projetos. Adicionalmente, tais metodologias de gestão não formalizam a influência da restrição dos recursos e a existência de gargalos no programa, dando um único tratamento (em termos de programação e proteção) a todas as atividades do programa (RAND, 2000; ANAVI-ISAKOW & GOLANY, 2003; RAZ et al., 2003; ROZENES et al., 2006). Contudo, o PERT e o CPM foram considerados como métodos bem sucedidos e depois de terem passado por importantes evoluções e adequações constituem a base da maioria de sistemas de software dedicados à gestão de projetos (KOLISCH, 1999). Não obstante, Jyh-Bin (2007) afirma que a dificuldade para entregar projetos pontualmente, respeitando o escopo e orçamento planejado permanece. Recentemente, a metodologia CC/BM (Critical Chain /Buffer Management), ou seja, Cadeia Crítica e Gestão de Buffers foi proposta por Goldratt em 1997. Essa metodologia permite estruturar atividades e eventos em redes, se baseando na Teoria das Restrições (TOC: Theory of Constraints) que na programação de tarefas da prioridade ao recurso mais escasso e o protege contra perturbações que podem reduzir sua utilização. A essência da metodologia CC/BM radica nos seguintes três pilares (NEWBOLD, 1998; HERROELEN & LEUS, 2001; STEYN, 2002; LEACH, 2005).− Cadeia crítica (Critical Chain): a mais longa seqüência de atividades sem folga que determina a duração do projeto;− Inserção de buffers de tempo: “amortecedores” ou espaços de tempo usados como proteção contra incertezas;− Gestão de buffers de tempo: ações preventivas e/ou corretivas realizadas no andamento do projeto a partir do consumo dos buffers devido aos atrasos nas atividades.

A gestão dos buffers de tempo como o principal elemento de proteção e controle é ainda mais importante na gestão simultânea de vários projetos em paralelo. A metodologia CC/BM estabelece que a programação de projetos paralelos deve considerar, na sua estrutura, a inserção de diferentes tipos de buffers de tempo. Cada um desses buffers protege um elemento particular do programa de múltiplos projetos. Nesse contexto, este artigo se concentra no estudo do buffer que permite reduzir e gerenciar as interdependências entre projetos criadas pelo compartilhamento de recursos escassos. Tais buffers, chamados de Buffers de Capacidade – BCs são intervalos de tempo colocados entre atividades de projetos diferentes programadas consecutivamente no recurso gargalo. Os BCs servem para proteger cada projeto contra atrasos nas tarefas dos projetos que o antecedem no recurso gargalo. Sem essa proteção, mesmo um


projeto bem planejado e gerenciado pode ser prejudicado na sua execução por atrasos oriundos de outros projetos. Além disso, através da parcela consumida dos BCs, a gerência geral dos projetos pode, com mais facilidade, localizar atrasos e antecipar a formação problemas (NEWBOLD, 1998; HERROELEN et al., 2002; LEACH, 2005)

Pela sua relevância na gestão eficiente dos projetos, os BCs precisam ser tratados com um cuidado especial. Em particular, um bom dimensionamento dos BCs é crucial para atingir os objetivos de robustez e estabilidade propostos na metodologia CC/BM. Na literatura, o método mais utilizado no dimensionamento dos BCs é discutido por Leach (2005). Os critérios de dimensionamento dos BCs apresentam questões e ambigüidades similares às apontadas por Kjersti & Taylor (1999); Herroelen & Leus (2001) e Herroelen et al. (2002) na análise exaustiva da metodologia CC/BM e do dimensionamento e funcionamento dos tipos de buffers de tempo utilizados. Contudo, o estudo do dimensionamento dos buffers e das conseqüências que estes têm na programação dos projetos é ainda pouco explorado, sendo que os trabalhos mais significativos ao seu respeito são focados em ambientes de gestão de projetos isolado. Desta maneira, pesquisas focadas nos critérios de dimensionamento dos buffers utilizados na gestão de múltiplos projetos são relevantes para o desenvolvimento da metodologia CC/BM.

No presente artigo tem-se o objetivo de mostrar efeitos importantes que a inserção e o dimensionamento dos BCs têm sobre o conjunto de projetos simultâneos e sobre cada um dos projetos que o compõem. Nesse sentido são levantadas questões importantes com respeito ao método de dimensionamento mais utilizado na literatura e nas ferramentas de software mais conhecidas. Com a finalidade de exemplificar os fenômenos que ocorrem em função da definição do tamanho dos BCs e mostrar os aspectos mais salientes das iterações complexas das durações probabilísticas das atividades, recorreu-se à simulação de um modelo sintético, cuja topologia oferece os elementos necessários para os objetivos do artigo.

O restante do artigo está organizado como segue. Na seção 2 são brevemente recordados os conceitos da metodologia CC/BM para programação de projetos isolados. A seção 3 detalha os conceitos da metodologia CC/BM para múltiplos projetos. A seção 4 apresenta o modelo de simulação utilizado e a analise dos resultados obtidos. O artigo termina com uma conclusão e algumas perspectivas de pesquisa.

2. Metodologia CC/BM para projetos isolados A metodologia CC/BM surge com a finalidade de atenuar as deficiências crônicas da gestão

de projetos. Essas deficiências são geralmente expressas em função do desrespeito dos prazos limites, a ultrapassagem de orçamentos, e/ou a redução do escopo dos projetos (STEYN, 2002; RAZ et al., 2003). Entre as características da metodologia se destaca a prioridade que esta da á visão gerencial, fornecendo elementos que controlam os efeitos causados por aspectos psicológicos e técnicos que explicam a razão dos persistentes atrasos nas atividades e a dificuldade de trasladar os ganhos de tempo locais (ganhos causados por atividades completadas antes do previsto) no total do projeto. Tais aspectos psicológicos são: Lei de Parkinson (Tendência de nunca se terminar uma tarefa antes do prazo), Síndrome do Estudante (Tendência de sempre se iniciar uma tarefa apenas quando já não houver folga para atender o prazo) e a Lei de Murphy (Impressão de que todos os percalços previstos realmente ocorrem, certamente porque não se quer acreditar que eles podem, de fato, ocorrer) (RAND, 2000; HERROELEN & LEUS, 2001; RAZ et al., 2003; LEACH, 2005).

Com a finalidade de manter a duração do projeto mínima e fazer que a execução das atividades seja o mais cedo possível (as-soon-as possible), três considerações importantes estão na base da programação CC/BM:

− A duração das atividades é estimada sem proteções ou folgas de tempo embutidas. Isso é considerando que existe um 50% de probabilidade da atividade atrasar (i.e. a mediana da distribuição);

− O programa não considera datas de entrega (due dates) nem pontos de controle (milestone) intermediários;


− O programa não admite que a atividade de um recurso seja interrompida para que ele seja deslocado para alguma outra atividade, ou seja, a execução das atividades não pode ser em forma intermitente.

A metodologia supõe que as durações das atividades são determinísticas e sem folgas embutidas para compensar atrasos, construindo a rede de atividades segundo a regra de programação “mais tarde possível” (as-late-as-possible) e respeitando as restrições de precedência, assim como as de utilização de recursos. Depois de programar a última atividade da cadeia crítica se insere o buffer do projeto – BP. Tal buffer substitui os tempos de segurança (que usualmente nas metodologias PERT/CPM, são considerados em cada atividade) na função de evitar que atrasos ou alterações na cadeia crítica afetem o cumprimento da data de entrega do projeto. Do mesmo modo, os buffers de alimentação - BA protegem a cadeia crítica dos atrasos das atividades não críticas. Estes são localizados onde as atividades não críticas desembocam na cadeia crítica (HERROELEN & LEUS, 2001; HERROELEN et al., 2002).

3. Metodologia CC/BM para múltiplos projetosAs diretrizes para cumprir os objetivos de estabilidade e robustez do programa que a

metodologia estabelece para projetos isolados são estendidas para ambientes de vários projetos simultâneos. Nesse contexto, a metodologia visa definir datas de término exeqüíveis para cada projeto, mantendo o equilíbrio de carga de trabalho no conjunto de múltiplos projetos. Segundo Herroelen et al. (2002); Anavi-Isakow & Golany (2003); Cohen et al. (2004) e Leach (2005) as principais fases da CC/BM em múltiplos projetos são:

− Definir uma prioridade para cada projeto inserido no sistema;− Programar cada projeto individual de acordo com a metodologia CC/BM;− Juntar os projetos num único programa, nivelando as atividades de forma que as

capacidades dos recursos não sejam excedidas;− Identificar qual é o recurso mais carregado entre todos os projetos e a seqüência de

atividades que serão executadas por ele (seqüência crítica do recurso);− Inserir os BCs necessários para evitar que atrasos num projeto se propaguem para o

projeto seguinte.− Inserir os buffers de tambor – BT, buffers de tempo com funcionalidade similar a dos

buffers de alimentação – BA. A função de um BT é evitar que uma atividade não crítica venha a atrasar uma atividade da seqüência crítica.

A imagem 1 exemplifica a localização e funcionalidade dos elementos da programação CC/BM num ambiente de dois projetos paralelos, projetos A e B. A programação é iniciada com a definição da prioridade de cada projeto. Seguidamente, se identifica o recurso gargalo (cinza escuro) e a seqüência de atividades a serem executadas por ele (seqüência crítica: A2, A3, A20, A30). Com base nesses elementos, é realizado o nivelamento dos recursos dos projetos. Nesse processo se redefinem as datas de inicio dos projetos com o objetivo de evitar a programação simultânea de varias tarefas para um mesmo recurso. Com isso feito, a proteção do programa é iniciada com a inserção dos BCs. Estes são colocados entre as atividades de projetos diferentes cuja execução é feita pelo recurso gargalo (atividades da seqüência crítica). Finalmente, os BTs são inseridos entre as atividades da seqüência crítica e as atividades não críticas que lhes sejam predecessores. É importante lembrar que cada projeto inserido no programa deve estar corretamente protegido com os buffers definidos para projetos isolados, sendo que no termino do processo de programação de múltiplos projetos, cada projeto estará protegido tanto contra as incertezas próprias como contra as incertezas oriundas dos projetos que o antecedem.

Devido a este estudo se concentrar na análise dos BCs, sua funcionalidade, assim como, os fenômenos e riscos decorrentes a partir do seu dimensionamento, são o foco das seguintes seções.


Buffer do Projeto

A2A1

A4

A3 A5

A10

A20 A50

A40

Buffer Tambor

Projeto A

Projeto B

Buffer de capacidadeA30

Buffer do Projeto

Tempo

Imagem 1: Programação de múltiplos projetos por meio da CC/BM

3.1 Buffer de Capacidade O buffer de capacidade é um intervalo de tempo definido em função da capacidade do

recurso gargalo e tem a finalidade de evitar que, na seqüência de atividades por ele executadas (geralmente, atividades de todos os projetos do sistema), atrasos de um projeto ocasionem atrasos nos projetos com tarefas subseqüentes no recurso. Portanto a inserção dos BCs procura isolar um dado projeto dos demais, deslocando seu inicio e/ou postergando sua data de término. Espera-se que o efeito desses rearranjos na programação dos projetos faça com que o programa completo dos múltiplos projetos seja robusto ante as incertezas. Ou seja, que no caso de atrasos e outros imprevistos, apenas pequenas alterações sejam necessárias para restabelecer a qualidade e viabilidade do programa. Contudo, isso só é possível mediante aumento da duração (makespan) do projeto, e, conseqüentemente, o risco de perder a competitividade do projeto por apresentar prazos de entrega maiores que a concorrência. A partir de tais efeitos, é que vários autores ressaltam a importância dos critérios considerados no dimensionamento dos buffers (NEWBOLD, 1998; KJERSTI & TAYLOr, 1999; RAND, 2000; HERROELEN et al., 2002).

Leach (2005), baseando-se na teoria de filas e nas suas próprias experiências no gerenciamento de projetos, recomenda utilizar BCs equivalentes a 25% da capacidade do recurso gargalo. Ou seja, programar todas as atividades que antecedem BCs considerando uma disponibilidade de apenas 75% da capacidade total do recurso gargalo. Este método não ignora as diferenças entre as prioridades e/ou nível de incerteza entre as atividades de projetos distintos.

Neste artigo se questiona a eficiência desse método, apontando a falta de uma base racional que justifique o uso da mesma porcentagem da duração da atividade antecedente para dimensionar todos os BCs de um sistema ou conjunto de projetos. Isso pode prejudicar o desempenho dos projetos cujas atividades estão mais no final na seqüência do gargalo. Além disso, sugere-se que o dimensionamento dos BCs depende tanto do recurso gargalo quanto das interdependências dos projetos constituintes do sistema e das diferentes necessidades de proteção eficiente contra as incertezas presentes nas atividades. Sendo, portanto, necessário examinar a interação entre os BCs e o BP de cada projeto. Um tratamento puramente analítico só permitiria investigar as conseqüências do dimensionamento dos BCs em casos muito simples e particulares que comportem os eventos probabilísticos que ocorrem durante a execução do projeto, razão pela qual um estudo baseado em simulação parece mais adequado.

Para alcançar os objetivos da pesquisa por meio de simulação, um pequeno exemplo numérico se torna essencial. Decidiu-se utilizar uma versão simplificada e adaptada do problema de múltiplos projetos proposto por Pritsker B. et al. (1969.). Tal exemplo sintético é caracterizado pela simplicidade e por alguns aspectos essenciais para gerar os fenômenos de interesse. A complexidade e porte de projetos reais, com muitos detalhes irrelevantes,


dificultariam a identificação e entendimento dos fenômenos que são os objetos de estudo neste artigo.

4. Modelo de simulaçãoO objetivo da simulação é representar a rotina probabilística da execução das atividades

programadas no planejamento dos múltiplos projetos, identificando e quantificando os diferentes tipos de atrasos ocorridos sob cada política de dimensionamento. O atraso de uma atividade qualquer pode ser originado pela indisponibilidade dos recursos ou pelo atraso numa seqüência de atividades ligadas por uma cadeia de relações de precedência. O papel da simulação é permitir entender os fenômenos provocados pelos BCs e medir seus efeitos sobre o desempenho dos múltiplos projetos.

1 2 3 4 5 6 7 8 9 10 11

P1A1

P1A2

BP1

P2A1

P2A3

BP2

P3A1

BP3

A= 5, B=3, C=2

A= 0, B=1, C=1

A= 1, B=1, C=1

A= 2, B=2, C=0

A= 2 B=1, C=1

Disponibilidade de recursos: A=6, B=4, C=3

Imagem 2: Exemplo simulado (Programa-base)Fonte: Adaptação de Pritsker B. et.al.(1969).

O programa-base utilizado é o problema adaptado de Pritsker B. et al. (1969.), cuja programação foi reproduzida nas ferramentas de gestão de projetos Prochain e Pipeline (Imagem2). O programa consiste de três projetos, cada um formado pelas atividades críticas e pelos respectivos BP. O modelo simulado considera apenas as atividades críticas. Como há buffers de alimentação (BAs) e buffers de tambor (BTs), para que atrasos nessas atividades possam afetar a cadeia crítica é necessário que haja numa cadeia não crítica um atraso total superior ao seu BA. Se os buffers estiverem bem dimensionados, e forem eficazes, essa é uma probabilidade pequena e, de qualquer forma, os efeitos de atividades não críticas não são o foco do estudo.

O modelo de simulação foi implementado na ferramenta de apoio ProcessModel. O modelo foi elaborado com a técnica de avanço por tempo (time-driven) em que o tempo simulado avança a intervalos regulares. A cada instante (no tempo de simulação) são executadas as alterações no estado do sistema que, segundo o cronograma e/ou a lógica dos eventos descritos pelo modelo, devem ocorrer. Assim, a cada novo instante (hora, dia ou outra unidade de tempo) o programa identifica as atividades que (segundo o programa base, o programa projetado, prioridades e a disponibilidade de recursos naquele instante do tempo de simulação), devem ser iniciadas ou terminadas. Os três projetos são executados de forma simultânea respeitando a prioridade definida para cada projeto (ordem: P1, P2, P3).

O modelo utiliza uma função de distribuição binomial negativa, com origem deslocada, para descrever a duração real da execução das atividades, identificando os atrasos das atividades e dos próprios projetos. Propriedades da função binomial negativa permitem que as distribuições de


atraso dos projetos também sejam modeladas por uma binomial negativa que representa a soma dos atrasos das atividades que o formam. Uma variável aleatória com distribuição binomial negativa pode ser vista como o número x de “fracassos” obtidos numa série de ensaios de Bernoulli, com probabilidade de “sucesso” p, até que s sucessos sejam obtidos. No contexto do modelo, supõe-se que a duração de uma atividade é constituída por duas partes. Uma é o número (determinístico) de dias (para facilitar a linguagem, usaremos “dias” ao invés de “unidades de tempo”) de trabalho produtivo necessário para que a tarefa seja executada; a outra é o número (probabilístico) de dias em que não foi possível trabalhar. O número de dias de trabalho produtivo é representado pelos s dias de trabalho produtivo (número de sucessos na binomial negativa). O número de dias de atraso (dias improdutivos) é a variável de distribuição binomial negativa, x, os fracassos na seqüência de ensaios. A probabilidade de um dia ser produtivo é o parâmetro p (probabilidade de “sucesso” nos ensaios de Bernoulli). A escolha da distribuição binomial negativa tem algumas vantagens. Primeiro, ela corresponde a um processo que tem um apelo intuitivo, ou seja, além do tempo mínimo, a atividade tem dias em que, por motivos diversos, a tarefa não avança. Segundo, ela apresenta uma assimetria típica das distribuições empíricas e converge para a distribuição de Poisson que é freqüentemente utilizada. Finalmente, ela simplifica e dá clareza ao modelo de simulação de avanço por tempo.

Assim, a cada novo instante da simulação, para cada atividade em andamento, o programa verifica se os recursos necessários estão disponíveis para a execução da atividade e, então, sorteia (segundo a probabilidade dada) se a atividade foi produtiva, ou não, naquela unidade de tempo. Se for, uma unidade é somada ao tempo de “trabalho produtivo”. Quando o número de unidades de tempo produtivo necessárias para execução da tarefa é atingido, a atividade é terminada. Assim, são consideradas duas causas distintas para atrasos (dias improdutivos): a) atraso devido à indisponibilidade de recurso e, b) atraso devido a dias improdutivos na execução da tarefa. Essa forma de simulação tem a vantagem de facilitar a implementação de outras análises em que decisões durante a execução dos projetos são tomadas em função do estado de consumo dos buffers.

Os BCs são inseridos no programa-base causando o deslocamento da data de termino dos projetos e, durante a execução, a mitigação na quantidade de atrasos originados pela indisponibilidade de recursos devido aos atrasos em outras atividades. A análise de tais efeitos é apresentada a seguir na seção de resultados.

A simulação consiste de 20 cenários definidos pela probabilidade de atraso do projeto considerada (25%, 20%, 15% e 10%) e pelo tamanho de BC inserido (0%, 15%, 25%, 35% e 45%). São efetuadas 80 replicações similarmente reproduzidas para cada cenário, permitindo, que sua análise seja sob as mesmas condições.

4.1 Apresentações de resultados A inserção de um BC qualquer, provoca um deslocamento equivalente na data de entrega

prometida do projeto que o segue. Ou seja, se por um lado, os BCs aumentam a robustez do programa, por outro, eles podem alongar o makespan dos projetos que tenham atividades subseqüentes a ele na programação do gargalo. Embora isso tenha conseqüências importantes para os objetivos de cada projeto, e para a gestão dos múltiplos projetos, os autores da metodologia, e algumas ferramentas de software que a implementam, sugerem o dimensionamento dos BCs com base em critérios empíricos que dimensionam os BCs como uma porcentagem fixa da capacidade do recurso gargalo.

Adiante, procuraremos mostrar, ainda que por meio de exemplo simples, fortes indícios de que tais critérios de dimensionamento podem, inadvertidamente, prejudicar projetos do conjunto. Sugerimos que os BCs podem ser mais eficientes quando seu dimensionamento leva em conta as características dos projetos como o grau de interdependência existente entre eles, as incertezas em suas atividades e as capacidades dos recursos.

A análise dos diferentes tamanhos de BC é estruturada em três partes. Inicialmente analisamos o efeito agregado nos atrasos e nos deslocamentos das datas de entrega prometidas


em relação à segurança oferecida pelo BP de cada projeto. Numa segunda parte focalizamos o efeito dos BCs sobre os atrasos originados pela indisponibilidade de recursos.

Buffer de Capacidade VS Buffer do projeto.Nesta análise procuramos entender como a inserção de BCs de diferentes tamanhos afeta a

programação de cada projeto. Considerando apenas a cadeia crítica, a inserção de BCs pode ser entendida como a adição de segurança que completa a proteção oferecida pelo BP. Nesse sentido, comparamos o programa-base de cada projeto (sem os BCs) com os diferentes programas projetados resultantes da inserção dos BCs. As inserções provocam o deslocamento das datas prometidas e devem mitigar os atrasos originados pela indisponibilidade de recursos e são automaticamente refletidas no consumo dos BPs, exceto o do projeto correspondente à maior prioridade de execução (primeiro projeto em ser executado).

2.5

3.0

3.5

4.0

4.5

5.0

5.5

6.0

6.5

7.0

BP50_BC00 BP50_BC15 BP50_BC25 BP50_BC35 BP50_BC45

Consumo do BP

BP1 BP2 BP3

Imagem 3: BC vs Consumo do BP (25% de probabilidade de atraso do projeto)

Na Imagem 3 se mostra como os três projetos do sistema apresentam um comportamento diferenciado ante a inserção dos BCs dimensionados sob o mesmo critério (uma única percentagem para todos os BCs). O P1, por ser o projeto de maior prioridade, não apresenta atrasos originados na indisponibilidade de recursos, e, conseqüentemente, não requer um BC na sua frente. Esse comportamento se mantém para cada probabilidade de atraso testada.

Contrariamente ao P1, os projetos P2 e P3 apresentam um consumo crescente do BP, à medida que se aumenta os BCs. Esses projetos, por compartilharem recursos com o projeto P1, e entre eles mesmos, se beneficiam da proteção dos BCs. Contudo, dimensionar ambos os BCs com o mesmo percentual da capacidade do recurso gargalo origina diferenças importantes entre as curvas de consumo do BP2 e do BP3. O rápido crescimento do BP2 dá indícios de que os diferentes tamanhos de BCs inseridos, não cumprem a esperada função mitigadora de atrasos nas datas prometidas, pois acarretam o rápido consumo do BP2 causado unicamente pelo espaçamento criado pela inserção do BC1 e não por causa de atrasos reais. Tal comportamento indica que o projeto P2 tem pouca necessidade de segurança adicional. O projeto P3 só atinge esse comportamento com a inserção de BCs dimensionados com porcentagens grandes, indicando que existe a necessidade importante de adicionar proteção no projeto.

A análise conjunta dos três projetos do sistema expõe a existência de diferentes necessidades de segurança entre eles, dando indícios do comportamento particular que cada um dos projetos tem ante as inserções dos BCs. O entendimento de tais particularidades é mais bem observado se focalizarmos nos atrasos originados pela indisponibilidade de recursos

Cons

umo

BP


Atrasos originados pela indisponibilidade de recursos.Esta análise avalia os projetos P2 e P3 separadamente, visando identificar e entender os

efeitos de mitigação de atrasos que os BC2 e BC3 têm nos respectivos projetos. Para tal fim, comparamos, para cada tamanho do BC testado, os “atrasos devidos à falta de recurso”, os “atrasos reais do projeto” (quando o BP é ultrapassado) e o “incremento do makespan” que a inserção do BC causa. Para cada projeto são ilustrados os dois tamanhos de BC mais relevantes para apontar os diferentes efeitos que o mesmo método de dimensionamento tem em ambos os projetos. As comparações são feitas com valores percentuais para facilitar o entendimento do impacto nos projetos.

-10

0

10

20

30

40

50

60


%

Incremento makespan Atrasos por falta de recurso Atraso efetivo do P2

Imagem 4: Efeito do BC no makespan e nos atrasos do P2 (25% de prob. de atraso do projeto)

-20

-10

0

10

20

30

40

50

60


%



Os gráficos da Imagem 4 e da Imagem 5 referentes ao projeto P2 mostram uma relação

linear ascendente entre os incrementos de tamanho no BC2 e o aumento do makespan do projeto. Todavia no caso em que a probabilidade de atraso do projeto è estabelecida no valor mais alto (25%) e o projeto não conta com a proteção de nenhum BC (tamanho nulo), o atraso efetivo do projeto é ínfimo. Atrasos do projeto com valores negativos (ou términos do projeto adiantados) são atingidos com BCs aproximados a 20% da capacidade do recurso. Repare-se, também, que os atrasos devido à falta de recurso são mitigados em maior proporção pelo BP2. Este comportamento corrobora que as características do projeto P2, em função do grau de incerteza dependente do projeto antecessor em prioridade (projeto P1), fazem que a necessidade de inserir


um BC seja mínima em cenários pessimistas e nula em cenários otimistas (probabilidade de atraso menores a 15%). Inserções de BCs de tamanhos maiores a 20% em cenários pessimistas e tamanhos maiores a 0% em cenários otimistas, significariam um adiamento desnecessário na definição da data de entrega, e, conseqüentemente, a perda de competitividade do projeto frente à concorrência.

Ainda que o projeto P3 seja executado nos mesmos cenários dos projetos anteriores, este necessita da inserção de um BC de maior tamanho que o proteja das incertezas dos projetos que o antecedem em prioridade (P1 e P2). A diferença do projeto P2, para cenários pessimistas o projeto P3(Imagem 6 e Imagem 7) atinge a maior eficiência de mitigação de atrasos por falta de recurso com BC dimensionados em aproximadamente 35%. Para cenários otimistas, o tamanho de BC necessário diminui proporcionalmente com o nível de risco considerado, sendo preciso manter um BC de tamanho mínimo aproximado de 10% para o cenário mais otimista.

Observa-se que o dimensionamento dos BC está diretamente relacionado com o nível de incerteza dos projetos. É assim que, pequenas probabilidades de atraso nos projetos permitem que os BPs absorvam melhor os atrasos devidos á falta de recursos e, conseqüentemente, seja menor a necessidade de inserir BCs no programa. Embora tal comportamento seja comum em ambos os projetos, a relação de interdependências e as particularidades de cada um deles fazem que para uma mesma probabilidade de atraso, o tamanho do BC mais eficiente para cada projeto seja diferente.

-10

0

10

20

30

40


%



-20

-10

0

10

20

30

40


%




5. Conclusão e perspectivas de pesquisaA partir do estudo da metodologia CC/BM para múltiplos projetos, o presente artigo mostrar

efeitos importantes que a inserção e o dimensionamento dos BCs têm sobre a programação do conjunto de projetos simultâneos e sobre cada um dos projetos que o compõem.

Os BCs têm a finalidade de absorver os atrasos originados pela indisponibilidade de recursos, evitando que atrasos nas atividades de um projeto causem atrasos nas atividades de projetos subseqüentes, trazendo estabilidade na gestão dos múltiplos projetos a traves do isolamento de cada projeto. Isso só é possível mediante o aumento da duração (makespan) dos projetos, e, conseqüentemente, o aumento do risco de perder a competitividade dos mesmos por apresentar prazos de entrega maiores que a concorrência. O método mais utilizado no dimensionamento de BCs estabelece como regra geral para todos os buffers presentes no programa, que o espaço de tempo adequado para alocar entre cada par de projetos consecutivos é igual a 25% da capacidade do recurso gargalo.

Mediante a simulação probabilística da etapa de execução do conjunto de projetos, o artigo mostra que o ordenamento prioritário dos projetos faz com que os projetos menos prioritários sejam afetados pelas incertezas próprias e por aquelas originadas nas interdependências com os projetos predecessores. Nesse sentido, utilizar a mesma porcentagem para dimensionar todos os BCs do conjunto de projetos, pode prejudicar o desempenho de mais de um dos projetos, já seja por deixá-lo desprotegido ou por deslocá-lo mais do necessário sacrificando sua competitividade.

As análises feitas sugerem que dados os propósitos dos BCs e as incertezas presentes nas durações das atividades, seu dimensionamento depende das interações entre as atividades de cada projeto, do recurso gargalo, das interdependências entre os projetos do sistema e da proteção que se deseja contra atraso na entrega de cada projeto

Seria interessante a verificação dos resultados apresentados a partir de abordagens analíticas que reúnam uma grande amostra de casos práticos com características estatisticamente controladas.

Da mesma maneira, o estudo pode ser continuado mediante a aplicação de heurísticas evolucionarias que permitam modelar o comportamento dos BC em função das interações entre as atividades de cada projeto, do recurso gargalo, das interdependências entre os projetos do sistema e da proteção que se deseja contra atraso na entrega de cada projeto. Assim mesmo, é necessário explorar a utilização de métodos estatísticos que permitam modelar a natureza das incertezas que interagem no sistema.

6. Bibliografia.

Anavi-Isakow, S.; Golany, B. Managing multi-project environments through constant work-in-process. International Journal Of Project Management, v. 21, n. 1, p. 9-18, 2003.

Cohen, I.; Mandelbaum, A.; Shtub, A. Multi-project scheduling and control: a process-based comparative study of the critical chain methodology and some alternatives. Project Management Journal, v. 35, n. 2, p. 39, 2004.

Chen, C. S. Concurrent engineer-to-order operation in the manufacturing engineering contracting industries. Int. Industrial And Systems Engineering, v. 1, n. 1/2, 2006.

Hans, E. W.; Herroelen, W.; Leus, R.; Wullink, G. A hierarchical approach to multi-project planning under uncertainty. Omega, v. 35, n. 5, p. 563-577, 2007.

Herroelen, W.; Leus, R. On the merits and pitfalls of critical chain scheduling. Journal Of Operations Management, v. 19, n. 5, p. 559-577, 2001.


Herroelen, W.; Leus, R.; Demeulemeester, E. Critical chain project scheduling: do not oversimplify. Project Management Journal, v. 33, n. 4, p. 48, 2002.

Jyh-bin, Y. How the critical chain scheduling method is working for construction. Cost Engineering, v. 49, n. 4, p. 25, 2007.

Jersti, H.; Taylor, S. G. Quantifying buffers for project schedules. Production And Inventory Management Journal, v. 40, n. 2, p. 43, 1999.

Kolisch, R. Resource allocation capabilities of commercial project management software packages. Interfaces, v. 29, n. 4, p. 19, 1999.

Kurtulus, I.; Davis, E. W. Multi-project scheduling: categorization of heuristic rules performance. Management Science, v. 28, n. 2, p. 161, 1982.

Leach, L. P. Critical Chain Project Management. Artech house, inc., 2005.

Newbold, R. C. Project Management in the Fast Lane: Applying the Theory of Constraints. Boca raton, fl: crc press taylor & francis group, llc, 1998. (the st. Lucie press/apics series on constraints management).

Pritsker B., A. A.; Watters, L. J.; Wolfe, P. M. Multiproject scheduling with limited resources: a zero-one programming approach. Management Science, v. 16, n. 1, set. 1969 1969.

Rand, G. K. Critical chain: the theory of constraits applied to project management. International Journal Of Operations & Production Management, v. 18, p. 173 - 177, 2000.

Raz, T.; Barnes, R.; Dvir, D. A critical look at critical chain project management. Project Management Journal, v. 34, n. 4, p. 24, 2003.

Rozenes, S.; Vitner, G.; Spraggett, S. Project control: literature review. Project Management Journal, v. 37, n. 4, p. 5, 2006.

Steyn, H. Project management applications of the theory of constraints beyond critical chain scheduling. International Journal Of Project Management, v. 20, n. 1, p. 75-80, 2002.


gestão de múltiplos projetos por meio da metodologia da … · gestão de múltiplos projetos por...

Documents