Como NÃO gerenciar projetos de ERP - Site Campus

Como NÃO gerenciar projetos de ERP

Como não gerenciar projetos de ERP

Quando você começa a gerenciar um projeto  de implantação de ERP, qual perfil você adota? Você se preocupa com a satisfação dele, trabalha com foco no cliente ou no dinheiro dele? Vamos abordar este tema polêmico: A maior parte dos projetos de implantação de ERP do mercado não possuem foco no cliente, apenas no dinheiro.

No artigo anterior falamos sobre levantamento de requisitos, passando dicas e informações para ajudá-lo nesta etapa.Vamos agora falar sobre os problemas que existem na gestão de projetos ERP, um projeto comum tanto em empresas pequenas como grandes.

Existem 3 tipos de gerentes de projetos:

  • Os que não gostam de métodos ágeis. Nunca usaram ou falharam uma vez e acham que os métodos não funcionam
  • Aqueles que acham que os métodos ágeis são a solução para qualquer problema e tentam ignorar completamente o modelo clássico
  • E aqueles que procuram combinar as práticas em busca da melhor solução para o projeto.

Independente do perfil, quando nos aprofundamos em qualquer uma das práticas veremos que nenhuma delas garante o sucesso do projeto ao ser utilizada. Mesmo um projeto que falhou pode ter sido gerenciado com sucesso.

O maior desafio do gerente de projetos é aceitar quando o projeto vai falhar e escolher a melhor decisão na hora certa.

Quando um projeto falha, o que acontece? Vamos ver como se comportam os 3 perfis acima:

  • Modelos Clássicos: A culpa é dos recursos, terceiros, administração. Como acredita que as práticas tradicionais são infalíveis, acredita que a culpa não é dele.
  • Modelos exclusivamente ágeis: A culpa acaba sendo sempre da falta de orçamento ou da equipe, alegando que as pessoas não sabem trabalhar. Utilizam o conceito de ‘falha rápida’ de maneira incorreta, desistindo do projeto logo nos primeiros indícios de problemas. Culpam também o cliente por não saber explicar o que quer (mas também não o ajuda a descobrir o que quer).
  • Métodos Híbridos: Procura avaliar todos os cenários do projeto, considerando a prática da equipe, os testes e a documentação existente. Avalia em conjunto com o time antes de tomar a decisão de cancelar um projeto, sem culpar alguém em específico.

Veja que, mesmo em modelos híbridos, a falha pode ocorrer. O fato de saber combinar bem as práticas do mercado não significa que trará sucesso ao seu projeto. Porém combinar técnicas o ajudará com mais informações para a melhor tomada de decisão. Além disso, em projetos híbridos, o gerente de projetos acredita no seu time. Sabe a capacidade de entrega dele, sabe o que motiva o time. Um time motivado poderá entregar mais em menos tempo pois estará trabalhando a favor do projeto.

Você foca no cliente ou no dinheiro dele?

Quando você entra na carreira de gerente de projetos, certamente seu primeiro projeto será um clássico, seguindo o PMBOK. Você pensa que pode gerenciar todos os projetos que existem simplesmente por conhecer bem o guia. Acham que conhecer o produto é desnecessário, que basta seguir as etapas escritas no guia.

Vamos usar como exemplo os projetos de implantação de sistemas ERP.
Black Week Site Campus

Um ERP possuí diversas funcionalidades para controle da empresa, desde emissão de notas fiscais, controle de estoque, sistemas contábeis, entre outros. A configuração dele varia de cliente para cliente, mesmo na essência sendo o mesmo produto.

Sem a devida integração na equipe, o Gerente de Projetos pode cometer erros na hora do planejamento deste tipo de projetos.

O Programador pode querer a solução mais simples. O vendedor do ERP pode apenas querer vender os recursos mais lucrativos. Cada um pensa apenas em sí mesmo: Querem ser o melhor técnico, o melhor programador, o melhor vendedor.

Chega então o momento em que o Gerente de Projetos não está entregando valor e sim apenas buscando o lucro, o projeto com maior retorno ao invés da maior qualidade.

Guerra de Contratos em Projetos de ERP

