Buondì, e buon lunedì.
Quale è il ruolo che gli utenti hanno nella selezione e adozione del Tech?

 

Qualche lunedì fa ti parlavo di come ci stiamo impegnando per rivedere la nostra business continuity e quindi anche migrare l’intera struttura su nuove tecnologie, e di come stiamo avanzando il più velocemente possibile la roadmap di Catobi Lab, la piattaforma integrata di questa Crew.

 

Tendenzialmente quando si parla di Roadmap di Project Management, si tende a prendere in considerazione due grandi domande:

La tua organizzazione ha determinato la visione del prodotto? La tua organizzazione ha definito una strategia globale per trasformare la visione del prodotto in realtà?

 

Le trovo giustissime entrambe, ma non sufficienti.
È chiaro ed evidente a tutti che una roadmap ben fatta, ti permette:

  • Avere un quadro stabile per negoziare con il tuo team una serie di processi necessari per raggiungere gli obiettivi dell’organizzazione.
  • Visualizzare chiaramente il piano completo, permettendoti di prevedere ulteriori passaggi;
  • Essere in grado di monitorare accuratamente le prestazioni delle attività e coordinare i collaboratori.

 

Come è anche vero che la gestione dei progetti è un lavoro estremamente complesso. Richiede enormi capacità di pianificazione e un alto livello di auto-organizzazione. Ma non solo e non parlo di una buona scelta di software.

 

Parlo di come la roadmap sia preda di influenze.

 

GO↓

La roadmap.

La struttura strategica.

 

Si ritiene che questo metodo sia stato implementato per la prima volta da Motorola negli anni ’80, che definì la roadmap come an extended look at the future”. Naturalmente, a partire dagli anni ’80, sono state espresse molte altre definizioni e opinioni. Ma hanno alcune cose in comune.

 

Sono tutti d’accordo sul fatto che la pianificazione della roadmap offre numerosi vantaggi vitali per un’azienda, tra cui:

  • Allineare gli investimenti e l’R&D con gli obiettivi e la strategia
  • Raggiungere un consenso sulle priorità e sulle azioni richieste
  • Promuovere la comunicazione tra le varie parti interessate
  • Mantenere i partecipanti sulla stessa onda.

 

Che qualsiasi roadmap dovrebbe rispondere a tre domande fondamentali :

  1. Cosa vogliamo ottenere?
  2. Dove siamo adesso?
  3. Come raggiungiamo i nostri obiettivi?

 

Ma anche perché è fondamentale cogliere alcuni concetti quando inizi a pianificare la tua strategia:

 

→ Visione

Immaginare che la tua organizzazione raggiunga i suoi obiettivi, perché non vuoi che i tuoi obiettivi siano posti nel vuoto, ma legati a problemi e background reali.

 

→ Pensiero strutturale

Non poteva mancare lei, la legge di Pareto: il principio per cui il 20% dei nostri sforzi genera l’80% dei risultati e viceversa. Bene, potresti dire che il pensiero strutturale è ciò che usi per determinare quel 20%.

 

In breve, in Catobi, facciamo così:

  • Scegli il tuo grande obiettivo
  • Esplodi gli obiettivi secondari
  • Esplodi sotto-obiettivi
  • Usa gli obiettivi secondari per definire le milestones

 

  1. Non dimenticare di impostare i KPI per ogni livello→ Analisi GAPUsando questo metodo, puoi identificare i punti critici: il divario tra il tuo As-is e il tuo To-be. Può variare in molti modi, ti racconto come funziona da noi:
  • Definisci i componenti chiave della tua attività 
  • Determina come questi componenti devono essere modificati 
  • Analizza le capacità organizzative per influenzare i componenti. 
  • Scegli la soluzione tecnologica.

 

→ Balance Score Card

Redigere la Roadmap sul principio della BSC che includa:

  • Elenco di componenti o dimensioni
  • Elenco di ciò che deve essere modificato su di loro
  • Azioni specifiche per cambiarlo
  • Risultato previsto o benefici di questi cambiamenti

 

NB. Sii incrementale. Mai costruire un piano a lungo termine rigido.

 

Insomma abbiamo sempre utilizzato una checklist di controllo per la creazione di una Roadmap funzionante, ma non stavamo prendendo in considerazione un interessante aspetto ↓

Esercizio di Influenza

Il ruolo delle persone.

 

Secondo Craig Roth e Jeff Chamberlain, è necessario comprendere la voce dell’utente, in pratica il ruolo che gli utenti svolgono nella selezione e adozione del software. Un’analisi dei comportamenti che ha creato 5 cluster di utenti.

 

→ Acceptors
Un gruppo che prende qualsiasi software viene loro fornito e raramente si lamentano. Ritengono che il nuovo software raramente, o mai, interrompa il loro lavoro o richieda troppo tempo e sforzi per essere appreso. Non hanno alcun interesse a partecipare alle decisioni tecnologiche per la loro azienda.

 

