The Spider Team

Planejamento, Execução e Controle: A importância de simulações baseados em um exemplo no segmento de Petróleo

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Thu, 28 Oct 2010 13:54:00 +0000

Entre minhas apresentações, esta é uma de minhas favoritas e hoje descobri que já teve mais de 4000 visualizações no Slide Share.

Aguardo comentários!

Planejamento, Execução e Controle: A importância de simulações baseados em um exemplo no segmento de Petróleo

View more presentations from Peter Mello.

Por onde andam meus textos?

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sun, 05 Sep 2010 12:33:00 +0000

Senhores,

Agradeço aos que andam repassando emails perguntando sobre os textos na Mundo PM, sobre minha participação nas listas e meus seminários em eventos do PMI.

Este ano comecei a trabalhar em uma segunda edição do meu livro com o Delarue (www.thespiderteam.com/forense) e me envolvi em um grande programa/projetos fora de minha cidade, reduzindo meu tempo livre para textos soltos, comentários e blogs.

No entanto: Resolvi não submeter o livro a regras de copyrights da editora e vou publicá-lo gradativamente online e gratuitamente em www.thespiderteam.com/performance

A tentativa de pegar o livro atual e oferecer amplos exemplos em Spider e Excel (Spider por minha conta e Excel pelo esforço do Ricardo Delarue) também se mostrou cansativa para o leitor final e - por esta razão - a nova versão - a ser reescrita do zero depois de completarmos 200 páginas em parceria - está focada em exemplos práticos com o Spider.

Isso porque:

- A versão gratuita do Spider permitirá que estudantes e GPs em projetos de pequeno porte possam adotar em 100% os exempos, dicas, perigos e vantagens de técnicas de análise de performance destacados no site.

- Usuários de outras ferramentas profissionais (leia-se aqui Primavera, visto que o MSProject não está preparado para fazer certo as contas necessárias) poderão repassar conceitos e alertas ao seu próprio ambiente.

Das 200 páginas já elaboradas para o livro que não será publicado, 5% foram convertidas para o site e o restante será repassado gradativamente na medida em que eu perceber que há usuários para esta aventura de análise de performance em projetos.

O "livro virtual" está sendo editado em um formato online que permite sua impressão em PDF sem muito estresse e também uma leitura confortável para usuários IPAD.

Este novo projeto - cujas páginas são transcritas para o site apenas quando estou fazendo as pontes "porto alegre - belo horizonte", "porto alegre - brasilia", "porto alegre - fortaleza" e "fortaleza - brasilia" (estou voando de 5 a 10 horas por semana), não inclui a parte de análise forense de cronogramas (visto que é o Delarue que aborda este tema na primeira edição), mas tem pontos muito importantes sobre Análise de Valor Agregado, Gerenciamento por Tendências, Curvas, etc.

De tempos em tempos, pode ser que eu traga algo daquele site para este blog.

Abraço,

Peter.

Babaquices: Scrum x PMBoK

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Fri, 02 Jul 2010 06:42:00 +0000

Jose Finocchio Jr has sent you a message.
Date: 6/28/2010
Subject: Debate Scrum X

Peter,

Gostaria de ouvir sua opinião no debate Scrum X PMBOk,
Voce poderia dar sua opinião no grupo de discussão GERENCIAMENTO DE PROJETOS, basta seguir o link abaixo.

Um abraço

Finocchio

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1812399&discussionID=23478386&goback=%2Eanh_1812399

===============

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.

Evento Internacional (Grécia): Green Project Management

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Fri, 23 Apr 2010 14:15:00 +0000

Em Junho, a X25/The Spider irá apresentar um trabalho sobre o Gerenciamento Verde de Projetos em um evento internacional na Grécia.

Peter Mello é o representante brasileiro para o evento especializado na área, organizado pela Associação Greco-Americana de Gerenciamento de Projetos. O evento irá trazer informações sobre otimização de resultados em projeto a partir da aplicação de conceitos de Lean e Gerenciamento Verde de Projetos.

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

Gerenciamento Verde de Projetos

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sat, 03 Apr 2010 10:39:00 +0000

Aeroporto de Porto Alegre, via celular.

Cuidado! Não confunda gerenciamento verde de projetos (Green Project Management) com gerenciamento de projetos verdes!

Aqui estamos falando de gerenciamento voltado a otimização de resultados, com atenção a redução de desperdicios durante a realização do projeto, independente do seu produto estar relacionados a sustentabilidade do planeta.

O assunto será tratado em um evento na Grécia pela associação greco-americana de projetos, em conjunto com uma visão lean aplicada a projetos em junho.

Serei um dos keynote speakers e voltarei a escrever sobre o assunto por aqui.

Chegou o avião. 20 minutos para catilografar esta pequena nota...

Interfaces - A comunicação em essência

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sun, 28 Feb 2010 16:34:00 +0000

Estamos já cansados de ouvir que 90% do tempo do gerente de projetos é dedicado a comunicação e que mais de 70% dos projetos que falham tem a comunicação como o seu maior problema.

Até onde a comunicação pode ser uma entidade abstrata, onde entendemos sua importância mas não sabemos como interagir para garantir resultados adequados? Até onde o entendimento dos envolvidos, a criação de matrizes de responsabilidade e planos de comunicação podem assegurar melhores resultados em projetos?

Como diria qualquer bom consultor, "DEPENDE...". E aí, para cada projeto, para cada tipo de cliente, para cada situação de projetos teríamos regras, necessidades e objetivos bem distintos em relação a comunicação que precisa ser feita.

De forma prática. Como podemos fazer a diferença? Gerenciando INTERFACES.

Sinceramente não sei se pesquei o termo em alguma leitura específica sobre o assunto. Não posso dizer se o termo foi já abordado por alguém, mas há alguns anos eu defino como crucial em meus projetos o controle sobre INTERFACES e faço este controle explicitando em meus cronogramas a minha relação com terceiros.

Neste contexto, ao decompor meu projeto em sua EAP, no primeiro nível vou ter elementos específicos do produto que pretendo entregar e também um item dedicado à gestão. Em algumas empresas com quem já trabalhei ou acompanho suas atividades, é comum neste segundo nível da EAP (considerando o projeto completo como o primeiro nível) que utilizem áreas da empresa para então definirem as partes dos produtos que serão elaboradas.

Ilustrando este caso, teríamos que para a entrega de um sistema de transporte de carvão, no primeiro nível teríamos o projeto em si e no segundo nível teríamos: gestão, engenharia, suprimentos, fabricação, transportes, montagem e pré-operação. Se olharmos a seco as "melhores práticas em EAP" preconizadas pelo PMI, teríamos um foco em entregas de produto, quebrando o segundo nível talvez em torres, galerias, etc. De fato, isso pouco importa e poderemos tratar isso em outro blog... Precisamos sim ter a nossa EAP direcionada a entregas, mas estas entregas não precisam ser necessariamente resultados visíveis para o cliente (a torre) e podem eventualmente ser resultados visíveis para a equipe (a engenharia da torre, a montagem da torre, etc).

