Prova Real: Reduzindo a duração de projeto ao atuar em atividade SEM folga Zero

(a respeito de CPM, Folga Zero e conceitos que podem obscurecer nossa gestão)
__________________________________________________________________________________

 

     Aprendemos nas boas escolas de GP que não adianta atuar em atividade não crítica para reduzir seu tempo se o nosso objetivo é reduzir o tempo de um projeto.

     No jargão CPM, se reduzirmos o tempo de uma atividade que não tenha folga zero, ela não terá nenhum efeito sobre a redução do tamanho total do projeto.

 

ERRADO!
Crashing – ou compreensão de cronograma – pode ser feito também quando atuamos em atividades não críticas.

 

EXEMPLO:
     - Temos escavadeiras em um trecho que são utilizadas para preparar valas para a colocação de tubulação; estas escavadeiras também tem um gancho que lhes permite serem usadas para realizar o abaixamento dos tubos embora com menor produtividade que os side-booms que são equipamentos especializados para este abaixamento, logo são mais rápidos na realização destas tarefas.

     - Em um dado projeto, temos duas frentes de trabalho: uma frente está auxiliando a finalização de certos ajustes no trecho para a colocação de meio-fio, postes, entre outros; esta frente de trabalho não está no caminho crítico.

     - A segunda frente de trabalho está atrasada e tem como meta cumprir 2000 metros de abaixamento de tubos; esta equipe conta com uma escavadeira e um side-boom e embora o side-boom seja mais rápido que uma escavadeira na hora de baixar tubos, a escavadeira abre valas em um ritmo mais rápido que o side-boom segue na sequência para fazer o abaixamento; falta também apoio de mão de obra (ajudantes) para apoiar as operações com ambas as máquinas e com isso aumentar a produtividade da equipe, que define o tamanho do projeto por estar no caminho crítico.

     - Se aplicarmos SOMENTE TEORIA, vamos trabalhar com a noção de que só adianta atuar sobre atividades críticas – logo aquelas de folga zero – para conseguir realizar a meta de 2000 metros em 4 dias ao invés dos 5 dias previstos.

     - No entanto, o SENSO COMUM e a experiência em campo de muitos técnicos, planejadores, ajudantes e operadores de máquina já nos dizem que se de alguma forma eu atuar reduzindo o tempo das atividades no caminho não-crítico e com isso liberando antecipadamente a escavadeira que está naquela equipe e também alguns ajudantes, eu terei condições de também atuar em fast-tracking (paralelismo) na frente de trabalho que está no caminho crítico.

 

     Resultado: Além de aumentar as horas extras do operador do side-boom para ele tentar compensar com um dia mais longo a produtividade que lhe falta para alcançar a produtividade da escavadeira que está abrindo as valas à sua frente, o gestor pode também aumentar as horas extras do operador da escavadeira da OUTRA equipe (que não está no caminho crítico) e com isso entregando o resultado da outra frente de serviço ainda mais rápido do que o planejado (Crashing em atividade não crítica). Uma vez entregue o primeiro conjunto de atividades não críticas (que adeptos da Corrente Crítica talvez não tivessem decidido por esta abordagem por terem como princípio deixar para mais tarde toda atividade não crítica), agora temos recursos extras para criar uma nova frente de serviço para ampliar a produtividade no abaixamento dos tubos, utilizando a segunda escavadeira em conjunto com o side-boom.

     ”Puristas CPM” já me disseram, para este meu exemplo, que o que eu fiz na realidade foi encontrar um meio de ter os recursos extras necessários para o fast-tracking do caminho crítico e por isso a regra de que o projeto só se reduz quando atuamos sobre o caminho crítico e que apenas arranjei um pretexto para trazer de outra frente do projeto algo que eu deveria de qualquer forma trazer para as atividades principais.

     NO ENTANTO, o que temos que lembrar aqui é o princípio da coisa: Não importa se estou falando de economizar recursos humano, máquina, dinheiro ou tempo em uma frente de serviço para então ter a disponibilidade destes mesmos recursos (que são limitados) para atuar sobre o caminho crítico e para isso eu preciso “ter a cabeça aberta” para atuar sobre atividades NÃO CRÍTICAS antes de poder atuar onde realmente importa.

 

Quebra-se aí então dois paradigmas:
1) Não se deve só olhar o caminho crítico como forma de reduzir o tempo em um projeto;
2) A atividade “CPM FOLGA >0″ pode ser tão crítica quanto a “CPM FOLGA = 0″, pois se eu não tiver discernimento para agir sobre ela, não terei os recursos necessários para realizar o que desejo sobre o “Caminho Crítico Oficial”.

