robot pointing on a wall

Quando il saggio indica la governance, lo stolto guarda l’AI

/in , , /by

Quando faccio progetti (di strategia, di riorganizzazione del marketing, di introduzione dell’AI), un’interessante situazione nella quale mi imbatto (credo comune a molti e molte) è che ci sono alcune incomprensioni iniziali che non sono tecnologiche: le persone fanno fatica a identificare cosa vogliono risolvere (dove spesso il racconto è focalizzato su sintomi e soluzioni) e le organizzazioni non hanno deciso chi può decidere cosa (per cui c’è un momento di lentezza per capire qual è il giro del fumo).

Non è una novità e il fatto che si riproponga in contesti diversi, con strumenti diversi, in aziende di dimensioni diverse è per me interessante. L’AI adesso è solo l’ultimo sintomo, più visibile degli altri perché arriva con aspettative alte e risultati spesso deludenti.

Il risultato è prevedibile: si introducono strumenti senza rivedere i processi, si ottimizza localmente quello che si rompe sistemicamente, si crea nuovo muda (spreco) credendo di eliminarlo 1.

Tre problemi concreti che trovo in sequenza, quasi sempre in quest’ordine.

Primo problema: non sai cosa stai risolvendo

L’errore più comune (nell’introduzione di qualsiasi strumento, AI inclusa) non è scegliere la soluzione sbagliata, ma è scegliere la soluzione prima di aver definito il problema.

Usiamo l’AI per fare le sintesi delle riunioni.

Bene. E quelle sintesi le usa qualcuno? Generano decisioni? Cambiano qualcosa?

No, ma almeno le abbiamo.

Questo è waste con un’interfaccia moderna. Nessuno strumento lo trasforma in valore, lo produce più velocemente (il famigerato AI Slop).

Prima di qualsiasi introduzione serve una domanda brutalmente semplice: qual è il problema che stiamo cercando di risolvere, e come fa questo strumento a risolverlo? Se la risposta è vaga, il problema non è ancora definito. E se il problema non è definito, qualsiasi soluzione è prematura. 2

Ma c’è un prerequisito ancora più a monte, che ho affrontato nel post precedente: per definire un problema con sufficiente precisione da poterlo delegare (a un collaboratore, a un team, a un sistema AI) hai bisogno di conoscenza dichiarativa, la capacità di descrivere quello che fai, i criteri con cui decidi, il risultato che vuoi ottenere. Chi non ha sviluppato questa competenza non riesce a identificare il problema in modo utilizzabile e finisce per delegare un compito che nemmeno lui sa definire con precisione 3.

C’è poi una seconda domanda da fare, che viene quasi mai fatta:

questo è un problema mio, del mio team, o dell’organizzazione?

Perché la risposta cambia completamente chi deve risolverlo, con quali strumenti e con quale livello di autonomia.

Secondo problema: non hai deciso chi può decidere cosa

Che si tratti di riorganizzare il marketing, introdurre un nuovo processo o adottare strumenti AI, il problema sottostante è quasi sempre lo stesso: manca una struttura chiara di governance. Chi può usare quali strumenti, per quali attività, con quali output attesi, con quale livello di autonomia non è sempre chiaro perché è parte (più frequentemente di quanto vorrei) di una conoscenza implicita, non dichiarata e che quindi deve essere trovata.

Senza questa struttura succedono due cose opposte e ugualmente dannose.

  • La prima: le persone non agiscono perché non sanno se possono, se devono, se è appropriato.
  • La seconda: le persone agiscono in modo non coordinato, producendo output incompatibili, processi ridondanti, e una frammentazione del lavoro che è peggio della situazione di partenza.

Quello che serve (e che poche organizzazioni hanno costruito in modo esplicito) è qualcosa che somiglia a una costituzione dell’autonomia 4: un insieme di principi chiari che definisce le aree in cui il problem solving locale è abilitato e le aree in cui serve coordinamento. Non un manuale operativo non una policy di 40 pagine. Un frame che risponde a: cosa puoi decidere da solo, cosa devi concordare, cosa non puoi fare senza autorizzazione esplicita.

Senza questo frame, ogni persona e ogni team risolve il problema come può, con gli strumenti che ha, secondo criteri che non sono condivisi. L’organizzazione diventa una collezione di ottimizzazioni locali che non si sommano mai in efficienza sistemica.

5

Terzo problema: il lavoro di orchestrazione frammenta l’attenzione

Quando nuovi strumenti entrano nel flusso di lavoro (e l’AI lo fa in modo particolarmente pervasivo) il lavoro cambia natura. Non scompare: si trasforma. Meno produzione diretta, più orchestrazione: definire il task, verificare l’output, correggere, iterare, integrare.

