Proposte comparabili partono da un incarico descritto bene: 12 informazioni utili da fornire

L'attuale Sourcing Playbook del Regno Unito afferma che una specifica chiara dovrebbe fornire agli offerenti informazioni sufficienti per decidere consapevolmente se partecipare. Sottolinea inoltre che senza una comprensione condivisa dei requisiti è difficile collegare i prezzi proposti ai costi e ai risultati attesi dal committente. [1]

La Government Commercial Function lo esprime ancora più direttamente: una buona specifica dovrebbe contenere le informazioni necessarie affinché i fornitori possano calcolare correttamente i costi e il committente possa confrontare le offerte su una base equivalente. [2]

Allo stesso tempo, il Digital, Data and Technology Playbook britannico mette in guardia da una definizione eccessiva della soluzione. Raccomanda di concentrarsi sull'utente, sul problema e sul risultato atteso, lasciando ai fornitori spazio per proporre un modo efficace di raggiungerlo. [3]

La conclusione non è "descrivi tutto nel massimo dettaglio possibile". Una regola migliore è:

descrivi con precisione ciò che deve essere comune a tutte le proposte, non ciò che uno specialista competente può ragionevolmente progettare da solo.

Due proposte professionali non saranno mai identiche, e non dovrebbe essere questo l'obiettivo.

Comparabilità significa che gli specialisti rispondono allo stesso problema con ipotesi sostanzialmente simili.

Dovrebbero quindi avere una comprensione analoga di:

• obiettivo,
• ambito,
• punto di partenza,
• risultato atteso,
• vincoli importanti,
• tempistiche,
• responsabilità del cliente,
• modo in cui presentare il prezzo,
• criteri con cui la proposta verrà valutata.

Possono invece differire per:

• approccio proposto,
• ordine delle attività,
• metodo,
• composizione del team,
• strumenti,
• suddivisione in fasi,
• modo di ridurre i rischi.

Queste differenze spesso hanno valore e dovrebbero rimanere visibili.

Parti dal problema, non da un elenco di funzionalità.

Invece di:

"Mi serve un'applicazione con pannello, notifiche e report."

prova:

"Attualmente cinque persone gestiscono il processo con fogli di calcolo ed e-mail. È difficile vedere lo stato attuale di una pratica, chi ne è responsabile e quale sia il passo successivo. Vogliamo ridurre il monitoraggio manuale e avere un unico punto con lo stato aggiornato."

La seconda descrizione non decide ancora quale applicazione debba essere costruita.

Aiuta però lo specialista a capire perché il progetto esiste.

La Federal Acquisition Regulation per servizi basati sui risultati raccomanda di descrivere il lavoro soprattutto attraverso i risultati richiesti, non attraverso il modo di esecuzione o il numero di ore. La dichiarazione minima degli obiettivi comprende elementi come finalità, ambito, contesto, risultati richiesti e vincoli operativi. [4]

Descrivi quindi che cosa dovrebbe essere possibile al termine del lavoro.

Per esempio:

• un utente può completare autonomamente un processo definito,
• il team può vedere lo stato corrente di tutte le pratiche,
• il cliente riceve un'analisi con priorità,
• il sistema viene trasferito in un nuovo ambiente e funziona secondo criteri concordati,
• il materiale preparato è pronto per la pubblicazione in un canale specifico.

Il risultato dovrebbe essere abbastanza concreto da far comprendere a entrambe le parti la direzione del lavoro.

Non deve però significare una garanzia di risultato commerciale dipendente dal mercato, dal comportamento degli utenti o da altri fattori fuori dal controllo del fornitore.

La stessa esigenza finale può richiedere sforzi molto diversi a seconda del punto di partenza.

È utile indicare:

• che cosa esiste già,
• che cosa funziona e deve essere conservato,
• che cosa non funziona,
• se esistono file sorgente,
• se esiste documentazione,
• se ci sono dati da migrare,
• se bisogna lavorare su un sistema esistente,
• quali materiali sono già pronti.

