blog.tenstep.com.br

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

Sem comentários »

O processo de criação de uma estrutura analítica do projeto (EAP), requer um processo repetitivo de fracionar partes maiores do trabalho em uma série de partes cada vez menores.

Uma pergunta apropriada é, até que tamanho as atividades devem ser fracionadas. A resposta a essa pergunta é o limiar para o fracionamento do trabalho e não fará sentido fracioná-lo ainda mais. Não há nenhuma regra rígida e fixa para o limiar, mas há algumas diretrizes gerais e então algumas advertências que poderão ser aplicadas.

Geralmente para projetos grandes, qualquer parte do trabalho que for superior a 80 horas de empenho deverá ser fracionada em partes menores. Em outras palavras, não deverá haver nenhuma atividade no cronograma com a duração superior a 80 horas. Contudo, para os projetos de tamanho médio ou pequeno, o limiar poderá ser menor e provavelmente será menor. Se o seu projeto for de tamanho médio, as atividades não deverão ser maiores que 40 horas. Se o projeto for pequeno, fracione as atividades em trabalhos menores que 20 horas. Lembre-se de que o limiar que você estabeleceu é o limite máximo e você poderá fracionar as atividades menores de acordo com as suas necessidades.

Há duas advertências para você ter em mente.

1. É possível que as atividades que serão trabalhadas em um futuro distante, não possam ser fracionadas o suficiente para atender o limiar, porque poderá haver muitas coisas desconhecidas sobre elas. Se esta incerteza envolver somente algumas atividades, então você poderá deixar o trabalho em um nível superior. Contudo, se for difícil para definir e estimar a maior parte do trabalho futuro, a melhor abordagem será fracioná-lo em um projeto separado, fora do escopo que já está atualmente sendo planejado. Por exemplo, poderá ser difícil planejar e estimar o trabalho das fases de construção e de testes de um projeto sem primeiramente definir as exigências do negócio. Nesse caso, a melhor abordagem é definir um projeto inicial para reunir as exigências do negócio, como um segundo projeto de acompanhamento para projetar, construir e testar a solução. Com base nos resultados do primeiro projeto, o segundo projeto poderá ser esboçado e estimado com maior precisão.

Dito isso, se você não tiver a opção de múltiplos projetos, este trabalho futuro poderá ser deixado em um nível mais alto do que o limiar. O risco é que, quando este trabalho se aproximar, as estimativas terão uma margem de erro maior e você terá que lidar com as conseqüências de exceder o prazo final e o orçamento do seu projeto. A reserva de contingência para as estimativas pode ser aumentada para gerenciar as incertezas do trabalho futuro.

2. Uma das razões para fracionar atividades em partes menores é para saber claramente o que deve ser feito. Se uma atividade for bastante óbvia para a pessoa que for designada, então essa atividade não necessitará ser fracionada além do limiar. Por outro lado, se o trabalho não for bem conhecido pela pessoa designada, então o trabalho poderá ser fracionado além do limiar para fornecer maior clareza a essa pessoa. Por exemplo, se uma atividade que foi calculada para ser concluída em 70 horas nunca foi executada antes, a mesma poderá necessitar ser fracionada em uma série de atividades menores para garantir que as pessoas designadas saibam exatamente o que deve ser feito.

Estes dois fatores - a habilidade para gerenciar eficazmente o trabalho e a habilidade para entender o trabalho requerido - devem dirigir sua decisão sobre o quão pequeno as atividades deve ser.

Limiar de Duração

Um outro limiar que deve ser considerado é o limiar de duração. Em geral, a duração das atividades deveria ser fracionada em um nível não superior a dois ciclos de reportagem do trabalho da equipe do projeto. Por exemplo, se você receber uma atualização de andamento formal (Status) da sua equipe a cada duas semanas, então o limiar de duração não deverá ser maior do que quatro semanas. Ou se você tiver semanalmente uma reunião de avaliação de andamento (Status) do projeto, as atividades não deverão ter mais do que duas semanas. Esta regra assegurará que não haverá mais do que dois períodos de avaliação de andamento (Status) do projeto antes de uma atividade ser indicada como completada ou sinalizada como atrasada. Por exemplo, se você se reunir com a sua equipe semanalmente e a duração da atividade for menor ou igual a duas semanas de empenho, então nenhuma atividade ficará ativa mais do que duas reuniões antes de ser indicada como completada ou atrasada. Por outro lado, se você tiver uma atividade com a duração de cinco semanas, é possível que haja até seis reuniões de avaliação de andamento (Status) do projeto antes que você tenha certeza de que a atividade será completada ou não de acordo com o cronograma. Este é um exemplo de onde a atividade precisa ser fracionada no mínimo um nível a menos. Atividades menores permitem o descobrimento de problemas muito mais cedo.

Obs. O limiar de duração será utilizado quando o cronograma for finalizado e não quando for criada a EAP. Quando a EAP for criada, você saberá somente as estimativas das horas de esforço. Depois que os recursos humanos forem aplicados no diagrama de rede, você poderá validar se a regra do limiar de duração é satisfatória e fazer algumas alterações se necessário.

Para maiores detalhes sobre a construção de um cronograma, veja >> Construir o Plano de Trabalho (Workplan) e o Orçamento.

Sem comentários »

Entender o nível de tolerância da sua organização em relação aos riscos

