RFP software: come gli studi le leggono, le valutano e determinano il prezzo

RFP software: come gli studi lo leggono, lo valutano e ne determinano il prezzo

Un RFP software viene letto da persone che decidono se dedicare una settimana del tempo di ingegneri senior a un’offerta che potrebbero non vincere. Nei primi quindici minuti, uno studio ha solitamente deciso se rispondere, quanto seriamente farlo e quale rischio di prezzo assumersi. Questo articolo illustra tale decisione dal punto di vista del fornitore, così potrete inviare un RFP software che vi consenta di ottenere proposte migliori e prezzi più equi dalle aziende con cui desiderate davvero lavorare.

Questa non è una guida alla scrittura. Abbiamo già trattato struttura, modelli, criteri di valutazione e sicurezza nella nostra guida alle RFP per lo sviluppo software. Qui esaminiamo cosa succede dopo che premete Invia.

Punti chiave

• Gli studi fanno rapidamente una prima selezione degli RFP software. Un ambito non chiaro, l’assenza di indicazioni sul budget e la mancanza di accesso ai responsabili delle decisioni sono i motivi più comuni per cui le aziende migliori rifiutano di partecipare.
• Requisiti vaghi non producono offerte più economiche. Producono offerte maggiorate, perché il fornitore deve includere nel prezzo il rischio legato a ciò che non può vedere.
• I criteri di valutazione indicano ai fornitori cosa scrivere. Se attribuite maggiore peso alla collaborazione e all’approccio, riceverete proposte incentrate sulla collaborazione e sull’approccio.
• Un intervallo di budget, una finestra per le domande e risposte e un responsabile indicato per nome contribuiscono più alla qualità delle proposte di qualsiasi pagina aggiuntiva di requisiti.
• Una proposta del fornitore poco articolata è spesso un segnale relativo alla vostra RFP, non soltanto al fornitore.

Indice

• A cosa dovrebbe servire una RFP software
• Come appare una RFP software dal punto di vista del fornitore
• Come gli studi valutano i requisiti
• Come i criteri di valutazione influenzano le proposte che ricevete
• Come gli studi determinano il prezzo di una richiesta di proposta software
• I segnali d’allarme di una RFP che i fornitori notano
• Cosa rivelano le proposte solide sulla vostra RFP
• Come leggere correttamente le risposte dei fornitori
• Avete davvero bisogno di una RFP software?
• Il nostro approccio a una RFP software presso Ridiculous Engineering
• Inviate una RFP software a cui valga la pena rispondere
• Domande frequenti
• Fonti

A cosa dovrebbe servire una RFP software

Una richiesta di proposta chiede a più fornitori di presentare offerte formali sulla base dei requisiti che definite ed è particolarmente utile per progetti complessi con elementi diversi, secondo la panoramica di TechTarget sulle RFP. Questa definizione descrive l’obiettivo dell’acquirente. L’obiettivo del fornitore è diverso: decidere se questo è un progetto per cui vale la pena presentare un’offerta e, in tal caso, quanto costerà davvero realizzarlo.

Questi due obiettivi si incontrano nel documento. Una buona RFP li rende entrambi facili da perseguire. Una RFP carente costringe il fornitore a fare supposizioni, e le supposizioni determinano il prezzo.

Come appare una RFP software dal punto di vista del fornitore

Immaginate la persona che la riceve: un principal, un responsabile engineering o un solution architect che sta già seguendo anche progetti per clienti. Non la legge per piacere. Effettua una rapida valutazione iniziale e le domande sono sempre le stesse.

Le domande della prima valutazione

1. Esiste un problema concreto e un responsabile concreto? Uno sponsor aziendale identificato e un risultato dichiarato indicano un progetto destinato ad arrivare alla consegna. Un documento privo di entrambi suggerisce un’attività esplorativa.
2. Il budget è della stessa entità dell’ambito del progetto? Pochi acquirenti pubblicano una cifra, ma un intervallo o un tetto massimo consente al fornitore di dire rapidamente se il lavoro è compatibile. In assenza di queste indicazioni, il fornitore può evitare di partecipare alla gara oppure valutare i costi di una versione molto più ampia del progetto, per cautelarsi.
3. La RFP è un vero processo di selezione? Gli studi riescono spesso a capire quando un fornitore è già stato scelto e la RFP è solo documentazione per gli acquisti. Di solito rinunciano, perché redigere una proposta seria è costoso.
4. Possiamo parlare con qualcuno? Una finestra per le domande e risposte e un referente in grado di rispondere alle domande sul prodotto sono segnali fortemente positivi.
5. La tempistica è realistica? Una finestra di risposta di pochi giorni per uno sviluppo complesso indica ai fornitori che l’acquirente attribuisce più valore alla rapidità delle pratiche che alla qualità delle risposte.