E as interfaces? Bom, não importa como foi feita a EAP, estamos imaginando que há um pacote de trabalho definido como "gestão de projeto" e este pacote ou nível será novamente decomposto em outros elementos. É aí onde entram as interfaces:

PROJETO

+ ENGENHARIA

+ SUPRIMENTOS

+ ...

+ GESTAO

---+ INTERFACES

--------+ COM Fornecedor A

--------+ COM Fornecedor B

--------+ COM O CLIENTE

-------------+ REUNIOES PERIÓDICAS

-------------+ DEPENDÊNCIAS EXTERNAS

------------------= Licença Ambiental Fornecida

------------------= Liberação de entrada para iniciar atividades

------------------= Autorização para supressão vegetal na Área X

------------------= Autorização para supressão vegetal na Área Y

(etc)

E o que é tão importante nestas interfaces?

- Precisamos explicitar as condições externas que podem ou não prejudicar o andamento normal de meus trabalhos. Não adianta reportar que estou atrasado por que não me liberaram o acesso se eu não deixo explícito o momento em que esta liberação deveria ter ocorrido e quando de fato ela veio ocorrer. É a diferença entre estas datas que me favorecem o pleito de prazo junto ao cliente, mediante uma explícita relação de dependências que precisam ser criadas para que venham a refletir no caminho crítico do meu projeto.

Se no início do projeto bastava uma única autorização para entrar no local de trabalho e cuidar do que está acontecendo, então esta autorização tem data certa no meu cronograma e eventuais atrasos serão reportados com as medições de projeto. Em um dado instante, dentro da área em que se esperava trabalhar há subdivisões espaciais que podem ou não serem acessadas pela minha equipe por uma série de razões (uma área tem acesso restrito por conta de alguma instrução do cliente, uma outra área tem um problema de acesso, outra há elementos externos que não permitem o trabalho, etc). Neste momento, torna-se necessário ir a área de Interfaces com o cliente e trazer novos marcos de controle com novas condições externas que irão impactar o meu trabalho no futuro.

Aqui não importa se estamos falando de projetos de engenharia ou de software (ou qualquer outro, desde que façamos a abstração necessária do conceito). Em um projeto de software não é comum que não se possa entrar em uma determinada área por estar interditada por alguma razão, mas é comum não se conseguir acesso a um determinado tipo de cliente ou a uma determinada reunião por razões antes não documentadas.

Ao explicitar em INTERFACES aquelas dependências que consideramos externas e amarrarmos elas à outras atividades de projeto, nós conseguimos algumas coisas importantes:

A) Explicitamos informações que irão apoiar a identificação de quem é a responsabilidade por atrasos;

B) Chamamos a atenção do cliente para os itens que estão travando o nosso trabalho e consideramos de sua responsabilidade;

C) Detectamos impactos e com isso podemos calcular outras alternativas e ajustes em cronogramas para reduzir os impactos;

D) Lidamos com os problemas de forma pró-ativa e clara, ampliando os canais de comunicação e trazendo os clientes a atuarem como parceiros na resolução dos mesmos.

Devemos pensar que após explicitar em nossa área de interfaces que um determinado item passa a repercutir em atraso para o nosso projeto, mesmo que o cliente não concorde com aqueles elementos expostos que afirmamos atrapalhar o nosso projeto nós estamos no LUCRO.

Conflitos são naturais em qualquer projeto. O que precisamos é atuar de forma pró-ativa com eles e solucioná-los o mais cedo possível. Se entendemos que uma dada autorização é necessária para a execução de nossos trabalhos e ao deixar isso explícito no cronograma o cliente afirma que a lógica de dependências não está correta, duas coisas podem então acontecer:

A) Vamos começar com os trabalhos sob responsabilidade do cliente pois ele mesmo disse que aquela dependência não deveria ser considerada;

B) Vamos ter o cliente correndo atrás do problema para que não fique explícito no cronograma que cada adia de atraso é oriundo de suas dificuldades internas e não necessariamente de nossa equipe de projeto.

Ou seja: Dado o conflito, qualquer resolução é favorável ao projeto. Não fazer nada é que seria o problema.

Em um certo cenário em um projeto de menor porte na empresa onde estou trabalhando, o GP do outro projeto veio me contar que tinha um problema de atraso com o cliente e que ele o estava ameaçando de multas. O cliente dizia que uma dada entrega de materiais tinha ocorrido em diversas etapas (em diferentes semanas) e por isso o projeto estava atrasado. O GP dizia que mesmo com o material em campo, não poderia ter seguido com os trabalhos por que dependia de liberações de bases civis de responsabilidade do cliente.

Ao quebrarmos as suas atividades de execução em blocos menores, cada um deles amarrado a sua própria necessidade de materiais e à liberação das bases por parte do cliente, o que conseguimos foi evidenciar que para cada base o material de fato estava à tempo e que os atrasos estavam vinculados à construção civil que não era de nossa responsabilidade, no lugar da chegada de materiais como alegava o cliente.

Explicitar estes elementos não são agradáveis. O cliente de fato vai ficar mal-humorado em ver em uma seção do cronograma um conjunto de atividades que são de SUA responsabilidade. Isso gera conflito, mas é um conflito que favorece a resolução de problemas em favor do projeto (logo a ambas as partes). Esconder as dependências ou não explicitá-las e trazer para o GP o risco exclusivo de arcar com todos os problemas de projetos.

Dai a César o que é de César e dai ao cliente o que é do cliente. Transparência de ações e uma adequada amarração de dependências externas e internas em um cronograma são elementos-chave para o sucesso de qualquer projeto.

Em resumo: No contexto apresentado, INTERFACES é uma seção especial de um cronograma, devidamente estruturada na EAP do projeto, onde deixamos de forma explícita as dependências externas do projeto oriundas de fornecedores e cliente, desde a chegada de um material, a liberação de um documento ou o fornecimento de algum elemento crítico para o projeto. Reuniões, emissões de documento e até mesmo correspondências enviadas e recebidas podem eventualmente fazer parte destas INTERFACES, conforme o GP definir em seu plano de projeto e de comunicação.

2010 a 40 graus...

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sun, 21 Feb 2010 01:48:00 +0000

Quente! E não estamos só falando de temperaturas.

Devo dizer que preciso começar a avaliar minha posição agnóstica (aquele que não sabe ou quer saber da existência de um Deus).

O final de ano de 2009 e os dias seguintes tem se mostrado extremamente alinhados com um bocado de mudanças... Prioridades em 29 de Dezembro de 2009 são completamente diferentes das prioridades de HOJE, fevereiro, um pouco antes de completar 60 dias de radicais mudanças.

Além de um interessante projeto no Nordeste do País que estou assumindo como seu gestor de projetos em conjunto com uma complexa equipe de coordenadores de engenharia, coordenadores de obra, coordenadores de produção, gestores de contrato, entre outros, acabo de ter um documento técnico aprovado por um comitê de eventos em Gerenciamento de Projetos na Grécia...