E reforçamos ainda outro entendimento:
- Cronogramas SEM ANÁLISE DE RECURSOS são melhor que cronograma nenhum, mas estão longe de ser o que melhor poderíamos oferecer aos nossos clientes e patrocinadores! Como planejadores, temos que ultrapassar barreiras culturais e conseguir fazer mais do que os heróis de antigamente, que resolviam tudo na força e no papel e caneta…

Qual é o C+C do seu projeto? (Caminho + Crítico)
- O que tem folga zero? ou
- O que lhe dá possibilidades de cumprir seu objetivo para com o seu cliente?

 

Tudo tem o seu tempo, mas o tempo do CPM acabou.
Vivemos em uma era onde deve prevalecer o bom uso de nossos recursos.

 

Peter.
(publicado originalmente na E-Plan, na mesma data)

_____________________________________________

** Retorno na Lista **

— Em planejamento@…, “Farhad” <farhad@…> escreveu

 

      Bravo Peter,
      Você consegue se superar!
      Você monta um cenário absurdo (fazer crashing na atividade não crítica) e depois você mesmo derruba o argumento “que o que eu fiz na realidade foi encontrar um meio de ter os recursos extras necessários para o fast-tracking do caminho crítico e por isso a regra de que o projeto só e reduz quando atuamos sobre o caminho crítico e que apenas arranjei um pretexto para trazer de outra frente do projeto algo que eu deveria de qualquer forma trazer para as atividades principais.”

     Impressionante a sua obstinência de não achar erro de lógica na sua própria argumentação! Você não precisa de contraditório, é o reu e promotor ao mesmo tempo! And the prosecutor rest his case!

 

Farhad

 
________________________________________________________________________

** Comentário do autor **

 

Farhad,

Capacidade de abstrair?

     O exemplo que eu dei apareceu durante o desenvolvimento de um cronograma baseado em recursos, onde estávamos simulando situações de melhoria de tempo de projeto com a colocação de novos recursos.

     Enquanto estávamos voltados só para o problema principal (o caminho crítico que todo mundo fala), não adiantava tentar movimentar os recursos já disponíveis e precisávamos trazer NOVOS recursos.

     A premissa, de que era necessário CRASHING no caminho principal não serviu.

     A opção de FAST-TRACKING não parecia possível, pois não tínhamos como criar
atividades paralelas com a mesma equipe restrita.

 

*** Precisamos então ABSTRAIR:

- Crashing PODE ser feito FORA DO CAMINHO CRÍTICO;
- Este Crashing LIBERA NOVOS RECURSOS;
- Estes recursos PODEM ser utilizados em Fast-Tracking;
- Fast-Tracking RESOLVE o problema no Caminho Crítico

 

     E quem ficar preso SOMENTE nos conceitos básicos, não poderá desenvolver cenários de planejamento para soluções que vão além das premissas ensinadas nos cursos em geral.

Não concorda? Não use.

Abraço,

 

Peter.

Método da Corrente Crítica e CPM

CCM – Critical Chain Method: Método da Corrente Crítica
CPM – Critical Path Method: Método do Caminho Crítico

 

      Na ilustração abaixo temos uma mesma rede de atividades vista sob a perspectiva da aplicação do CCM e do CPM (CCM também é conhecida por CCPM, ou Critical Chain Project Management).

Diagram de Rede de um Projeto

Diagram de Rede de um Projeto

 

     Após a identificação do Caminho Crítico, determinado pela sequência lógica entre as atividades, para o Método da Corrente Crítica, ainda é necessário:

     1) Verificar qual é o caminho crítico em função de restrições de recursos (o que seria a corrente crítica própriamente dita);

     2) Reduzir os tempos individuais de cada atividade sob o preceito de que todas as atividades sempre carregam com si proteções individuais que devem ser levadas ao projeto;

     3) Transferir parte das reservas “colhidas das atividades individuais” para as reservas do projeto, transferindo assim o que se protegia individualmente para o “controle do projeto”, através da administração de um “buffer de projeto”.

      A ilustração abaixo é o mesmo conjunto de atividades do diagrama de rede anterior, agora com o registro das durações individuais (originais) em sua representação como um Diagrama de Gantt.

Diagrama de Gantt (CPM)

