sábado, 5 de agosto de 2017

Percentual de Conclusão Previsto no Project

Olá pessoal,

Um dos principais questionamentos que os usuários do Microsoft Project possuem é geralmente traduzido com a seguinte pergunta: “como posso fazer para criar uma fórmula que calcule o percentual previsto (ou o percentual planejado) no Microsoft Project?

Apesar de este ser o tema central desse post, nossa energia e foco não estarão concentrados em criar uma fórmula que efetue o tão desejado cálculo – mas sim em provocar a reflexão e iniciar uma discussão com os usuários que utilizam o Microsoft Project, de modo que possamos explorar as opções disponíveis.

Para iniciar a reflexão sobre este tema, vale a pena fazer uma pergunta: por que uma ferramenta tão difundida e mundialmente utilizada como o Microsoft Project não possui um mecanismo de cálculo do percentual previsto? Seria motivo de frustração muito grande (para dizer o mínimo) saber que a Microsoft, com uma equipe de engenheiros tão qualificada, deixou de lado um requisito tão “básico” como esse...

Seguindo essa linha de raciocínio, acredito que é muito pertinente pegar emprestado um comentário do meu amigo Alexandre Paiva, um dos mais qualificados profissionais de gerenciamento de projetos que conheço. O Alexandre mantém, na minha opinião, o melhor blog sobre o Microsoft Project do Brasil (Alexandre, continuamos todos esperando o Blog do Gerente de Projetos sair da manutenção e voltar ao ar....). Veja o que ele disse sobre o percentual previsto:

“A grande dúvida quando surge este papo de previsto versus realizado é entender do que estamos falando. Há muita confusão entre as pessoas que lidam com o MS Project. A primeira pergunta a ser colocada quando estamos falando de medir desempenho previsto e realizado é: “que estratégia de atualização e medição estamos utilizando?” Aqui, cabe lembrar que existem basicamente 3 – duração, trabalho e físico.

É preciso entender também que para adotar estas estratégias, é preciso identificar que variáveis são ou serão coletadas durante as medições do projeto (ex: se eu perguntar por horas trabalhadas, estamos falando da estratégia de atualização por trabalho/esforço).

Outro ponto importante para a estratégia (física): é FUNDAMENTAL entender como estimar os recursos corretamente em seus projetos. É preciso entender o que cada recurso representa, como o custo incide, qual é a melhor abordagem de custo para o recurso (custo/uso, custo/unidade, custo por tempo, etc.), custo fixo, custo variável, etc.

O que eu quero mostrar é que o campo em si e a ferramenta são só um detalhe. É preciso entender gerenciamento de projetos e os conceitos e boas práticas. Resumindo, e aqui fica a minha sugestão para a turma do MS Project e comunidade: entenda o real significado dos campos. Entenda como o MS Project pode apoiar melhor a gestão dos seus projetos. Coloque sempre as boas práticas em Gerenciamento de Projetos na frente da ferramenta e lembre-se de que ela – a ferramenta – é tão somente meio e não fim”

Eu não poderia concordar mais com o que o Alexandre disse. Aliás, eu jamais conseguiria expressar isso de uma maneira tão simples, direta e persuasiva. Porém, a questão ainda fica no ar... um leitor pode comentar: “Ok, tudo bem, o discurso é bonito e tudo mais, só que eu preciso entregar para o meu patrocinador (seja ele o meu chefe, seja ele o meu cliente...) quanto deveríamos ter avançado na evolução do projeto até hoje”.

E aí eu acredito que não há nada como os exemplos práticos para demonstrar que o percentual previsto é um conceito que irá depender de inúmeras variáveis e que pode nos levar a tirar conclusões precipitadas (para não dizer errôneas) sobre os nossos projetos. Foi então que eu decidi fazer uma experiência. A ideia é simples: por que não pesquisar o termo “percentual previsto MS Project” e utilizar as fórmulas sugeridas em um cronograma, testando algumas variáveis e simulando alguns cenários? Dessa maneira, seria possível descobrir se alguma fórmula customizada apresenta resultados consistentes, de modo que possamos utilizá-la no nosso dia-a-dia.