Questo sembra un miglioramento. In parte lo è, ma introduce un effetto collaterale che si rischia di sottovalutare: la frammentazione dell’attenzione.

Se ogni quindici minuti verifico l’output di un processo delegato (a un agente AI, a un collaboratore remoto, a un sistema automatizzato) sto lavorando su più cose contemporaneamente in modo strutturale (e ho già mostrato in un post precedente cosa produce il multitasking sul rendimento “Perché è pericoloso lavorare su più progetti”): il multitasking non è un’abilità. È un costo.

Il context switching non sparisce con l’AI, si moltiplica, perché le istanze di lavoro si moltiplicano.

Questo ha un’implicazione diretta su come organizzare il lavoro: non per attività, ma per blocchi di risultato.

La domanda non è “cosa faccio adesso?” ma “qual è il risultato che voglio avere al termine di questo blocco di tempo, e come organizzo gli strumenti per ottenerlo senza dover verificare ogni quindici minuti?” e oltretutto torniamo a un ripensamento profondo delle attività per evitare di rendere più inefficienti processi non pensati per l’AI.

Il focus si sposta ancor di più dall’attività all’impatto ovvero dal tempo lavorato al risultato prodotto. Non è una novità concettuale (è la logica del lavoro per obiettivi, degli OKR, di qualsiasi approccio che mette il risultato prima del processo).

Ma la moltiplicazione degli strumenti rende questa transizione non più opzionale.

6

Il problema dell’accountability che nessuno vuole affrontare

C’è un quarto problema, che non viene quasi mai nominato esplicitamente: è il più scomodo, ed è quello che rischia di avere le conseguenze più serie in particolare con l’AI, ma non solo.

Chi risponde quando qualcosa va storto?

Per rispondere con precisione, possiamo sfruttare uno strumento che il project management usa da decenni: una RAM, Responsibility Assignment Matrix, una matrice che mappa ruoli e responsabilità su attività o deliverable. Il PMBOK del PMI la definisce come strumento per illustrare le connessioni tra work package e membri del team di progetto 7.

La RACI (il tipo di RAM più usato) assegna a ogni attività quattro ruoli: chi esegue (Responsible), chi risponde del risultato (Accountable), chi viene consultato (Consulted), chi viene informato (Informed). Una regola fondamentale, ribadita dal PMBOK: per ogni attività deve esserci un solo Accountable. Non due. Non nessuno. Uno.

Ora prova ad applicare questa logica a un processo che include un sistema AI.

L’AI non può essere Accountable, per lo meno non nel senso tecnico del termine. Accountable significa rispondere del risultato, avere skin in the game, subire le conseguenze di una decisione sbagliata. Un sistema non risponde, non subisce conseguenze, non impara nel senso in cui impara una persona che ha sbagliato e ne porta il peso.

Questo non è un problema filosofico, è un problema operativo immediato.

In questo momento, tutta la responsabilità dell’output di un sistema AI ricade sull’operatore, la persona o l’organizzazione che ha scelto di usarlo, che lo ha configurato, che ha accettato il risultato. Anche quando il risultato è sbagliato. Anche quando l’errore era nel modello, nel training data, in una deriva che l’utente non aveva modo di prevedere.

Il parallelo più preciso è quello della guida autonoma. In caso di incidente, chi risponde? Il guidatore che non aveva le mani sul volante? Il produttore del software? La casa automobilistica? La risposta legale è ancora in costruzione, ma la risposta operativa attuale è che il guidatore è Accountable, perché era nella posizione di controllo.

Con l’AI in azienda funziona esattamente così. L’operatore risponde sempre. Anche se ha fatto “tutto bene”. La delega al sistema non riduce la responsabilità, la maschera, finché non emerge il problema.

Questo ha due implicazioni concrete che le organizzazioni quasi mai considerano esplicitamente.

  1. Il livello di controllo iniziale non può essere basso. Un sistema AI non è un collaboratore che ha già dimostrato di meritare autonomia. È un sistema che deve guadagnarsi la fiducia attraverso output verificati, iterazioni corrette, perimetri testati. Il controllo non è inefficienza, ma è il costo necessario di un sistema che non può essere Accountable per sé stesso.
  2. Il controllo non può probabilmente essere mai eliminato del tutto. Può essere ridotto, può essere spostato, può essere automatizzato in parte, ma la catena di accountability deve sempre terminare in una persona. Non in un sistema. Non in un processo. In qualcuno che può rispondere.

Questo è il motivo per cui introdurre qualsiasi strumento senza aver prima definito la governance dell’autonomia non è solo inefficiente. È un rischio che l’organizzazione sta assumendo senza averlo nominato (soprattutto in una narrazione dove adesso possiamo fare più cose: facciamo più cose, ma come le controlliamo senza diventare controllori a tempo pieno?).

Da dove si parte

