SPI e o Earned Schedule

Há mais de 30 anos que o Earned Value Management (EVM) tem dado uma ajuda preciosa ao Gestores de Projecto relativamente ao desempenho dos seus projectos em termos de custo e prazo, durante a execução destes. Com base nesta ferramenta, é possível tomar consciência do estado do projecto, permitindo tomar acções correctivas quando necessário, antes que este esteja quase concluído e impossibilite a sua recuperação.

Contudo, apesar do tradicional EVM ter dado uma boa resposta ao calculo das estimativas finais do custo do projecto (utilizando o Cost Performance Index - CPI), em termos de estimativas de data final do projecto já não se pode dizer o mesmo. Refiro-me em concreto ao SPI (Schedule Performance Index), indicador de desempenho de projectos em termos de prazo. Da forma como este indicador é obtido (Earned Value/Planned V alue), em que ambas variáveis são valores monetários, é dificil de acreditar que espelhe fielmente o desempenho do projecto. Há em particular 3 situações em que o SPI não fornece valores credíveis, nomeadamente quando a curva do Planned Value não é linear, quando a tarefa não se inicia na data em que está planeada e quando a tarefa/projecto acaba após a data da baseline. Neste último caso, independentemente do atraso registado, o SPI será sempre 1 (no final da tarefa/projecto tem-se EV = PV), como que indicando que a tarefa/projecto acabou exactamente no dia em que foi planeado.

Atendendo aos ponto acima referidos, com mais ênfase no último ponto, houve a necessidade de procurar uma outra forma de medir o desempenho. Há várias propostas, mas aquela que me parece mais válida é o Earned Schedule (ES), em que se pode definir como sendo o momento em que o actual EV deveria ter sido obtido. Define-se então o SPI(t) como sendo o ES/PD (Planned Duration, duração planeada da tarefa/projecto) e o tradicional SPI($)=EV/PV.

Analisemos um projecto de duração 18 meses, e estamos no mês 10. Definimos que neste mês o PV=$5M e o EV=$4M. O SPI($)=4/5=0.8. Analisando o gráfico abaixo verifica-se que o actual EV estava planeado para o mês 6 (e não no mês 10). O SPI(t) é então 6/10=0.6, ou seja completou-se no mês 10 o que estava planeado se completar no mês 6.

