Duas razões do fracasso dos projectos

As histórias de fracassos espectaculares abundam, mas nem sempre são vistas como aquilo que são – exemplos. Já ouvimos falar dum projecto que tinha 150.000 euros de orçamento inicial e só é fechado quando ultrapassou já 1.000.000 de euros. Ou um projecto para um novo sistema que devia ser entregue em Julho e que é finalmente posto em produção em Setembro, mas dois anos depois. Qual será a razão que persegue os projectos e os conduz a estes fracassos.

O culpado mais apontado, por muitos, é a deficiente estimação. Há uma anedota o comum que afirma que uma pessoa com perfil técnico tem muita dificuldade em estimar o custo do almoço, mesmo quando dispõe de uma ementa. Mas isto é, claro, um mito.

Há pessoas com baixas capacidades de estimação, mas mesmo quando as estimativas falham por cem por cento, o custo total não poderá ultrapassar o dobro do inicial. Se as contas estão bem-feitas! Isto não é o desejável, mas nada disto é comparável com as ultrapassagens que todos conhecemos em projectos que parecia serem todos muito sérios e com horizontes bem definidos. Lamentavelmente, na maioria deles estamos envolvidos porque de alguma forma estaremos envolvidos no pagamento de alguma coisa, já que a maioria esmagadora destes são projectos com dinheiros públicos.

Mas a má estimação não parece ser a justificação para desvios de 500 e mais por cento. De facto, muitas pessoas experientes conseguem estimar razoavelmente bem, e, na onda de um projecto grande, o optimismo de alguns estimadores equilibra-se com o pessimismo de outros. Embora existam muitas outras razões recorrentes para a falha dos projectos há duas que se salientam como principais e primárias: as alterações de âmbito e o planeamento fraco do projecto.

As alterações de âmbito são provavelmente a causa maior para o fracasso dos projectos. O problema com as alterações de âmbito não é somente porque aumentam o custo, mas porque adicionam o custo fora da proporção correspondente ao esforço aparente. Por exemplo, um projecto estimado a 20 milhões cresce até um projecto que, se tivesse sido planeado dessa forma do início, seria estimado em 40 milhões. Somos tentados a acreditar que o custo final do projecto será à volta de 40 milhões, mas muitas vezes será perto dos 80 ou 90 milhões, porque as alterações do âmbito perturbam o planeamento e o desenvolvimento do que estava já concluído, isso implica re-trabalho e , se o processo for suficientemente longo, podem comprometer a estrutura do projecto como se quisesse adicionar 5 andares a um prédio planeado para 10.

As alterações de âmbito são um problema por duas ordens de razões. (1) Quer o projecto não teve o seu âmbito definido desde o início ou o gestor de projecto falhou na gestão efectiva dos pedidos de alteração do âmbito. As alterações de âmbito são inevitáveis e não são necessariamente más. Só se tornam perigosas quando não são devidamente geridas, isto é, quando não são adequadamente definidas, avaliadas, acompanhadas e geridas.

A segunda causa de maior preocupação e causadora de fracasso dos projectos é o planeamento pobre e, em particular, a desconsideração das actividades de projecto durante o planeamento. Estas actividades não fazem parte das estimativas, elas não surgem no plano e não parece que tenham efeito no plano. Mas quando são necessárias podem provocar o caos. Por exemplo, um projecto em que é necessário realizar a formação de um grupo de utilizadores, mas que falha na definição e realização de uma actividade para criar os materiais de formação, irá ser a base de atrasos logo no momento em queo teria a possibilidade de realizar os benefícios.

Os projectos não têm de falhar! Quando um gestor de projecto experiente e as suas equipas tratam de forma séria o planeamento e a gestão das mudanças do âmbito os projectos geralmente cumprem com sucesso. Se quer trabalhar sossegadamente em projectos de sucesso e deixar os catastróficos para outros, aprenda a controlar estas partes essenciais da gestão dos projectos.

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)

A Consultoria de Gestão e o Fracasso dos PMO

Os PMO que foram implementados em grandes companhias fracassam porque perdem, na sua maioria, o seu tempo em intermináveis batalhas com outros departamentos ou em crises de identidade que impedem a afirmação da sua missão.

O problema é que o culpado habitual por esta ineficácia e falhanço do PMO, ou seja, a falta de compromisso da gestão, não é de facto a causa primária. Na realidade, o denominador comum do fracasso dos PMO pode ser atribuído antes ao papel desempenhado pelos consultores de gestão que estabeleceram o PMO. Estes consultores desempenharam um papel instrumental nas três áreas abaixo durante a criação do PMO, criando defeitos estruturais de grande dimensão, que embora com todas as tentativas de resolução se mantêm como uma nódoa que não se apaga.
 