→ Venters
Sono il gruppo più propenso a lamentarsi del software con i loro colleghi, ma non commentano mai pubblicamente. Percepiscono maggiormente il rischio che il nuovo software occasionalmente interrompa il loro lavoro o richieda troppo tempo e fatica, ma non fanno molto al riguardo.

 

→ Drivers
Sono il campione interno ideale. Se non sono soddisfatti, lavorano con l’IT per risolvere i problemi e sono abbastanza disposti, se soddisfatti del software, a investire più tempo nell’apprendimento di funzionalità avanzate. Inoltre personalizzeranno e adatteranno il software a loro piacimento. Amano essere coinvolti nelle decisioni tecnologiche.

 

→ Doubters
I Doubters sono simili ai Venters, ma molto più propensi a condividere problemi (sia positivi che negativi) pubblicamente. Generalmente hanno una mentalità negativa nei confronti del nuovo software, essendo il gruppo più propenso a dire che il nuovo software interrompe spesso il lavoro, ma hanno interesse a essere coinvolti nelle decisioni tecnologiche, ma tendenzialmente per essere oppositori al cambiamento.

 

→ Lobbyists
Sono meno interessati a essere coinvolti nelle decisioni tecnologiche a livello aziendale. Se queste persone non sono soddisfatte del software, è più probabile che facciano tutto il possibile per farlo deragliare, sia internamente che esternamente. Ma vale anche il contrario, se funziona bene. Ritengono che il nuovo software occasionalmente abbia un impatto negativo su di loro.

 

Quando lo leggi, ti sembra di averlo sempre saputo, anche a me.
Ma prova a risponderti, ad esempio, a questa domanda:

  • Chi inviti alla riunione strategica in fase di Discovery?

 

Considerando questi 5 cluster, abbiamo creato una regola, che va applicata così:

  • Per risolvere un problema, invita da quattro a sei persone
  • Per prendere una decisione, invita da quattro a sette persone
  • Per impostare un ordine del giorno, invita da cinque a 15 persone
  • Per fare un brainstorming, invita da 10 a 20 persone

 

Le uniche persone che partecipano alla tua riunione dovrebbero essere quelle che hanno assolutamente bisogno di parteciparvi.

 

Le altre sono ininfluenti.

Questo è Remarks. Il Touchpoint digitale di Catobi. Se ti fa piacere continuare a parlare di questi temi, ti basta iscriverti qui→

Carlo Tommaso Bisaccioni | Catobi

Buondì, e buon lunedì.
Quale è il ruolo che gli utenti hanno nella selezione e adozione del Tech?

 

Qualche lunedì fa ti parlavo di come ci stiamo impegnando per rivedere la nostra business continuity e quindi anche migrare l’intera struttura su nuove tecnologie, e di come stiamo avanzando il più velocemente possibile la roadmap di Catobi Lab, la piattaforma integrata di questa Crew.

 

Tendenzialmente quando si parla di Roadmap di Project Management, si tende a prendere in considerazione due grandi domande:

La tua organizzazione ha determinato la visione del prodotto? La tua organizzazione ha definito una strategia globale per trasformare la visione del prodotto in realtà?

 

Le trovo giustissime entrambe, ma non sufficienti.
È chiaro ed evidente a tutti che una roadmap ben fatta, ti permette:

  • Avere un quadro stabile per negoziare con il tuo team una serie di processi necessari per raggiungere gli obiettivi dell’organizzazione.
  • Visualizzare chiaramente il piano completo, permettendoti di prevedere ulteriori passaggi;
  • Essere in grado di monitorare accuratamente le prestazioni delle attività e coordinare i collaboratori.

 

Come è anche vero che la gestione dei progetti è un lavoro estremamente complesso. Richiede enormi capacità di pianificazione e un alto livello di auto-organizzazione. Ma non solo e non parlo di una buona scelta di software.

 

Parlo di come la roadmap sia preda di influenze.

 

GO↓

La roadmap.

La struttura strategica.

 

Si ritiene che questo metodo sia stato implementato per la prima volta da Motorola negli anni ’80, che definì la roadmap come an extended look at the future”. Naturalmente, a partire dagli anni ’80, sono state espresse molte altre definizioni e opinioni. Ma hanno alcune cose in comune.

 

Sono tutti d’accordo sul fatto che la pianificazione della roadmap offre numerosi vantaggi vitali per un’azienda, tra cui:

  • Allineare gli investimenti e l’R&D con gli obiettivi e la strategia
  • Raggiungere un consenso sulle priorità e sulle azioni richieste
  • Promuovere la comunicazione tra le varie parti interessate
  • Mantenere i partecipanti sulla stessa onda.

 

Che qualsiasi roadmap dovrebbe rispondere a tre domande fondamentali :

  1. Cosa vogliamo ottenere?
  2. Dove siamo adesso?
  3. Come raggiungiamo i nostri obiettivi?

 

Ma anche perché è fondamentale cogliere alcuni concetti quando inizi a pianificare la tua strategia:

 

→ Visione