No meio de toda esta confusão, o Gerente de Projetos começa a ver seu projeto cada vez pior. O cliente não recebe o valor que esperava, começa a não querer mais pagar o trabalho ou ainda os recursos que pediu não funcionam bem.

Nesta hora, ao invés de se preocupar com a satisfação do cliente, vão buscar os contratos e as cláusulas contratuais. Nesta hora querem cobrar mais por recursos que o cliente tinha entendido que teria, se preocupando mais com o valor/hora do que com a satisfação do cliente. Vendeu mais horas? Então o projeto é um sucesso!

Quando o cliente pede um relatório que não estava incluso, mas deveria, o que acontece? Vende mais horas, cobra mais. O importante neste momento é cobrar mais e esquecer da satisfação do cliente com o sistema implantado.

Como o Gerente de Projetos está agindo com os métodos clássicos, acredita no registro das informações ao longo do projeto, formalizando tudo o que o cliente pediu. Se não pediu, se não está no documento, não está incluso, então deve ser cobrado.

O projeto deu errado? Culpa do cliente que não soube explicar o que queria. Culpa da equipe que não soube desenvolver o que precisava. Mas nunca culpa do Gerente pois ele seguiu os métodos…

No fim, depois de muita discussão, o cliente acaba pagando novamente para ter o que ele queria no início. A certeza é uma só: Ele pode até receber o que queria, mas não comprará mais nada da mesma empresa.

Mas e quanto ao vendedor do projeto?

Na hora do aperto, o cliente chama o vendedor para discutir os termos “achei que estava incluso”. Nesta hora, o vendedor já não está mais na empresa, não faz mais parte da equipe ou não está disponível.

Ao mesmo tempo que o cliente quer desistir, ele percebe que já gastou muito com o projeto. Nesta hora ele se vê obrigado a investir ainda mais no projeto.

Neste  momento aparece o vendedor para assinar os contratos novos e a empresa acha que o projeto é um sucesso por ter vendido mais antes mesmo do final. Tudo errado!

Mas então o que devemos fazer?

Existe no próprio PMBOK a recomendação de planejamento por ondas sucessivas, uma prática adotada pela maior parte (se não, todos) métodos ágeis existentes. Você não precisa saber no começo do projeto que o cliente precisará do módulo X porque a regra dele pode mudar. Você tem que estar preparado pela mudança ao longo do projeto, entregando o que é realmente importante pra ele.

No momento da compra do projeto, ele pode não precisar de um módulo Fiscal mas meses depois do início do projeto a condição fiscal dele pode mudar, precisando então do módulo. Precisamos nos adaptar a esta situação e negociar.

Existem modelos de contrato com escopo fixo por sprint. Ou seja, eu cobro conforme o que for acordado com o cliente para a próxima entrega. Não preciso fechar o escopo no início do projeto e cercar isso no contrato.

Existe a barreira dentro da própria empresa onde o Gerente de Projetos atua. O mundo está mudando mas muitas empresas querem continuar como estão simplesmente porque o modelo funciona há muito tempo. Não adianta. Você gera desperdício e insatisfação apenas por acreditar que seu modelo é único e correto.

Para os casos de implantação de sistemas ou ERP, a melhor sugestão é quebrar a necessidade do cliente em fases. Levante os requisitos iniciais, monte o planejamento para as próximas 3, 4 sprints e adeque o contrato para este cenário. Você entregará o valor antecipadamente, trazendo os recursos mais importantes pra ele no início e depois buscará entregar os recursos seguintes.

Gostaram do artigo? O objetivo do projeto é alertar que mesmo com métodos atuais ou híbridos, precisamos ter foco no valor do projeto. Usar os métodos novos mas com velhas práticas não trará o sucesso esperado. Lembre-se que modelos de gestão são ferramentas, práticas que usamos em conjunto com nossas habilidades. Se vamos usar as melhores práticas, temos que usar as melhores habilidades.

Clique aqui e veja uma aula em que apresentamos dicas para você crescer de nosso curso livre Seja Você o Líder – faça esta aula gratuitamente e aprenda mais!


#
Compartilhe!
Fale com o Site Campus

Tags: , , , ,