Project Management Canvas, com José Finocchio Jr

José Finocchio
José Finocchio

Hoje, em nossa série Metodologias de Gerenciamento de Projetos, falando sobre a metodologia Project Management Model Canvas, temos José Finocchio Jr. autor do livro “Project model Canvas: Gerenciamento de Projetos sem Burocracia”, co-Autor de  “Fundamentos de gerenciamento de projetos” adotado como livro-texto na FGV (Fundação Getúlio Vargas), palestrante em vários congressos de Gerenciamento de Projetos do PMI e do Brazilian Oil & GAs.

Como surgiu a ideia do Project Model Canvas?

Eu me inspirei em Diversos autores líderes na área de gestão: EM primeiro lugar devo citar o Dan Roam e em seus livros entre eles desenhando negócios, O David Sibett com sua metodologia de facilitação prática (possui três livros publicados alguns deles em português). O David Rock com “Conceitos de neurociência” (foi de lá que tirei o pitch), o Simon Sinek com “O poder do WHY” e é claro a estética do livro “Business Model Generation” me influenciou na estética do Canvas (Mas há que se ressaltar que um business plan é radical mente diferente de um plano de projeto, em primeiro lugar um modelo de negócio é concebido para durar e o projeto é feito para terminar). E sim o movimento ágil em influenciou também especialmente a Mary Poppendieck. Continue lendo “Project Management Canvas, com José Finocchio Jr”

Stakeholders – O Túnel do Tempo

Assita no DailyMotion: Stakeholders – Túnel do Tempo

No fantástico e improvável cenário de uma instalação secreta do governo norte-americano, dedicada à incrível tarefa de criar uma máquina do tempo, uma cena muito comum na rotina de gerentes de projeto pelo mundo a fora: ter que lidar com os stakeholders. Nos trechos do primeiro episódio da série, você pode ver como o gerente de projetos, o especialista e o patrocinador (representando o cliente) interagem sobre as expectativa do projeto.

E você? Como lidaria com uma situação do tipo? Deixe um comentário! Até a próxima!

Papo GP Responde: Escopo

 

EmailOlá Diego. Estou na faculdade e temos que fazer um projeto […] … Eu gosto muito de projetos mais estou meio perdido no escopo.

– Sandoval

Boa noite, sou estudante de engenharia mecânica em São Paulo e vim morar um ano em Montevideu para aprender espanhol e desenho técnico, só que arrumei um emprego aqui e tenho algumas ideias para mostrar na concessionaria que trabalho. Meu gerente quer que eu monte um escopo com planilha etc…. como faço? Você pode me ajudar? Estou desesperado.

– Jean Continue lendo “Papo GP Responde: Escopo”

Escopo e Requisitos

Na mosca!
Na mosca!

Qual a diferença entre escopo e requisito?

O escopo é aquilo que deve ser feio/entregue/criado. O escopo de um produto é a descrição do que se espera que o produto seja. O escopo do projeto é a descrição do que se espera que o projeto faça (normalmente, que entregue o escopo do produto!). Continue lendo “Escopo e Requisitos”

10 Dicas para Coleta de Requisitos

Na mosca!
Na mosca!

Os requisitos do projeto são uma parte de fundamental importância para a definição não só do escopo, mas também dos objetivos do projeto. Quando os requisitos não são claros, a chance do projeto não ter sucesso ou ter apenas sucesso parcial (por que deixou de atender a necessidade do cliente, por exemplo) é muito maior. Os requisitos são determinados pelas partes interessadas do projeto, todas elas ou as mais importantes e ativas.

Continue lendo “10 Dicas para Coleta de Requisitos”

Resposta PMP II

O RISCO DE NÃO ATINGIR OS OBJETIVOS E A QUALIDADE DO PROJETO

pode ser minimizado através de um monitoramento continuo
é considerado um risco de longo prazo
será refletido no uso cotidiano do produto/serviço
B e C
todas acima

Resposta Correta: todas acima. A não-adequação final do projeto aos requisitos de qualidade é sim um risco de longo prazo, pois estes costumam ser os mais sacrificados perto do final do projeto quando problemas ocorrem (estouros de Custo e/ou Prazo), e também por que o aval do cliente só vem com o termino do projeto e a apresentação final de seus Deliverables, que pode ou não ser o que o cliente esperava/necessitava. Um delivery que não atende as necessidades do cliente tenderá a causar problemas aos seus processos, demandar retrabalho, atender com eficiência reduzida ao problema a que se dispõe a resolver e/ou até mesmo jamais ser implementado. A melhor forma de se evitar este tipo de situação é monitorar de perto os parâmetros de qualidade do projeto com uma periodicidade regular e não muito entendida, comparando o que está sendo feito com os indicadores/requisitos/objetivos/scopo do projeto e, se possível, recebendo a aprovação do cliente (e ou demais stakeholders necessários) para garantir que a qualidade esteja assegurada.

Lembre-se que as respostas para a certificação devem ser escolhidas sempre pensando na melhor resposta possível.

Delivery: São as entregas das atividades descritas na EAP (Estrutura Analítica do Projeto) e/ou os resultados das etapas do ciclo de vida do projeto. Deliveries podem ser desde documentos, serviços ou até produtos. Por exemplo: o principal delivery da fase de Planejamento é o Plano de Gerenciamento do Projeto. Enquanto o delivery de um projeto de imobiliário pode ser um prédio ou sua planta.

