Tag Archives: MSP

[E-Plan] – Disponível o Spider SCPM para download

  By petersmello | 10/02/2012 - 1:35 am | Publicações
Leave a comment

(cópia de e-mail publicado na E-Plan em 09/02/2012)
___________________________________________________

 

O Spider CPM será o novo substituto do MS-Project nos projetos do dia-a-dia!

100% gratuito;
“100″ limite de tamanho para os projetos;
“100″ limite de campos do usuário (texto, numérico, datas)
“100″ erro em cálculos financeiros

 

     Use sinais e fórmulas simples relacionando campos do usuário e traga tabelas inteiras de controle de produção, chegada de materiais, emissão de notas fiscais, controle de time-sheets, registro de entregas para o cliente e dezenas de outras atividades em projetos nas áreas de Construção Civil, Montagem Mecânica, Desenvolvimento de Software e etc.

     Gere curvas-S imediatamente, demonstrando avanços entre o previsto x realizado; Utilize Valor Agregado sem erro de fórmulas e contas como a concorrência; Utilize recursos avançados em CPM para a identificação de atividades para crashing ou fast-tracking em projetos; Veja o caminho crítico de projetos; encontre folgas livres e totais sem complicação.

 

** Encontrou um BUG? **

     Conheça o melhor suporte tecnológico em um produto disponível no mercado! A Spider Management Technologies atende “bug fixes” com um tempo médio inferior a 10 dias, garantindo assim que o seu software realiza as funções que se presta a realizar, sem você ter que esperar aquele super lançamento da versão 2015, ou 2020…

     NOTA: A garantia de software livre de bugs é mantida para os usuários de versões pagas, apesar deles buscarem imediatamente a resolução de qualquer problema encontrado também em versões gratuitas. Esta observação é apenas por que a Spider se reserva ao direito de não atender o usuário gratuito com a mesma
presteza de um usuário pago, mas eu aposto minhas Certificações PMI que se você se deparar com qualquer bug, vai ver sua solução MUITO antes do próximo PACK Microsoft!

 

*** POR QUE é GRÁTIS ? ***

1) Vladimir Liberzon, arquiteto do Software e Presidente da empresa, tem no Spider uma criação para garantir a execução de suas atividades como Gerente de Projetos e não para ganhar dinheiro… Os mais de 50.000 usuários pagantes nos países da extinta União Soviética já lhe garantem os proventos que necessita
para ele e suas próximas gerações.

2) Porque em algum momento você vai entender que CPM (Critical Path Method) é uma metodologia incompleta e com grandes deficiências e aí você vai decidir utilizar o Spider Professional que faz o melhor nivelamento de recursos do mundo!

3) Porque em algum momento você vai ver que as concepções de Portfólio das soluções americanas (HP, IBM, EPM, Clarity, Primavera, etc) são incompletas e com grandes deficiências e aí você vai decidir utilizar o Spider Professional para unir os projetos de sua empresa em um grande painel de controle onde recursos compartilhados podem ser nivelados, controlados geridos no âmbito do Portfólio, permitindo a simulação antecipada de novos empreendimentos em sua carteira.

4) Porque nós do Brasil sabemos que você já está viciado no MSProject e aprendeu a tocar aquele violão com uma cópia pirata, ou de um amigo, ou aquela licença meio utilizada em várias máquinas de sua empresa e nós queremos que você tenha a oportunidade de aprender um novo software com a possibilidade de utilizá-lo
profissionalmente em sua empresa mesmo que ela não tenha como investir $$ em tecnologia.

 

*****
AJUDE A DIVULGAR!
O SPIDER fornece soluções gratuitas que já estão em uso em dezenas de projetos desde 2008 e os objetivos do The Spider Team vão muito além dos objetivos mercadológicos da concorrência! Nós queremos debate, aprendizado, melhoria…
Participe desta aventura conosco e ADOTE UMA ARANHA
*****

 

www.thespiderteam.com/licenciamento
(cadastro, download e uso do software SCPM gratuitos)

 

     Clique no “EU GOSTEI” em nossa página para o Facebook e nos ajude a incrementar a teia da aranha! Assista vídeos e apresentações sobre temas educacionais na área de projetos e mande sua sugestão dos assuntos que quer aprender, ensinar ou debater com nossa equipe!

 

