RFP per un progetto software: come scriverla per ricevere preventivi comparabili

Se ogni fornitore interpreta a modo suo cosa gli hai chiesto, i preventivi che ricevi non sono comparabili. Una RFP scritta bene risolve il problema alla radice.

7 ottobre 2026 · 7 min


Il motivo più comune per cui tre preventivi software sono impossibili da confrontare non è che i fornitori siano disonesti: è che hanno risposto a tre domande leggermente diverse, perché la richiesta di partenza lasciava troppo all’interpretazione di ciascuno. Una RFP (richiesta di offerta) scritta bene non serve a impressionare i fornitori: serve a farti ricevere risposte alla stessa domanda.

Cosa deve contenere, punto per punto

  1. Contesto e obiettivo di business. Non solo cosa vuoi costruire, ma perché — quale problema risolve, per chi. Aiuta i fornitori a proporre soluzioni, non solo a eseguire una lista.
  2. Perimetro funzionale. Funzione per funzione, non un titolo generico. Se scrivi “gestionale ordini”, ogni fornitore lo riempirà con assunzioni diverse.
  3. Vincoli tecnici noti. Sistemi esistenti da integrare, infrastruttura obbligata, requisiti di sicurezza o normativi già noti.
  4. Tempistiche attese, con eventuali vincoli non negoziabili (una scadenza commerciale, un evento fisso).
  5. Budget indicativo, anche a range. Ometterlo del tutto non protegge la trattativa: produce solo preventivi tarati su ipotesi diverse, impossibili da confrontare.
  6. Criteri di valutazione. Cosa peserà nella scelta — prezzo, referenze, tempi, competenza tecnica — e con che peso relativo. Dichiararlo in anticipo alza la qualità delle proposte che ricevi.
  7. Formato di risposta richiesto. Stesse sezioni per tutti, comprese ipotesi ed esclusioni esplicite. È quello che rende i preventivi finalmente confrontabili voce per voce.

L’errore più comune: scrivere la soluzione invece del problema

Una RFP che descrive già l’architettura tecnica desiderata (“vogliamo un’app in React con backend su Node”) toglie ai fornitori lo spazio per proporre l’approccio migliore — e a te la possibilità di scoprire soluzioni più adatte o più economiche. Descrivi il problema da risolvere e i vincoli reali; lascia la soluzione tecnica a chi la propone, valutandola come parte dell’offerta.

Quanto deve essere lunga

Non conta la lunghezza, conta l’assenza di ambiguità. Una pagina densa e precisa vale più di venti pagine generiche. Se un fornitore può leggerla e farti due o tre domande di chiarimento mirate, hai scritto una buona RFP. Se non fa domande, probabilmente non l’ha letta con attenzione, oppure l’ha interpretata a modo suo — in entrambi i casi è un segnale da non ignorare.

Come si confrontano le risposte

Metti le offerte in una tabella con le stesse voci della RFP, non con la struttura che ciascun fornitore ha scelto per la propria proposta. Dove un fornitore ha risposto e un altro no alla stessa voce, hai trovato una domanda di chiarimento da fare prima di decidere — non un dettaglio da ignorare.

In sintesi

Una RFP ben scritta sposta il lavoro di chiarimento prima dell’offerta, non dopo la firma: descrive il problema, i vincoli e i criteri di valutazione in modo che ogni fornitore risponda alla stessa domanda. Il tempo speso a scriverla bene si ripaga nella prima ora di confronto tra preventivi finalmente comparabili.

Hai un progetto o un fornitore da rimettere in riga?

La Diagnosi Progetto IT parte da qui: 5 giorni, prezzo fisso, a rischio zero.

Altri articoli