Estou afastado dos blogs e das listas de discussão, meus habituais vícios e agora tenho um grande volume de responsabilidades que somam um contrato para um livro, um contrato para um projeto, um contrato para o desenvolvimento de um fluxo/método de trabalho aplicado a uma empresa em ampla expansão, uma parceria com o Planning Planet e outras coisas que até mesmo neste momento de reflexão já não consigo lembrar sem ver minha lista de tarefas!

Procuro manter as coisas alinhadas para seguir difundindo conteúdos de acesso livre como sempre fiz... Logo que possível vou começar a republicar os materiais que venho acertando e complementando. A boa notícia é que em meu acordo para o desenvolvimento de novos projetos e métodos com a empresa onde venho investindo a maior parte do meu tempo agora, está previsto a liberação de conteúdos de nossa experiência em projetos lá para o desenvolvimento de artigos, seminários e afins. Isso significa maiores oportunidades de demonstrar com textos práticos o que de fato é possível se desenvolver com a técnica russa SDPM e com a ferramenta Spider Project que também - por sua vez - traz novidades incríveis em 2010 como a capacidade de lidar com caminhos alternativos em projetos.

Abraços a todos e espero retornar a este espaço logo, com temas técnicos interessantes para o desenvolvimento de bons cronogramas e planos de projetos!

Engenheiros & sua capacidade de sonhar...

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sat, 30 Jan 2010 23:49:00 +0000

Talvez seja pelo espírito criativo, ou o desejo de ser prático... Cada vez mais percebo uma grande parte dos engenheiros presos em um mundo de faz-de-conta em relação a tudo o que se passa em gestão de projetos. Não consigo ainda descrever o que os leva a tratarem o projeto no sentido de empreendimento de forma tão distinta do que fazem melhor: o projeto no sentido do design.

Por que é que projetos (designs) são devidamente versionados e aprovados junto aos clientes, mas um engenheiro que faz um plano de projeto ou mesmo um cronograma não se lembra nem de fixar uma linha de base e nem de aprovar de fato as mudanças que vai trazendo ao dia-a-dia do projeto? Onde é que está a distância entre o formalismo do "design freeze" que seria a origem do que se constrói e se entrega e o resto de toda a documentação necessária para que as coisas aconteçam?

Como é que se pode buscar a perfeição em linhas milimétricas que determinam o projeto mecânico, elétrico e hidráulico e não se busca entender de fato as atividades que devem existir em um cronograma para que todo aquele design possa acontecer?

É claro que há exceções entre os engenheiros... Que não fiquem já todos chateados comigo... Mas o fato é que os poucos que se salvam ainda não são suficientes para salvar a maioria dos projetos (empreendimentos) de seus insucessos (atrasos, custos elevados, problemas de última hora, etc).

--- Este assunto ainda precisa ser discursado com mais argumentos. Aqui começa uma auto-provocação.

Bom fim de semana a quem passou por aqui.

o que eh sucesso em um projeto?

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sun, 10 Jan 2010 17:51:00 +0000

(via celular, logo sem acentuacao)

pedro nao era da turma do fundao, e nem um dos melhores da turma. nunca ficou de recuperacao, mas tambem nao ganhou premios. na faculdade, passou em ultimo em sociologia, soh que era filho e neto de medicos e isso nao agradou a ninguem. fez o curso tranquilo, desfrutou de grandes amizades e se formou com um ano de atraso. nao arranjou emprego na area e acabou passando em um concurso federal, para motorista. nos intervalos do trabalho escrevia poesias e de tempos em tempos ganhava algum elogio no blog onde publicava seus textos.

seu irmao assumiu a clinica ortopedica do pai, tinha um super carro. casou-se com uma modelo internacional e vivia em festas chiques, high society. tirou seu phd na alemanha e tinha uma casa de campo. todos os seus anos de cdf na escola e os 10 anos em cursos, residencias e especializacoes culminaram em um premio internacional.

qual foi o irmao que teve maior sucesso na sua vida?

sucesso em projetos eh atender aos criterios de sucesso previamente definidos. e os melhores criterios sao aqueles que apoiam a tomada de decisao durante o transcurso do projeto.

serah que vale acabar o projeto no prazo e no custo? melhor gastar um pouco mais e acabar antes? ateh onde vale atrasar, mesmo a desagrado do cliente e melhor usar os recursos compartilhados garantindo tambem o sucesso de outros projetos na carteira?

perguntar o que define sucesso em projetos eh uma das coisas mais importantes em gerenciamento de projetos. soh que esta pergunta deve trazer diferentes respostas em funcao de cada envolvido (equipe, empresa, cliente, etc) e em funcao de cada fase, etapa e contexto! um gp de sucesso eh aquele que melhor coordena expectativas e resultados para todos os envolvidos, ainda que preservando os maiores privilegios ao seu cliente.

Novos artigos on-line

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sun, 10 Jan 2010 00:49:00 +0000

Conceitos: Diagram Tempo x Caminho (novo)

Definição e aplicação do Diagrama de Tempo Caminho

Acelerando Cronogramas (Crashing) (revisão/complemento)

Demonstração de que o crashing somente em atividades críticas é uma falácia e o comportamento do crashing em cronogramas RCP dependem de um adequado nivelamento de recursos.

Opinião: Saber dizer não (revisão/complemento)

Para cumprir com objetivos em projeto, é necessário estabelecer limites apropriados, junto a equipe, cliente e patrocinadores.

SDPM - 8 passos para a técnica (tradução)

Documento sinalizando os principais pontos tecnológicos necessários para o desenvolvimento do método Success Driven Project Management.

Para acessar este e outros artigos, uma opção é usar o InfoSpider (gerenciador de documentos). Já são 145 downloads em janeiro! Quem tiver problemas no seu uso, favor escrever para info@thespiderteam.com

Em breve: Artigo de um amigo e parceiro! Aguardem.

Peter.

Mais da mesma chatice, mas é uma reflexão

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Sat, 09 Jan 2010 13:54:00 +0000

Em prol da espontâneidade

Aos que me acompanham pelo conteúdo técnico, minhas desculpas por seguir neste tópico (listas e minha saída da Eplan). Isso é efeito do momento e em breve a situação estará normalizada.

Com o cancelamento de minha participação na EPLAN, venho recebendo cópias de emails enviados, com contatos amáveis e outros agradecendo minha saída. Em um resumo, agora sou "criança" por que não "aguentei uma reclamação do Lápis". Também recebi até um pedido de desculpas via Skype do Vitor (como se ele tivesse influência ou culpa nesta decisão) e outros emails curiosos.

Vamos ver se explico a saída de forma definitiva:

1) Não é por que recebi um aviso da moderação, mas por que tem pessoas que se importam com "o calor da discussão que tenho com alguém" e o moderador é então pressionado a intervir. O assunto já foi tópico antes: quem não gosta dos meus emails, que me filtre. Se o Vitor parece me ofender ou se eu pareço ofender o Vitor, isso é problema meu com ele, pois nenhum de nós dois estamos falando obscenidades e sim discutindo!