Semear as sementes da confusão nos executivos

Mantém-se uma confusão perpétua mas cabeças dos executivos acerca das funções, responsabilidades e competências dos PMO. Isto nasce porque os consultores contratados para o estabelecer focam-se, de forma exclusiva, em estabelecer um PMO que exiba características de uma função de reporting e pouco mais. Neste arranjo, os status de diferentes projectos e programas são agregados, racionalizados e então apresentados à equipa de gestão para a tomada de decisões.

O que acontece é que muitos dos executivos são incapazes de vestir a roupa do sponsor do projecto (antes desempenhado pelo CEO) e tomarem as decisões importantes para os projectos que estão debaixo do seu âmbito de decisão. Ainda mais, muito poucos executivos possuem ideias sólidas acerca de como um PMO centralizado deve funcionar. Assim, é lógico encontrar a falta de compromisso executivo quando o PMO entra em modo de cruzeiro.
 

Nunca foi uma questão de metodologia de projecto

Na fase de lançamento, a companhia de consultoria que estabelece o PMO presta muito pouca atenção à metodologia de programa / projecto ou à standardização dos documentos de projecto e dos modelos bem, ainda, à formação das pessoas do PMO na realização das suas funções para além do reporting. O próprio reporting sofre da ausência de uma abordagem estruturada e muitas vezes existe uma exagerada dependência das «apresentações de Powerpoint».

Depois após a implementação, o PMO armado unicamente com slides coloridos está muito mal equipado para apoiar ou realizar projectos e programas. Segue-se um crescente fracasso dos projectos e todas as tentativas para rectificar esta situação fracassam irremediavelmente.

Tudo isto porque as soluções utilizadas para enfrentar a fraqueza estrutural derivam da experiência de lançamento do PMO. Como exemplo, muitos executivos assumem que, só porque o PMO realizou resultados durante a fase de lançamento, irá depois, com uma abordagem similar e sem trabalho adicional, fornecer os mesmos resultados positivos.
 

Demasiada confiança em funções e responsabilidades centralizadas

Outra descoberta desconcertante é que as funções e responsabilidades, estruturas de processos e governação executadas pelo PMO estão baseadas na sua vida no lançamento. Encontramos muitas vezes funções de 'Launch PMO', 'Launch Manager', 'Launch Director', 'Launch Gate', 'Launch Project Life Cycle', 'Launch Check Lists', etc. como parte do léxico. Em muitas vezes, só o prefixo ‘Launch’ é removido das descrições de funções e processos, mas a essência está inalterável. Subsequentemente, o PMO e a sua equipa são incapazes de se adaptarem ao ritmo da vida da companhia e descobrem-se na periferia da realização dos projectos.

Para remediar a situação, são aplicadas duas soluções típicas. Em primeiro lugar, são recrutados «gestores de projecto certificados» e espera-se que estes realizem os projectos dentro do plano. Contudo, na ausência de uma metodologia sólida de gestão de projecto, vemos que muitos ficam parados num limbo.

Em segundo lugar, são recrutados para a remediação consultores muito dispendiosos com experiência extensiva em trabalho com PMOs. Em alguns casos, os consultores são na realidade contratados da mesma companhia de consultoria que estabeleceu o lançamento do PMO e falham miseravelmente quando lhes é atribuída a responsabilidade de resolver os problemas e sanar o PMO. Tudo isto exacerba o problema e marginaliza o papel do PMO na vida da companhia.

Para ser justo com os gestores de gestão, estes são normalmente contratados em virtude da sua competência no domínio e não pelas suas competências em PMO. Este é um valor adicional que é introduzido como uma parte dos serviços de consultoria sem custo adicional. Esta prática está generalizada de tal forma que os executivos ficam a pensar porque é que há tanto fracasso de projectos apesar do lançamento com sucesso de novas linhas de negócio.

Para evitarem cometer o mesmo erro segunda vez, os executivos devem por bem escrutinar as capacidades de PMO dos seus consultores, para além do conhecimento do domínio. Em alternativa, podem contratar um especialista de PMO para a companhia, que trabalhe em colaboração com os consultores na fase de lançamento e assegure que é entregue um PMO adequado, equipado com a metodologia certa e os recursos estabelecidos.

Os executivos devem procurar optar por companhias que forneçam a capacidade de PMO, mas também transfiram as competências para os futuros responsáveis pelos mesmos na companhia.