Sfruttare al Massimo una Demo Software

 

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast utilizzando un programma software automatico. Chiediamo scusa per eventuali errori di battitura, poiché il bot non è sempre preciso al 100%.

Galen Low: Un’altra demo software di un fornitore sta andando a rotoli. Il tuo direttore tecnologico e il tuo responsabile DevOps sembrano giocare al bingo delle parole chiave con ogni termine di marketing che il presentatore menziona. Gli occhi del tuo direttore generale si stanno velando mentre gli argomenti diventano troppo tecnici. E anche se la persona che presenta sembra davvero competente, nessuno sembra affrontare l’elefante nella stanza: in realtà è il cugino del vostro CEO.

Non c’è un modo per rendere questo tempo più utile per tutti?

Se le demo poco coinvolgenti sono state un ostacolo per prendere una decisione informata sull’acquisto di nuovo software per la tua organizzazione, continua ad ascoltare.

Andremo a vedere alcune delle strategie più efficaci per rendere la fase di demo nella selezione dei software molto più rilevante per le reali esigenze della tua azienda.

Ciao a tutti, grazie per essere all’ascolto! Mi chiamo Galen Low e sono con il Digital Project Manager. Siamo una community di professionisti digitali con la missione di aiutarci a vicenda a sviluppare competenze, acquisire sicurezza e creare connessioni per valorizzare la gestione dei progetti nel mondo digitale. Se ti interessa saperne di più, visita thedigitalprojectmanager.com.

Bene. Oggi parliamo del processo di selezione di un nuovo software per i team di progetto, e nello specifico di come andare oltre il discorso di vendita tipico di una demo per essere certi che lo strumento scelto sia non solo il migliore, ma quello giusto per il modo in cui i tuoi team lavorano. Oggi con me c’è Olivia Montgomery, Associate Principal Analyst presso Capterra ed ex responsabile IT PMO, che ora offre consulenza alle PMI sulla selezione dei software.

Ciao Olivia!

Olivia Montgomery: Ciao, Galen! Grazie per avermi invitata.

Galen Low: È stato fantastico riaverti nel programma. Come vanno le cose ad Austin?

Olivia Montgomery: Abbastanza emozionanti. C’è il South by Southwest in corso, ed è di nuovo in presenza, la prima volta dal 2020. Quindi la città è vivace e ci sono così tanti eventi, incontri e cose da fare. Settimana davvero entusiasmante.

Galen Low: Di nuovo in pista, di nuovo in pista. South by Southwest, sono super entusiasta. È ovunque sui miei social e via dicendo. Non sono mai stato ad Austin, ma è una comunità musicale incredibile. Ci sono moltissime cose che succedono, tantissime conferenze e possibilità di incontrarsi e divertirsi.

Ora davvero, non ho più scuse. Potrebbe essere quest’anno. Potrebbe essere davvero l’anno buono.

Olivia Montgomery: Ed è davvero bello. Hanno inserito anche tanti temi tecnologici. Ho potuto seguire incontri di leader della supply chain, del CEO di Amtrak, John Deere è qui con grandi dimostrazioni tecnologiche. Ci sono esperienze in VR che puntano fortemente sullo storytelling in modi nuovi, da temi molto seri a intrattenimento leggero, e ci mostrano come interagire in modo diverso con i contenuti e tra di noi.

Galen Low: Molto interessante. Qual è stata la tua esperienza preferita finora?

Olivia Montgomery: Oltre alla tecnologia e all’innovazione, ho visto la nuova Batmobile dal vivo. Devo dire che è stato un momento clou per me. Sono un'appassionata di cinema. In realtà non guardo mai i trailer, quindi non ho visto nulla su Batman, ma ho visto la Batmobile per la prima volta dal vivo. Davvero fantastico.

Galen Low: Credo sia anche meglio di un trailer.

Olivia Montgomery: Sono d’accordo. Ho percepito l’atmosfera, ora sono davvero curiosa di vedere il film.

Galen Low: È proprio quello che mi aspetto sempre di più, ora che le cose cominciano a riaprirsi. Incontrare l’inaspettato, scoprire cose che non avevi programmato.

Fantastico. Bene. Andiamo al sodo.

Parliamo della parte più stressante e piena di dubbi del processo di selezione software: la demo. Quindi, lasciatemi introdurre la questione.

