RFP Software: Come Ottenere Preventivi Confrontabili

Una RFP software, cioè una richiesta di offerta, dovrebbe rendere i fornitori confrontabili. La maggior parte ottiene l’effetto opposto, perché descrive una soluzione in modo abbastanza dettagliato da vincolare la risposta e insieme omette le informazioni che chiunque userebbe per quotarla. Il risultato sono cinque preventivi distanti un ordine di grandezza, tutti formalmente conformi, e nessuno che misuri la stessa cosa.

La diagnosi consueta è che i fornitori siano evasivi. Ogni tanto è vero. Molto più spesso il documento ha chiesto un numero che dal suo contenuto non si poteva ricavare, e ogni fornitore ha riempito i vuoti con ipotesi diverse.

La prova che dice se la vostra RFP funzionerà: due fornitori diversi potrebbero leggerla e arrivare in sostanza allo stesso perimetro? Se un documento scrive «gestione utenti» senza indicare quanti ruoli esistono, se i permessi cambiano per singolo record o se serve un aggancio a una directory già presente, uno quota una settimana e l’altro due mesi. Rispondono entrambi onestamente. Voi non potete confrontarli.

Perché un elenco di funzioni è il punto di partenza sbagliato

Un elenco di funzioni dice al fornitore che cosa avete deciso, non che cosa vi serve. Conta, perché la decisione può essere sbagliata, e chi se ne accorge non ha modo di dirlo dentro la struttura che gli avete imposto.

Nasconde inoltre proprio le informazioni che determinano il costo. Nel software lo sforzo sta nelle parti scomode: quanti sistemi esterni bisogna collegare, quanti dati esistenti vanno migrati e in che stato sono, quanti tipi distinti di utente con permessi differenti esistono e quali sono gli obblighi normativi. Un elenco di funzioni può essere lunghissimo e non contenere niente di tutto questo.

L’alternativa non è la vaghezza. Descrivete il problema con precisione, dichiarate i vincoli davvero fissi e lasciate che sia la proposta a spiegare l’approccio. Otterrete risposte diverse fra loro, e le differenze saranno informative invece che rumore.

Che cosa dovrebbe contenere davvero una RFP software

Il problema di business e che cosa significa riuscire. Che cosa succede oggi, che cosa dovrebbe succedere al suo posto e da che cosa capirete che ha funzionato. I fornitori usano questa parte per mettere in discussione il perimetro, che è la cosa più preziosa che possano fare in questa fase.

Volumi e scala, con i numeri. Utenti, transazioni, record, crescita attesa. Solo questo elimina buona parte della varianza fra i preventivi.

I sistemi da collegare, indicati per nome, con una nota su quali abbiano un’interfaccia documentata. Una sola integrazione con un sistema legacy privo di documentazione può costare più di tutto il resto messo insieme.

I dati che avete già. Quanti sono, dove risiedono e in che condizioni si trovano. La migrazione è regolarmente la voce più sottostimata di qualsiasi progetto.

I vincoli davvero fissi. Obblighi normativi, una localizzazione di hosting imposta, un fornitore di identità già in uso, una data inamovibile. Dite quali sono rigidi e quali sono preferenze, perché i fornitori quotano i vincoli rigidi in modo difensivo.

Che cosa non state chiedendo. Escludere le cose in modo esplicito è uno dei modi più economici per ridurre la varianza fra i preventivi.

La vostra fascia di budget. Tenerla nascosta non fa scendere il prezzo. Produce proposte dimensionate su un budget che nessuno conosce, che poi vanno rifatte. Una fascia dichiarata permette ai fornitori di dirvi che cosa ci sta dentro. La nostra guida ai costi dello sviluppo software su misura spiega che cosa compra ogni fascia.

Le domande che distinguono i fornitori

Fate meno domande, ma migliori. Queste rivelano più di una matrice di conformità da cento righe.

Che cosa costruireste per primo, e perché? La sequenza mostra se hanno capito il problema o soltanto il documento.

Qual è la parte più rischiosa e come la ridurreste? Un fornitore che nomina un rischio reale è più affidabile di uno che non ne segnala nessuno.

Chi farà materialmente il lavoro? Nomi, seniority e quanta parte del loro tempo. Una proposta scritta da persone che poi non la realizzeranno è una delusione che si ripete.

