blog.tenstep.com.br

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 menor número 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 quantificar 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 produtivo 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.

A melhor abordagem para determinar o valor de um projeto produzido, normalmente é analisar os documentos de “Proposição de Valor do Projeto” ou de “Análise de Custo / Benefícios” que foram criados antes de o 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 captura 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 até que o projeto esteja terminado e as entregas sejam implantadas. Em muitos casos, a equipe do projeto é dispensada, então normalmente a coleta de métricas relativa aos benefícios, é transferida para o departamento de suporte.

Estabelecer uma baseline se o alvo não estiver definido

A coleta de informações de métricas em si, oferece valor limitado para o projeto. Você agrega maior valor quando compara as suas métricas com os alvos e padrões. Para muitas métricas têm-se alguns alvos implícitos, mesmo se você não especificá-los no projeto. Por exemplo, a coleta de informações sobre o esforço, a duração e os custos atuais são utilizados para comparar com o esforço, com a duração e com os custos estimados, para ter uma idéia da situação atual do seu projeto.

Entretanto, para muitas métricas não há um alvo implícito a alcançar. Por exemplo, se você monitorar a satisfação do seu cliente, ele poderá avaliar a sua equipe em uma média de 3,8 sobre uma escala de 5,0. Mas, este é um número bom, ou ruim? Como você não tem outros dados ou informações para comparar, isto fica muito difícil para saber. A maneira de se obter mais valor de uma métrica é utilizar a primeira medida como baseline – em outras palavras, uma reflexão da situação atual de seu projeto. Em uma pesquisa de satisfação do cliente, considere os resultados primários como baseline e depois tente aumentar os números em comparação a baseline. Por exemplo, depois de obter uma nota de baseline de 3,8 em uma escala de 5,0, você poderá decidir estabelecer um alvo de 4,2 em uma escala de 5,0 antes do término do projeto. Outra opção é estabelecer um objetivo para melhorar seus resultados de baseline com um percentual (ex. 10%). Você deve entender que as métricas de baseline poderão não ser fáceis para definir. Em alguns casos você poderá acumular um número de métricas iniciais antes de declarar a sua baseline. Um exemplo, você poderá acompanhar a quantidade de defeitos no sistema por mês durante três meses, e utilizar uma média mensal como sendo sua métrica de baseline.

Compare os custos das coletas de métricas versus seus benefícios

Assim como há custos associados a todas as atividades de Gerenciamento de Projetos, também há custos associados para coletar métricas e gerenciar o processo de coleta das mesmas. No caso do Gerenciamento do Escopo e o gerenciamento das Incidências Problemáticas, estes são processos fundamentais de gerenciamento de projetos e os custos associados aos mesmos necessitam ser investidos pelo Gerente do Projeto para ser bem-sucedido. Entretanto, o gerenciamento das métricas está mais sob o comando do Gerente de Projetos e também da cultura da organização. Em muitos casos, o custo da coleta e a utilização de alguns tipos de métricas podem ser proibitivos. Estes tipos de métricas não devem ser procurados. Outras métricas são interessantes, porém não fornecem o tipo de informação que possa ser utilizado para fazer melhorias. O ponto principal é que o custo de coletar cada métrica deve ser equilibrado com os benefícios potenciais adquiridos. Comece pela coleta de métricas que são requeridas pela organização. Então, adicione as métricas que tem o menor custo e empenho para coletar e que possam fornecer o máximo de benefícios.

Utilize as métricas coletadas

Você não quer coletar métricas apenas por coletar. Isto não faz sentido na perspectiva do gerenciamento de projetos e apenas consumirá o tempo que poderá ser utilizado em outras áreas mais importante do projeto. Se forem requeridas métricas especificas pela sua organização, então as coléte. Coléte também, outras métricas que são necessárias pelo seu projeto particular. Entretanto, se você não tiver nenhum propósito com as métricas coletadas, ou se o projeto for muito curto e não houver tempo suficiente para utilizá-las, então a coleta de métricas não tem valor para o seu projeto.

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

Sem comentários »

Não é óbvio que a maioria dos problemas encontrados em um projeto, tende a aparecer nas fases de construção e de testes? Na realidade, alguns gerentes de projeto apressam propositadamente o planejamento, a análise e o design, porque eles calculam que encontrarão alguns erros na fase de testes.

Infelizmente, quanto mais tarde você descobrir os erros em seu projeto, mais dispendioso será e mais tempo você levará para resolvê-los. Quando você estiver criando o seu Cronograma, invista mais tempo nas áreas de preparação e planejamento, isso salvará tempo e custo no seu projeto. Por exemplo, investir mais tempo na fase de planejamento, economizará o tempo na fase de análise. Investir mais tempo na fase de análise, fará com que o trabalho de design seja executado com menos problemas. Investir mais tempo nas revisões das entregas, resultará em achar os erros mais cedo e economizará tempo na fase de testes. Testar completamente, resulta em salvar tempo na fase de implementação e subseqüentemente no suporte. É claro que você não deseja planejar nem analisar excessivamente. Mas seja diligente neste trabalho. Não se apresse. O tempo investido no início é compensado mais tarde durante o ciclo de vida do projeto.