Poniamo che tu sia stato incaricato di trovare un nuovo strumento per la tua organizzazione, e che tu sia il decisore unico o il presidente del comitato di selezione. Hai passato ore a definire i casi d’uso, raccogliere i requisiti dal team, fissare i budget con la direzione e fare centinaia di ricerche online. Finalmente arrivi a una short-list di strumenti che sembrano adatti, ora vuoi vederli in azione.

Perché questa fase mette così tanta pressione e dubbi? Credo sia perché rappresenta la vera sintesi di tutto il lavoro svolto finora. Devi coordinare tutti gli stakeholder. Devi comunicare efficacemente i requisiti ai fornitori, assorbire una quantità di informazioni e reagire sul momento, e tutto avviene nell’ambiente più stressante di tutti: una riunione.

Partendo da ciò, pensavo di cominciare esaminando le posizioni più scettiche. Un team o un’organizzazione dovrebbero davvero dare peso a una demo? Non è solo una tecnica di vendita?

Olivia Montgomery: Fate le demo, davvero. Capisco. Ho partecipato anch’io a molte demo e spesso erano solo commerciali. Per questo ho iniziato a pensare a modi per migliorarle. Credo molto nel processo delle demo e il project manager ha molto da preparare per renderla una delle fasi più importanti della selezione.

Quindi sì, fate le demo, ma non lasciatevi semplicemente guidare dal fornitore. Questo è l’errore che fanno molti. Dovete guidare e impostare i requisiti su ciò che volete davvero vedere nella demo.

Galen Low: È giusto. Questi strumenti sono molto articolati e spesso li scegliamo per far fare molte cose diverse a persone diverse. Ma è davvero possibile approfondire abbastanza in una demo, oltre a vedere le funzionalità di base? Quali strategie dovrebbe adottare un’organizzazione per assicurarsi di ottenere le risposte che servono?

Olivia Montgomery: Sì. Ottime domande.

Prima di tutto no, non puoi vedere tutto in una demo software. Qui torna utile la ricerca fatta prima. Se hai avviato una RFP, o quando sei arrivato ai tuoi due o tre finalisti, fatti mandare tutto il materiale in un documento. La demo non è il posto per verificare ogni funzionalità necessaria.

Concentrati sull’interfaccia utente e su due-tre user story chiave che il tuo team deve poter seguire. Quali processi di business deve sostenere questo tool? E soprattutto: agli utenti piace l’aspetto e l’utilizzo? Potrebbe essere il loro primo contatto, quindi vedere la UI è fondamentale. L’elenco dettagliato delle funzionalità invece va fatto prima di firmare.

Galen Low: Ottimo punto, grazie. Perché, in effetti, la demo non è il culmine, piuttosto colma alcune lacune.

In realtà fa parte del processo di ricerca. Ci sono cose che devi vedere dal vivo per capirle: l’interfaccia, alcuni casi d’uso specifici... Nessuno pretende che in due ore ci facciano vedere tutte le funzioni. Meglio concentrarsi su dettagli che contano davvero.

Olivia Montgomery: Esatto. E raccomando vivamente di fissare due demo.

Mi piace dividere: una demo business-oriented e una demo tecnica. Unirle in un’unica riunione sarebbe complicato e lungo. La metà degli stakeholder si annoierebbe con la parte tecnica e viceversa. Quindi consiglio di separarle, per rispetto del tempo di tutti.

E servono persone diverse nei due incontri. Non sono sempre gli stessi. È un ulteriore passo di verifica e raccolta requisiti dal vendor.

Quindi, fissa due appuntamenti — a prescindere dal tipo di strumento: che sia un software di project management, contabilità, ERP, ecc, la struttura resta la stessa.

La prima è rivolta al business. Porta il business owner, ma anche l’utente di riferimento, di solito un supervisor, un lead, chi lo userà ogni giorno. Così puoi valutarlo dal punto di vista strategico e operativo.

Il decision maker valuta la scalabilità e la coerenza col business, ma il power user si concentra sulle sue funzioni chiave: può svolgere le sue attività principali? Com’è l’esperienza?

A volte i PM dicono di non riuscire a coinvolgere il power user, spesso all’inizio del progetto. Ma sono loro poi a testare durante la fase di QA. Sono la fonte primaria per i requisiti utente: devono essere soddisfatti dell’aspetto e delle funzionalità.