"Un nuovo sito" può significare costruire da zero oppure riprogettare un sito esistente mantenendo contenuti, indirizzi, analisi, integrazioni e dati.

Sono lavori diversi, anche se il risultato visivo finale può sembrare simile.

L'ambito non dovrebbe costringere gli specialisti a indovinare quali parti del problema devono valutare.

Per esempio:

Incluso:

• analisi della soluzione attuale,
• progettazione di nuove viste,
• implementazione,
• migrazione di una parte definita dei dati.

Fuori ambito:

• creazione di nuovi contenuti,
• acquisto di licenze,
• manutenzione dopo il primo mese,
• ricostruzione del sistema di pagamento.

L'esempio di Terms of Reference della Banca Mondiale sottolinea che requisiti e aspettative dei servizi dovrebbero essere espressi chiaramente e adattati al progetto specifico. [5]

I confini sono particolarmente importanti quando due attività sono naturalmente collegate ed è facile supporre che una includa l'altra.

Se ti aspetti materiali o risultati specifici, nominali chiaramente.

Possono includere:

• una soluzione funzionante,
• file sorgente,
• un rapporto,
• documentazione,
• un progetto visivo,
• un insieme di materiali,
• configurazione dell'ambiente,
• formazione,
• una registrazione,
• trasferimento del codice e degli accessi.

Parole come "progetto", "analisi" o "implementazione" possono essere interpretate in modi diversi.

Un elenco comune dei principali elementi da consegnare aiuta a evitare che una proposta includa molto più di un'altra senza che la differenza sia evidente dietro nomi simili del servizio.

Non ogni vincolo è un dettaglio tecnico.

Possono essere importanti, per esempio:

• un sistema o ambiente obbligatorio,
• integrazione necessaria con un servizio specifico,
• requisiti di accessibilità,
• norme di settore,
• restrizioni sull'archiviazione dei dati,
• necessità di mantenere l'infrastruttura attuale,
• dispositivi o browser specifici,
• lavoro in determinati orari,
• accesso limitato ai dati.

La FAR include esplicitamente i vincoli operativi nella dichiarazione degli obiettivi, mentre il Digital, Data and Technology Playbook britannico mostra perché non bisogna imporre una soluzione quando non esiste un vincolo reale. [4] [3]

Una buona regola:

indica ciò che lo specialista non può cambiare, ma non inventare un vincolo solo perché sei abituato a una determinata soluzione.

Lo specialista dovrebbe sapere su quale livello di collaborazione può basare la propria proposta.

Indica se fornirai:

• una persona con potere decisionale,
• accesso ai sistemi,
• materiali esistenti,
• dati,
• account di prova,
• informazioni dal team,
• accesso agli utenti,
• contenuti,
• riunioni regolari,
• risposte entro un tempo definito.

Se non sai ancora che cosa potrai fornire, è utile dirlo comunque.

La mancanza di accesso a dati, materiali o persone può cambiare metodo, costo e tempi. Non è un piccolo dettaglio organizzativo. Fa parte delle condizioni su cui viene costruita la proposta.

Non tutte le date hanno lo stesso significato.

Distingui tra:

• data preferita di inizio,
• scadenza non prorogabile,
• data legata a un evento esterno,
• data indicativa,
• fasi che devono avvenire in un ordine specifico.

Se una scadenza non può davvero cambiare, spiega perché.

Se è flessibile, dillo anche.

Così lo specialista può proporre un altro ambito, un'altra sequenza o una consegna per fasi invece di assumere che ogni data sia un requisito assoluto.

Non esiste una regola unica secondo cui il cliente deve sempre rivelare l'intero budget.

A seconda della situazione puoi indicare:

