Propostas comparáveis começam com uma descrição clara do trabalho: 12 informações que vale a pena fornecer

O atual Sourcing Playbook do Reino Unido afirma que uma especificação clara deve fornecer aos concorrentes informação suficiente para decidirem de forma informada se querem apresentar proposta. O documento também observa que, sem uma compreensão comum dos requisitos, é difícil relacionar os preços propostos com os custos e resultados esperados pelo comprador. [1]

A Government Commercial Function coloca a questão de forma ainda mais direta: uma boa especificação deve conter informação suficiente para os fornecedores calcularem corretamente os custos e para o comprador poder comparar propostas numa base equivalente. [2]

Ao mesmo tempo, o Digital, Data and Technology Playbook britânico alerta contra a definição excessiva da solução. Recomenda focar o utilizador, o problema e o resultado esperado, deixando espaço para os fornecedores proporem uma forma eficaz de o alcançar. [3]

A conclusão não é "descreva tudo com o máximo de detalhe possível". Uma regra melhor é:

descreva com precisão aquilo que tem de ser comum a todas as propostas, não aquilo que um especialista competente pode razoavelmente conceber por si.

Duas propostas profissionais nunca serão idênticas, e esse não deve ser o objetivo.

Comparabilidade significa que os especialistas respondem ao mesmo problema com premissas aproximadamente semelhantes.

Devem, por isso, ter uma compreensão semelhante de:

• objetivo,
• âmbito,
• ponto de partida,
• resultado esperado,
• limitações importantes,
• prazo,
• responsabilidades do cliente,
• forma de apresentar o preço,
• critérios usados para avaliar a proposta.

Podem, no entanto, diferir em:

• abordagem proposta,
• ordem das atividades,
• método,
• composição da equipa,
• ferramentas,
• divisão em etapas,
• forma de reduzir o risco.

Estas diferenças têm frequentemente valor e devem continuar visíveis.

Comece pelo problema, não por uma lista de funcionalidades.

Em vez de:

"Preciso de uma aplicação com painel, notificações e relatórios."

tente:

"Atualmente cinco pessoas gerem o processo através de folhas de cálculo e correio eletrónico. É difícil ver o estado atual de cada caso, quem é responsável e qual é a próxima tarefa. Queremos reduzir o acompanhamento manual e ter um único local com o estado atualizado."

A segunda descrição ainda não decide que aplicação deve ser construída.

Mas ajuda o especialista a compreender porque é que o projeto existe.

A Federal Acquisition Regulation para serviços baseados em resultados recomenda descrever o trabalho principalmente através dos resultados exigidos, e não pela forma de execução ou pelo número de horas. A sua declaração mínima de objetivos inclui elementos como finalidade, âmbito, contexto, resultados necessários e limitações operacionais. [4]

Por isso, descreva o que deverá ser possível quando o trabalho terminar.

Por exemplo:

• um utilizador consegue concluir sozinho um processo definido,
• a equipa consegue consultar o estado atual de todos os casos,
• o cliente recebe uma análise com prioridades,
• o sistema é transferido para um novo ambiente e funciona segundo critérios acordados,
• o material preparado está pronto para publicação num canal definido.

O resultado deve ser suficientemente concreto para que ambas as partes compreendam a direção do trabalho.

Não precisa de significar uma garantia de resultado comercial que dependa do mercado, do comportamento dos utilizadores ou de outros fatores fora do controlo do fornecedor.

A mesma necessidade final pode exigir esforços muito diferentes consoante o ponto de partida.

É útil indicar:

• o que já existe,
• o que funciona e deve ser preservado,
• o que não funciona,
• se existem ficheiros fonte,
• se existe documentação,
• se há dados a migrar,
• se é necessário trabalhar sobre um sistema existente,
• que materiais já estão prontos.

"Um novo site" pode significar construir de raiz ou reconstruir um site existente preservando conteúdos, endereços, análise, integrações e dados.

São trabalhos diferentes, mesmo que o resultado visual final possa parecer semelhante.

O âmbito não deve obrigar os especialistas a adivinhar que partes do problema devem avaliar.

Por exemplo:

Incluído:

• análise da solução atual,
• design de novas vistas,
• implementação,
• migração de uma parte definida dos dados.

Fora do âmbito:

• criação de novos conteúdos,
• compra de licenças,
• manutenção após o primeiro mês,
• reconstrução do sistema de pagamentos.

O exemplo de Terms of Reference do Banco Mundial sublinha que os requisitos e expectativas dos serviços devem ser claramente articulados e adaptados ao projeto concreto. [5]

Os limites são especialmente importantes quando duas tarefas estão naturalmente relacionadas e seria fácil presumir que uma inclui a outra.

Se espera materiais ou resultados concretos, identifique-os.

Podem incluir:

• uma solução funcional,
• ficheiros fonte,
• um relatório,
• documentação,
• design visual,
• um conjunto de materiais,
• configuração de ambiente,
• formação,
• gravação,
• transferência do código e acessos.

