Neste endereço, você tem uma opção para navegar pelos 42 processos do PMBOK, clicando sobre cada processo de cada área de conhecimento e verificando o fluxo de informações entre os grupos de processos de Iniciação, Planejamento, Execução, Controle e Finalização.
http://www.thespiderteam.com/pmbok2008
Este blog nasce em homenagem ao novo Spider – Spider CPM (carinhosamente apilidado de SCPM). Esta nova modalidade de licença – 100% gratuita inclusive para uso profissional – é chamada pelos russos de “versão Extra Lite” pois não realiza as operações que fizeram o Spider Project famoso em todo o mundo: O nivelamento de cronogramas em função de recursos (entre eles máquinas, materiais, equipamentos e disponibilidade financeira).
Pouco sabem os russo que apesar de “Extra-Lite” para eles, a ferramenta é eficaz para cumprir o que 9 em cada 10 usuários de MS-Project® fazem: Redes CPM, com pouca ou nenhuma aplicação de recursos às atividades.
Mais curto, mais rápido: Aprenda o Spider CPM em alguns passos.
Esta apresentação é suportada por um vídeo criado por Marcus Possi. Veja o vídeo em http://www.thespiderteam.com/slides/slide001
O Spider CPM é uma ferramenta disponível para que você tenha uma oportunidade de aprender tudo sobre o Critical Path Method e ter uma opção profissional – gratuita- que lhe servirá como uma substituto para o MS-Project® em 9 de cada 10 situações em que se utiliza esta tradicional ferramenta Microsoft.
E não teria graça utilizar uma ferramenta gratuita que lhe custasse uma tonelada de dinheiro em cursos! A oferta gratuita do The Spider Team no Brasil é completa: Cursos, dicas e a ferramenta.
Onde está o peguinha? Nós temos certeza de que você irá se apaixonar pelas possibilidades exclusivas oferecidas pelo Spider e irá contribuir para constituir uma comunidade que irá questionar uma série de atrocidades que encontramos no mundo do Gerenciamento de Projetos. Estamos apostando que em breve você ou sua organização vão perceber que existe muito mais do que o CPM (Critical Path Method – Método do Caminho Crítico) e irá conhecer detalhes sobre o RCP (Resource Critical Path – Método do Caminho Crítico) que é a grande especialidade do Spider Project Professional, a ferramenta líder de mercado nos países da extinta União Soviética e utilizado em projetos, programas e portifólios de grande envergadura.
Para ser um profissional “de mercado”, você precisa dominar o CPM e também irá se beneficiar do uso de Análise de Valor Agregado, dois assuntos cobertos e atendidos pelo Spider CPM. O seu caminho para utilizar o Spider e aproveitar mais sobre estas técnicas, você encontra neste site!
http://spiderproject.com.br/ead
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
A abertura do evento será feita pelo Ministro das Relações Exteriores da Grécia e terá entre os palestrantes representantes da Arábia Saudita, Inglaterra, Grécia, Canadá, Estados Unidos, Japão, entre outros. A palestra “key-note” de Peter Mello irá abordar gerenciamento ativo de riscos, o success driven project managent, técnicas de compressão e melhoria de resultados em cronogramas e redução de custos em projetos através da aplicação do Green Project Management.
Informações sobre o palestrante:
http://conferences.hau.gr/?i=project2010.en.speakers.162
Informações sobre os demais participantes:
http://conferences.hau.gr/?i=project2010.en.speakers
Informações sobre o evento:
http://conferences.hau.gr/?i=project2010.en.agenda
Peter, você poderia dar sua opinião no grupo de discussão GERENCIAMENTO DE PROJETOS? Basta seguir o link abaixo. Um abraço, Finocchio
———————————————–
Peter Mello, em resposta a carta:
Caro José, obrigado pelo convite e desculpe pelo tempo em lhe responder.
Roda na Internet, no meio acadêmico e no ambiente profissional há muito tempo um sentimento de incompatibilidade entre o Scrum e o Guia PMBoK® ou de forma ainda mais ampla uma diferenciação entre Métodos Ágeis e o PMBok.
Vou começar lhe respondendo que aquele que sequer PENSAR que há uma incompatibilidade entre os métodos ágeis e o PMBoK é um BABACA. A coisa é ainda mais grave por que este mesmo babaca também deve pensar que o PMBoK é uma metodologia e nem fora do mundo ágil ele irá fazer bom proveito desta publicação do PMI.
O que me assusta e por isso aqui vou negritar a palavra BABACA é que existem diversos trabalhos de conclusão de cursos circulando por aí com esta estupidez e ela atesta a burrice generalizada dos coordenadores e bancas de exame acadêmico que concordaram com este absurdo.
Já vi tratamentos entre o Ágil e o PMI como se estivéssemos falando da diferença entre o Islamismo e o Cristianismo. Há outros “especialistas” mais hábeis ou políticos que vão falar do PMI e suas publicações e os diversos métodos ágeis como se fossem apenas impressões divergentes entre o Católicos e Luteranos.
Vamos combater esta babaquice generalizada com alguma conceituação básica: O Guia PMBoK® é apenas um compêndio de boas práticas em gerenciamento de projetos e poderá um dia até ser fonte de consulta para conhecermos algo sobre o Scrum ou outros métodos ágeis quando estes forem reconhecidos por algum grupo de envolvidos na manutenção do PMBoK como relevantes àquela publicação.
Note que o fato de um dia o Scrum aparecer no Glossário do PMBoK não fará com que ele seja mais compatível ou menos compatível com o próprio guia! Também sequer irá confirmar que o Scrum é uma boa prática generalizada ou não para o universo do Gerenciamento de Projetos no mundo pois a decisão final sobre a entrada de novos paradigmas no PMBoK está restrita a um pequeno grupo de “autores centrais” destas publicações do PMI que também não estão isentos de serem também uns babacas no entendimento sobre a questão.
Como já adianto que vou ser mal interpretado no parágrafo anterior, me permita completar a explicação: NÃO estou afirmando que sejam uns babacas e muito menos estou falando daqueles que hoje foram os responsáveis pelas últimas atualizações encontradas no PMBoK e outras publicações do PMI. Estou apenas dizendo que a decisão final do que é considerado ou não para o PMBoK em última instância está sempre limitado a um conjunto pequeno de profissionais e normalmente ainda carregados de um “bias” ocidental e/ou americanizado por mais neutro que se esforce em parecer.
Voltando ao Scrum: qualquer equipe de projetos dentro de um paradigma ágil, em maior ou menor grau, pode a qualquer momento se beneficiar de algum conhecimento oriundo do PMBoK ou, ainda, se utilizar de conhecimentos em gerenciamento de projetos que até mesmo aparecem neste Guia e que em maior ou menor grau já são aplicados aos métodos ágeis independente de onde tiverem se originado.
Vale lembrar que o PMBoK não traz nada de novo e sim aquilo que já se configurou como aplicado em gerenciamento de projetos em uma ou mais áreas, em uma ou mais regiões, por um ou mais grupos e que – no momento de sua redação para o PMBoK foram aceitos pelo limitado grupo de voluntários e ainda menor grupo de “autores centrais” desta e todas as outras publicações do PMI.
É relevante destacar que métodos ágeis também podem conviver dentro de um mesmo projeto com métodos convencionais e grupos distintos, utilizando métodos distintos, podem estar todos respondendo a um mesmo gerente de projeto, um mesmo cliente final e para entregar um mesmo produto.
Isso não ocorre somente em uma situação – por exemplo – onde uma equipe está desenvolvendo um hardware qualquer e outra equipe está desenvolvendo o software a ele relacionado (o hardware pode ser uma cafeteira, um computador ou um avião e o software pode ser o contador de minutos de preparo do café ou o sistema de guia de mísseis termonucleares).
Existem situações onde um mesmo software precise ser quebrado em módulos e sub módulos e alguns destes irão ser administrados em uma dinâmica em cascata, outros com a aplicação do RUP e outros mais com o SCRUM.
Outro ponto relevante e que vale apena já destacarmos neste email desta madrugada de sexta-feira é que há diversas demonstrações de métodos ágeis que contribuem para o desenvolvimento de projetos que vão além do desenvolvimento de software. Assim, vou adicionar à categoria de babacas aqueles que disserem que métodos ágeis nunca poderão fazer parte do PMBoK por estarem ligados a uma única indústria (TI) enquanto o PMBoK tem uma condição de espaço generalista (acredite, já ouvi esta barbaridade).
Aproveitando que não preciso oferecer fontes de consulta, encontrar frases de efeito, me valer de citações tiradas de livros importantes para defender de forma idiota um TCC que logo será aceito por um coordenador tão babaca quanto este estudante que busca seu importante título de graduação ou mestrado, vou deixar neste espaço um “alerta geral” para gerentes de projetos tradicionais em qualquer indústria: fiquem atentos aos métodos ágeis e entendam, utilizem, complementem, critiquem e melhorem os seus conceitos pois há muito o que se aprender com o Scrum e com outros métodos ágeis que vale ser aplicado em projetos de todo o tipo e de todo tamanho.
O alerta também vale para os envolvidos com estes métodos, para que evitem radicalismos e oposições extremistas em nome de Alá ou do Scrum Master e tragam o PMBoK para dentro de suas experiências pois também terão o que aprender.
Bom, é até aqui que consigo ir nesta madrugada e talvez volte a completar este texto em alguma data futura (provavelmente em rebate à comentários de alguns dos babacas que irão se ofender com o meu texto).
Abraço do seu ex-aluno, companheiro de seminários e amigo. Me desculpe se o seu debate estiver indo em outra direção no link que me passou, mas não me dei nem ao tempo ou trabalho de segui-lo antes de explicitar a minha indignação com muito do que venho ouvindo sobre o assunto.
Peter.
Brasília Reconhecida por excelência em Gerenciamento de Projetos
pelo Instituto Americano de Projetos
(Project Management Institute)
Brasília, DF, Novembro de 2009
— Peter Berndt de Souza Mello recebeu o prêmio do Project Management Institute (PMI®): “Eric Jenett Project Management Excellence Award” por sua ampla contribuição para a prática da profissão de Gerenciamento de Projetos e demonstrou liderança e iniciativa enquanto desenvolvendo avanços em relação a conceitos, técnicas, práticas ou teorias sobre o Gerenciamento de Projetos.
Peter Mello, Diretor de Projetos da X25 Treinamento e Consultoria (X25), oferece serviços de treinamento e Consultoria para organizações governamentais e empresas privadas. Ele utiliza seus recursos e talentos para desenvolver softwares de distribuição gratuita e materiais relacionados ao gerenciamento de Projetos. Peter Mello é consultor em Gerenciamento de Projetos e Portfólios com trabalhos apresentados no Brasil e exterior, com ênfase no Gerenciamento de Riscos e Gerenciamento de Cronogramas com a aplicação da Metodologia SDPM (Success Driven Project Management) e o desenvolvimento de cronogramas baseado em restrições.
“O Programa de Premiações do PMI reconhece a excelência em gerenciamento de Projetos em diversas categorias para organizações, comunidades, capítulos do PMI, trabalhos voluntaries, produtos e indivíduos,” disse Gregory Balestrero, presidente e CEO do PMI. “Ganhar este prêmio é um testemunho do valor que o gerenciamento de Projetos pode trazer para uma variedade de envolvidos (stakeholders).”
“Eu conheci ao sr. Eric Jenett em pessoa e entendo que suas conquistas relacionadas ao Gerenciamento de Projetos é uma coisa extraordinária. Eu realmente tenho muito orgulho de receber este prêmio, confiado a mim pelo meu empenho particular,” disse Peter Mello.The Eric Jenett Project Management Excellence Award foi criado em honra a Eric Jenett, um dos cinco fundadores do PMI e o fundador do capítulo de Houston. Ele foi um dos seus presidentes e membro do Conselho Diretivo do PMI e foi eleito PMI Fellow em 1982. O prêmio Eric Jenett foi apresentado ao seu ganhador no 4o Congresso Brasileiro de Gerenciamento de Projetos, em Belo Horizonte, Brasil, nos dias 11 a 13 de novembro de 2009.
Após a apresentação de Key-Note do Presidente do PMI (Greg Balestrero) durante o 4° Congresso Nacional em Belo Horizonte, o Chariman do Board do PMI (Ricardo Vargas) entregou o prêmio a Peter Mello, primeiro Latino-Americano a receber a honra. Pela tarde, Peter Mello também fez uma apresentação como co-autor do trabalho aprovado pela comissão técnica escrito por Alexandre Zoppa, Jefferson Guimarães e Mello.
Sobre o Project Management Institute (PMI)
É a organização líder mundial em Gerenciamento de Projetos, com quase 500.000 membros e credenciados em mais de 185 países. Desde a sua fundação há 40 anos, o PMI já influenciou mais de um milhão de praticantes, negócios, governos, estudantes e entidades de treinamento. Hoje, os produtos e services do PMI estão distribuídos em uma grande gama de padrões para Projetos, programas e portfolio, bem como com cinco credenciais para a profissão, incluindo a aclamada certificação PMP® (Project Management Professional). O PMI mantém o “Global Corporate Council” e o “European Corporate Networking Group” relacionado a grandes multinacionais e organizações governamentais, endorsando o valor do Gerenciamento de Projetos. É a única associação de Gerenciamento de Projetos com um programa de pesquisa estabelecido, já tendo investido mais de USD 14 milhões de dólares em suporte a dezenas de Projetos de pesquisa desde 1997. Veja mais sobre a associação em www.pmi.org.
História das premiações do PMI:
http://www.pmi.org/About-Us/Our-Professional-Awards/PMI-Professional-Awards-History.aspx
Press release (PMI):
http://www.pmi.org/About-Us/Press-Releases/Brasilia-Local-Recognized-for-Project-Management-Excellence.aspx
No Practice Standard of Scheduling (publicação do PMI®), uma hammock é colocada como sinônimo de tarefas-sumário e deveriam, portanto reunir informações sobre a duração das atividades a ela vinculadas.
O termo hammock surgiu muito antes do standard e tem implementações com funções mais completas em softwares como o Primavera e Spider.
Como mecanismo básico, a hammock é “presa nas pontas” por outras atividades distribuídas no projeto e portanto passa a ter a duração da rede entre as atividades que “esticam as pontas da hammock”. O nome “hammock” corresponde a outro tipo de rede: aquela de dormir, como as que vemos no Ceará ou nos barcos de transporte do Amazonas.
Uma hammock portanto pode ser uma sumarizadora de atividades que estão em distintas partes de uma EAP. Diferente da Tarefa-Sumário como encontramos no MSProject, ou as “Fases” no Spider, a hammock pode ser influenciada por elementos distribuídos por todo o projeto, sem uma hierarquia pré-definida.
O texto completo contém:
- Ilustrações de diferentes tipos de hammock.
- Aplicação na distribuição de atividades de projeto.
- Cálculo de desperdícios.
- Simulação de opções de nivelamento em projeto.
Abra o texto completo em PDF em:
[link ainda não disponível em função das mudanças do site do Spider Team]
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.
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