2) Não é por que preciso de uma campanha de egos. Minha decisão tinha sido tomada em dezembro e recuei por pedidos que - como um colega colocou - poderia virar até novela da globo. Na primeira rodada, a confusão era com o tom da discussão entre o Farhad e eu... Ambos pensamos em deixar a lista, ambos recuamos, mas ele ficou recluso e auto-moderado, o que significativamente reduziu a nossa troca de emails... Ora, se são poucos com quem venho trocando emails e estes vão gradativamente tendo que se moderar e com isso bloquear o que seriam nossas discussões, para que permanecer em uma lista de discussão?

3) Tirando xingamentos e mentiras, argumentos fortes e fracos, exaltações, conceitos certos ou errados, precisam existir em discussões. Temos que ter a liberdade de simplesmente provocar os demais, em busca de um resultado que sirva de ponto comum. Eu particularmente evito afrontas pessoais até levar o primeiro cutucão. E quando recebo, não me ofendo. Apenas respondo, de preferência na mesma altura... O calor sobe? Ótimo! Em stress somos capazes de pensar coisas de forma diferente e até mesmo os erros que podem sair destes momentos podem nos dar uma nova visão do que se discute!

4) A EPLAN era um vício. Eu vinha gastando tempo em emails truncados e reformulações da mesma coisa que já havia sido tratada em outra sequencia de emails... Por que não me livrar dos idiotas que não respeitam a manutenção de discussões e de tabela ainda ganhar tempo para escrever minhas coisas de forma mais ordenada?

5) Não é uma saída definitiva. Me dei férias! Vou trabalhar textos antigos e novos em um novo ambiente, testar novos modelos de interação, organizar pensamentos.

6) A saída não é efeito só da Eplan, mas do meu modo de agir que realmente pertuba. Ao longo dos anos, já recebi reclamações similares da TOC, PMI-SP, etc... É cansativo imaginar um espaço para discussões, aberto para provocações de qualquer um, e depois se sentir travado por que ou as idéias vão além do que querem tratar, ou sou muito chato por que escrevo muito... Bananas! Os filtros estão aí para quem quiser usar... E para quem não quer, de cada rodada "quente" de discussões, abordamos coisas de uma forma diferente que podem nos ajudar a não só pensar fora da caixa, mas viver fora da caixa (como diz meu amigo Ed).

Resumindo:

- Adoro a EPLAN e valorizo o trabalho do Lápis.

- Tenho contato direto com o Vitor e com o Farhad e seus ataques são parte do jogo, bem como minhas respostas. De fato, era este direito que eu queria respeitado, mas "os outros" se não podem contribuir com uma discussão, o que fazem é tolher nossa capacidade de sermos espontâneos.

- Se não é para ser espontâneo e discutir, vou organizar pensamentos e coordenar textos via meu blog! Muito mais simples, me toma muito menos tempo e pode - se existir interação via comentários - ainda provocar evoluções e melhorias no que venho tratando.

Diagrama Tempo x Caminho

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Fri, 08 Jan 2010 12:49:00 +0000

Diagrama Tempo x Caminho

A partir da identificação de elementos notáveis em um projeto, um diagrama de tempo x caminho pode ser tornar um elemento importante para detectar: falhas de lógica do diagrama de redes, impactos no projeto em função de redução de produtividades esperadas, áreas/fases em atraso, entre outros.

Embora tenha uma aplicação visível em projetos como a construção de uma ponte, uma estrada ou gasoduto, um diagrama tempo x caminho também pode ser criado para acompanhar andares de um prédio, número de casos de uso desenvolvidos em um sistema de software e outros projetos onde seja possível caracterizar uma entrega especifica.

No exemplo a seguir, estamos identificando pontos notáveis para a construção de 200 km de rodovia, com duas frentes de trabalho (uma construindo a rodovia do km 0 ao km 100 e outra frente trabalhando do km 200 ao km 100).

(O texto completo já está disponível em PDF, junto com outros que estou organizando. Será publicado se existir demonstração de interesse, via comentários a este post ou solicitação por email - blog.peter@thespiderteam.com)

Incontrolável participante de listas...

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Thu, 07 Jan 2010 02:11:00 +0000

Nova bronca:

- Outra vez recebo um aviso do moderador da E-Plan para conter meus inflados debates nas listas de discussão.

Ok, é mesmo um vício.

Vou em função de um argumento até o fim.

Novamente pertubei à maioria...

E desta vez, estou me desligando definitivamente da lista E-Plan. Me manterei cadastrado em algumas outras só por que quase nunca nada se escreve mesmo, logo não custa acompanhar um pouco.

Vou me dedicar a um livro que já foi rascunhado e retornarei a E-Plan (se o moderador assim me permitir) somente com o livro pronto.

Neste BLOG, estou inaugurando o uso da ferramenta "siga este blog" do Google. Já está ativa há dois dias e ainda não tem assinantes... De repente, já cheguei no máximo da insanidade e ando mesmo falando bobagens...

Com o tempo, saber se terei ou não seguidores deste BLOG é que servirá de termômetro para seguir escrevendo. Se não tiver pelo menos uns 30 até Março, me desligarei deste espaço também. Seguramente minha família irá agradecer se eu passar menos tempo ligado aos meus emails e discussões!

A quem veio até aqui, o meu convite para clicar no botão ao lado e marcar seu interesse por este blog... Outra opção é baixar o meu aplicativo que serve como um gerenciador de artigos e materiais do Spider Team, sendo a maioria de minha autoria.

Informações sobre o aplicativo estão neste link.

Aos que quiserem um contato direto, procurem o skype petersmello (favor falar o assunto pois venho bloqueando uma série de convites que só levam a correntes e sites de pornografia).

Agradeço antecipadamente aos 111 downloads que já tive do aplicativo infospider.exe neste início de ano e os 83 usuários que registraram o Spider Project. Espero que parte deste público se inscreva neste blog também!

Abraço,

Peter.

Quando Atrasar Compensa (Aldo Mattos)

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 05 Jan 2010 13:18:00 +0000

Sobre o assunto "Crashing", vale a leitura do texto do Aldo Mattos que demonstra o "trade-off" entre custos e prazos para a realização de "crashings" em projetos.

As simulações de cenário que ele propõe pode permitir grandes economias em projetos. Encontrar o local adequado para um "Crashing" significa estabelecer bons parâmetros de projeto para aumentar suas oportunidades de sucesso.

No texto do Aldo apenas uma observação (que foi tópico do meu email anterior). O "crashing" que ele demonstra é calculado em cima de uma rede CPM e assim ele está correto ao afirmar que devemos olhar as atividades críticas para sua realização. No entanto, se tivermos o cronograma nivelado por recursos (recomendável), poderemos perceber que o crashing também pode acontecer em atividades não-críticas e temos cronogramas ainda mais realistas pois podemos avaliar diversos cenários em função da aplicação dos recursos e não somente suposições sobre reduções provocadas "no braço" em uma rede CPM.

O texto do Aldo está em:

http://www.aldomattos.com/artigos/Quando_Atrasar_Compensa.pdf

Demonstração - Crashing funciona fora do Caminho Crítico

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 05 Jan 2010 13:09:00 +0000

Crashing

O "Crashing" é uma técnica de aceleração de cronogramas através da redução da duração de atividades mediante a colocação de recursos extras ou uso de horas extras.