• un budget massimo,
• una fascia di budget,
• un budget per la prima fase,
• che prima vuoi una proposta di ambito e solo dopo il prezzo,
• la struttura desiderata per la suddivisione del prezzo.

Per il confronto, la cosa più importante è che gli specialisti presentino i costi in una struttura simile.

Per esempio:

"Indica separatamente il prezzo per analisi, design, implementazione e manutenzione mensile. Specifica anche i costi di servizi esterni non inclusi."

Questo formato è molto più facile da confrontare di quattro importi complessivi che comprendono cose diverse.

L'incertezza non scompare solo perché non viene scritta.

Se non sai:

• quanti dati devono essere migrati,
• se un'interfaccia esterna consente l'operazione necessaria,
• se tutti i contenuti saranno pronti,
• se il codice attuale può essere ragionevolmente esteso,
• se un'approvazione necessaria arriverà in tempo,

dillo.

La guida GAO sulle stime affidabili dei costi sottolinea l'importanza di ipotesi esplicite e dell'analisi di rischi e incertezze. [6]

Un buon specialista può quindi:

• includere una riserva,
• proporre una fase di analisi iniziale,
• valutare varianti,
• indicare una condizione che cambierebbe il prezzo,
• rifiutare di fingere una precisione che in questa fase non può essere raggiunta onestamente.

Un'incognita esplicita è migliore di un'ipotesi nascosta.

Se sai già che cosa conterà nella decisione, dillo prima che vengano preparate le proposte.

Puoi valutare:

• adeguatezza dell'approccio proposto,
• esperienza con problemi simili,
• qualità delle prove del lavoro precedente,
• realismo del calendario,
• disponibilità,
• gestione dei rischi,
• competenze delle persone che lavoreranno davvero al progetto,
• prezzo,
• costo di manutenzione,
• qualità della comunicazione.

Le attuali indicazioni della Banca Mondiale sui Rated Criteria segnalano che i criteri non legati al prezzo possono includere qualità della metodologia e del piano di lavoro, gestione del rischio, capacità di esecuzione e personale chiave. I criteri vengono adattati al progetto e ponderati secondo la loro importanza relativa. [7]

Questo non significa che un piccolo incarico abbia bisogno di un punteggio formale.

Basta saper rispondere prima di inviare la richiesta:

"Che cosa, oltre al prezzo, renderebbe una proposta migliore per me rispetto a un'altra?"

Se vuoi davvero confrontare le proposte, chiedi a tutti di rispondere allo stesso insieme di domande di base.

Per esempio:

1. Come interpreti il problema e il risultato atteso?
2. Quale approccio proponi?
3. Che cosa include esattamente la tua proposta?
4. Che cosa è escluso?
5. Quali ipotesi stai facendo?
6. Qual è il calendario?
7. Di che cosa hai bisogno dal cliente?
8. Quali sono i principali rischi?
9. Qual è il prezzo e che cosa include esattamente?
10. Quale esperienza o prova di lavoro simile è rilevante per questo incarico?

Negli appalti pubblici, standardizzare risposte, criteri e formati di prezzo serve proprio a valutare le proposte su una base comune. La Government Commercial Function sottolinea la necessità di fornire informazioni sufficienti per una corretta valutazione dei costi e un confronto equivalente. [2]

Un formato comune non dovrebbe eliminare le differenze tra specialisti. Dovrebbe soltanto renderle visibili negli stessi punti.

Dipende dall'obiettivo della richiesta.

Condividere il budget può aiutare quando:

• l'ambito può essere adattato alle risorse disponibili,
• vuoi una raccomandazione sulla migliore opzione entro un limite,
• vuoi escludere rapidamente proposte incompatibili con la realtà finanziaria del progetto.

Non condividere l'intero budget può avere senso quando:

• prima vuoi una valutazione indipendente dell'ambito appropriato,
• non conosci ancora il costo realistico,
• stai confrontando diversi modelli di soluzione,
• il processo richiede un altro modo di raccogliere i prezzi.

