PMI
http://www.pmi.org.br/
Site da PMI no Brasil. Explica a fundação do PMI e as metas. Fala também sobre o que é o Gerenciamento de Projetos. Pesquisas, matérias, notícias e agenda de cursos.
Os sites abaixo são chamados de capítulos no Brasil do PMI. Cada localidade tem um representante e um local fixo estabelecido. Pode-se obter informações sobre as atividades, eventos e novidades sobre a atuação do PMI em cada estado brasileiro.
HTTP://www.pmipr.org.br
http://www.pmisp.org.br/
http://www.pmimg.org.br/
http://www.pmirs.org.br/
http://www.pmidf.org
http://www.pmipe.org.br
http://www.pmisc.org.br/
http://www.pmirio.org.br
http://www.pmies.org.br/
http://www.pmiba.org.br
----------------------------------------------------------------
Periódicos e Revistas
http://www.mundopm.com.br
Site da melhor revista sobre Gerência de Projetos do Brasil. Opção de Download dos artigos das edições anteriores. Assinatura custa R$ 125,00. Seis edições anuais. Pode ser feito com cartão de crédito.
http://www.pmnetwork-digital.com
Revista da PMI.
----------------------------------------------------------------
Artigos, Entrevistas, Citações e Notícias.
http://www.gestaodeprojetosbrasil.com.br/
Possui um teste para PMP com gabarito no final do teste.
Fórum de discussão sobre o assunto. É necessário registrar-se para acessar os tópicos do site.
http://www.ricardo-vargas.com/pt/
Ricardo Vargas é especialista em Gerência de Projetos, muito conhecido no ramo. É autor de 10 livros na área. Nesse portal também encontramos artigos, slides e vídeos. Site em português e inglês.
http://www.projectmanagement.com/
http://www.pmforum.org/
Portais em inglês. Contêm fórum e artigos sobre o assunto. Muito utilizado pelos professores na Pós-graduação da FGV.
http://ogerente.com.br
Também contem artigos e entrevistas sobre o assunto. Área interessante dos livros recomendados. Na seção de Gestão de Projetos são mais de 70 indicações. Todos os livros possuem uma resenha sobre o objetivo principal da publicação.
http://gestaodeprojetos.net/
Artigos sobre assuntos gerais na área de TI, como governança e serviços de software. Na seção de Gestão de Projetos encontram-se vários artigos referentes ao tema como viabilidade econômica de um projeto. Assuntos sobre os Recursos e Gerente de Projetos. E dicas para exames certificações.
http://www.gestaodeprojeto.info/
Site do Fernando Barbi, PMP com conceitos interessantes na Gestão de Projetos e bem didáticos. Contem também dicas e passos para se gerenciar um bom projeto. E na parte técnica também podemos recorrer a documentos importantes para um projeto e áreas de conhecimento. Contem um local com arquivos para download que ajudam na gestão de projetos.
http://www.pmportal.com.br
Possui vários artigos e publicações na área de Gerência de Projetos. Também encontramos cursos, tutoriais e testes para PMP. Na seção de downloads, encontramos softwares e termos (documentos) que auxiliam o Gerente a conduzir seus projetos.
http://www.ibgp.com.br/
Portal do Instituto Brasileiro para Gestão de Projetos. Possui área para cursos on-line para associados. São três assuntos: Curso de Análise de Risco, Curso de Gerência de Projetos de Software e Curso de Monitoração de Projetos.
----------------------------------------------------------------
Softwares para Gerenciamento de Projetos
http://www.msproject.com/
http://www.microsoft.com/project
Portais dedicados ao produto da Microsoft para Gerenciamento de Projetos. Microsoft Project Profissional 2010. É possível baixar uma versão de teste.
http://www.mpug.com
Grupo de usuários do Microsoft Project. Site em inglês.
http://www.primavera.com
Portal dedicado ao produto da Oracle para Gerenciamento de Projetos.
http://www.aisc.com/
Software Artemis Project Management.
http://www.projectbuilder.com.br
No portal tem explicações sobre o software, vídeos mostrando a utilização e a opção de prova de conceito. Versão para teste.
http://www.borland.com/br/solutions/project-and-portfolio-management/index.html
Produto da Borland para Gerenciamento de Projetos e Portfolio de TI.
----------------------------------------------------------------
Empresas que oferecem cursos referentes à Gerência de Projetos.
http://www.clarify.com.br
Site de uma Empresa que treinamento preparatório para certificação em CAPM e PMP com agenda de Cursos e Treinamentos. Também tem treinamento de Gerência de Projetos, MS Project e informações sobre consultoria na área. Em São Paulo.
http://www.pmtech.com.br/
Site de Empresa especializada em capacitação em projetos. Em Porto Alegre. Contêm também artigos e casos sobre Gerência de Projetos.
http://www.projectlab.com.br/
Empresa Global R.E.P do PM. São Paulo, Rio, Belo Horizonte e Salvador. Possui também calendários de eventos .
----------------------------------------------------------------
MBA e Pós-Graduação
http://www.educaedu-brasil.com/gestao-e-gerencia-de-projetos/brasilia--capital-federal
Indica vários locais sobre MBA e especialização em Gerência de Projetos em Brasília.
http://www5.fgv.br/mgmbsb/MGM-BSB/DetCurso.aspx?codCurso=314
MBA da FGV em Gerência de Projetos. Contem toda a programação do curso.
http://www.uniceub.br/curso/Posgraduacaolatosensu/cur030_GerenciaProjetosTI.aspx
Pós-graduação em Gerência de Projetos. Início em Agosto de 2010.
http://www.unieuro.edu.br/posgraduacao_2005/dados_curso.asp?curso=97
MBA Gestão de Projetos de Software. Ensino a distância. Site contem todo o conteúdo programático.
quarta-feira, 25 de agosto de 2010
Estudo de Viabilidade
Alguns projetos não são definidos tão facilmente. Em alguns casos você não tem uma boa idéia em relação aos custos e aos benefícios. E mais, você poderá não saber se o projeto é tecnicamente viável. Nesses casos uma abordagem mais detalhada é necessária - o Estudo de Viabilidade.
Um Estudo de Viabilidade é utilizado para fornecer muito mais diligência e compreensão sobre o projeto, e se o mesmo é praticável e viável. Na verdade, o Estudo de Viabilidade poderá ser considerado um projeto em si. Poderá requerer o documento Termo de Abertura do Projeto, um cronograma e poderá necessitar ser gerenciado como um projeto pequeno. Por outro lado, o Estudo de Viabilidade poderá ser apenas uma análise mais detalhada sobre a viabilidade do projeto e poderá não requerer uma estrutura igual à de um projeto pequeno.
O resultado do Estudo de Viabilidade é um documento que fornece as informações sobre a viabilidade e a praticabilidade de um projeto. Existe um número de áreas da viabilidade que devem ser analisadas:
- Técnico. O projeto é viável em termos técnicos? Se for, indique todos os riscos técnicos associados ao projeto.
- Financeiro. O projeto é viável em termos financeiros? Essa informação é muito importante saber, especialmente se o custo do projeto provocará um impacto grande na empresa. É possível que o projeto tenha um custo tão significativo que ponha a empresa toda em risco. Por exemplo, a empresa poderá ter condições suficientes para incluir o projeto no portfolio, mas poderá ter grandes problemas e impactos caso o projeto exceda significativamente o orçamento. Você deverá incluir uma análise sobre o que acontecerá caso o projeto estoure o orçamento.
- Operacional. A empresa tem condições operacionais para manter o produto do projeto ao longo da vida do mesmo? Certifique-se de que a empresa tem habilidade para manter os produtos que serão criados pelo projeto. É possível que o projeto em si seja viável, mas poderá haver um risco significativo relativo à habilidade de suportar e manter o produto após a conclusão do projeto.
- Geográfico. O projeto é viável baseado no local físico dos membros da equipe do projeto?
- Tempo. O projeto é viável baseado na quantidade de tempo requerido pelas partes interessadas? Esta é uma preocupação maior nos projetos grandes. A empresa poderá ter condições financeiras para executar o projeto, mas poderá não ter todos os membros da equipe livre para executar o projeto.
- Recursos. A empresa tem todos os funcionários, os equipamentos, as fontes e outros recursos necessários para executar o projeto?
- Jurídico. Há algum problema jurídico que faça inviável este projeto?
- Político. Há algum problema político interno (ou externo) que torne inviável este projeto?
- Análise de custo/benefício (em um nível macro). Incluir uma análise de custo/benefício que considere as expectativas de retorno e custos ao longo de um tempo pré-estabelecido. O objetivo de uma análise de custo/benefício é para quantificar cada custo e cada benefício, mesmo aqueles custos e/ou benefícios denominados intangíveis ou ocultos. É importante quantificar o máximo possível cada custo e cada benefício. Normalmente, a análise de custo/benefício representa custos e benefícios incrementais. O resultado financeiro mais útil de uma análise de custo/benefício é a representação de um sumário do fluxo de caixa ao longo do tempo.
As conclusões e as recomendações devem ser documentadas. Uma técnica que poderá ser utilizada é investigar um número de alternativas sobre como o projeto poderá progredir. Para cada alternativa descreva os benefícios, os custos e os riscos. Isso mostrará ao leitor que um nível certo de diligência foi utilizado e que um número de alternativas foi considerado. Os seguintes itens deverão ser considerados nas recomendações:
- Premissas (suposições)
- Riscos
- O modelo financeiro que foi utilizado
- Benefícios estimados
- Custos estimados
- Alinhamento dos objetivos às estratégias da empresa
- Urgência
- Conseqüências se não for executado no período planejado
fonte: TenStep®
Um Estudo de Viabilidade é utilizado para fornecer muito mais diligência e compreensão sobre o projeto, e se o mesmo é praticável e viável. Na verdade, o Estudo de Viabilidade poderá ser considerado um projeto em si. Poderá requerer o documento Termo de Abertura do Projeto, um cronograma e poderá necessitar ser gerenciado como um projeto pequeno. Por outro lado, o Estudo de Viabilidade poderá ser apenas uma análise mais detalhada sobre a viabilidade do projeto e poderá não requerer uma estrutura igual à de um projeto pequeno.
O resultado do Estudo de Viabilidade é um documento que fornece as informações sobre a viabilidade e a praticabilidade de um projeto. Existe um número de áreas da viabilidade que devem ser analisadas:
- Técnico. O projeto é viável em termos técnicos? Se for, indique todos os riscos técnicos associados ao projeto.
- Financeiro. O projeto é viável em termos financeiros? Essa informação é muito importante saber, especialmente se o custo do projeto provocará um impacto grande na empresa. É possível que o projeto tenha um custo tão significativo que ponha a empresa toda em risco. Por exemplo, a empresa poderá ter condições suficientes para incluir o projeto no portfolio, mas poderá ter grandes problemas e impactos caso o projeto exceda significativamente o orçamento. Você deverá incluir uma análise sobre o que acontecerá caso o projeto estoure o orçamento.
- Operacional. A empresa tem condições operacionais para manter o produto do projeto ao longo da vida do mesmo? Certifique-se de que a empresa tem habilidade para manter os produtos que serão criados pelo projeto. É possível que o projeto em si seja viável, mas poderá haver um risco significativo relativo à habilidade de suportar e manter o produto após a conclusão do projeto.
- Geográfico. O projeto é viável baseado no local físico dos membros da equipe do projeto?
- Tempo. O projeto é viável baseado na quantidade de tempo requerido pelas partes interessadas? Esta é uma preocupação maior nos projetos grandes. A empresa poderá ter condições financeiras para executar o projeto, mas poderá não ter todos os membros da equipe livre para executar o projeto.
- Recursos. A empresa tem todos os funcionários, os equipamentos, as fontes e outros recursos necessários para executar o projeto?
- Jurídico. Há algum problema jurídico que faça inviável este projeto?
- Político. Há algum problema político interno (ou externo) que torne inviável este projeto?
- Análise de custo/benefício (em um nível macro). Incluir uma análise de custo/benefício que considere as expectativas de retorno e custos ao longo de um tempo pré-estabelecido. O objetivo de uma análise de custo/benefício é para quantificar cada custo e cada benefício, mesmo aqueles custos e/ou benefícios denominados intangíveis ou ocultos. É importante quantificar o máximo possível cada custo e cada benefício. Normalmente, a análise de custo/benefício representa custos e benefícios incrementais. O resultado financeiro mais útil de uma análise de custo/benefício é a representação de um sumário do fluxo de caixa ao longo do tempo.
As conclusões e as recomendações devem ser documentadas. Uma técnica que poderá ser utilizada é investigar um número de alternativas sobre como o projeto poderá progredir. Para cada alternativa descreva os benefícios, os custos e os riscos. Isso mostrará ao leitor que um nível certo de diligência foi utilizado e que um número de alternativas foi considerado. Os seguintes itens deverão ser considerados nas recomendações:
- Premissas (suposições)
- Riscos
- O modelo financeiro que foi utilizado
- Benefícios estimados
- Custos estimados
- Alinhamento dos objetivos às estratégias da empresa
- Urgência
- Conseqüências se não for executado no período planejado
fonte: TenStep®
domingo, 22 de agosto de 2010
O Gerenciamento de Projetos como Processo
O gerenciamento de projetos é a supervisão de um projeto do início ao fim.
Para que seu projeto seja bem-sucedido, você precisa transformar aquilo que aparece como vago conceito na mente da administração em um programa mensurável e sujeito à prestação de contas, que não apenas aplique uma vasta gama de conhecimentos, habilidades e recursos, mas que também satisfaça as necessidades organizacionais e seja concluído de acordo com o orçamento e o prazo.
O gerenciamento de projetos constitui alocação, utilização e acompanhamento de recursos para satisfazer as necessidades de um projeto específico, em um prazo determinado. Isso requer ter sob absoluto controle questões envolvendo pessoal, qualidade, orçamento e comunicação. O gerenciamento adequado de projetos pode garantir:
Rápido desenvolvimento de fontes de informação;
Uso eficiente e eficaz dos recursos;
Definições e proporções relevantes do sucesso.
Alguns exemplos nos quais o gerenciamento de projetos é usado:
Projeto de um carro;
Desenvolvimento de um novo produto;
Realização de uma campanha política.
O gerenciamento de projetos é o processo por meio do qual a empresa faz com que as coisas aconteçam.
Para que seu projeto seja bem-sucedido, você precisa transformar aquilo que aparece como vago conceito na mente da administração em um programa mensurável e sujeito à prestação de contas, que não apenas aplique uma vasta gama de conhecimentos, habilidades e recursos, mas que também satisfaça as necessidades organizacionais e seja concluído de acordo com o orçamento e o prazo.
O gerenciamento de projetos constitui alocação, utilização e acompanhamento de recursos para satisfazer as necessidades de um projeto específico, em um prazo determinado. Isso requer ter sob absoluto controle questões envolvendo pessoal, qualidade, orçamento e comunicação. O gerenciamento adequado de projetos pode garantir:
Rápido desenvolvimento de fontes de informação;
Uso eficiente e eficaz dos recursos;
Definições e proporções relevantes do sucesso.
Alguns exemplos nos quais o gerenciamento de projetos é usado:
Projeto de um carro;
Desenvolvimento de um novo produto;
Realização de uma campanha política.
O gerenciamento de projetos é o processo por meio do qual a empresa faz com que as coisas aconteçam.
terça-feira, 17 de agosto de 2010
Respostas do Exercício do dia 11/08/2010
1- O que é ciclo de vida?
Ciclo de vida é o conjunto de transformações, etapas e divisões de uma vida ou projeto a fim de assegurar a sua continuidade.
2- Qual a importância da visão de etapas / fases?
O projeto sendo dividido por processos. A visão de etapas ou fases visa facilitar a integração e o gerenciamento do projeto.
3- Em que se aplica o conceito de ciclo de vida? Exemplifique.
Aplica-se para que os trabalhos sejam desenvolvidos de forma contínua do início ou fim. Exemplo: Ciclo de vida de um projeto em construção naval (Desenvolvimento dos requisitos do proprietário, Design preliminar, Design contratual, Contratação da construção, Design de detalhamento e planejamento da construção e construção)
4- No modelo do Pmbok, quais os elementos do ciclo de vida?
Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento.
5- Quais os modelos de gestão de etapas do ciclo de vida?
Modelos de Atividade, Modelos de Atividade de Granularidade Fina, Modelos Papel-Ação, Modelos Entidade-Relação, Atividades do Processo de Engenharia de Requisitos, Levantamento de Requisitos, Análise e Negociação de Requisitos, Documentação de Requisitos, Validação de Requisitos, Modelo em Cascata, Modelo em Espiral, Prototipagem Evolucionária e Codificação e Correção.
6- De acordo com o explicado em aula, qual a importância da fase anterior a formalização do projeto?
Antes da fase de iniciação do projeto o levantamento econômico se faz necessário, verifica os termos de referência, Identificação (Individualização do Problema, Definição de Produto Objetivo), Descrição (Estrutura, Dimensionamento, Localização, Seqüenciação), Inserção (Configuração Sistêmica, Inserção socioeconômica, Inserção Institucional, Organogramação, Revisão e Correções), Aprovisionamento e Controle (Provisão de Recursos Humanos, Suprimento de Recursos Tangíveis e Intangíveis, Nível Tecnológico, Sistemas de Comunicações, Controle de Qualidade e Modelagem Financeira) e por fim a Apresentação (Investimento, Risco e Finalização).
7- O que é modelagem de projeto?
É como o projeto será feito.
Antes de se começar a modelar uma idéia, isto é, de transformá-la em projeto, deve-se considerar se o esforço vale à pena. Por isso, antecede o primeiro passo, na modelagem de projetos, uma visão genérica do que se pretende ver realizado.
Esse momento é extremamente importante, porque a configuração de projetos encerra custos, financeiros e não-financeiros. Às vezes, esses custos são consideráveis. Trata-se, portanto, agora de verificar se o processo de modelagem pode ser iniciado ou não, isto é, trata-se de evitar o risco de investir tempo e recursos em algo que depois se mostrará não factível ou irrelevante.
Além de serem extremamente variadas, as razões e condições para a modelagem de projetos são determinantes da forma e do sentido que lhes serão dados.
As razões para modelar o projeto e as suas características operacionais lhes dão um sentido particular.
A vontade individual ou de um grupo, aliada ao conjunto de pressões conformam a justificativa e o sentido do projeto. Por isso, as razões que levam à construção do projeto devem estar bem claras antes de se dar os primeiros passos efetivos de modelagem.
Conclui-se que, a modelagem é uma atividade recorrente, com idas e vindas e alguma dose de retrabalho. Isto porque, quando se elabora o projeto, é comum notar que alguns dos fatores idealizados são irrealizáveis ou podem se feitos de maneira mais econômica. O mesmo acontece quando se formula o projeto.
8- O conceito de ciclo de vida esta ligada a linha do tempo, por quê?
No início de um ciclo de vida de um projeto é estabelecido um cronograma para a gerência do tempo de projeto. O objetivo maior é descrever os processos requeridos para o fim do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades pré estabelecido.
9- O modelo DMAIC foi preconizado por qual indústria?
Indústria automobilística.
10- Qual o fundamento do DMAIC?
DMAIC é o processo de melhoria contínua usado na metodologia 6 Sigma. Refere-se a uma estratégia de qualidade baseada em dados para melhorar processos. As fases interconectadas do DMAIC são:
Define - Definir
Measure - Medir
Analyse - Analisar
Improve - Melhorar
Control - Controlar
11- Qual o fundamento do PDCA?
PDCA é um ciclo de desenvolvimento com foco na melhoria contínua. É aplicado para atingir resultados dentro de um sistema de gestão e pode ser utilizado em qualquer empresa de forma a garantir o sucesso nos negócios, independentemente da área de atuação da empresa.
O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e ciclicamente, e toma-se uma ação para eliminar ou ao menos diminuir defeitos na execução.
Ciclo de vida é o conjunto de transformações, etapas e divisões de uma vida ou projeto a fim de assegurar a sua continuidade.
2- Qual a importância da visão de etapas / fases?
O projeto sendo dividido por processos. A visão de etapas ou fases visa facilitar a integração e o gerenciamento do projeto.
3- Em que se aplica o conceito de ciclo de vida? Exemplifique.
Aplica-se para que os trabalhos sejam desenvolvidos de forma contínua do início ou fim. Exemplo: Ciclo de vida de um projeto em construção naval (Desenvolvimento dos requisitos do proprietário, Design preliminar, Design contratual, Contratação da construção, Design de detalhamento e planejamento da construção e construção)
4- No modelo do Pmbok, quais os elementos do ciclo de vida?
Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento.
5- Quais os modelos de gestão de etapas do ciclo de vida?
Modelos de Atividade, Modelos de Atividade de Granularidade Fina, Modelos Papel-Ação, Modelos Entidade-Relação, Atividades do Processo de Engenharia de Requisitos, Levantamento de Requisitos, Análise e Negociação de Requisitos, Documentação de Requisitos, Validação de Requisitos, Modelo em Cascata, Modelo em Espiral, Prototipagem Evolucionária e Codificação e Correção.
6- De acordo com o explicado em aula, qual a importância da fase anterior a formalização do projeto?
Antes da fase de iniciação do projeto o levantamento econômico se faz necessário, verifica os termos de referência, Identificação (Individualização do Problema, Definição de Produto Objetivo), Descrição (Estrutura, Dimensionamento, Localização, Seqüenciação), Inserção (Configuração Sistêmica, Inserção socioeconômica, Inserção Institucional, Organogramação, Revisão e Correções), Aprovisionamento e Controle (Provisão de Recursos Humanos, Suprimento de Recursos Tangíveis e Intangíveis, Nível Tecnológico, Sistemas de Comunicações, Controle de Qualidade e Modelagem Financeira) e por fim a Apresentação (Investimento, Risco e Finalização).
7- O que é modelagem de projeto?
É como o projeto será feito.
Antes de se começar a modelar uma idéia, isto é, de transformá-la em projeto, deve-se considerar se o esforço vale à pena. Por isso, antecede o primeiro passo, na modelagem de projetos, uma visão genérica do que se pretende ver realizado.
Esse momento é extremamente importante, porque a configuração de projetos encerra custos, financeiros e não-financeiros. Às vezes, esses custos são consideráveis. Trata-se, portanto, agora de verificar se o processo de modelagem pode ser iniciado ou não, isto é, trata-se de evitar o risco de investir tempo e recursos em algo que depois se mostrará não factível ou irrelevante.
Além de serem extremamente variadas, as razões e condições para a modelagem de projetos são determinantes da forma e do sentido que lhes serão dados.
As razões para modelar o projeto e as suas características operacionais lhes dão um sentido particular.
A vontade individual ou de um grupo, aliada ao conjunto de pressões conformam a justificativa e o sentido do projeto. Por isso, as razões que levam à construção do projeto devem estar bem claras antes de se dar os primeiros passos efetivos de modelagem.
Conclui-se que, a modelagem é uma atividade recorrente, com idas e vindas e alguma dose de retrabalho. Isto porque, quando se elabora o projeto, é comum notar que alguns dos fatores idealizados são irrealizáveis ou podem se feitos de maneira mais econômica. O mesmo acontece quando se formula o projeto.
8- O conceito de ciclo de vida esta ligada a linha do tempo, por quê?
No início de um ciclo de vida de um projeto é estabelecido um cronograma para a gerência do tempo de projeto. O objetivo maior é descrever os processos requeridos para o fim do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades pré estabelecido.
9- O modelo DMAIC foi preconizado por qual indústria?
Indústria automobilística.
10- Qual o fundamento do DMAIC?
DMAIC é o processo de melhoria contínua usado na metodologia 6 Sigma. Refere-se a uma estratégia de qualidade baseada em dados para melhorar processos. As fases interconectadas do DMAIC são:
Define - Definir
Measure - Medir
Analyse - Analisar
Improve - Melhorar
Control - Controlar
11- Qual o fundamento do PDCA?
PDCA é um ciclo de desenvolvimento com foco na melhoria contínua. É aplicado para atingir resultados dentro de um sistema de gestão e pode ser utilizado em qualquer empresa de forma a garantir o sucesso nos negócios, independentemente da área de atuação da empresa.
O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e ciclicamente, e toma-se uma ação para eliminar ou ao menos diminuir defeitos na execução.
sábado, 14 de agosto de 2010
Porque os Projetos falham?
Quando um projeto é encerrado prematuramente, é cancelado ou termina sem que seus objetivos tenham sido atingidos, considera-se que ele fracassou. O Gestor do Projeto (GP) tem que se prevenir, o que não é muito difícil já que as causas são quase sempre as mesmas. O texto abaixo lista algumas das possíveis causas que os projetos possam falhar.
Expectativas irrealistas.
Se for verdade que o segredo da felicidade é a administração das expectativas, se você não administrar as suas (e as do patrocinador), você pode acabar se decepcionando com resultados que, sob uma outra ótica, seriam considerados bons. Seja por uma falha de compreensão do escopo ou por um cronograma muito apertado, o projeto que não têm bases realistas e sólidas tendem a falhar mais do que os projetos que levam em conta a cultura da empresa e as restrições impostas naquele momento. Mas como saber se as minhas expectativas são realistas? Pense em discuti-las com profissionais mais experientes que conhecem os problemas que você terá de resolver e que conhecem a organização. Às vezes o procedimento mais simples fica travado pela burocracia e quem já passaram por isso pode ajudá-lo contornar os obstáculos.
Planejamento deficiente.
Depois de estudar muita estatística cheguei a uma conclusão: planejamento é muito mais arte do que ciência. Você pode aprender os mais sofisticados métodos de previsão, saber calcular o desvio-padrão de uma estimativa e usar as ferramentas mais sofisticadas e mesmo assim errar. Porquê? Em geral por que partiu de premissas erradas. Você espera que determinado fornecedor entregue uma tarefa com uma eficiência de 95% e ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e você deve acomodar os 25% (30%-5%) que aconteceram de forma imprevisível. Vivemos num mundo complexo em que os eventos podem ser influenciados por acontecimentos de uma forma numa vez, mas por outra bem diferente na próxima ocorrência. Quando aproximamos um processo tendemos a buscar uma função com forma linear, algo como y=Ax+B. Neste modelo, a variável x que se observa explica a variável y segundo os parâmetros A e B. Mas se houver outro fator, digamos z, que afeta y e não colocamos na equação (porque quando medimos x e y, z era desprezível), podemos incorrer em grandes erros nos casos em que esta variável omitida, z, assuma valores significativos. Nos processos de Gestão de Riscos, deve-se identificar os fatores relevantes (no nosso caso, x e z) e procurar medir, ou estimar, qual o possível impacto no resultado final (no nosso caso, y).
Falha no controle de desempenho.
Não há nenhuma desculpa aceitável para se perder o controle sobre o desempenho da equipe de projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs preferem relatórios, outros vão para o contato cara-a-cara. Não importa como, mas é vital que este processo de acompanhamento seja permanente e regular. Se a tarefa parece cansativa, automatize-a, mas faça. As pessoas respondem de forma diferente quando são monitoradas, como nos ensina o “efeito Hawthorne”. Neste experimento, o mero fato de estarem sendo acompanhados por pesquisadores fazia com que os trabalhadores de uma fábrica produzissem mais. Tentaram variar a luminosidade do ambiente de trabalho e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas. Ficou claro que não era a luz que influía nos resultados, mas o ato de estar sendo monitorado é que fazia o pessoal dar duro. Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se muito como métrica a quantidade de linhas de código escritas. Mas um programador pode entregar mais código e ao mesmo tempo cometer mais erros do que os outros. Um bom indicador deve ser simples, mas não tão simples que esconda o que se deseja realmente medir, que é a quantidade de código de boa qualidade. Lembre-se da velha fórmula: "tudo o que se deseja obter deve ser medido".
Falta de liderança efetiva.
Eu encontrei vários GPs que vinham de organizações matriciais fortes e acredito que foram muitos influenciados por elas. Parece que nestas organizações, as pessoas demoram mais a responder por receio de entrar numa área alheia. No limite, a guerra entre os "feudos" impede que boas iniciativas interdepartamentais decolem. As pessoas estão reprimidas e, se o GP é "cria da casa", ele pode apresentar hesitações "inexplicáveis". Estas pessoas usualmente apostam que muitos ruídos se dissipam "sozinhos", o que obviamente não acontece. O ruído, isto é, um pequeno problema dentro da equipe, pode ser mais do que isso. Pode ser que não seja tão pequeno, mas que assim pareça por uma falha de percepção do GP. Quanto maior o projeto, maior a inércia (leia-se, resistência a mudanças) e maiores as chances de ruídos. Quanto mais rápido o problema for endereçado pelo GP, melhor para todos. Além disso, a verdadeira liderança é inspiradora e viral: um bom líder acaba criando um ambiente propício ao surgimento de novos líderes a sua volta. Uma dica: se você topar com uma equipe cheia de pessoas motivadas e que apresentam um claro interesse em liderar, você tem uma boa pista de que o GP é um bom líder.
Falta de skills (habilidades) dos membros do time de projeto.
Quando contratou um profissional, o GP pode ter sido enganado pensando que o candidato sabia fazer uma coisa que na verdade não sabe, mas isso é difícil de ocorrer se você tomar as devidas precauções como estabelecer uma descrição funcional ("job description") bem detalhada e que especifique uma série de habilidades que possam ser verificadas. Mas mesmo que você tenha feito tudo certo, começou o projeto, definiu e plataforma de desenvolvimento (digamos, por exemplo Windows), contratou experts e depois, por uma daquelas voltas da vida, descobre que o produto deveria ser desenvolvido em outra plataforma (por exemplo, Unix) que sua equipe não conhece. O que fazer? Trocar ou retreinar? Depende dos recursos de tempo e verba disponíveis, mas via de regra prepare-se para mudar boa parte da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria especificar o pagamento de um bônus de desligamento antes de contratar o profissional. Quanto antes fica claro as regras do jogo, melhor para todos. No final, a opção é simples: agir quando ainda há tempo ou ver o barco afundar.
Falta de motivação do time e dos interessados.
O moral da equipe sofre muito quando a gestão é fraca. Imagine se o João, que é um gerente júnior importante para o projeto acabou de casar e está sendo pressionado pela esposa a procurar outro emprego que pague mais. O GP, temendo perdê-lo, lhe promete um bônus, mas não pede autorização da direção nem com do pessoal de RH. Ele pensa que não é necessário já que o projeto tem orçamento para isso. João dá duro, se esforça e o projeto é um sucesso. Na hora “H”, o bônus não vem como prometido e João recebe um tapinha nas costas. As explicações são as mais diversas: não temos orçamento para isso, é política de empresa não fazer estas coisas, você não seguiu os procedimentos da empresa, etc... Isso pouco importa para quem não recebeu a devida recompensa. O que acontecerá com o desempenho de João depois disso? Isso para não mencionar a perda de credibilidade. Tenho uma regra: quando um bom profissional está entregando abaixo do seu potencial o GP tem "culpa no cartório": ele deveria ter se informado sobre o que está acontecendo. No caso do João, ele agora está saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP deveria ter tomado as devidas medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal. Moral de história: se você não puder oferecer um bônus, não o faça. Se fizer, tem de cumprir.
Falta de apoio dentro da organização.
Apoio aqui é a força política que um diretor, sócio ou presidente pode dar ao projeto. A figura mais importante para o projeto é a do patrocinador que deve comunicar aos demais membros da organização a importância da iniciativa para a empresa, cobrando deles a atenção necessária para que as tarefas sejam concluídas. Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com um grande número de pedidos processados manualmente todos os dias. Haverá uma sobrecarga do pessoal do departamento pelo tempo necessário ao teste e implantação do projeto. Esse tempo extra, pode exigir a contratação de pessoal temporário para fazer as tarefas do dia-a-dia enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de alguém com poder de decisão pode ser difícil contratar esta equipe para ajudar na transição ou para fazer o pessoal do departamento financeiro separar duas horas do seu dia para testar e aprender a usar a nova ferramenta.
Falta de recursos.
Apesar de algumas pessoas não tomarem o cancelamento de um projeto por falta de fundos como um fracasso. Entendo que de alguma forma o GP poderia ter se antecipado ao problema. Qualquer companhia pode enfrentar momentos difíceis, que exijam a redução rápida de custos. No entanto, isso dificilmente acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001). Em geral os sinais estão por toda parte e cabe ao GP estar ligado neles. Por exemplo, se parte dos recursos para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa Selic) sobem, é provável que surjam dificuldades para realizar esta captação. E como tratar o problema com a equipe? É melhor abordar o tema claramente numa reunião do que deixar os rumores de demissões tomarem conta das mentes de pessoas que deveriam estar concentradas em obter resultados. Se haverá um corte de orçamento, o GP deve se antecipar e planejar como se poderia reduzir custos e seguir com o projeto. No limite, ele deveria pensar em encerrar o projeto deixando resultados palpáveis, mesmo que não os originalmente esperados. A partir de algo concreto é mais provável que se possa retomar o projeto quando o ambiente econômico melhorar. Mas se os recursos faltarem porque a empresa está vendo outros projetos como prioritários, o GP deve lutar por seu projeto e mostrar o que já se ganhou com ele e quanto ainda deve ganhar se completá-lo. Se o patrocinador receber um plano para seguir com o projeto com custos reduzidos, isso pode evitar a suspensão/cancelamento do projeto.
Conclusão.
Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre se faça uma reunião de encerramento para se discutir “o que se pode aprender com essa experiência”. Quando há confiança e respeito mútuo a equipe enfrenta as conseqüências do fracasso de forma unida. Cabe ao GP informar aos demais os propósitos da reunião, senão corre-se o risco dos mais exaltados buscarem culpados, o que cria um clima desagradável que impede o diálogo. Sugiro que cada um faça o seu mea culpa, levantando apenas os pontos em que deveria ter agido de outra forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo que o grupo fez tudo o que podia ser feito para evitar o fracasso, o GP deve tirar as lições devidas e resumi-las para todos. Assim aumentam-se as chances de sucesso no próximo projeto. De toda forma, planejamento e comunicação são as duas atribuições críticas que o GP não deve delegar.
Texto extraído do site de Fernando C Barbi, PMP.
Expectativas irrealistas.
Se for verdade que o segredo da felicidade é a administração das expectativas, se você não administrar as suas (e as do patrocinador), você pode acabar se decepcionando com resultados que, sob uma outra ótica, seriam considerados bons. Seja por uma falha de compreensão do escopo ou por um cronograma muito apertado, o projeto que não têm bases realistas e sólidas tendem a falhar mais do que os projetos que levam em conta a cultura da empresa e as restrições impostas naquele momento. Mas como saber se as minhas expectativas são realistas? Pense em discuti-las com profissionais mais experientes que conhecem os problemas que você terá de resolver e que conhecem a organização. Às vezes o procedimento mais simples fica travado pela burocracia e quem já passaram por isso pode ajudá-lo contornar os obstáculos.
Planejamento deficiente.
Depois de estudar muita estatística cheguei a uma conclusão: planejamento é muito mais arte do que ciência. Você pode aprender os mais sofisticados métodos de previsão, saber calcular o desvio-padrão de uma estimativa e usar as ferramentas mais sofisticadas e mesmo assim errar. Porquê? Em geral por que partiu de premissas erradas. Você espera que determinado fornecedor entregue uma tarefa com uma eficiência de 95% e ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e você deve acomodar os 25% (30%-5%) que aconteceram de forma imprevisível. Vivemos num mundo complexo em que os eventos podem ser influenciados por acontecimentos de uma forma numa vez, mas por outra bem diferente na próxima ocorrência. Quando aproximamos um processo tendemos a buscar uma função com forma linear, algo como y=Ax+B. Neste modelo, a variável x que se observa explica a variável y segundo os parâmetros A e B. Mas se houver outro fator, digamos z, que afeta y e não colocamos na equação (porque quando medimos x e y, z era desprezível), podemos incorrer em grandes erros nos casos em que esta variável omitida, z, assuma valores significativos. Nos processos de Gestão de Riscos, deve-se identificar os fatores relevantes (no nosso caso, x e z) e procurar medir, ou estimar, qual o possível impacto no resultado final (no nosso caso, y).
Falha no controle de desempenho.
Não há nenhuma desculpa aceitável para se perder o controle sobre o desempenho da equipe de projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs preferem relatórios, outros vão para o contato cara-a-cara. Não importa como, mas é vital que este processo de acompanhamento seja permanente e regular. Se a tarefa parece cansativa, automatize-a, mas faça. As pessoas respondem de forma diferente quando são monitoradas, como nos ensina o “efeito Hawthorne”. Neste experimento, o mero fato de estarem sendo acompanhados por pesquisadores fazia com que os trabalhadores de uma fábrica produzissem mais. Tentaram variar a luminosidade do ambiente de trabalho e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas. Ficou claro que não era a luz que influía nos resultados, mas o ato de estar sendo monitorado é que fazia o pessoal dar duro. Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se muito como métrica a quantidade de linhas de código escritas. Mas um programador pode entregar mais código e ao mesmo tempo cometer mais erros do que os outros. Um bom indicador deve ser simples, mas não tão simples que esconda o que se deseja realmente medir, que é a quantidade de código de boa qualidade. Lembre-se da velha fórmula: "tudo o que se deseja obter deve ser medido".
Falta de liderança efetiva.
Eu encontrei vários GPs que vinham de organizações matriciais fortes e acredito que foram muitos influenciados por elas. Parece que nestas organizações, as pessoas demoram mais a responder por receio de entrar numa área alheia. No limite, a guerra entre os "feudos" impede que boas iniciativas interdepartamentais decolem. As pessoas estão reprimidas e, se o GP é "cria da casa", ele pode apresentar hesitações "inexplicáveis". Estas pessoas usualmente apostam que muitos ruídos se dissipam "sozinhos", o que obviamente não acontece. O ruído, isto é, um pequeno problema dentro da equipe, pode ser mais do que isso. Pode ser que não seja tão pequeno, mas que assim pareça por uma falha de percepção do GP. Quanto maior o projeto, maior a inércia (leia-se, resistência a mudanças) e maiores as chances de ruídos. Quanto mais rápido o problema for endereçado pelo GP, melhor para todos. Além disso, a verdadeira liderança é inspiradora e viral: um bom líder acaba criando um ambiente propício ao surgimento de novos líderes a sua volta. Uma dica: se você topar com uma equipe cheia de pessoas motivadas e que apresentam um claro interesse em liderar, você tem uma boa pista de que o GP é um bom líder.
Falta de skills (habilidades) dos membros do time de projeto.
Quando contratou um profissional, o GP pode ter sido enganado pensando que o candidato sabia fazer uma coisa que na verdade não sabe, mas isso é difícil de ocorrer se você tomar as devidas precauções como estabelecer uma descrição funcional ("job description") bem detalhada e que especifique uma série de habilidades que possam ser verificadas. Mas mesmo que você tenha feito tudo certo, começou o projeto, definiu e plataforma de desenvolvimento (digamos, por exemplo Windows), contratou experts e depois, por uma daquelas voltas da vida, descobre que o produto deveria ser desenvolvido em outra plataforma (por exemplo, Unix) que sua equipe não conhece. O que fazer? Trocar ou retreinar? Depende dos recursos de tempo e verba disponíveis, mas via de regra prepare-se para mudar boa parte da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria especificar o pagamento de um bônus de desligamento antes de contratar o profissional. Quanto antes fica claro as regras do jogo, melhor para todos. No final, a opção é simples: agir quando ainda há tempo ou ver o barco afundar.
Falta de motivação do time e dos interessados.
O moral da equipe sofre muito quando a gestão é fraca. Imagine se o João, que é um gerente júnior importante para o projeto acabou de casar e está sendo pressionado pela esposa a procurar outro emprego que pague mais. O GP, temendo perdê-lo, lhe promete um bônus, mas não pede autorização da direção nem com do pessoal de RH. Ele pensa que não é necessário já que o projeto tem orçamento para isso. João dá duro, se esforça e o projeto é um sucesso. Na hora “H”, o bônus não vem como prometido e João recebe um tapinha nas costas. As explicações são as mais diversas: não temos orçamento para isso, é política de empresa não fazer estas coisas, você não seguiu os procedimentos da empresa, etc... Isso pouco importa para quem não recebeu a devida recompensa. O que acontecerá com o desempenho de João depois disso? Isso para não mencionar a perda de credibilidade. Tenho uma regra: quando um bom profissional está entregando abaixo do seu potencial o GP tem "culpa no cartório": ele deveria ter se informado sobre o que está acontecendo. No caso do João, ele agora está saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP deveria ter tomado as devidas medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal. Moral de história: se você não puder oferecer um bônus, não o faça. Se fizer, tem de cumprir.
Falta de apoio dentro da organização.
Apoio aqui é a força política que um diretor, sócio ou presidente pode dar ao projeto. A figura mais importante para o projeto é a do patrocinador que deve comunicar aos demais membros da organização a importância da iniciativa para a empresa, cobrando deles a atenção necessária para que as tarefas sejam concluídas. Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com um grande número de pedidos processados manualmente todos os dias. Haverá uma sobrecarga do pessoal do departamento pelo tempo necessário ao teste e implantação do projeto. Esse tempo extra, pode exigir a contratação de pessoal temporário para fazer as tarefas do dia-a-dia enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de alguém com poder de decisão pode ser difícil contratar esta equipe para ajudar na transição ou para fazer o pessoal do departamento financeiro separar duas horas do seu dia para testar e aprender a usar a nova ferramenta.
Falta de recursos.
Apesar de algumas pessoas não tomarem o cancelamento de um projeto por falta de fundos como um fracasso. Entendo que de alguma forma o GP poderia ter se antecipado ao problema. Qualquer companhia pode enfrentar momentos difíceis, que exijam a redução rápida de custos. No entanto, isso dificilmente acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001). Em geral os sinais estão por toda parte e cabe ao GP estar ligado neles. Por exemplo, se parte dos recursos para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa Selic) sobem, é provável que surjam dificuldades para realizar esta captação. E como tratar o problema com a equipe? É melhor abordar o tema claramente numa reunião do que deixar os rumores de demissões tomarem conta das mentes de pessoas que deveriam estar concentradas em obter resultados. Se haverá um corte de orçamento, o GP deve se antecipar e planejar como se poderia reduzir custos e seguir com o projeto. No limite, ele deveria pensar em encerrar o projeto deixando resultados palpáveis, mesmo que não os originalmente esperados. A partir de algo concreto é mais provável que se possa retomar o projeto quando o ambiente econômico melhorar. Mas se os recursos faltarem porque a empresa está vendo outros projetos como prioritários, o GP deve lutar por seu projeto e mostrar o que já se ganhou com ele e quanto ainda deve ganhar se completá-lo. Se o patrocinador receber um plano para seguir com o projeto com custos reduzidos, isso pode evitar a suspensão/cancelamento do projeto.
Conclusão.
Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre se faça uma reunião de encerramento para se discutir “o que se pode aprender com essa experiência”. Quando há confiança e respeito mútuo a equipe enfrenta as conseqüências do fracasso de forma unida. Cabe ao GP informar aos demais os propósitos da reunião, senão corre-se o risco dos mais exaltados buscarem culpados, o que cria um clima desagradável que impede o diálogo. Sugiro que cada um faça o seu mea culpa, levantando apenas os pontos em que deveria ter agido de outra forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo que o grupo fez tudo o que podia ser feito para evitar o fracasso, o GP deve tirar as lições devidas e resumi-las para todos. Assim aumentam-se as chances de sucesso no próximo projeto. De toda forma, planejamento e comunicação são as duas atribuições críticas que o GP não deve delegar.
Texto extraído do site de Fernando C Barbi, PMP.
sábado, 7 de agosto de 2010
O Gerente de Projetos
O trabalho do gerente de um projeto pode ser sintetizado em dois grandes elementos:
• Planejar (antes) e Controlar (durante) as atividades do projeto e seu gerenciamento, conforme se pode constatar pela concentração de processos de gerenciamento de um projeto abrangendo todas os aspectos envolvidos.
• Comunicar: os gerentes de projetos passam a maior parte do seu tempo se comunicando com os membros da equipe e outras partes interessadas do projeto.
Além disso, os gerentes de projetos usam diversas habilidades interpessoais com frequência, dentre as quais pode-se destacar:
• Liderança
• Solução de conflitos e problemas
• Negociação, influência e persuasão
• Organização e disciplina
• Decisão, iniciativa e proatividade
• Empreendedorismo
• Transparência, clareza e objetividade
• Eficácia
Mais que ser um facilitador, o gerente de projetos deve fazer a diferença no andamento e no sucesso dos projetos.
Texto extraído do espaço de Márcio d'Avila (www.mhavila.com.br/pessoal)
• Planejar (antes) e Controlar (durante) as atividades do projeto e seu gerenciamento, conforme se pode constatar pela concentração de processos de gerenciamento de um projeto abrangendo todas os aspectos envolvidos.
• Comunicar: os gerentes de projetos passam a maior parte do seu tempo se comunicando com os membros da equipe e outras partes interessadas do projeto.
Além disso, os gerentes de projetos usam diversas habilidades interpessoais com frequência, dentre as quais pode-se destacar:
• Liderança
• Solução de conflitos e problemas
• Negociação, influência e persuasão
• Organização e disciplina
• Decisão, iniciativa e proatividade
• Empreendedorismo
• Transparência, clareza e objetividade
• Eficácia
Mais que ser um facilitador, o gerente de projetos deve fazer a diferença no andamento e no sucesso dos projetos.
Texto extraído do espaço de Márcio d'Avila (www.mhavila.com.br/pessoal)
Assinar:
Postagens (Atom)