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.
Subscribe to:
Posts (Atom)