Aqui cabe um comentário adicional: é sempre bom enfatizar que o objetivo desse post não é o de contestar ou apontar eventuais falhas em fórmulas disponibilizadas por outros membros da comunidade que dedicam um pouco do seu tempo para compartilhar seu conhecimento. Muito pelo contrário, queremos aqui explorar este tema tão relevante e testar as alternativas disponíveis.

Cenário dos testes

Para que seja possível testar o funcionamento do Percentual Previsto, vou utilizar algumas tarefas simples (e não um cronograma inteiro, justamente para simplificar ao máximo os cenários de testes). As principais características dessas tarefas são:

- Todas as tarefas serão agendadas automaticamente
- Não serão criadas datas de exceção no calendário
- O Microsoft Project seguirá a configuração padrão para o cronograma: 9:00 – 18:00; 8 horas por dia; 40 horas por semana; 20 dias no mês
- Todas as tarefas são do tipo Unidades Fixas, que é o padrão do Microsoft Project
- Todas as tarefas irão possuir pelo menos 1 recurso atribuído

Resultados: sintaxe 1

A primeira fórmula a ser testada possui a seguinte sintaxe:

Int(IIf([Data de status]>[Término Agendado];100;IIf([Data de status]<[Início Agendado];0;ProjDateDiff([Início Agendado];[Data de status])/ProjDurValue([Duração Agendada])*100)))

Agora vamos lá construir o novo campo personalizado no Project. Irei criar o campo como tipo número, e irei chama-lo de “% Prev 1”. Caso você não saiba como criar campos personalizados, sugiro dar uma olhada nesse post. Uma vez criado o campo, será necessário adicioná-lo ao modo de exibição atual (Gráfico de Gantt):


Quando efetuamos a leitura da sintaxe utilizada na construção do campo, é possível perceber que o principal fator considerado no cálculo é o tempo. Entretanto, o que inicialmente causa estranheza é o fato de o campo já estar apresentando o percentual previsto como 100% mesmo sem termos realizado nenhuma ação ou lançado progresso nas tarefas. Analisando novamente a sintaxe do campo, percebemos que este fato está relacionado à Data de Status (que, neste caso, ainda não foi definida). Então, vou definir a Data de Status do projeto como 24/07, que é a data de início do projeto (para definir a Data de Stutus do projeto, clique em Projeto > Data de Status). O resultado refletido no campo pode ser visto conforme abaixo:


Uma vez definida a Data de Status para 24/07, o percentual previsto da “Atividade 1” foi calculado para 20% – ou seja, a fórmula está considerando que estamos no final do primeiro dia e, como a atividade será realizada em 5 dias, 20% do caminho (tempo) já foi percorrido. Até aqui, podemos considerar que está tudo indo bem com a fórmula, correto...? Bem, como eu havia comentado na introdução desse post, é importante lembrarmos que tudo vai depender do que estamos querendo analisar/comparar.

Imagine que você tenha que informar o progresso real atingido até o momento (mesmo estando no primeiro dia). Você conversa com o recurso atribuído à tarefa e ele informa que está tudo indo conforme o planejado. Então, você deve atualizar o seu cronograma. Para isso, clique em Projeto > Atualizar Projeto:


Como você já havia definido a Data de Status como 24/07, a única coisa a ser feita é manter as opções Atualizar trabalho como concluído até e Definir 0% a 100% concluído selecionadas e clicar em OK:


Perceba o cálculo do progresso real na tarefa resumo “Iniciação” e também na tarefa de resumo do projeto “Cronograma”:


Perceba que mesmo que as tarefas regulares apresentem resultados semelhantes na comparação entre previsto e realizado (neste caso a “Atividade 1”), o mesmo não é verdadeiro para as tarefas resumo (10% de percentual previsto contra 7% de percentual executado). Mas, por que isso acontece? Em linhas gerais, enxergamos essa diferença em virtude do que o Alexandre havia comentado lá em cima... vamos lembrar:

“é preciso identificar que variáveis são ou serão coletadas durante as medições do projeto (ex: se eu perguntar por horas trabalhadas, estamos falando da estratégia de atualização por trabalho/esforço)”

Agora tudo fica muito mais claro... enquanto a sintaxe da fórmula leva em consideração o tempo (basicamente a diferença entre o início e término das tarefas), o Microsoft Project usa como referência o trabalho/esforço necessário para finalizar as tarefas. Perceba que neste cronograma exemplo a tarefa “Atividade 2” está acontecendo em paralelo com a “Atividade 3”, de modo que não se deve levar em consideração como as tarefas estão distribuídas ao longo do tempo – mas sim qual será o montante de trabalho necessário para que elas sejam entregues.

A tabela abaixo faz uma comparação entre a fórmula que foi criada e o cálculo padrão do Microsoft Project com base na Data de Status definida (24/07):


Perceba que, na medida em que o tempo avança, o cálculo vai ficando cada vez mais discrepante. Imagine que você tenha atingido o final da primeira semana, e então tenha definido a Data de Status para 28/07. Em seguida, você consulta o recurso responsável pela execução da tarefa e recebe a informação de que tudo correu conforme o planejado, e a tarefa está concluída. Você então clica em Projeto > Atualizar Projeto e mantém as opções Atualizar trabalho como concluído até e Definir 0% a 100% concluído selecionadas. Após clicar em OK, o resultado será:


Quando se está realizando comparações entre previsto x realizado, é importante sempre levar em consideração os fatores que estão sendo utilizados, para não comparar bananas com maçãs. Enquanto o cálculo do percentual previsto coloca seu foco exclusivamente no tempo (chegamos na metade da execução do projeto, ou seja, 1 de 2 semanas passadas), o percentual concluído do Microsoft Project leva em consideração no cálculo o montante de esforço necessário para que o projeto seja concluído (e, considerando essas circunstâncias, temos apenas 33% do trabalho finalizado – 40 horas realizadas de 120 horas totais).

Resultados: sintaxe 2

A segunda fórmula a ser testada possui a seguinte sintaxe:

(IIf([Data de status]>[Término Estimado da Linha de Base];100;IIf([Data de status]<[Início Estimado da Linha de Base];0;ProjDateDiff([Início Estimado da Linha de Base];[Data de status])/ProjDurValue([Duração Estimada da Linha de Base])*100)))

Como o campo % Prev1 já foi criado, vou criar um novo campo do tipo número chamado % Prev2. Após criar o campo e copiar a fórmula, vou ocultar o % Prev1 da visualização atual e substituí-lo pelo % Prev2:


A diferença substancial da fórmula atual para a anterior é que a sintaxe do % Prev2 precisa que a Linha de Base esteja definida para que o cálculo seja realizado. Sendo assim, defina a Linha de Base do projeto e veja o resultado:


Como é possível verificar, continuamos a perceber o mesmo comportamento na segunda sintaxe.

Resultados: sintaxe 3

A terceira fórmula a ser testada possui a seguinte sintaxe:

IIf([Duração Agendada]<>0;(round(([COTA]/[Custo da linha de base])*100));IIf([Data de status]<[Término Agendado];0;100))

Vamos seguir a mesma linha de pensamento. Como já temos os campos % Prev1 e % Prev2, vou criar um novo campo do tipo número chamado % Prev3. Após criar o campo e copiar a fórmula, vou ocultar o % Prev2 da visualização atual e substituí-lo pelo % Prev3:


Neste caso temos um cenário diferente dos dois cenários avaliados anteriormente: a sintaxe da fórmula não está levando em consideração o fator tempo, mas sim informações de custo. A avaliação principal é feita com base no campo COTA (Campo Orçado do Trabalho Agendado), que contém os custos da linha de base divididos em fases acumulados até a data de status (ou data atual). Caso você tenha interesse em obter informações detalhadas sobre o campo COTA, visite a página de suporte da Microsoft neste link.

