White paper - C'è un pilota a bordo?

Importante :  Il presente articolo è stato tradotto automaticamente, vedere la dichiarazione di non responsabilità. Per visualizzare la versione inglese dell'articolo, fare clic qui.

"C'è un pilota a bordo?" è una domanda che nessun passeggero si augura mai di sentire. Ho riletto uno straordinario articolo di cronaca su un incidente come questo realmente accaduto a dicembre 2013. Quando il pilota di un volo proveniente da Des Moines si è sentito improvvisamente male, il copilota ha chiesto se ci fosse un pilota a bordo. Il capitano Mark Gongol, pilota di cacciabombardieri dell'aeronautica militare USA, si è offerto di prendere il suo posto. L'aereo, i passeggeri e il personale di bordo sono tutti atterrati senza problemi.

Si tratta di una bella storia, ma il motivo che mi ha spinto di recente a rileggerla è da attribuire a qualcosa di completamente diverso. Un nostro potenziale cliente ha chiamato e ci ha chiesto se poteva realizzare un progetto "pilota" del nostro software di schede attività per i progetti dell'organizzazione. Questi tipi di richieste mi lasciano sempre un po' perplesso. Il significato della parola "pilota" in un aereo è ben chiaro a tutti, ma quando qualcuno valuta le opzioni software e parla di progetto "pilota" non sono altrettanto sicuro.

Il termine "pilota" nel mondo del software è spesso associato ad altri metodi di valutazione complessi, come la "prova di concetto". Esaminiamo cosa significano questi termini e come usarli al meglio in un processo di valutazione aziendale.

Prova di concetto

Questo termine risale a molti anni fa ed è molto diffuso nell'ingegneria elettrica. Il "breadbording" veniva creato per vedere se era possibile realizzare un circuito, non per iniziare a metterlo in produzione. Nella fase di prova di concetto, si poteva trascorrere più tempo in laboratorio che non a creare il circuito in produzione, ma l'unica conseguenza negativa poteva essere un danno arrecato al solo circuito stampato a cui si stava lavorando. Si trattava di un metodo economico e a basso rischio per dimostrare che un circuito elettrico poteva offrire il risultato previsto.

In termini di software, l'obiettivo di una prova di concetto dovrebbe essere quello di dimostrare qualcosa. Quando i potenziali clienti chiamano per chiedere se posso aiutarli a realizzare una prova di concetto per un software di gestione di progetti o di schede attività, pongo sempre la stessa domanda: "Quali concetti volete provare?"

La risposta che segue in genere è il silenzio o un'espressione confusa.

Se si vuole condurre una prova di concetto e non si ha idea di cosa si stia cercando di provare, come si può determinare se il risultato è un successo o un fallimento? Ovviamente, non c'è modo.

Perché allora, ci si potrebbe chiedere, qualcuno dovrebbe pensare a effettuare una prova di concetto? La risposta più comune è che il richiedente non ha probabilmente il necessario supporto da parte del management per implementare il software che sta esaminando e si augura che eseguendolo davanti ai dirigenti riesca a convincerli della validità dell'idea e a farsi approvare l'implementazione. In questo caso la "prova" è rivolta al management e il "concetto" è l'intera idea del software aziendale.

Se fosse così facile convincere i dirigenti che il software di gestione di progetti e schede attività dell'organizzazione è la scelta giusta per loro, ne distribuiremmo molto di più.

Il problema con questo metodo è che il lavoro che sarà possibile svolgere per realizzare una specifica istanza di una prova di concetto non avrà molto probabilmente lo stesso livello di supporto che si otterrebbe con l'implementazione in produzione di un sistema aziendale. Quando un'organizzazione implementa un sistema aziendale, ad esempio per la gestione di progetti o schede attività, è necessario soddisfare molti requisiti per trasformarlo in un successo. Prima di tutto, sarà necessario l'input del management e del personale che userà il prodotto per tutti gli aspetti dell'organizzazione coinvolti nell'implementazione. Poi, sarà necessario avere del tempo per la configurazione, l'assistenza dei servizi tecnici per il collegamento ad altri sistemi dell'organizzazione, la sponsorizzazione del management, il tempo per la formazione e ovviamente un contributo economico.