Palavras como "design", "análise" ou "implementação" podem ser interpretadas de formas diferentes.

Uma lista comum dos principais elementos a entregar ajuda a evitar que uma proposta inclua muito mais do que outra, mas que essa diferença fique escondida sob nomes de serviço semelhantes.

Nem toda a limitação é um detalhe técnico.

Podem ser relevantes, por exemplo:

• um sistema ou ambiente obrigatório,
• integração necessária com um serviço específico,
• requisitos de acessibilidade,
• regulamentação setorial,
• restrições de armazenamento de dados,
• necessidade de manter a infraestrutura atual,
• dispositivos ou navegadores específicos,
• trabalho em horários definidos,
• acesso limitado aos dados.

A FAR inclui explicitamente limitações operacionais na declaração de objetivos, enquanto o Digital, Data and Technology Playbook britânico mostra por que não se deve impor uma solução quando não existe uma limitação real. [4] [3]

Uma boa regra:

indique aquilo que o especialista não pode alterar, mas não invente uma limitação apenas porque está habituado a uma determinada solução.

O especialista deve saber em que nível de colaboração pode basear a proposta.

Indique se irá disponibilizar:

• uma pessoa com poder de decisão,
• acesso aos sistemas,
• materiais existentes,
• dados,
• contas de teste,
• informações da equipa,
• acesso a utilizadores,
• conteúdos,
• reuniões regulares,
• respostas dentro de um prazo definido.

Se ainda não sabe o que poderá fornecer, também vale a pena dizê-lo.

A falta de acesso a dados, materiais ou pessoas pode alterar o método, o custo e o prazo. Não é um pequeno detalhe administrativo. Faz parte das condições em que a proposta é construída.

Nem todas as datas têm o mesmo significado.

Distinga entre:

• data preferida de início,
• prazo improrrogável,
• data ligada a um acontecimento externo,
• data indicativa,
• etapas que têm de ocorrer numa determinada ordem.

Se um prazo realmente não puder mudar, explique porquê.

Se for flexível, diga também.

Assim, o especialista pode propor outro âmbito, outra ordem ou uma execução por etapas, em vez de assumir que todas as datas são exigências absolutas.

Não existe uma regra única segundo a qual o cliente deve sempre revelar o orçamento total.

Consoante a situação, pode indicar:

• orçamento máximo,
• intervalo de orçamento,
• orçamento para a primeira etapa,
• que primeiro pretende uma proposta de âmbito e só depois o preço,
• estrutura esperada para a decomposição do preço.

Para comparar, o mais importante é que os especialistas apresentem os custos numa estrutura semelhante.

Por exemplo:

"Indique separadamente o preço de análise, design, implementação e manutenção mensal. Identifique também os custos de serviços externos que não estão incluídos."

Este formato é muito mais fácil de comparar do que quatro valores totais em que cada um inclui coisas diferentes.

A incerteza não desaparece só porque não foi escrita.

Se não sabe:

• quantos dados será necessário migrar,
• se uma interface externa permite a operação necessária,
• se todos os conteúdos estarão prontos,
• se o código atual pode ser razoavelmente desenvolvido,
• se uma aprovação necessária será obtida a tempo,

diga-o.

O guia do GAO sobre estimativas fiáveis de custos destaca a importância de premissas explícitas e da análise do risco e da incerteza. [6]

Um bom especialista pode então:

• incluir uma reserva,
• propor uma etapa de diagnóstico,
• avaliar variantes,
• indicar uma condição que alteraria o preço,
• recusar fingir uma precisão que ainda não pode ser alcançada de forma honesta.

Uma incógnita explícita é melhor do que uma premissa escondida.

Se já sabe o que será importante na decisão, diga-o antes de as propostas serem preparadas.

Pode avaliar:

• adequação da abordagem proposta,
• experiência com problemas semelhantes,
• qualidade das provas de trabalho anterior,
• realismo do calendário,
• disponibilidade,
• forma de gerir o risco,
• competências das pessoas que irão efetivamente trabalhar no projeto,
• preço,
• custo de manutenção,
• qualidade da comunicação.

A orientação atual do Banco Mundial sobre Rated Criteria indica que critérios não relacionados com o preço podem incluir a qualidade da metodologia e do plano de trabalho, gestão do risco, capacidade de execução e pessoal-chave. Os critérios são adaptados ao projeto e ponderados segundo a sua importância relativa. [7]

Isto não significa que um pequeno trabalho precise de pontuação formal.

Basta conseguir responder antes de enviar o pedido:

"O que, além do preço, faria uma proposta ser melhor para mim do que outra?"

Se quer realmente comparar propostas, peça a todos que respondam ao mesmo conjunto básico de perguntas.

Por exemplo:

1. Como entende o problema e o resultado esperado?
2. Que abordagem propõe?
3. O que inclui exatamente a sua proposta?
4. O que fica excluído?
5. Que premissas está a assumir?
6. Qual é o calendário?
7. De que precisa do cliente?
8. Quais são os principais riscos?
9. Qual é o preço e o que inclui exatamente?
10. Que experiência ou provas de trabalho semelhantes são relevantes para este projeto?

