Entre os dias 17 e 19 de setembro, tivemos o 12^o Seminário Internacional de Gerenciamento de Projetos do PMI-SP, um evento memorável. Em particular, tivemos uma apresentação fantástica do astronauta Marcos Pontes.

O Ricardo Vargas apresentou a palestra “Pulse of the Profession”, um estudo muito bacana realizado pelo PMI (veja o .pdf). Ao final da palestra, nosso amigo Farhad levantou um ponto importante: será possível o projeto atingir objetivos de negócio sem atingir os próprios objetivos do projeto, e vice-versa?

Farhad (@farhadak) defendeu que os objetivos do projeto devem ser os próprios objetivos do negócio! O que eu concordo muito… Inclusive, em nosso post anterior, falávamos exatamente sobre gestão de benefícios. Projetos devem criar valor para as organizações.

Por outro lado, Ricardo Vargas disse que, no caso da pesquisa, objetivos do projeto referiam-se à escopo, tempo e custo, entre outros. Enquanto que os objetivos de negócio, esses sim estavam ligados a benefícios, objetivos estratégicos e valor adicionado aos negócios.

Desta forma, é perfeitamente possível ter projetos de sucesso do ponto de vista interno (objetivos do projeto) e que sejam um fracasso externamente (ponto de vista de negócios). Na minha opinião, ambas as “disciplinas” devem andar juntas. Isto é, fazer os projetos certos (estratégia, portfólio, benefícios) da maneira certa (gerenciamento do projeto e balanceamento das restrições).

Embora eu acredite que é melhor fazer os projetos certos da maneira errada do que fazer os projetos errados da maneira certa, isso não é sucesso. Por exemplo, se pensarmos no Sidney Opera House, muitos dizem que é um sucesso, já que o resultado trouxe muitos benefícios. Entretanto, o projeto teve grandes problemas. Poderíamos dizer que ele foi mal gerenciado… então foi um fracasso. O fato de o resultado ter sido muito bom, como o Ford Taurus também, não deve apagar o fato de o projeto ter sido mal gerenciado.

Essa foi uma discussão que tive com nosso amigo Renato Branco (@rhbranco). Muitas pessoas estão usando o fato de “agregar valor” para “relaxar” na execução dos projetos. Ou seja, se eu tivesse feito o projeto do iPad muito mal gerenciado, atrasado, custando mais, ainda assim seria um sucesso? Embora um grande sucesso de negócios, eu vejo isso como um sucesso parcial. Aliás, acho perigoso pensar nos benefícios como o fator mais importante.

O que temos observado é que o gerenciamento dos projetos tem sido banalizado. Uma das causas é o foco extremo em estratégia e gerenciamento de portfólio, bem como a má implantação de PMOs em algumas organizações. As melhores práticas se tornaram um muito de ferramentas e técnicas sintetizadas em templates padronizados e controladas por softwares “schedulers”.

O resultado é que, em vez de formar gerentes de projetos, estamos formandos “pilotos” de MS-Project. Os PMOs estão se tornando burocráticos. E as áreas de negócios estão dominando o gerenciamento de projetos com a idéia dos “benefícios”…

Um outro fator é que a grande quantidade de cursos de gerenciamento de projetos tem criado um efeito perverso. Se por um lado estamos conseguindo disseminar a cultura de GP, por outro muitos de nós estamos nos apegando a receitas de bolo… Existem muitos livros básicos, como os da Rita Mulcahy, Kim Heldman (e os meus) que tratam gerenciamento de projetos de maneira introdutória. São livros para iniciantes.

Ao longo da carreira, precisamos nos aprofundar, buscando outras fontes de conhecimento, livros específicos, cursos avançados etc. Não basta apenas saber os nomes das ferramentas. Por exemplo, se o amigo leitor já deu uma lida nos livros da Rita, ou quaisquer outros, deve saber o que é crashing. Trata-se basicamente de uma técnica de adicionar recursos para acelerar a execução de uma tarefa. Nem todas as tarefas podem ser aceleradas, como o exemplo comum de que 9 mulheres não podem fazer 1 bebê em 1 mês…

Mas crashing é uma técnica avançada. Vai além de simplesmente alocar mais recursos para terminar tarefas antes. É preciso saber quais tarefas podem ser aceleradas, quanto elas podem ser aceleradas, quantos recursos serão necessários e avaliar o custo-benefício de fazer isso. Dê uma olhada na figura abaixo.

Figura 1 – Custo x Duração

Trata-se de uma curva de custo versus duração fictícia de um projeto. CT é o custo total o projeto, que é a soma de CD e CI. CD é o custo das atividades, que é a somatória do custo individual de cada uma delas. CI é o custo fixo vezes a duração do projeto. Observa-se, portanto, que CI é uma reta, aumentando com o tempo. Já CD pode ou não se reduzir conforme a duração do projeto aumenta ou diminui. Finalmente, o CT poderá ter um ponto ótimo de inflexão, ou não.

Tudo isso depende do custo marginal das atividades ou custo de compressão por unidade de tempo. Isto é, o custo dos recursos para acelerar as atividades (crashing).

Imagine a tabela abaixo e o gráfico a seguir, que mostra a curva custo x duração do projeto.

Tabela 1 – Custos e duração do projeto

Figura 2 – Curva de Custo versus Duração 

Você saberia dizer qual valor de custo fixo inviabilizaria (do ponto de vista de custos) qualquer tentativa de crashing? Isso pode ser importante para o VPL do projeto, por exemplo. Veja também nosso post sobre viabilidade.

Não basta apenas investir nas soft skills, gerenciamento de stakeholders e comunicação, é preciso também desenvolver as hard skills, princípios e fundamentos de GP, bem como ferramentas e técnicas, além de softwares. Gerenciamento de projetos é uma disciplina de gestão e possui um cunho bastante técnico também.

Grande abraço e até a próxima!