Da tre domande, in quest’ordine.

La prima: qual è il problema che voglio risolvere? Torniamo sempre allo SMART: Specifico, misurabile, collegato a un risultato atteso. Se la risposta è vaga, il lavoro è ancora a monte e prima di rispondere serve la capacità di descrivere il proprio lavoro con sufficiente precisione dichiarativa.

Senza quella, il problem solving rimane procedurale: si agisce per intuizione, non per definizione 8 .

La seconda: chi è Accountable del risultato, e come lo verifico? Senza questa risposta l’organizzazione sta delegando responsabilità a qualcuno o qualcosa che non può tenerla.

La terza: come organizzo il lavoro per evitare che l’orchestrazione frammenti l’attenzione più di quanto lo strumento la liberi? Il guadagno di efficienza si perde se il context switching diventa strutturale.

L’AI è uno strumento potente, ma il problema che trovo spesso negli assessment non è mai lo strumento: è sempre la struttura che manca prima dello strumento e la struttura, come quasi sempre, non è un problema tecnologico 9.

Altri approfondimenti interessanti:

Report Deloitte – State of AI in the Enterprise – Solo il 21% delle imrpese ha pensato/impostato una governance per gli agenti AI

Riflessione di Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura

Notes:

  1. Ne ho scritto estesamente in “AI: può avere effetti collaterali, leggere il foglio illustrativo” — il punto Lean/VSM è preciso: automatizzare un’attività inefficiente non la rende efficiente, la rende inefficiente più velocemente. ↩
  2. Il frame del problem framing non è nuovo: Thomas Wedell-Wedellsborg lo ha articolato bene in “What’s Your Problem?”. TLDR: il modo in cui definisci un problema determina quali soluzioni riesci a vedere. Cambia il frame, cambia la soluzione, spesso radicalmente. ↩
  3. “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” — il punto centrale: chi non riesce a descrivere il proprio lavoro non riesce a delegarlo. Né a un junior, né a un sistema AI. La conoscenza procedurale non è trasferibile finché non diventa dichiarativa. ↩
  4. Ciao Holocracy, sì, sto guardando te e le tue bellissime impostazioni: consiglio di guardare https://www.holacracy.org/ Ci sono poi altri elementi interessanti come il Ren Den Hey, Sociocracy etc. ↩
  5. Ho già scritto del problema dell’ottimizzazione locale in “L’AI tra Hype e Processi”: l’efficienza su un pezzo del processo non è efficienza del processo. Il Value Stream Mapping lo rende evidente — il collo di bottiglia non è mai dove pensi. ↩
  6. L’impatto sui team di lavoro è già in corso — ne ho scritto in “L’impatto dell’AI sui team di lavoro”: l’efficienza sulla produzione sposta l’attenzione su decisioni e priorità. Il problema è che molte organizzazioni non hanno ancora spostato i criteri di valutazione delle persone nella stessa direzione. Si misura ancora il tempo, non il risultato. ↩
  7. PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), www.pmi.org. La RAM è descritta nella sezione dedicata alla gestione delle risorse di progetto. Il PMBOK cita la RACI come esempio di RAM — non come framework autonomo. La RACI (Responsible, Accountable, Consulted, Informed) è un tipo specifico di RAM, probabilmente il più diffuso, ma non l’unico: esistono varianti con designazioni diverse a seconda del contesto di progetto. ↩
  8. Il collegamento tra conoscenza dichiarativa e capacità di definizione del problema è il filo conduttore di “Se non sai spiegarlo, non sai farlo. E l’AI nemmeno.” I due post si leggono in sequenza: prima sviluppi la competenza dichiarativa, poi riesci a usarla per identificare problemi risolvibili. ↩
  9. “Qualche triste verità sui tool di project management, AI inclusa” — il punto centrale: i tool non risolvono problemi strutturali. Un CRM senza processo sottostante è uno scaffale vuoto. L’AI senza governance è un acceleratore di caos. ↩
colorful abstract geometric design with spheres

Se non sai spiegarlo, non sai farlo. E nemmeno l’AI.

/in , , /by

In ogni team c’è quella persona che fa le cose in modo impeccabile: istinto, velocità, qualità. La chiami per i problemi difficili e li risolve.

Poi provi a farla lavorare con un junior, a farle trasmettere quello che sa e… catastrofe. Risultato pessimo: Senior frustrato, Junior frustrato. Non riesce a spiegare perché fa quello che fa, le fa e basta e il Junior dovrebbe apprendere per osmosi 1.

Non è cattiveria. È che sapere fare e sapere spiegare sono due competenze diverse e non si sviluppano automaticamente l’una con l’altra.

Read more

Notes:

  1. che è poi il motivo per cui alcune imprese vorrebbero tornare in presenza, così non hanno bisogno di struttura (fine del piccolo rant sulla presenza vs remoto) ↩