Precursores da Aranha no Brasil:
- Jefferson Guimarães, primeiro usuário pagante do Brasil!
- Alexinaldo Alves, primeiro usuário brasileiro a exportar o Spider para a
Bolívia!
- Peter Mello, primeiro brasileiro a receber um treinamento pelos Russos!
- Marcus Possi, primeiro autor de livros sobre o Spider no Brasil, já publicado
em 4 edições e em inglês e Português!

     Junte-se a estes e a pelo menos outros 500 usuários do Spider no Brasil.

 

     No máximo o que pode acontecer é a Microsoft ficar VERDE de inveja ou ciúme e decidir dar o suporte ao seu produto que nós usuários e ex-usuários de versões pagas deste software esperamos por tantos e tantos e tantos anos!!

 

—-
Aviso legal: As opiniões, convites, declarações, especificações e comentários
deste e-mail são a opinião pessoal de Peter Berndt de Souza Mello e não
correspondem à declarações e afirmações da Spider Management Technologies. Nesta
lista de discussão, convido todos a fazer sua própria interpretação crítica do
que é ou não é surpreendente sobre o Spider Project.

Considerações sobre Hammoks e Exemplos aplicados

  By Isadorasm | 23/06/2009 - 5:42 pm | Publicações
Leave a comment

     No Practice Standard of Scheduling (publicação do PMI®), uma hammock é colocada como sinônimo de tarefas-sumário e deveriam, portanto reunir informações sobre a duração das atividades a ela vinculadas.

     O termo hammock surgiu muito antes do standard e tem implementações com funções mais completas em softwares como o Primavera e Spider.

     Como mecanismo básico, a hammock é “presa nas pontas” por outras atividades distribuídas no projeto e portanto passa a ter a duração da rede entre as atividades que “esticam as pontas da hammock”. O nome “hammock” corresponde a outro tipo de rede: aquela de dormir, como as que vemos no Ceará ou nos barcos de transporte do Amazonas.

     Uma hammock portanto pode ser uma sumarizadora de atividades que estão em distintas partes de uma EAP. Diferente da Tarefa-Sumário como encontramos no MSProject, ou as “Fases” no Spider, a hammock pode ser influenciada por elementos distribuídos por todo o projeto, sem uma hierarquia pré-definida.

 

O texto completo contém:

- Ilustrações de diferentes tipos de hammock.
- Aplicação na distribuição de atividades de projeto.
- Cálculo de desperdícios.
- Simulação de opções de nivelamento em projeto.

 

Abra o texto completo em PDF em:
[link ainda não disponível em função das mudanças do site do Spider Team]

Tarefa Hammock (Debate) – Parte II

  By Isadorasm | 21/06/2009 - 7:55 pm | Publicações
Leave a comment

Antes de continuar, algumas considerações:

1- Este material surgiu em função de um debate na lista da E-Plan.
2- Você pode visualizar a parte I do Debate (Clicando aqui)
3- Você pode saber mais sobre o tema abortado – Hammocks & Exemplos aplicados – (Clicando aqui)

___________________________________
Carta de Farhad Abdollahyan sobre Hammocks:

 

     Caro Peter,

     Para começar, no exemplo não sei de onde vem a Corrente Critica (30 dias)!!! E depois o 25 dias, dado que as atividades supostamente tinham 10 (C) e 20 dias (A, B e D) de duração!

     Dependendo da maneira que nivelarmos o projeto, passamos de 40 dias sem nivelamento para 50 ou 60 dias, dado que o caminho crítico sem nivelamento é Início-A-B-Fim. (0+20+20+0). Se colocarmos uma prioridade maior no C, o MS Project nivelará a atividade A e teremos:

“corrente crítica” = (C)Farhad 10 + (A) Farhad 20 + (B) Peter 20 = 50

Senão teremos