Criar um cronograma de curto prazo para guiar os processos de definição e de planejamento

O processo de criação dos documentos “Termo de abertura do projeto” e do “Cronograma”, poderá requerer um longo tempo e ser muito complicado. Então, este processo deve ser bem organizado. Após o gerente do projeto ser designado, ele deverá criar imediatamente um cronograma de curto prazo para planejar e gerenciar as atividades iniciais. Este Cronograma inicial, deverá abranger o tempo necessário para criar o documento “Termo de abertura do projeto” e o Cronograma do Projeto. Se este processo requerer duas semanas, o gerente do projeto deverá criar um Cronograma provisório que abranja no mínimo duas ou três semanas. Se o tempo necessário para criar o documento Termo de abertura do projeto e o Cronograma final for quatro semanas, este Cronograma inicial deverá abranger no mínimo quatro semanas, mas poderá fazer sentido criar um plano que abranja cinco ou seis semanas. Este Cronograma provisório, deverá abranger tudo nas atividades iniciais em termos de organização e planejamento do projeto, até que o Cronograma formal do projeto esteja completo para guiar o restante do projeto.

Determine se as horas atuais de esforço serão capturadas

Capturar as horas atuais de esforço do projeto e documentá-las no Cronograma, esta é uma decisão que deve ser tomada cedo no projeto. Por exemplo, você estimou uma atividade para 40 horas de esforço e dez dias de duração. Quando a atividade estiver concluída, você poderá facilmente comparar a duração estimada com a duração atual. Mas, você irá monitorar as horas de esforço para saber se realmente a atividade utilizará 40 horas? Capturar as horas atuais do esforço requer muito mais diligência da parte da equipe do projeto para documentar exatamente o tempo utilizado para cada atividade e relatar. Há muito valor associado à capturação das horas atuais do esforço, incluindo a ajuda para fazer as estimativas futuras com mais precisão. Entretanto, muitas organizações não capturam as horas atuais de esforço. Se a sua organização não capturar as horas atuais de esforço, será difícil para o gerente do projeto reforçar esta disciplina. Coletar as horas atuais de esforço, geralmente é algo requerido (ou não) pela empresa.

Tenha cautela em relação à folga em demasiado no cronograma

Como descrito antes, normalmente há somente um caminho no Cronograma que não tem folga. Este é o caminho crítico e o mesmo controlará a data final. Embora todos os outros caminhos no Cronograma tenham alguma folga, poderá haver alguma preocupação se houver folga em demasiado. O termo “Folga em demasiado” significa que os outros caminhos têm muitos intervalos onde nenhum trabalho necessita ser feito. Isso poderá conduzir a um diagrama de rede longo e magro. Claro, poderá não haver problema com esta ocorrência. Entretanto, as implicações potenciais em relação as folgas em demasiado no Cronograma, são como seguem:

- Muitos recursos humanos vão e voltam (rotativo) ao projeto. Isso poderá causar problemas para assegurar que todos os recursos humanos estarão disponíveis quando necessários e pelo tempo que for necessário. Particularmente, você deverá assegurar-se de que os recursos humanos que serão utilizados no caminho crítico e também utilizados em outros caminhos, tenham trabalho atribuído também nos períodos das folgas.

- Poderá haver falta de senso de urgência pela parte de todos os recursos humanos que não estão trabalhando no caminho crítico. Ou seja, você tem um ou mais recursos humanos trabalhando muito nas atividades do caminho crítico para alcançar os prazos finais, enquanto que todos os outros recursos têm muitas folgas em seus cronogramas. Isto poderá desmotivar muito os recursos humanos que trabalham no caminho crítico.

Tenha cautela em relação a falta de folga no cronograma

Mesmo que haja riscos associados a folga em demasiado, também haverá algum risco associado à falta de folga. Nesse caso, alguns pequenos resvalamentos nos caminhos que estão fora do caminho crítico, poderão transformá-los em caminhos críticos. Então, seria melhor se o Cronograma do projeto, pudesse ser programado de tal maneira que os caminhos que não são críticos, fossem com a menor folga possível “mas não com folga zero” e de modo que os recursos humanos associados aos caminhos, pudessem ser utilizados continuamente no projeto.

Para maiores detalhes sobre o planejamento do cronograma, veja >> Construir o Cronograma e o Orçamento

1 comentário »

Resolva as incidências problemáticas o mais cedo possível