Diagrama de Gantt (CPM)

     É possível identificar neste Diagrama de Gantt que a “Atividade 2″ é a única que não está no caminho crítico do projeto e ela tem uma folga livre (deslocamento potencial sem prejuízo do início da próxima atividade) e uma folga total (deslocamento potencial sem alterar a data de término do projeto) de 104 horas.

     O Caminho Crítico Total tem 224 horas, representados pelas atividades 3 (80 horas), 4 (80 horas) e 5 (64 horas).

     Apenas em caráter ilustrativo, vamos imaginar que exatamente as mesmas atividades estariam determinando a Corrente Crítica do Projeto (o que significa dizer que mesmo após nivelado o cronograma CPM pelos recursos, somente a atividade 2 permaneceria fora da corrente crítica).

     Vamos somar agora 4 elementos ao Diagrama de Redes original:

A) Um “feeding buffer”, que é uma reserva que se cria para a sequência de atividades em que se retirou reservas individuais e que não pertence a Corrente Crítica;

B) Um “project buffer”, que é uma reserva que se cria na Corrente Crítica “devolvendo” para o projeto uma parte das reservas individuais que se retirou de cada atividade;

C) Um “término sem buffer”, que é um marco que registra o término do projeto entre a atividade de início e a última tarefa da Corrente Crítica, sem considerar o “Project Buffer”

D) Um “término com buffer”, que é o marco final do projeto identificando o último momento possível de realização do projeto conforme o seu planejamento CCM original (que equivale a corrente crítica + project buffer)

Diagrama de Rede (CCM)

Diagrama de Rede (CCM)

      Nota: O Diagrama de Redes acima seria diferente com a aplicação do MS-Project e outras ferramentas que não possuem atividades do tipo “hammock”.  Neste caso, no MSP teríamos uma ligação TI do “Término” para o “Project Buffer” e outra ligação TI do “Project Buffer” para o “Término com Buffer”.

     A vantagem de utilizarmos uma hammock na representação acima é que a atividade “hammock” se reduz “automaticamente” na medida em que outras atividades na corrente critica tem uma duração maior que a planejada, de tal forma com que esta “hammock” serve para calcularmos o “consumo das reservas”, sem precisarmos ajustar manualmente (ou usando um plug-in) a duração remanescente do pulmão (buffer) a cada vez que alguma tarefa consome a reserva.

     (no exemplo acima, o “feeding buffer” também deveria ser modelado com o uso de uma hammock para uma aplicação efetiva do controle sobre pulmões, mas o princípio é o mesmo do “project buffer” já ilustrado).

 

Criando os Buffers (Pulmões)

     A forma com que se criam os pulmões e se decide pela retirada das reservas individuais de cada tarefa é o calcanhar de aquiles do método, pois não há exatamente um consenso sobre a forma com que se localiza “proteções individuais de cada atividade” para que sejam retiradas e levadas para o controle do projeto.

     Diversos usuários poderão determinar o tamanho “não-conservador” (sem proteções) de uma atividade utilizando um mecanismo com 3 estimativas (pessimista, otimista, mais provável), ou usando médias históricas da empresa ou discutindo com a equipe.

     Usuários mais “puros” do Método irão aplicar a regra 50 x 50, onde independente da atividade, iremos retirar 50% da duração de todas as atividades para que elas se tornem desafiadoras para a equipe e devolveremos ao pulmão do projeto 50% destas reservas.

     Utilizando uma abordagem “purista”, então temos:

Atividade 2 = de 40 horas para 20 horas;
Atividade 3 = de 80 horas para 40 horas;
Atividade 4 = de 80 horas para 40 horas;
Atividade 5 = de 64 horas para 32 horas;

      Feeding Buffer: O “pulmão” das redes secundárias é colocado no ponto uma atividade fora da corrente crítica se “encontra” com a corrente principal. O “Feeding Buffer” protege então aquela parte da rede sem “danos” a corrente principal até que o “Feeding buffer” se esgote.

     O Feeding Buffer neste projeto foi colocado entre a atividade 2 e 3 e devolve à equipe 50% da reserva retirada. Das 20 horas retiradas da atividade 2, temos o “retorno” ao projeto de 10 horas neste “Feeding Buffer” ou Pulmão de Convergência.

     Project Buffer: O “pulmão do projeto” recebe 50% dos temos retirados da Corrente Crítica, ou seja:50% de 40 horas da atividade 3 + 50% de 40 horas da atividade 4 + 50% de 32 horas da atividade 5. O Pulmão do Projeto tem assim uma duração de 56 horas.

     A seguir temos o Diagrama Gantt do mesmo cronograma original, agora com os tempos, reservas e complementos do Método da Corrente Crítica.