No cenário analisado atualmente, o ponto central é que se deve evitar comparar duas informações através de dois métodos de cálculo diferentes (custos para o percentual previsto e esforço/trabalho para o percentual concluído).

Resultados: sintaxe 4

Vamos à quarta fórmula a ser testada. Ela possui a seguinte sintaxe:

Str(int(IIf([Data de status]<[Início da linha de base];0;IIf([Data de status]>[Término da linha de base];1;(ProjDateDiff([Início da linha de base];[Data de status];[Calendário do projeto]))/(ProjDateDiff([Início da linha de base];[Término da linha de base];[Calendário do projeto]))))*100))

Você já sabe o que fazer, certo? Crie um novo campo do tipo número chamado % Prev4. Após criar o campo e copiar a fórmula, oculte a coluna que exibe o campo % Prev3 na visualização atual faça sua substituição pelo % Prev4:


Mais uma vez, encontramos discrepâncias nos cálculos para as linhas de resumo, o que impede a comparação dos valores.

Resultado: cálculo do percentual previsto para tarefas interrompidas

Para finalizar os testes com os principais cenários para cálculo do percentual concluído, vamos agora realizar uma simulação bem simples. Vou criar um cronograma com uma única tarefa (Ativade 1), e exibir as colunas customizadas com o percentual previsto uma ao lado da outra:


Agora vamos conhecer os critérios e restrições existentes: digamos que, para esta tarefa, o trabalho deverá ocorrer normalmente nos dois primeiros dias (24/07 e 25/07); então, a tarefa deverá ser paralizada até a segunda-feira da próxima semana (31/07), quando o trabalho será retomado. Para interromper o trabalho da tarefa, iremos utilizar o recurso Dividir Tarefa do Microsoft Project:


Após dividir a tarefa a partir do dia 26/07, o cronograma será reajustado da seguinte maneira:


Agora, para que seja possível visualizar o comportamento dos campos que calculam o percentual previsto, defina a Data de Status do projeto como 28/07. O resultado será:


Perceba que não há consistência nos resultados obtidos em cada um dos campos (o que de certa maneira é até esperado, em virtude de cada um utilizar um critério de cálculo diferente). Porém, o que é mais preocupante é que há situações em que o percentual previsto é calculado como 100% mesmo a tarefa não tendo chego na sua metade (tanto em termos de tempo quanto em termos de trabalho/esforço). Se atualizarmos a tarefa como esperado através da opção Atualizar Projeto, o resultado será:


Comentários e observações finais

Espero que este post, através de seus exemplos práticos, cenários e simulações, tenha contribuído e ajudado os leitores a obter um melhor entendimento sobre um dos temas mais pesquisados no que se refere a utilização e customização do Microsoft Project. Por mais que os resultados obtidos nos campos personalizados muitas vezes se aproximem do resultado final calculado pelo software, podemos observar claramente que as opções aqui testadas acabam deixando margem para dúvidas, o que acaba de certa forma comprometendo a análise e a comparação entre planejado e realizado.

Um ponto que precisa ser destacado é que os cenários testados utilizaram simulações simples, com um número baixíssimo de tarefas e sem considerar inúmeras variáveis que são uma realidade quando estamos gerenciando um projeto. Portanto, na medida em que o grau de complexidade do cronograma subir, é inevitável que sejam encontradas maiores diferenças entre as informações comparadas.

Alternativas, downloads & links

Para aqueles que quiserem aprofundar o seu conhecimento e estudar caminhos alternativos ao cálculo do percentual previsto, a alternativa mais recomendada é estudar o método de Análise de Valor Agregado. Há um vasto material disponível, entre os quais podemos citar:


Sequência de posts do MVP Mário Trentim sobre o Valor Agregado no blog da Revista Mundo PM: parte 1, parte 2, parte 3


