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 »

Em um projeto grande, poderá haver muitas pessoas que tem algum papel no processo de criação e de aprovação das entregas do projeto. As vezes esse processo é direto e simples, por exemplo, uma pessoa cria um documento e uma outra pessoa aprova. Em outros casos, poderá haver muitas pessoas envolvidas na criação de uma entrega, e varias outras que necessitam aprová-la.

Para os cenários complicados que envolvem muitas pessoas, é altamente conveniente ter uma Matriz de Responsabilidades para as Entregas. Isso ajuda a estabelecer as expectativas, e assegurar que as pessoas saibam de suas responsabilidades. Por exemplo, você necessita saber se os membros do Comitê de Direção deverão aprovar o documento dos requerimentos de negócio ou não. A Matriz de Responsabilidade esclarecerá todos os papéis e responsabilidades.

Na matriz, as pessoas ou (papéis) diferentes, são representadas nas colunas da primeira linha, e as entregas são representadas em filas na primeira coluna. Então, utiliza-se os pontos de interseção para descrever a responsabilidade de cada pessoa (ou papel) para cada entrega.

Veja abaixo uma matriz simples e as categorias de responsabilidade sugeridas.

  
“A” - Significa a pessoa (ou função) que aprovará a entrega.
“R” - Significa a pessoa (ou função) que fará a revisão da entrega.
“C” - Significa a pessoa (ou função) que criará a entrega. Normalmente há somente uma pessoa responsável pela criação da entrega, embora muitas pessoas podem fornecer informações (input).

Na tabela acima, o documento de Termo de abertura do projeto é criado pelo Gerente do Projeto, e aprovado pelo Patrocinador, pelo Diretor do Projeto e pelo Comitê de Direção. A Equipe do Projeto tem a responsabilidade de revisar o documento.

Os documentos que descrevem os requerimentos do negócio são criado pela Equipe do projeto, revisados pelo Gerente do Projeto e pelo Diretor do Projeto, e aprovados pelo Patrocinador e pelo Comitê de Direção.

O propósito da Matriz de Responsabilidade é proporcionar claridade e obter um acordo sobre quem faz o que, assim pode-se definir as colunas com a quantidade de detalhes que faz sentido. Por exemplo, no exemplo anterior, a Equipe do Projeto pode ser substituída por pessoas especificas, responsáveis pela criação dos documentos que descrevem os requerimentos de negócios. Após concluída a Matriz, a mesma deverá ser circulada para aprovação. Se a matriz for criada dentro do processo de planificação, a mesma poderá ser incluída no Termo de abertura do projeto como anexo. Se a matriz for criada como um documento separado, a mesma também deverá ser circulada para aprovação.

Para que a Matriz de Responsabilidade seja eficaz, é vital que a mesma seja bem clara. A matriz deverá refletir as expectativas e as responsabilidades das pessoas envolvidas. Por exemplo, se o Patrocinador delegar a responsabilidade de aprovação do documento “Requerimentos do Negócio” a um subordinado, esse fato deverá ser representado na matriz para que todos saibam. Por outro lado, se o patrocinador decidir que ele aprovará o documento “Requerimentos do Negócio”, então, de fato, somente ele deverá aprová-lo.

A - Aprovação das entregas

R - Revisão das  entregas e fornecer feedback

C - Criador, ou seja o responsável por criar a entrega. Normalmente há somente uma pessoa responsável pela criação da entrega, entretanto poderá haver mais pessoas envolvidas. Neste caso as pessoas poderão ser representadas da seguinte maneira:

- C1 Responsável primário
- C2 Responsável suplente
- C3….

I - Fornecer Informações

N - Notificar quando uma entrega for concluída

M - Gerenciar as entregas. Por exemplo: um bibliotecário, (ou a pessoa responsável pelo repositório de documentos)

Para maiores detalhes sobre o planejamento do projeto, veja >> Definir Tarefas

Sem comentários »