Se non si soddisfano questi requisiti, come sarà il sistema che si può completare nella prova di concetto? Nella migliore delle ipotesi sarà soltanto un abbozzo della soluzione prevista. Nell'odierna era del cloud, è probabile che si possa accedere a un sistema completamente ospitato, quindi almeno non ci si dovrà preoccupare di acquistare server e software, ma la semplice installazione di un sistema rappresenta solo una piccola percentuale del lavoro richiesto per realizzare anche una sola implementazione di base della prova di concetto.

È facile capire perché le aziende esiteranno a destinare ingenti somme di denaro e risorse all'implementazione di qualcosa che può avere un potenziale impatto sull'intera organizzazione. Si tratta di un'impresa ad alto rischio. In genere si tende a parlare solo dei vantaggi del software di gestione dei progetti dell'organizzazione, ma è facile immaginare che se lo stesso progetto fallisce si potrà avere un impatto negativo della stessa entità. Quindi è ovvio che ci si preoccupi di alleviare i rischi. Ma se la vera sfida consiste nel convincere il management sui vantaggi del sistema, esistono sicuramente modi migliori per farlo. Noi di HMS Software siamo orientati verso alcune tecniche seguenti:

  1. Parlare con un cliente reale già consolidato.

    Siamo fortunati ad avere alcuni clienti validi che sono piuttosto soddisfatti. Quando un nuovo cliente potenziale ha dei dubbi su quello a cui andrà incontro, lo facciamo incontrare con un attuale cliente. In molti casi il cliente è abbastanza generoso da offrire un incontro di persona. In altri casi si scambiano telefonate a cui noi deliberatamente non partecipiamo. Da parte nostra, invitiamo il cliente a condividere sia le buone notizie che le sfide.

  2. Presentare prove concrete.

    Se il cliente potenziale vuole una dimostrazione pratica, possiamo fornirgliela noi. Esistono validi motivi per cui è necessario provare prima alcuni aspetti di determinate implementazioni. Magari saranno coinvolte grandi quantità di uno specifico tipo di dati. Una volta ad esempio ci hanno chiesto di dimostrare che la nostra soluzione funzionava con un carico di lavoro particolarmente grande. Ci è stato chiesto di dimostrare la compatibilità del software con determinati browser o con specifici database o il collegamento con particolari versioni di alcuni sistemi esterni. Se questo tipo di concetto blocca la valutazione, le persone più indicate per superare la sfida sono gli esperti in materia.

  3. Offrire formazione.

    Nel caso in cui il cliente potenziale debba assolutamente dimostrare che il sistema funziona con i suoi dati e se usato dal suo personale, possiamo aiutare a caricare i dati in un sistema ospitato, quindi eseguire un minimo di configurazione del sistema come richiesto dal cliente e formare le persone che saranno coinvolte. Preferiamo decisamente andare nell'azienda per aiutare con la dimostrazione, ma se non è possibile, chiediamo di esaminare quello che le persone coinvolte useranno e proponiamo di modificarlo o di formare le persone nel modo appropriato.

Dov'è un pilota quando ne serve uno?

Il progetto pilota può rivelarsi in effetti la scelta migliore. Se viene chiesto di stabilire una distribuzione pilota di un sistema di gestione dei progetti o di schede attività dell'organizzazione, è necessario prima di tutto stabilire gli obiettivi. Se gli obiettivi riguardano solo la prova di concetto, allora non si tratta affatto di un programma pilota.

Un progetto pilota è una distribuzione attiva, reale e in produzione. Coinvolge in genere un sottoinsieme della base totale di utenti considerati per il sistema da valutare e pertanto è probabile che richieda del tempo. Anche se vengono considerate fin dall'inizio le esigenze della base completa di utenti di destinazione, il programma pilota si focalizza su un'implementazione reale per il solo gruppo di utenti pilota. Questi utenti gestiranno effettivamente i progetti o compileranno le schede attività con il nuovo sistema.