Per facilitare, raccogli le user story dal team, almeno una o due dal power user, e inviale al fornitore prima della demo. Così possono preparare il sistema e mostrarti esattamente quei casi. Devi poter dire: come contabile, devo poter chiudere il report di fine mese in 24 ore. Devi vedere che sia fattibile.

La user story non deve specificare la singola funzione; magari il tool è innovativo in quel compito. Non vuoi restringere troppo il campo: lascia la possibilità che il vendor ti sorprenda. Ma l’utente deve vedere di poter svolgere le sue azioni chiave, e l’owner vuole vedere, per esempio, la dashboard esecutiva all’accesso. Chiedi sempre dati fittizi nelle demo per vedere come funzionano i report su casi simili ai tuoi.

Galen Low: Mi piace molto l’idea di separare i gruppi. Può sembrare contro-intuitivo, ma ha senso perché servono due conversazioni diverse sullo stesso tool.

Ottimizza il tempo delle persone; spesso troviamo resistenza a coinvolgere subito i power user, ma è vitale per valutarne davvero l’utilità e creare sponsor interni al cambiamento. Se non sono presenti, saranno forse i primi a criticare poi la scelta.

Hai menzionato la sandbox: molti sono abituati a vedere la demo e poi provare in autonomia dopo. C’è un mondo in cui si può anche testare direttamente in sandbox durante la demo?

Olivia Montgomery: Sicuramente i power user lo adorerebbero! A volte si pensa che il nuovo tool farà fare un balzo enorme ai processi, grazie all’automazione... ma non è detto. Il power user può capire se lo strumento è adatto agli scenari attuali e a quelli futuri.

Rendere accessibile la sandbox in anticipo davvero aiuterebbe: così il power user capisce subito se può lavorarci da subito e non perdere funzionalità essenziali.

Non so se i team tecnici lo trovano così necessario, ma sono per la massima trasparenza: parla con stakeholder e fornitori, non lasciare che siano solo loro a guidare la demo. Ma resta aperto, potrebbero proporre soluzioni nuove.

Galen Low: Approfondiamo la preparazione delle due demo. Hai casi pratici di user story efficaci che si possono proporre, o consigli per raccoglierle bene, senza limitare la creatività del vendor?

Olivia Montgomery: Se hai un business analyst IT che raccoglie i requisiti sei fortunato, ma non è comune. E anche così, il power user va aiutato: spesso non ha mai fornito user story o requisiti.

Io uso spesso un questionario “stile Mad Libs”. Chiedo: nel ruolo di..., devo poter..., in modo da.... Così compila facilmente e velocemente. Con queste user story puoi inviarle direttamente al vendor per preparare la demo su casi reali.

Galen Low: Favoloso, adoro unire Mad Libs e user story! Così il vendor può strutturare una demo coerente e la squadra può confermare che davvero il tool supporterà i loro compiti.

Olivia Montgomery: L’aspetto e l’esperienza utente sono il cuore della demo business. Ma la seconda demo, quella tecnica, può includere domande come: ogni quanto vengono eseguiti certi job? Sono pianificabili? Quanto durano? Basta all’azienda?

Serve che i responsabili tecnici e quelli del vendor siano presenti per domande chiave: dove sono archiviati i dati? Li ospitano loro? Li ospitiamo noi? Serve codice custom? Quali integrazioni sono già disponibili?

Chiedi esplicitamente quali tool attuali integra il software. Se non esistono integrazioni pronte all’uso, è un vincolo importante? Servirà sviluppo personalizzato, il vendor lo fa, abbiamo le risorse e il tempo?

La conversazione tecnica può sembrare lunga, ma se ti prepari è gestibile e ti risparmia grane future.

Galen Low: C’è molto da coprire, può creare conversazioni dispersive. Come si fa a selezionare e dare priorità ai casi da testare e alle domande da porre al vendor?

Olivia Montgomery: Qui dovete affidarvi ai lead di team e ai business leader: parlate con loro prima della demo e chiedete: cosa ti interessa di più, cosa non deve mancare? Raccogliete due-tre punti chiave da ognuno e assicuratevi che in demo si coprano. I vendor sono bravi a gestire il tempo, ma non fatevi problemi a intervenire se serve.

