Gerente de Projeto: o capanga do mafioso

Há algum tempo eu comecei uma saga de desconstrução do castelo de cartas que é o velho mundo dos ERPs tradicionais - aqueles velhos conhecidos, grandes, caros e que nunca funcionam direito. 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.

Comecei a série desmontando o produto, com “O ERP está morto”. Quando publiquei esse texto não imaginava que de repente meus velhos amigos de profissão se dividiriam explicitamente em dois grupos: uma parte que estava com o saco cheio de enganar os clientes e a si próprios, e outra parte formada pelos que ainda vivem de explorar a falta de percepção de um público iludido por alguma marca famosa.

Num segundo artigo, foi a hora de falar da coisa mais odiada pelo cliente de toda empresa de software: o suporte. Vimos que o problema do suporte raramente está na própria área de suporte, e todas as principais técnicas usadas para melhorar o cenário acabam apenas encobrindo a causa raiz do problema e piorando o cenário mais ainda.

Mas agora chegou a vez de uma turminha que tem um “lugar especial” no meu coração: os gerentes de projeto de ERP. 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 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 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 :>

Os itens acima foram apenas um aquecimento das turbinas, pois 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 grana 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.

 

Comments

[Marcelo Toyama]

Muito bom! Tem fundamento. Apenas complementando, já existem algumas consultorias adotando Agile em projetos de implementação e melhorias e os resultados tem sido bons. Outro ponto, é que já não existem clientes "bobos" e não raramente vemos os fornecedores tomando "invertidas" e se obrigando a entregar projeto com margem negativa.

[Marcio Fornari]

Estou lendo os posts a bastante tempo e tudo que o Marcelo disse tem razão, mas está falando muita bobagem, pois pelo que eu saiba antes ele vendia sistema desktop e agora passou a vender sistema baseado em WEB e SAAS, e está escrevendo isso defendendo o seu peixe. 'claro', falando verdade que parecem 'bobagens' que a empresa certa é aquela que emite 100% de notas fiscal, isso todo mundo sabe, mas sobrevive nesse país ?, ainda mais sabendo o que nossos políticos fazem com nossos impostos, obviamente é muito mais simples fazer um sistema fiscal também. Obviamente os SAAS só podem ser feitos assim, pois são mais fáceis de serem fiscalizados, nos EUA isso não pegou, pois lá as empresas não querem o SAAS em um servidor que não seja o deles, e aqui no Brasil pra vc ter o seu próprio servidor aumenta ainda mais esses custos. Eu penso o ERP ainda não morreu, e o que vale é o sistema funcionar e o suporte atender bem, nem que leve 5 horas, atendeu bem, você mantem o cliente

[Marcelo Lombardo]

Oi, Marcelo Fornari

Vamos lá, primeira coisa: modelo errado existe em Web/SaaS ou em Desktop. Não é porque é SaaS que é bom, muito menos o contrário.

Agora bobagem mesmo é dizer que não pode usar um sistema na Web para poder fazer caixa dois. Esse país não vai pra frente porque os políticos são o reflexo perfeito de um povo corrupto como qualquer um que venda ou compre sem nota. O problema desse país são caras que pensam como você, que se combate corrupção com mais corrupção, que critica o político corrupto mas age da mesma forma que ele dentro da sua esfera de alcance.

[Antonio Romano]

Apenas para comentar sobre o texto e não sobre política (pois já estou de saco cheio desse negócio). Implantei ERP com sucesso e com fracasso, Tive as suas experiências. Mas afinal, haveria outra opção? A opção pelo SAAS ainda é muito cara se olharmos para os grandes fornecedores, mas considero a melhor opção, visto que os investimento e riscos são menores, pois você pode exigir que se não atender você irá deixar o serviço ou cobrar uma multa.
O ERP tradicional e o PMBOK não são os culpados dos insucessos. O fato é que para se ter sucesso em qualquer iniciativa você precisa de conhecimento, compromisso e persistência. o PMBOK ajuda na persistência, pois estabelece um método de trabalho com um plano de execução. O problema é que, algumas vezes, o plano é deixado de lado. O Gerente de Projeto deve conhecer o que vai ser comprado e implantado. O GP deve ser do cliente e nunca do fornecedor. Essa estória de usar o GP do fornecedor para "dar as cartas do projeto não funciona". O compromisso é a principal bandeira de um bom projeto. Se a alta administração e a média gerência não estiverem comprometidas com os resultados do projeto, então o projeto vai fracassar. O CHAOS Report é muito claro. Projetos falham mais quando não se usa nenhum método, mas o principal problema são as expectativas não realistas e os requisitos mal descritos. Então, na minha opinião, o problema não está no GP, nem no PMBOK, nem no Agile e nem no ERP. O problema está antes disso. O ideal é usar uma metodologia clara para contratação do ERP. Seguir 3 passos: 1) Conhecer os produtos e ver onde eles estão funcionando bem; 2) Criar uma lista de requisitos de negócios que devem ser atendidos e 3) Realizar provas de conceito que demonstrem a capacidade plena de atender os requisitos de negócio. Por exemplo: O sistema deve permitir agendar uma visita aos representantes (que atendem no sistema porta a porta) informando data e período do dia e o sistema deve criar um roteiro otimizado com base nos CEPS dos clientes e das datas e períodos informados. Mas só isso não é suficiente: O contrato deve ser elaborado contendo toda a lista do que vai ser atendido de forma muito, muito detalhada. E por fim, esperar que os GAPS ocorram e que estes não sejam superiores a 20% do projeto orçado. Dessa forma você terá um projeto realista e de sucesso. Eu sou a favor das metodologias de gerenciamento de projetos, independente da que for, é muito melhor errar sabendo para onde estou indo do que errar sem ter plano nenhum.

[Marcelo Lombardo]

Oi, Antonio Romano

Dá para perceber que você tem bastante km rodado no assunto. Tem bastante nexo o seu comentário, mas existem os seguintes pontos:

1 - A maioria das pequenas e médias empresas possuem uma organização super frágil, e executam as tarefas da forma que "sabem fazer" ou que "sempre fizeram". Por isso a análise detalhada de requisitos e de aderência normalmente apontam para um "uma carroça mais rápida" ao invés de "um carro", como dizia Henry Ford, gerando milhões de parametrizações ou customizações sem sentido. Então é um jogo normalmente sem vencedores.

2 - Um processo passo a passo como o que você descreve, em uma empresa bem organizada, poderia funcionar sim - se não fosse por um outro probleminha. Pois é, ainda tem gente bem pior na fita aguardando a vez, e esse é o tema do próximo artigo, aguarde.

Abraços e muito obrigado!!!!

Marcelo

[Rômulo]

Olá Marcelo.
Até procurei em seus poats. Mas não encontrei. Gostariabde saver como foi sua experiência com a patente nos EUA.?