(figura extraída do sitio http://www.earnedschedule.com)

Consideremos agora que o projecto acabou só ao fim de 25 meses, recalculemos os SPI. SPI($)=1 e SPI(t)=18/25=0.72, valores bem diferentes. É bem notório aqui a vantagem de se utilizar o Earned Schedule para o calculo do SPI, chamado neste caso de SPI(t). É de facto mais fidedigno.

Para mais informações e detalhes sobre esta temática, aconselho a consultar http://www.earnedschedule.com/.

Na minha opinião pessoal, creio que o uso do Earned Schedule promete trazer mais rigor ao EVM e a possibilidade de se obter valores de forecast mais fiáveis. Aliás, no PMI Earned Value Management Practice Standard, versão de 2005, já inclui os principios do Earned Schedule e já o referencia com sendo uma prática emergente. É por isso conveniente estar atento/a a esta evolução na forma como a avaliação de desempenho dos projectos será feita em breve.

Negociação

Todos os projectos envolvem negociação, nem que seja de ideias. Há pouco tempo ouvi uma história que me pareceu curiosa e que aqui reproduzo:

Numa época de grande escassez de laranjas, o dono da maior produtora de laranjas foi contactado por duas empresas que pretendiam adquirir toda a sua produção. Uma delas precisava das laranjas para produzir uma vacina contra uma doença letal que punha em risco toda a população mundial. A outra queria produzir uma solução que recuperasse os danos na camada de ozono e evitasse o degelo. Não querendo desperdiçar um bem escasso, o dono da empresa convocou ambas a empresa para apresentarem os beneficios dos seus projectos. Durante dias as empresas expuseram de forma detalhada os seus argumentos e esgrimiram argumentos para defenderem a importância do seu projecto face ao da adversária. Sem conseguir tomar nenhuma decisão, o dono da empresa suspendeu as negociações e decidiu analisar os planos de produção de cada uma delas. Descobriu que para produzir a vacina apenas era o sumo da laranja e que para produzir o recuperador da camada de ozono só eram precisas as cascas.

Moral da história: para que uma negociação possa ser bem sucedida é essencial conhecer não só os seus objectivos com os da outra parte.

Sistema de Gestão de Qualidade e Gestão de Projectos

Como recentemente alguém disse e bem, desenvolver projectos em qualidade é diferente de desenvolver projectos com qualidade. Esta pequena diferença semântica, ente outras interpretações, sugere que um projecto pode ter qualidade mas não necessariamente ser eficaz e/ou eficiente. Deste modo, para garantir o alinhamento da qualidade, eficácia e eficiência é normal que as organizações implantem um Sistema de Gestão de Qualidade (SGQ), com base em ISO’s, tais como o ISO9001 (definição SGQ), ISO9000 (fundamentos e vocabulário), ISO9004 (melhoria continua), entre muitas outras normas e metodologias.

E eis que, os colaboradores de uma organização que implanta um SGQ começam a ter o sentimento de burocracia, ou mesmo de perda de tempo, em algumas das suas tarefas. E é aqui que julgo importante reforçar o objectivo de um SGQ e o seu posicionamento face à gestão de projecto. Uma compilação de normas, processos, boas práticas, metodologias… deve ajudar as pessoas da equipa de projecto a produzirem resultados mais eficazmente, eficientemente e com mais qualidade. I.e. o que garante a qualidade dos resultados são as pessoas com o suporte do SGQ, e não o contrario.

No que toca particularmente à gestão de projecto, mesmo que um SGQ defina detalhadamente variadíssimos processos para esta área, apenas uma pequena parte da actuação de um GP é contemplada, pois na minha perspectiva, gerir um projecto é também gerir pessoas, custo, tempo, âmbito, risco, satisfação do cliente, entre outros aspectos importantes para alcançar o objectivo do projecto.

E a si, caro leitor, este puzzle também lhe faz sentido?

Quem é, de onde vem, para onde vai?

Quem já geriu projectos em diferentes organizações sentiu “na pele”, quase de certeza absoluta, o que teorizam os livros: o Gestor de Projectos (GP) exerce a sua função de forma completamente diferente dependendo da organização onde está inserido.

Esta diversidade na forma como se é GP levanta, para mim, uma questão básica:

Quando é que um profissional que gere um projecto não é GP? Ou, o que tem de garantir um profissional que gere um projecto para lhe podermos chamar GP?

Na minha opinião, um GP na sua forma minimalista é:

Um profissional que consegue apresentar factualmente a situação do projecto e consegue prospectivar a situação dos trabalhos do projecto até à conclusão deste.

Concordam? Ou, saber apenas onde está e para onde vai o projecto é demasiadamente redutor para a função de GP?

Culturas

Acabado de regressar de Luanda, onde estive duas semanas, muitas das conversas acabam por cair na forma como as coisas funcionam em Angola. Não raro, as conversam giram à volta da realidade profissional, das condicionantes específicos de um país diferente, da forma como a gestão da influência se faz, como a língua simplifica ou complica a capacidade de fazer coisas e colocar todos os interessados (os stakeholders...) orientados no mesmo sentido.
É mais simples? É mais complexo? Como se consegue? que "skills" são mais importantes?
Que diferenças são visíveis entre Portugal e Angola, na gestão dos projectos?
Que importância têm os aspectos culturais na gestão de projectos, no estabelecimento de uma linguagem comum que leve uma equipa multicultural a entender-se, baseada em alguma plataforma comum de comunicação, para levar por diante um projecto?
Uma questão para debater. Porque as respostas também têm culturas subjacentes...

Relacionamento Interpessoal

Um gestor de projecto deve possuir um equilíbrio entre técnicas de gestão de projecto e competências de relacionamento interpessoal, uma vez que o trabalho de um gestor de projecto é concretizado através da equipa de projecto e de outros stakeholders. Segundo o PMI, um gestor de projecto deve possuir capacidades de liderança, team building, motivação, comunicação, influência, tomada de decisões, negociação e sensibilidade cultural e politica. Do meu ponto de vista um gestor de projecto que não possua capacidades de relacionamento interpessoal terá grandes dificuldades em concluir um projecto com sucesso pois o dia a dia de um gestor de projecto é lidar com as pessoas. Um projecto é realizado por pessoas, para pessoas com pessoas.

Faseamento vs Qualidade do Produto Implementado

Quando existe a necessidade de fasear as entradas em produção de um projecto, considerando a implementação de uma nova aplicação de TI, geralmente não se tem em consideração que o período de estabilização/garantia dos desenvolvimentos dessas fases, deve ser garantido por recursos alocados a 100% a essas tarefas de manutenção, para não afectar o plano de implementação das fases posteriores.
Normalmente, de modo a não encarecer o projecto, a equipa de implementação é a mesma que realiza a manutenção/garantia após as entradas em produção faseadas. Quando existe esta duplicação de funções, corremos diversos riscos, directamente associados à complexidade do projecto/aplicação a implementar:
- Atrasos no projecto, derivados da alocação da equipa de desenvolvimento na estabilização da aplicação em produção;
- Diminuição da qualidade dos desenvolvimentos, derivada da pressão que poderá existir se, por exemplo, parte da equipa de implementação ainda está a “corrigir” problemas da Fase 1, quando de aproxima a milestone de entrada em produção da Fase 2.

Teremos duas hipóteses, de forma a mitigar os riscos associados ao faseamento dos desenvolvimentos:

1. Identificar no plano de projecto um período de estabilização/garantia dos desenvolvimentos de cada fase, garantindo que a fase sequente só se inicia após a finalização desse período;

2. Prever/garantir a constituição da equipa de manutenção, independente da equipa de implementação, e alocar recursos dessa equipa nas fases de implementação, de modo a haver uma passagem de know-how entre as duas equipas.

Scrum

Enquanto que num projecto linear o processo de controlo de alterações exige uma análise de impacto muito exaustiva, desencorajando os pedidos de alteração de âmbito e transferindo esse esforço para a fase de planeamento, nas metodologias ágeis, nomeadamente na Scrum em que se restrição tempo é “intocável” e o custo é também muitas vezes fixo, só mesmo com alterações ao âmbito se conseguem entregas dentro do tempo e do custo.

Apesar do sucesso crescente e comprovado das metodologias ágeis na gestão de projectos de TI, não resisto a lançar duas provocações:

1. Será aceitável correr o risco de no final de um projecto se entregar um produto cujo âmbito ficou aquém do inicialmente definido para se poder cumprir com o tempo e com o custo?

2. O GP num projecto agile não se torna apenas num Gestor de Alterações, transformando-se cada Scrum num Processo de Controlo de Alterações?