Diagrama de Gantt (CCM)

Diagrama de Gantt (CCM)

 Curiosidade:
- No CCM,  as atividades são colocadas em ALAP (As Late as Possible) para que sejam realizadas no momento mais tardio possível em um projeto. Por esta razão, a atividade 2 (que antes tinha uma folga de 104 horas) agora está agendada para acontecer 30 horas antes da atividade 3 (20 horas previstas para a própria atividade + 10 horas de reserva).

- Embora a aplicação de algumas atividades em ALAP possa ser interessante (pois se posterga a necessidade de atenção do gerente às atividades secundárias e também se deixa para mais tarde o investimento/custo da mesma), deve-se ter muito cuidado com esta abordagem pois estamos agregando um risco desnecessário a esta tarefa para que ela interfira no desempenho geral do projeto! Se a duração original dela era 40 horas e ela era secundária, por que arriscar realizá-la em 30 horas no último instante possível e eventualmente ter que consumir o pulmão do projeto, deslocando a atividade 3 que está na corrente crítica?

 

** O Arquivo deste exemplo está disponível em:

     http://www.thespiderteam.com/download/sprj/exemplo_ccm.001.sprj

** Para abrir o arquivo, instale gratuitamente o Spider CPM:

     http://www.thespiderteam.com/blog/licenciamento

 

 Observações finais

- Percebe-se que o cronograma final em CCM é 25% menor que o cronograma CPM e por isso é visto como um cronograma desafiador; outros métodos com a aplicação de Corrente Crítica e mesmo com o uso de pulmões também estão disponíveis.

- O SDPM (Success Driven Project Management) é um método que utiliza o nivelamento de recursos (Resource Critical Path) para estabelecer o caminho crítico do projeto (o que eles chamavam de “true critical path”). O RCP é – pela própria definição do PMBOK 4a edição (página 155) o equivalente a Corrente Crítica (Caminho Crítico do Projeto Alterado pelas Restrições de Recursos). Não se deve confundir o “conceito de corrente crítica” com o “Método da Corrente Crítica” (O método exige a identificação da corrente crítica e depois o levantamento das reservas e criação dos pulmões, entre outras coisas).

- O SDPM, que também é “um método” de Corrente Crítica, desenvolve os seus lastros virtuais (similares aos pulmões) a partir do uso de estimativas em três cenários e simulações de risco de projeto; o lastro em SDPM não fica preso a corrente crítica e é controlado a partir dos indicadores de probabilidade de sucesso em substituição ao controle sobre os pulmões de CCM.

Resultado comparado (CPM x CCM)

Gantt do mesmo projeto em uma visão CPM e CCM

Gantt do mesmo projeto em uma visão CPM e CCM

[E-Plan] – Disponível o Spider SCPM para download

(cópia de e-mail publicado na E-Plan em 09/02/2012)
___________________________________________________

 

O Spider CPM será o novo substituto do MS-Project nos projetos do dia-a-dia!

100% gratuito;
“100″ limite de tamanho para os projetos;
“100″ limite de campos do usuário (texto, numérico, datas)
“100″ erro em cálculos financeiros

 

     Use sinais e fórmulas simples relacionando campos do usuário e traga tabelas inteiras de controle de produção, chegada de materiais, emissão de notas fiscais, controle de time-sheets, registro de entregas para o cliente e dezenas de outras atividades em projetos nas áreas de Construção Civil, Montagem Mecânica, Desenvolvimento de Software e etc.

     Gere curvas-S imediatamente, demonstrando avanços entre o previsto x realizado; Utilize Valor Agregado sem erro de fórmulas e contas como a concorrência; Utilize recursos avançados em CPM para a identificação de atividades para crashing ou fast-tracking em projetos; Veja o caminho crítico de projetos; encontre folgas livres e totais sem complicação.

 

** Encontrou um BUG? **

     Conheça o melhor suporte tecnológico em um produto disponível no mercado! A Spider Management Technologies atende “bug fixes” com um tempo médio inferior a 10 dias, garantindo assim que o seu software realiza as funções que se presta a realizar, sem você ter que esperar aquele super lançamento da versão 2015, ou 2020…

     NOTA: A garantia de software livre de bugs é mantida para os usuários de versões pagas, apesar deles buscarem imediatamente a resolução de qualquer problema encontrado também em versões gratuitas. Esta observação é apenas por que a Spider se reserva ao direito de não atender o usuário gratuito com a mesma