Se uma atividade de alvenaria leva 6 dias para ser realizada com uma produtividade de 1m2 por hora e um pedreiro, podemos aumentar as horas de trabalho diárias ou somar um novo pedreiro a equipe para reduzir o prazo.

A noção que temos derivada da aplicação do Método do Caminho Crítico é de que só adianta reduzir a duração de atividades que estejam no caminho crítico. Isso de fato é verdade em cronogramas que não estejam levando em consideração o uso de recursos, mas a transposição da regra para cronogramas baseados em corrente crítica é uma falácia.

====

- O artigo completo está em:

* http://www.thespiderteam.com/infospider/arquivos/strl_artigos_crashing.pdf

Quem quiser ver a prova real rodando em um cronograma, pode acessar a pasta de ARTIGOS no aplicativo InfoSpider. A pasta inclui agora uma pasta sobre crashing, com o texto e também o cronograma em formato SPIDER.

(vale lembrar que o InfoSpider abre arquivos em formato Spider e não precisa de direitos de administrador para rodá-lo em qualquer computador, rodando inclusive em uma pen-drive).

O aplicativo está em:

* http://www.thespiderteam.com/infospider/infospider.exe

ARTIGOS - Curva-S, Valor Agregado, Dependências, entre outros.

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Mon, 04 Jan 2010 16:27:00 +0000

Prezados,

Entre os assuntos discutidos recentemente na lista E-Plan, Farhad e Vitor não vislumbram o uso de múltiplas métricas para acompanhamento de projetos. Eles, como muitos, confundem multiplas visões de um projeto e suas respectivas métricas com complexidade em projetos, o que não é verdade!

O artigo strl_conceitos_curva-s_analise_valor_agregado.pdf mostra a facilidade de se ter múltiplas curvas a partir de um mesmo (e bem elaborado) cronograma. Temos com isso redução de riscos em projetos e oportunidades para reduzir prazos e custos, tanto para a empresa que realiza o trabalho quanto para o cliente.

O artigo pode ser acessado de duas formas:

A) Acesso direto ao arquivo em:

http://www.thespiderteam.com/infospider/arquivos/strl_conceitos_curva-s_analise_valor_agregado.pdf

B) Através do INFOSPIDER. O InfoSpider é um aplicativo que cria uma lista de artigos, tutoriais e referências onde estou compilando artigos novos e antigos.

Para baixar o infospider:

http://www.thespiderteam.com/infospider/infospider.exe

Lista de artigos já publicados no InfoSpider:

Tutoriais

01.Criando Atividades

02.Utilizando Recursos

03.Utilizando Materiais|.

04.Utilizando Calendários

05.Realizando Medição e Controle

Artigos

Conceitos: Caminho Critico e Corrente Crítica

Conceitos: Curva-S e Valor Agregado

Conceitos: Dependências entre atividades

Considerações sobre EAPs

Projetos Verdes

Revista World Pipeline: SDPM

Documentação Técnica SPIDER

Primeiro contato Spider

White Paper (Funcionalidades)

Comparativo com MS-Project

Múltiplas visões para relatórios

Seminários

Portfólio, Corrente Crítica e SDPM

***********************

Em breve, mais de 20 seminários, artigos, debates, exemplos e outros materiais estarão disponíveis pelo aplicativo. É uma aplicação leve que facilita a identificação e leitura de materiais. Funciona como um gerenciador de documentos remotos.

***********************

Espero que gostem do Gerenciador de Documentos! Espero que no futuro ele possa ser utilizado para apoiar a divulgação de textos de outros colaboradores da área de projetos e não apenas os artigos de minha autoria.

Achados e Perdidos

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Fri, 01 Jan 2010 11:03:00 +0000

Entre as dezenas de postagens e respostas que faço para listas de discussão, há momentos em que invisto um bom tempo em algum conteudo e que depois não ganha um espaço além da resposta na própria lista.

O artigo Nivelamento Baseado em Fluxo de Caixa permite uma avaliação de fluxo de caixa em projetos e o seu balanceamento em função do resequenciamento de atividades para garantir a realização de atividades que possam ser suportadas pelos pagamentos recebidos.

Em resumo:

- Projetos possuem aportes (entradas);

- Projetos têm despesas (saídas);

- A sequência estabelecida para um conjunto de atividades pode melhorar ou piorar o fluxo de caixa, obrigando a empresa a complementar o caixa mediante empréstimos, atrasos de pagamentos com fornecedores, entre outros;

- A reorganização de atividades baseada na restrição financeira permite a avaliação de múltiplos cenários. O que é melhor? Atrasar o projeto e acertar o fluxo de caixa ou pegar um empréstimo por um curto período e antecipar a conclusão do projeto?

O artigo contém dezenas de ilustrações sobre o assunto.

2010 - Micro Projetos

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Fri, 01 Jan 2010 08:05:00 +0000

Brasília, 01 de janeiro de 2010, 6:05 AM

Acredito que de uma forma ou de outra, todo mundo toma alguma resolução na virada de um ano. Assim, ao listar um monte de objetivos a serem alcançados em 2010, eu não estou fazendo nada diferente e um dos meus objetivos para 2010 é o de explorar minha criatividade em fazer a diferença.

Por onde começar? Estabelecendo um ambiente de trabalho propício e implementando projetos.

Um primeiro desafio é o de ser capaz de me organizar por projetos! Estou criando então um laboratório de micro projetos, onde vou estabelecer uma metodologia mínima para sua realização. Há muito entendo que métodos e técnicas essenciais para a sobrevivência de grandes projetos podem melhorar a taxa de sucesso daqueles outros que por serem tão pequenos são postos apenas como itens de uma "lista de tarefas".

Vamos ser francos: Temos que estabelecer uma diferença entre o que são itens para uma lista de tarefas e o que são projetos, ainda que sejam mini projetos, executados por uma única pessoa ou com pequena ajuda de terceiros.

Itens para se colocar em uma lista de tarefas:

- Pagar o IPVA do carro;

- Ligar para um amigo com quem não converso há anos;

- Renovar a carteira de habilitação (e posso estar enganado).

Micro Projetos

- Organizar um novo blog;

- Desenvolver uma metodologia para tratar mini projetos;

- Manter a postagem de um artigo técnico por semana;

- Perder peso!

- Organizar as caixas postais (para o meu caso pelo menos, que detenho dezenas de domínios e escrevo dezenas de emails diários)...

METODOLOGIA para Micro Projetos

- Por esta postagem no blog, estabeleço a abertura oficial de um pré-projeto chamado "MMP" (Metodologia para Micro Projetos).

- Como um dos primeiros itens a abordar nesta metodologia, vou considerar pré-projeto todos aqueles candidatos a projetos que ainda não tiveram um planejamento mínimo para determinar pelo menos:

- RESPONSÁVEL
- MOTIVADOR

- LISTA DE ENVOLVIDOS

- ENTREGA PRINCIPAL

- OUTRAS ENTREGAS

- CRONOGRAMA MACRO (Marcos de entrega)
- CRITÉRIOS DE SUCESSO