Preparare un’offerta richiede un impegno concreto. Le ipotesi per la fase di analisi, gli schemi architetturali, l’assegnazione delle risorse e un modello di prezzo richiedono tutti l’attenzione di figure senior. Le aziende molto richieste investiranno questo impegno solo dove le probabilità sono ragionevoli.

Perché questo è importante per voi

Le aziende più propense a rifiutare una RFP vaga sono spesso quelle che hanno più alternative. Se desiderate una risposta a una RFP software da parte di un team con un solido storico di risultati, il documento deve rispettare il loro tempo. Ciò significa meno sezioni standard e più informazioni che incidono sul prezzo.

Come gli studi valutano i requisiti

I requisiti sono la parte a cui i fornitori dedicano più tempo di lettura, perché è lì che si nascondono i costi.

Il dettaglio aiuta, ma deve essere quello giusto

Requisiti dettagliati aiutano a ottenere risposte confrontabili e una RFP software può includere utilmente requisiti, informazioni sul fornitore, referenze, licenze e costi del progetto, come descritto nella guida del Project Management Institute al processo RFP Per uno studio, il dettaglio utile è quello che modifica l’impegno richiesto:

• Quanti ruoli utente esistono e cosa può fare ciascuno
• Quali sistemi devono integrarsi e se dispongono di API documentate
• Dove risiedono oggi i dati e quanto sono puliti
• Quali obblighi di conformità o accessibilità si applicano
• Chi gestirà il software dopo il lancio

Meno utile è un elenco di funzionalità di 200 righe privo di priorità. Indicare gli elementi indispensabili o preferibili, idealmente sotto forma di storie utente con criteri di accettazione, consente al fornitore di distinguere lo sviluppo essenziale dalla lista dei desideri. In assenza di priorità, un fornitore scrupoloso considera ogni elemento obbligatorio nel calcolo del prezzo.

Prescrivere la soluzione anziché descrivere il problema

Alcune RFP impongono l’architettura, lo stack e le schermate. Altre descrivono il problema e gli indicatori di successo. Le linee guida di PublicCode.net sulla redazione delle RFP raccomandano criteri orientati al problema, che lasciano ai fornitori la scelta del cosa e del come, creando spazio per nuovi approcci.

Dal punto di vista del fornitore, si tratta di una distinzione concreta. Se la vostra RFP prescrive una soluzione, otterrete conformità, non capacità di giudizio. Ogni fornitore dirà di sì al vostro progetto e le proposte si assomiglieranno. Se descrivete il problema, potrete vedere come ragiona ciascun team: è questa l’informazione che vi serve per selezionare il fornitore software.

L’eccezione è rappresentata da un vincolo inderogabile. Se dovete operare su uno specifico cloud, integrarvi con uno specifico ERP o rispettare uno standard preciso, dichiaratelo chiaramente. I vincoli sono utili. Le preferenze mascherate da vincoli non lo sono.

Come i criteri di valutazione influenzano le proposte che ricevete

I fornitori leggono la vostra griglia di valutazione come un brief per la redazione. Daranno risalto a tutto ciò a cui sono associati punti.

Gli schemi di valutazione pubblicati mostrano quanta varietà esista. Una corte superiore della California ha valutato le proposte su una scala di 100 punti che comprendeva esperienza, costi, assistenza, collaborazione, disponibilità in loco, un team dedicato e accettazione dei termini. Un’associazione regionale per l’osservazione oceanografica, nella propria RFP sulla gestione dei dati, ha assegnato un peso del 30% ciascuno alle qualifiche tecniche e all’approccio operativo con un piano di transizione, e del 10% alla capacità di partnership strategica.