presteza de um usuário pago, mas eu aposto minhas Certificações PMI que se você se deparar com qualquer bug, vai ver sua solução MUITO antes do próximo PACK Microsoft!

 

*** POR QUE é GRÁTIS ? ***

1) Vladimir Liberzon, arquiteto do Software e Presidente da empresa, tem no Spider uma criação para garantir a execução de suas atividades como Gerente de Projetos e não para ganhar dinheiro… Os mais de 50.000 usuários pagantes nos países da extinta União Soviética já lhe garantem os proventos que necessita
para ele e suas próximas gerações.

2) Porque em algum momento você vai entender que CPM (Critical Path Method) é uma metodologia incompleta e com grandes deficiências e aí você vai decidir utilizar o Spider Professional que faz o melhor nivelamento de recursos do mundo!

3) Porque em algum momento você vai ver que as concepções de Portfólio das soluções americanas (HP, IBM, EPM, Clarity, Primavera, etc) são incompletas e com grandes deficiências e aí você vai decidir utilizar o Spider Professional para unir os projetos de sua empresa em um grande painel de controle onde recursos compartilhados podem ser nivelados, controlados geridos no âmbito do Portfólio, permitindo a simulação antecipada de novos empreendimentos em sua carteira.

4) Porque nós do Brasil sabemos que você já está viciado no MSProject e aprendeu a tocar aquele violão com uma cópia pirata, ou de um amigo, ou aquela licença meio utilizada em várias máquinas de sua empresa e nós queremos que você tenha a oportunidade de aprender um novo software com a possibilidade de utilizá-lo
profissionalmente em sua empresa mesmo que ela não tenha como investir $$ em tecnologia.

 

*****
AJUDE A DIVULGAR!
O SPIDER fornece soluções gratuitas que já estão em uso em dezenas de projetos desde 2008 e os objetivos do The Spider Team vão muito além dos objetivos mercadológicos da concorrência! Nós queremos debate, aprendizado, melhoria…
Participe desta aventura conosco e ADOTE UMA ARANHA
*****

 

www.thespiderteam.com/licenciamento
(cadastro, download e uso do software SCPM gratuitos)

 

     Clique no “EU GOSTEI” em nossa página para o Facebook e nos ajude a incrementar a teia da aranha! Assista vídeos e apresentações sobre temas educacionais na área de projetos e mande sua sugestão dos assuntos que quer aprender, ensinar ou debater com nossa equipe!

 

Precursores da Aranha no Brasil:
- Jefferson Guimarães, primeiro usuário pagante do Brasil!
- Alexinaldo Alves, primeiro usuário brasileiro a exportar o Spider para a
Bolívia!
- Peter Mello, primeiro brasileiro a receber um treinamento pelos Russos!
- Marcus Possi, primeiro autor de livros sobre o Spider no Brasil, já publicado
em 4 edições e em inglês e Português!

     Junte-se a estes e a pelo menos outros 500 usuários do Spider no Brasil.

 

     No máximo o que pode acontecer é a Microsoft ficar VERDE de inveja ou ciúme e decidir dar o suporte ao seu produto que nós usuários e ex-usuários de versões pagas deste software esperamos por tantos e tantos e tantos anos!!

 

—-
Aviso legal: As opiniões, convites, declarações, especificações e comentários
deste e-mail são a opinião pessoal de Peter Berndt de Souza Mello e não
correspondem à declarações e afirmações da Spider Management Technologies. Nesta
lista de discussão, convido todos a fazer sua própria interpretação crítica do
que é ou não é surpreendente sobre o Spider Project.

Uma provocação para o Caminho Crítico (2012)

     Apesar deste ser o quinto conjunto de slides para quem estiver se aventurando pelo Spider CPM, estes slides abordam somente a questão teórica (e prática) das folgas e definições de Caminho Crítico, sem uma abordagem específica para a ferramenta Spider.

     Já parou para pensar que a “sua folga” (de fim-de-semana) não é folga no caminho crítico? Veja os slides e deixe o seu comentário!

 

Peter.

