Embora o homem lide com projetos desde a construção das pirâmides do Egito, foi no século passado que o “schedule-driven projects” ganhou as estantes e academias para resolver o desafio da entrega de projetos complexos e que precisam rezar a cartilha do budget.
Os projetos espaciais da NASA, por exemplo, ganharam muito nos últimos 50 anos com metodologia e técnicas de gestão, apesar de hoje os “ônibus espaciais” estarem em desuso e a NASA não estar na sua melhor fase.
Depois de tantos anos de desenvolvimento e evolução na forma de lidar com projetos, ainda temos um cenário distante do ideal, principalmente, quando falamos de grandes projetos de TI como, por exemplo, os de implantação de ERPs (Enterprise Resource Planning).
Segundo uma pesquisa divulgada em 2012, a consultoria norte-americana, Panorama, divulgou que mais da metade destes projetos atrasam. A pesquisa abrangeu cerca de 2.000 empresas de 61 países, ao longo de seis anos (2006-2012).
E o motivo dos atrasos não advém principalmente da tecnologia dos produtos, mas sim, de aspectos ligados às pessoas. Funcionalidade e dificuldades técnicas totalizam menos de 20%, enquanto problemas organizacionais, mudanças de escopo, limitações de recursos humanos e dificuldades com a qualidade dos dados, totalizam mais de 65%.
Nos últimos 15 anos, tenho acompanhado de perto grandes projetos de TI aqui no Brasil e na Europa e o que alguns apontam como causas, na minha opinião, não passam de consequências de um processo mais longo e complexo. Os atrasos e estouros de orçamento estão neste grupo de consequências e não de causas.
Muitas empresas têm comprado de forma equivocada estes projetos. Tudo começa com a intenção de que o novo sistema, atenda TUDO o que o atual sistema ou sistemas não cobrem. Adicionalmente, as áreas de TI, veem o momento da escolha do novo sistema como uma oportunidade para que o backlog, lista de pendências de melhorias do sistema atual, seja incluído.
Nascem então, os primeiros grupos, conhecidos como comitês e que trabalham na escolha do sistema, que “abre a porteira” para que todos os usuários operacionais peçam tudo o que estava represado e escrevam todos seus desejos em um “caderno de requisitos”.
Quando este processo ganha complexidade, muitas empresas contratam consultorias especializadas em seleção de software, que adicionam à uma lista, novos requisitos de mercado, que representam as melhores práticas de negócios.
Ao final, temos uma RFP (Request For Proposa)l, em bom português, um pedido de proposta e tomada de preços, que inclui documentos anexos com milhares de perguntas sobre aquilo que o sistema deveria atender e como deveria atender. Quando digo milhares, não se trata de figura de linguagem. Dois mil ou mais requisitos é algo que se vê facilmente nos processos atuais.
Adicionalmente, os preços (principalmente no Brasil) precisam ser “FECHADOS”, segundo uma cultura que herdamos ou criamos em algum momento. Tenho visto recentemente o termo “EMPREITADA” aparecer com mais frequência, e isto, não me parece bom.
Aqui temos uma combinação explosiva: escopo complexo, preço fechado e uma “pretensa mitigação de risco”. Os processos de escolha de um novo ERP no Brasil, na verdade, não aliviam, e sim, transferem o risco para os fabricantes e empresas fornecedoras, que “descarregam” onde?
No preço, óbvio. Mas dirão os sábios: “A concorrência impede que os preços sejam uma válvula de escape e cada empresa “envidará” seus melhores esforços para orçar um projeto viável e competitivo”.
Isto acaba não ocorrendo em nenhum projeto complexo, mesmo quando falamos de concorrência pública. Se isso fosse verdade, por que encontramos as estradas públicas esburacadas e mal cuidadas, se o processo de escolha combinou a melhor qualidade com o menor preço?
Um projeto de serviços complexos, como é o caso da implantação de um novo sistema corporativo (ERP, Intranets, CRM, etc) não é equivalente a uma obra civil, naquilo que possa ser “preço-fechado”. Quando uma empreiteira executa uma construção, ela lida com obstáculos físicos, regulações ambientais e equipes dispersas.
No caso de um projeto complexo de TI, os usuários não podem ser “demitidos” e o cliente não pode ser duramente pressionado, afinal, é o cliente. Para que o projeto seja de “preço-fechado” ele precisa ter também o “escopo-fechado”, mas os requisitos técnicos e funcionais, representados pela RFP respondida, não são suficientes para definir o escopo.
O ambiente corporativo, grau de preparo dos usuários, cultura do cliente e disponibilidade de tempo das equipes, também interferem da velocidade e qualidade de entrega. Clientes e consultorias de sistemas precisam estabelecer as premissas de execução, que condicionam o bom andamento do projeto.
O problema é que a sequência com que este processo ocorre não ajuda em nada na definição de um bom projeto para o cliente. Se começa “inflando o escopo”, em que tudo deve ser exigido e previsível, como prazo e valores fechados, então se descobre que o projeto é caro e que as premissas de execução são muito duras, ou ainda, que o cliente deverá parar a empresa enquanto se dedica quase integralmente ao projeto, e com isso concluísse que não há chances de êxito.
Ao invés de administrar e reduzir os riscos, a forma como hoje é conduzida a escolha de um novo sistema corporativo, leva os clientes, fornecedores e fabricantes para uma zona de risco ampliada.
Quem discute o que é essencial para uma primeira fase de entrega? Qual gerente ou diretor de TI tem coragem de comprar um projeto estimado, com escopo simples e assumir a direção do projeto?
Por que o risco é terceirizado para os fornecedores? Quem disse que os requisitos da RFP retratam o que é realmente importante para o cliente e não refletem somente a manutenção do antigo com uma nova interface? A escolha leva tanto tempo, que os requisitos ficam obsoletos porque a empresa mudou e continua mudando...
Em geral, quando falamos com algumas empresas estrangeiras, a forma de trabalho é diametralmente oposta da prática daqui. O contratante sabe pedir e escreve um documento simples, normalmente intitulado “statament of work”, ou seja, um acordo de escopo de trabalho, em que os projetos são estimados com forte gestão interna do cliente, que avalia a qualidade da entrega e equipe.
Outra exigência é que os projetos sejam entregues em fases e com a filosofia “keep-it-simple”, na melhor intenção de não complicar, e com um planejamento de melhoria contínua, em fases, derivada do amadurecimento com o uso do sistema pelo cliente.
Tudo resolvido? Não! Mas é um bom começo para não continuarmos nos enganando sobre o que é gestão de projetos e o que é proteção dos nossos empregos, terceirizando um risco que não pode ser terceirizado.
*Alexandre Marques é empresário e sócio-fundador do Grupo i9. Trabalha há 21 anos na área de TI, 15 anos com ERP, CRM, Portais Corporativos e Projetos e Integração.