Business Case para quê?

Para que serve o Business Case se não existe a posteriori a confrontação dos benefícios identificados com a realidade do Negócio após a realização do projecto?

Em muitas ocasiões, o decisor ao analisar o Business Case, só está interessado em saber se o Break-Even está dentro dos valores que possibilitem a realização do projecto. E, geralmente, não confronta os dados apresentados com a realidade do Negócio nos anos posteriores à implementação do projecto.

Por outro lado, as áreas de Negócio responsáveis pela elaboração dos Business Case, ao saberem que não irá haver confrontação dos benefícios esperados com a realidade do Negócio após a realização do projecto, sentem que podem manipular os dados do Business Case, sobrevalorizando os benefícios e subvalorizando os custos, de modo a fazerem aprovar o projecto que tanto querem, sem que sejam responsabilizados no futuro pela análise realizada.

Para que serve então, um estudo de impacto no Negócio, se as premissas não são realistas?

A confrontação do Business Case com os benefícios qualitativos e quantitativos reais para o Negócio após a realização do projecto, poderia trazer muitos benefícios:
- Possibilita a constante melhoria dos indicadores dos Business Case futuros;
- Responsabiliza as áreas de Negócio pelas análises realizadas;
- Melhora a identificação de projectos que tragam reais benefícios para o Negócio;
- Melhora o planeamento dos futuros projectos.

O Negócio só deveria fechar o dossier do projecto, quando realizasse o estudo dos benefícios reais alcançados pela sua concretização.

PMO

Muitos acham que a implementação de um PMO não é relevante na Gestão de Projectos, outros nem sabem do que se trata. A implementação de um PMO (Project Management Office) deve ser realizada em casos em que os projectos sejam extensos e complexos. Deve ser formado por profissionais que servem as necessidades da Organização em termos de Gestão de Projectos.

Um PMO desempenha diversas funções, tais como:
- fornecer suporte de Gestão de Projectos à equipa de projecto, assumindo tarefas administrativas da calendarização, produção e manutenção do repositório/histórico, de relatórios, ou outra informação do projecto, assim como a sua distribuição ou divulgação;
- desenvolver, manter e promover metodologias/normas, ferramentas e técnicas de Gestão de Projectos por forma a que as Organizações possam melhorar a nível organizacional e realizar projectos de forma consistente;
- ajudar na melhoria da rentabilidade e promover equipas de projecto produtivas.

A verdade é que muitos desconhecem a utilidade/função de um PMO numa equipa de Gestão de Projectos, mas será que depois desta breve nota vão continuar a achar a sua implementação irrelevante?

Business Case, onde começa um projecto...

Tudo começa com uma Ideia que se materializa em Business Case(BC) ou estudo de Viabilidade antes de se transformar em Projecto.

Passo a transcrever a definição de Business Case do Wikipidia:
“A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need. An example could be that a software upgrade might improve system performance, but the "business case" is that better performance would improve customer satisfaction, require less task processing time, or reduce system maintenance costs. A compelling business case adequately captures both the quantifiable and unquantifiable characteristics of a proposed project.
Business cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief. Information included in a formal business case could be the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks. Consideration should also be given to the option of doing nothing including the costs and risks of inactivity. From this information, the justification for the project is derived. Note that it is not the job of the Project Manager to build the business case, this task is usually the responsibility of stakeholders and sponsors.”

Esta definição está correctíssima e acaba muito bem: não faz parte das funções do gestor de projecto elaborar o BC.
No entanto, não são raros os projectos aos quais foi dado o “go” sem BC ou, pior, com base num BC que não reflecte a realidade dos factos, mas o que o sponsor quer ver. Quando o projecto nos chega, já “foi dada a cara” e assumidos compromissos com cliente interno ou externo, pelo que ficamos condenados a gerir projectos mal dimensionados. A partir daí cabe-nos a nós, gestores de projectos, justificar: a necessidade de mais recursos, mais prazo, mais orçamento, o porquê de um NPV (VAL) negativo e de um payback inexistente...