Durante l'implementazione pilota verranno affrontate le stesse sfide poste da una distribuzione completa di produzione, ad eccezione del volume o della complessità dei dati. Le sfide più comuni dei progetti pilota che ho visto finora includono la mancanza di sponsorizzazione, la carenza di budget, tempo e risorse e, probabilmente peggio di tutto, la mancanza di obiettivi articolati che consentano di stabilire se il progetto pilota è riuscito o meno.

Questo non vuol dire che i progetti pilota non siano validi. Possono infatti rivelarsi utili e possono servire ad alleviare il rischio che una distribuzione incompleta o mal configurata possa avere conseguenze negative sull'intera organizzazione. Ma per il successo di un progetto pilota è necessaria una riflessione approfondita.

Abbiamo da poco iniziato a occuparci di una distribuzione di dimensioni significative per un ente pubblico. L'aspetto gratificante è che l'ente ha già dedicato tutto il tempo necessario a completare la valutazione, scegliendo alla fine il sistema aziendale da acquisire, che fortunatamente è il nostro. Durante l'anno scorso abbiamo collaborato con il loro team di valutazione per assicurarci di rispondere alle loro domande tecniche, ma ora l'obiettivo punta all'impatto sui processi quotidiani delle persone dell'organizzazione.

Ci hanno proposto di lavorare per un periodo di 6 mesi con un gruppo che, anche se nutrito, rappresenta comunque solo il 10% del totale. Il budget previsto è adeguato, il programma pilota ha il supporto del management ai livelli più elevati e abbiamo tutto il tempo necessario per assicurarci di poter assistere con tutte le attività che normalmente svolgiamo in distribuzioni come questa. Il gruppo che verrà inserito in questo ambiente di gestione di progetto e schede attività lo userà in produzione nel prossimo futuro, quindi non si tratta solo di un test, ma sarà effettivamente la prima fase della distribuzione, non una prova "per vedere come va". Considerando tutti questi fattori, prevediamo di ottenere un risultato positivo alla fine di quest'anno.

Conclusioni

I progetti pilota e le prove di concetto sono realtà incontestabili nel software aziendale, ma per trasformarli in un successo è necessario evidenziare alcuni fattori chiave per le persone coinvolte:

  1. Prima di tutto, assicurarsi di aver articolato chiaramente gli obiettivi.

  2. Poi, verificare che il management sia consapevole dei requisiti e intenda offrire il supporto necessario in termini economici, di risorse e di tempo al fine di raggiungere questi obiettivi.

  3. Infine, assicurarsi di creare un piano di progetto e di gestirlo come qualsiasi altro progetto del portfolio.

Informazioni sull'autore

Chris Vandersluis è presidente e fondatore di HMS Software, un Microsoft Certified Partner, con sede a Montreal, in Canada. Ha una laurea in economia della McGill University e vanta un'esperienza più che trentennale nell'automazione dei sistemi di controllo dei progetti. È un membro di lunga data del Project Management Institute (PMI) e ha contribuito a fondare le sedi di Montreal, Toronto e Quebec del Microsoft Project Users Group (MPUG). Le pubblicazioni a cui Chris ha contribuito includono Fortune, Heavy Construction News, Computing Canada magazine, PMI’s PMNetwork e Project Times. Insegna il corso di Advanced Project Management alla McGill University e partecipa spesso come relatore ad eventi delle associazioni sulla gestione dei progetti in America del Nord e in tutto il mondo. HMS Software ha pubblicato TimeControl, un sistema di controllo del tempo orientato ai progetti, ed è un Microsoft Project Solution Partner dal 1995.

Chris Vandersluis può essere contattato tramite posta elettronica all'indirizzo chris.vandersluis@hms.ca

Per altre altri articoli su EPM scritti da Chris Vandersluis, visitare il blog EPM Guidance (http://www.epmguidance.com/?page_id=39).

Nota : Dichiarazione di non responsabilità per la traduzione automatica: Il presente articolo è stato tradotto tramite un software di traduzione automatica e non da una persona. Microsoft offre le traduzioni automatiche per consentire a coloro che non conoscono la lingua inglese di leggere gli articoli sui prodotti, sui servizi e sulle tecnologie Microsoft. Dal momento che l'articolo è stato tradotto automaticamente, potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli.

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

Grazie per i tuoi commenti e suggerimenti

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×