A Nova Revolução Russa (Spider SCPM)

     Prezados,

     Não canso de me surpreender com o Marcus Possi, agora já companheiro de algum tempo em nossas aventuras e desaventuras com o Spider Project.

     Ontem (pela noite, visto que agora já é madrugada), perguntei a ele se valeria a pena pedir aos russos que colocassem um link no SCPM que levase a um site tipo moodle específico onde pudéssemos trabalhar o tema SPIDER para a nova comunidade que esperamos formar.

     Algumas horas depois, já temos o Moodle no ar com o boneco do SpiderProject – CPM disponível para eu inaugurar este fórum…

     Bom, há tempos eu e o Marcus Possi (e em breve apresentaremos alguns outros) fomos picados e envenenados pela Aranha. Conseguimos provocar o russo Liberzon a lançar uma versão de uso gratuito – que já tem algumas centenas de usuários – mas que por sua quantidade limitada de atividades (Desk200) não virou a bola da vez.

     Este ano começamos com o lançamento do Spider CPM – uma versão sem limite de atividades e exclusiva para a aplicação do CPM (ou seja, não faz nivelamentos). Considerando que 9 em cada 10 usuários MS-Project que conheço não utilizam nivelamentos de recursos, o Spider CPM agora tem a chance de se tornar “a ferramenta” de mercado, criando assim uma comunidade de usuários que poderá utilizar este software para casa, escola ou trabalho com a certeza de que estará entrando em um mundo “sem bugs”.

     Embora nenhum desenvolvedor possa garantir soft sem bugs, a Spider tem orgulho de manter um suporte técnico que está pronto a lançar uma nova versão da ferramenta com algumas semanas após algum bug que possa comprometer o trabalho de alguém venha a ser encontrado.

     O Spider tem algumas peculiaridades que lhe são exclusivas e a grande curva de aprendizado está na sua interface “não Microsoft”. Mais do que nunca, vencer esta barreira pode ser uma oportunidade para crescimento profissional fora de série… Aceite este desafio e conheça a ponta do iceberg da melhor ferramenta de planejamento do mercado, líder na região em que nasceu (países da extinta União Soviética)!

 

Abraço,
Peter Mello, SpS, PMP, PMI-SP

Tarefa Hammock (Debate) – Parte II

Antes de continuar, algumas considerações:

1- Este material surgiu em função de um debate na lista da E-Plan.
2- Você pode visualizar a parte I do Debate (Clicando aqui)
3- Você pode saber mais sobre o tema abortado – Hammocks & Exemplos aplicados – (Clicando aqui)

___________________________________
Carta de Farhad Abdollahyan sobre Hammocks:

 

     Caro Peter,

     Para começar, no exemplo não sei de onde vem a Corrente Critica (30 dias)!!! E depois o 25 dias, dado que as atividades supostamente tinham 10 (C) e 20 dias (A, B e D) de duração!

     Dependendo da maneira que nivelarmos o projeto, passamos de 40 dias sem nivelamento para 50 ou 60 dias, dado que o caminho crítico sem nivelamento é Início-A-B-Fim. (0+20+20+0). Se colocarmos uma prioridade maior no C, o MS Project nivelará a atividade A e teremos:

“corrente crítica” = (C)Farhad 10 + (A) Farhad 20 + (B) Peter 20 = 50

Senão teremos

“corrente crítica” = (A) Farhad 20 + (B) Peter 20 + (D)Peter 20 = 60

     Em segundo lugar, creio que está cometendo um erro crasso de conceito e outro de entendimento do problema!

     Quando escreve que “Se eu prender uma atividade HAMMOCK em INICIO e FIM e colocar FARHAD e Peter como recurso utilizado nela” não faz menor sentido. Uma atividade “Hammock” ou “Summary Activity” é “um grupo de atividades do cronograma agregadas, relacionadas em algum nível de resumo e exibidas/relatadas como uma única atividade no nível de resumo”, em outras palavras, uma Hammock não é uma atividade de verdade, é apenas uma sumarizadora, portanto, não devemo alocar recurso nela diretamente.

     Para criar uma HAMMOCK, criamos um marco de início e um de fim e relacionamos logicamente as atividades desta sub-rede (ou sub-projeto) e temos uma hammock. No MS Project conseguimos este efeito criando uma indentação, e o SW demonstra uma barra preta variável (como você disse) cujo início tem uma relação início a início com a primeira atividade da rede e o seu ponto final tem uma relação término a término com a última (no seu exemplo “início” e “Fim” respectivamente).

     De certa forma, representa o pacote de trabalho.

     O outro erro seu é que recomenda uma atividade sumarizadora para o colega que tem dois grupos de atividades distintas:

     (1) Atividades que irão produzir as entregas propriamente ditas, e (2) Atividades de fiscalização e apoio que não geram entregas tangíveis.

     Se indentar as atividades principais e criar a super guarda-chuva (HAMMOCK) não irá resolver o problema do colega, pois o que ele quer realmente é poder inserir atividades de fiscalização e apoio.

     E não se trata de questão de SW, pois para dizer a verdade, o MS Project até permite associar recurso a esta atividade sumarizadora (e calcularia os custos como o colega quer), mas este macete tem dois problemas: (a) MSP soma os custos das atividades de sub-rede com os custos dos recursos alocados diretamente na Hammock e mostra tudo no Hammock, isto pode confundir! (b) Da mesma forma que não é correto colocar predecessor ao nível da Hammock, não devemos também alocar recurso no Hammock.

