blog.tenstep.com.br

Uma das características de um projeto são as datas definidas para o início e para o término das atividades. Isso parece simples até que você começa a tentar definir exatamente o significado das datas. Não há um padrão universal recomendado para as datas. Em muitos casos, isso depende da organização e de algumas implicações na escolha entre uma ou outra alternativa. Segue abaixo algumas opções para identificar a data de início.

A geração de idéia. Isso marca a data do início bem antes do projeto ser formalizado e na primeira vista poderá não fazer sentido. Entretanto, lembre-se que a definição que você escolher poderá depender do foco da sua empresa. Por exemplo, você poderá escolher esta definição se a sua empresa estiver focando em reduzir o tempo requerido entre a geração de idéias e a implantação das mesmas. Neste caso, a preocupação é com o tempo requerido para implantar boas idéias. Se a sua empresa deseja minimizar o tempo requerido entre a geração de idéias e a realização das mesmas, você poderá escolher essa definição de data de início projeto.

O orçamento é aprovado. Esta definição é um pouco mais concreta do que a primeira. Nesta definição uma idéia foi gerada e uma avaliação dos custos / benefícios foi feita. O projeto também passa pelo processo de priorização e tem um orçamento aprovado. Tenha em mente, que o orçamento poderá ter sido aprovado anteriormente durante o processo de planejamento do negócio e o trabalho atual poderá ter início somente no próximo ano. Por esse motivo, para muitas empresas essa definição poderá não ser adequada.

O gerente do projeto é designado. Essa situação é a mais comum. Pode ser difícil para você declarar que um projeto começou antes de ter um gerente de projeto designado. A definição utilizada pela metodologia TenStep PGp® é a seguinte: O planejamento e a definição do projeto começam quando o gerente do projeto é designado.

O Termo de abertura do projeto é aprovado pelo cliente. Em algumas organizações o projeto começa oficialmente quando o cliente aprova o documento “Termo de abertura do projeto”. Algumas empresas requerem um Termo de abertura do projeto, um cronograma e um orçamento aprovado antes da equipe ser designada. Normalmente isso é feito para assegurar que o acordo seja aprovado antes do trabalho do projeto começar.

A reunião do início do projeto (kickoff) é realizada. Usando esta definição, o planejamento e a definição do trabalho são considerados trabalhos de “pré-projeto”. Todos os projetos começam com a realização de uma reunião de início do projeto (kickoff) com o cliente e com a equipe do projeto. Quando esta reunião é realizada, o planejamento já foi completado, o cliente já aprovou o começo do trabalho e a equipe do projeto já foi designada. A reunião é o momento para comunicar a todos, que o projeto está pronto para começar.

Porque a data de início é importante

Você poderá pensar que isso não é uma substancia real quando o projeto começa. Não ter uma data de início definida, não significa que o trabalho não seja um projeto. É óbvio que em algum ponto o projeto começou. Todo  projeto tem um ponto em que o trabalho não está em progresso e um ponto quando o trabalho entra em progresso. Assim, em algum ponto de fato o projeto “Inicia”.

É importante saber a data do início, porque, poderá haver conseqüências e incentivos ao longo do tempo para completar o projeto. Os exemplos dessas conseqüências e de incentivos são os seguintes:

Responsabilidade da equipe do projeto. É difícil considerar que as pessoas sejam responsáveis por coisas que elas não têm sobre controle. Por está razão, faz sentido que o gerente do projeto seja considerado responsável pelo projeto a partir do momento em que ele for designado, e não antes. Se o cronômetro começar antes do gerente do projeto ser designado, é possível que algumas decisões já foram tomadas e alguns recursos já foram utilizados antes dele começar, e por essa razão ele não terá o controle total do projeto. Do mesmo modo, se os membros das equipes forem considerados responsáveis para completar o projeto dentro do orçamento e do cronograma, ficará difícil de considerá-los responsáveis pelo trabalho e pelas decisões tomadas antes deles serem designados. Por essa razão, talvez o projeto deva começar oficialmente somente quando o documento “Termo de abertura do projeto, o Cronograma” e o “Orçamento” forem aprovados, ou após a reunião de início do projeto (kickoff) ser realizada.