futuristic abstract maze with colorful lights

Tra progetti e prodotti digitali

/in , /by

Capita spesso: un’azienda decide di rifare un qualcosa di digitale e parte la ricerca di un’agenzia o un brief al team interno.

Al primo incontro iniziano le incomprensioni: da un lato ci si aspetta che l’agenzia/team possa fare qualunque cosa dall’altro iniziano le sopracciglia alzate.

Questa criticità nasce da una generica confusione su cosa serve e cosa chiedere. Vogliamo un progetto? Un prodotto? Capire la differenza è il primo passo per non sprecare tempo, budget (soprattutto per le PMI) e capire anche quali competenze è meglio avere in casa.

Read more
close up photo of yellow tape measure

La verità sulle stime di progetto

/in , , /by

C’è una domanda ricorrente che si presenta puntualmente in tutte le aule durante i corsi di Project Management e mentre lavoro con i team marketing: la famigerata domanda sulle stime di progetto. Questa domanda si presenta in vari modi: come possiamo fare stime migliori? Come facciamo a stimare? Perché le stime di progetto sono sbagliate? e varianti.

La questione stime di progetto è bellissima perché spesso parte da presupposti sbagliati e da una concezione errata di questo termine. Per migliorare le nostre stime dobbiamo partire dalle basi: che cosa è una stima?

Read more
an artist s illustration of artificial intelligence ai this image visualises the benefits and flaws of large language models it was created by tim west as part of the visualising ai pr

AI: può avere effetti collaterali, leggere il foglio illustrativo

/in , , /by

Come credo la maggior parte delle persone, tra le altre cose sto lavorando a diversi progetti legati all’Intelligenza Artificiale (IA o AI) legati all’ottimizzazione dei processi in ambito marketing (automazioni, agenti, low code e tutte quelle belle cose li) e, oltre a sporcarmi le mani guardo anche agli impatti più ampi e devo dire che ho notato una cosa interessante (forse banale): stiamo rendendo i processi meno efficienti.

Read more
robot pointing on a wall

L’impatto dell’AI sui Team di lavoro

/in , , , /by

Se proviamo a cercare un po’ di articoli sull’Intelligenza Artificiale e il lavoro, la quasi totalità si concentra su elementi di produzione/efficienza: come creare più post, come fare più contenuti, come sviluppare nuovi agent… e anche su LinkedIn si parla della velocità di realizzazione di ricerche, contenuti e di come grazie all’AI possiamo fare più cose a parità di tempo.

Proviamo ad andare oltre questo elemento superficiale e considerare gli effetti sui Team di lavoro facendo delle ipotesi su quello che potrebbe accadere ai gruppi di lavoro in vari ambiti (soprattutto marketing, comunicazione, prodotto) partendo da alcune premesse di carattere generale.

Read more: L’impatto dell’AI sui Team di lavoro

Quattro premesse

Prima di parlare dell’impatto dell’AI sui team di lavoro sono opportune quattro premesse:

  • premessa sui contenuti: alla velocità di produzione non corrisponde un aumento di spazi;
  • premessa sulle attività: l’efficienza sulla produzione sposta l’attenzione su decisioni e priorità;
  • premessa sulle competenze: l’AI è una protesi magnificativa che richiede una doppia componente;
  • premessa sull’organizzazione: con poca chiarezza i benefici sono quasi nulli.

Premessa sui contenuti

Grazie all’evoluzione dell’Intelligenza Artificiale oggi è possibile fare più contenuti? Assolutamente sì, ma è un elemento che non dovrebbe monopolizzare le conversazioni: aumentare la produzione di contenuti non è un obiettivo, ma potrebbe essere uno strumento funzionale al raggiungimento di alcuni obiettivi, anche se improbabile.

Perché improbabile? Banalmente per tre ragioni:

  1. Non è aumentata la quantità di tempo disponibile: abbiamo sempre 24 ore in una giornata, non abbiamo più tempo rispetto al passato e mediamente gli Italiani passano quasi due ore al giorno sui Social Media (con una leggera flessione anno su anno);
  2. Non sono aumentati gli spazi disponibili: se il tempo speso sulle piattaforme non aumenta, lo spazio disponibile per attirare l’attenzione delle persone rimane lo stesso.
  3. Non c’è causalità tra quantità e risultati: aumentare la quantità di post (o di budget) non si traduce necessariamente in un aumento dei risultati funzionali al raggiungimento degli obiettivi.

Se guardiamo qualche infografica ci sono già più contenuti che tempo, spazio e persone per guardarli.

Per cui riflettere su come automatizzare o aumentare la produzione di contenuti non è particolarmente interessante, bisognerebbe chiedersi sempre di più quali contenuti ha senso produrre.