Nessuna delle due è la risposta giusta per voi. Il punto è ciò che un fornitore ricava da questi schemi. Nel secondo esempio, il fornitore sa che il modo in cui subentra e gestisce il sistema è importante quanto il codice. Dedicherà a questi aspetti una parte consistente della proposta.

Una matrice ponderata segnala rigore

Una matrice di valutazione dei requisiti, che assegna un punteggio alle risposte in base a elementi indispensabili, desiderabili e preferibili ponderati, è uno strumento comune, e la Guida alla PMI lo descrive come un confronto trasparente basato su un foglio di calcolo. Quando un fornitore ne vede uno nella RFP, ne ricava due informazioni: l’acquirente ha riflettuto su come prendere la decisione e questa difficilmente dipenderà dal numero più basso.

Il problema del peso attribuito al prezzo

Il peso attribuito ai costi è la leva che gli acquirenti valutano più spesso in modo errato. Se attribuite al prezzo il 60% del punteggio, riceverete offerte aggressive da fornitori disposti a dare per scontato che tutto proceda senza intoppi, e offerte ponderate da fornitori che si tirano indietro. Se lo fissate al 20 o 30%, incoraggerete proposte che spiegano i rischi con onestà. Nessuno dei due estremi è sbagliato, ma occorre agire deliberatamente. La vostra ponderazione indica quale tipo di fornitore desiderate.

Come gli studi determinano il prezzo di una RFP software

Questa è la parte che gli acquirenti vedono meno. Il prezzo di una risposta a una RFP software raramente deriva da un unico calcolo. È una stima a cui si aggiunge il rischio.

Passaggio 1: dimensionare il lavoro

Il team suddivide l’ambito in componenti, stima l’impegno necessario per ciascuno e tiene conto di progettazione, sviluppo, test, gestione del progetto e messa in produzione. A tutto ciò che la RFP lascia vago viene associata un’ipotesi.

Passaggio 2: valutare i costi degli elementi incerti

Ogni ambiguità diventa un’ipotesi esplicita o una contingenza. Se la RFP dice «integrare con i nostri sistemi esistenti» senza specificarne alcuno, il fornitore deve decidere se si tratti di una singola API ben definita o di cinque database legacy. Un fornitore prudente presume il caso più complesso, oppure inserisce l’ipotesi nella proposta e include nel prezzo un processo di gestione delle modifiche.

Ecco perché requisiti vaghi non fanno risparmiare. L’incertezza non è gratuita e qualcuno la paga. Il fornitore la incorpora nel prezzo oppure si tutela nel contratto.

Passaggio 3: scegliere un modello commerciale

Prezzo fisso, tempo e materiali e modelli per fasi trasferiscono il rischio a soggetti diversi. Un prezzo fisso per un ambito non chiaro trasferisce il rischio al fornitore, che lo include nel prezzo. Il modello a tempo e materiali lo trasferisce nuovamente all’acquirente, che ottiene flessibilità e meno certezza. Molti studi propongono una breve fase di analisi iniziale retribuita, seguita da una stima dello sviluppo, perché sostituisce le supposizioni con dati concreti. Se la vostra RFP lo vieta, state chiedendo ai fornitori di tirare a indovinare.

Per capire cosa determina le cifre sul mercato, consultate la nostra analisi dei costi dello costi dello sviluppo di software personalizzato.

Passaggio 4: decidere quanto essere competitivi

Il fornitore valuta quindi il contesto competitivo. Un intervallo di budget è utile in questa fase: consente a uno studio di proporre la versione migliore del progetto compatibile con le vostre possibilità, anziché la versione ideale che non potete permettervi. Dopo la ricezione delle proposte, il processo prosegue spesso con una preselezione, negoziazioni economiche e tecniche, offerte migliori e definitive e l’assegnazione in base ai criteri dichiarati, come osserva TechTarget. I fornitori lo sanno. Alcuni lasciano margine per negoziare. Altri presentano il loro prezzo effettivo e non lo modificano. Dichiarare chiaramente se organizzerete una fase per le offerte migliori e definitive consente a tutti di giocare secondo le stesse regole.