“corrente crítica” = (A) Farhad 20 + (B) Peter 20 + (D)Peter 20 = 60

     Em segundo lugar, creio que está cometendo um erro crasso de conceito e outro de entendimento do problema!

     Quando escreve que “Se eu prender uma atividade HAMMOCK em INICIO e FIM e colocar FARHAD e Peter como recurso utilizado nela” não faz menor sentido. Uma atividade “Hammock” ou “Summary Activity” é “um grupo de atividades do cronograma agregadas, relacionadas em algum nível de resumo e exibidas/relatadas como uma única atividade no nível de resumo”, em outras palavras, uma Hammock não é uma atividade de verdade, é apenas uma sumarizadora, portanto, não devemo alocar recurso nela diretamente.

     Para criar uma HAMMOCK, criamos um marco de início e um de fim e relacionamos logicamente as atividades desta sub-rede (ou sub-projeto) e temos uma hammock. No MS Project conseguimos este efeito criando uma indentação, e o SW demonstra uma barra preta variável (como você disse) cujo início tem uma relação início a início com a primeira atividade da rede e o seu ponto final tem uma relação término a término com a última (no seu exemplo “início” e “Fim” respectivamente).

     De certa forma, representa o pacote de trabalho.

     O outro erro seu é que recomenda uma atividade sumarizadora para o colega que tem dois grupos de atividades distintas:

     (1) Atividades que irão produzir as entregas propriamente ditas, e (2) Atividades de fiscalização e apoio que não geram entregas tangíveis.

     Se indentar as atividades principais e criar a super guarda-chuva (HAMMOCK) não irá resolver o problema do colega, pois o que ele quer realmente é poder inserir atividades de fiscalização e apoio.

     E não se trata de questão de SW, pois para dizer a verdade, o MS Project até permite associar recurso a esta atividade sumarizadora (e calcularia os custos como o colega quer), mas este macete tem dois problemas: (a) MSP soma os custos das atividades de sub-rede com os custos dos recursos alocados diretamente na Hammock e mostra tudo no Hammock, isto pode confundir! (b) Da mesma forma que não é correto colocar predecessor ao nível da Hammock, não devemos também alocar recurso no Hammock.

Abraço,

Farhad

 

———————————————————————————————————
Peter Mello, em resposta a carta:

 

      Farhad,
      Meu erro foram as unidades. Eu comecei com a unidade DIA e depois coloquei o custo HORA. Onde eram 20 e 10 dias, eu fiz o exercício com 10 e 5 dias (portanto basta dividir os seus achados por 2 para acertar com meu erro de unidades).
O raciocínio está correto e os resultados (ajustados) também:
- seus 60 dias seriam os meus 30
- seus 50 dias seriam os meus 25.
- o valor hora é de fato R$ 1,25 (para dar os R$ 10,00 por dia que usei nas minhas contas)
No entanto:

      A) O MSProject precisa que você faça ajustes manuais durante o nivelamento para achar o melhor resultado. Se você tiver 4 ou 40 atividades, vai conseguir fazer a priorização correta e ter um bom retorno. Se tiver 400 ou 4000 atividades, não pode depender de priorizações manuais para encontrar o melhor nivelamento
      B) O MSProject não mostra a corrente crítica. Apenas coloca em vermelho os elementos pertencentes ao caminho crítico CPM e portanto todas as folgas não tem qualquer utilidade.
      Quanto aos usos da HAMMOCK:
      - A descrição da Hammock no Practice Standard of Scheduling nasceu DEPOIS das hammocks serem inventadas e aplicadas em diversos softwares. Não é por que o Practice Standar diz que a hammock só pode ser utilizada para A, B ou C que ela também não possa ser usada para D, E ou F. No entanto, a regra MÍNIMA estabelecida para uma hammock é que ela seja capaz de agregar durações provenientes das atividades que ela sumariza. No Standard, tarefa sumário e hammock são sinônimos, o que não é exato. A hammock se presta a sumarizar atividades que não estão em subitens da mesma decomposição da EAP, enquanto a tarefa sumário está sempre presa a estrutura hierárquica da decomposição.
      - Por estas “funções extras” da hammock que não estão no Practice Standard e nem no MSProject, mas estão no Primavera e no Spider é que a hammock se presta exatamente ao que o colega quer, durante sua análise de fiscalização.
     - Você sabia que durante o preparo do Practice Standard houve uma votação para ver se “cronograma nivelado por recurso” deveria entrar ou não no Standard? Como a base dos desenvolvedores é americana e eles usam CPM e prestam pouca atenção a CCPM ou qualquer método que faça nivelamento adequado de recursos, cronogramas baseados por recursos quase não foram contemplados no Practice Standard.
     - Se isso tivesse acontecido, isso iria fazer com que as pessoas que utilizam corrente crítica ou resource critical path deixassem de usar ? O standard não é prescritivo e sim descritivo.