Melhorias dos processos. Muitas empresas mantêm informação sobre o tempo de duração total dos projetos e fazem tentativas para encurtar em média este tempo. É importante que todas as pessoas dentro da empresa usem um ponto padronizado para marcar o início e um ponto para marcar o final de todos os projetos, ou os números referentes a duração dos projetos não terão significado.

Financiamento / Contabilidade. Muitos projetos são considerados despesas capitais. Esta definição, quando o projeto começa, tem conseqüências em termos das atividades que podem ser capitalizadas e as atividades que necessitam ser despesas.

Comparações com outras empresas. Se você comparar o tempo que a sua empresa utiliza para entregar os projetos vs. outras empresas, você deverá assegurar-se de ter uma definição em comum entre as empresas sobre a data de início e a data final dos projetos. Se a sua empresa considera que os projetos começam quando o gerente de projetos é designado e as outras empresas consideram que os projetos começam somente quando a reunião de início (Kick-off) dos projetos é realizada, isso aparentará que a sua empresa levará mais tempo para entregar os projetos.

Sumário

Todos os projetos têm uma data de início. Mas saber exatamente quando um projeto começa é algo que as empresas podem definir de forma diferente. Há um número de eventos que seriam candidatos a data de início. Se a sua empresa não capturar métricas e não oferecer incentivos baseados na conclusão do projeto na data acordada e dentro do orçamento, então isso realmente não é importante. Entretanto, se haver conseqüências baseada na Data de início definida, então a empresa deve ser cuidadosa e certificar-se de que a data de início definida conduz ao comportamento apropriado que estão tentando conseguir.

Para maiores detalhes sobre a definição de um projeto, veja  >> Definir o Projeto

Sem comentários »

Um dos objetivos de coletar métricas é para capturar precisamente o valor de um projeto produzido. Em alguns casos, o valor é óbvio. Por exemplo, as vendas poderiam aumentar, o nível dos estoques poderia ser reduzido, e um número menor de pessoas poderiam estar envolvidas nos processos. Porém, em muitos casos, estas informações podem ser difíceis ou até mesmo impossíveis de serem quantificadas com exatidão. Alguns problemas comuns incluem:

- O projeto produz benefícios leves, tal como melhoramento na satisfação do cliente ou na qualidade dos produtos.

- O projeto envolve infra-estrutura que é utilizada para grandes grupos de pessoas. Por exemplo, quão mais produtivos seríamos se os computadores tivessem o dobro de memória que eles têm hoje? Qual é o valor quantitativo fornecido com a implementação de um novo sistema interno de telefone? Estes tipos de perguntas são difíceis para quantificar o benefício do negócio.

- O projeto resulta em um aumento de informações disponíveis para as pessoas. É difícil saber exatamente como estas informações serão utilizadas para as tomadas de decisões mais precisas e conscientes.

- O resultado da execução dos projetos múltiplos ao longo do tempo resulta em melhor desempenho dos sistemas, dos processos, da produtividade, etc., mas é difícil saber exatamente o valor entregue em cada projeto.

- Pequenos melhoramentos que são difíceis de serem observados com significância. Por exemplo, na eliminação de passos em um processo, o processo leva menos tempo, mas o tempo restante é utilizado em outro trabalho.

Normalmente, a melhor abordagem para determinar o valor proposto de um projeto, é analisar os documentos de “Valor Proposto do Projeto”, de “Business Case” ou de “Análise de Custo / Benefícios” que foram criados antes do projeto começar. Analisar como os benefícios foram quantificados nestes documentos e se você poderá medir os resultados semelhantes quando o projeto estiver concluído. Se existir benefícios quantitativos identificados, então as métricas deverão mostrar o valor entregue. Se existir benefícios leves (ou qualitativos) identificados, provavelmente você necessitará utilizar métricas anedóticas, pesquisas e evidências indiretas para mostrar o valor fornecido.

Se o projeto for patrocinado pelo cliente, o mesmo deverá ser responsável pela coleta das métricas e um processo deverá ser estabelecido para garantir que as métricas serão coletadas. As métricas específicas são baseadas nas métricas que foram usadas para justificar o projeto no caso de negócio (business case). Tipicamente, os benefícios do projeto não começam enquanto o projeto não for terminado e as entregas implantadas. Em muitos casos, a equipe do projeto é dispensada, e normalmente a coleta de métricas relativa aos benefícios, é transferida para o departamento de suporte.

Coletar Métricas e Demográficos podem Assistir Projetos Futuros

