Entre os indicadores mais utilizados para o controle de um projeto está a EVA (Earned Value Analysis)
Após a conclusão do cronograma, com as respectivas alocações de recursos e conhecendo-se o valor/hora de cada recurso, já é possível conhecer o "custo planejado" de cada tarefa do projeto. É ainda possível saber as datas de início e fim (planejadas) para cada tarefa do projeto.
À medida que o tempo passa, é importante verificar se as tarefas estão sendo executadas de acordo com o planejado (tanto do ponto de vista de prazo quanto de custo).
A análise do Valor Agregagdo no permite comparar estes três pontos fundamentais do projeto em uma determinada data:
Basicamente, responde-se às seguintes perguntas:
- Quais tarefas eu deveria ter cumprido até esta data?
- Quais tarefas eu realmente cumpri?
- Qual o custo das tarefas realizadas?
Para uma análise mais efetiva, utilizando-se índices (KPI), compara-se "O custo das tarefas que eu deveria ter cumprido" com "o custo das tarefas que eu realmente cumpri".
Uma explicação preliminar em português pode ser encontrada aqui.
Uma boa explicação do método em inglês pode ser encontrada clicando-se aqui.
Uma explicação de como usar o método no MS-Project pode ser encontrada aqui.
Para um estudo mais aprofundado, com exemplos, consulte o:
Tutorial on Earned Value Management Systems - Dennis J. Frailey
Tuesday, November 18, 2008
Monday, November 10, 2008
Recursos Humanos no Projeto
Papeis e responsabilidades:
A definição de papeis e responsabilidades tem , além de outras vantagens, o fato de atenuar conflitos de interesses e promover a integração e a comunicação.
Papéis típicos num projeto:
- Comitê executivo
- Gerente de projeto
- Representante do Escritório de Projetos (PMO)
- Membro da equipe.
Responsabilidades do Gerente de Projetos
Em se tratanto de Recursos Humanos, as responsabilidades do GP são:
- Negociar os melhores recursos com os chefes dos recursos ( gerentes funcionais).
- Definir os papeis e as responsabilidades dos membros da equipe.
- Reconhecer e suprir as necessidades de treinamento dos membros da equipe.
- Criar um Plano de Desenvolvimento da Equipe (alinhado ao cronograma do projeto).
- Promover o desenvolvimento contínuo da equipe.
Evolução da equipe (estágios)
- Forming (formação da equipe)
- Storming (conflitos)
- Norming (organizando)
- Performing (desempenhando)
- Adjourning (desmembrando)
Habilidades Gerenciais relevantes em cada estágio
- Na formação da equipe
* Definição de responsabilidades
* Networking
- Nos conflitos
* Escuta ativa
* Gestão de conflitos
* Assertividade
* Avaliação de desempenho
- Na fase de organização
* Comunicação
* Retorno (feedback) positivo
- Na fase de desempenho
* Construção de consenso
* Premiação
* Tomada de decisão
* Capacidade de tracking
* Delegação
- No desmembramento:
* Capacidade de avaliação
* Capacidade de celebração
* Capacidade de propor melhorias
A definição de papeis e responsabilidades tem , além de outras vantagens, o fato de atenuar conflitos de interesses e promover a integração e a comunicação.
Papéis típicos num projeto:
- Comitê executivo
- Gerente de projeto
- Representante do Escritório de Projetos (PMO)
- Membro da equipe.
Responsabilidades do Gerente de Projetos
Em se tratanto de Recursos Humanos, as responsabilidades do GP são:
- Negociar os melhores recursos com os chefes dos recursos ( gerentes funcionais).
- Definir os papeis e as responsabilidades dos membros da equipe.
- Reconhecer e suprir as necessidades de treinamento dos membros da equipe.
- Criar um Plano de Desenvolvimento da Equipe (alinhado ao cronograma do projeto).
- Promover o desenvolvimento contínuo da equipe.
Evolução da equipe (estágios)
- Forming (formação da equipe)
- Storming (conflitos)
- Norming (organizando)
- Performing (desempenhando)
- Adjourning (desmembrando)
Habilidades Gerenciais relevantes em cada estágio
- Na formação da equipe
* Definição de responsabilidades
* Networking
- Nos conflitos
* Escuta ativa
* Gestão de conflitos
* Assertividade
* Avaliação de desempenho
- Na fase de organização
* Comunicação
* Retorno (feedback) positivo
- Na fase de desempenho
* Construção de consenso
* Premiação
* Tomada de decisão
* Capacidade de tracking
* Delegação
- No desmembramento:
* Capacidade de avaliação
* Capacidade de celebração
* Capacidade de propor melhorias
Tuesday, November 4, 2008
Custos do projeto
Entre os principais custos de um projeto está o custo de mão-de-obra. Em especial porque, na maioria dos projetos, essa mão-de-obra tende a ser especializada.
Uma vez mais a WBS é conveniente. Quebrando as tarefas do projeto até o nível apropriado, torna-se possível determinar as competências necessárias para cada tarefa.
Há uma relação bem forte entre a competência necessária e o custo médio de um profissional. Com essas informações e a duração de cada tarefa, é possível saber quanto tempo cada profissional será necessário possibilitando uma estimativa de custo de mão-de-obra.
Conhecendo-se ainda o início de cada tarefa e o material (ou equipamento) necessário para cada uma delas, é possível determinar o custo de material e equipamento e desenvolver um plano de compras para o projeto.
Em projetos de duração mais longa, é importante considerar os custos levando em consideração o tempo. Para tanto, é comum usar-se análises tais como Análise do Valor Presente (NPV) ou a Análise da Taxa de Interna de Retorno (IRR).
Uma vez mais a WBS é conveniente. Quebrando as tarefas do projeto até o nível apropriado, torna-se possível determinar as competências necessárias para cada tarefa.
Há uma relação bem forte entre a competência necessária e o custo médio de um profissional. Com essas informações e a duração de cada tarefa, é possível saber quanto tempo cada profissional será necessário possibilitando uma estimativa de custo de mão-de-obra.
Conhecendo-se ainda o início de cada tarefa e o material (ou equipamento) necessário para cada uma delas, é possível determinar o custo de material e equipamento e desenvolver um plano de compras para o projeto.
Em projetos de duração mais longa, é importante considerar os custos levando em consideração o tempo. Para tanto, é comum usar-se análises tais como Análise do Valor Presente (NPV) ou a Análise da Taxa de Interna de Retorno (IRR).
Planejamento do tempo
Uma vez criada a WBS, você já tem uma lista de todas as tarefas necessárias para que o escopo seja atendido.
O passo seguinte é estimar a duração de cada tarefa. A experiência ajuda bastante nessa estimativa; entretanto, ainda que você não tenha experiência alguma e não tenha ninguém pra ajudar, vale a pena fazer uma estimativa. Ainda que você esteja redondamente enganado, aprenderá no processo e estará mais preparado para a próxima vez.
Muito importante, porém, é separar as etapas da elaboração do cronograma. Enquanto você estiver construindo a WBS (lista de tarefas a serem executadas) não se preocupe muito com a duração das tarefas (em especial se você não souber). Quando você já tiver a WBS, mantenha o foco em estimar a duração de uma tarefa de cada vez.
O passo seguinte é estimar a duração de cada tarefa. A experiência ajuda bastante nessa estimativa; entretanto, ainda que você não tenha experiência alguma e não tenha ninguém pra ajudar, vale a pena fazer uma estimativa. Ainda que você esteja redondamente enganado, aprenderá no processo e estará mais preparado para a próxima vez.
Muito importante, porém, é separar as etapas da elaboração do cronograma. Enquanto você estiver construindo a WBS (lista de tarefas a serem executadas) não se preocupe muito com a duração das tarefas (em especial se você não souber). Quando você já tiver a WBS, mantenha o foco em estimar a duração de uma tarefa de cada vez.
Estrutura Analítica do Projeto
A estrutura analítica do projeto, também conhecida como WBS (do inglês Work Breakdown Structure)
Veja um exemplo de como construir sua WBS no link abaixo:
http://www.netmba.com/operations/project/wbs/
Veja um exemplo de como construir sua WBS no link abaixo:
http://www.netmba.com/operations/project/wbs/
Definindo o Escopo
Antes de tudo é preciso definir escopo...
Escopo é uma representação tecnicamente viável das necessidades do cliente.
Lembre-se de que nem todo cliente tem muito claro suas necessidades. E, dentre os que têm, nem todos estão aptos a expressá-las em algum tipo de linguagem.
Por conta disso, antes de determinar o escopo, é fundamental "ouvir de forma ativa" as necessidades do cliente.
Ouvir é fundamental mas não basta!! É preciso construir cenários considerando as necessidades do cliente e submeter estes cenários a diferentes situações. Esse exercício conduz o cliente a uma percepção mais ampla de suas necessidades além de reconhecer eventuais contradições e a descobrir novas possibilidades (desejos) antes que sejam gastos recursos e tempo de desenvolvimento.
1) Levantamento de necessidades
O primeiro passo no levantamento de necessidades é descobrir as funcionalidades e características.
Essa é uma boa oportunidade para deixar o cliente "viajar na maionese". Não é o melhor momento pra fazer análise de viabilidade. Quanto mais o cliente falar nesse momento, maiores são as chances de se capturar os desejos mais profundos dele e maiores são as chances de se encantar o cliente com o produto final.
Perguntas que podem ajudar:
- Como você imagina o produto ou serviço (características)?
- O quê você espera que o produto faça (funcionalidades)?
- Como você se imagina usando o produto?
- Quem você espera que use o produto?
2) Classificação das necessidades
Após levantar as características e funcionalidades, é fundamental classificá-las por nível de importância. Possíveis níveis de importância são: crítico, importante, interessante, irrelevante. Não tente classificar sem o consentimento do cliente mas é importante que essa classificação tenha uma data de conclusão.
3) Cenários
Crie cenários com as necessidades do cliente. O exercício do cenário ajuda capturar funcionalidades e características assumidas como sendo óbvias ou que o clinte não consegue imaginar.
Ex.: performance, disponibilidade, necessidade de redundância, segurança entre outros...
O exercício do cenário é ainda uma excelente forma de testar o quanto você entendeu de tudo o que o cliente falou. Se você entendeu tudo errado, ficará muito claro no cenário construído.
O mesmo exercício ajuda ainda a revelar características ou funcionalidades conflitantes. Ex.: Um carro capaz de:
- Levar 10 pessoas mais bagagem
- Viajar a 300 km/h
- Fazer 50 km/l
etc...
Determinação do escopo
Até aqui, cuidou-se do levantamento de necessidades. Uma vez conhecidas, classificadas e testadas as necessidades, é possível falar-se em termos de tarefas necessárias para que as funcionalidades sejam entregues.
Como exemplo, digamos que, após intensas negociações, o cliente aceitou abrir mão das duas últimas funcionalidades do carro (exemplo anterior). Assim, as necessidades do clientes resumem-se a: "Um carro capaz de levar 10 pessoas mais bagagem".
Um escopo razoável para esse projeto não é o carro e sim a seguinte lista de tarefas:
- Desenvolver um carro (capaz de levar 10 pessoas mais bagagem)
- Construir protótipo
- Testar o carro (com 10 pessoas mais bagagem dentro)
- Iniciar produção
- Lançar o carro.
Converter as necessidades em tarefas é um exercíco que ajuda bastante à comprensão do que precisa ser feito.
É fundamental que o cliente concorde que os seus requisitos serão atendidos através da execução das tarefas no escopo.
Escopo é uma representação tecnicamente viável das necessidades do cliente.
Lembre-se de que nem todo cliente tem muito claro suas necessidades. E, dentre os que têm, nem todos estão aptos a expressá-las em algum tipo de linguagem.
Por conta disso, antes de determinar o escopo, é fundamental "ouvir de forma ativa" as necessidades do cliente.
Ouvir é fundamental mas não basta!! É preciso construir cenários considerando as necessidades do cliente e submeter estes cenários a diferentes situações. Esse exercício conduz o cliente a uma percepção mais ampla de suas necessidades além de reconhecer eventuais contradições e a descobrir novas possibilidades (desejos) antes que sejam gastos recursos e tempo de desenvolvimento.
1) Levantamento de necessidades
O primeiro passo no levantamento de necessidades é descobrir as funcionalidades e características.
Essa é uma boa oportunidade para deixar o cliente "viajar na maionese". Não é o melhor momento pra fazer análise de viabilidade. Quanto mais o cliente falar nesse momento, maiores são as chances de se capturar os desejos mais profundos dele e maiores são as chances de se encantar o cliente com o produto final.
Perguntas que podem ajudar:
- Como você imagina o produto ou serviço (características)?
- O quê você espera que o produto faça (funcionalidades)?
- Como você se imagina usando o produto?
- Quem você espera que use o produto?
2) Classificação das necessidades
Após levantar as características e funcionalidades, é fundamental classificá-las por nível de importância. Possíveis níveis de importância são: crítico, importante, interessante, irrelevante. Não tente classificar sem o consentimento do cliente mas é importante que essa classificação tenha uma data de conclusão.
3) Cenários
Crie cenários com as necessidades do cliente. O exercício do cenário ajuda capturar funcionalidades e características assumidas como sendo óbvias ou que o clinte não consegue imaginar.
Ex.: performance, disponibilidade, necessidade de redundância, segurança entre outros...
O exercício do cenário é ainda uma excelente forma de testar o quanto você entendeu de tudo o que o cliente falou. Se você entendeu tudo errado, ficará muito claro no cenário construído.
O mesmo exercício ajuda ainda a revelar características ou funcionalidades conflitantes. Ex.: Um carro capaz de:
- Levar 10 pessoas mais bagagem
- Viajar a 300 km/h
- Fazer 50 km/l
etc...
Determinação do escopo
Até aqui, cuidou-se do levantamento de necessidades. Uma vez conhecidas, classificadas e testadas as necessidades, é possível falar-se em termos de tarefas necessárias para que as funcionalidades sejam entregues.
Como exemplo, digamos que, após intensas negociações, o cliente aceitou abrir mão das duas últimas funcionalidades do carro (exemplo anterior). Assim, as necessidades do clientes resumem-se a: "Um carro capaz de levar 10 pessoas mais bagagem".
Um escopo razoável para esse projeto não é o carro e sim a seguinte lista de tarefas:
- Desenvolver um carro (capaz de levar 10 pessoas mais bagagem)
- Construir protótipo
- Testar o carro (com 10 pessoas mais bagagem dentro)
- Iniciar produção
- Lançar o carro.
Converter as necessidades em tarefas é um exercíco que ajuda bastante à comprensão do que precisa ser feito.
É fundamental que o cliente concorde que os seus requisitos serão atendidos através da execução das tarefas no escopo.
Monday, October 27, 2008
A fase Planejamento
Considerada, por este blogueiro, a fase do projeto que mais exige do Gerente de Projeto, essa fase tem as seguintes etapas:
1) Mobilizar o time base do projeto
Planejar um projeto leva tempo e exige recursos. No Descritivo do Projeto (que deveria ter sido preparado na fase anterior), há um "Cronograma Macro do Projeto". Esse cronograma é um excelente ponto de partida para construir o time base do projeto. O time base deve ser composto por pessoas que consigam, a partir do cronograma macro, construir um cronograma detalhado.
Uma vez associados nomes às atividades do cronograma macro, torna-se mais fácil construir a Matriz de Mesponsabilidades (voltaremos a discutir esse tema mais tarde).
2) Construir o Plano Geral do Projeto
O objetivo desta etapa é a construção de um documento único contendo todos os planos do projeto.
A construção de um Plano Geral do Projeto envolve uma "meia dúzia" de sete ou oito passos:
2.1- Descrição do projeto
Cabe uma tentativa de revisão da descrição feita no Descritivo do Projeto. É bem provável que, nesse ponto do projeto algumas idéias já estejam mais maduras permitindo uma descrição mais robusta. Vale a pena tentar re-escrever o descritivo do projeto.
2.1.1 - Resultados pretendidos
É importante enfatizar os resultados pretendidos em um tópico a parte. Essa é uma boa oportunidade de rever os objetivos do projeto. Esse exercício ajudará muito na hora de explicar os objetivos do projeto para a equipe de projeto.
2.1.2 - Escopo/não escopo
Nesse sub-tópico detalha-se o escopo e não escopo do projeto.
2.2 - Projetos relacionados
Um esforço adicional para relacionar todos os projetos que têm alguma relação com o seu projeto pode aumentar as chances de se utilizar parte de uma solução já desenvolvida.
Considerar sinergia é sempre uma boa escolha.
2.3 - Organização do projeto
Nesse tópico são colocados:
2.3.1 Estrutura Organizacional
É recomendável publicar-se a estrutura organizacional do projeto. Essa informação pode poupar algum tempo em um ambiente de grande rotatividade de pessoas como é um projeto.
2.3.2 Diretório de Participantes do Projeto
Esse tópico guarda a lista de todos os participantes do projeto com seus e-mails, celulares, msn, etc...
2.3.3 Papeis e Responsabilidades
Esse é um tópico para determinar (e deixar claro para todos) o como se espera que cada um atue no projeto.
2.3.4 Regras de Escalonamento
Nesse ponto do documento descreve-se em quais situações uma questão deve ser submetida a uma instância superior.
2.4 - Estrutura Analítica do Projeto (WBS)
2.5 - Matriz de Responsabilidades
Uma matriz de responsabilidades determina a participação de cada um dos envolvidos nas tarefas do cronograma macro do projeto.
2.6 - Planilha orçamentária
É fundamental que seja construída uma planilha determinando a previsão de quanto e quando serão executados os gastos do projeto. Ainda que não se tenha um cronograma detalhado nesse momento do projeto, uma estimativa de orçamento garante que o planejamento seja feito levando em consideração o fator custo.
2.7 - Cronograma
Nessa parte do Plano Geral do Projeto se coloca o cronograma detalhado.
2.8 - Plano de Compras
Para os projetos que envolvem compras, um plano de compras deve ser colocado neste tópico do plano geral do projeto.
2.9 Plano de Acompanhamento e Controle
Nesse ponto do Plano Geral do Projeto, coloca-se a forma como se espera fazer o acompanhamento do projeto. As opções são, entre outras:
- Reuniões periódicas de avaliação do progresso
- Envio de relatórios semanais sobre o andamento
- Reuniões específicas em pontos chave do projeto (como eventos de pagamento, por exemplo).
3) Realizar a Reunião de Kick-off
Uma vez determinados todos os planos do projeto e compilados todos em um só documento, realiza-se a reunião de Kick-off concluíndo-se o planejamento e dá-se início à fase de execução.
Voltar para as fases do projeto
1) Mobilizar o time base do projeto
Planejar um projeto leva tempo e exige recursos. No Descritivo do Projeto (que deveria ter sido preparado na fase anterior), há um "Cronograma Macro do Projeto". Esse cronograma é um excelente ponto de partida para construir o time base do projeto. O time base deve ser composto por pessoas que consigam, a partir do cronograma macro, construir um cronograma detalhado.
Uma vez associados nomes às atividades do cronograma macro, torna-se mais fácil construir a Matriz de Mesponsabilidades (voltaremos a discutir esse tema mais tarde).
2) Construir o Plano Geral do Projeto
O objetivo desta etapa é a construção de um documento único contendo todos os planos do projeto.
A construção de um Plano Geral do Projeto envolve uma "meia dúzia" de sete ou oito passos:
2.1- Descrição do projeto
Cabe uma tentativa de revisão da descrição feita no Descritivo do Projeto. É bem provável que, nesse ponto do projeto algumas idéias já estejam mais maduras permitindo uma descrição mais robusta. Vale a pena tentar re-escrever o descritivo do projeto.
2.1.1 - Resultados pretendidos
É importante enfatizar os resultados pretendidos em um tópico a parte. Essa é uma boa oportunidade de rever os objetivos do projeto. Esse exercício ajudará muito na hora de explicar os objetivos do projeto para a equipe de projeto.
2.1.2 - Escopo/não escopo
Nesse sub-tópico detalha-se o escopo e não escopo do projeto.
2.2 - Projetos relacionados
Um esforço adicional para relacionar todos os projetos que têm alguma relação com o seu projeto pode aumentar as chances de se utilizar parte de uma solução já desenvolvida.
Considerar sinergia é sempre uma boa escolha.
2.3 - Organização do projeto
Nesse tópico são colocados:
2.3.1 Estrutura Organizacional
É recomendável publicar-se a estrutura organizacional do projeto. Essa informação pode poupar algum tempo em um ambiente de grande rotatividade de pessoas como é um projeto.
2.3.2 Diretório de Participantes do Projeto
Esse tópico guarda a lista de todos os participantes do projeto com seus e-mails, celulares, msn, etc...
2.3.3 Papeis e Responsabilidades
Esse é um tópico para determinar (e deixar claro para todos) o como se espera que cada um atue no projeto.
2.3.4 Regras de Escalonamento
Nesse ponto do documento descreve-se em quais situações uma questão deve ser submetida a uma instância superior.
2.4 - Estrutura Analítica do Projeto (WBS)
2.5 - Matriz de Responsabilidades
Uma matriz de responsabilidades determina a participação de cada um dos envolvidos nas tarefas do cronograma macro do projeto.
2.6 - Planilha orçamentária
É fundamental que seja construída uma planilha determinando a previsão de quanto e quando serão executados os gastos do projeto. Ainda que não se tenha um cronograma detalhado nesse momento do projeto, uma estimativa de orçamento garante que o planejamento seja feito levando em consideração o fator custo.
2.7 - Cronograma
Nessa parte do Plano Geral do Projeto se coloca o cronograma detalhado.
2.8 - Plano de Compras
Para os projetos que envolvem compras, um plano de compras deve ser colocado neste tópico do plano geral do projeto.
2.9 Plano de Acompanhamento e Controle
Nesse ponto do Plano Geral do Projeto, coloca-se a forma como se espera fazer o acompanhamento do projeto. As opções são, entre outras:
- Reuniões periódicas de avaliação do progresso
- Envio de relatórios semanais sobre o andamento
- Reuniões específicas em pontos chave do projeto (como eventos de pagamento, por exemplo).
3) Realizar a Reunião de Kick-off
Uma vez determinados todos os planos do projeto e compilados todos em um só documento, realiza-se a reunião de Kick-off concluíndo-se o planejamento e dá-se início à fase de execução.
Voltar para as fases do projeto
A fase Iniciação
Atividades importantes da fase:
+ Identificação do problema ou oportunidade
+ Determinação das necessidades
+ Determinação das características principais do produto ou serviço
+ Estudo de viabilidades:
– Técnica
– Econômico-financeira
– Comercial
– Gerencial
Entregáveis (deliverables) da fase:
1) Nomeação do líder do projeto
2) Documento de termo de abertura do projeto (com os seguintes tópicos):
* O nome do projeto
* Justificativa do projeto
* Premissas e restrições
3) Documento descritivo do projeto (com os seguintes tópicos):
* Objetivo do projeto e metas
* Uma descrição do projeto
* Determinação de Escopo e Não Escopo
* Áreas impactadas na empresa
* Um cronograma macro
* Uma previsão orçamentária macro
* Premissas
* Principais riscos do projeto
4) Estudo de viabilidade do projeto.
Lembre-se de que, projetos são ambientes nos quais o fator humano é muito importante. Assim, não se pode dizer que os pontos acima são obrigatórios mas, antes de passar para a fase seguinte do projeto, é importante levá-los em consideração e ainda fazer um estudo de viabilidade. Quanto maior o projeto, maiores serão os benefícios de conduzí-lo de acordo com as melhores práticas.
Voltar para as fases do projeto
+ Identificação do problema ou oportunidade
+ Determinação das necessidades
+ Determinação das características principais do produto ou serviço
+ Estudo de viabilidades:
– Técnica
– Econômico-financeira
– Comercial
– Gerencial
Entregáveis (deliverables) da fase:
1) Nomeação do líder do projeto
2) Documento de termo de abertura do projeto (com os seguintes tópicos):
* O nome do projeto
* Justificativa do projeto
* Premissas e restrições
3) Documento descritivo do projeto (com os seguintes tópicos):
* Objetivo do projeto e metas
* Uma descrição do projeto
* Determinação de Escopo e Não Escopo
* Áreas impactadas na empresa
* Um cronograma macro
* Uma previsão orçamentária macro
* Premissas
* Principais riscos do projeto
4) Estudo de viabilidade do projeto.
Lembre-se de que, projetos são ambientes nos quais o fator humano é muito importante. Assim, não se pode dizer que os pontos acima são obrigatórios mas, antes de passar para a fase seguinte do projeto, é importante levá-los em consideração e ainda fazer um estudo de viabilidade. Quanto maior o projeto, maiores serão os benefícios de conduzí-lo de acordo com as melhores práticas.
Voltar para as fases do projeto
As fases do projeto....
Nenhum projeto vai dar certo ou errado apenas com base em quantas e quais fases ele está dividido. Entretanto, é uma boa prática dividir o projeto em 4 fases:
- Iniciação
- Planejamento
- Execução
- Encerramento
- Iniciação
- Planejamento
- Execução
- Encerramento
Thursday, October 23, 2008
Aquisições
No caso específico de aquisições, o ambiente de projeto não traz grandes particularidades a menos da necessidade das compras estarem disponíveis na data de início das atividades para as quais foram requisitadas.
Por conta disso, é fundamental um plano de compra que considera prazos de entrega de fornecedores. Prazo mínimo de entrega, prazo máximo e prazo mais provável. É preciso ainda levar em consideração esses prazos no momento de elaboração do cronograma do projeto.
Um contrato estipulando multas por atrasos pode ajudar a manter motivados alguns fornecedores. Para o caso de partes críticas, é importante ter um plano backup quando for o caso.
Voltar para Áreas do Conhecimento
Por conta disso, é fundamental um plano de compra que considera prazos de entrega de fornecedores. Prazo mínimo de entrega, prazo máximo e prazo mais provável. É preciso ainda levar em consideração esses prazos no momento de elaboração do cronograma do projeto.
Um contrato estipulando multas por atrasos pode ajudar a manter motivados alguns fornecedores. Para o caso de partes críticas, é importante ter um plano backup quando for o caso.
Voltar para Áreas do Conhecimento
Riscos
O risco é inerente ao ambiente do projeto por ser algo novo e temporário. À medida que aumenta a competição, aumenta também a importância desse fator.
Uma vantagem do Risco em relação a um problema é que o problema já está acontecendo enquanto que um risco é algo que pode acontecer com uma certa probabilidade e que tem um certo impacto caso ocorra.
Define-se os Componentes do Riscos:
Probabilidade
Determinado o evento, estima-se a probabilidade de ocorrência do evento.
Por exemplo:
Probabilidade =
0 (Zero) => se é impossível a ocorrência do evento e
1 (Um ) => se há 100% de chances da ocorrência do evento.
Impacto
De forma independente da probabilidade, estima-se o impacto do evento.
É comum estabelecer notas para o impacto. Ex:
10 - Causará perda de vida humana
5 - Causará prejuízos graves
1 - Causará prejuízos pequenos
Criticidade
A criticidade é calculada multiplicando-se probabilidade pelo impacto.
Criticidade = Probabilidade * Impacto.
Costuma-se criar uma escala de ação de acordo com a criticidade. As possíveis ações são:
1) Alta criticidade = Mitigar o risco
2) Média criticidade (baixo impacto x alta probabilidade) = Monitoramento constante
3) Média criticidade (alto impacto x baixa probabilidade) = Plano de contigência
4) Baixa criticidade = Monitoramento periódico
Estratégias de abordagem da Criticidade:
- Reduzir:
Procura-se reduzir a probabilidade ou o impacto. Normalmente se usa redundância (aviões bi-motores).
- Evitar:
Busca-se outra solução. Ex.: Usar aço ao invés de fibra de carbono ou titânio
- Aceitar:
Em casos de baixa criticidade não é tão grave aceitar um risco (colocando-se um plano de contigência eventualmente).
- Transferir:
As vezes é recomendável transferir o risco pra alguém em melhores condições de tratá-lo.
Ex.: Contratar um cardiologista ao invés de usar o seu irmão enfermeiro no caso de doenças do coração.
Voltar para Áreas do Conhecimento
Uma vantagem do Risco em relação a um problema é que o problema já está acontecendo enquanto que um risco é algo que pode acontecer com uma certa probabilidade e que tem um certo impacto caso ocorra.
Define-se os Componentes do Riscos:
- Evento
- Probabilidade de ocorrência
- Gravidade do impacto ou efeitos ou conseqüência
- Criticidade ou nível de controle (Probabilidade x Impacto)
Probabilidade
Determinado o evento, estima-se a probabilidade de ocorrência do evento.
Por exemplo:
Probabilidade =
0 (Zero) => se é impossível a ocorrência do evento e
1 (Um ) => se há 100% de chances da ocorrência do evento.
Impacto
De forma independente da probabilidade, estima-se o impacto do evento.
É comum estabelecer notas para o impacto. Ex:
10 - Causará perda de vida humana
5 - Causará prejuízos graves
1 - Causará prejuízos pequenos
Criticidade
A criticidade é calculada multiplicando-se probabilidade pelo impacto.
Criticidade = Probabilidade * Impacto.
Costuma-se criar uma escala de ação de acordo com a criticidade. As possíveis ações são:
1) Alta criticidade = Mitigar o risco
2) Média criticidade (baixo impacto x alta probabilidade) = Monitoramento constante
3) Média criticidade (alto impacto x baixa probabilidade) = Plano de contigência
4) Baixa criticidade = Monitoramento periódico
Estratégias de abordagem da Criticidade:
- Reduzir:
Procura-se reduzir a probabilidade ou o impacto. Normalmente se usa redundância (aviões bi-motores).
- Evitar:
Busca-se outra solução. Ex.: Usar aço ao invés de fibra de carbono ou titânio
- Aceitar:
Em casos de baixa criticidade não é tão grave aceitar um risco (colocando-se um plano de contigência eventualmente).
- Transferir:
As vezes é recomendável transferir o risco pra alguém em melhores condições de tratá-lo.
Ex.: Contratar um cardiologista ao invés de usar o seu irmão enfermeiro no caso de doenças do coração.
Voltar para Áreas do Conhecimento
Comunicação
A gestão da comunicação é um dos temas mais negligenciados nos projetos.
Ninguém nunca se esquece de enviar um e-mail pro chefe comunicando o encerramento do projeto com sucesso... mas quase ninguém se lembra de enviar uma mensagem comunicando que sua tarefa está concluída e que está livre pra receber mais trabalho, ou que vai começar a trabalhar numa nova tarefa em dois dias e vai precisar o "formulário amarelo" assinado.
O plano de comunicação deve considerar o canal de comunicação bem como a riqueza de cada canal.
Numa escala que vai de Pobre até Rico há os seguintes passos:
- Canais impessoais = Boletins, Relatórios Gerais no Site do projeto;
- Canais pessoais estáticos = e-mails, cartas
- Canais interativos = telefone, chats
- A presença física = reuniões
Algumas dicas:
É ainda muito importante marcar reuniões periódicas para alinhamento e avaliação de progresso. É uma boa prática marcar tais reuniões já no plano do projeto (tal sessão do Project Chart chama-se Plano de Gerenciamento das Comunicações). Desta forma a agenda dos participantes já fica assegurada com antecedência.
Recomenda-se que o Plano de Gerenciamento das Comunicações tenha:
– Audiência (partes interessadas);
– Agenda;
– Responsável pela comunicação;
– Canal de comunicação;
– Freqüência da comunicação;
Voltar para Áreas do Conhecimento
Ninguém nunca se esquece de enviar um e-mail pro chefe comunicando o encerramento do projeto com sucesso... mas quase ninguém se lembra de enviar uma mensagem comunicando que sua tarefa está concluída e que está livre pra receber mais trabalho, ou que vai começar a trabalhar numa nova tarefa em dois dias e vai precisar o "formulário amarelo" assinado.
O plano de comunicação deve considerar o canal de comunicação bem como a riqueza de cada canal.
Numa escala que vai de Pobre até Rico há os seguintes passos:
- Canais impessoais = Boletins, Relatórios Gerais no Site do projeto;
- Canais pessoais estáticos = e-mails, cartas
- Canais interativos = telefone, chats
- A presença física = reuniões
Algumas dicas:
- Mensagens complexas exigem canais mais ricos. Negociações são melhor conduzidas pessoalmente.
- Mensagens de rotina podem ser enviadas por canais mais pobres
- Não é necessário usar apenas um canal
É ainda muito importante marcar reuniões periódicas para alinhamento e avaliação de progresso. É uma boa prática marcar tais reuniões já no plano do projeto (tal sessão do Project Chart chama-se Plano de Gerenciamento das Comunicações). Desta forma a agenda dos participantes já fica assegurada com antecedência.
Recomenda-se que o Plano de Gerenciamento das Comunicações tenha:
– Audiência (partes interessadas);
– Agenda;
– Responsável pela comunicação;
– Canal de comunicação;
– Freqüência da comunicação;
Voltar para Áreas do Conhecimento
Qualidade
A questão da qualidade é relativamente ampla e pode ser dividida em, pelo menos, dois pontos:
a) Qualidade técnica
A garantia de qualidade técnica, trabalha para que as funcionalidades e características acertadas sejam entregues; evitando-se que o cliente receba um produto inoperante ou em operação parcial.
Para tanto, são realizados os testes de homologação.
b) Qualidade do projeto
Já a qualidade do projeto tenta orientar para que o projeto seja conduzido da maneira correta (se preocupando menos com a qualidade do produto).
Para ajudar a execução de projetos de acordo com as melhores práticas, é comum criar-se formulários e check-lists a serem utilizados ao longo da vida do projeto. Ex.: o termo de abertura do projeto, o descritivo do projeto, o termo de encerramento do projeto, etc...
O uso destes formulários na hora certa pode evitar muitos problemas.
A garantia da qualidade do projeto deve ser um processo natural e não pode ser o ponto mais importante do projeto. É perfeitamente razoável se questionar a utilidade de um campo em um formulário ou do formulário inteiro. Entretanto, esse questionamento deve ser feito no ambiente e no momento certo. Lembre-se que a primeira face da metodologia que todos exergam é um aumento da carga de trabalho.
Ninguém vai ganhar o "Nobel de originalidade" por reclamar de ter que preencher um formulário ou fazer um cronograma.
Voltar para Áreas do Conhecimento
a) Qualidade técnica
A garantia de qualidade técnica, trabalha para que as funcionalidades e características acertadas sejam entregues; evitando-se que o cliente receba um produto inoperante ou em operação parcial.
Para tanto, são realizados os testes de homologação.
b) Qualidade do projeto
Já a qualidade do projeto tenta orientar para que o projeto seja conduzido da maneira correta (se preocupando menos com a qualidade do produto).
Para ajudar a execução de projetos de acordo com as melhores práticas, é comum criar-se formulários e check-lists a serem utilizados ao longo da vida do projeto. Ex.: o termo de abertura do projeto, o descritivo do projeto, o termo de encerramento do projeto, etc...
O uso destes formulários na hora certa pode evitar muitos problemas.
A garantia da qualidade do projeto deve ser um processo natural e não pode ser o ponto mais importante do projeto. É perfeitamente razoável se questionar a utilidade de um campo em um formulário ou do formulário inteiro. Entretanto, esse questionamento deve ser feito no ambiente e no momento certo. Lembre-se que a primeira face da metodologia que todos exergam é um aumento da carga de trabalho.
Ninguém vai ganhar o "Nobel de originalidade" por reclamar de ter que preencher um formulário ou fazer um cronograma.
Voltar para Áreas do Conhecimento
Integração
Integração e sinergia...
Numa viagem de Ji-Paraná(RO) para São Paulo, tive uma escala em Cuiabá. Eu viajava por uma empresa nova no trecho cujas conexões ainda não funcionavam muito bem. Cheguei em Cuiabá e, enquanto curtia minhas 4 horas de espera no aeroporto, tive a oportunidade de ver como deveria ser feito. A experiência durou menos de 30 minutos...
Nessa janela de tempo, dois aviões grandes, vindos de regiões completamente diferentes no pais, pousaram, trocaram passageiros, bagagens e carga e levantaram vôo. E eu fiquei ali procurando um bom motivo pra ter escolhido a outra compania aérea. O preço da passagem não serviu como desculpa dessa vez...
Garantir a integração nem sempre é uma tarefa fácil e só é possível através do planejamento. Duas tarefas não planejadas só acontecerão no momento ideial se Murphi estiver de férias... por isso, planeje, otimeze o plano, reveja a relação entre as tarefas, reveja a alocação das pessoas.
Terminado o cronograma, faça uma análise do caminho crítico (assunto a ser abordado em post a parte).
A integração também não existe sem uma comunicação apropriada (mas essa é outra área do conhecimento).
Voltar para Áreas do Conhecimento
Numa viagem de Ji-Paraná(RO) para São Paulo, tive uma escala em Cuiabá. Eu viajava por uma empresa nova no trecho cujas conexões ainda não funcionavam muito bem. Cheguei em Cuiabá e, enquanto curtia minhas 4 horas de espera no aeroporto, tive a oportunidade de ver como deveria ser feito. A experiência durou menos de 30 minutos...
Nessa janela de tempo, dois aviões grandes, vindos de regiões completamente diferentes no pais, pousaram, trocaram passageiros, bagagens e carga e levantaram vôo. E eu fiquei ali procurando um bom motivo pra ter escolhido a outra compania aérea. O preço da passagem não serviu como desculpa dessa vez...
Garantir a integração nem sempre é uma tarefa fácil e só é possível através do planejamento. Duas tarefas não planejadas só acontecerão no momento ideial se Murphi estiver de férias... por isso, planeje, otimeze o plano, reveja a relação entre as tarefas, reveja a alocação das pessoas.
Terminado o cronograma, faça uma análise do caminho crítico (assunto a ser abordado em post a parte).
A integração também não existe sem uma comunicação apropriada (mas essa é outra área do conhecimento).
Voltar para Áreas do Conhecimento
Gerindo Recursos Humanos
Em termos de recursos humanos, um Gerente de Projeto deveria saber, pelo menos:
- Otimizar o desempenho da equipe.
As pessoas são mais eficientes quando estão satisfeitas. Assim, é importante que elas tenham suas espectativas satisfeitas, estejam bem remuneradas, tenham perspectiva de crescimento, participem do processo decisório e estejam bem informadas do que se passa.
Entretanto, é também muito importante a percepção das pessoas em relação a cada um dos pontos acima. Por exemplo, não basta pagar mais para que um funcionário tenha a percepção de que é bem remunerado.
Algumas ações de recursos humanos são caras (aumento de salário, por ex.) outras nem tanto assim. Ouvir a equipe não custa tanto e tem um impacto positivo além de dar a chance de satisfazer outros desejos (se tais desejos couberem no budget). Um elogio sincero também ajuda bastante.
- Ter a pessoa certa para a tarefa certa na hora certa
As pessoas não nascem prontas. Elas precisam (e podem) ser preparadas. Por conta disso, um inventário com as principais características de cada funcionário da empresa é muito importante. Se a empresa conhece a capacidade de aprendizado, as experiências afins e a vontade de um determinado funcionário em participar de um determinado projeto. Há uma enorme oportunidade de treiná-lo (antes ou "on the job"). Dessa forma, ao final do projeto, além dos lucros proporcionados pelo produto entregue, há ainda um profissional mais capacitado e mais motivado na empresa além da percepção (para todos os outros funcionários) de que "aqui" vale a pena vestir a camisa.
Porém, quando não é possível, nem sempre o projeto pode esperar e o papel do Gerente de Projeto é garantir que o recurso certo esteja disponível na hora necessária (dentro do custo previsto se possível).
Voltar para Áreas do Conhecimento
- Otimizar o desempenho da equipe.
As pessoas são mais eficientes quando estão satisfeitas. Assim, é importante que elas tenham suas espectativas satisfeitas, estejam bem remuneradas, tenham perspectiva de crescimento, participem do processo decisório e estejam bem informadas do que se passa.
Entretanto, é também muito importante a percepção das pessoas em relação a cada um dos pontos acima. Por exemplo, não basta pagar mais para que um funcionário tenha a percepção de que é bem remunerado.
Algumas ações de recursos humanos são caras (aumento de salário, por ex.) outras nem tanto assim. Ouvir a equipe não custa tanto e tem um impacto positivo além de dar a chance de satisfazer outros desejos (se tais desejos couberem no budget). Um elogio sincero também ajuda bastante.
- Ter a pessoa certa para a tarefa certa na hora certa
As pessoas não nascem prontas. Elas precisam (e podem) ser preparadas. Por conta disso, um inventário com as principais características de cada funcionário da empresa é muito importante. Se a empresa conhece a capacidade de aprendizado, as experiências afins e a vontade de um determinado funcionário em participar de um determinado projeto. Há uma enorme oportunidade de treiná-lo (antes ou "on the job"). Dessa forma, ao final do projeto, além dos lucros proporcionados pelo produto entregue, há ainda um profissional mais capacitado e mais motivado na empresa além da percepção (para todos os outros funcionários) de que "aqui" vale a pena vestir a camisa.
Porém, quando não é possível, nem sempre o projeto pode esperar e o papel do Gerente de Projeto é garantir que o recurso certo esteja disponível na hora necessária (dentro do custo previsto se possível).
Voltar para Áreas do Conhecimento
Tempo
3) Tempo
Nunca gostei do tempor "Gerir o tempo". O que se faz na verdade é a gestão de um cronograma e de pessoas que cumprem esse cronograma.
Como GP, você deve ter claro que nem todos os componentes de sua equipe são tão pro-ativos quanto você. Assim, você precisa ter muito claro, quais são as próximas atividades a serem executadas e quem deve executá-las. Você deve ainda fazer o follow up com cada um antes da tarefa começar (pra garantir que o responsável tenha tudo o que precisa pra iniciar a tarefa). Não corra o risco de ouvir justificativas do tipo: "não fiz porque o formulário amarelo não chegou". Pergunte antes, se é necessário um formulário amarelo, descubra quem tem que enviar e garanta que o bendito formulário amarelo estará disponível.
Voltar para Áreas de Conhecimento
Nunca gostei do tempor "Gerir o tempo". O que se faz na verdade é a gestão de um cronograma e de pessoas que cumprem esse cronograma.
Como GP, você deve ter claro que nem todos os componentes de sua equipe são tão pro-ativos quanto você. Assim, você precisa ter muito claro, quais são as próximas atividades a serem executadas e quem deve executá-las. Você deve ainda fazer o follow up com cada um antes da tarefa começar (pra garantir que o responsável tenha tudo o que precisa pra iniciar a tarefa). Não corra o risco de ouvir justificativas do tipo: "não fiz porque o formulário amarelo não chegou". Pergunte antes, se é necessário um formulário amarelo, descubra quem tem que enviar e garanta que o bendito formulário amarelo estará disponível.
Voltar para Áreas de Conhecimento
Custos
2) Custos
Gerir custos exige:
1) Planejar o projeto dentro de um nível razoável de detalhes. Somente planejando razoavelmente será possível avaliar quanto de cada recurso será necessário e em que momento do projeto.
A gestão de custos parte de um cronograma. No cronograma, definidas as tarefas e suas datas de início e fim, é possível alocar os recursos necessários para a mesma.
Uma vez alocados os recursos, é ainda necessário avaliar se o projeto exigirá custos adicionais com viagens, reuniões, treinamentos, máquinas, softwares, etc...
Uma parte dos custos de um projeto pode ser estimada multiplicando-se o valor/hora de um recurso pelo tempo que o recurso será necessário (essa informação vem do cronograma).
A outra parte do custo do projeto vem das despesas adicionais (viagens, cursos, máquinas, etc...)
Desta forma, é possível até construir o fluxo de caixa planejado do projeto detarminando não somente o custo do projeto mas quando será necessário dispor do dinheiro. Colocar os custos de um projeto em um fluxo de caixa pode ser a diferença entre a aprovação ou a reprovação de uma proposta de projeto.
Voltar para Áreas de Conhecimento
Gerir custos exige:
1) Planejar o projeto dentro de um nível razoável de detalhes. Somente planejando razoavelmente será possível avaliar quanto de cada recurso será necessário e em que momento do projeto.
A gestão de custos parte de um cronograma. No cronograma, definidas as tarefas e suas datas de início e fim, é possível alocar os recursos necessários para a mesma.
Uma vez alocados os recursos, é ainda necessário avaliar se o projeto exigirá custos adicionais com viagens, reuniões, treinamentos, máquinas, softwares, etc...
Uma parte dos custos de um projeto pode ser estimada multiplicando-se o valor/hora de um recurso pelo tempo que o recurso será necessário (essa informação vem do cronograma).
A outra parte do custo do projeto vem das despesas adicionais (viagens, cursos, máquinas, etc...)
Desta forma, é possível até construir o fluxo de caixa planejado do projeto detarminando não somente o custo do projeto mas quando será necessário dispor do dinheiro. Colocar os custos de um projeto em um fluxo de caixa pode ser a diferença entre a aprovação ou a reprovação de uma proposta de projeto.
Voltar para Áreas de Conhecimento
Gerir Escopo
1) Gerir Escopo
1.1) Levantamento de necessidades
Nessa etapa, o Gerente de Projeto ouve o cliente numa entrevista dirigida, fazendo perguntas que levem o cliente a dar mais detalhes sobre o que ele deseja.
Nem sempre o cliente sabe expressar seu desejo. Lembre-se de que, se ele fosse capaz de colocar o que quer de maneira clara e ordenada, talvez já tivesse feito e o projeto não seria mais necessário.
É importante o uso de perguntas abertas (evite perguntas com respostas do tipo "sim" ou "não"). Quanto mais o cliente falar, maiores são as chances de se capturar funcionalidades "escondidas" que encantarão o cliente.
1.2) Estabelecer o escopo
Uma vez determinadas as reais necessidades do cliente, deve-se "traduzir" essas necessidades para especificações técnicas.
Por exemplo:
- Necessidade: "Eu queria não perder tanto tempo enviando mala direta pelo correio para os meus clientes"
- Especificações técnicas:
a) Treinar funcionários pra passar a pegar/atualizar o e-mail dos clientes
b) Cadastrar os e-mails dos clientes
c) Criar texto a ser enviado por mala-direta
d) Desenvolver um programa de "mailing"
e) Passar a enviar as malas diretas de forma automática
1.3) Estabelecimento do Escopo
Uma vez determinadas as especificações técnicas, é preciso garantir que o cliente concorde que a execução dos tópicos descritos nas especificações técnicas satisfará as suas necessidades.
Para que o cliente concorde, muitas vezes ele exige uma prova de conceito ou a construção de um protótipo. Entretanto, uma vez concordado, o escopo passa ser o Descrito nas Especificações Técnicas e não mais as Necessidades do Cliente.
Uma desmonstração clara e precisa de como as especificações técnicas garantem a satisfação das necessidades do cliente bem como a documentação precisa do processo de estabelecimento do escopo (PRINCIPALMENTE COM ATAS DE REUNIÕES) é fundamental para evitar stress desnecessário na fase final do projeto.
O Gerente de Projeto deve sempre garantir a entrega do escopo (nem mais e nem menos que isso). Algumas vezes o escopo muda durante o projeto (o que não é nenhum pecado desde que a mudança seja submetida a um processo formal de aprovação e seja replanejada envolvendo renegociação de custos, riscos e prazos).
Voltar para Áreas de Conhecimento
1.1) Levantamento de necessidades
Nessa etapa, o Gerente de Projeto ouve o cliente numa entrevista dirigida, fazendo perguntas que levem o cliente a dar mais detalhes sobre o que ele deseja.
Nem sempre o cliente sabe expressar seu desejo. Lembre-se de que, se ele fosse capaz de colocar o que quer de maneira clara e ordenada, talvez já tivesse feito e o projeto não seria mais necessário.
É importante o uso de perguntas abertas (evite perguntas com respostas do tipo "sim" ou "não"). Quanto mais o cliente falar, maiores são as chances de se capturar funcionalidades "escondidas" que encantarão o cliente.
1.2) Estabelecer o escopo
Uma vez determinadas as reais necessidades do cliente, deve-se "traduzir" essas necessidades para especificações técnicas.
Por exemplo:
- Necessidade: "Eu queria não perder tanto tempo enviando mala direta pelo correio para os meus clientes"
- Especificações técnicas:
a) Treinar funcionários pra passar a pegar/atualizar o e-mail dos clientes
b) Cadastrar os e-mails dos clientes
c) Criar texto a ser enviado por mala-direta
d) Desenvolver um programa de "mailing"
e) Passar a enviar as malas diretas de forma automática
1.3) Estabelecimento do Escopo
Uma vez determinadas as especificações técnicas, é preciso garantir que o cliente concorde que a execução dos tópicos descritos nas especificações técnicas satisfará as suas necessidades.
Para que o cliente concorde, muitas vezes ele exige uma prova de conceito ou a construção de um protótipo. Entretanto, uma vez concordado, o escopo passa ser o Descrito nas Especificações Técnicas e não mais as Necessidades do Cliente.
Uma desmonstração clara e precisa de como as especificações técnicas garantem a satisfação das necessidades do cliente bem como a documentação precisa do processo de estabelecimento do escopo (PRINCIPALMENTE COM ATAS DE REUNIÕES) é fundamental para evitar stress desnecessário na fase final do projeto.
O Gerente de Projeto deve sempre garantir a entrega do escopo (nem mais e nem menos que isso). Algumas vezes o escopo muda durante o projeto (o que não é nenhum pecado desde que a mudança seja submetida a um processo formal de aprovação e seja replanejada envolvendo renegociação de custos, riscos e prazos).
Voltar para Áreas de Conhecimento
Monday, October 20, 2008
Sunday, October 19, 2008
O Escopo do Projeto
Já o escopo do Projeto pode ser definido como o conjunto de ações (ou atividades) cujo resultado é um produto com as características e funções descritas no escopo do produto.
Exemplo:
a) Para atender a funcionalidade de comunicação
a.1) Desenvolver uma antena
a.2) Desenvolver programa compatível com o padrão de comunicação
a.3) Testar
b) Para atender a função de divertimento
b.1) Desenvolver jogos
b.2) Desenvolver browser
b.3) Acesso à internet
b.4) Disponibilizar joguinhos e músicas para download
b.5) Etc...
As chances de sucesso de um projeto são muito maiores quando o cliente e a equipe de projetos trabalham juntos na compreensão do escopo do produto e na "tradução" desse escopo em "escopo do projeto".
Assim feito, a equipe do projeto pode dedicar-se integralmente a atingir as metas do projeto deixando de se questionar se o produto irá (ou não) atingir suas metas.
Voltar
Exemplo:
a) Para atender a funcionalidade de comunicação
a.1) Desenvolver uma antena
a.2) Desenvolver programa compatível com o padrão de comunicação
a.3) Testar
b) Para atender a função de divertimento
b.1) Desenvolver jogos
b.2) Desenvolver browser
b.3) Acesso à internet
b.4) Disponibilizar joguinhos e músicas para download
b.5) Etc...
As chances de sucesso de um projeto são muito maiores quando o cliente e a equipe de projetos trabalham juntos na compreensão do escopo do produto e na "tradução" desse escopo em "escopo do projeto".
Assim feito, a equipe do projeto pode dedicar-se integralmente a atingir as metas do projeto deixando de se questionar se o produto irá (ou não) atingir suas metas.
Voltar
O Escopo do Produto
Uma dica para ajudar na distinção:
Um produto pode ser definido através de suas funções e características.
Ex.:
As seguintes "funções" e "características"...
a) Exemplo de funções:
- Comunicação
- Divertimento
- Armazenar contatos
- Despertador
- Alta duração de bateria
- Baixo tempo de recarga
e
b) exemplo de características:
- Visor de cristal líquido
- Teclas iluminadas
- Leve
- Dobrável
Podem caracterizar o Escopo do Produto no projeto de um telefone celular.
Voltar
Um produto pode ser definido através de suas funções e características.
Ex.:
As seguintes "funções" e "características"...
a) Exemplo de funções:
- Comunicação
- Divertimento
- Armazenar contatos
- Despertador
- Alta duração de bateria
- Baixo tempo de recarga
e
b) exemplo de características:
- Visor de cristal líquido
- Teclas iluminadas
- Leve
- Dobrável
Podem caracterizar o Escopo do Produto no projeto de um telefone celular.
Voltar
Friday, October 17, 2008
S.M.A.R.T - Definindo objetivos...
Os objetivos do projeto devem seguir a regra S.M.A.R.T
Ex.: O objetivo desse projeto é desenvolver um novo modelo de carro popular a ser entregue em Abril de 2015.
S - Specific (o objetivo precisa ser específico)
O objetivo é específico (não um avião, não uma lancha, um CARRO)
M - Measurable (o objetivo precisa ser mensurável)
ex: O objetivo é um carro. Dá pra medir no final do projeto se o carro está pronto ou não.
A - Accurate (precisa ser exato)
No exemplo acima, não resta dúvidas quanto a precisão do objetivo. Essa precisão é importante também em termos de tempo (Abril de 2015).
R - Realistic (precisa ser realista)
Para ser realista é preciso considerar o contexto. No caso de uma empresa de TI, esse objetivo pode não ser realista mas para a Toyota ou a Ford, é um objetivo realista.
T - Time Bounded (limitado no tempo)
Um objetivo precisa levar o tempo em consideração. Por isso Abril/2005 no exemplo.
Voltar para "Gerenciar projetos é..."
Ex.: O objetivo desse projeto é desenvolver um novo modelo de carro popular a ser entregue em Abril de 2015.
S - Specific (o objetivo precisa ser específico)
O objetivo é específico (não um avião, não uma lancha, um CARRO)
M - Measurable (o objetivo precisa ser mensurável)
ex: O objetivo é um carro. Dá pra medir no final do projeto se o carro está pronto ou não.
A - Accurate (precisa ser exato)
No exemplo acima, não resta dúvidas quanto a precisão do objetivo. Essa precisão é importante também em termos de tempo (Abril de 2015).
R - Realistic (precisa ser realista)
Para ser realista é preciso considerar o contexto. No caso de uma empresa de TI, esse objetivo pode não ser realista mas para a Toyota ou a Ford, é um objetivo realista.
T - Time Bounded (limitado no tempo)
Um objetivo precisa levar o tempo em consideração. Por isso Abril/2005 no exemplo.
Voltar para "Gerenciar projetos é..."
Gerenciar projetos é...
Uma das diferenças entre um projeto e uma atividade cotidiana é o fato de que o projeto propõe-se a construir algo novo. Mesmo no caso de construção de casas, ainda que se esteja construíndo várias casas iguaisç sempre acontece algo novo em cada casa.
Fatos corriqueiros como um funcionário ficou doente, o Corinthians perdeu ou acabou o cimento; cada um pode se tornar uma justificativa para um atraso na obra.
Assim, o Gerente de Projeto precisa administrar estas incertezas do projeto, planejando a execução antes do seu início. Após um plano bem feito, é preciso controlar a execução do projeto garantindo que ele seja concluído dentro do Prazo, conforme o Orçamento aprovado e que o objetivo do projeto seja entregue no Padrão de Qualidade acertado.
Um projeto não nasce pronto. Antes que se possa ver o produto ou serviço no mercado, é necessário algumas informações básicas. Supondo que um projeto possa ser dividido em fases: Preparação, Planejamento, Execução e Encerramento; veja abaixo algumas informações importantes por fase.
Fase 1: Preparação
Nessa fase é importante ter claro, pelo menos os seguintes pontos:
O Objetivo do Projeto
Para se ter uma boa definição do objetivo do projeto, é preciso abusar da capacidade de ouvir o cliente (interno ou externo). O objetivo do projeto é, geralmente, um produto ou um serviço a ser desenvolvido.
Os objetivos do projeto devem seguir a regra S.M.A.R.T
A Justificativa do Projeto
É interessante, nesse momento, tentar descrever uma justificativa do projeto. Uma boa justificativa responderá a pergunta: "Por que alguém investiria dinheiro nessa idéia?"
O núcleo da equipe (time base)
Um outro ponto importante a considerar é quem comporá a equipe básica do projeto. Nesse instante, não é necessário ainda dar nome aos cargos mas é interessante levantar quais competências seriam interessantes para cada papel na equipe básica.
Premissas e restrições
Um outro ponto de fundamenteal importância são as premissas e restrições. Nesse tópico se estabelece, mais do que uma "proteções" para o idealizador do projeto, pontos relevantes a serem "observados" sem os quais, a entrega do projeto fica comprometida.
Ex.:
- É preciso que o Budget seja liberado antes do final do projeto.
- É preciso que, no máximo, 30% da equipe torça pro Corinthians devido a atrasos na obra quando o Corinthians perde.
- Etc...
Metas do Projeto
Nem sempre é simples diferenciar "Metas do projeto" de "Objetivos do projeto" (previamente definidos). Essa é, no entanto um bom momento pra rever e aprofundar os objetivos aproveitando a chance para colocar sub-produtos ou objetivos parciais.
Por exemplo, no caso do projeto de um novo carro, o Objetivo é o carro, mas as metas poderiam ser:
a) Subproduto:
- Uma equipe com experiência em projetos de carro
- Certificar 30% da equipe como PMP
- etc...
b) Objetivos parciais
- Conseguir financiamento do BNDS até Nov/2010
- Ter o primeiro protótipo até Mar/2012
- etc...
Fase 2: Planejar
2.1) O Escopo
É muito comum a confusão entre o produto (ou serviço que se deseja desenvolver) e o projeto que desenvolverá o produto/serviço. Se produto e projeto já causam confusão, o risco é ainda maior quando se fala de Escopo do Produto e Escopo do projeto.
2.1.1) O Escopo do Produto
2.1.2) O Escopo do Projeto
(to be continued...)
Fatos corriqueiros como um funcionário ficou doente, o Corinthians perdeu ou acabou o cimento; cada um pode se tornar uma justificativa para um atraso na obra.
Assim, o Gerente de Projeto precisa administrar estas incertezas do projeto, planejando a execução antes do seu início. Após um plano bem feito, é preciso controlar a execução do projeto garantindo que ele seja concluído dentro do Prazo, conforme o Orçamento aprovado e que o objetivo do projeto seja entregue no Padrão de Qualidade acertado.
Um projeto não nasce pronto. Antes que se possa ver o produto ou serviço no mercado, é necessário algumas informações básicas. Supondo que um projeto possa ser dividido em fases: Preparação, Planejamento, Execução e Encerramento; veja abaixo algumas informações importantes por fase.
Fase 1: Preparação
Nessa fase é importante ter claro, pelo menos os seguintes pontos:
O Objetivo do Projeto
Para se ter uma boa definição do objetivo do projeto, é preciso abusar da capacidade de ouvir o cliente (interno ou externo). O objetivo do projeto é, geralmente, um produto ou um serviço a ser desenvolvido.
Os objetivos do projeto devem seguir a regra S.M.A.R.T
A Justificativa do Projeto
É interessante, nesse momento, tentar descrever uma justificativa do projeto. Uma boa justificativa responderá a pergunta: "Por que alguém investiria dinheiro nessa idéia?"
O núcleo da equipe (time base)
Um outro ponto importante a considerar é quem comporá a equipe básica do projeto. Nesse instante, não é necessário ainda dar nome aos cargos mas é interessante levantar quais competências seriam interessantes para cada papel na equipe básica.
Premissas e restrições
Um outro ponto de fundamenteal importância são as premissas e restrições. Nesse tópico se estabelece, mais do que uma "proteções" para o idealizador do projeto, pontos relevantes a serem "observados" sem os quais, a entrega do projeto fica comprometida.
Ex.:
- É preciso que o Budget seja liberado antes do final do projeto.
- É preciso que, no máximo, 30% da equipe torça pro Corinthians devido a atrasos na obra quando o Corinthians perde.
- Etc...
Metas do Projeto
Nem sempre é simples diferenciar "Metas do projeto" de "Objetivos do projeto" (previamente definidos). Essa é, no entanto um bom momento pra rever e aprofundar os objetivos aproveitando a chance para colocar sub-produtos ou objetivos parciais.
Por exemplo, no caso do projeto de um novo carro, o Objetivo é o carro, mas as metas poderiam ser:
a) Subproduto:
- Uma equipe com experiência em projetos de carro
- Certificar 30% da equipe como PMP
- etc...
b) Objetivos parciais
- Conseguir financiamento do BNDS até Nov/2010
- Ter o primeiro protótipo até Mar/2012
- etc...
Fase 2: Planejar
2.1) O Escopo
É muito comum a confusão entre o produto (ou serviço que se deseja desenvolver) e o projeto que desenvolverá o produto/serviço. Se produto e projeto já causam confusão, o risco é ainda maior quando se fala de Escopo do Produto e Escopo do projeto.
2.1.1) O Escopo do Produto
2.1.2) O Escopo do Projeto
(to be continued...)
Thursday, October 16, 2008
Sete pontos importantes para um bom GP
- Entusiasmo pelo projeto
- Gerenciar mudança de forma efetiva
- Atitude tolerante a respeito da ambiguidade
- Competência para União do Time e Negociação
- Orientação ao cliente
- Aderência às Prioridades do Negócio
- Conhecimento do negócio
"The complete Idiot's Guide to Project Management" - 4a Edição
Campbell, G. M
Baker, S.
Editora Alpha.
Os diferentes papeis do GP:
Papel interpessoal:
- Trabalhar de forma efetiva com gente de formação diversa
- Criar a unidade no time (resolvendo disputas)
- Mater o foco e a motivação dos componentes da equipe
- Manter um relacionamento positivo com os Stakeholders
- "Ficar rouco de tanto OUVIR"
- Programar e conduzir reuniões periódicas
- Criar e manter o cronograma de trabalho dos membros do time
- Comunicar a visão do projeto para os Stakeholders
- Providenciar avaliações periódicas com relação aos "deliverables" de cada etapa.
- Empregar recursos adicionais de forma apropriada quando o projeto exige
- Manter o equilíbrio entre Budget, Prazo e Qualidade
- Evitar "fugir do escopo" e "estourar o budget".
São Responsabilidades do GP:
- A estrutura organizacional do projeto com seus papeis e
responsabilidades; - A montagem da equipe de projeto;
- Viabilizar a capacitação da equipe nas competências necessárias ao projeto;
- Gerenciar os relacionamentos interpessoais e organizacionais;
- Intermediar o relacionamento entre a gerência superior e a equipe de projeto;
- Transmitir as lições aprendidas;
Fatores Essenciais de Sucesso de qualquer projeto
- Alinhamento entre os stakeholders (internos e externos) e a equipe do projeto a respeito dos objetivos do projeto.
- Suporte da diretoria no que se refere tanto a disponibilizar recursos quanto a remoção de obstáculos.
- Comunicação efetiva.
O equilíbrio entre Tempo, Recursos, Resultados e Percepção...
Uma das maiores dificuldades em gestão de projeto é o equilíbrio entre Tempo, Recurso e Qualidade dos Resultados entregues (também denominado "Percepção do Cliente".
Um bom GP vai tentar descobrir qual dos três vértices (a Qualidade, o Prazo ou o Budget) tem maior impácto na percepção do cliente.
Por conta disso, é necessário levar em consideração os Fatores Essenciais de Sucesso do Projeto.
Mais que "fazer certo" é preciso fazer a coisa certa!!
Não basta fazer certo...
Huguinho é excelente em matemática mas está indo mal em geografia. Sua mãe (a irmã do Pato Donald) o manda estudar e ele passa a tarde toda no quarto estudando o que gosta.
Não precisa ser o gênio estrategista de negócios "Tio Patinhas" pra saber que a nota do Huguinho não vai melhorar.
Antes de mais nada, os objetivos do projeto precisam estar alinhados com os objetivos estratégicos da empresa.
Um projeto nasce para atender a uma necessidade.
- Uma necessidade de mercado
- Uma oportunidade de negócio
- Um objetivo estratégico de:
. Treinar 80% do pessoal em um determinado tema
. Elevar o IDH da comunidade que mora em volta da empresa
. etc
Huguinho é excelente em matemática mas está indo mal em geografia. Sua mãe (a irmã do Pato Donald) o manda estudar e ele passa a tarde toda no quarto estudando o que gosta.
Não precisa ser o gênio estrategista de negócios "Tio Patinhas" pra saber que a nota do Huguinho não vai melhorar.
Antes de mais nada, os objetivos do projeto precisam estar alinhados com os objetivos estratégicos da empresa.
Um projeto nasce para atender a uma necessidade.
- Uma necessidade de mercado
- Uma oportunidade de negócio
- Um objetivo estratégico de:
. Treinar 80% do pessoal em um determinado tema
. Elevar o IDH da comunidade que mora em volta da empresa
. etc
Subscribe to:
Posts (Atom)
