Valor Ganho (EVM) explicado

Muitos sistemas avançados de gestão de projeto utilizam o modelo tradicional de planeado vs real para acompanhar até que ponto o projeto está a decorrer (bem ou não tão bem) de uma perspetiva financeira. Contudo este modelo deixa de fora um elemento importante – o valor do trabalho já realizado.

 Quando o planeado vs real são os únicos valores acompanhados, só consegue ver se está abaixo ou acima do orçamentado. Diz muito pouco ou nada sobre o progresso daquilo que estamos a realizar. Por exemplo, podemos estar a gastar demasiado porque estamos avançados relativamente ao plano e fizemos imensos progressos.

Assim, aquilo que parece um problema é antes uma vantagem porque iremos terminar mais cedo e provavelmente abaixo do orçamento. Mas, se não existir nenhum sistema para atribuir valor às realizações não teremos nenhuma forma fácil de saber quais as implicações de ultrapassar o orçamento. Pode, claro, rever o plano e obter um sumário da percentagem de conclusão do projeto, mas este valor de percentagem, por si só, não está ligado aos valores baseados em custo do orçamento e custo real que estamos a acompanhar.

Para simplificar muito o conceito de valor ganho, podemos dizer que este irá atribuir um valor ao progresso que se realizou, com base no orçamento baseado no tempo.
Para ilustrar vamos usar um exemplo em termos de planeado vs real e de seguida vamos adicionar valor ganho para ver o que revela esta outra dimensão.

Temos um projeto de 10 meses que está planeado para gastar 1 Milhão por mês para um orçamento total na conclusão (BAC) de 10 M. Já passaram 2 meses e de acordo com os números de custo do planeado vs real já gastou menos 50% do que devia. Podemos assim assumir que o projeto está a decorrer bem, porque aparentemente está a gastar menos do que o que estava planeado.

Ao introduzirmos os números de valor ganho com base no progresso real do projeto obtemos uma nova perspetiva. Depois de 2 meses de trabalho, só foi completado 5% do trabalho. O cálculo simples para este cenário é 5% sobre um total de 10 M do orçamento serão 500 k. Este é o número do valor ganho.

O que é que este número de valor ganho nos diz acerca da presente situação do projeto?A despesa inferior realizada não é uma boa notícia para o projeto porque o cronograma está 75% para trás; o projeto está na realidade a gastar mais com base no trabalho realizado. O que parece bem numa perspetiva de planeado vs. real está longe de estar bem quando o valor do progresso é introduzido como valor ganho.Isto significa ainda que podemos ver o impacto para o projeto utilizando os cálculos standard de valor ganho. 

Estes sublinham a dimensão dos problemas em que o projeto pode estar envolvido.

• Orçamento na conclusão (Budget at Completion - BAC): 10 M
• Valor planeado até à data (Planned Value – PV): 2 M
• Valor ganho até à data (Earned Value – EV): 0,5 M
• Custo real até à data (Actual Cost – AC): 1 M
• Variância de custo (earned value – actual cost) = -0,5 M (significa gastar mais 100%)
• Variância de agendamento (earned value – planned value) = 1,5 M (1,5 meses ou atrasado 75%)
• Cost Performance Index (CPI): (earned value / actual cost) = 0.5 (por cada euro gasto ganhou 50 cêntimos)
• Schedule Performance Index (SPI): (earned value / planned value) = 0.25
• Estimado na conclusão (Estimate at Completion – EAC): (budget at completion / cost performance index) = 20 M
• Estimado até à conclusão Estimate to Completion: (budget at completion – earned value)/cost performance index = 19 M
• Tempo para completar = (10-0.5) /0.25 = 38 meses

Com base na performance corrente este projeto irá necessitar de 20 M (19+1) e 48 meses (38+2) para concluir.

Embora este seja um exemplo exagerado, muitos projetos sofrem algum nível de sobre despesa e sub-performance nas etapas iniciais. Isto é característico porque leva sempre mais do que o estimado com seguir ter todas as pessoas no site, o equipamento entregue e todos a trabalhar a bom ritmo.

Sem gestão do valor ganho, contudo, é impossível ter consciência do impacto potencial destes atrasos iniciais, que podem passar sem notícia significativa. A gestão pode não reagir da forma apropriada ou suficientemente cedo a estas tendências de forma a prevenir a ameaça de longo prazo ao sucesso do projeto.

Adaptação de post da Ten Six Consulting LLC.

Controlar os pedidos de Alteração nos projectos

Os pedidos de alteração quando um projecto se inicia são uma parte inevitável do projecto. Elas podem ser o resultado de mudanças externas no negócio ou podem ser mudanças internas requeridas porque os propósitos originais do projecto não foram claramente definidos ou compreendidos.

As mudanças requeridas por factores externos estão normalmente fora do controlo de um gestor de projecto e há muitas vezes poucas escolhas para as enfrentar. Muitos dos gestores de projecto experimentados terão já colocado em posição um processo no início do projecto para tratar destes pedidos e o plano será suficientemente flexível para tratar delas sem afectar o resultado final.

