Sabemos que os contratantes e contratados (compradores e fornecedores) são partes interessadas uns dos outros. Porém, esses relacionamentos nem sempre recebem a atenção que merecem. O resultado pode ser desastroso, como veremos ao longo do post em um caso que resultou em processo judicial. O assunto stakeholders e aquisições está intimamente relacionado com nosso post anterior (“pensar como um gerente de projetos”).

Algumas coisas são difíceis de ensinar. É o chamado conhecimento tácito (know how / knowing), diferente do conhecimento explícito (knowledge). O conhecimento tácito vem da experiência, é o saber fazer. Já o explícito está sistematizado, podendo ser escrito ou não. Por exemplo, conhecimento explícito seria uma receita de como fazer uma torta de maçã. Não sabe como fazer? Vá ler a receita neste link. A receita inclui um passo-a-passo de misturar ingredientes e por aí vai. Mas por que a torta da minha avó fica boa e a minha não, se estamos seguindo a mesma receita?! Por causa do conhecimento tácito, que não dá para tirar da cabeça dela e colocar na sua.

Por isso, não adianta reclamar que as metodologias de gerenciamento de projetos não funcionam. Ler o Guia PMBOK e outros livros somente proporciona conhecimento explícito. É a experiência que vai trazer conhecimento tácito, como colocar em prática Isso envolve pequenas nuances e outras questões contingenciais difíceis de explicar.

Em se tratando do gerenciamento de suprimentos, especificações e aquisições em projetos, a dor de cabeça pode ser ainda maior. Em alguns projetos, existe uma rede de fornecedores com vários níveis (subcontratados). Por outro lado, como defendemos no framework (neste post) de gerenciamento de stakeholders como clientes (livro), é função do gerente do projeto extrair as informações necessárias das partes interessadas.

Recentemente, a Oracle e a Universidade de Montclair chegaram a um acordo em um processo judicial de mais de 3 anos a respeito de um projeto de implantação de ERP (Enterprise Resource Planning) de 2009! Vejam as notícias sobre o caso na Information Week e na Computer World. Obviamente, houveram erros e falhas tanto da parte do cliente (Montclair) quanto do fornecedor (Oracle), pelo que indica o processo judicial. Entretanto, penso que muitas disputas (veja aqui alguns dos maiores fracassos na implantação de ERP) seriam evitadas com um melhor gerenciamento de partes interessadas.

Primeiramente, as responsabilidades precisam ser muito bem definidas. Não existe nada pior do que incerteza, zonas cinzentas. O cliente acha que o fornecedor vai fazer algo, mas o fornecedor acredita que não faz parte das suas responsabilidades fazer esse “algo”.

Figura 1 – Fluxo de aquisições a partir do cliente

Atuando na parte do cliente, eu procuro especificar bem o que desejo, de modo que não receba coisas que não quero e também de maneira que não faltem coisas que considero essenciais. Todavia, como percebi ao longo do tempo, os clientes, na grande maioria, desconhecem os detalhes daquilo que estão comprando, o que torna difícil para eles criar uma especificação detalhada.

O caso Montclair vs Oracle ilustra bem isso. A universidade de Montclair tinha um problema, que podemos definir como: desejamos gerenciar efetivamente nossos recursos utilizando um software confiável. Então eles contrataram a Oracle, uma empresa tradicional e respeitada neste mercado. Provavelmente, o pessoal da Montclair não sabia exatamente as implicações que um novo ERP teria, tais como:

• (re)definição e adequação de processos;
• funcionalidades necessárias / desejadas;
• treinamento;
• infraestrututra, etc.

O pessoal da Oracle, que já realizou vários desses projetos em clientes com maturidades diferentes, deveria saber das dificuldades e orientar o cliente, deixando bastante claro o que faz parte do escopo do projeto e o que não faz. Além disso, a Oracle poderia ter indicado quais seriam as responsabilidades do cliente explicitamente. Como não sei os detalhes, não posso dizer se houve erro ou não nesta parte. O que fica claro pelas reportagens em torno do caso é que cliente e fornecedor passaram a se culpar mutuamente por atrasos, falhas e outros problemas durante a implantação do ERP. Talvez, com uma atitude mais proativa dos gerentes de projetos de ambos os lados, utilizando um gerenciamento efetivo de stakeholders, as organizações tivessem buscado maneiras de colaborar para resolver os problemas, em vez de culparem-se mutuamente.

Outro ponto importante é a escolha do tipo de contrato, ou negócio jurídico bilateral, e suas cláusulas. O tipo e os termos e condições específicas do contrato usado definem o grau de risco que está sendo assumido pelo comprador e pelo fornecedor. Nos projetos, os contratos costumam ser dividos em:

• Contratos de Custos Reembolsáveis (CR) – Cost reimbursable;

Neste tipo de contrato, os custos do fornecedor são reembolsados, acrescidos de um valor adicional. O comprador tem um grande risco neste tipo de contrato pois se desconhece os custos finais do contrato. Obviamente, é possível incluir incentivos e faixas para limitar os custos mínimo e máximo do contrato.

• Contratos de Tempo e Material (T&M) – Time and material; e,

Este tipo de contrato se baseia em um custo por unidade (hora, material etc). Ele apresenta elementos de um contrato de preço fixo (no preço fixo por unidade) e elementos de contratos de custos reembolsáveis (o custo total é desconhecido, embora possa ser colocado um limite).

• Contratos de Preço Fixo (PF) – Fixe Price (FP).

Costuma ser tipo de contrato mais comum. Neste tipo de contrato um preço fechado é acordado para o projeto como um todo. É um contrato de grande risco ao fornecedor, pois se existirem custos adicionais terão que ser assumidos por ele. Por outro lado, se o cliente não especificar bem aquilo que deseja, terá grandes problemas (risco). Já nos contratos de custos reembolsáveis, é possível fazer mudanças nas especificações ao longo do tempo, enquanto que nos contratos de preço fixo as alterações geralmente envolvem aditivos.

Figura 2 – Modalidades de contrato

Finalmente, vale a pena revisitar a figura abaixo sobre o gerenciamento de stakeholders.

Figura 3 – Gerenciamento dinâmico de stakeholders

Infelizmente, chegamos ao final do post. É um assunto interessantíssimo e que demanda mais tempo e conteúdo. Além disso, é extremamente importante para os gerentes de projetos conhecer os aspectos importantes dos contratos, já que estarão envolvidos e sujeitos à eles (eu, particularmente, resolvi fazer Direito depois da graduação em Engenharia…). Voltaremos ao gerenciamento de aquisições em outros posts. Até lá!