Todos os projetos possuem riscos, e todos os riscos têm potencial para impactar o projeto. O processo de gerenciamento dos riscos é utilizado para determinar quais são os riscos mais importantes a serem gerenciados. Durante o processo de identificação dos riscos, você poderá encontrar muitos riscos com algumas chances de acontecer ao longo do projeto e que terão um impacto marginal para o projeto. A questão que se deve perguntar é, o risco identificado terá um impacto significativo no projeto que deve ser levado em consideração? (A mesma pergunta ocorre para as abordagens qualitativas ou quantitativas). A resposta a esta pergunta indica a sua tolerância aos riscos.

Por exemplo, vamos dizer que você identificou um risco que tem grande chance de ocorrer, mas o impacto será de R$ 300,00 e a duração de quatro horas. Você poderá decidir não gerenciar esse risco, porque o impacto no projeto é muito pequeno e o projeto poderá absorver o custo se o mesmo ocorrer. Às vezes o custo do gerenciamento de um risco pode ser maior que o impacto no projeto se o mesmo ocorrer. Observe neste caso, você não poderá listar este risco como uma Premissa devido a grande chance de o mesmo ocorrer.

Os números utilizados no exemplo acima são triviais e fáceis de ignorá-los. Mas, vamos dizer que o impacto do risco é de cinco mil reais (R$ 5000,00) e três dias de duração ou de cem mil reais (R$ 100.000,00) e três meses de duração. Este risco deverá ser gerenciado? Claro, que as respostas para estes valores varia de acordo com o tamanho de cada projeto. Se o seu projeto tivesse um orçamento de sessenta mil reais (R$ 60.000,00) e sessenta dias de duração, um impacto de cinco mil reais (R$ 5.000,00) e três dias de atraso poderá representar um bom motivo para gerenciar esse risco. Se o orçamento do seu projeto fosse de três milhões de reais (R$ 3.000.000,00) e um ano de duração, o impacto de cinco mil reais (R$ 5.000,00) e três dias de atraso seria um risco marginal.

Quando você for identificar os riscos, determine um nível de tolerância para cada risco. Isto lhe ajudará a focar nos riscos mais importantes e que estão acima do nível de tolerância, e ignorar os riscos que estão abaixo do nível de tolerância. A cultura da sua empresa poderá refletir o nível de tolerância dos riscos. Algumas empresas não têm problema para aceitar um nível mais elevado dos riscos em seus projetos (Risk-takers). Também, elas tendem a estabelecer um valor (R$) mais alto antes de decidirem gerenciar um risco.

Por outro lado, algumas empresas são o adverso sobre os riscos (Risk-adverse). Tendem a aceitar projetos que têm menos riscos e também, tendem a estabelecer um valor (R$) mais baixo para gerenciar os riscos. Ou seja, digamos que há um projeto similar em ambas empresas. Os gerentes de projetos destas empresas adversa aos riscos, tendem a gerenciar os riscos que um gerente de projetos da outra empresa poderá decidir não gerenciar.

Certificar-se de que o esforço e o custo associado ao gerenciamento de cada risco não excederá o impacto no projeto

Todos os projetos têm algum risco envolvido, e as atividades associadas ao gerenciamento dos riscos obviamente têm um custo. O gerente do projeto e o cliente devem certificar-se de que o esforço e o custo associado ao gerenciamento de cada risco não excederá o impacto no projeto (em termos de custo e prejuízos) se acaso o risco ocorrer. Normalmente isso não é aplicável para os riscos de nível elevado, entretanto, se você estiver gerenciando riscos médios e pequenos, certifique-se de que os custos e os benefícios associados as respostas aos riscos, fazem sentido para o projeto. Se o custo associado ao gerenciamento de um risco for maior que o impacto no projeto, não faz sentido gerenciar o risco desta maneira. É possível que se o custo associado ao gerenciamento do risco for maior do que o impacto no projeto, você poderá decidir não gerenciar o risco e incluir o mesmo como parte da análise e do planejamento da reserva para contingência.

Tentar incluir no orçamento do projeto uma reserva de contingência para os ricos desconhecidos

Baseado em uma análise qualitativa dos riscos no início do projeto, o gerente do projeto pode solicitar um orçamento de reserva para contingência dos riscos. Entretanto, a identificação dos riscos não é algo que acontece somente no início de um projeto. O gerente do projeto necessita avaliar os riscos durante todo o projeto. Conseqüentemente, como uma parte do seu processo de estimação, poderá fazer sentido incluir nos projetos médios e grandes, algum tempo e um orçamento para os riscos desconhecidos. Isso fará sentido especialmente para os projetos que têm um número significativo de riscos de nível elevado. Se você fizer um trabalho eficaz para reavaliar periodicamente os riscos, você poderá encontrar novos riscos a serem gerenciados que não foram incluídos na Reserva de contingência original. Há alguma comprovação na indústria, de que uma reserva para contingência de 5% pode ser adicionada ao projeto para tratar dos riscos que são desconhecidos no início do projeto. (Lembre-se, que o tempo e o custo associado para mitigar e gerenciar os riscos identificados, devem ser incluídos na estimativa original.)

Para maiores detalhes sobre o gerenciamento dos riscos, veja >> Gerenciando os Riscos.

Sem comentários »