Iniciei o trabalho com uma equipa de projecto de uma grande companhia que está a preparar a realização de uma obra de grande dimensão – que é mesmo o propósito da mesma companhia e veio-me à cabeça um turbilhão de ideias com os problemas enfrentados no início de um projecto e com as concepções diversas que se tem sobre a gestão de projecto.
O desenvolvimento dos grandes projectos de engenharia como a ilha Jumeirah no Dubai ou o desenvolvimento do Airbus A380, são concluídos com atraso de perto de dois anos relativamente ao plano. Estes são só dois exemplos, mas essa é uma constante porque esta performance dos projectos não é uma excepção. Desde a remodelação da cozinha até ao desenvolvimento de um produto, os projectos tendem para estar atrasados no tempo relativamente ao plano ou acima do orçamento, ou ambos. 
É tecnicamente possível fazer melhor mesmo em projecto de grande escala, com envolvimento de nova tecnologia como o exemplo do programa Apollo, que alcançou o seu propósito 5 meses antes do prazo, ou, para falarmos de um exemplo mais perto, a Ponte Vasco da Gama (2 meses antes do prazo). Mas estes não são fenómenos que se repitam com facilidade.
Assim, é legítimo perguntar se não somos capazes de fazer melhor, considerando as ferramentas que agora possuímos. A chave é, parece-me, que a gestão de programas e de projectos são tratadas como campos técnicos quando deviam ser olhadas como jogos, visto que os resultados são consequência de decisões tomadas por diversos agentes independentes.
Na gestão de projecto decompõe-se um projecto em actividades mais pequenas, às quais se atribuem durações, recursos e constrangimentos de tempo e de precedência. De seguida são realizados cálculos que produzem gráficos de Gantt, são identificados os perfis para os recursos, o caminho crítico, etc. A ferramenta mais comum é aquela que permite realizar o Método do Caminho Crítico (todas as ferramentas no mercado). Recentemente, chegou Eli Goldrath com a sua Cadeia Crítica da Gestão de Projecto (Critical Chain) que se foca nos recursos ou a Matriz de Desenho da Estrutura (Design Strucuture Matrix) que visa gerir as interacções entre as actividades.
Estes são todos modelos consistente e muito bons para as apresentações de soluções, mas estão muito longe do dia-a-dia da gestão de projecto dirigindo-se muito mais ao primitivo processo de listas de itens de acção. O problema mais óbvio com o uso destas ferramentas é que a duração para as actividades elementares é desconhecida e nunca vi uma organização que realizasse um esforço sério para recolher estes dados.
Uma actividade de projecto não é como uma actividade de montagem fabril que possa ser cronometrada ou registada em vídeo. O trabalho de projecto nunca é completamente repetitivo, se repetimos sempre a mesma acção, então é chamado produção ou transacção, mas não um projecto. Como nunca fizemos esta actividade de projecto antes, não pode dizer quanto tempo levará, mas pode obter outra informação dos seus componentes e pode estimar as similaridades ou as diferenças, com as actividades que já realizou antes, se mantém um registo disso. O trabalho de engenharia é organizado por projecto e o tempo dos engenheiros é controlado por timesheets, mas estas folhas são preenchidas após os factos pelos próprios engenheiros sem rigor efectivos e não são exactas.
Há formas de estimar melhor o trabalho das actividades, mas esse não é a preocupação principal dos gestores de projecto, ao contrário, o seu pensamento está focado em frases que começam com «Nada mais interessa, se…». Inicialmente, um gestor encarregado de liderar o projecto criou um plano que deve ser aprovado e nada mais interessa. O propósito do plano não é assim estimação mas sim persuasão. Como é que isto será realizado? Não há uma forma directa de o dizer, porque obviamente depende de quem deve ser persuadido. O que é constante é que o gestor de projecto está a vender, e irá fazer tudo o que for necessário para fechar o negócio.