Approfondimenti sul contesto:

Premessa sulle attività

Se il focus dell’AI è “produrre di più” ci stiamo concentrando sulla realizzazione di attività (o task) e anche questo non dovrebbe essere un obiettivo: se infatti ci concentriamo sul “fare cose” nel giro di alcuni mesi saremo nuovamente saturi e al punto di partenza, nuovamente stressati e con backlog lunghissimi.

There’s always more to build than we have time or resources to build – always

Le attività dovrebbero essere focalizzare sul ridurre la quantità di lavoro massimizzando l’impatto delle poche attività rimaste

Minimize output, and maximize outcome and impact

Le due frasi di Jeff Patton riportando l’attenzione a un tema che potremmo definire strategico: se oggi il costo e il tempo di realizzazione (operatività) si compattano, il focus e l’attenzione si spostano su altri elementi più decisionali sia in positivo (cosa fare) che negativo (cosa scegliere di non fare).

Approfondimenti sul contesto:

Premessa sulle competenze

L’Intelligenza Artificiale consente alle persone di migliorare le proprie competenze e velocizzare alcune attività sempre da un punto di vista operativo. Migliorare non significa creare o sostituire: da questo punto di vista l’AI è una protesi estensiva e in alcuni casi magnificativa 1.

Rimanendo vicini a questo concetto e riprendendo il concetto di persona T-Shaped o π-Shaped (alcune competenze orizzontali e alcune verticali) ecco che l’AI consente di aumentare le capacità senza però diventare sostitutiva (anche se questo è uno dei desideri non detti da parte di certe organizzazioni o manager).

Realtà vs Desiderio

Con l’AI lavoratori e lavoratrici assumono una forma che ricorda più una V, ma non consente di estendere le proprie competenze (che chiameremo, come nell’immagine “non skill”).

Una maggior autonomia delle persone, grazie all’aumento delle capacità, richiede anche una riflessione sul ruolo della persona e sul lavoro stesso. Se infatti in passato la Job Description o il Ruolo erano molto legati alla componente operativa, con la perdita di rilevanza di questa ecco che i confini tra alcune professioni tendono a perdere di senso.

Possiamo dare concretezza a questo concetto con un esempio: il lavoro dello Scrittore. Se tradizionalmente siamo abituati a sottolineare la componente pratica (una persona che di lavoro scrive), nel momento in cui l’Intelligenza Artificiale riduce/semplifica la parte operativa, la dimensione del lavoro si sposta verso la parte creativa (intesa come capacità di sviluppare soluzioni emergenti).

Ad aumentare di rilevanza sono ambito e capacità di affrontare una serie di nuove sfide in contesti ignoti.

Approfondimenti sul contesto:

Premessa sull’organizzazione

In un contesto dove il contesto VUCA si rinforza (dato che abbiamo un aumento di accelerazione e volatilità, incertezza, complessità e ambiguità) possiamo proporre una nuova metafora vicina al mondo ittico:

Pesce organizzato mangia pesce disorganizzato

Se infatti conosciamo già due frasi piuttosto famose – Pesce grande mangia pesce piccolo e pesce veloce mangia il pesce lento – oggi la componente organizzativa (non intesa come rigidità, ma come conoscenza del lavoro e capacità evolutiva) consente di massimizzare il valore delle nuove tecnologie.

Uno dei limiti che sta emergendo nell’implementazione di soluzioni legata all’AI è infatti il debito semantico, ovvero l’ambiguità su processi, ruoli, pratiche, struttura.

Nel momento in cui si vogliono ottimizzare i processi, è necessario che questi siano noti, nel momento in cui si vuole sostituire una persona, è necessario avere chiaro il ruolo etc. etc

La presenza di poca chiarezza sta generando la diffusione dei due/tre use case nell’adozione dell’AI su larga scala, con un focus sempre sulle attività e poco sugli impatti.

Approfondimenti sul contesto:

Team e AI

Sulla base di queste premesse che compongono il contesto è possibile andare a immaginare quali potrebbero essere gli impatti sui team di lavoro.

Come Team di Lavoro, appoggiandoci a Scrum, intendiamo un gruppo di persone (superiore a due e inferiore a 10) in possesso delle competenze e capacità necessarie per trasformare delle idee in incrementi.

Nel team consideriamo una eventuale presenza di Agenti AI (entità autonome o semi-autonome basata su intelligenza artificiale, sviluppata per perseguire uno o più obiettivi specifici all’interno di un ambiente definito).

Riduzione del numero di membri

Uno dei primi effetti potenziali sui team è la riduzione del numero di persone necessarie per produrre lo stesso output.

L’AI consente a singoli individui di svolgere in autonomia attività che in precedenza richiedevano il contributo di più specialisti e quindi un numero minore di persone è ora in grado di coprire un ventaglio di attività più ampio.