Mas os pedidos de alteração provenientes de factores internos devem ser tratados de forma muito diferente. Num projecto ideal muitos destes devem ser evitados garantindo que os objectivos do projecto estão bem definidos, que os requisitos estão documentados claramente, que foram comunicados a todos os stakeholders e que estes compreenderam o que é esperado do produto final. Claro que nós não vivemos num mundo ideal e por mais profunda e bem detalhada que sejam as fases iniciais do projecto tem de existir em posição um efectivo processo de controlo da mudança.

Nem todos os stakeholders e utilizadores conseguem visualizar o produto final pela leitura da documentação e estudo de diagramas. Mesmo quando são usados protótipos para melhorar a produção de requisitos, estes são, pela sua própria natureza, produtos não inteiramente funcionais e serão inevitáveis incompreensões e assumpções nos projectos complexos.

De qualquer forma, a boa documentação e documentação clara dos objectivos e requisitos de projecto irão minimizar o número de pedidos de alteração.

Então qual é a melhor forma de controlar os pedidos de alterações num projecto e continuar a realizar a conclusão do projecto dentro de um orçamento, de escalas de tempo e âmbito?

Distinguir entre o Necessário e o «Era bom ter»

Cada um dos pedidos de alteração deve ter uma justificação (que tal um «business case») que os suporte, tal como o projecto tem uma justificação. Claro, que esta justificação pode ser muito simples e breve, mas é um elemento necessário de todos os pedidos de alteração antes que possam ser considerados para inclusão no projecto.
O elemento mais importante deste «business case» do pedido de alteração é o benefício esperado o qual deverá indicar o valor que será adicionado ao projecto pela mudança. Isto indicará, por si próprio, quais as mudanças que serão provavelmente necessárias. É importante reconhecer que a descrição de alguns destes «business cases» pode não beneficiar necessariamente o projecto em termos de tempo e orçamento, mas sejam necessárias para que o cliente se mantenha competitivo no mercado.
Se os benefícios não forem especificamente declarados então deve discutir-se a questão com a pessoa que requereu a alteração para determinar se existe um genuíno benefício de negócio.
Soluções melhor desenhadas, ou mais bonitas, com funcionalidades e mais atractivas não são benefícios, a não ser que possam ser apoiadas pela forma como estas tiveram um impacto positivo no orçamento e no plano do projecto, ou, um impacto positivo nos esforços dos utilizadores em completarem actividades regulares. As perguntas mais vulgares a que deve responder o «business case» são:

• · Qual é a mudança externa no negócio de que resultou este pedido de alteração?
• · Quais os factores internos de que resultou este pedido de alteração?
• · Como é que esta mudança irá afectar o tempo que levamos a completar o projecto?
• · Como irá esta mudança afectar o produto final para o utilizador?
• · Que poupanças serão realizadas pela implementação desta mudança?

Evite desperdiçar Tempo e Esforço

A forma mais óbvia de evitar desperdiçar recursos valiosos de projecto em pedidos de alteração excessivos e em todo o processo de gestão da mudança, é garantir que o projecto se inicia com objectivos e requisitos claramente definidos. É também importante o critério que iremos usar para determinar o sucesso do projecto estar documentado sucintamente desde o início do projecto. Deve garantir que estes documentos são distribuídos aos stakeholders e utilizadores e que estão acessíveis cópias dos documentos.

Planeie actividades incluídas no plano do projecto para tratar dos pedidos de alterações e se este tempo foi ocupado adie os pedidos importantes para a próxima semana. Garanta que todas as partes interessadas sabem como trabalha este processo.

Tenha um Critério Claro de Aceitação e Rejeição

Defina um critério para avaliar estes pedidos que não serão, ou não poderão ser implementados. Quem faz o pedido tem de compreender o critério e este tem de ser consequente. O critério essencial, como já vimos, é ter uma justificação escrita, um «business case», que esclareça os benefícios. Se não tiver pode ser de imediato devolvido a quem emitiu o pedido. Não perca tempo atrás de quem fez o pedido para saber qual é a justificação escrita. A responsabilidade disso é de quem faz o pedido que o deve fazer logo desde o início (mesmo que depois devamos discutir e aprofundar a discussão sobre esta justificação).

Esteja preparado para fundamentar as razões para rejeitar um pedido de alteração com uma descrição bem pensada do porquê para não incluir a mudança. Mantenha-se na sua decisão a não ser que o sponsor do projecto queira aumentar o orçamento ou o tempo disponível no projecto.

Esteja, também, preparado para ser flexível e para negociar a substituição de uma actividade em favor da mudança quando não há nem orçamento nem tempo disponível.
Aplique sempre as melhores práticas de gestão de projecto em todas as áreas do projecto se quer aumentar as suas oportunidades de sucesso.