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:

Artigo técnico da Microsoft sobre a Análise de Valor Agregado

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

Livro ‘Análise de Valor Agregado – 6ª Edição’ do autor Ricardo Vargas

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

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!