Immaginare che la tua organizzazione raggiunga i suoi obiettivi, perché non vuoi che i tuoi obiettivi siano posti nel vuoto, ma legati a problemi e background reali.

 

→ Pensiero strutturale

Non poteva mancare lei, la legge di Pareto: il principio per cui il 20% dei nostri sforzi genera l’80% dei risultati e viceversa. Bene, potresti dire che il pensiero strutturale è ciò che usi per determinare quel 20%.

 

In breve, in Catobi, facciamo così:

  • Scegli il tuo grande obiettivo
  • Esplodi gli obiettivi secondari
  • Esplodi sotto-obiettivi
  • Usa gli obiettivi secondari per definire le milestones

 

  1. Non dimenticare di impostare i KPI per ogni livello→ Analisi GAPUsando questo metodo, puoi identificare i punti critici: il divario tra il tuo As-is e il tuo To-be. Può variare in molti modi, ti racconto come funziona da noi:
  • Definisci i componenti chiave della tua attività 
  • Determina come questi componenti devono essere modificati 
  • Analizza le capacità organizzative per influenzare i componenti. 
  • Scegli la soluzione tecnologica.

 

→ Balance Score Card

Redigere la Roadmap sul principio della BSC che includa:

  • Elenco di componenti o dimensioni
  • Elenco di ciò che deve essere modificato su di loro
  • Azioni specifiche per cambiarlo
  • Risultato previsto o benefici di questi cambiamenti

 

NB. Sii incrementale. Mai costruire un piano a lungo termine rigido.

 

Insomma abbiamo sempre utilizzato una checklist di controllo per la creazione di una Roadmap funzionante, ma non stavamo prendendo in considerazione un interessante aspetto ↓

Esercizio di Influenza

Il ruolo delle persone.

 

Secondo Craig Roth e Jeff Chamberlain, è necessario comprendere la voce dell’utente, in pratica il ruolo che gli utenti svolgono nella selezione e adozione del software. Un’analisi dei comportamenti che ha creato 5 cluster di utenti.

 

→ Acceptors
Un gruppo che prende qualsiasi software viene loro fornito e raramente si lamentano. Ritengono che il nuovo software raramente, o mai, interrompa il loro lavoro o richieda troppo tempo e sforzi per essere appreso. Non hanno alcun interesse a partecipare alle decisioni tecnologiche per la loro azienda.

 

→ Venters
Sono il gruppo più propenso a lamentarsi del software con i loro colleghi, ma non commentano mai pubblicamente. Percepiscono maggiormente il rischio che il nuovo software occasionalmente interrompa il loro lavoro o richieda troppo tempo e fatica, ma non fanno molto al riguardo.

 

→ Drivers
Sono il campione interno ideale. Se non sono soddisfatti, lavorano con l’IT per risolvere i problemi e sono abbastanza disposti, se soddisfatti del software, a investire più tempo nell’apprendimento di funzionalità avanzate. Inoltre personalizzeranno e adatteranno il software a loro piacimento. Amano essere coinvolti nelle decisioni tecnologiche.

 

→ Doubters
I Doubters sono simili ai Venters, ma molto più propensi a condividere problemi (sia positivi che negativi) pubblicamente. Generalmente hanno una mentalità negativa nei confronti del nuovo software, essendo il gruppo più propenso a dire che il nuovo software interrompe spesso il lavoro, ma hanno interesse a essere coinvolti nelle decisioni tecnologiche, ma tendenzialmente per essere oppositori al cambiamento.

 

→ Lobbyists
Sono meno interessati a essere coinvolti nelle decisioni tecnologiche a livello aziendale. Se queste persone non sono soddisfatte del software, è più probabile che facciano tutto il possibile per farlo deragliare, sia internamente che esternamente. Ma vale anche il contrario, se funziona bene. Ritengono che il nuovo software occasionalmente abbia un impatto negativo su di loro.

 

Quando lo leggi, ti sembra di averlo sempre saputo, anche a me.
Ma prova a risponderti, ad esempio, a questa domanda:

  • Chi inviti alla riunione strategica in fase di Discovery?

 

Considerando questi 5 cluster, abbiamo creato una regola, che va applicata così:

  • Per risolvere un problema, invita da quattro a sei persone
  • Per prendere una decisione, invita da quattro a sette persone
  • Per impostare un ordine del giorno, invita da cinque a 15 persone
  • Per fare un brainstorming, invita da 10 a 20 persone

 

Le uniche persone che partecipano alla tua riunione dovrebbero essere quelle che hanno assolutamente bisogno di parteciparvi.

 

Le altre sono ininfluenti.

Questo è Remarks. Il Touchpoint digitale di Catobi. Se ti fa piacere continuare a parlare di questi temi, ti basta iscriverti qui→

Carlo Tommaso Bisaccioni | Catobi

Il nutrimento della tua strategia di Business
Tutti i lunedì mattina alle 9.00
Nella tua Inbox. È gratis
Metodi e strumenti per abilitare l’innovazione nella tua azienda

    Accetto la privacy di Catobi