- DIÁRIO DE BORDO

(e outros itens que também serão parte do desenvolvimento do próprio MMP)

Um diário de bordo ou mesmo um portal de projeto são elementos que não só favorecem o desenvolvimento de um bom projeto, mas preparam terreno para que os demais projetos se beneficiem de lições aprendidas. Assim, a MMP deverá estabelecer um mecanismo básico para a manutenção de um portal de projeto ou um diário de bordo.

Até segunda ordem (abertura oficial do projeto MMP e a criação de um ambiente propício ao seu desenvolvimento), neste blog deverei manter um diário de bordo específico para este caso.

PORTFÓLIO de MICRO PROJETOS

Um elemento fundamental que percebo nos 30 minutos que já gastei na elaboração desta postagem é de que ao falar em micro projetos que precisam ser organizados e mantidos como pré-projetos é que a metodologia deve já nascer sendo capaz de lidar com a noção de um portfólio de projetos. Assim, o sucesso de alguns micro projetos serão garantidos com a adequada seleção e priorização dos mesmos em relação a dezenas de outros que se não forem devidamente tratados irão apenas sobrecarregar os envolvidos e reduzir desordenamente a capacidade produtiva dos mesmos.

Aqui a situação se complica pois de uma forma ou outra, estabelecer formas de lidar com este portfólio também pode ser um micro projeto. Para facilitar a evolução dos trabalhos, devo provocar este tópico a ser tratado como uma entrega secundária do projeto MMP.

LISTA DE TAREFAS:

Seguramente os itens a seguir pertencem apenas a uma lista de tarefas até que possam ser apropriados dentro de um ambiente organizado e distribuídos entre os projetos e pré-projetos adequados.

- Criar um novo blog para comportar a reorganização desejada para 2010;

- Listar os candidatos a Micro Projetos a serem tratados em 2010;

- Percorrer pendências de 2009, estabelecendo quais tarefas se relacionam a esforços que deverão ser abandonados ou aqueles que deverão ser reorganizados sob a ótica de um portfólio de micro projetos ou transformados em projetos "de fato".

Brasília, 01 de janeiro de 2010, 6:50 AM

** COMPLEMENTO as 11:03 AM:

- Foi criado o website para A METODOLOGIA PARA MICRO PROJETOS

Tópicos: Cronogramas baseado em restrições (2)

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Wed, 23 Dec 2009 18:15:00 +0000

* CLIQUE AQUI para listar este texto junto com todos os demais artigos sobre Cronogramas Baseado em Restrições. Isso pode ser feito antes de ler o texto, para identificar os demais conteúdos relacionados.

* CLIQUE AQUI para ver a primeira parte deste artigo.

Dando continuidade ao tópico sobre Cronogramas baseado em restrições, temos a obrigação de nos perguntar por que tão raramente encontramos cronogramas com recursos de fato definidos para cada tarefa. O CPM – Critical Path Method é considerado a base para o planejamento moderno de projetos e ainda assim ignora fatos do mundo real em uma modelagem de um cronograma: disponibilidade de recursos.

Se meu cronograma me serve para acompanhar contratos e serviços de terceiros, posso me dar ao luxo de pensar em um primeiro momento de que é adequado criar apenas dependências entre tarefas e ignorar a ausência ou disponibilidade de recursos.

Ao tomar esta atitude, como está de fato o cronograma do terceirizado que irá me prestar o serviço? Ele está a par dos recursos efetivos que necessita para cumprir seus compromissos comigo ou não foi tudo um chute e em breve o projeto começara a se atrasar com toda a culpa sobre o Murphy e nunca sobre o fato de que o cronograma era apenas ficção científica desenhado em uma folha de papel?

Na minha cabeça, como cliente ou contratado, cronogramas SEMPRE precisam ter recursos aplicados. O nível de detalhe é determinado pelo tipo de projeto, sua duração, seus riscos, maturidade das equipes, conhecimento prévio do assunto, entre outros. Ainda assim, atividades não ficam pairando soltas no ar.

Dizem que reconhecemos um bom líder quando encontramos alguém que prefere tomar uma decisão errada a não tomar decisão alguma. Em um cronograma, é mais adequado errar em todas as estimativas de recursos necessários, cargas e durações do que simplesmente omiti-las de meu planejamento.

Para dar continuidade ao assunto, vou criar algumas ilustrações com o uso da versão gratuita do Spider. Para aqueles que estiverem interessados não só em acompanhar os conceitos, mas experimentar variações em um planejamento em função de recursos, eu solicito a instalação do aplicativo que pode ser feita pelo site do The Spider Team.

Nota: Embora no primeiro artigo desta série eu tenha dito que existem algumas diferenças entre cronograma baseado em restrições, CCPM, SDPM e RCP, eu acredito que somente os cronogramas extensivamente trabalhados com a aplicação de recursos são dignos de serem chamados de cronogramas baseados em restrições e - neste contexto - todo e qualquer texto que eu falar sobre o assunto poderá ser achado pela tag [RCP].

(Este assunto continua em posts previstos para 2010).

Tópicos: Cronogramas baseado em restrições

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 22 Dec 2009 14:01:00 +0000

Falar em Cronogramas baseado em restrições é um pouco diferente de falar de Corrente Crítica e de RCP (Resource Critical Path - Caminho Crítico de Recursos), mas há uma interseção entre estas definições.

As definições a seguir não são completas e irão divergir de certos contextos descritos por certos autores. Elas são importantes para criar um pensamento inicial do que vou tratar neste e nos demais artigos sobre o assunto:

1) Corrente Crítica: Definição cunhada por Goldratt e que corresponde ao que no PMBOK é descrito como “caminho crítico alterado por recursos”. Em termos genéricos, corrente crítica seria o somatório da identificação do caminho crítico das tarefas (CPM) e do caminho crítico dos recursos (RCP), com algumas observações a seguir.

2) CPM: Método desenvolvido no final da década de 50 e que busca compreender o menor tempo possível de um projeto através do seqüenciamento lógico das atividades. É caracterizado por uma solução matemática, desenvolvida por J. Kelley, que estabelece que o caminho crítico é a seqüência de atividades que determinam o início e fim de um projeto e que possuem folga zero entre as atividades.

3) RCP: Conceito que complementa a busca pelo menor tempo possível para um projeto. Após a criação do diagrama de redes e a definição do caminho crítico das tarefas (CPM), o próximo passo é carregar cada atividade de seus recursos necessários e descobrir as sobrecargas dos mesmos para então criar uma nova seqüência de atividades. Novamente procura-se identificar a seqüência cuja folga entre atividades seja igual a zero, mas esta folga é determinada pela disponibilidade dos recursos e não pelo relacionamento entre as atividades dentro do diagrama. O próprio J. Kelley tentou descobrir fórmulas para calcular o RCP e desistiu pelos anos de 64/65, pois se percebeu que não há uma fórmula única e um cronograma baseado em restrições (de recursos) é resultado de algoritmos computacional (tentativas e erros) e não de uma única solução.