Abraço,

Farhad

 

———————————————————————————————————
Peter Mello, em resposta a carta:

 

      Farhad,
      Meu erro foram as unidades. Eu comecei com a unidade DIA e depois coloquei o custo HORA. Onde eram 20 e 10 dias, eu fiz o exercício com 10 e 5 dias (portanto basta dividir os seus achados por 2 para acertar com meu erro de unidades).
O raciocínio está correto e os resultados (ajustados) também:
- seus 60 dias seriam os meus 30
- seus 50 dias seriam os meus 25.
- o valor hora é de fato R$ 1,25 (para dar os R$ 10,00 por dia que usei nas minhas contas)
No entanto:

      A) O MSProject precisa que você faça ajustes manuais durante o nivelamento para achar o melhor resultado. Se você tiver 4 ou 40 atividades, vai conseguir fazer a priorização correta e ter um bom retorno. Se tiver 400 ou 4000 atividades, não pode depender de priorizações manuais para encontrar o melhor nivelamento
      B) O MSProject não mostra a corrente crítica. Apenas coloca em vermelho os elementos pertencentes ao caminho crítico CPM e portanto todas as folgas não tem qualquer utilidade.
      Quanto aos usos da HAMMOCK:
      - A descrição da Hammock no Practice Standard of Scheduling nasceu DEPOIS das hammocks serem inventadas e aplicadas em diversos softwares. Não é por que o Practice Standar diz que a hammock só pode ser utilizada para A, B ou C que ela também não possa ser usada para D, E ou F. No entanto, a regra MÍNIMA estabelecida para uma hammock é que ela seja capaz de agregar durações provenientes das atividades que ela sumariza. No Standard, tarefa sumário e hammock são sinônimos, o que não é exato. A hammock se presta a sumarizar atividades que não estão em subitens da mesma decomposição da EAP, enquanto a tarefa sumário está sempre presa a estrutura hierárquica da decomposição.
      - Por estas “funções extras” da hammock que não estão no Practice Standard e nem no MSProject, mas estão no Primavera e no Spider é que a hammock se presta exatamente ao que o colega quer, durante sua análise de fiscalização.
     - Você sabia que durante o preparo do Practice Standard houve uma votação para ver se “cronograma nivelado por recurso” deveria entrar ou não no Standard? Como a base dos desenvolvedores é americana e eles usam CPM e prestam pouca atenção a CCPM ou qualquer método que faça nivelamento adequado de recursos, cronogramas baseados por recursos quase não foram contemplados no Practice Standard.
     - Se isso tivesse acontecido, isso iria fazer com que as pessoas que utilizam corrente crítica ou resource critical path deixassem de usar ? O standard não é prescritivo e sim descritivo.
Vou preparar um PDF com tudo, para você ver como funciona.

 

Abraços,
Peter.

[TOC] Mega projetos

Tópico:

- Troca de correspondências sobre megaprojetos encaminhada para à lista TOC –

 

Carta de Humberto Baptista
__________________________________________

 

—– Original Message —–
From: Humberto Baptista
To: toc-brasil@yahoogrupos.com.br
Sent: Friday, June 19, 2009 11:45 AM
Subject:[toc-brasil] TOC em mega projetos

 

     Olá Rômulo,

     O quanto você sabe sobre TOC?
     Com o risco de “chover no molhado”: você conhece o princípio de Pareto, certo? 80% dos fenômenos pode ser explicado por 20% das causas em uma coleção de eventos independentes. Agora se os eventos não são independentes a relação não é mais 80:20, mas em geral sobe para 99:1 ou mais ainda. Ou seja, quanto mais fortemente conectado um sistema menos causas impactam o sistema como um todo.
Imagine agora “mega projetos”: existem muitas relações entre as partes destes, tantas que às vezes a própria rede de projetos (que deveria ser uma visão simplificada da relidade) chega a ser incompreensível. Justamente por esta vasta quantidade de relacões de causa e efeito podemos ver que o número de causas (ou pontos de alavancagem) nestes sistemas é muito pequeno.
      A TOC fornece ferramentas para identificar os pontos de alavancagem (restrições) e gerenciar o sistema através deles.

 