Sinto uma forte resistência em envolver a gestão de projecto na elaboração do BC, tanto do parte das equipas comerciais como dos próprios PMO’s.
Os primeiros até entendo, pois a voz da razão soa como um obstáculo ao desenvolvimento do negócio. Como já ouvi uma vez: “vocês são técnicos e estão aqui para fazer das nossos mentiras verdades...”.
Que os PMO’s não queiram participar na análise de viabilidade dos projectos que irão ter que gerir, custa-me aceitar. Mas então, as lessons learned, todos os históricos de planos, de dimensionamento de equipas, de orçamentos finais, de riscos projectos... enfim, toda essa informação que o PMI tanto preza e que os PMO armazenam ,não deveria ser um dos input para o BC? Se os PMO’s são responsáveis pela gestão de portfólio, onde é que começa? O PMO não deveria querer ganhar força de intervenção na decisão de “go/no go” dos projectos?
É na Ideia e no BC que o projecto nasce, e o que nasce torto tarde ou nunca se endireita...

Datas, quero datas, e já hoje!

A quantos gestores de projecto são pedidas datas de finalização do projecto sem haver uma ideia clara do âmbito do produto?

A principal responsabilidade de um gestor de topo não é pedir datas, ainda mais quando o gestor de projecto não as tem para dar (a não ser que seja um cartomante).

O Gestor de topo deve pressionar para primeiro haver uma clarificação precisa do que se pretende do projecto, este é o passo mais importante para o sucesso, estabelecer a visão, o produto do projecto. Depois exigir planeamento, e rigoroso. E por fim as datas aparecem, e realistas.

Isto é do senso comum mas curiosamente poucos entendem este processo natural.

Penso que este aspecto está intrinsecamente relacionado com a pressão dos dias de hoje para acontecerem resultados, e por vezes essa pressa leva a saltar fases fundamentais para o sucesso de um projecto.

Ninguém pode trabalhar para resultados, podemos é trabalhar nos aspectos que potenciam os resultados. Na gestão de projecto, potenciar os resultados, i.e, o sucesso do projecto, é despender esforço em primeiro definir o âmbito do produto, e só depois planear e executar.

Parece evidente mas será assim tão comum?

Abraham Maslow nasceu a 1 Abril de 1908, faria hoje 102 anos. Defendeu uma teoria baseada na pirâmide das necessidades, hieraquizada em 5 níveis distintos, aplicável à Gestão de Recursos Humanos em todos os projectos.

- No 1º nível estão as necessidades fisiológicas, tais como as condições de trabalho em termos de ambiente físico, infraestrutura, ergonomia, horário de trabalho, etc..
- No 2º nível as necessidades de segurança, relacionadas com à continuidade do trabalho no projecto e em outros seguintes.
- No 3º nível as necessidades sociais, relacionamentos que se estabelecem com as pessoas da equipa do projecto e stakeholders, seja em termos de eventos ou comemorações por hitos alcançados.
- No 4º nível estão as necessidades de autoestima, ou seja, os elogios recebidos pelos profissionais, o reconhecimento, os prémios, bónus, etc...
- O 5º nível é o da autorealização, relacionado com a felicidade e realização por aquilo que se faz.

Ao contrário do que Maslow defendia, por vezes, as necessidades não seguem uma sequência contínua nos 5 níveis e podem sobrepor-se/misturar-se.
Mas se pensarmos num sentido mais lato, seremos movidos apenas por motivações intrínsecas, ou seja, pela vontade de realizar algo que conduza ao alcance do nível cinco?
O 4º nível poderá considerar-se a vontade externa, como um conjunto de estímulos e incentivos para levar à motivação, aos quais cada pessoa reage de maneira diferente?
Maslow afirmava que, quando uma necessidade não é satisfeita, não significará que a pessoa fica frustrada para sempre. De alguma forma, essa necessidade será compensada, pois a motivação é um ciclo constante na vida de todas as pessoas.

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.