NOTA: Corrente Crítica difere de RCP, pois pode ser construída com a identificação de alguns gargalos (algumas restrições) e não todas as restrições possíveis de serem descritas em um cronograma. Além disso, corrente crítica não irá considerar como restrições de recurso a disponibilidade ou ausência de materiais e de dinheiro.

Como resultado, posso ter um Cronograma baseado em Restrições utilizando: CPM + Nivelamento de Recursos (o equivalente a RCP), ou utilizando Corrente Crítica, que seria o equivalente a aplicação de CPM + nivelamento parcial de recursos (gargalos identificados).

Vale ressalvar que o uso de datas fixas em cronogramas (datas resultantes de acordo externo e não efeito do diagrama de redes) também caracteriza o uso de restrições e assim podemos também ter um cronograma CPM como um cronograma baseado em restrições, embora extremamente limitado se comparado à identificação da Corrente Crítica e do RCP.

Também vale lembrar que qualquer diagrama de redes que não tem restrições (datas externas, recursos humanos, materiais, equipamentos e dinheiro) deveria sempre ser igual independente do software em uso, visto que o caminho crítico em CPM é matematicamente calculado e não resultado de algoritmos.

AQUI - Link para a 2a parte deste artigo.

(Este assunto continua em posts previstos para 2010).

Primeiro dia sem E-Plan

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 22 Dec 2009 13:43:00 +0000

As vezes percebemos um vício só quando estamos nos desligando dele!

Nos últimos anos, a E-Plan vem sido uma companhia para o dia e noite. Muita propaganda, certamente, mas já tenho um dedo e olhos críticos treinados, para passar rapidamente por dezenas de emails e apagar todos os que não quero ler. Tenho alguns filtros pré-configurados também.

Após a enésima confusão nesta lista (e que já aconteceu em tantas outras), onde pessoas que não querem o trabalho de garimpar o que gostam ou não gostam reclamam de minha abundante participação e comentários, eu desiti de seguir insistindo. Hoje, vendo os emails sobre a confusão, vejo que (como alguém colocou na própria lista), virou novela da Globo. É até legal ver emails de gente pedindo para que eu e Farhad continuemos com nossas discussões e para ignorar reclamações dos que seriam - além de minoria - completamente fora do contexto de uma lista de discussão... Mas verdade seja dita, com elogios ou reclamações, o que temos é discussões inócuas e desinteressantes. Para uns, parece que eu e Farhad estamos na lista pelos louros e elogios, para outros, para vender software ou cursos e assim por diante.

De fato vendo produtos e serviços. São eles que dão suporte ao meu tempo livre para divagar sobre gerenciamento de projetos, discutir técnicas, ler variantes, aplicar conceitos e reportar resultados. Não posso ter vergonha disso. Também sei que ofereço muito mais valor em termos de conhecimento gratuito do que invisto em propaganda de serviços, etc. Assim, que cada um pense o que quiser, fale bem ou mal, eu ainda assim preciso de listas de discussão para evoluir com minhas pesquisas e trabalhos... Só que vou ser mais eletivo... Vou provocar discussões em grupos focados em algum tema (como fiz com um grupo de defensores do EVM junto a NASA)... Vou organizar meus textos e idéias e deixar que venham comentar - se estiverem interessados - em meu próprio blog. Mais comodo, mais organizado e eventualmente não tão interessante para mim (gosto da contínua necessidade de explicar e defender um tópico diante da visão crítica de outros).

Não penso em deixar de participar da lista. Mas não vou participar como antes.

Assuntos que me interessarem, eu vou talvez postar algo em meu blog. Ou vou só seguir acompanhando o tópico até que ninguém mais fale sobre o assunto... O provocador, chato, insistente, repetitivo, argumentativo, morreu... Ou como disse o Farhad, está de férias.

Tópicos para 2010

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Mon, 21 Dec 2009 17:21:00 +0000

Em função dos principais tópicos que mais me envolvi em 2008/2009, segue aqui a lista de artigos que pretendo escrever para 2010.

Aqueles que quiserem dar sugestões podem escrever para assuntos@thespiderteam.com ou deixar um comentário.

- Curva-S: Aplicações em geral e também quando se refere a Análise de Valor Agregado

- Gerenciamento Ativo de Riscos: integrando riscos e incertezas aos cronogramas

- Cronogramas baseados em restrições: O efeito pessoas e máquinas.

- Cronogramas baseados em restrições: O efeito materiais.

- Cronogramas baseados em restrições: O efeito dinheiro.

- Indo além do caminho crítico: CPM, PERT, SDPM, CCPM.

- Pontos fortes e fracos das técnicas CCPM (Corrente Crítica) e SDPM.

- Pontos fortes e fracos de estimativas por tendências usando EVM.

- Medições de avanço de projeto: Como fazer e o que esperar.

- ... (esta lista irá crescer através de sugestões e comentários)

Feliz Ano Velho - Uma nova era para este BLOG

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Mon, 21 Dec 2009 11:43:00 +0000

Dezembro - São Paulo, Porto Alegre e Brasilia

Enquanto viajava para atender clientes, me deparei com determinados momentos onde não tinha condições de fazer um dos meus passatempos favoritos: Ler e escrever na EPLAN, maior lista de discussão em Gerenciamento de Projetos do País.

Finalmente cheguei em casa e repassei mais de 400 emails em busca de tópicos que pudessem estimular uma discussão e como de costume encontrei pouca vida inteligente, a maior parte ao redor dos assuntos em debate com o Farhad.

Se alguém quiser fazer um filtro rápido nesta enorme e democrática lista para encontrar algo que não seja propaganda de cursos (que eu faço também), propaganda de softwares (que eu faço também), oportunidades de empregos e pedidos esdrúxulos, basta ver quais emails o Farhad se mete e acompanhar a partir deste ponto.

Ele é um excelente indicador, mas não absoluto. Isso porque de tempos em tempos ele se mete em cruzadas para corrigir ortografias, uso de termos técnicos, siglas com copyrights e outros tópicos que não merecem tanta atenção ou debate.

Como parte da história para aqueles que gostam de fofoca, eu e Farhad já fomos inimigos mortais. Me ligavam no celular para dizer "não chegue perto dele pois se ele seguir contra você e não tiver mais como argumentar contra, vai colocar uma cinta de bombas na cintura e se explodir ao lhe dar um abraço!". A época era algo ao redor de 2004. A razão era o Clube PMP, um fórum online onde eu reuni em 20 meses cerca de 2400 pessoas e onde as coisas giravam em torno de post publicos, onde comecei a desenvolver minha paixão por artigos na área de Gerenciamento de Projetos.

Em seu nascimento, o Clube PMP foi visto como uma ameaça as comunidades oficiais do PMI. Talvez por que criticava o fato dos capítulos não terem uma unidade nacional (hoje já existe) e por oferecerem vantagens somente a associados (enquanto o Clube era gratuito). A situação ficou crítica quando ao buscar patrocínio para manter a hospedagem do site, a X25 fechou uma parceria comigo e o que eu passei a escrever não só era a "opinião e trabalho do Peter", mas também propaganda de uma empresa.

