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.
Cenário Inicial:
- Total do Projeto : R$ 650.000,00 - Budget semanal: R$ 130.000,00
Em azul, temos o aporte semanal e a programação do trabalho utilizando ao máximo a disponibilidade financeira. O projeto leva um total de 30 dias.
Cenário CCPM:
- Total do Projeto : R$ 650.000,00
Em azul escuro, o novo Budget, com aporte financeiro pequeno no início, obrigando o deslocamento das atividades de projeto para frente.
Em verde, a nova seqüência de despesas de projeto. A partir da 3ª semana, quando o fluxo de caixa recebe novamente apoio financeiro da empresa, o budget extra não permite recuperar o tempo de projeto.
Em laranja, as atividades conforme programação anterior, antes da falta de caixa.
Nota: Neste cenário não temos ainda a indicação de onde estão os pulmões, pois o enfoque do exercício é no entendimento de que “eventos externos” (como a ausência de caixa conforme o previsto) irão promover a retração das atividades. Este “atraso” de três dias seria então “absorvido” pelo pulmão de projeto e a data final para o cliente permaneceria assegurada.
Cenário SDPM:
- Total do Projeto : R$ 650.000,00
- Budget semanal: R$ 90.000,00 (primeiras semanas, com aporte maior ao final)
Em um cenário com aplicação de SDPM, não existe um pulmão que “fixa” a corrente crítica. O pulmão, ao mesmo tempo em que protege, proíbe sua otimização.
Um novo nivelamento do projeto com a situação crítica de falta de caixa, permite ainda encaixar uma nova ordenação entre as atividades no momento em que o caixa é regularizado.
Pontos fortes e fracos: SDPM & CCPM.
A aplicação efetiva de SDPM necessita de um planejamento em maior nível de detalhe. Em um cenário onde apenas uma parte das restrições é identificada e
trabalhada, SDPM e CCPM terão resultados similares e CCPM será
consideravelmente mais fácil de aplicar.
Por esta razão, é plausível considerar que um cronograma gerencial em CCPM venha ser mantido em 300 linhas, mantendo os demais cronogramas de subcontratados, subprojetos e outras áreas envolvidas em separado. O resultado provavelmente ainda assim será superior ao que poderíamos obter com CPM.
Em situações com constante mudança de condições de logística (como contratos com grande diversidade de materiais e subprodutos adquiridos de terceiros), com flutuações de custos operacionais (prazos de mobilização/desmobilização, alterações em câmbio de moeda, variação de custos de materiais de larga aplicação, etc). O planejamento adicional exigido por SDPM permite a otimização não só de prazos, mas de aplicação de materiais, uso de recursos humanos e financeiros.
Comparando o resultado com 33 dias em um “panorama CCPM” com os 31 dias de um “panorama SDPM”, podemos perceber que pequenas inversões de prioridades são suficientes para assegurar um impacto reduzido em função da mudança do orçamento semanal. No comparativo a seguir, o cronograma com 33 dias está fixado como “linha de base”.
Sem o pulmão fixando uma única corrente crítica, o sistema antecipou uma atividade de R$ 24.000,00 e inverteu a seqüência entre três outras de R$ 72.000 ou R$ 74.000, respeitando os predecessores e o fluxo de caixa, mas permitindo uma redução em 2 dias (8%) em relação ao prazo total do projeto já acomodado às restrições financeiras.
Para um planejamento adequado para SDPM, temos que:
1) Considerar qualquer elemento de projeto um potencial gargalo de projeto; 2) Entender que um recurso pode ser 100% crítico em 1 dia do projeto e
totalmente desnecessário nos outros 99 dias;
3) Detalhar as informações de projeto para que possamos enxergar as alterações na rede de atividades em função de otimizações criadas com o auxílio de uma modelagem computacional do projeto;
4) Realizar um monitoramente constante da situação real do projeto para identificar novas restrições (faltas, máquinas quebradas, redução de produtividade, etc) que poderão disparar novo seqüenciamento de atividades em um cronograma otimizado;
5) Realizar um planejamento adequado de riscos, trazendo para dentro do modelo computacional do cronograma aquelas atividades de resposta a risco (positivos ou negativos) que também irão exigir o consumo de recursos humanos, materiais e financeiros;
6) Empregar o nivelamento de recursos, não o escalonamento, de tal forma que todo e qualquer elemento é considerado em relação ao “seu momento crítico” dentro da corrente crítica do projeto;
7) Manter Lastros de Projeto e não Pulmões. Lastros são virtuais (é a diferença entre a data/budget acertado com o cliente e a data/budget estabelecida como meta para a equipe) e, portanto não prejudicam a análise da rede em função da solução ótima de nivelamento.
Ishikawa e Guimarães
Normalmente aplicamos o Diagrama de Espinha-de-Peixe ou Ishikawa na identificação de causas e efeitos. Guimarães (Mostra TIC, 2006, Palestra “Urucu/Manaus”) destaca uma aplicação complementar, essencial para SDPM:
- Toda e qualquer atividade deve ser entendida como um processo;
- Como processo, cada atividade terá um conjunto de entradas, consumir recursos e fornecer algum resultado;
- Cada atividade/processo deve ser analisada sob a ótica de 6M de Ishikawa: Mão de Obra, Material, Máquina, Medição, Método ou Meio Ambiente.
O “Meio Ambiente” pode ser uma restrição importante (uma atividade em campo em época de chuvas terá produtividade inferior à mesma atividade em época de seca). O "Método" é o procedimento para a execução da própria atividade/processo, A definição da “Medição” do trabalho a ser desenvolvido permitirá controle adequado do resultado do trabalho (volume/produtividade) e, portanto estimativas mais adequadas dos 3 cenários.
"Mão de Obra", "Material" e "Máquina" são os recursos necessários e suas disponibilidades ou ausências irão refletir no seqüenciamento final de todas as atividades de projeto.
Vale lembrar – em especial no caso de aplicação do Spider Project Professional – que o “dinheiro” é um “material especial”, cujo controle de entradas/saídas também permite melhorias na programação das atividades de um projeto.
A capacidade do Spider em nivelar atividades de projeto com base a fluxo de caixa e também entender o consumo individual de materiais em função de recursos humanos ou equipamentos (cálculo de consumo em atribuição de recursos) fazem desta ferramenta um instrumento único no mercado para cronogramas baseados em restrições (RCP – Resource Critical Path).
Conteúdos relacionados
- Fragnets, Gerenciamento de Riscos, Nivelamento de Recursos, Otimização de Cronogramas, Análise de Indicadores de Projeto, Gerenciamento por Tendências, Análise de Valor Agregado, CPM,CCPM, RCP, entre outros. Estes e outros tópicos são apresentados pelo autor em http://www.revoluting.com
O Autor
Peter Mello detém as certificações do PMI®: PMP e PMI-SP.