Uma incidência problemática é um problema que será prejudicial ao sucesso do projeto e não poderá ser resolvido pela equipe do projeto. Essa definição leva ao entendimento de que tais Incidências Problemáticas devem ser atendidas com urgência. Se um problema estiver mesmo sendo classificado como uma incidência problemática, o gerente do projeto deverá assumir a responsabilidade de resolvê-lo. O gerente do projeto, necessitará ter uma atividade que ocorra semanalmente no Cronograma para dar seguimento as Incidências Problemáticas em aberto e assegurar de que as mesmas  serão resolvidas de forma diligente.

Pelo mesmo raciocínio, se não há urgência em resolver a incidência problemática ou se ela já está ativa por algum tempo, você deverá fazer uma nova investigação para ver se realmente trata-se de uma incidência problemática. Poderá ser um problema potencial (risco) ou um item de ação que necessitará ser resolvido mais tarde no projeto. As incidências problemáticas, por natureza, devem ser resolvidas com um senso de urgência.

Entender a diferença entre incidências problemáticas versus itens de ação

Em muitos casos, os gerentes de projetos não utilizam um Registro de incidências problemáticas para identificar e acompanhar somente as incidências problemáticas. Muitos itens que são classificados como incidências problemáticas, na verdade são riscos (problemas potenciais) ou apenas itens de ação. Itens de ação são atividades que deverão ser atendidas em algum momento. Eles podem ou não envolver problemas para o projeto. Se você descobrir que o seu Registro de Incidências Problemáticas tem dúzias de itens, provavelmente você está incluindo e mantendo itens de ação como incidências problemáticas. Como incidências problemáticas são problemas grandes, em nenhum momento deverá haver muitos itens em aberto.

Tente resolver a causa da raiz e não apenas os sintomas

Quando surgirem os problemas, resolva-os o mais rápido possível. No entanto, certifique-se de que a causa da raiz da incidência problemática seja resolvida e não somente os sintomas. Resolver a causa da raiz, assegurará que o problema seja definitivamente eliminado no projeto. Normalmente a causa da raiz pode ser encontrada através de uma série de perguntas “por quê”. Por que surgiu a incidência problemática? Quando a pergunta for respondida, pergunte “por que” novamente, pergunte “por que” a você mesmo várias vezes sucessivamente. Quando você não conseguir mais responder “por que”, provavelmente você estará próximo da causa da raiz da incidência problemática.

Identificar as soluções juntamente com as incidências problemáticas

As Incidências problemáticas podem ser levantadas pelos membros da equipe, pelos clientes ou por quaisquer partes interessadas do projeto. É uma boa prática encorajar as pessoas a ajudar na identificação das soluções juntamente com as incidências problemáticas. Assim, quando um membro da equipe identificar uma incidência problemática em potencial, peça a ele que traga também uma ou mais soluções possíveis. Esse processo ajudará a estabelecer responsabilidade entre os membros da equipe, mas também ajudará a determinar possíveis cursos de ação. Na verdade, se uma ou mais soluções for viável, o problema poderá ser resolvido com a ajuda do gerente do projeto e nunca chegar ao nível de uma incidência problemática.

Às vezes você necessita tomar decisões em meio de alternativas ruins

Depois das revisões dos processos e das técnicas para gerenciar as incidências problemáticas, você poderá pensar, que deverá resolver todas as incidências problemáticas com sucesso. Mas o fato é que você poderá encontrar algumas incidências problemáticas que não tenham soluções boas e claras. Com isso em alguns casos, poderá ser difícil de determinar uma boa opção para a resolução. Em alguns casos, surgem incidências problemáticas que são difíceis para serem resolvidas não por falta de opções, mas pela dificuldade na obtenção de aprovação e a decisão entre uma série de alternativas. Em outros casos, não há alternativas boas, e a decisão final poderá ser a que se mostrar menos prejudicial ao projeto.

Um exemplo deste dilema é uma incidência problemática que envolve política interna. Normalmente quando um problema começa a se misturar com as políticas internas, você descobrirá que a resolução é muito difícil, porque os processos de tomada de decisões são muito complicados e não são simples como examinar os fatos. Quando um problema torna-se político, uma resolução poderá ser aprovada, mas não será a resolução ideal para a equipe do projeto. Entretanto, uma decisão para a resolução é muito importante.

Nessas situações, tente fazer os aprovadores entender que normalmente uma demora na decisão não torna o resultado mais aceitável. O gerente do projeto deverá esforçar-se para obter uma resolução o mais rápido possível, para que o projeto possa seguir em frente. Se uma Incidência problemática torna-se política, o gerente do projeto normalmente necessita do apoio do patrocinador e das partes interessadas para ajudar na resolução.

Para maiores detalhes sobre o gerenciamento de problemas, veja >> Gerenciando as Incidências Problemáticas

Sem comentários »