Abraços,
Humberto

 

___________________________________
Peter Mello, em resposta ao debate:

 

     Humberto,

     Goldratt fala da “Simplicidade Inerente” e por isso defende projetos simplificados em até 300 atividades, não é isso?

     Creio que por isso você fala que uma rede “deveria ser uma visão simplificada da relidade”, certo?

      Este é um ponto fundamental de diferença entre a abordagem de Restrições desenvolvida por Goldratt e uma abordagem de Restrições desenvolvida com base ao RCP (Resource Critical Path) na Rússia.

      Depois de estar em um evento com Goldratt e ter participado do seu webcast (graças ao seu generoso convite junto com o Alonso), eu mais do que nunca acredito que este conceito “de manter simples” é um mecanismo de lidar com o problema mais amplo quando não se tem ferramentas adequadas para os cálculos em menor nível.

     Ou seja: Já que a rede fica grande e eu não sei o que fazer com ela, preciso simplificar a rede para poder fazer algo!

      No entanto, vivemos em um mundo de altíssimo avanço tecnológico e da mesma forma que um engenheiro faz desenhos eletrônicos usando CAD, podemos desenhar cronogramas detalhadíssimos, utilizando as melhores ferramentas da qualidade para entender o MENOR grão possível do projeto e – sem entender exatamente como o software faz – ter um resultado em um nível mais alto, em que eu ENXERGO e ENTENDO, algo que será melhor do que eu simplificar por conta própria.

      Ou seja: Eu acho que todos os conceitos de CCPM são aplicáveis em pequenos, médios e mega projetos, menos o conceito de redes simplificadas. Há centenas, se não milhares, de restrições que precisam ser trabalhadas nestes megaprojetos e para você focar nas mais importantes, precisa que “alguém mais” (ou o software) resolva boa parte das outras por você!

     PROJETOS SÃO DINÂMICOS. A instabilidade é muito mais comum neste ambiente do que na indústria, onde nasceu a TOC. Por esta razão, uma rede de projeto pode mudar drasticamente da noite para o dia simplesmente por que uma equipe de projeto não pode chegar ao local, ou um equipamento importante quebrou.

     Na indústria, uma máquina quebrada é tratada pelas reservas para as incertezas e logo que ela é reparada, a sequencia de atividades continua. Se o tempo quebrado for MENOR do que o buffer, a sequencia continua sem grandes prejuízos.

      Em um projeto, uma máquina quebrada não pode ser só tratada pelas reservas! A ausência da mesma pode determinar que um conjunto completamente novo de atividades precise ser executado, ou uma nova sequÊncia de uso dos recursos seja criada para lidar com a impossibilidade de trabalhar exatamente naquele segmento.

      SUPONHA que em meu projeto eu precise de uma PONTE para atividades subsequentes que será construída no próprio projeto. Em função da forma com que organizo as atividades baseado nos recursos possíveis, pode acontecer que eu programe para DEPOIS da ponte atividades que de fato poderiam ser feitas SEM ela, mas por falta de recursos eu primeiro planejei eles utilizados na PONTE e depois então nas atividades remanecentes.

      Em uma rede CCPM, eu vou colocar um buffer e minha sequência no caminho crítico fica IMUTÁVEL. Assim, se a PONTE sofre atrasos ou quebra, todas as atividades seguintes na mesma rede ficam aguardando a solução, enquanto o buffer vai sendo consumido. Em muitos casos, mesmo que o gerente possa atuar de forma distinta, como o CRONOGRAMA é simplificado, ele nem percebe as demais coisas que pode fazer enquanto espera a ponte (planejamento da rede com nível pequeno de detalhe).

      Em uma rede SDPM, eu não tenho o buffer “preso” a um único caminho e tenho detalhadamente TODAS as atividades que cada recurso pode efetuar. No momento em que a PONTE não está disponível, eu posso reprocessar todo o diagrama de redes e adiantar atividades que de fato não dependem da ponte enquanto o problema é resolvido.

     Portanto, meu alerta para o Rômulo é: Se não tem ferramenta adequada, use CCPM x CPM que você terá muitas vantagens. Se pode contar com ferramentas de otimização de cronograma, planeje em maior detalhe e utilize CCPM aliado a conceitos de SDPM, para lidar com as incertezas dos mega projetos!

Abraço,

 

Peter Mello, PMI-SP, PMP
The Spider Team

http://www.thespiderteam.com/sdpm