Aspetti positivi

  • Possibilità di lavorare su un numero limitato di attività
  • Efficienza operativa
  • Riduzione dei costi fissi
  • Comunicazione più semplice

Aspetti negativi

  • Aumento delle dipendenze esterne per mancanza di skill “profonde”
  • Incremento della superficialità data la riduzione dei punti di vista
  • Crescita della fragilità dato che ci sono meno ridondanze

Domanda chiave: come garantire resilienza in team più piccoli?

Team super-frazionati

Onde evitare dipendenze esterne, manteniamo un numero di persone simile al passato, ma questo team viene diviso su più progetti essendo aumentata la capacità produttiva. Ogni membro del team lavora su più stream e i team diventano sovra-estesi e multi-funzionali.

Questo è il modello adottato (spesso) nei contesti che vogliono massimizzare l’output senza ridisegnare l’organizzazione.

Aspetti positivi

  • Riduzione dei costi
  • Sviluppo di skill trasversali
  • Flessibilità cross-progetto

Aspetti negativi

  • Riduzione del deep work e aumento del content switching
  • Aumento dei costi organizzativi
  • Diminuzione della qualità per priorità concorrenti

Domanda chiave: come evitare la dispersione nei team frammentati?

Singolo Team multiprogetto

Una ulteriore possibilità è rappresentata da team stabili, strutturati, che operano contemporaneamente su più iniziative, mantenendo un’identità e una coesione interna.

A differenza dei team super-frazionati, in cui le singole persone sono coinvolte in progetti diversi spesso in contesti separati, qui il team agisce come unità unica e coerente, anche se lavora su stream paralleli. È una forma organizzativa che tenta di massimizzare l’efficienza senza perdere la cultura di team.

Aspetti positivi

  • Efficienza operativa
  • Resilienza e cultura di team
  • Diminuzione degli overhead rispetto a team separati

Aspetti negativi

  • Ambiguità decisionale
  • Potenziali carichi disomogenei
  • Dipendenza da figure di coordinamento

Domanda chiave: come generare impatto e non solo output?

TAAS – Plug and Play

Un ulteriore scenario è rappresentato da team modulari temporanei, attivati su richiesta in base a una specifica esigenza progettuale. Parliamo di team costruiti con logica Plug & Play o Team As A Service (TAAS): composti da persone interne, collaboratori esterni e, in alcuni casi, agenti AI, con l’obiettivo di rispondere rapidamente a bisogni puntuali (campagne, prodotti sperimentali, redesign, validazioni rapide).

A differenza dei team stabili o funzionali, questi team hanno una durata limitata e una missione chiara: vengono creati e sciolti in modo flessibile, spesso operando su processi già standardizzati o documentati.

Questo modello consente alle organizzazioni di reagire in modo rapido a opportunità o cambiamenti, senza dover riconfigurare l’intera struttura e richiede una forte maturità progettuale, chiarezza di obiettivi e un sistema di gestione del lavoro che consenta l’integrazione veloce dei team temporanei nel flusso complessivo.

Aspetti positivi

  • Massima flessibilità nella risposta ai bisogni progettuali
  • Attivazione rapida di competenze e capacità
  • Scalabilità abilitata da AI e standard operativi
  • Maggiore controllo sui costi variabili rispetto a team interni fissi

Aspetti negativi

  • Rischio di perdita di continuità e conoscenza progettuale
  • Maggiori costi cognitivi per integrazione e onboarding
  • Possibile disconnessione rispetto alla cultura e ai processi interni
  • Dipendenza da documentazione ben fatta e processi formalizzati

Domanda chiave: Come mantenere coerenza e qualità in team temporanei attivati su richiesta?

Notes:

  1. In Kant e l’Ornitorinco U. Eco definisce le protesi in tre macro-categorie: sostitutive (fanno quello che il corpo faceva, ma non fa più) estensive ( prolungano l’azione naturale del corpo) e magnificative (qualcosa che qualcosa che va oltre l’estensione) ↩
green hedge maze

It’s Not Me, It’s You (Gantt)

/in , /by

Quasi sempre, quando sono in agenzia o in azienda per consulenze o formazioni su processi e gestione dei progetti, nelle prime sessioni ci sono delle domande sui Gantt di progetto, famigerati strumenti di previsione progettuale. Dopo un minimo di discussione, prendiamo il Gantt e lo buttiamo con la consapevolezza che è uno strumento estremamente interessante, ma che probabilmente non fa al caso nostro. Per capire il motivo andiamo con ordine.

Read more: It’s Not Me, It’s You (Gantt)

Un minimo di Storia del Gantt