Vou preparar um PDF com tudo, para você ver como funciona.

 

Abraços,
Peter.

Tarefa Hammock (Debate) – Parte I

  By Isadorasm | 20/06/2009 - 9:42 pm | Publicações
Leave a comment

Antes de continuar, algumas considerações:

1- Este material surgiu em função de um debate na lista da E-Plan.
2- Você pode visualizar a parte II do Debate (Clicando aqui)
3- Você pode saber mais sobre o tema abortado – Hammocks & Exemplos aplicados – (Clicando aqui)

 

Carta de Farhad Abdollahyan sobre Hammocks:
___________________________________________

 

—– Original Message —–
From: Farhad Abdollahyan, PMP
To: planejamento@yahoogrupos.com.br
Sent: Friday, June 19, 2009 12:06 PM
Subject: [E-Plan.br *9 Anos*] – Re: Tarefa Hammock

 

      Caro Peter,
      Não pretendo polemizar, mas cabe alguns esclarecimentos:

     (1) o colega usa MS Project, não SPIDER ou Primavera, portanto, o que lhe aconselhei resolverá o problema dele.

     (2) O que eu estou colocando, em termos de pacotes de trabalho e atividades gerenciais, também deve ser valido em qualquer outra ferramenta (Spider, I-Nexus, Primavera, Clarity, etc.), pois, a partir do momento em que alguém colocasse uma atividade que começa com marco inicial do projeto e que termine com o marco final esta tarefa se transforma em um dos caminhos críticos do projeto.
É simples assim!
Se nivelasse esta atividade, em qualquer SW decente de GP, o prazo total do projeto irá estender, o que convenhamos é um contra-senso total!
     (3) Não faz sentido de fazer nivelamento de recursos em atividades gerenciais (fiscalização e apoio) se este nivelamento afetar as datas de entregas técnicas, pois como mencionei “… é correto considerar atividades gerenciais como críticas apenas por que estão no caminho crítico? Estas tarefas realmente atrasam o projeto? A resposta é não!”, ou pelo menos não deveriam! Você não deve atrasar um projeto por que não tem fiscal para liberar ou homologar uma entrega. Não é uma boa prática! Ao contrário, deve adicionar recursos ou mudar a fiscalização de tal sorte que esta atividade não se torne burocrática atrasando o projeto, não acha?
     (4) O que defendo é que as atividades (meio) de apoio gerencial, ou devem ser espalhados ao longo de todos os pacotes de trabalho, ou devem ser concentrados num subprojeto sem amarração com as entregas para não afetar o cerne, ou seja as entregas (fim) que adicionam valor ao cliente. Alias, esta minha posição é respaldada pela técnica de Product-based Planning do PRINCE2.
Se pensar um pouco fora da caixa (do SPIDER), pelo menos por alguns momento, verá que tenho razão.

 

Forte abraço,
Farhad

 

——————————————————————————————————
Peter Mello, em resposta a carta:

 

     Farhad,

     Você se esquece que quando dá uma informação genérica e categórica sobre hammock sem de fato dizer onde se aplica sua resposta, você infelizmente vai passar a informação equivocada para quem não está acompanhando a mensagem desde o início.
Somente alguns – que leram todo o thread – vão saber que o colega usa MSProject e que sua resposta é PARA este caso em particular.

     Quanto as suas afirmações:
     I – “Se nivelasse esta atividade, em qualquer SW decente de GP, o prazo total do projeto irá estender, o que convenhamos é um contra-senso total!”
Errado. Um bom software de nivelamento poderá de fato descobrir formas de REDUZIR o tempo global de projeto por perceber o custo que a atividade de fiscalização tem no projeto. Ele irá buscar alternativas de mudança de prioridades nas atividades reais de projeto para que o valor global do projeto seja REDUZIDO. Lembre-se: a hammock não determina o tamanho do projeto. Ela tem o tamanho de suas atividades determinadas pelas atividades a qual se relaciona. Se eu mudo a ordem entre elas, a hammock DIMINUI.