==========================================

Finalmente, caso você queira baixar este material em formato digital, basta clicar nesse link.

Vou ficando por aqui, mas gostaria de saber a sua opinião: você já precisou calcular o percentual previsto nos seus projetos? Possui alguma fórmula para fazer isso? Utilize a área de comentários do post para participar da discussão.

Um forte abraço e até a próxima!

12 comentários:

  1. Saudações Raphael!
    Eu quero compartilhar aqui no post uma situação com a qual me deparei hoje.
    Eu uso a fórmula da sintaxe 1 no meu ambiente EPM com Project Online e Professional, porém, eu trabalho com a data atual no lugar da data de status e as datas da linha de base 0 no lugar das datas agendadas.
    O meu cenário que me causou espanto foi o seguinte:
    Eu tenho dois projetos com duração média de 200 dias. Quando eu visualizo o projeto usando o campo nativo Status no MS Project o projeto está No Prazo. Porém, quando eu visualizo o projeto tomando como base o meu KPI customizado através da referida fórmula o projeto está atrasado (muuuuuutio atrasado). As tarefas estão todas com progressões em dia, algumas até adiantadas.
    Eu fiz algumas análises e notei que em algumas tarefas dezenas de recursos foram alocados, porém, a distribuição ficou como padrão, ou seja, cada um trabalhando 8 horas por dia. O resultado disto é que as tarefas com grande volume de recursos e de pouca duração, aproximadamente 5 dias e 40 recursos alocados, chegam a ter trabalho planejado de 1600 horas!
    Isto me causou uma confusão mental gigante e foi difícil chegar em um consenso. Ou eu mudava a fórmula customizada, ou trabalhava com os parâmetros do MS Project e eliminava meu KPI customizado ou mantinha meu KPI customizado e registrava este fato no meu formulário de principais acontecimentos e lições aprendidas.
    Resolvi então, por questões relacionadas a tempo, manter o meu cenário customizado atual, registrar o acontecimento e planejar uma nova fórmula para calcular meu percentual previsto de forma que o resultado não seja tão agressivo como é hoje. A minha situação só não foi mais grave porque eu, ainda, não faço controle de custos do portfólio de projetos da empresa.
    Bom... esta é minha contribuição para o tema proposto e espero que demais espectadores do blog possam participar da discussão e contar suas experiências.
    Abraço e até breve!

    ResponderExcluir
    Respostas
    1. Fala Mosar,

      Cara, que grande prazer ver seu comentário aqui no blog. Eu realmente gosto muito dessa participação, troca de experiências e feedback!

      Sabe, eu acho que muitas vezes algumas pessoas podem ficar com a impressão de que nós, que escrevemos e compartilhamos informações, somos os donos da verdade, e que tudo que dizemos é lei. Pois a verdade é que eu acho muito o contrário...

      Nós somos aqueles caras que experimentam alguma coisa, erram, e depois procuram compartilhar um pouco da sua experiência para contribuir e também comparar com o que os outros estão fazendo :-)

      Por isso achei muito bacana o seu depoimento aqui no post. É uma excelente maneira de compararmos cenários, discutir possiveis soluções e melhorarmos o nosso conhecimento e a maneira como gerenciamos nossos projetos.

      Agora, 40 recursos alocados em uma tarefa!!! Rapaz...! Que tipo de projeto é, construção civil?

      Um forte abraço meu amigo!

      Excluir
  2. Saudações Raphael e demais!
    Hoje eu descobri um outro problema grave com a fórmula que estou usando (cenário 1).
    Muitos cronogramas dos projetos da companhia não seguem o padrão de vinculação de tarefas, por exemplo:
    Uma tarefa tem início em 01/04/2018 e término em 05/04/2018. A tarefa seguinte tem início em 22/04/2018 e término em 10/05/2018. Estas tarefas não possuem um vínculo feito no MS Project mas são sequenciais.
    Com isto descobri que cronogramas que possuem muitas tarefas neste modelo sempre estarão totalmente atrasados.
    Ainda não tive tempo de testar mas creio que terei que aplicar vínculos com latências neste tipo de sequência de tarefas.
    Para piorar minha situação, meus gerentes de projetos têm apenas licenças do Project Essentials e eu sou o único que possui a licença do Microsoft Project Professional!

    ResponderExcluir
    Respostas
    1. Fala Mosar,

      Pois é, mais um ponto a se considerar sobre o percentual previsto. Porém, essas tarefas que não possuem vínculo entre si estão relacionadas a pelo menos uma predecessora? Lembre-se que não é boa prática possuir tarefas no cronograma que não possuam predecessoras.

      Um abraço e obrigado por compartilhar suas experiências por aqui!

      Excluir
    2. Saudações Pessoal!
      Respondendo sua pergunta, Raphael, as tarefas não possuem predecessoras. São tarefas soltas que ocorrem em sequencia, porém, a maioria delas possui uma certa latência positiva.
      Eu fiz um teste em algumas delas inserindo latências via MS Project Professional e o status do cronograma melhorou, voltando para um cenário mais próximo do real.

      Excluir
  3. Boa tarde.
    Raphael, tem alguma formula que calcule o % previsto utilizando os valores de trabalho (horas) estimado para cada tarefa?

    ResponderExcluir
    Respostas
    1. Fala Victor, tudo bem? Não tenho conhecimento se há alguma fórmula que faça esse cálculo.

      Abs!

      Excluir
    2. Saudações Parceiros!
      Teoricamente sim.
      Eu fiz um teste rápido com base na fórmula do primeiro cenário deste post.
      Basta apenas converter as durações e diferenças de datas, que são formatadas em dias, para horas, ou seja, multiplicar por 8 (valor de horas padrão).
      Fica aí esta dica!
      Forte abraço e comentem os resultados obtidos nos testes de vocês!

      Excluir
  4. Boa tarde, Mosar.
    rsrs Vou pedir sua ajuda mais uma vez então.
    Sei fazer as alterações não. Quem me dera ter o mesmo nível de conhecimento de vocês.
    Se der para colar a formula ai agradeço.

    ResponderExcluir
  5. Oi Raphael. Tudo bem? Existe a fórmula nos relatórios para apresentar as tarefas concluídas (7 dias), atrasadas e próximas atividades (7 dias). Que formula posso utilizar para apresentar no relatório apenas as atividades previstas de 1 dia. Tenho um projeto de 180 dias, e precisaremos reportar diariamente a evolução. Não quero fazer isso apenas filtrando no project. Quero apresentar no relatório. Parabéns pelo Blog e Obrigado

    ResponderExcluir
  6. Olá Luciano, tudo bem? Obrigado pelo seu comentário.

    Gostaria de me situar e entender melhor a sua dúvida: quando você diz que existem fórmulas para apresentar as tarefas nos relatórios, você está se referindo aos relatórios visuais disponibilizados pelo Microsoft Project?

    Se sim, acredito que a resposta para sua dúvida é até mais simples do que parece: quando você clica em algum elemento do relatório (uma tabela ou um gráfico, por exemplo), do lado direito da tela irá aparecer os itens que este elemento está utilizando: lista de campos, filtros, grupos, classificação e etc. Nesse sentido, basta você observar qual o filtro que está associado ao elemento, de modo que você possa escolhar uma opção diferente ou, caso nenhuma das opções seja viável, criar o seu próprio filtro.

    Dessa maneira você poderá customizar o relatório para que ele entregue as informações das quais você necessita.

    Fico no aguardo do seu feedback neste tópico.

    Abs!

    ResponderExcluir
    Respostas
    1. Exatamente isso Raphael. Não consegui fazer uma fórmula para apresentar as atividades do dia anterior. Tem apenas para os últimos 7 dias. Que formula posso utilizar exibir apenas as atividades do dia anterior ou apenas do dia? Obrigado

      Excluir