La situazione peggiore non è necessariamente l'assenza di un budget, ma l'assenza di informazioni su che tipo di risposta economica ti aspetti.

Lo specialista dovrebbe sapere se deve indicare un prezzo unico, una fascia, varianti, prezzi per fase oppure ipotesi necessarie per una stima più precisa.

Una buona descrizione dell'incarico non deve rispondere a ogni domanda.

Può dire onestamente:

• "Non sappiamo ancora se il sistema attuale può essere esteso in sicurezza.",
• "Non conosciamo il numero esatto di record da migrare.",
• "Non abbiamo ancora deciso se la seconda lingua rientrerà nella prima fase.",
• "Abbiamo bisogno di aiuto per scegliere l'opzione migliore."

È un'informazione utile.

L'incertezza dovrebbe influenzare il modo in cui la proposta viene preparata, non scomparire dal documento.

In alcune situazioni, il miglior primo servizio non è la realizzazione completa, ma una breve fase iniziale che termina con una decisione, un ambito più preciso o una stima più affidabile.

1. Dare a ogni specialista un insieme diverso di informazioni.

2. Elencare funzionalità senza spiegare problema e obiettivo.

3. Non indicare che cosa esiste già.

4. Nascondere vincoli che in seguito cambiano il modo di eseguire il lavoro.

5. Chiedere un solo prezzo finale senza spiegare che cosa deve includere.

6. Valutare le proposte con criteri che non erano stati definiti in anticipo.

7. Confondere una descrizione dettagliata del problema con l'imposizione dettagliata della soluzione.

1. Ho descritto chiaramente il problema e non soltanto la soluzione che avevo immaginato?
2. È chiaro il risultato che voglio ottenere?
3. Lo specialista comprende lo stato attuale?
4. È chiaro che cosa deve essere preservato?
5. Sono chiari i confini del primo ambito?
6. Ho indicato gli elementi principali da consegnare?
7. Ho indicato i vincoli reali?
8. È chiaro che cosa fornirò da parte mia?
9. Il calendario è descritto insieme alla sua flessibilità?
10. Il formato del prezzo permetterà di confrontare le proposte?
11. Ho descritto apertamente le principali incognite?
12. So che cosa valuterò oltre al prezzo?
13. Tutti gli specialisti risponderanno a un insieme simile di domande?
14. Ho lasciato spazio a una soluzione migliore di quella che avevo immaginato?

Una buona descrizione dell'incarico ha due obiettivi apparentemente opposti.

Deve essere abbastanza concreta perché più specialisti valutino lo stesso problema.

Allo stesso tempo deve essere abbastanza aperta perché ognuno possa proporre il proprio approccio, forse migliore.

Un ordine utile è:

problema -> risultato -> stato attuale -> ambito -> elementi da consegnare -> vincoli -> responsabilità del cliente -> tempi -> formato del prezzo -> incognite e rischi -> criteri di scelta -> formato comune di risposta.

Se, dopo aver ricevuto le proposte, scopri che una persona ha valutato l'intero progetto, un'altra solo l'analisi e una terza ha ipotizzato integrazioni aggiuntive, il problema potrebbe non essere nei preventivi.

Forse ognuno ha ricevuto un incarico diverso, anche se a tutti è stato inviato lo stesso testo.

[1] UK Government - The Sourcing Playbook
Apri fonte

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

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

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

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

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

[7] World Bank - Rated Criteria
Apri fonte

Nota metodologica: le fonti provengono soprattutto dagli appalti pubblici e dalla gestione dei costi. Non sono presentate come regole direttamente applicabili a un mercato privato di specialisti. L'articolo usa solo i principi che sostengono realmente: chiarezza dei requisiti, orientamento ai risultati, ipotesi e rischi espliciti, informazioni di prezzo comparabili e valutazione della qualità con criteri ulteriori rispetto al solo prezzo.