Exemplo:
Inicio>A>B>Fim
Inicio>C>D>Fim
- A, B e D tem 20 dias
- C tem 10 dias
- A e C são executadas por FARHAD
- B e D são executadas por PETER
- FARHAD custa R$ 10,00 a hora
- PETER custa R$ 10,00 a hora.
- Se eu prender uma atividade HAMMOCK em INICIO e FIM e colocar FARHAD e Peter como recurso utilizado nela, então o software irá calcular:
- Farhad: Uso em A, C e também em todo o tempo restante do projeto.
- Peter: Uso em B e D.

     NOTA: após o envio do email (editado no Blog): As durações A,B,D são de fato 10 dias e C apenas 5 dias. O valor de R$ 10,00 é por DIA, não por HORA.

     Se eu utilizar um nivelamento padrão de mercado, eu vou ter a rede nivelada por recurso assim:

Corrente Crítica (30 dias)
- Início>A (FARHAD, 10 dias = 100 reais) > B (PETER, 10 dias = 100 reais) > D (PETER, 10 dias = 100 reais) > FIM
Caminho Não Crítico:
A > C (FARHAD, 5 dias = 50 reais) > FIM
Hammock:
- Irá calcular o custo de Farhad quando não estiver trabalhando = 30 dias – 15 = 15 x 10 = R$ 150,00
- Irá calcular o custo de Peter quando não estiver trabalhando = 30 dias – 20 = 10 x 10 = R$ 100,00

     CUSTO FINAL DO PROJETO = R$ 300 (corrente critica) + R$ 50 (caminho não crítico) + R$ 250,00 (hammock)

     TOTAL: R$ 600,00 (ou 30 dias com 2 pessoas a 10 reais cada)
Se eu utilizar o nivelamento de um BOM SOFTWARE (que você disse que ia aumentar o projeto), o resultado é:

Corrente Crítica (25 dias)
- Inicio>C (FARHAD, 5 dias = 50 reais) > B (PETER, 10 dias = 100 reais) > D (PETER, 10 dias = 100 reais) > FIM
Caminho Não Crítico:
C > A (FARHAD, 10 dias = 100 reais) > FIM
Hammock:
- Irá calcular o custo de Farhad quando não estiver trabalhando = 25 dias – 15 = 10 x 10 = R$ 100,00
- Irá calcular o custo de Peter quando não estiver trabalhando = 25 dias – 20 = 5 x 10 = R$ 50,00

CUSTO FINAL DO PROJETO = R$ 250 (corrente critica) + R$ 100 (caminho não crítico) + R$ 150,00 (hammock)
TOTAL: R$ 500,00 (ou 25 dias com 2 pessoas a 10 reais cada)

 

CONCLUSÃO:
A) A hammock não muda o caminho crítico;
B) A hammock permite o cálculo gerencial de desperdícios em projeto;
C) A hammock apoia o software em tomada de decisão quanto ao melhor sequenciamento entre recursos.

     II – “(3) Não faz sentido de fazer nivelamento de recursos em atividades gerenciais (fiscalização e apoio) se este nivelamento afetar as datas de entregas técnicas… é correto considerar atividades gerenciais como críticas apenas por que estão no caminho crítico? Estas tarefas realmente atrasam o projeto? A resposta é não!”, ou pelo menos não deveriam! Você não deve atrasar um projeto por que não tem fiscal para liberar ou homologar uma entrega.”

     Farhad: Claro que não queremos atrasar um projeto por que a fiscalização não homologou alguma coisa. Mas o fato é que isso ACONTECE e portanto tem que ser levado em consideração em nosso projeto!

     Meu papel não é remover um problema do meu modelo de cronograma por que não quero que ele aconteça. Meu papel é colocar o problema no modelo e descobrir qual é a forma de minimizar o impacto caso isso aconteça. Portanto, exatamente por que um fiscal pode de fato atrasar o projeto e se tornar uma atividade crítica embora não deva ser, eu preciso definitivamente tentar trazer esta situação para o meu modelo e ver alternativas para lidar com o problema!
Você continua “Ao contrário, deve adicionar recursos ou mudar a fiscalização de tal sorte que esta atividade não se torne burocrática atrasando o projeto, não acha?”

     Claro que acho! Exatamente por que pode ser necessário adicionar mais recursos de fiscalização para evitar os problemas é que eu preciso calcular o TEMPO, os RECURSOS e os CUSTOS desta fiscalização como parte do meu projeto!! Somente se eu colocar esta situação no meu cronograma e descobrir COMO atuar com ela é que vou eliminar o problema e não simplesmente tirando a atividade de fiscalização do meu projeto!

