Pontos Fortes e Fracos:
CCPM e SDPM
(Peter Mello, peter.mello@x25.com.br, agosto/2009)
O presente conteúdo nasceu em um artigo intitulado “Pontos Fortes e Fracos do Método da Corrente Crítica”. A partir do debate com participantes de listas de discussão como TOC e E-PLAN, o conteúdo se estendeu por outros três artigos. Este documento reúne estes artigos e traz pequenas revisões.
Conteúdo
Primeira Parte – Introdução ...2
Perigo nos pulmões ...4
Cenário para exame ...4
Criando a Corrente Crítica...5
O problema ...5
Cronogramas menores sem cortes – Otimização da rede ...6
Resultados ...6
Alerta Vermelho ...7
Diversas soluções para uma mesma rede ...7
Parte II – Desenvolvendo o segundo artigo ...8
Complexidade & Micro-Gerenciamento ... 12
“Projetos muito detalhados” exigem equipes especializadas e cronogramas complexos. 12 “Projetos com muitas linhas são difíceis de gerenciar” ... 14
“Não posso fazer projetos grandes, pois entro em micro-gerenciamento” ... 14
De volta aos pulmões ... 15
Parte III – Uma introdução ao SDPM ... 17
Lastros – A “visão dos pulmões” sob a ótica de SDPM ... 20
E se as premissas estiverem erradas? ... 23
Parte IV – Aplicação dos métodos e o nivelamento de recursos ... 26
Nivelamentos otimizados ... 28
Pulmões x Lastros ... 28
Gerenciamento de Riscos – A visão integrada de SDPM ... 29
Diferenciando “chute” e “criação de cenários”... 30
Pontos fortes e fracos: SDPM & CCPM. ... 34
Ishikawa e Guimarães ... 35
Conteúdos relacionados ... 36
O Autor ... 36
Primeira Parte – Introdução
Este é um texto particularmente difícil de escrever de forma a manter os ânimos dos principais defensores do Método da Corrente Crítica sem trazer ares de competição e sim de complementação.
Um apelo que faço para os implementadores de CCPM (Critical Chain Project Management) é que façam uma viagem no tempo para lembrar como os usuários de CPM (Critical Path Method) resistiram (e muitos ainda irão resistir) a qualquer uma das idéias que vocês trouxeram a comunidade desde 1996 e com isso também abram suas mentes para avaliar como introduzir outras idéias ao que já realizam no seu dia- a-dia com o CCPM!
Em linhas gerais, o CCPM atravessou desafios incríveis em sua trajetória para promover a mudança e os resultados são fantásticos. No entanto, do mesmo modo em que o CCPM trouxe avanços em relação ao Método do Caminho Crítico, há outros pontos que também podem trazer avanços para o Método da Corrente Crítica!
A essência dos pontos que vou descrever a seguir está relacionada a outro método da corrente crítica que teve origem na Rússia ainda nas décadas de 60/70 e não com a Teoria das Restrições lançada pelo pai da Corrente Crítica, na década de 80, e inicialmente focada na Indústria.
Há quem veja os métodos como concorrentes. Eu trabalho com a idéia de serem complementares. Existem situações claras onde os conceitos do Método da Corrente Crítica são mais do que suficientes para trazer uma evolução no ambiente de projetos e há outras situações onde o método russo SDPM – Success Driven Project Management – está mais preparado a lidar com a complexidade das restrições que serão tratadas.
Um ponto forte do Método da Corrente Crítica está relacionado à sua origem e expertise do sr. Goldratt em relação as indústrias e o nascimento da Teoria das Restrições, bem como toda a trajetória de implementações do método até a publicação em 2007 das Árvores de Estratégias e Táticas (S&T). Meu sonho de consumo é aproximar as S&T do método russo, entre outros elementos.
A ampla aplicação do conceito de “Simplicidade Inerente” de Goldratt ao seu extremo onde reservas de projeto são rapidamente calculadas com a regra do 50x50 são para mim o calcanhar de Aquiles do Método. A insistência em se falar de “um gargalo” na corrente crítica e o seu escalonamento para garantir a execução do projeto, sem considerar uma multiplicidade de gargalos como faz o SDPM é outro problema.
De fato, sem o uso de um software ou apenas com plug-ins sobre plataformas que não são capazes de fazer bons nivelamentos de projetos, as técnicas do Método da Corrente Crítica são absolutamente sensacionais. Nestes cenários, manter projetos
com poucas linhas, focar em um gargalo, escalonar os demais recursos ao gargalo encontrado e proteger a rede com buffers é uma solução simples e genial.
Mas nós estamos em uma época onde da mesma forma que podemos aplicar softwares avançados para desenhos (CAD), também podemos aplicar softwares avançados para tratar cenários com múltiplos gargalos e com um conjunto de informações milhares de vezes mais amplos e complexos do que aqueles preconizados pelos implementadores do método! Está na hora de modelarmos computacionalmente os cronogramas, buscando a melhor resposta.
Por esta razão, temos que nos dar ao direito de buscar estimativas cada vez mais adequadas; temos que trabalhar a construção de cenários que de fato façam uma previsão do que pode dar certo e errado e temos que nivelar nossos cronogramas com toda e qualquer restrição que seja fato em nossos projetos, seja ela um problema de calendário de recurso, uma quantidade de pessoas ou máquinas necessárias, a falta de um material ou fluxo de caixa!
Ampliar a complexidade do que planejamos em um projeto não pode ser sinônimo de “romper com os preceitos do método”! Eu assisti pessoalmente a declaração do sr. Goldratt de que projetos precisam estar contidos em 300 linhas de planejamento e também vi ele defender que não há ganhos efetivos no detalhamento dos cortes que faremos nas durações das atividades e portanto basta uma regra simples e direta para tal.
Em contraposição a isso, temos quatro elementos essenciais do método Russo que são diferentes do Método da Corrente Crítica que eu priveligio em função de minha experiência profissional, de meus experimentos e da transparência dos resultados obtidos com o SDPM:
1) Projetos devem ser detalhados no menor grão a que tivermos acesso, buscando sempre identificar de fato os 6M (mão de obra, máquina, método, medição, material e meio ambiente);
2) Estimativas devem ser criadas com base a cenários (otimista, pessimista e provável), favorecendo um percentual de confiança negociado com os envolvidos e não através de uma regra simplificada de transferência de reservas das atividades para um pulmão;
3) Reservas devem pertencer a todo o projeto e não serem fixadas em uma única corrente crítica, pois as restrições de projeto são voláteis e novas correntes críticas podem surgir a cada dia de projeto;
4) O acompanhamento de reservas não pode ser feito com uma análise de penetração linear, considerando apenas o que se gastou e o que falta gastar sem analisar os cenários pessimistas e otimistas.
Infelizmente, quando faço a reunião destes elementos às dinâmicas de trabalho do Método da Corrente Crítica eu passo a ser visto como um “agressor” ou inimigo do método, quando de fato em cada tipo de projeto, dependendo da maturidade dos
um ou mais pontos relacionados acima poderiam ser mantidos em função dos conceitos básicos do método da corrente crítica.
Diversos autores relacionados as implementações de CCPM também já chegaram a propor alguns mecanismos básicos de SDPM (como a criação de cenários) e não foram vistos como divergentes ou inimigos pelo simples fato de que suas idéias começavam todas a partir de um vínculo histórico com a Teoria das Restrições.
Por outro lado, o SDPM não tem nenhum encontro histórico com a Teoria das Restrições. Seus achados e mecanismos de trabalho estão relacionados ao que se chama de “RCP – Resource Critical Path” ou “Caminho Crítico dos Recursos”. Este termo está voltado ao gerenciamento de projetos e vem sendo utilizado desde a década de 60 para qualquer algoritmo que aplicasse alterações no caminho crítico do projeto a partir do nivelamento de recursos sobre o caminho crítico original (seqüência de atividades no diagrama de redes com folga zero).
Assim como a aviação foi criada por esforços diferentes dos Irmãos Wright e de Santos Dumont, criando uma antipatia entre os defensores de cada uma das versões sobre a invenção do avião, SDPM e CCPM partiram de histórias diferentes e vieram tratar problemas similares, com abordagens também muito parecidas em alguns aspectos. Será que os seus diversos implementadores (tanto de SDPM como CCPM) precisam ficar defendendo particularidades de cada método ou podem desenvolver soluções integradas que aproveitem os pontos fortes de cada abordagem?
Perigo nos pulmões
Em ambos os métodos, nós temos a transferência de parte da duração de cada atividade para uma reserva sob administração do projeto. Algumas razões são comuns: A Lei de Parkson e a Síndrome do Estudante são fenômenos conhecidos que provocam o consumo de reservas localizadas em atividades. No entanto, enquanto as principais reservas calculadas pelo Método da Corrente Crítica irão se transformar no “pulmão do projeto” e proteger o projeto a partir de uma corrente crítica fixada, o SDPM irá manter um controle virtual sobre estas reservas através dos Índices de Probabilidade de Sucesso e com isso mantém a flexibilidade do cronograma para que seja readequado ao longo de todo o projeto, permitindo a alteração daquilo que entendemos como a corrente crítica.
Cenário para exame
O projeto inicial tem 36 dias de duração (A > B > C) e não está protegido por pulmões. Há outro caminho no projeto (D > E > C) que tem 30 dias de duração, tendo assim uma folga de seis dias.
Criando a Corrente Crítica
Após a colocação dos recursos, passamos a ter superalocações até que um nivelamento seja feito (área sinalizada no diagrama de redes, em função de José e Maria).
Como Maria não poderá realizar B e E na mesma data, a atividade E será postergada e empurrar C para frente. O mesmo ocorre entre as atividades A e D, a serem realizadas por João.
Executando este nivelamento na maioria dos softwares, o projeto passa a ter 48 dias ao invés dos 36 dias originais:
Sem entrarmos em discussão quanto à melhor forma de reduzir o tamanho das atividades e transferir parte da proteção para os pulmões, se aplicarmos a “regra 50 x 50”, teremos o seguinte cronograma:
Notas:
- A atividade D foi colocada em ALAP – o mais tarde possível – com a proteção de um pequeno pulmão de convergência, por esta razão, já não tem mais folga;
- A, B, E, C (corrente crítica) tinha antes 4 x 12 dias = 48. Após a aplicação do método, temos 4 x 6 dias = 24 dias e ainda + 12 dias de pulmão (50% dos 24 dias retirados de A,B,E,C).
O problema
- O uso dos pulmões e a colocação de atividades em ALAP podem mascarar outras opções de nivelamento de recursos. A proteção de uma parte da rede como
que há atrasos na corrente crítica) pode esconder outras opções de reorganização das atividades.
No exemplo acima, não há uma instrução específica (uma dependência obrigatória) que obrigue o projeto a começar pela atividade A.
Se invertermos a seqüência de atividades entre (A) e (D), temos um ganho de prazo, como podemos ver ao observarmos os dois cronogramas possíveis, a seguir.
Cronogramas menores sem cortes – Otimização da rede
O segundo cronograma é resultado de uma análise de otimização de resultados executada com o uso de um software especializado (Spider Project). Neste caso, a duração foi reduzida de 48 para 42 dias sem nenhuma aplicação de redução no tempo das atividades ou criação de pulmões.
Como resultado, todas as atividades nesta situação são críticas e se utilizarmos os pulmões, teremos um único pulmão de projeto protegendo todas as atividades (A,B,C,D e E).
Se voltarmos a aplicar a “Regra 50 x 50”, temos então neste caso:
Resultados
- No primeiro nivelamento, o projeto resultou em uma duração total de 36 dias após a aplicação do Método da Corrente Crítica. Há uma corrente secundária, com a atividade D e um pulmão de convergência.
1
2
- No segundo nivelamento, o projeto resultou em uma duração total de 32 dias.
Não existe uma corrente secundária ou pulmões de convergência, pois tanto (A>B) como (D>E) pertencem à corrente crítica.
Alerta Vermelho
Não apenas no início do projeto, onde ainda podemos identificar qual é a melhor alternativa de nivelamento antes de aplicar o método, mas a qualquer momento, podemos ter alternativas no seqüenciamento entre atividades que podem favorecer a realização do projeto em um tempo menor ou a um custo inferior.
A necessidade de alterarmos a seqüência entre atividades pode ser resultante de um acidente de percurso, uma mudança de uma máquina ou profissional, um atraso significativo em uma atividade secundária, entre outros.
Em uma rede “presa” por pulmões, nem mesmo algoritmos complexos e o uso de softwares sofisticados poderão encontrar as melhores alternativas de nivelamento de recursos em um projeto.
É importante destacar que em ambos os casos têm como origem o mesmo diagrama de redes e os mesmos recursos, respeitando as mesmas dependências obrigatórias. Ainda assim, o segundo cronograma tem uma duração total menor em função da otimização da seqüência de atividades.
Diversas soluções para uma mesma rede
Após o envio do primeiro artigo às listas, eu recebi alguns exemplos de nivelamentos feitos em outros softwares (além do Spider que utilizo para meus exemplos) que também encontraram como melhor opção o “segundo cronograma”, mais curto do que o primeiro.
Isso apenas reforça o fato de que durante o avanço do projeto, nosso diagrama de redes pode ser reorganizado em seqüenciamentos diferentes em função da disponibilidade ou falta de recursos e, portanto, não é “natural” preservar uma
“corrente crítica principal” através da aplicação dos pulmões.
É claro que em um projeto real, se um Gerente de Projetos tiver uma atividade da corrente crítica que - de um momento para o outro - não possa vir a ser realizada (em função da ausência de recursos humanos, máquinas ou financeiros), este gerente não ficará apenas “consumindo indefinitamente o pulmão”. É muito provável que ele faça uma reavaliação de todo o seu planejamento e procure transferir os recursos remanescentes para outras atividades – antes não críticas e nem planejadas – para que o projeto possa prosseguir enquanto aguarda a solução do problema que mantém aquela atividade parada.
A questão é: Por que esperar a incidência de um problema grave para rever a rede do projeto?
- Um “cronograma CPM” não pode ser “reorganizado” em função de alterações das restrições durante o percurso do projeto por que não “enxerga” recursos.
- Seu sucessor, o “cronograma CCPM”, também não pode ser “reorganizado” já que - apesar de ser “baseado em restrições de recursos” - o seqüenciamento agora está trancado por um conjunto de redes e sub-redes protegidas por pulmões de convergência e o pulmão do projeto.
Em função destas duas características é que mantenho o meu “favoritismo” ao conceito de “lastros de projeto” que são utilizados em SDPM. Estes lastros protegem o projeto de variações de forma similar aos pulmões de Goldratt, mas não “pertubam” a otimização do cronograma, pois estes lastros não são colocados “fisicamente” dentro do projeto, preservando à rede original e garantindo a flexibilidade necessária para encontrar novos seqüenciamentos entre atividades sempre que possível.
Os “lastros de projeto” serão apresentados nas seções seguintes deste documento. De forma resumida, os “lastros” são pulmões virtuais criados em um cronograma para agir diante de incertezas e riscos, mediante a construção de um cronograma probabilístico.
Parte II – Desenvolvendo o segundo artigo
Com o lançamento do primeiro artigo, hoje integrado a este conteúdo, recebi alguns comentários interessantes de pessoas envolvidas com a aplicação de CCPM.
Dentro do possível, os tópicos discutidos em função da correspondência trocada estão incluídos à seguir.
Na primeira parte, estabeleci um relacionamento entre a “simplicidade inerente”
e o planejamento em poucas linhas (cerca de 300, conforme palavras do sr. Goldratt em seu WebCast de CCPM, em 2008). Em um dos emails recebidos, me explicaram que nenhum projeto precisa ficar preso a uma pequena quantidade de atividades e que outras áreas envolvidas, fornecedores, equipes técnicas, entre outros poderão manter cronogramas complementares com maior detalhe de informações. O que deveria acontecer é que “somente sob a ótica de gestão e a aplicação dos pulmões” é que manteríamos as informações restritas às 300 linhas.
Em linhas gerais, a resposta não convence e permaneço fiel a dois conceitos encontrados em publicações do Project Management Institute (Practice Standard of Scheduling e “Standard of Work Breakdown Structure):
A) Devemos desenvolver um “Modelo de Cronograma” (no sentido de modelar a realidade) que seja completo o suficiente para atender a todos os envolvidos.
Este “modelo” então dá origem a diversos cronogramas para cumprir distinas funções. Entre os cronogramas possíveis, oriundos sempre de um “modelo completo”, temos os cronogramas de marcos, gerencial, de equipe, de entregas, etc.
B) Este “Modelo” (Schedule Module) deve ter as atividades detalhadas em um tamanho que se aproxime a dois ou três ciclos de medição, derivados de uma EAP cujos pacotes de trabalho de fato descrevam quem faz o quê, de qual forma, quando, por quanto e em quanto tempo.
O item (A) significa que mesmo que eu tenha uma visão gerencial resumida, ela deve ser derivada de uma visão detalhada e não uma “re-interpretação” das informações provenientes de outras áreas ou subprojetos.
O item (B) estabelece regras básicas para este detalhamento. Se minha capacidade de gerenciamento é de uma medição (monitoramento) a cada semana, então as atividades devem ser detalhadas com cerca de duas semanas de duração (dois a três ciclos).
Segundo os implementadores de CCPM com quem venho trocano emails, seus cronogramas permanecem com menos de 300 linhas pois o que é tratado como uma atividade no projeto seria de fato “explodida” em cronogramas sob controle dos responsáveis por aqueles resultados. Apenas para fins didáticos, a ilustração a seguir representa um projeto “gerencial”, sem conter os detalhes de fornecedores, equipes técnicas, etc.
Neste caso, (C) e (E) seriam “atividades” de projeto, mas realizadas por terceiros, sem uma análise detalhada de possíveis restrições.
Ao criar Feeding Buffers – FB (Pulmões de Convergência) e o Project Buffer – PB (Pulmão de Projeto), eu poderia ter um resultado similar a:
Para este exemplo, não importa discutirmos se as durações de “atividades externas” (C e E) devem também ser cortadas dentro de uma “Regra 50x50” ou não. O problema ilustrado a seguir permanece o mesmo, independente da abordagem.
A questão é que sem detalharmos C e E, podemos estar mascarando outras dependências e restrições importantes para o projeto.
Vamos supor que a atividade C seja “Aquisição de Filtro Prensa” e a atividade E seja “Aquisição de Sistema de Transmissão de Dados”. C é realizado pela empresa ACM-C e a atividade E seja realizada pela empresa ACM-E.
Sob minha ótica gerencial, entre pedir e receber o filtro e pedir e receber o sistema, eu tenho atividades de interação com estas empresas que também dependem de recursos de minha empresa. Pode ser desde a aprovação de documentação à vistoria técnica de equipamentos, acompanhamento de instalações, entre outros.
Se C e E fossem tratados como um “pacote de trabalho” entregue as respectivas empresas e o seu detalhamento devidamente colocado em meu cronograma, eu teria cronogramas “gerenciais” com muito mais do que 300 linhas, mas poderia descobrir gargalos de recursos não visíveis com um cronograma simplificado.
Neste “Schedule Model”, as atividades C e E agora são “hammocks”. Uma hammock é uma atividade que “resume” o que está relacionado a ela, assumindo então a duração do conjunto que a compõe.
“Detalhes C” é um subprojeto com o máximo de detalhamento que se possa ter, mesmo que desenvolvido por terceiros (no caso estes dados seriam oriundos do cronograma da empresa ACM-C). O conjunto de todas as atividades devem então coincidir com o tempo esperado no “cronograma gerencial” para sua realização.
O mesmo acontece com “Detalhes E”, que poderia conter 5, 50 ou 5000 linhas provenientes do detalhamento de projeto feito pela empresa ACM-E.
Ainda neste exemplo de cunho didático, em função do cronograma mais detalhado sou capaz de perceber que para a “aprovação de documentos” para a empresa ACM-C, vou utilizar o meu recurso interno JOSÉ. Este mesmo recurso também irá acompanhar a instalação do sistema de dados, com a empresa ACM-E.
Teremos então um “conflito de uso de recursos” que em uma situação habitual dentro do paradigma CCPM será resolvida em função dos pulmões (FB e PB). No entanto, estamos já contando com um mecanismo de proteção desenhado para a
“execução do projeto” para acomodar um problema que já desde o “planejamento”
poderíamos estar cientes, tomando as devidas providências.
Na ilustração a seguir, JOSÉ - que não havia sido considerado como recurso crítico - é aplicado em atividades do subprojeto C e em atividades do subprojeto E, alterando a data final do projeto (ainda durante o planejamento).
A antecipação do problema me permite tomar decisões em caráter pró-ativo, sem ter que com isso queimar pulmões durante o projeto. Entre as opções, posso eventualmente arranjar uma nova seqüência entre atividades, a contratação temporária de pessoal, a negociação com o cliente para entrega já com um prazo maior, entre outros.
Na vida real, estamos sujeitos a dezenas de variações em projetos provenientes das mais diversas fontes (calendários, faltas, atividades de última hora, problemas com equipamentos, dificuldades na realização de atividades, etc). No exemplo acima, a agenda pessoal de um único funcionário compromete a interação com duas empresas distintas.
Em muitos casos, o que é tratado como “MURPHY” em um projeto, consumindo pulmões de convergência ou de projeto (FB/PB), um planejamento integrado poderia ter resolvido antecipadamente.
Complexidade & Micro-Gerenciamento
Em sua essência, cronogramas para o método SDPM (Success Driven Project Management) são detalhados em níveis bem mais elevados que àqueles criados para atender CCPM. Em muitos casos, encontramos resistência a este tipo de planejamento em função de diferentes argumentos.
“Projetos muito detalhados” exigem equipes especializadas e cronogramas complexos.
Falso! Em projetos detalhados utilizamos o conceito de Fragnets (Fragmentos de Rede) que são compostos por atividades repetidas e que podem ser armazenadas para aplicações futuras. Isso quer dizer que as pessoas que detém algum conhecimento sobre o projeto podem ser reunidas para estabelecer a “melhor forma”
de executar um determinado conjunto de ações e depois estas atividades são replicadas.
Não podemos confundir “simplicidade” com “poucas linhas”! Se meu projeto está na área de engenharia, eu posso criar Fragnets para “realizar acabamento em um andar no prédio”, “realizar instalação elétrica de quadro de força”. Se meu projeto está na área de tecnologia da informação, posso criar uma Fragnets para “desenvolver a análise de um caso de uso” ou “testar um módulo do sistema”.
Cada Fragnets recebe recursos genéricos, durações genéricas, seqüências genéricas de atividades. São pequenas, fáceis de entender e garantem um fluxo mínimo de informações em projetos.
Um projeto de 10 andares terá 10 x mais Fragnets que um projeto de um único andar, mas a complexidade para montar o cronograma final é praticamente a mesma.
Exemplo de aplicação de Fragnets.
- Vamos considerar a seguinte Fragnets com 4 atividades e 2 recursos:
Os recursos foram nivelados de acordo com sua capacidade (Corrente Crítica) e a duração total deste fragmento é de 120 horas. Qual será a duração total deste projeto se tivermos 10 fragmentos como este?
Em um nivelamento padrão (a seguir, em MSProject®), as 10 Fragnets de 120 horas não levam 120 x 10 (1200 horas) pois há folga entre as atividades “C” e portanto o conjunto pode ser realizado em 840 horas.
É natural em qualquer conjunto de atividades de projeto que as dependências lógicas entre um conjunto de atividades faça com que alguns recursos permaneçam ociosos enquanto outras atividades estão em andamento. No entanto, diferente de um
“Diagrama CPM", que possui uma única solução matemática, o nivelamento de atividades em função de recursos pode alterar radicalmente de um software para outro.
Nivelamentos em diferentes softwares, quando baseado em restrições de recursos, são praticamente um exercício de “tentativa e erro” e através de iterações com diferentes critérios é que um software determina o cronograma esperado para um conjunto de atividades organizadas pela disponibilidade de recursos.
Por esta razão, se criarmos estas mesmas 10 Fragnets do exercício anterior em um cronograma no Spider, aplicando sua função de otimização, para este caso em particular eu como resultado 820 horas.
“Projetos com muitas linhas são difíceis de gerenciar”
Falso! O processamento fica por conta dos softwares, muito mais desenvolvidos hoje em dia do que na década de 80, época em que TOC nascia e preparava diversos de seus conceitos que foram propagados para CCPM anos depois. Através de hammocks ou acompanhamentos de fases de projeto, indicadores de consumo de reservas, entre outros, o controle de um projeto de 50.000 linhas é feito nas mesmas condições de um projeto de 1.000 linhas.
“Não posso fazer projetos grandes, pois entro em micro-gerenciamento”
Falso! Se meu “projeto complexo” tem detalhamento feito por terceiros (outras áreas, empresas, subprojetos, etc), o monitoramento destas atividades permanece feito por eles. Isso seria exatamente igual dentro da “visão CCPM” onde detalhes além das 300 linhas seriam controlados em outros cronogramas.
Se meu projeto é interno, igual posso distribuir a responsabilidade do apontamento de avanços de atividades aos responsáveis pelas próprias atividades. O que necessito é encontrar DESVIOS e ser alertado com a maior brevidade possível. É melhor dar à minha equipe uma planilha semanal de 30 atividades e ter resultados
“por aproximação” deles neste nível do que resumir estas mesmas 30 atividades em um cronograma gerencial e pedir uma nova estimativa de realização!
Portanto, se distribuo 500 atividades e não 50, não quer dizer que preciso ver uma a uma se elas foram realizadas! Posso continuar recebendo medições parciais, reunindo 10 atividades de cada vez e tirar resultados estatísticos.
Em SDPM, o monitoramento constante permite a criação de índices de probabilidade de sucesso que são então utilizados para verificar a saúde das reservas (de tempo e financeira) do projeto.
De volta aos pulmões
Na primeira parte, mostrei dois nivelamentos possíveis para um mesmo projeto e estabeleci um Axioma que diz que “uma única corrente crítica protegida com um pulmão de projeto pode mascarar alternativas de reorganização das atividades de um projeto para compensar problemas encontrados em atividades fora da corrente crítica, antes delas chegarem a consumir pulmões de convergência ou mesmo do projeto”.
Entre os emails enviados, não recebi nenhuma crítica a esta declaração. Em princípio, o entendimento é de que a adoção do método tem vantagens que ultrapassam eventuais prejuízos em função de contínuas otimizações do cronograma e exatamente para estas casualidades que já existem os pulmões. Em resumo, o pulmão dentro do cronograma seria um mal necessário.
Veremos em momento oportuno que a técnica SDPM também protege a rede com reservas (lastros) equivalentes aos pulmões, mas o seu controle é virtual (através de índices de probabilidade de sucesso) e com isso a rede fica “livre” para que novos nivelamentos de recurso ofereçam seqüenciamentos melhorados entre as atividades.
Recebi – contudo – uma crítica ao meu modelo (encaminhada por Antônio Oliveira à lista TOC). O modelo de cronograma criticado corresponde á seguinte figura do utilizada na primeira parte deste documento:
No email recebido, a partir de um modelo criado com o uso do PS8 (cujo fabricante eu desconheço), o projeto “comportaria” a existência de Feeding Buffers, conforme ilustração abaixo:
Segundo a opinião do A.Oliveira, somente uma corrente crítica deve ser considerada em CCPM (e por esta razão a Tarefa E na ilustração abaixo apareceria em AZUL e não em vermelho como no meu modelo.
No entanto, não há como concordar com a crítica! Basta uma análise rápida da rede RCP para verificarmos que – sem exceção – todas as atividades neste exemplo não têm folga livre ou folga total. Significa dizer que o atraso de qualquer uma delas gera o consumo imediato do Pulmão de Projeto, havendo ou não um Pulmão de Convergência pois este - de fato - tem duração ZERO.
A Tarefa E é CRÍTICA, pois qualquer atraso repercute na Tarefa B, que utiliza o mesmo recurso e, portanto se propaga pela Corrente Crítica. Não há “um consumo”
de um Feeding Buffer, pois apesar de termos uma dependência por tarefa (links) somente entre E > C, temos uma dependência por recursos (RCP) entre E > B.
Assim, dizer que há “uma única corrente crítica” é simplesmente absurdo no exemplo dado e muito menos será verdade em projetos mais complexos. Na ilustração a seguir, temos o mesmo cronograma agora com a opção de contagem de folgas:
Não conheço como os diversos softwares de CCPM calculam as folgas, em especial aqueles que se utilizam de plug-ins com o MSProject®. Uma coisa, no entanto é evidente: O MSProject® calcula folgas (livre e total) utilizando-se apenas da técnica CPM (Critical Path Method) e portanto após um nivelamento, estes softwares poderão indicar que tarefas não críticas são críticas e vice-versa.
Na ilustração, as atividades D e E só possuem Folga Livre (chamada de Margem de atraso Permitida na ferramenta) e Folga Total (Margem de atraso total) se estivéssemos analisando somente o diagrama de redes, sem considerar os recursos.
No entanto, qualquer atraso em D (João) reflete em atraso de A (João) e sua propagação imediata para o pulmão do projeto. O mesmo vale para qualquer atraso em E (Maria), embora ela tenha uma “folga aparente” de 6 dias.
Nota: A contagem das folgas acima não correspondem a “erro de software” e sim uma limitação de sua implementação, pois só considera o Caminho Crítico de Tarefas” e não o Caminho Crítico de Recursos/Resource Critical Path (RCP). Este parágrafo eu repito em diversos documentos em que discuto esta restrição da ferramenta visto que fui duramente criticado em certa ocasião em certa lista de discussão por querer “denegrir a imagem do outro software para vender o meu”. O absurdo desta crítica é que se eu me privar de demonstrar como cada software conta o que de fato é folga livre, eu estarei permitindo que indicadores “azul/vermelho” em projetos não tenham qualquer significado prático, já que não me alertam em relação a que atividades irão afetar a data de término de meus projetos.
Parte III – Uma introdução ao SDPM
O SDPM – Success Driven Project Management, método Russo desenvolvido na década de 90 nasceu a partir de fundamentos do Resource Critical Path (RCP) – Caminho Crítico dos Recursos e não com base à TOC ou CCPM.
Desde a década de 60, especialistas em cronogramas nos Estados Unidos, Europa e antiga União Soviética tentaram dezenas de algoritmos para melhorar os resultados obtidos com o CPM – Método do Caminho Crítico, para incluir as dependências por recursos. Até mesmo os criadores de CPM se aventuraram por este caminho, desistindo de encontrar uma “fórmula única” em 1964.
Enquanto o “caminho crítico das tarefas” é uma solução matemática, podendo ser repetida por qualquer software, o “caminho crítico dos recursos” comporta milhares de respostas para um mesmo projeto. Assim, cada software poderá implementar o RCP de forma distinta.
O Sr. Vladimir Liberzon publicou os princípios de SDPM após a queda do Muro de Berlim, mas baseado em resultados já obtidos com RCP em computadores do tipo Mainframe, desde 1978.
SDPM é um método baseado em restrições como CCPM (Método da Corrente Crítica). No entanto, CCPM tem como origem os conceitos desenvolvidos na TOC na década de 80 (Teoria das Restrições) enquanto SDPM tem como origem os algoritmos de RCP desenvolvidos nas décadas de 60 e 70.
RCP é o equivalente (por aproximação) a Corrente Crítica. Em ambos os casos, encontramos em um projeto a menor duração possível em função do conjunto de atividades estabelecida pela seqüência lógica e restrições de recursos.
Um ponto relevante que distingue os dois é o fato de que RCP ser criado em função de qualquer tipo de restrição e, portanto o caminho crítico do projeto pode ser alterado pela falta não só de recursos humanos ou máquinas, mas também estoque de materiais e fluxo de caixa.
De forma simplificada, podemos dizer que tanto o SDPM como CCPM são
“métodos baseados na corrente crítica”, assim como ambos podem se utilizar de softwares capazes de calcular o RCP, incluindo ou não fluxos de caixa e materiais.
SDPM é o equivalente (por aproximação) a CCPM. Ambos possuem diversas premissas comuns, como a de dar importância para a criação de reservas de projeto, procurar evitar as multi-tarefas, combater à Síndrome de Estudantes e Mal de Parkson.
Um ponto relevante que distingue os dois é o fato de que SDPM trabalha com lastros virtuais (reservas que não estão fixadas na corrente crítica) e CCPM trabalha com a aplicação de Feeding Buffers e Project Buffers (FB e PB), o que chamamos habitualmente de pulmões.
Em minha opinião, há elementos provenientes de TOC (como as Árvores de Estratégias e Táticas) que poderiam fortalecer SDPM, assim como diversas características de SDPM poderiam fortalecer a aplicação de CCPM.
As características de “simplificação do planejamento” provenientes de CCPM, como a sua “não preocupação” em buscar cronogramas detalhados como sugerem as melhores práticas do PMI (apontados anteriormente) e a aplicação de escalonamentos
SDPM CCPM
RCP Corrente Crítica
protegidos por pulmões (nivelamentos parciais) no lugar de planejamento detalhado e nivelamentos otimizados me fazem acreditar que o Método da Corrente Crítica é uma solução inteligente a ser aplicada em substituição ao CPM, em projetos de pequeno porte ou com pequenas equipes, em especial quando não podemos lançar mão de recursos computacionais. CCPM não está preparada para lidar com um Gerenciamento Ativo de Riscos e nem com situações complexas com múltiplos gargalos, comum em projetos de médio e grande porte.
Não vou discutir o sucesso que CCPM já tenha alcançado em alguns projetos de grande porte. Se comparado à aplicação do Método do Caminho Crítico, a inclusão de restrições e o trabalho de redução de multi-tarefas, melhor aproveitamento de reservas de projeto, entre outros fazem do método um grande avanço em relação ao que é adotado comumente.
O que estou discutindo é que podemos FAZER MUITO MAIS, ampliando nosso planejamento, assumindo controle sobre múltiplos gargalos e tratando de forma pró- ativa os riscos de projeto.
SDPM vem crescendo em seminários apresentados junto ao Project Management Institute e em “cases” provenientes da experiência russa e soviética começam a ser documentados no ocidente. Entre os últimos projetos, o SDPM vem sendo aplicado nos preparativos para os Jogos Olímpicos de Inverno de 2014, que acontecem na Rússia. A escolha do comitê por este método é resultado do sucesso obtido com a recuperação do projeto para os Jogos Olímpicos da Juventude em 1996, uma das primeiras aplicações de SDPM no mundo. O projeto atual reúne mais de 240 subprojetos e investimentos na ordem de USD 80 bilhões de dólares. Mais do que criar instalações para os jogos ou dormitórios, este projeto reúne a modernização de uma região remota da Rússia maior do que a Argentina, com projetos para a construção de portos, aeroportos, malha rodoviária, ferroviária e sistemas de telecomunicações.
O projeto atual, apresentado em “roadtour” pelo sr. Liberzon no Brasil, contém um planejamento com mais de 140.000 linhas e o nivelamento de mais de 1.400 recursos dos mais diferentes, entre máquinas, recursos humanos, disponibilidade de financiamentos e estoque de materiais.
Para o Comitê Olímpico, um painel de controle criado com hammocks reúne pouco mais de 240 linhas (um por subprojeto) para o gerenciamento global de reservas de tempo e caixa. Para os gestores, este projeto poderia se passar por “um projeto CCPM com menos de 300 linhas”, onde os “pulmões” são tratados como
“lastros virtuais” através do Índice de Probabilidade de Sucesso. No entanto, embora o painel de controle seja simplificado, ele é “mantido vivo” por uma complexa rede de relacionamentos entre atividades e recursos, sendo capaz de “responder” à alterações em função de problemas comuns, como atrasos em materiais, redução de produtividade, em resposta a riscos diversos, entre outros.
O que alcançamos com a abordagem SDPM é uma “visão gerencial simplificada”, similar à preconizada por Goldratt para o CCPM, mas reforçada por informações
Lastros – A “visão dos pulmões” sob a ótica de SDPM
Já discutimos o problema de fixarmos uma única corrente crítica do projeto, pois esta – uma vez protegida pelo pulmão de projeto, irá mascarar possíveis melhorias na rede durante o andamento do projeto.
Se um determinado recurso em uma atividade antes não considerada como crítica tiver problemas graves de produtividade, por exemplo, o “sistema como um todo”
estará parcialmente protegido pelo Feeding Buffer deste caminho secundário e depois pelo Project Buffer. Em linhas gerais, se este consumo não for elevado, o impacto pode passar despercebido e o projeto terminar dentro de seus objetivos.
Percebemos então que a criação dos pulmões na técnica CCPM atende seus objetivos! Isso não quer dizer, contudo, que o conceito não possa ser ampliado e oferecer maiores benefícios ao projeto.
SDPM traz o conceito de lastros virtuais. Corresponde a criação de um cronograma META, com base a um grau de confiança que se pretende impor ao projeto.
Assim como em CCPM, em SDPM entende- se que toda atividade tem uma flutuação em relação às possíveis durações, em função de causas conhecidas ou desconhecidas.
A curva com distribuição Beta acima é uma representação adequada tanto para uma única atividade como para a duração total de um projeto. Podemos dizer que uma atividade X tem uma duração estimada de provável de n dias. Provável significa que dentro das flutuações possíveis, ela irá mais vezes se aproximar da duração provável do que em um de seus extremos (resultado otimista ou pessimista).
A duração otimista é normalmente baseada em um limite técnico. Diz-se que entre uma estimativa ótima e provável temos cerca de 50% de chances de que a duração real aconteça neste intervalo. Entre a duração provável e pessimista, temos outros 50% de chances, mas quanto maior a probabilidade de confiança desejada, mais próximo do infinito estará o resultado pessimista.
Em CCPM, partimos do pressuposto que quanto maior a experiência de um profissional em algum tipo de atividade, mais ele está acostumado a perceber que fatores externos podem atrapalhar sua produtividade e, portanto eles têm uma tendência a “sobrecarregar” a duração das atividades com margens de segurança elevadas. A regra básica do corte de 50% vem atender – de forma simplificada – com a necessidade de aproximar as estimativas de suas durações prováveis.
Diversos implementadores de CCPM aceitam diferentes mecanismos para estabelecer o tamanho do corte nas atividades individuais e a criação dos buffers.
Regra estatística, aplicação de simulações, triangulações, aplicação de estimativas em dois e três pontos, e outros mecanismos já foram empregados, embora exista um
“entendimento comum” de que a aplicação da regra básica 50 x 50 seria suficiente.
Duração Otimista
Duração Provável
DuraçãoPessimista
Em SDPM, buscamos sempre a criação de CENÁRIOS de Projeto. Para um grande volume de atividades, ou para projetos mais rápidos, os cenários podem ser criados com a aplicação de “descontos” da média para encontrar o resultado otimista e de “sobrecargas” para encontrarmos os resultados pessimistas. Quando estas variações são aplicadas desta forma, de fato não se deve esperar uma precisão ou acurácia nos resultados maior ou menor do que os cortes impostos nos buffers de CCPM.
Neste sentido, podemos dizer que ambos os métodos não estão exatamente interessados em “acertar” com as estimativas, mas sim o de criar uma melhor aplicação das durações estimadas, de forma que a equipe de projeto tenha metas desafiadoras (cronogramas baseados em durações não conservadoras) e ainda assim o projeto tenha uma proteção previamente acordada com os envolvidos para conter as variações que seriam “naturais” no sistema.
Podemos então – de forma rápida e eficaz – criar lastros em projetos para SDPM com praticamente os mesmos objetivos a serem obtidos com CCPM.
No entanto, para projetos em que temos que estar mais seguros de seus resultados, sejam eles financeiros ou em relação ao cumprimento de prazos, com a aplicação de SDPM podemos:
A) Determinar diferentes cenários com diferentes probabilidades de sucesso;
B) Simular não apenas alterações em atividades em função de desvios “naturais”, mas também em relação a situações extremas, com a inclusão de análise de cenários de risco e planejamento de respostas.
Se pensarmos em uma simplificação de conceitos matemáticos, um cronograma normal, criado com valores médios de duração de atividades (cronogramas determinísticos), a chance efetiva de cumprirmos com a data final planejada é inferior a 30%.
Isso acontece por que são construídos com o conceito de MÉDIAS. Por serem valores médios, em cerca de 50% dos casos no projeto deveríamos ter resultados reais abaixo da duração estimada e em 50% dos casos restantes teríamos os resultados além da duração estimada.
Parte-se do princípio que teremos compensações ao longo do projeto e estas, na realidade não acontecem.
De forma resumida, resultados ótimos (abaixo da média) são desperdiçados. Ou os recursos poderiam terminar antes do prazo acordado e estendem o trabalho à duração disponível (Lei de Parkson), ou as atividades são deixadas para serem realizadas próximas do seu limite (Síndrome do Estudante). Soma-se “Murphy” a esta combinação e qualquer ganho de projeto é jogado fora.
Por outro lado, atrasos serão sempre atrasos e estes rapidamente irão se acumular com os demais, levando o cronograma final sempre a datas posteriores ao
Ao cortarmos as “gorduras localizadas” e transferirmos parte delas para o final, o que temos são metas desafiadoras para as equipes, onde os resultados positivos não são desperdiçados e os resultados negativos são então protegidos com as reservas globais.
Com a criação de 3 cenários, onde o original é considerado a versão pessimista, o cenário com os 50% de corte aplicados em CCPM é a versão otimista e a versão mais provável é uma média entre ambos os cenários, o buffer calculado em SDPM pode ser visto como na ilustração a seguir:
Na coloração vermelha, temos as atividades críticas já com a duração 50%
equivalente ao projeto original. Em laranja, temos um comparativo com o mesmo cronograma criado com os pulmões de CCPM. Em azul, temos os lastros de projeto com base a metodologia SDPM.
Em CCPM, uma atividade “Pulmão de Projeto” seria colocada entre o marco de fim (vermelho) e a meta de finalização (laranja). No caso de SDPM, o lastro é uma representação do que pode acontecer além do tempo imposto a equipe sem ainda prejudicar a meta estabelecida.
O cronograma “em azul” corresponde ao cronograma crítico. Se deixarmos tudo para fazer no último instante, mas ainda assim as durações forem adequadas, cada atividade pode acontecer NO MÁXIMO até o período sinalizado em azul.
Se as premissas de duração que adotamos para a montagem deste cronograma forem verdadeiras, então a curva de análise de risco correspondente ao projeto é a seguinte:
Por esta simulação, o cronograma “à moda CCPM” teria 88,50% de probabilidade de ser cumprido no prazo.
E se as premissas estiverem erradas?
O cronograma acima foi criado baseado em elementos provenientes da aplicação do Método da Corrente Crítica, entre eles:
A) O entendimento de que o cronograma original estava com “gorduras”
localizadas em cada atividade;
B) O entendimento de que recriando o mesmo projeto com 50% de duração em cada atividade, existe de fato uma possibilidade de que as durações reais sejam próximas dos valores estabelecidos como meta;
C) O entendimento de que uma duração total igual a 75% da duração anterior, desde que o cronograma da equipe seja aquele com os cortes, tem chances reais de ser realizado.
Se uma parte destas premissas não for verdadeira, o projeto irá consumir os pulmões durante sua realização, mas terminará no prazo estipulado com o cliente.
Se outra parte destas premissas não se realizar, o projeto irá ultrapassar as reservas e terminará além da data estabelecida como meta.
Para identificar a “saúde” do projeto, em CCPM realizamos uma análise do consumo dos pulmões. Um ponto fraco nesta análise é que se considera um consumo linear de reservas ao longo de projeto e em CCPM não somos capazes de diferenciar os avanços de projeto quando ultrapassamos uma parte do projeto onde fizemos em menor tempo atividades de maior risco ou vice-versa.
Para o projeto exemplo, temos 11 unidades no pulmão e temos um total de 21 unidades de duração. Através da marcação de limites inferiores e superiores, temos 3 áreas na figura para determinarmos o consumo das reservas: No limite verde, o consumo do pulmão está abaixo de 1/3 e portanto não há preocupações quanto à data final.
Entre o 1/3 inferior e 1/3 superior, estamos consumindo as reservas em um ritmo que merece atenção e no limite superior temos um consumo abusivo e, portanto temos que tomar ações imediatas para garantir o sucesso do projeto.
Em SDPM, utilizamos o ÍNDICE DE PROBABILIDADE DE SUCESSO (IPS), que pode ser calculado com o uso de ferramentas conhecidas no mercado, como a Simulação de Monte Carlo. O Spider, única ferramenta hoje disponível no mercado 100% aderente ao modelo SDPM, tem um mecanismo interno para calcular este índice.
O IPS sobe ou desce de acordo com a margem de contribuição para o sucesso do projeto de cada atividade. Quanto mais o projeto se aproxima do limite azul, menor está o lastro do projeto. Na ilustração, após 3 medições, a tarefa crítica E teve um atraso além do previsto no cenário “meta” (duração entre o provável e pessimista dentro da margem desejada), fazendo com que as demais atividades avance no tempo (comparar a barra vermelha – atual com a barra laranja, que é a linha de base).
Através de nova análise probabilística, temos então uma redução do IPS de 88%
(original) para 77% (atual).
Uma vantagem do IPS sobre a análise de pulmões de CCPM está relacionada à manutenção de cenários de gerenciamento de risco.
Se partirmos do pressuposto que uma equipe realize todas as atividades 100%
conforme o planejado, nós teremos em CCPM a indicação de que o pulmão de projeto
é saudável. O pulmão não é capaz de identificar que até o momento nenhuma atividade de alto grau de risco foi ainda realizada (logo é esperado que não sejam consumidos os pulmões) e que na segunda etapa do projeto as atividades de maior dificuldade irão todas acontecer (o que deverá consumir os pulmões além dos valores previamente calculados).
O IPS sempre leva em consideração a probabilidade de término conforme a data meta estabelecida. Se o cenário “pessimista” for modificado, com a inclusão de novas restrições como alteração no valor dos materiais, ausência de recursos humanos por conta de uma greve, etc, o IPS irá imediatamente apontar uma redução na probabilidade de sucesso do projeto, mesmo que a equipe esteja realizando em 100%
todas as atividades previstas até o momento.
O IPS, portanto consegue identificar o consumo do lastro não em função de uma análise linear do tempo e recursos consumidos no projeto, mas sim o consumo do lastro em relação ao que de fato aconteceu em relação ao planejado e aquilo que ainda pode acontecer em relação aos cenários otimistas e pessimistas de projeto.
Outro aspecto fundamental desta análise de saúde do projeto está no fado de que o IPS consegue examinar o PESO particular de cada atividade.
Se duas atividades, A e B, têm cenários otimista e pessimista diferentes (mesmo que a duração mais provável seja a mesma), então um dia de atraso na atividade A irá contribuir de forma diferente à saúde do projeto do que um dia de atraso na atividade B. Esta “margem de contribuição” também irá depender do fato das atividades estarem ou não na Corrente Crítica do Projeto.
Um ponto interessante sobre o acompanhamento de tendências do IPS é que o percentual pré-estabelecido não é o mais importante e sim a direção para a qual estamos indo durante o projeto.
Isso quer dizer que para projetos mais importantes, podemos optar por assumir maiores ou menores riscos, dependendo de nossa visão estratégica. Podemos ter um lastro calculado em 35% ou um lastro calculado em 90%. Nossa meta então é manter ou aumentar a probabilidade definida como meta para cumprir o prazo final, não importa o seu valor inicial.
IPS inicial baixo: o lastro é pequeno. Projeto de maior risco.
IPS inicial alto: o lastro do projeto é grande. Projeto de menor risco.
Nota: O IPS em SDPM pode ser calculado não só para a duração do projeto, mas para durações parciais, para disponibilidade de recursos humanos, para consumo de materiais, para acompanhamento financeiro, etc. Este é outro aspecto relevante de SDPM que não tem suporto similar em CCPM: Análise de pulmões financeiros.
Na ilustração acima, a cada nova medição temos o relatório de que a atividade C está levando mais tempo que o planejado, mas, segundo a interpretação dos envolvidos, mesmo a projeção do trabalho remanescente é inferior à data prometida e por esta razão diz-se que o IPS neste projeto está próximo a 100%.
Podemos perceber pela ilustração que não é necessário termos um “pulmão”
fixado ao fim do projeto, bastando o acompanhamento do “consumo virtual” ao compararmos o cronograma dado para a equipe com o cronograma meta (em azul) que foi negociado com o cliente. Em projetos reais, com grande quantidade de atividades, é natural que diversos recursos antes não considerados críticos passem a ser o gargalo do projeto. Isso pode acontecer em função de uma máquina que quebrou, um fornecedor que não encaminhou um determinado tipo de material ou uma parte do projeto que não passou nos testes de qualidade. Se não tivermos uma corrente crítica pré-definida, softwares de otimização do cronograma podem então identificar formas de reorganizar as seqüência entre tarefas, de forma a compensar atrasos em projeto em função destes recém-encontrados gargalos ou restrições.
Parte IV – Aplicação dos métodos e o nivelamento de recursos
Devemos lembrar que o Método da Corrente Crítica por si só permite a melhoria de cronogramas a partir de sua aplicação, sem a necessidade específica do apoio de um software. Isso quer dizer que a simples dinâmica de reduzir durações para estabelecer metas mais desafiadoras às equipes e a colocação de reservas sob a administração do Gerente de Projetos já pode trazer resultados interessantes para projetos de qualquer porte.
Mesmo que se faça a opção por não fazer cortes no pulmão criado e que os cortes em cada atividade sejam feitos em quantidades variadas, o método tem a qualidade de chamar a atenção dos envolvidos quanto à importância de se ter controle sobre desvios e também o de provocar um sentimento de auto-superação.
Outra qualidade do Método da Corrente Crítica é o fato de resolver alguns conflitos de nivelamento de recursos pelo simples percepção de que atrasos irão acontecer, dentro de certos limites. O que temos na realidade é um escalonamento, onde a solução para os conflitos não resolvidos são tratados pelos pulmões.
Por outro lado, esta “acomodação natural” pode nos levar a um relaxamento quanto à interação de fato necessária entre recursos de projeto. Em muitos casos, um nivelamento adequado dos recursos pode representar reduções de prazo significativas. A ordem dos tratores altera a construção do viaduto e as vezes somos levados a não examinar o tamanho desta diferença.
Em SDPM, não temos a opção de adotar o método sem contar com um adequado nivelamento de recursos. Os lastros criados têm como objetivo atender variações esperadas em cada atividade por razões outras além do conflito de recursos. Ou seja, espera-se que os recursos estejam devidamente planejados, descritos e nivelados antes da adoção do Método.
É claro que uma vez criado os lastros, sua aplicação permite inclusive a acomodação de recursos mal nivelados, assim como em CCPM, mas isso é um efeito colateral. Em termos de “fundamentação dos métodos”, SDPM não espera resolver este tipo de situação enquanto CCPM teria isso em sua “lógica intrínseca operacional”.
Em termos práticos, se eu utilizo CPM (Método do Caminho Crítico), eu não tenho visibilidade dos impactos que conflitos de recursos terão em meu projeto. O princípio para sua adoção deveria ser o de que “uma vez fechada a data acertada com o cliente, em função primordialmente da seqüência lógica entre as atividades, o esforço principal do GP será o de sempre buscar os recursos necessários, no tempo e quantidade necessários, para cumprir com a programação criada”.
A premissa de que os recursos serão obtidos quando necessários pode ser válida em algumas poucas situações e foi essencialmente verdade quando da criação do método: Em plena Guerra Fria, o objetivo para o “modo americano” era de atingir as metas, custasse o que custasse.
Do outro lado do planeta, os Soviéticos se contrapunham à hegemonia americana em uma situação crítica, com parte de sua população dizimada pela guerra, muitos recursos escassos e conflitos pela imposição de um novo regime em toda a sua extensão. O RCP (Caminho Crítico do Recurso) deveria então descrever exatamente a situação de falta de recursos e o planejamento deveria então ser otimizado dentro dos limites de pessoas, máquinas e recursos financeiros disponíveis.
Por esta razão, o seu planejamento não podia contar apenas com a abundância de recursos (CPM) ou mesmo um escalonamento dos mesmos (CCPM), mas sim dependia do contínuo aprimoramento matemático de mecanismos que fizessem com que os nivelamentos de recursos fossem capazes de reduzir prazos e custos através
Nivelamentos otimizados
Já foi demonstrado que pulmões no lugar de lastros podem “fixar” a corrente crítica em uma única posição no projeto e com isso retirar a capacidade de softwares de otimização de encontrar caminhos alternativos, otimizando os resultados de projeto em função de melhorias na rede para beneficiar redução de custos e/ou prazos.
Na ilustração a seguir, temos uma mesma rede com apenas quatro atividades onde a simples inversão entre atividades de início geram uma redução em 20% no tempo do pacote. Em vermelho temos o “recurso A” e em azul temos o “recurso B”.
Ambas as soluções atendem todas as prerrogativas de CPM (hard-logic ou dependências obrigatórias) e ambas soluções garantem um nivelamento apropriado de cargas de trabalho para cada recurso.
Pulmões x Lastros
CCPM, originária da TOC – Teoria das Restrições – desenvolve o entendimento de que o mundo com recursos abundantes esperado pelo CPM de fato não existe.
Utilizando o aprendizado em fábricas, extrapola o entendimento de que “há um caminho crítico baseado na lógica do sistema que determina o menor tempo do projeto” e alcança o entendimento de que “há uma corrente crítica baseada no limite produtivo de gargalos que irão impactar o desempenho global do projeto”.
Esta percepção gera um “ganho” excepcional e o método baseado em escalonamentos e pulmões resolve um problema básico: no mundo ocidental não há softwares desenvolvidos para lidar com o complexo mundo de RCP.
Outro ponto relevante do CCPM em termos de mudança cultural é o de começar a ampliar o planejamento para o instante que nós podemos então de perceber estes gargalos. Ou seja, cronogramas começam a exigir maior detalhamento em relação às quais são os recursos necessários.
Sem softwares avançados e com os pulmões resolvendo parte dos conflitos oriundos do escalonamento, CCPM então impressiona pela capacidade de ampliar as chances de sucesso em projetos. Anos mais tarde, o método vai incorporando outros valores desenvolvidos com a TOC, como é o caso das Árvores de Estratégias e Táticas e, portanto amplia sua capacidade de transformar as organizações mediante o entendimento do que de fato precisa ser feito, de que forma e com quais recursos críticos.
Nivelamento com 15 dias
Nivelamento com 12 dias
Entendemos desta evolução histórica e dos dois cenários extremos que foram criados (experiência Ocidental e a Soviética), que SDPM nasceu de uma exigência por resultados precisos, fundamentado na análise de cenários de risco e na aplicação de avançados algoritmos de RCP (nivelamento de atividades por recursos). Podemos então estabelecer algumas diferenças entre o que são os “pulmões” de CCPM e os
“lastros” de SDPM.
PULMÕES: Somam reservas oriundas das atividades que foram “cortadas” de suas proteções individuais. Estas proteções somam estimativas dos envolvidos em relação a atrasos por conta de conflitos de prioridades, impossibilidade de se determinar a produtividade real das tarefas e experiências anteriores.
LASTROS: É o resultado entre a estimativa do projeto baseado em 3 cenários (pessimista, otimista e provável), o seu grau de confiança desejado (quanto maior a confiança, mais próximo do cenário pessimista estamos indo) e a meta de projeto estabelecida. Lastros são criados com base a estimativas baseadas na impressão dos envolvidos, assim como em CCPM, mas são documentados de forma mais detalhada, permitindo análise crítica em situações futuras. Além disso, Lastros também são criados em função de respostas a riscos que são desenvolvidas em projeto. Este tipo de detalhe raramente é absorvido dentro dos cronogramas CCPM. O Lastro em SDPM irá cumprir com a proteção do projeto para atividades que não são sequer planejadas em outros métodos.
Gerenciamento de Riscos – A visão integrada de SDPM De forma resumida, durante a criação
de cenários para SDPM, não apenas detectamos quais seriam os extremos das durações esperadas das atividades do dia- a-dia de projetos (3 estimativas), mas também tratamos os possíveis riscos positivos e negativos que poderão influenciar os resultados do projeto.
Alguns exemplos:
- O cenário otimista pode contar com o término no prazo de outro projeto, liberando então mais recursos humanos para o novo projeto. As atividades terão durações menores e produtividades maiores em função da disponibilidade dos recursos extras.
- O cenário otimista pode estar baseado em uma situação onde os produtos criados (soldas realizadas ou pacotes de programação implementados) tenham pequeno índice de erros, demandando com isso poucas ações de reparo.
- O cenário provável contém índices de erros, quantidades de recurso, durações estimadas e demais estimativas dentro da situação habitual pela qual construiríamos nossos cronogramas determinísticos habitualmente. Poderá conter também aqueles
mitigação, eliminação e transferência de riscos são também incluídas no cronograma e, portanto temos um impacto eminente em função do nivelamento dos recursos humanos, técnicos e financeiros que serão consumidos não só em atividades regulares de projeto, mas também nestas atividades de resposta a riscos.
- O cenário pessimista contém situações extremas que, se consideradas, irão dar ao projeto maior segurança de ser realizado em até cerca de 90% dos casos.
Diferenciando “chute” e “criação de cenários”
Uma argumentação freqüente é a de que quando um profissional coloca reservas em suas atividades ele já está protegendo seu trabalho em função dos riscos. Não faria diferença em termos práticos para o projeto ter as atividades já “com gorduras” ou tê-las colocadas nos cenários.
Já tivemos como perceber que o simples “deslocamento” destas reservas das atividades em si para o fim do projeto aumentam o controle gerencial e, portanto sua real aplicação nas situações de risco.
Precisamos perceber que o passo seguinte, representado pela criação de cenários documentados, amplia ainda mais nossa capacidade de análise das estimativas. Um cenário comporta o aprendizado contínuo: Se ao longo do projeto novos riscos forem identificados, eles serão trazidos para os cenários e a probabilidade geral de sucesso do projeto será recalculada independente da equipe estar ou não fazendo o projeto conforme o planejado. Isso pode significar o entendimento de que um projeto precise ser cancelado, por exemplo, sem demérito da equipe.
O que estamos fazendo é “modelar a realidade dentro de nossos cronogramas”
com mais e mais detalhes, para que o “modelo” se aproxime cada vez mais da realidade.
Quantos projetos foram cancelados em função da nova realidade estabelecida com a explosão das bolhas do mercado americano no segundo semestre de 2008?
Não importa se estes projetos tivessem seus cronogramas simplificados com CPM, melhorados com CCPM ou extremamente detalhados por SDPM, muitos deles seriam cancelados da mesma forma.
No entanto, para os projetos baseados em um detalhamento em cenários e técnicas de análise de lastros - como temos em SDPM - nós teremos condições de ampliar nosso entendimento de ONDE o contexto externo está de fato impactando os cenários de nosso planejamento e – se ainda assim o projeto for cancelado – permitir a criação de uma documentação que sirva para ampliarmos nossa capacidade de responder a novas adversidades no futuro.
Em um projeto de alta tecnologia, baseado essencialmente na especialidade técnica de sua equipe, o impacto do aumento de preços de recursos essenciais como a eletricidade ou custo de laptops pode não ser significativo para o projeto. Por outro lado, em um projeto de construção civil, o aumento do custo do aço pode fazer com que o projeto inteiro represente um prejuízo para a empresa.
Em ambos os casos, se estamos acompanhando o projeto com o uso de cenários de SDPM, o nosso Indicador de Probabilidade de Sucesso (IPS) está baseado principalmente na capacidade do projeto andar conforme o planejado. Ainda assim, sem alterarmos nenhuma linha de planejamento das atividades que estamos executando, os cenários otimista, pessimista e provável receberão novas informações, como a alteração de custos de recursos humanos e equipamentos datam de chegada de materiais, disponibilidade financeira, entre outros.
Estas informações “externas” irão então alterar nosso IPS, e inclusive nosso próprio cronograma (visto que o nivelamento RCP é baseado em qualquer tipo de restrição). Em algumas situações, o impacto financeiro – por exemplo – pode ser compensado com a reorganização de prioridades de execução no projeto!
Em certo projeto, um budget semanal de R$ 130.000,00 é necessário para a sua execução conforme o planejamento inicial. A empresa então perde um contrato externo e sua capacidade financeira é prejudicada. O projeto então passa a ter que ser realizado com um budget semanal R$ 90.000,00 - até que novos contratos permitam a recuperação dos investimentos para complementar a falta de recursos anterior.
Em uma rede CCPM, protegida por um pulmão, não temos como identificar redes alternativas e priorizações entre outras atividades de menor custo que poderiam ser realizadas com a redução do budget. O impacto natural será uma redução de produtividade no projeto em função da nova restrição financeira e o projeto irá avançar consumindo mais pulmões do que o necessário por não poder executar todas as atividades planejadas.
Em uma rede SDPM, as novas restrições são embutidas no cálculo. Um novo nivelamento deverá também gerar algum consumo dos lastros de projeto, mas não na mesma proporção. Em determinados casos, a reorganização de atividades também necessárias ao projeto, mas de menor consumo financeiro, fará com que o projeto possa manter um nível de produtividade razoável, suportando parcialmente o impacto proveniente da redução financeira.
