2/06/2012

Blogs em www.Gestaodeprojetos.com.br

**
Postagens de Peter Mello estão agora em www.gestaodeprojetos.com.br
**

Prezados,

Na data de hoje, estarei iniciando uma coleta generalizada de posts, artigos, seminários e conteúdo relacionados aos trabalhos do The Spider Team e também de minha autoria, para publicação em novo endereço.

10/28/2010

9/05/2010

Por onde andam meus textos?

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.

7/02/2010

Babaquices: Scrum x PMBoK

**
Postagens de Peter Mello estão agora em www.gestaodeprojetos.com.br
**

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.

4/23/2010

Evento Internacional (Grécia): Green Project Management

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

4/03/2010

Gerenciamento Verde de Projetos

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...

2/28/2010

Interfaces - A comunicação em essência

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.


2/20/2010

2010 a 40 graus...

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!




1/30/2010

Engenheiros & sua capacidade de sonhar...

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.

1/10/2010

o que eh sucesso em um projeto?

(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.

1/09/2010

Novos artigos on-line


  • 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.
  • 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


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.

1/08/2010

Diagrama Tempo x Caminho

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)

1/07/2010

Incontrolável participante de listas...


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.


1/05/2010

Quando Atrasar Compensa (Aldo Mattos)

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:

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

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

1/04/2010

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


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:
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:

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.

1/01/2010

Achados e Perdidos

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

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


12/23/2009

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


* 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).

Ocorreu um erro neste gadget