Che cosa succede quando il perimetro cambia? Cambierà. La risposta vi dice come funziona il rapporto sotto pressione, che conta più della tariffa giornaliera.

Che cosa vi serve da noi? I progetti falliscono per indisponibilità lato cliente almeno quanto per incapacità del fornitore, e chi lo dice sta descrivendo la realtà invece di vendere.

Che cosa possediamo alla fine? Codice, infrastruttura, account, dati. Mettetelo per iscritto prima della selezione, non dopo.

Come leggere le risposte

Il preventivo più basso di solito riflette l’interpretazione più stretta del perimetro, non la maggiore efficienza, e lo scarto riemerge sotto forma di richieste di modifica appena il lavoro è partito.

Guardate dove ciascun fornitore ha messo la fatica. Una proposta che dedica la sua lunghezza all’integrazione e alla migrazione dei dati ha capito dove sta la difficoltà. Una che la dedica alla metodologia e alle foto del team non si è confrontata con il problema.

Trattate le obiezioni non richieste come un segnale positivo. Un fornitore che dice che una parte del vostro perimetro è superflua, o che un vincolo dichiarato costerà più di quanto valga, sta facendo esattamente il lavoro che volete. I fornitori che sono d’accordo su tutto sono più facili da leggere e peggiori con cui lavorare.

E verificate che ogni preventivo risponda alla stessa domanda. Dove due differiscono di un fattore tre, uno dei due ha dato per scontato qualcosa che il documento non diceva, e scoprire quale è più utile di qualunque griglia di punteggio.

Quando è meglio non farne una

Se il lavoro è piccolo, o esplorativo, o se non sapete ancora che cosa vi serve, la RFP è lo strumento sbagliato. Costa settimane a entrambe le parti e produce una falsa impressione di precisione.

In quei casi conviene di solito un incarico di discovery a pagamento: un lavoro breve che produce una specifica da portare poi sul mercato, oppure che stabilisce che la cosa non vale la pena. Entrambi gli esiti battono una gara su un perimetro che nessuno sapeva definire. La disciplina di perimetrazione della nostra guida allo sviluppo di MVP si applica in modo diretto.

Mecanik risponde alle RFP e aiuta anche le organizzazioni a scriverle, come parte del nostro lavoro di sviluppo software. I documenti che producono buoni preventivi sono in modo costante quelli più corti, con dentro numeri veri.

Domande frequenti

Che cosa deve contenere una RFP software? Il problema di business e che cosa significa riuscire, volumi e scala con numeri veri, i sistemi da integrare indicati per nome e con la nota su quali abbiano un’interfaccia documentata, lo stato dei dati da migrare, quali vincoli sono davvero fissi, che cosa resta esplicitamente fuori perimetro e una fascia di budget.

Devo indicare il budget nella RFP? Sì. Tenerlo nascosto non fa scendere il prezzo, produce proposte dimensionate su un budget che nessuno conosce e che poi vanno rifatte. Una fascia dichiarata permette ai fornitori di dirvi che cosa è realisticamente fattibile al suo interno e rende le risposte confrontabili.

Perché i preventivi per lo stesso software variano così tanto? Di solito perché il documento ha lasciato dei vuoti e ogni fornitore li ha riempiti con ipotesi diverse. Una riga come «gestione utenti», senza indicazione sul numero di ruoli, sui permessi per singolo record o sull’aggancio a una directory, può essere quotata onestamente a una settimana oppure a due mesi. La varianza è una proprietà della RFP, non dei fornitori.

Quali domande rivelano un buon fornitore software? Che cosa costruirebbe per primo e perché, che cosa considera la parte più rischiosa e come la ridurrebbe, chi farà materialmente il lavoro e con quanta parte del proprio tempo, come vengono gestiti i cambi di perimetro, che cosa gli serve da voi e che cosa possedete alla fine.

Quando è meglio non usare una RFP? Quando il lavoro è piccolo, esplorativo, o non riuscite ancora a definire che cosa vi serve. Una gara su un perimetro indefinito costa settimane a entrambe le parti e crea una precisione fittizia. Un incarico di discovery a pagamento che produce una specifica, o che stabilisce che il progetto non vale la pena, è lo strumento migliore.