Segnali d’allarme nelle RFP notati dai fornitori

Questi sono gli schemi che spingono gli studi esperti a rifiutare l’incarico o a presentare offerte difensive. Nella maggior parte dei casi è facile correggerli prima dell’invio.

Nessuno di questi elementi, preso singolarmente, è fatale. Diversi elementi insieme indicano a uno studio che dovrebbe dedicare altrove il proprio tempo.

Per quanto riguarda il linguaggio contrattuale, le linee guida del PMI suggeriscono che l’ufficio legale o l’amministrazione dei contratti dovrebbe fornire il testo standard per le istruzioni ai partecipanti, i termini e le condizioni e la riservatezza. Fatelo fin dall’inizio. Le condizioni che compaiono per la prima volta nella fase contrattuale vi costano fiducia e tempo.

Cosa rivelano le proposte solide sulla vostra RFP

Se le proposte dei fornitori che ricevete sono scarne, generiche o quasi identiche, resistete alla tentazione di dare subito la colpa ai fornitori. Verificate la RFP.

• Proposte generiche di solito indicano che la RFP non offriva nulla di specifico a cui rispondere.
• Prezzi molto diversi tra loro di solito indicano che l’ambito non era chiaro e che ogni fornitore ha formulato ipotesi diverse. Chiedete loro di elencare le proprie ipotesi e confrontatele prima di confrontare i totali.
• Poche risposte di solito indicano un problema di tempistiche, budget o condizioni che le aziende serie hanno notato.
• Proposte che riformulano i vostri requisiti senza commenti indicano che il fornitore non aveva spazio, o motivo, per esercitare il proprio giudizio.

Una risposta solida a una RFP software fa qualcosa di più utile. Mette in discussione un’ipotesi, propone una suddivisione in fasi, pone una domanda difficile su un’integrazione oppure segnala che un requisito incide sulla maggior parte dei costi. È questo il tipo di proposta che vale la pena cercare, ed è il tipo di proposta per cui la vostra RFP deve lasciare spazio.

Come leggere correttamente le risposte dei fornitori

Una volta ricevute le risposte, il punto di vista del fornitore può aiutarvi nella valutazione.

1. Confrontate le ipotesi prima dei totali. Due prezzi sono confrontabili solo se si basano sullo stesso ambito.
2. Prestate attenzione alle persone. Chi svolgerà effettivamente il lavoro e parteciperà alla sessione di domande e risposte? Il nostro framework per la scelta di un’azienda di sviluppo software personalizzato approfondisce gli indicatori relativi al team e al processo.
3. Premiate la trasparenza sui rischi. Un fornitore che segnala ciò che potrebbe andare storto di solito dimostra l’esperienza per cui state pagando.
4. Chiedete una sessione operativa. Un’ora di conversazione dal vivo con il team che realizzerà il progetto vi dice più di un altro giro di domande scritte.
5. Considerate con sospetto il prezzo più basso e con curiosità quello più alto. Chiedete a ciascun fornitore di illustrare cosa è incluso e cosa non lo è.

Gli acquirenti del settore pubblico devono rispettare ulteriori regole oltre a queste, illustrate nella nostra guida all’acquisto di software per la pubblica amministrazione.

È davvero necessaria una RFP per il software?

A volte la risposta onesta è no. Una RFP formale è adatta ad acquisti complessi e ad alto rischio, quando diversi fornitori qualificati potrebbero avere successo e serve una documentazione difendibile e comparabile. È invece poco adatta quando si sta ancora definendo cosa costruire, quando il budget è ridotto o quando ci si fida già di un partner. In questi casi, un breve incarico di analisi preliminare o una conversazione con due o tre aziende preselezionate porta spesso a una risposta migliore e più rapidamente.

Vale anche la pena mettere alla prova il presupposto di partenza. Ogni sistema personalizzato comporta una responsabilità a lungo termine per hosting, sicurezza e aggiornamenti; pertanto, prima di avviare il processo, è opportuno verificare che lo sviluppo personalizzato sia davvero la soluzione giusta. Il nostro articolo su software open source e proprietario può aiutare a rispondere a questa domanda.

Il nostro approccio a una RFP per il software presso Ridiculous Engineering

