blog.tenstep.com.br

É importante para os gerentes de projetos reconhecer os estágios pelos quais um documento deve passar, desde o início de sua criação até a conclusão do mesmo. Este conhecimento permite que os gerentes de projetos compreendam a situação atual (Status) de um documento em qualquer momento e ajudará a assegurar que será alocado o tempo adequado para completar o documento. Por exemplo, quando um membro da equipe diz que pode concluir um documento em duas semanas, o que ele está dizendo? Ele está dizendo que o documento vai estar pronto para circular para feedback e para a aprovação em duas semanas ou que o documento vai estar concluído e totalmente aprovado em duas semanas? Nem todos os documentos precisam passar por todos os estágios de criação a aprovação. No entanto, dependendo do documento, um ou mais dos passos podem ser necessários.

Alguns dos passos de revisão definidos nesta seção também são considerados partes de um processo de controle de qualidade para os documentos.

1. Preparação
Às vezes você pode simplesmente sentar-se e começar a escrever o seu documento. Outras vezes você necessita preparar-se e planejar. Isto é especialmente uma realidade quando o documento for muito extenso e complexo. Em muitos casos você não pode começar a escrever porque não tem as suas idéias estruturadas. A preparação e o planejamento, que inclui esboçar o índice e estruturar as seções, lhe ajudarão a começar.

2. Criação Inicial do Documento
Neste passo, o documento é criado em formato de rascunho. Se não houver revisões e aprovações posteriores, este passo resultará na criação da entrega final. A maior parte das horas de esforço associadas ao documento são investidas neste passo. Os passos posteriores podem ser demorados, mas não utilizam a mesma quantidade de esforço.

3. Feedback e Modificação (Iterativo)
Esses dois passos envolvem a circulação do documento para revisão inicial e feedback. Com base nos comentários da revisão, o documento é atualizado. Dependendo do documento em particular, este pode ser um passo iterativo. Um documento pode ter uma revisão interna, seguida de uma revisão pelas partes interessadas e uma revisão da gerência. Após cada uma dessas revisões, o documento é modificado com base no feedback e enviado para o próximo passo.

4. Aprovação
Quando o documento tiver circulado para revisão e feedback, e posteriormente atualizado, ele estará pronto para aprovação final. Alguns documentos devem ser formalmente aprovados por escrito. Outros documentos são simplesmente considerados concluídos após o recebimento da rodada final de revisão, feedback, e ser atualizado.

Os documentos finais poderão requerer atualizações posteriores que também poderão requerer seus próprios mini processo de ciclo de vida (feedback / modificação / aprovação).

Rascunho dos Documentos

Rascunho dos documentos, são documentos que foram inicialmente concluídos pelo autor, mas que ainda não estão prontos para serem considerados totalmente completos no ponto-de-vista do projeto. Em muitos casos, é porque o documento está passando por algum tipo de processo de revisão. O rascunho dos documentos pode ser armazenado na área de trabalho do autor. No entanto, em projetos grandes ou naqueles em que é necessário maior rigor no gerenciamento da documentação, é recomendável manter uma biblioteca ou uma pastas para rascunhos. Nesse caso, o processo seria como segue:

Se o rascunho do documento precisar ser atualizado, o documento é copiado para a área de trabalho para a atualização, deixando-se o documento original na biblioteca de rascunhos.

1. Um documento é criado e editado na área de trabalho do autor.

2. Depois que o rascunho inicial estiver pronto, o documento é movido da área de trabalho para a biblioteca de rascunhos. O documento permanece lá até que o autor precise atualizá-lo ou que esteja pronto para ser movido para o repositório de documentos aprovados.

3. Circular uma cópia do rascunho do documento para revisão e feedback.

4. Se o rascunho do documento precisar ser atualizado, o documento é copiado para a área de trabalho para a atualização, deixando-se o documento original na biblioteca de rascunhos.

5. Esse processo é repetido até que o documento esteja totalmente concluído. Então o documento poderá ser movido da biblioteca de rascunho para seu destino final na biblioteca.

O valor dessa abordagem é que a equipe de projeto sempre tem um rascunho de cada documento, e somente uma versão aprovada e em uso.

Para maiores detalhes sobre Gerenciamento de Documentos, veja >> Gerenciando a Comunicação

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 »

Uma das preocupações de muitos gerentes de projetos é que eles são expectados fornecer uma estimativa detalhada do trabalho do projeto quando o documento Termo de abertura do projeto e o cronograma forem criados. Entretanto, nesse ponto, os requisitos detalhados ainda não foram coletados, então como poderão estimar detalhadamente o trabalho do projeto? A pergunta parece ser válida, contudo, quando falamos sobre o recolhimento de requisitos detalhados, normalmente 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 os requisitos detalhados antes de se comprometer 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 coleta dos requisitos poderá durar de seis a oito semanas (ou mais). Então, será que realmente devemos esperar para fornecer as estimativas do projeto somente quando os requisitos forem coletados e aprovados? Em caso afirmativo, o projeto poderá estar um terço concluído antes de validarmos 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 quantia significativa de dinheiro. Esta é a razão por que a maioria das metodologias de gerenciamento de projetos não inclui o processo de coleta dos requisitos detalhados do projeto.

Da mesma forma, 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. Observe que esta mesma lógica poderá ser levada ao extremo.

As três abordagens seguintes, permitirão que você estime o trabalho do projeto antes de coletar os requisitos detalhados do projeto. (Isto supõe que você está coletando os requisitos como parte da primeira fase de execução do projeto. Se você usar técnicas ágeis ou iterativas você poderá coletar os requisitos de maneira iterativa durante todo o projeto.)

Abordagem tradicional: Quando você criar o documento Termo de Abertura do Projeto e o cronograma do projeto, estime o trabalho dentro de uma média de 10% a 15% . Entretanto, há uma suposição subjacente de que o gerente do projeto e/ou a equipe do projeto já realizaram esse tipo de trabalho antes, e baseado nos requisitos 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 os requisitos foram coletados, 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 a coleta dos requisitos do projeto. Você deverá poder estimar este projeto de coletar os requisitos do projeto dentro de uma média de 15%. Depois que este projeto de coletar os requisitos for completado, 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 os requisitos forem coletados: 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 os requisitos forem coletados, o gerente do projeto fornece uma estimativa mais detalhada do trabalho dentro de uma média de 15%. Esta é a estimativa que o gerente do projeto deverá comprometer-se.

Muitos gerentes de projetos pensam que a melhor abordagem é coletar os requisitos de forma iterativa. Entretanto, o ciclo de vida iterativo não fornece resposta nos termos de como estimar 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á coletando somente um subconjunto dos requisitos 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 estimativas, veja >> Construir o Cronograma e o Orçamento

Sem comentários »