Così tutti sentono di aver contributo e non si sentono ignorati.

Galen Low: Come project manager hai controllo su alcune fasi, ma alcune decisioni spettano realmente alla direzione. Bisogna sempre affidarsi alle priorità dei decision maker, ma assicurandosi di raccogliere input da tutti.

Olivia Montgomery: Esatto. Ricorda che in demo occorre puntare su 3-4 user story da presentare al vendor e chiedere il resto per iscritto tramite RFP o documentazione. Dopo la demo, chiedi sempre dettaglio di costi per codice custom, automazioni, integrazioni extra e specifica chi se ne occuperà. Così ti tieni fuori dai dettagli in demo e usi il tempo per vedere davvero come lavora il software.

Galen Low: Voglio tornare al tema delle due demo divise. Alla fine, il comitato di selezione deve comunque ricompattarsi. Ha senso creare una scheda di valutazione per confrontare in modo oggettivo i prodotti in short-list?

Olivia Montgomery: Adoro le vendor scorecard, sono utilissime e non fuori moda! Eliminano la componente emotiva delle demo troppo commerciali. Tornare sempre al motivo per cui si cerca il software. Con la scorecard si guarda se risponde ai requisiti tecnici e business: se manca uno dei due, non va bene.

Aiutano durante il confronto e vanno conservate per auditing e cambi organizzativi: ogni volta che ti chiedono perché hai escluso un vendor, puoi dimostrarlo. Puoi anche pesare i criteri e avere uno storico consultabile quando serve rivalutare una soluzione.

Come project manager, salva sempre le scorecard: se cambia il CTO, puoi spiegare la scelta e costruire relazioni basate su fiducia e trasparenza.

Galen Low: Tre cose: uno, la scorecard non deve essere generica: deve rispecchiare gli obiettivi, perché stiamo scegliendo il software? Due, meglio scale da 1 a 5, non da 1 a 10, con significato chiaro di ogni valore. Tre, le scorecard possono essere personalizzate per i vari ruoli e team, l’importante è che tutti usino la stessa matrice per tutti i tool in gara. Sei d’accordo?

Olivia Montgomery: Sì, occorre una sola scorecard modello con tutti i requisiti tecnici e di business, ma preciso chi compila quali aree. Tutti possono vedere l’intera scorecard, anche se alcune colonne sono grigiate. Così sanno che altre voci sono rilevanti per altri stakeholder e si favorisce il dialogo: ad esempio, se un IT director dà punteggio basso alle integrazioni, ma il business owner ha ricevuto rassicurazioni commerciali, bisogna chiarire: ci sono rischi, è una custom integration? La discussione va affrontata prima della firma.

Galen Low: Esatto, la scorecard innesca dialoghi di confronto, non determina automaticamente la scelta.

Olivia Montgomery: Assolutamente. Così si evitano tensioni e si resta sui fatti e sui numeri, non su pareri divergenti.

Galen Low: Ricapitolando: dopo le demo, serve raccogliere e consolidare i punteggi. Usi una piattaforma, fai un meeting dedicato, coinvolgi tutti i decisori. Ogni organizzazione sarà diversa, ma serve avere le idee chiare su processo, chi decide, come si documenta tutto.

Olivia Montgomery: Verissimo. Occorre una strategia flessibile, conoscere bene le regole del gioco e chi decide. Può essere un comitato steering in grandi aziende, o solo i direttori di business e IT in realtà più piccole. Meglio preparare tutto in anticipo, così gestisci aspettative e tempistiche, anche a seconda delle risorse a disposizione.

Galen Low: Perfetto, serve lungimiranza: pianificazione, coinvolgimento, comunicazione chiara con vendor e stakeholder, raccolta dati, consolidamento per la decisione finale con tracciabilità auditabile. Così si possono giustificare decisioni a nuovi manager o auditor e si coltivano relazioni di fiducia aziendale.

Olivia Montgomery: Se il coinvolgimento nelle scorecard è difficile, puoi proporre di compilarle insieme in un meeting: dopo le demo, fissate 45 minuti e compilatele insieme, così diventa un esercizio collettivo e di confronto attivo. Spesso ai business leader piace discutere insieme e arrivare al consenso. Ogni azienda ha il suo stile.

