Planejamento
Publicações arquivadas desta categoria
Tudo que você precisa para gerenciar projetos
Publicações arquivadas desta categoria
Publicado por John Grass, PMP em 15 Nov 2008 | sob: Planejamento, Gerenciando o Projeto
Às vezes o gerente do projeto pode ficar muito tranqüilo (ou intranqüilo) sobre o andamento do projeto. Em muitos casos, é recomendável buscar alguém de fora para avaliar os processos de gerenciamento de projeto que estão sendo utilizados e certificar-se de que o projeto está evoluindo como o esperado. Este “partido terceirizado” poderá ser qualquer pessoa qualificada, exceto o gerente do projeto. Em alguns casos, a empresa poderá ter um especialista interno em auditoria de projetos. Também, é possível que o patrocinador, o gerente do gerente do projeto ou um consultor externo possa realizar esta auditoria.
O gerente do projeto ou o gerente funcional poderá convocar uma auditoria do projeto como parte de um programa geral de gerenciamento da qualidade. Em alguns casos, como em projetos governamentais, as auditorias periódicas podem ser exigidas como parte do contrato geral. De qualquer forma, uma auditoria externa deve tranqüilizar as partes interessadas do projeto pelo fato de que estão sendo utilizados processos efetivos de gerenciamento do projeto e que o projeto aparentemente está na trilha.
A auditoria de projeto focaliza na garantia da qualidade - indagações sobre os processos utilizados para criar as entregas.
Gerenciar o projeto dentro dos níveis de tolerância estabelecidos
Quando você gerencia um Cronograma, você não necessita ser 100% preciso em relação a cada minuto ou Real (R$). Também você não quer fazer um drama se o seu projeto estiver com um dia de atraso por uma semana e um dia adiantado na semana seguinte. Seu cliente não espera esse nível de precisão, nem está interessado em boletins de hora em hora sobre o andamento do projeto.
Como gerente do projeto, você deve ter bom senso para avaliar o nível de tolerância do seu projeto. Por exemplo, digamos que você esteja atualizando o seu Cronograma e percebe que ultrapassou o orçamento em um mil reais (R$ 1.000,00). O que você deve fazer? Você deve ou não encaminhar uma incidência problemática ou um risco sobre esse estouro no seu orçamento? Você acha que deve informar o cliente? Bem, isso irá depender do seu nível de tolerância. Se você tiver um orçamento de dez mil reais (R$ 10.000,00), provavelmente você deverá se preocupar, pois há um risco de exceder o orçamento em 10%. Mas, se o seu projeto tiver um orçamento de um milhão de reais (R$ 1.000.000,00), então um mil reais (R$ 1.000,00) não será problema para se preocupar. (Na verdade, você seria um herói se conseguisse concluir o projeto com uma margem de erro de um mil reais [R$ 1.000,00]).
Use o bom senso e trabalhe com o seu cliente para estabelecer os níveis de tolerância para o orçamento e o prazo final. Se você conseguir se manter dentro das tolerâncias, então tudo bem, mas se você ultrapassar esses limites, com certeza você deverá se preocupar.
Considere a utilização da técnica valor agregado para compreender a situação atual do cronograma e do orçamento
Os projetos, especialmente os grandes, nunca são executados exatamente como o planejado. Algumas atividades terminam mais cedo. Outras mais tarde. Às vezes não é fácil para você saber se está adiantado ou atrasado em relação ao cronograma. Às vezes é difícil para você saber se está abaixo do orçamento ou não. Vejamos um exemplo simples. Você tem um projeto de seis meses de duração e já trabalhou três. Seu Cronograma lhe diz que você deveria ter gastado 50% do orçamento, mas você percebeu que já gastou 65%. O que você acha? Você está ou não com problemas?
Sim, pode estar, mas não necessariamente. Se você completou somente a metade do trabalho, você poderá estar com problemas. Mas e se o seu projeto estiver adiantado no cronograma? Se você estiver adiantado no cronograma, poderá fazer sentido que você tenha gastos acima do orçamento planejado neste ponto do projeto.
Esse é o objetivo de calcular o valor agregado. Valor agregado é um método para determinar o progresso do trabalho, considerando onde você está em comparação com onde você esperava estar até o momento.
Para maiores detalhes sobre o gerenciamento de projeto, veja >> Gerenciando o Plano de Trabalho (Workplan) e o Orçamento
Publicado por John Grass, PMP em 04 Nov 2008 | sob: Planejamento, Estimativas
Uma das preocupações de muitos gerentes de projetos é que eles são esperados fornecer uma estimativa detalhada do trabalho do projeto quando o documento Termo de abertura do projeto e o cronograma forem criados. Entretanto, as exigências detalhadas não foram recolhidas ainda, então como eles poderão estimar detalhadamente o trabalho do projeto? A pergunta parece ser válida, contudo, quando nós falamos sobre o recolhimento de exigências detalhadas, normalmente nós estamos falando sobre a fase de análise, que faz parte do ciclo de vida do projeto, e não do trabalho preliminar de definição e de planejamento do projeto.
Seu primeiro pensamento poderá ser que talvez você deva ter as exigências detalhadas antes que você se comprometa com uma estimativa para o trabalho. Mas será que isso realmente é prático? Vamos dizer que há um projeto típico de desenvolvimento de software. O projeto poderá durar seis meses e o processo de recolhimento das exigências poderá durar de seis a oito semanas (ou mais). Então, será que nós realmente devemos esperar para fornecer as estimativas do projeto somente quando as exigências forem recolhidas e aprovadas? Em caso afirmativo, o projeto poderá estar um terço concluído antes que nós validemos o custo total e a data final do projeto. Caso o projeto não faça mais sentido na perspectiva de análise do benefício/custo, esta descoberta será muito tarde e você poderá já ter consumido uma quantidade significativa de dinheiro. Esta é a razão por que a maioria das metodologias de gerenciamento de projetos não inclui o processo de recolhimento das exigências detalhadas do projeto.
Igualmente se você usar este mesmo argumento, você poderá dizer que ainda não está confiável para estimar o trabalho do projeto sem primeiramente concluir a fase de design, e então você não estará confiável para estimar o trabalho do projeto até que você tenha a fase de construção concluída, etc. Você vê que esta mesma lógica poderá ser tomada ao extremo.
As seguintes três abordagens permitirão que você estime o trabalho do projeto antes de recolher as exigências detalhadas do projeto. (Isto supõe que você está recolhendo as exigências como parte da primeira fase da execução do projeto. Se você usar técnicas ágeis ou iterativas você poderá recolher as exigências de maneira iterativa durante todo o projeto.)
Abordagem tradicional: Estime o trabalho dentro de uma média de 10%-15% quando você criar o documento Termo de Abertura do Projeto e o cronograma do projeto. Entretanto, há uma suposição subjacente que o gerente do projeto e/ou a equipe do projeto já realizaram esse tipo do trabalho antes, e baseado nas exigências em um nível elevado poderão estimar o trabalho dentro de uma média de 15%. Se você descobrir que estimou incorretamente depois que as exigências foram recolhidas, você deverá levar a situação ao patrocinador para resolução.
Fracionar o trabalho em partes menores. Se você não se sentir confortável para fornecer uma estimativa do projeto dentro de uma média de 15%, você poderá fracionar o projeto em múltiplos projetos menores. Quando você utiliza esta técnica, normalmente você cria somente o documento Termo de Abertura do Projeto e o cronograma para fazer o recolhimento das exigências do projeto. Você deverá poder estimar este projeto de coletar as exigências do projeto dentro de uma média de 15%. Depois que este projeto de coletar as exigências estiver completo, você poderá utilizar a informação para criar um segundo projeto para executar o restante do trabalho, que deverá ser estimado dentro de uma média de 15%. No final das contas, as entregas finais terão sido criadas através de dois projetos, cada um foi estimado e gerenciado dentro de uma média de 15% do orçamento (Fundos e prazos).
Estimar o trabalho em um nível elevado baseado no documento Termo de Abertura do Projeto e o cronograma, e então ajustar a estimativa depois que as exigências forem recolhidas. Esta é uma variação da primeira técnica acima. Nesta abordagem, o gerente do projeto e a equipe fornecem uma estimativa (melhor adivinhação) do trabalho baseada no documento Termo de Abertura do Projeto e o cronograma do projeto que já foram criados. Esta estimativa poderá ser dentro de uma média de mais ou menos 25%. Entretanto, baseado nas normas da organização, esta não é a estimativa que o gerente do projeto deverá se comprometer para entregar o projeto. Esta estimativa é apenas a melhor adivinhação baseada na informação disponível no momento. Depois que as exigências forem coletadas, o gerente do projeto fornece uma estimativa mais detalhada do trabalho dentro de uma media de 15%. Esta é a estimativa que o gerente do projeto deverá se comprometer.
Muitos gerentes de projetos acham que a melhor abordagem é recolher as exigências de forma iterativa. Entretanto, o ciclo de vida iterativo não dá a resposta nos termos de como você estima o projeto dentro de uma média de 15%. De fato, as abordagens iterativas poderão fazer este nível de exatidão mais difícil, porque você está recolhendo somente um subconjunto das exigências em cada iteração.
As três soluções acima fornecem um grupo das técnicas mais viáveis para estimar o trabalho dentro de uma média de 15%.
Para maiores detalhes sobre as estimativas, veja >> Construir o Plano de Trabalho (Workplan) e o Orçamento
Publicado por John Grass, PMP em 28 Out 2008 | sob: Planejamento, Gerenciando o Projeto, Documentação, Metricas
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