Na contratação pública, a normalização das respostas, critérios e formatos de preço serve precisamente para permitir que as propostas sejam avaliadas numa base comum. A Government Commercial Function destaca a necessidade de fornecer informação suficiente para um cálculo correto e uma comparação equivalente. [2]

Um formato comum não deve apagar as diferenças entre especialistas. Deve apenas tornar essas diferenças visíveis nos mesmos pontos.

Depende do objetivo do pedido.

Partilhar o orçamento pode ajudar quando:

• o âmbito pode ser ajustado aos recursos disponíveis,
• pretende uma recomendação para a melhor opção dentro de um limite definido,
• quer eliminar rapidamente propostas incompatíveis com a realidade financeira do projeto.

Não partilhar o orçamento completo pode fazer sentido quando:

• primeiro pretende uma visão independente sobre o âmbito adequado,
• ainda não conhece o custo realista,
• está a comparar diferentes modelos de solução,
• o processo exige outra forma de recolher preços.

O pior cenário não é necessariamente não indicar orçamento, mas não explicar que tipo de resposta de preço espera.

O especialista deve saber se deve apresentar um valor único, intervalo, variantes, preço por etapas ou premissas necessárias para uma estimativa mais precisa.

Uma boa descrição do trabalho não precisa de responder a todas as perguntas.

Pode dizer honestamente:

• "Ainda não sabemos se o sistema atual pode ser desenvolvido com segurança.",
• "Não sabemos o número exato de registos que terão de ser migrados.",
• "Ainda não decidimos se a segunda versão linguística faz parte da primeira etapa.",
• "Precisamos de ajuda para escolher a melhor opção."

É informação valiosa.

A incerteza deve influenciar a forma como a proposta é preparada, não desaparecer do documento.

Em algumas situações, o melhor primeiro serviço não é a execução completa, mas uma curta etapa de diagnóstico que termina com uma decisão, um âmbito mais preciso ou uma estimativa mais fiável.

1. Dar a cada especialista um conjunto diferente de informações.

2. Enumerar funcionalidades sem explicar o problema e o objetivo.

3. Não indicar o que já existe.

4. Esconder limitações que mais tarde alteram a forma de execução.

5. Pedir um único preço final sem explicar o que deve incluir.

6. Avaliar propostas segundo critérios que nem o próprio cliente definiu antecipadamente.

7. Confundir uma descrição detalhada do problema com a imposição detalhada da solução.

1. Descrevi claramente o problema e não apenas a solução que imaginei?
2. Está claro o resultado que quero alcançar?
3. O especialista compreende o estado atual?
4. Está claro o que deve ser preservado?
5. Os limites do primeiro âmbito são claros?
6. Indiquei os principais elementos a entregar?
7. Indiquei as limitações reais?
8. Está claro o que vou fornecer do meu lado?
9. O prazo está descrito juntamente com a sua flexibilidade?
10. O formato do preço permitirá comparar propostas?
11. Descrevi abertamente as principais incógnitas?
12. Sei o que vou avaliar além do preço?
13. Todos os especialistas vão responder a um conjunto semelhante de perguntas?
14. Deixei espaço para uma solução melhor do que aquela que eu próprio imaginei?

Uma boa descrição do trabalho tem dois objetivos aparentemente opostos.

Deve ser suficientemente concreta para que vários especialistas avaliem o mesmo problema.

Ao mesmo tempo, deve ser suficientemente aberta para cada um poder propor a sua própria abordagem, possivelmente melhor.

Uma ordem útil é:

problema -> resultado -> estado atual -> âmbito -> elementos a entregar -> limitações -> responsabilidades do cliente -> prazo -> formato do preço -> incógnitas e riscos -> critérios de escolha -> formato comum de resposta.

Se, depois de receber as propostas, descobrir que uma pessoa avaliou o projeto completo, outra apenas a análise e uma terceira assumiu integrações adicionais, o problema pode não estar nos orçamentos.

Talvez cada pessoa tenha recebido um trabalho diferente, mesmo tendo sido enviado o mesmo texto a todos.

[1] UK Government - The Sourcing Playbook
Abrir fonte

[2] Government Commercial Function - How to write a procurement specification
Abrir fonte

[3] UK Government - The Digital, Data and Technology Playbook
Abrir fonte

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Abrir fonte

[5] World Bank - Sample Consultants Terms of Reference
Abrir fonte

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Abrir fonte

[7] World Bank - Rated Criteria
Abrir fonte

Nota metodológica: as fontes vêm sobretudo da contratação pública e da gestão de custos. Não são apresentadas como regras diretamente aplicáveis a um mercado privado de especialistas. O artigo utiliza apenas os princípios que efetivamente sustentam: clareza dos requisitos, foco nos resultados, premissas e riscos explícitos, informação de preços comparável e avaliação da qualidade com critérios para além do preço.