Stakeholders: Stakeholders são as partes interessadas envolvidas de forma direta ou indireta com o projeto. Alguns exemplos de stakeholders são o cliente, o patrocinador do projeto, o gerente do projeto, o time do projeto, a sociedade civil, o governo, a empresa concorrente, uma ONG, ou qualquer outro indivíduo/organização cujos interesses venham a cruzar com o projeto.

Treinamento para certificação PMP, no seu SmartPhone!
Prepare-se para a Certificação PMP no seu próprio ritmo!

Por que projetos falham?

Não é terrível quando um projeto vai pelo ralo? A pior parte é que isso, segundo estatísticas, acontece pelo menos 70% das vezes segundo pesquisa do Standish Group. Parece muito, mas se você levar em consideração a Restrição Tripla (Custo-Tempo-Qualidade), um projeto só é um sucesso se conseguir atender aos requerimentos e especificações do escopo, ou seja, respeitar a Restrição Tripla. 

Mas fora isso… quais as razões que levam um projeto ao fracasso? Aqui vai uma lista dos maiores problemas que costumam ser a sentença de morte da maioria dos projetos. A posição dos mesmos é a minha opinião sobre seu impacto no projeto, e a quantidade de Caveiras, o número de ocorrências do mesmo nas minhas pesquisas.

 

  1. Falta de suporte do sponsor
  2. Falta de envolvimento do cliente
  3. Pouca ou ausência de habilidades interpessoais
  4. Gerenciamento de Comunicações falho ou inexistente
  5. Objetivos e metas mal definidas
  6. Escopo do projeto mal definido
  7. Scope Creep
  8. Planejamento falho ou inexistente
  9. Estimativas de tempo/recursos não realistas
  10. Baixa integração do time
  11. Má alocação de recursos materiais e humanos
  12. Gerenciamento de expectativas do cliente
  13. Inexistência ou mal uso de uma metodologia de gerenciamento de projetos
  14. Gerenciamento de Riscos inexistente
  15. Falta ou mal uso de um controle de mudanças
  16. Pouco ou nenhum tempo para testes
Scope Creep: O temido Scope Creep acontece quando o Escopo do projeto não para de ser alterado, tornando-se sempre maior do que originalmente estava previsto, sem que nenhum recurso seja adicionado ou algum tipo de planejamento. 

Esta lista não exaure o assunto, nem engloba todos os motivos possíveis, muito menos as nuances em que cada item pode se desdobrar, mas já serve como um aviso para navegantes de primeira viajem. Vale também lebrar que o Gerente de Projetos é o guardião do projeto que lhe foi confiado e, irrevogavelmente, a culpa sobre a falha do projeto irá sim cair sobre seus ombros. Mas agora já dá para saber com o que se preocupar. Boa sorte para todos nós.

 

Um exemplo real: Estávamos encarregados de conseguir o financiamento para uma ONG, para um centro de treinamento profissionalizante e; para o treinamento de voluntários para o trabalho em projetos sociais. Os seguintes fatores foram decisivos para o desfecho sofrível de ambos os projetos:

  • Scope Creep: Cada reunião com o financiador do projeto terminava com uma alteração no escopo que tornava o projeto ainda maior do que o planejado sem, entretanto, levar em consideração os recursos alocados e o prazo estipulado;
  • Estimativas de tempo/recursos nada realistas: Além de mim, eram mais três voluntários responsáveis por fazer toda as pesquisas necessárias, bem como escrever o projeto e atender às reuniões;
  • Escopo do Projeto mal definido: a ONG não sabia exatamente o que queria e isso resultava em retrabalho a cada reunião;
  • Má alocação de recursos materiais e humanos: Além de serem poucas pessoas responsáveis por toda a parte pesada do projeto, boa parte do time de voluntários não estava devidamente alocada, nem tinham o devido treinamento para executar as atividades que lhes foram confiadas;
  • 0% de Conhecimento das Melhores Práticas de Gerenciamento de Projetos: Eramos boms de elaborar projetos sociais. Mas quando chegou a hora de botar a mão na massa, as coisas saiam dos trilhos com facilidade, devido a falta de conhecimento de práticas de gerenciamento.


Leia também:
Por que Projetos Falham: 20 Dicas para Gerentes de Projetos

Leia mais em:
http://www.projectperfect.com.au/info_it_projects_fail.php
http://www.itweb.co.za/office/ast/0107120730.htm
http://www.coleyconsulting.co.uk/failure.htm
http://www.onlamp.com/pub/a/onlamp/2006/06/20/why-do-projects-fail.html
http://it.toolbox.com/blogs/lpuleo/why-do-projects-fail-960
http://www.pm4girls.elizabeth-harrin.com/?p=185
http://www.jiscinfonet.ac.uk/infokits/project-management/projects-fail
http://itmanagement.earthweb.com/cio/article.php/2201981
http://en.wikipedia.org/wiki/Kitchen_sink_syndrome

Postar no Del.icio.us

Salve no Digg

Salve no Netvibes

Adicione ao Facebook

Tweet isso!

Enviar para o reddit


Anuncie no LinkedIn

Adicione ao Technorati