Abraço,

 

Peter.

Dúvidas sobre caminho crítico e nível de confiabilidade da duração do projeto

  By Isadorasm | 16/10/2008 - 1:11 am | Publicações
Leave a comment

Carta de Davi Amorin
________________________________________________

 

—– Original Message —–
From: amorimdb
To: MS-Project@yahoogrupos.com.br
Sent: Thursday, October 16, 2008 4:29 PM
Subject: [MS-Project] Dúvidas sobre caminho crítico e nível de confiabilidade da duração do projeto

 

     Pessoal,

     Eu sou usuário recente do MSP e estou precisando de ajuda para solucionar um exercício de gerenciamento de tempo, onde tenho que:
1) Elaborar o diagrama de rede, explicitando o caminho crítico.
2) Apresentar o cronograma com recursos alocados e nivelados.
3) Apresentar a duração do projeto com 95,5% de confiabilidade.

     O que fiz até agora foi:

     Elaborar o cronograma com os recursos alocados, onde a partir disso pude obter o diagrama de rede e caminho crítico (após formatar o assistente de gráfico de Gantt). Apesar disso, não pude “interpretar” o caminho crítico. Realmente não entendi. O nivelamento dos recursos foi quase ok, apenas um recurso ficou superalocado em parte. Mas como faço para, a partir do caminho crítico, calcular via estimativa de três pontos a duração do projeto com 95,5% de confiabilidade?

     Se alguém tiver interesse, posso enviar o arquivo mpp.

 

Davi Amorim

 

_________________________________
Peter Mello, em resposta a carta:

 

     Amorim,

      Se com uma única estimativa e análise de caminho crítico fosse possível ter confiabilidade de 95,5% em um projeto, não teríamos falhas em planejamento. Você precisará obter – no mínimo – os valores otimista, provável e pessimista para cada atividade.

      Mecanismos básicos para se ter “faixas” de confiança podem ser vistos com a aplicação de PERT, o uso de Monte Carlo ou aplicação de SDPM.

      Eu sou usuário da última (SDPM – Success Driven Project Management) e portanto você encontra referências sobre o assunto em www.sdpmworld.com

      O primeiro ponto a entender de uma ‘estimativa com confiança’ é a de que não se tem uma data final, mas um período.

 

Exemplo:

- Se tenho 3 atividades sequenciais e cada uma leva de 2 a 10 dias, então meu projeto irá variar de 6 dias (3 x menor caminho) a 30 dias (3 x maior caminho).

- Se o tempo mais provável em cada tarefa é 4 dias, então com o PERT eu teria:

Pert = (Otimista + 4x Mais Provavel + Pessimista)/6 = (6+4×12+30)/6 = 14
Desvio = (pessimista-otimista)/6 = 4

Resultado: O tempo esperado do projeto é de 14 dias (50% de confiança), com um desvio de +/-4 para cada sigma.

Com 2 sigmas, temos 95,5% = 14+8 = 22 dias.

** Isso significa dizer que com 50% o projeto acaba até o dia 14 e com 95,5% ele acaba em até 22 dias **

 

Atenção:
- Muitas pessoas fazem o cálculo de desvio somente em atividades no caminho crítico e embora isso já seja melhor que resultados deterministicos, a “corrente crítica” do projeto pode estar mascarada (caminho mais longo do projeto após o nivelamento de recursos) e de fato pelo menos ela deveria ser avaliada em relação aos cenários otimista, pessimista e mais provável.

- Após chegar no resultado dentro da probabilidade desejada, se o cronograma final utilizar estas durações ele provavelmente também irá atrasar. Isso ocorre pelo fenômeno natural de que atrasos em uma tarefa se propagam as outras e os ganhos (adiantamentos) normalmente são desperdiçãdos. O ideal é que embora vc estime que o projeto acabe em X dias, o cronograma da equipe seja de X-n dias para que represente um DESAFIO para a equipe.

 

(técnicas como Método da Corrente Crítica e Success Driven Project Management lidam com estes fenômenos através do uso de reservas/buffers de projeto)

 

Abraço,

Peter Mello

** P.S. Me envie seu cronograma em MSP para novos comentários.