Il Gantt è uno strumento che ci consente di rappresentare la pianificazione di un progetto usando barre colorate: avremo quindi delle attività (sulla sinistra) con descrizione, durata, etc. e la visualizzazione su un arco temporale delle attività (sulla destra) con la possibilità di vedere dove siamo oggi (la linea tratteggiata in viola) nell’evoluzione del progetto dall’inizio alla fine.

Questo celebre strumento prende il nome dal suo creatore, Henry Laurence Gantt, che lo introdusse nel 1916 1. Questo strumento, così come altre pratiche di Project Management dei primi del ‘900, si basa sull’idea di poter spezzettare il lavoro in più parti e, misurando il tempo necessario per ogni attività, poter fare delle valutazioni e delle previsioni. Primo piccolo problema di questo strumento: il principio di visualizzare e gestire le risorse nasce con la schiavitù e l’esigenza di monitorare il lavoro 2 e nasce quindi con uno specifico contesto in mente: è uno strumento di controllo.

Al netto delle problematiche culturali (superabili), rimane una criticità: il contesto per cui è pensato questo strumento (e i necessari passaggi per costruirlo).

Il contesto del Gantt

Una delle caratteristiche della visione progettuale (e manageriale) della prima metà del novecento è la staticità del contesto aziendale.

  • se le attività e i mercati non cambiano nel tempo (o cambiano molto molto lentamente) ha perfettamente senso creare ex-ante una lista di tutto quello che c’è da fare;
  • se le attività non cambiano nel tempo e sono note è assolutamente possibile, alla luce dell’esperienza passato, poter prevedere il futuro del progetto.

Considerando questi due elementi appaiono sia i punti di forza che gli eventuali limiti di questo strumento che nasce per gestire una certa classe di progetti caratterizzati da predicibilità e scarso tasso di cambiamento (sia a livello di cambiamento dei requisiti che di contesto).

  • Siamo in un contesto statico? Può essere un buono strumento.
  • Siamo in un contesto dinamico? Può non essere un buono strumento.

Trovandomi a gestire normalmente progetti legati al marketing o ai prodotti digitali il mio contesto è tutto tranne che statico: potremmo scoprire che una certa funzionalità non è più necessaria, che un competitor ha lanciato qualcosa al quale dobbiamo rispondere, che un nuovo aggiornamento richiede lo sviluppo di nuovi content… oltretutto lavoro value driven e non guidato dal piano.

Tra piani e valore

Come detto poco sopra, il Gantt ha una caratteristica molto interessante: il fatto di distribuire su un arco temporale l’elenco dettagliato delle attività, la famigerata WBS (Word Breakdown Structure). Se abbiamo una bella Project Charter e una WBS strutturata ecco che traslare le attività su un calendario calcolando l’effort (la quantità di lavoro necessaria per realizzare l’attività) diventa semplice e se abbiamo uno strumento per allocare le persone e tenendo conto dei calendari possiamo calcolare l’elapsed 3.

Abbiamo messo in fila diversi “se” di cui due molto grandi: elenco delle attività completo e risorse disponibili. Quante volte abbiamo queste informazioni all’inizio del progetto?

Senza queste informazioni diventa molto difficile organizzare il tutto e poter avere uno strumento che ci aiuti nella gestione del progetto e nella visualizzazione del suo avanzamento. È come voler capire dove siamo durante un viaggio con una mappa disegnata secoli prima: ti mancano i riferimenti, fai fatica a capire dove ti trovi e di conseguenza quanto manca.

Inoltre, come è anche giusto che sia, se mi dai un piano il mio obiettivo è seguire quel piano e fare in modo che ci siano meno deviazioni possibili (ogni deviazione sono costi che si alzano e ritardi che si accumulano) 4. Personalmente io vivo questo approccio abbastanza male, perché ho l’idea che nel fare i progetti si debba cercare la massimizzazione del valore (e non litigare sulle CR).

Sì, ma…

Piero, come sei fiscale! Abbiamo capito che nel Gantt ci dovrebbe essere come minimo nome del task, inizio, fine, durata, predecessore e successore… ma noi non lo facciamo, facciamo una cosa più semplice e per noi funziona!

Certo che funziona, solamente non state usando un Gantt e non c’è nulla di male in questo, ma le parole sono importanti e vorrei citare un bel passaggio della Scrum Guide

 While implementing only parts of Scrum is possible, the result is not Scrum.

La frase citata è delicata, ma molto importante per comprendere e valutare le attività per quello che sono: “giochiamo a calcio, ma quando vuoi puoi anche prenderla con le mani” è un bellissimo sport/gioco, ma non è Calcio.

“Facciamo Scrum, ma senza lo Scrum Master, il PO è il PM, non facciamo la Sprint Review” stai facendo una cosa probabilmente interessante, ma non è Scrum. Allo stesso modo se non stai inserendo gli elementi base di un Gantt in un Gantt non stai facendo un Gantt (lapalissiano).