Verdade seja dita, a parceria com a X25 deu tão certo que meu curso em projetos (o GP2000 na época e o InteliMedia atual) - um pacote extenso e gratuito - recebeu registro junto ao PMI como a primeira iniciativa de uma PMI R.E.P. no Brasil para a difusão de conteúdo gratuito em gerenciamento de projetos. Um ano depois, além de dar cursos e coordenar cursos na X25, fui então convidado a fazer parte de fato da empresa, me tornando um sócio minoritário desta empresa que compartilhava comigo um senso de responsabilidade social, sempre dedicando parte do seu tempo a iniciativas e comunidades de cunho social e gratuito.

O Clube morreu. Foi atacado por hackers e depois quando tentamos dar um cunho de organização social efetiva (com o objetivo de ser um portal para iniciativas em projetos e não uma associação concorrente ao PMI), um de seus membros foi levado ao conselho de ética do PMI nos Estados Unidos. Embora "julgado inocente", literalmente "encheu o saco" ficar nadando contra a maré e fechamos o Portal. Cerca de R$ 250,00 em seus 3 anos de vida do Clube PMP foram levantados para a criação de uma associação de fato e por conta dos hackers, parte desta enorme quantia de dinheiro não foi devolvida a alguns contribuintes pois eu perdi o contato com os mesmos. Se você um dia contribuiu com o Clube e eu ainda lhe devo uns 10 ou 15 reais, por favor entre em contato comigo. Também levantei outros R$ 100,00 com o que seria a nova edição do Curso GP2000 e não pude entregar o material diferenciado que prometi para quem pagou uma "ajuda de custo" e não recebeu um contato meu depois (pela mesma razão, visto que foram três ataques de hackers que destruíram o banco de dados do site).

No meio desta história, fiquei de fora da Lista de Discussão do PMI-SP por um conjunto de razões. Além de minhas provocações, por acidente retornei uma mensagem enviada a lista EPLAN com diversos links a todos os destinatários, entre eles o PMI-SP, assim ferindo a regra de não mandar links para aquela lista. Este crime, somado ao desconforto de minhas provocações anteriores, se transformaram na minha expulsão (e só fui perdoado em 2009).

Farhad, veio me conhecer melhor em 2006/2007 e desenvolvemos então uma amizade fora do comum. Concordamos em muitas coisas, complementamos um ao outro em argumentos e defesas e não chegamos a um ponto de acordo em muitas outras. Nossos debates calorosos e cheios de provocações são de fato resultado de uma parceria e cumplicidade e não inimizade.

NÃO AGUENTO MAIS O FARHAD E O PETER

Em 20/12/2009, eu e Farhad trocamos cerca de 15 emails sobre Análise de Valor Agregado e suas variantes. Como de costume, ele vinha discordando de uma ampla aplicação da técnica que eu promovo, explicando se tratar de uma técnica especifica para contrato entre o cliente e o gerente de projeto a luz do que prega o Departamento de Defesa Americano (DoD). Por outro lado, ele promovia indicadores similares oriundos do que seria um "Performance Earned Value Management" baseado em diversos autores... Ainda que a conclusão não tenha sido alcançada, eu e ele estamos falando de coisas essencialmente similares e complementares, mas talvez baseado em uma terminologia diferente.

No calor desta discussão, me entra na lista um idiota cuja única contribuição para a lista aconteceu em 2008 quando perguntou algo sobre como usar o MS-Project. Este indivíduo indignado por ver sua caixa de correio cheia por uma discussão sobre um tema do qual ele deveria ter vergonha em não ser capaz de entender e fazer seus próprios comentários, ele se deu ao trabalho de criar um movimento "Fora Peter e Fora Farhad", logo assinado por outras três outras pessoas que como ele não são capazes de fazer algo muito simples: Criar um filtro na caixa para eliminar emails de qualquer pessoa de que não gostem, permitindo aos outros que gostam de discussões e várias vezes demonstraram aprenderem com elas seguirem acompanhando nossos debates.

Recebi no mesmo dia 35 emails de apoio. Mensagens do tipo "deixe os pequenos com suas cabeças pequenas e siga trazendo suas provocações e referências pois todos aprendemos com elas". Em várias outras listas eu já passei por estas discussões e tudo sempre gira em torno de "esse cara fala demais, ou seus debates com o Farhad são intermináveis".

Muitos não se tocam do que assinam: Uma lista de discussão. Não é uma lista de empregos, ou de amizades, ou só do que cada um espera ver, pois são necessidades e perfis diferentes em enormes comunidades. A EPLAN já há muito passou 5000 usuários.

Eu e Farhad poderíamos escrever em PVT? Claro. Mas ter um público que de tempos em tempos interfere, complementa e nos ajuda a entender onde precisamos reforçar o raciocínio é parte do processo que desenvolvemos em uma discussão.

MAS CHEGA. Invisto muito de meu tempo pelo prazer da provocação e da redescoberta, quando alguém se convence de algo ou me convence de outra coisa... No entanto, estar em um cenário onde idiotas e interessados estão juntos já não vale o esforço.

A partir de agora, vou elaborar meus textos, artigos, discussões e críticas através deste blog e meus artigos habituais, por minhas próprias listas... Para quem quiser, aqui neste blog podem ser deixados comentários e pedidos por algum assunto específico.

E assim "Estou de saco cheio de idiotas em listas de discussão"

Aos que não gostam de mim um macete: É só fechar o browser e não voltar neste endereço!

O dia que todo mundo gostar de mim, estou fazendo algo errado. Essa é a base do meu raciocínio para buscar avanços na minha carreira, na minha capacidade de pensar, julgar e abstrair.

E Feliz Natal para todos! Está aberto uma nova era para este BLOG.

Artigo - Futurologia?! (Cronogramas Probabilisticos)

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 01 Dec 2009 20:33:00 +0000

FUTUROLOGIA AO ALCANCE DE TODOS?!

Quem é que disse que não podemos prever o futuro?
A questão é trabalharmos adequadamente as probabilidades
e sabermos quais margens de confiança podemos estabelecer
para cada situação.

Imagine que eu vá jogar um dado. Posso dizer com 100% de
certeza de que vou tirar alguma coisa entre 1 e 6, certo?
Viu? Posso prever o futuro.

Se eu não fizer questão de acertar em 100%, posso dizer
com 50% de certeza que ao jogar um dado, você irá obter
como resultado um número par.

Da mesma forma, uma medida de sucesso em um projeto pode
ser realizada com a aplicação de cronogramas probabilísticos...

(texto completo em http://br10.net/futurologia)

=========================================

Últimos dias: Licenças do SPIDER DESK2000
Desconto de lançamento (50%)
http://thespiderteam.com/spiderdesk2000
=========================================

Comemoração Pessoal! Prêmio Internacional.

noreply@blogger.com (Peter Mello, SpS, PMP, PMI-SP) — Tue, 17 Nov 2009 11:31:00 +0000

Brasília é reconhecida por excelência em Gerenciamento de Projetos pelo

Project Management Institute através do
Eric Jenett Project Management Excellence Award.

(ver press release do PMI)

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.

(ver entrevista na Mundo PM)