Coletar e reportar um grupo de métricas consistentes no final de um projeto, ajuda a sua organização a ver as tendências para entregar os projetos em um período de tempo. As métricas devem mostrar como anda o comprometimento das equipes dos projetos em termos de qualidade, custo, e prazo. Quando você começar a coletar e reportar as métricas para mais e mais projetos, você poderá estabelecer uma baseline que permita que a sua organização veja como ela está progredindo ou decrescendo ao longo do tempo.

Se você coletar métricas para todos os projetos da sua organização, você também deverá coletar alguns demográficos sobre os projetos. Os demográficos de projetos são apenas características predefinidas de projetos que fornecem um pouco mais de descrição em cada projeto particular. Se os demográficos e as métricas forem armazenados em um arquivo ou em um banco de dados, estas informações poderão ser analisadas para mostrar as tendências de uma maneira mais discreta e granulada.

Se você não coletar os demográficos, você poderá sempre comparar o custo atual com o custo estimado, e então monitorar as tendências ao longo do tempo. Mas, a vantagem de coletar alguns demográficos é que você poderá compará-los com projetos similares. Por exemplo, você poderá comparar o custo e o esforço associado aos projetos de desenvolvimento de um mainframe e com os projetos de desenvolvimento da web. Ou em termos de prazos finais e orçamentos, você poderá comparar os projetos do departamento de vendas com os projetos da área financeira.

Um outro benefício de coletar demográficos de projetos é que você poderá utilizar a informação para fazer estimativas de projetos futuros. Por exemplo, se você tiver um novo projeto de desenvolvimento da web utilizando ASP e SQL*Server, você poderá buscar a informação no banco de dados dos projetos anteriores para ter uma idéia da quantidade de tempo, esforço, e custo que foram utilizados em projetos similares. Isto poderá ajudá-lo na estimativa de seu projeto. Em geral, os demográficos capturados de seus projetos concluídos poderão ser utilizados para fornecer informações adicionais em projetos futuros.

Para maiores detalhes sobre Métricas, veja >> Gerenciando as Métricas

Sem comentários »

Se você é um gerente de projeto, você já passou pela experiência de ser questionado sobre onde você está no projeto? Naturalmente que sim. A pergunta em si é vaga, e da mesma forma a sua resposta também foi vaga, tipo “Nós estamos bem próximo da programação” ou você poderá ter dado uma outra resposta também vaga, tal como “Nós estamos com a metade do trabalho completado” ou “Nós estamos com 90% do trabalho completado”.

Se você não tiver um cronograma válido, ou se você não estiver mantendo o cronograma atualizado, você sabe que a sua resposta será apenas uma adivinhação. Se você tiver um cronograma bom e mantê-lo atualizado, você terá uma boa idéia sobre o trabalho remanescente e qual a data projetada para a conclusão do mesmo. Mas, e o projeto, está 50% completado? ou 90%? Quem sabe!

A Introdução do Valor Agregado

As métricas do valor agregado foram estabelecidas para eliminar o trabalho de adivinhação e para determinar aonde você está em relação a uma linha de base. Na teoria, este conceito é muito elegante e interessante. Usá-lo permite que um gerente de projeto saiba com precisão aonde o projeto está, quanto trabalho ainda falta para ser concluído, qual é o custo esperado e em qual data o projeto deverá ser finalizado. O valor agregado também fornece muitas outras informações interessantes.

No entanto, você está utilizando o método do valor agregado em seu projeto hoje? Provavelmente não. Você não está usando o valor agregado porque a sua organização não o adotou. Utilizar o valor agregado em seus projetos requer um nível enorme de disciplina e a utilização de processos padronizados. É difícil aplicar o valor agregado a um projeto de cada vez, porque ninguém compreenderia o que você estaria fazendo e por quê. Há uma grande possibilidade de você nunca ter visto o valor agregado sendo utilizado fora de uma aula de treinamento.

História

O valor agregado existe por mais de cem anos. O valor agregado foi utilizado primeiramente no século dezoito, quando os gerentes tentaram fazer a linha de produção de uma fábrica funcionar o mais eficiente possível. O percurso para a eficiência requer uma fundação em métricas e o valor agregado era uma maneira para medir coisas com mais precisão.

