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:
==========================================
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!
