A gestão de projetos formal, com planejamento Waterfall, MS Project e tudo mais, parece ser um negócio que funciona cada vez menos - e a presença de um PMO (do inglês Project Manager Officer) certificado (podendo até ser daqueles com um cronograma numa mão e um bastão de baseball na outra) raramente modifica o resultado, seja para o bem ou para o mal.

Segundo a pesquisa, mais de 70% dos projetos falham, e na última década esse número gigantesco de insucesso praticamente não se modificou, variando poucos pontos para lá ou para cá, ano a ano. Por outro lado, no mesmo tempo, o PMI - Project Management Institute, órgão que certifica os PMOs, ou gerentes de projeto, despejou no mercado incontáveis gerentes de projeto certificados, e a metodologia PMBok impactou milhões de profissionais em todo o mundo.

Aproximadamente 40% dos projetos estudados no Chaos Report dos últimos anos são projetos ágeis, que não seguem a teoria do PMI, mas que tiveram cerca de 50% de taxa de sucesso - salvando assim o índice final da estatística. Mas por que isso importa no nosso caso? Porque metodologias ágeis são normalmente utilizadas apenas em projetos de desenvolvimento de software, e praticamente todos os projetos de implantação de ERP seguem até hoje o tradicional modelo Waterfall/PMBok.

Tudo começa com a formação do GP. Ele aprendeu - e acredita nisso - que não é preciso entender nada do assunto do qual o projeto trata. Ele foi convencido por um exaustivo treinamento, que aplicando as práticas do PMBok ganha-se o poder de gerenciar qualquer tipo de projeto, de software e assim por diante.

1 Equipe desmotivada: como o GP não tem paixão pelo assunto, ele não entende o propósito do projeto. Então ele assume o papel arcaico de um chefe que apenas segue o manual e cobra tarefas e prazos dos seus “recursos”.

2  As coisas podem sair erradas ou diferentes do planejado: o GP que não conhece profundamente ERP se apoia em especialistas para tomar as suas decisões, mas esses especialistas normalmente são também “recursos” e possuem interesses pessoais conflitantes com os objetivos do projeto.

O GP sabe que sua principal missão nunca foi a de entregar o projeto. A missão real sempre foi, em português claro, “disfarçar e faturar”. São apresentados abaixo, o segredo de três mágicas para entender melhor esse “disfarçar e faturar”:

A mágica do “querer rir e me fazer rir”

Existem dois tipos de horas aplicadas a um projeto: as pagas pelo cliente e as glosadas, que o cliente não aceita pagar. Em praticamente todas as velhas empresas de ERP tradicional, o rendimento variável ou bônus do GP é calculado em razão do percentual de horas cobradas de seus projetos.

A mágica da formalização

O overhead de custo de gestão é, na prática, usado pelo GP nas atividades de “cover your ass”, ou seja, o cliente paga o custo do GP fundamentalmente para o fornecedor provar que a culpa de qualquer desvio é sempre do próprio cliente.

A mágica do contrato

Todo o contrato de implantação de ERP possui um parágrafo em letras pequenas mais ou menos assim: “os valores e quantidades de horas desse documento são estimados com base nas informações prestadas pelo cliente até o presente momento.

Como o cliente já gastou uma boa quantia de dinheiro, provavelmente não vai por tudo a perder - e o que era dele por direito vai ser entregue com mais um pacote de horas adicionais, lindamente cobradas pelo fornecedor. O GP, que no começo da profissão costumava a ficar horrorizado, depois de meia dúzia de projetos acaba achando isso normal e até mesmo correto, pulando de cabeça nesse jogo sujo e repartindo o escalpo arrancado do cliente.

Em sumo, o GP assume o papel de principal orquestrador desse jogo, seguindo as “boas práticas” descritas em “metodologias internacionalmente reconhecidas”.

Fonte:

Acesse a matéria completa