Um negócio que se arrasta às custas da falta de opção do cliente somado a um conformismo trágico.

Um negócio onde vender carne de terceira ao preço de filet mignon se tornou o esporte predileto dos executivos de software da velha guarda, e onde um projeto que deu “apenas” 30% errado é encarado como uma grande vitória pelos magníficos gestores de TI.

Sei que toda a generalização é burra por natureza e que existem exceções para tudo, mas não vou perder tempo sendo politicamente correto a cada frase. Então, tenha certeza de que eu sei que o que escrevo não se aplica a todos (só a quase todos) os Gerentes de Projeto de ERP.

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.

Para provar o meu ponto, basta olhar os resultados do Chaos Report: pela estatística global publicada, 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.

Fomos inundados por uma cultura de gestão de projetos que na prática falhou miseravelmente em reverter qualquer estatística de insucesso. Olhando mais a fundo é até pior: aproximadamente 40% dos projetos estudados no Chaos Report dos últimos anos são projetos ágeis, que não seguem nem de longe a teoria maçônica do PMI, mas que tiveram cerca de 50% de taxa de sucesso - salvando assim o índice final da estatística.

Em outras palavras, se levássemos em conta apenas os projetos tradicionais com toda a carga de metodologia e com os caríssimos profissionais de gerenciamento de projeto, o índice de fracasso seria algo bem próximo a 100%.

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.

Ok, então concordamos que a metodologia utilizada mostra sinais claros de fadiga. Mas atribuir toda a culpa a uma metodologia é o mesmo que punir o mensageiro por uma mensagem ruim, ou ainda condenar o carro pelo acidente.

A pergunta deveria ser: onde está o nosso motorista bêbado? Bem aqui, conhecido como GP (Gerente de Projeto). 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 mais parece uma lavagem cerebral), que aplicando as práticas do PMBok ganha-se o poder de gerenciar qualquer tipo de projeto, de software a foguete espacial, mesmo sem entender nada sobre nenhuma dessas coisas.

Consequentemente temos um GP de um projeto de ERP que não conhece ERP ou gestão empresarial, e que usualmente odeia falar de imposto, de nota fiscal e de contabilidade. Esse motorista bêbado nos causa previsivelmente dois acidentes com vítimas fatais e ferimentos graves:

1 - Equipe desmotivada: como o GP não tem paixão alguma pelo assunto, ele não “saca” 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” (pois é, depois de décadas de dedicação obstinada, aquele consultor heroico, que carrega o piano, ganha o “maravilhoso” nome de recurso, que soa no ouvido como “ferramenta”, “coisa”...). Que esteja claro: não existe líder que não é apaixonado pelo assunto. Se não há paixão, o GP é no máximo um chefe, e chefe jamais, em hipótese alguma, extrai o melhor que uma equipe poderia dar.

2 - Tudo sai errado ou diferente 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” (já falei que odeio esse nome?) e possuem interesses pessoais conflitantes com os objetivos do projeto. O GP embarca hora na conversa de um, hora na conversa de outro, e quando descobre o caminho certo já é tarde. E quem paga a conta do tempo gasto com as cabeçadas? Isso é o que vem a seguir.

Independente do GP ser alvo de constante manipulação pela sua falta de conhecimento específico, de longe o problema mais cruel que ele tem que digerir é esse: assim como qualquer motorista sabe que se beber vai provavelmente causar acidentes, 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”.

Para entender o “disfarçar e faturar”, “Mister M” vai precisar contar o segredo de três mágicas:

- A mágica do “quer rir, então me faz 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.

E se o projeto foi entregue e o cliente ficou satisfeito? Isso, se acontecer algum dia, vale um troféu e um aplauso, mas grana que é bom depende dele conseguir arrancar mais dinheiro do cliente. E como o GP faz isso? Com as duas outras mágicas abaixo:

- A mágica da formalização: a burocracia é sem dúvida o paraíso dos incompetentes, pois fica fácil ocultar erros em meio a milhares de documentos e, principalmente, transferir a culpa para quem não se documentou formalmente - geralmente o cliente.

Portanto, 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 (desses velhos, tradicionais, grandes e complicados) 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”, ou seja, na hora da venda o cliente pergunta: o sistema faz isso e aquilo de tal jeito? O vendedor responde: sim, claro!

Como ninguém gravou, quando o problema vem à tona basta o GP dizer: “bem, eu não estava lá, existe alguma evidência documentada no contrato? “ - o cliente responde gritando: “não, mas chama o cara que me vendeu aqui!”.

Então basta o GP dar a resposta padrão: “putz, infelizmente ele não está mais na empresa (ou está de férias / licença paternidade / morto / internado / desaparecido)”. Concluindo, como o cliente já gastou um caminhão 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.

Moral da história: projeto bom é projeto que deu errado, ao menos na visão do cliente, pois é isso que dá muito mais dinheiro para o fornecedor. E o GP assume o papel de principal orquestrador desse jogo sujo, seguindo as “boas práticas” descritas em “metodologias internacionalmente reconhecidas”.

Se alguém já viu um ERP desses famosos e tradicionais implantado no prazo, na qualidade e no custo previstos, me avise.

* Marcelo Lombardo é idealizador do produto Omie e CEO da Omiexperience.