Al posto del Gantt

Se il Gantt funziona molto bene in certi contesti (per cui continuerò a sostenere la validità di questo strumento) bisogna tenere conto che in altre situazione potrebbe non offrire vantaggi significativi o avere dei costi di aggiornamento/mantenimento così alti da renderlo sub-ottimale: per fortuna non è l’unico strumento esistente.

In molti casi per le agenzie o i dipartimenti marketing una meravigliosa Timeline può essere più che sufficiente: invece di scendere nel dettaglio rappresentiamo la sequenza di milestone e task in ordine cronologico 5.

Se vogliamo rimanere ad alto livello, ma fornendo maggiori informazioni ecco che la Roadmap può essere un altro strumento particolarmente interessante da esplorare. È un documento più legato alla strategia (per cui ci vogliono traguardi e obiettivi) che però contiene informazioni utili legate anche agli Stakeholder e ad altre informazioni.

Niente più dettagli!

Evviva: Piero ha detto che non dobbiamo più dettagliare le attività.

Momento, momento, momento: non dobbiamo dettagliarle nella Timeline o nella Roadmap, ma questo non significa che le attività non vadano specificate insieme (valutando insieme al team quale sia il giusto livello di granularità).

Magari lo facciamo durante lo Sprint Planning (se usiamo Scrum) o in una riunione simile se usiamo un sistema Ibrido, ma per evitare ambiguità e incertezza, abbiamo bisogno di trasparenza e confronto.

Per cui Gantt mi spiace, non sei tu, sono io: i miei progetti cambiano troppo velocemente e io ho bisogno di qualcosa che mi porti valore. Speri rimarremo amici e ogni tanto potremo ancora parlare.

Notes:

  1. Datare esattamente l’introduzione di uno strumento non è mail facile, tendenzialmente possiamo essere confidenti dicendo inizio del 20° secolo, o 1910-1916 volendo restringere il periodo. Il 1916 è la data di pubblicazione del libro “Work, Wages, and Profits” in cui ne parla esplicitamente: fonte – PMI ↩
  2. Da questo punto di vista lo stesso Gantt aveva identificato alcune pratiche premianti legate al superamento delle attività base, una sorta di MBO ante litteram, riprese dalle pratiche di gestione delle piantagioni di cotone: qui un piccolo approfondimento ↩
  3. Ovviamente anche in questo caso è necessario un tool e anche se si possono disegnare cose interessanti con Excel non è per me lo strumento giusto per una gestione completa tramite Gantt ↩
  4. Se vogliamo questa è una delle grandi diatribe tra Project Manager, persone che si occupano di gestire progetti che vengono assegnati, e Product Manager, persone che si impegnano per il successo di un prodotto. Sono due mondi vicini, ma non perfettamente sovrapposti e tendenzialmente il mondo Agile è più spostato sulle idee di Product Management ↩
  5. Lo so che molti hanno sempre chiamato Gantt la timeline… ↩
person wearing red hoodie

Qualche triste verità sui tool di Project Management (AI Inclusa)

/in , /by

Quando insegno Project Management o lavoro in agenzia sull’ottimizzazione della gestione dei progetti arriva sempre una domanda “ma secondo te cambiando/introducendo un tool risolviamo i problemi?” con una mia risposta di base che è “gli strumenti sono importanti, ma non sperate siano la Soluzione”.

Read more
an artist s illustration of artificial intelligence ai this image depicts ai safety research to prevent its misuse and encourage beneficial uses it was created by khyati trehan as part

L’AI tra Hype e Processi

/in , , /by

Ogni giorno una persona che lavora nel digital si alza e sa che sarà uscito un nuovo tool di AI, che i tool già esistenti avranno presentato una nuova funzionalità e che ci saranno innumerevoli post su LinkedIn che raccontano di quanto sia interessante l’ultimo Ai Agent (con tanto di “commenta e chiedi il contatto per ricevere” che ha sostituito le landing page con i whitepaper).

Se da un lato abbiamo tanto hype con alte aspettative, dall’altro c’è una domanda frequente a cui è difficile dare una risposta immediata: “come possiamo ottenere dei benefici nella nostra azienda con queste incredibili AI?”. La risposta dovrebbe essere semplice, ma non lo è per una ragione estremamente banale: spesso mancano le basi, ma andiamo con ordine.

Read more
assorted medals

Perché prendere certificazioni come PM?

/in , /by

Durante i corsi e le consulenze in agenzia, puntualmente la domanda arriva: perché prendi le certificazioni sul Project Management e soprattutto sull’Agile e Scrum? Servono davvero? Qui le mie considerazioni assolutamente personali partendo da una panoramica sulle certificazioni, a cosa servono e perché le prendo.

Read more