Leggiamo le RFP nel modo descritto in questo articolo e cerchiamo di essere un buon candidato. Individuiamo il risultato aziendale, il responsabile e i vincoli, e vi diremo con chiarezza quando un requisito aumenta i costi o quando una prima fase più contenuta sarebbe più utile. I clienti lavorano direttamente con ingegneri senior, dalla fase di analisi preliminare fino al miglioramento a lungo termine.

Se state preparando l’invio di una RFP per il software o avete già ricevuto delle proposte e desiderate un secondo parere, il nostro team di sviluppo software personalizzato può aiutarvi, mentre il nostro servizio di consulenza software e supporto alla realizzazione include la revisione, dal lato del fornitore, dell’ambito e delle stime. Lo sviluppo software personalizzato viene definito caso per caso, con prezzi su richiesta. I progetti di siti web semplici partono da 3.000 USD e il prezzo finale dipende dall’ambito e dalla complessità.

Invii una richiesta di proposta software a cui valga la pena rispondere

Una richiesta di proposta software funziona al meglio quando è scritta per le due persone che la leggeranno: il valutatore che le assegna un punteggio e l’ingegnere che ne determina il prezzo. Presenti ai fornitori un problema concreto, un’indicazione del budget, le priorità, un modo per porre domande e criteri coerenti con ciò che ritiene importante. Riceverà meno proposte, ma migliori, con prezzi che riflettono il lavoro anziché gli elementi sconosciuti.

FAQ

Perché i migliori studi di sviluppo software rifiutano di rispondere a una richiesta di proposta?

Di solito perché il costo di una proposta seria supera le probabilità di aggiudicarsi il lavoro. Informazioni mancanti sul budget, nessuna possibilità di porre domande, una scadenza molto ravvicinata o il sospetto che un fornitore sia già stato preselezionato sono le cause più comuni. Correggere questi aspetti nel documento riporta in gara le aziende migliori.

Dovrei includere il mio budget in una richiesta di proposta software?

Di solito vale la pena includere un intervallo o un tetto massimo. In questo modo i fornitori possono proporre la soluzione migliore entro i vostri limiti, invece di tirare a indovinare, e diventa più facile confrontare le proposte. Se non potete condividere una cifra, indicate almeno se il progetto è finanziato e come è stato definito il budget.

Perché i prezzi nelle proposte dei miei fornitori sono così diversi?

Nella maggior parte dei casi, perché ciascun fornitore ha formulato ipotesi diverse riguardo ad ambito non chiaro, integrazioni o responsabilità dopo il lancio. Chiedete a ogni offerente di elencare le proprie ipotesi e le esclusioni, quindi confrontate i totali su basi omogenee.

Che cos’è un’offerta definitiva?

È una fase successiva alla valutazione iniziale, durante la quale i fornitori preselezionati vengono invitati a perfezionare i prezzi o le condizioni prima dell’aggiudicazione. TechTarget la elenca tra le possibili fasi successive alla presentazione delle proposte. Se intendete svolgerla, indicatelo nella richiesta di proposta, così i fornitori potranno determinare i prezzi di conseguenza.

Posso inviare una richiesta di proposta per un lavoro che non ho ancora definito completamente?

Sì, ma inquadrate la richiesta intorno al problema e chiedete un approccio per fasi, idealmente con una fase di analisi preliminare retribuita. Pretendere un prezzo fisso per un ambito non definito porta a offerte maggiorate o all’assenza di offerte da parte delle aziende più scrupolose.

Fonti

• Che cos’è una richiesta di proposta (RFP)? | TechTarget
• Gestire il processo RFP per l’acquisizione di software | PMI
• Scrittura dell’RFP, codice di processo per l’acquisizione di software | PublicCode.net
• RFP IT della Superior Court of California, County of San Francisco
• RFP per lo sviluppo, la gestione operativa e la manutenzione del sistema SECOORA

Consigliato

• Richiesta di proposta per lo sviluppo software: modello, criteri di valutazione e guida alla sicurezza
• Sviluppare o acquistare software: checklist decisionale per i responsabili
• Come scegliere un'azienda di sviluppo software personalizzato: un framework in 12 punti
• Stima dei progetti software: guida pratica per project manager