Galen Low: Ottima idea. Non è una gara a quiz o una giuria olimpica. È una discussione costruttiva.

In conclusione, non si può rendere tutti felici: come gestisci le aspettative di chi ha partecipato, così che non restino delusi dalla decisione finale?

Olivia Montgomery: Ecco perché le scorecard con pesi sono utili: mai dimenticare perché stai scegliendo il software e non usare il nome del vendor per il progetto, ma concentrarsi sul bisogno di business. La scorecard richiama sempre il problema che si vuole risolvere, non le feature più trendy. Così puoi tornare al punto: magari le dashboard erano bellissime, ma se manca l’integrazione con l’email (un must have), si può spiegare perché la scelta è caduta altrove. La trasparenza è fondamentale.

Galen Low: Il vero valore della scorecard è la trasparenza: serve per audit, chiarezza, per spiegare a chiunque in azienda perché si è presa una decisione e raccogliere rispetto anche da chi aveva altre preferenze.

Olivia Montgomery: L’importante è che la decisione sia rispettata, non che tutti siano felici. Serve un confronto onesto e aperto, così si previene la sfiducia e le scelte imposte senza criterio. Succede spesso che si scelga un tool per motivi personali, invece serve trasparenza.

Galen Low: Olivia, è sempre un piacere averti con noi. Il punto che mi colpisce di più è l’idea delle due demo distinte: il processo decisionale resta condiviso, ma si rispettano le specificità tematiche e si risparmia tempo alle persone. Un consiglio prezioso.

Olivia Montgomery: Meglio dividere: il power user non deve esserci per la parte tecnica pura, rispetti il tempo di tutti e fai emergere tutti i temi nel momento giusto, senza aspettare la fase di implementazione per trovare il consenso tra business e IT.

Galen Low: Ultima domanda. Una domanda-tranello.

Olivia Montgomery: Ancora?

Galen Low: Se sei project manager e vedi che il processo di selezione software è poco rigoroso, magari spinto per motivi personali: come puoi cercare di introdurre oggettività e trasparenza nella selezione?

Olivia Montgomery: Bisogna instaurare un rapporto di rispetto con chi sostiene queste scelte. Capire chi decide davvero. Se la persona non decide, serve coinvolgere chi ha il potere di scelta. Se invece è la persona decisiva, proponi di valutare insieme con una scorecard: spiega che vuoi vedere tutti gli aspetti prima del sì definitivo e coinvolgi tutti nel processo. Il metodo socratico funziona: chiedi di raccontare cosa sa sulle integrazioni e altri punti e lasciagli scoprire eventuali lacune. Mostra l’importanza di confrontare almeno un’alternativa reale e spiega che deve funzionare per business e IT, per presente e futuro. Fate questo lavoro insieme.

Galen Low: Fantastico.

Olivia, è stato un vero piacere averti. Oggi abbiamo fatto un vero deep-dive sul processo di selezione software, specialmente sulla demo e sulla fase decisionale successiva.

Spero che i nostri ascoltatori abbiano trovato valore e non vedo l’ora di averti di nuovo con noi per nuovi approfondimenti e altre domande-tranello!

Olivia Montgomery: Grazie mille per avermi invitata. Spero davvero che sia stato d’aiuto, magari qualcuno ora vede la demo in modo differente, senza subirla passivamente. Adoro parlare con te, Galen. Grazie ancora.

Grazie!

Galen Low: E tu che ne pensi? Una demo software vale il tempo del tuo team o è solo uno show che evita un’analisi più approfondita e pratica? Raccontate la vostra nei commenti qui sotto.

E se vuoi affinare le tue competenze da project leader strategico, vieni a unirti alla nostra community. Vai su thedigitalprojectmanager.com/membership per accedere a una comunità di supporto che condivide conoscenze, risolve sfide complesse e plasma il futuro della nostra professione — insieme.

Da template collaudati e sessioni mensili di formazione che ti fanno risparmiare tempo ed energia, al supporto tra pari nel forum, agli eventi della community e ai gruppi mastermind, essere membro della nostra community significa avere oltre mille persone dalla tua parte mentre navighi la tua carriera nella project delivery digitale.

Se ti è piaciuto quello che hai sentito oggi, iscriviti e resta aggiornato su thedigitalprojectmanager.com.

Alla prossima. Grazie per l’ascolto.