Na década de sessenta (1960), o departamento de defesa dos E.U.A. começou a exigir o uso do valor agregado em projetos relacionados à defesa. Como sabemos, se o governo contratar as empresas privadas para executar os projetos que tem o valor de centenas de milhões de reais ou de bilhões de reais, eles normalmente exigem relatórios de progresso do projeto que consistem em informações precisas e bem detalhadas e não simplesmente uma declaração vaga, tal como “Nós estamos bem próximo da programação” Os cálculos do valor agregado fornecem um sentido exato de aonde o projeto está de encontro com a linha de base e fornecem um aviso mais cedo se as tendências indicarem que o projeto excederá o orçamento ou ultrapassará o prazo final.

Infelizmente, muitas pessoas acreditam que os padrões estabelecidos pelo departamento de defesa dos E.U.A. são muito rigorosos e pesados, e que muitas das exigências de relatar o valor agregado fornecem somente um valor incremental. Esta história sobre o valor agregado transformou-se de uma ferramenta valiosa de gerenciamento de projetos em um grande peso para os projetos. Esta percepção do valor agregado como um grande peso poderá ser uma das razões a qual o valor agregado nunca decolou nos setores das indústrias privadas.

Os Conceitos Básicos do Valor Agregado

O valor agregado é uma maneira de medir o progresso. Em qualquer projeto, o valor a ser obtido é baseado em concluir o projeto. Na perspectiva do cliente, o valor do negócio é obtido quando o projeto é concluído. Se um projeto que tem 90% de seu trabalho concluído for cancelado, o valor do negócio poderá ser zero. Entretanto, o valor agregado é visto de forma diferente. Com o valor agregado, você está ganhando o valor do projeto em uma escala incremental enquanto o mesmo está sendo executado. Quando 50% do trabalho for completado, você poderia dizer que 50% do valor do projeto também foi realizado. A idéia geral por trás do valor agregado é de comparar aonde você está realmente de encontro com aonde você planejou estar. Vamos refinar um pouco mais esta idéia. Vamos dizer, que você está trabalhando atualmente nas atividades 49, 87, 88, 100 e 108 do seu cronograma e que todas as atividades predecessoras foram concluídas. O valor agregado permite que você quantifique todo o trabalho que foi realizado no projeto até o momento atual. O valor agregado também permite que você quantifique todo o trabalho que deveria ter sido concluído no projeto até o momento atual. Então, você poderá comparar o trabalho que foi feito de encontro com o trabalho que deveria ser feito para determinar se você está dentro da trilha, adiantado ou atrasado em relação ao cronograma.

Do mesmo modo, dado aonde você está hoje, os cálculos do valor agregado permitem que você determine o custo associado ao trabalho que foi feito até o momento atual e também o custo associado a todo o trabalho que você planejou concluir até o momento atual. Comparar estes dois números lhe dará uma idéia se você está tendendo a estourar o orçamento, está abaixo do orçamento ou no orçamento.

Também, utilizar as métricas de programação e dos custos lhe dará mais informações. Você poderá estar gastando o seu orçamento mais rápido do que o previsto, mas e se o motivo for porque você também está adiantado na programação? Ou seja, você poderá ter gasto mais por que a sua equipe poderá ter concluído mais trabalho do que o planejado. Isso poderá estar bom. Do mesmo modo, se o seu projeto estiver atrasado na programação, mas você também estiver abaixo do valor orçado para gastar até o momento, isso também poderá estar bom. Talvez você possa não ter alocado os membros da equipe para completar as atividades tão rapidamente como o planejado. Assim, o seu projeto está atrasado na programação e também nos custos. Se você tiver uma data crítica para concluir o projeto, isto poderá ser um problema. Se a data de conclusão do projeto for um pouco flexível, você poderá estar bem enquanto não gastar mais do que o seu orçamento. O valor agregado lhe dará a informação que você necessita para tomar as decisões certas.

Dependendo do livro que você lê, há dezenas (talvez centenas) de cálculos do valor agregado. Entretanto, a maioria deles envolvem a combinação de algumas métricas básicas do valor agregado em várias permutações.

Há três métricas que dão forma aos blocos de construção para o valor agregado - Valor Agregado, Custo Real e Valor Planejado.

Para maiores detalhes sobre o valor agregado e o gerenciando de um projeto, veja >> Gerenciando o Cronograma e o Orçamento

Sem comentários »