Perché gli Avvii di Progetto Falliscono per Chi Si Unisce Dopo
Il Mito dell'Avvio: Gli avvii di progetto creano allineamento all'inizio, ma le cose inevitabilmente cambieranno.
La Responsabilizzazione Conta: Quando chi si unisce a progetto avviato non ha responsabilità, slancio, morale e impatto ne risentono.
La Sfida della Documentazione: La documentazione tradizionale non funziona in progetti ad alta velocità; sono essenziali formati leggeri e adattabili.
IA e Neurodiversità: Gli strumenti di IA possono facilitare l'onboarding fornendo informazioni accessibili sul progetto, ma necessitano di dati accurati.
Una Cultura di Appartenenza: Favorire un senso di appartenenza è cruciale per l’integrazione efficiente nel team e il successo del progetto.
Perché i Kickoff Sono Fantastici… Ma Difettosi
Adoro una buona riunione di kickoff di progetto. È un'opportunità per creare entusiasmo, costruire slancio e favorire l’allineamento con tutte le persone giuste nella stanza.
Tranne che... i kickoff di progetto sono un mito totale.
Almeno, quella versione di essi lo è.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
La versione in cui raduniamo tutti gli stakeholder conosciuti, concordiamo una stella polare, scolpiamo il nostro approccio nella pietra, e poi partiamo insieme con l’assunzione che l’energia cinetica creata quel giorno porterà il progetto da inizio a fine da sola.
La realtà è che il cambiamento è inevitabile, e l'approccio della maggior parte dei team ai kickoff di progetto è in realtà fallimentare.
E questo inizierà a contare molto nell’economia dei lavoratori frazionari, alimentata dall’IA, in cui stiamo entrando.
Perché Un Buon Kickoff Non Garantisce Un Buon Progetto
Pensavo che la mia capacità di guidare ottimi kickoff di progetto fosse il mio vantaggio competitivo come PM. Quando avviavo i miei progetti, i team partivano con chiarezza e slancio invece che confusione e nuove domande irrisolte.
Infatti, dopo un kickoff spesso venivano da me a chiedermi l’agenda o le slide da usare anche per i loro progetti. Era motivo di orgoglio.
Ma poi è successo qualcosa che ha cambiato completamente la mia visione sui kickoff.
Durante uno dei miei progetti, membri chiave del team sono stati portati via e assegnati ad altri progetti — tutto senza tempo per un adeguato passaggio di conoscenze. Le persone di talento che li hanno sostituiti erano molto capaci, ma avevano la sensazione di partire svantaggiati, vivendo all’ombra di ciò che era già successo. Ogni conversazione era accompagnata da frasi come "ma io non c’ero quando è iniziato il progetto" oppure "mi sto solo aggiornando, non lasciate che le mie idee mandino all’aria i vostri piani."
Per i nuovi membri del team, non era che non avessero le informazioni, l’autorità o addirittura le idee. Era che non avevano la sensazione di essere proprietari del progetto.
E senza quella sensazione di ownership, le vele erano sgonfie. La missione non era la loro. Si sentivano come supplenti costretti a portare avanti un compito — vittime delle circostanze con poca voce in capitolo e poco controllo.
Purtroppo, all’epoca non me ne ero ancora reso conto.
Il Problema del Trasferimento della Conoscenza
All’epoca, la soluzione sembrava semplice: basta mettere a pari i nuovi arrivati. Trasferire le conoscenze nelle loro teste. Giusto?
Dopotutto, ci sono brief, dichiarazioni di ambito e documenti di requisiti in abbondanza — per non parlare delle slide del kickoff e dei risultati degli esercizi di visione.
Ma anche quando hai tutti i tuoi documenti di progetto ordinati e organizzati, per il nuovo membro del team abituarsi a una montagna di informazioni poco strutturate può sembrare come fare una revisione forense dei conti con una pistola puntata alla testa.
Certo, i nuovi membri possono fare domande, ma non sanno cosa non sanno. E la maggior parte delle volte non si sentono ancora a loro agio a fare le domande "sceme" per paura di sentirsi rispondere: "era nei documenti, non l’hai visto?"
Questo creava un ciclo in cui i nuovi arrivati rimanevano spaesati più a lungo — rendendo solo più difficile guidare il progetto.
Il Problema dell'Aggiornamento della Documentazione
Inoltre, ogni volta che inserivo una nuova persona nel mio progetto, mi rendevo conto che, tra i miei fantastici documenti, piccoli dettagli — e a volte anche dettagli importanti — non erano più allineati con lo stato attuale del progetto.
Dopo il kickoff, erano state prese centinaia di migliaia di micro-decisioni. Non quelle grandi che annoti in un registro delle decisioni, ma quelle piccole che sfuggono agli aggiornamenti della documentazione.
Mi ritrovavo a spiegare discrepanze, approfondire dettagli minimi e riferire conversazioni informali tra membri del team di cui non avevamo mai pensato di tenere traccia.
Il Problema della Velocità
Avrei potuto alleviare tutto ciò adottando un "sistema a coppie" in cui un nuovo arrivato viene affiancato a un collega del progetto? Credetemi, ci ho provato. Ma anche quello è fallito, perché il progetto non poteva permettersi di avere una persona a fare supporto part-time.
Stavamo già correndo a tutto gas, e non potevamo permetterci di rallentare. Le scadenze incombevano, la pressione aumentava, la visibilità cresceva, e l’aspettativa era che la squadra lavorasse ancora più velocemente mano a mano che altre persone venivano aggiunte, non meno.
Così, invece di rallentare il ritmo, ho continuato con lo status quo: la versione in cui chi entra a progetto in corso si ritrova a saltare su un’auto in corsa e mettere la mano nel fuoco.
Il Problema dell’Appartenenza
Ma mentre continuavo freneticamente a lanciare documenti e inviti a riunioni alle persone che venivano aggiunte al progetto — e mentre il team eseguiva automaticamente i task dal backlog — qualcosa è diventato chiarissimo: non si trattava di informazioni. Si trattava di appartenenza. E quello è uno stato emotivo che non può essere raggiunto solo attraverso la documentazione.
Non riuscivo a far sentire i nuovi membri del team parte del gruppo semplicemente rassicurandoli o parlando loro di più. Nessun sistema di affiancamento avrebbe risolto questo problema. Nessuna riunione “chiedimi qualsiasi cosa”, pianificata nell’agenda, avrebbe potuto appianare la situazione. Servivano spazi sicuri e alternativi.
Le persone trovano il senso di appartenenza in maniera diversa a seconda del contesto: c’è chi desidera tempo tranquillo con la documentazione prima di parlare con il team; chi vuole un compagno; chi ha bisogno di uno spazio sicuro dove fare le “domande stupide”; e chi desidera solo comprendere il “perché” che sta dietro la missione e il proprio ruolo all’interno di essa.
Quello era su cosa avrei dovuto investire il mio tempo e le mie energie: costruire un framework che permetta ai membri del team di trovare appartenenza secondo i propri tempi.
In definitiva, investivo troppo nell’evento di kickoff, mentre lasciavo chi si univa al progetto a metà strada a cavarsela da solo.
Questo ciclo di onboarding inadeguato non causa solo frustrazione nei singoli — mina l’intero progetto. Quando i nuovi arrivati non riescono a ingranare rapidamente, le decisioni rallentano, gli errori si moltiplicano e il morale del team ne risente.
E quando il cambiamento è inevitabile — quando i membri del team ruotano dentro e fuori durante il ciclo di vita di un progetto — questo approccio diventa insostenibile.
Per i nuovi membri del team, non era questione di mancanza di informazioni, di autorità o perfino di idee. È che non sentivano di avere la responsabilità personale.
Un altro modo di pensare ai kickoff: onboarding continuo
Allora qual è la risposta? Se investiamo troppo nei kickoff e troppo poco nella gestione del cambiamento e nell’onboarding a progetto avviato, come possiamo correggerlo?
Avevo le mie ipotesi, ma ho avuto anche un momento illuminante grazie a una persona che rispetto molto che ha detto:
"Riaffermo sempre il punto focale praticamente a ogni riunione perché la ‘stella polare’ cambia sempre. Mi ricorda come si pratica nel Kung Fu… C’è il punto centrale su cui ci si concentra nel controllo, e tutto il resto è contesto per ritornare a quella verità. È una conversazione, in cui entrambe le parti ‘fanno domande’ e ricevono risposte in tempo reale, usando tutti i sensi."
In altre parole, invece di fare affidamento sul grande entusiasmo di un kickoff, possiamo usare ogni interazione per rafforzare l’essenza di ciò che è davvero importante nel progetto. È parte integrante del collaborare insieme, invece che essere una grande festa da cui rischi di sentirti escluso se non eri presente.
Ecco quindi cosa ho provato a fare da allora per ogni progetto:
1. Una policy su documentazione leggera e facile da aggiornare
Ho messo da parte le mie bellissime presentazioni di kickoff e artefatti di progetto molto rifiniti (brief, report di stato, agende delle riunioni, RAID log), e invece ora do priorità ad avere i contenuti in un formato facile da aggiornare e semplice da leggere sia per membri umani che per colleghi AI.
Poi collaboro con i team di progetto per assegnare responsabili per l’aggiornamento dei documenti — proprio come facciamo per i responsabili dei rischi. Questo distribuisce il carico e permette ai membri del team di promuovere una documentazione accurata.
Per esempio, abbiamo documenti semplici e sintetici in Notion o Slite sui ruoli e le responsabilità del team, il brief di progetto e i piani di comunicazione del progetto. Nulla è bloccato in fogli di calcolo o PDF.
2. L’onboarding continuo come realtà accettata
Insieme alla documentazione, gestisco le aspettative con il team fin dall’inizio facendo capire che i team, gli obiettivi e tutto il contesto intorno al progetto potrebbero cambiare in qualsiasi momento, e che dovremo essere pronti a reagire.
In altre parole, invece di sperare e pregare che team e obiettivi non cambino, partiamo dal presupposto che cambieranno.
Questo significa evitare il più possibile che le informazioni restino solo nelle teste delle persone o siano legate a un preciso momento. Le riunioni vengono trascritte, le note dei relatori sono accessibili in forma scritta, la maggior parte delle conversazioni di progetto avviene in canali pubblici, e le decisioni sono documentate con scrupolo.
Questo aiuta a garantire che chi si è perso il giorno uno del progetto abbia comunque accesso alle informazioni di cui ha bisogno. E ci permette anche di cambiare direzione agilmente, come uno stormo di allodole, se cambiano obiettivi o circostanze del progetto.
3. L’AI come fonte unificata di verità per tutti i neurotipi
Inoltre, insieme ai miei team configuriamo chatbot AI o basi di conoscenza di progetto interrogabili il prima possibile durante il ciclo di progetto.
Nella maggior parte dei casi, non è sofisticato come si possa sognare quando si parla di AI, ma per noi svolge un ruolo importantissimo: offre un modo relativamente privato, sicuro e meno politicizzato per i membri del team di accedere alle informazioni di progetto — secondo le proprie modalità, nel modo in cui preferiscono apprendere.
Questi chatbot vengono alimentati fin dall'inizio con dati di progetto strutturati e non strutturati — brief, SOW, report di stato, verbali delle riunioni e alcune conversazioni del team. E poiché la documentazione è abbastanza snella da permettere ai membri del team di aggiornarla facilmente, è relativamente semplice per un’IA tenere traccia di ciò che è cambiato durante il progetto — decisioni prese, budget aggiunto, problemi emersi, rischi concretizzati, escalation verificatesi, ecc.
Quindi quel chatbot sarebbe interrogabile in qualsiasi momento da qualunque membro del team, in un contesto in cui non deve preoccuparsi di sembrare incompetente e senza bisogno di fissare una riunione con una figura autorevole già a corto di tempo.
Ad esempio, un membro del team può chiedere cose come:
- “In che modo il mio compito supporta l'obiettivo generale del progetto?”
- “Chi dipende da me per completare il mio deliverable in tempo?”
- “Dove devo salvare i miei deliverable finali, e qual è la nostra convenzione di denominazione dei file?”
Queste potrebbero essere domande a cui già conoscono la risposta, ma su cui vogliono rassicurazioni quando si alternano tra diversi progetti e attività.
In definitiva, i chatbot IA semplificano il processo di accesso alle informazioni, aumentando l'efficienza eliminando la necessità di formazione approfondita o di consultazione con molteplici fonti, e migliorano l’accessibilità tramite un'interfaccia facile da usare, accessibile da qualsiasi dispositivo connesso a Internet 24/7.
Ma ecco il punto: l’IA è nota per poter sbagliare.
E se sbaglia, un progetto può deragliare molto rapidamente. La conseguenza complessiva sarebbe un passaggio in più: provare a chiedere al chatbot, scrutinare la risposta perché potrebbe non essere corretta, quindi seguire il proprio istinto per decidere se fidarsi della risposta ricevuta e non chiedere a nessuno, oppure trovare qualcuno a cui chiedere—in altre parole, quando non ci fidiamo dell'IA, torniamo al punto di partenza.
Quindi i dati devono essere sufficientemente puliti da non essere contraddittori. E i membri del team devono effettivamente fidarsi che siano accurati (supponendo di non aver inserito informazioni errate).
Per garantire ciò, la nostra priorità è assicurare la massima accuratezza possibile, con membri chiave del team che fungano da garanti e arbitri di qualità usando alcuni casi di test e controlli a campione che effettuiamo regolarmente.
4. Rinforzo rituale degli obiettivi
E poi, per collegare tutto insieme, ho cercato di prendere alcuni dei miei elementi preferiti dei tragici kickoff di progetto "momentanei" e intrecciarli nella quotidianità. Ad esempio, ribadire e mettere costantemente in discussione la vision del prodotto o il BHAG affinché la missione sia compresa abbastanza bene da poter essere esaminata e verificare che stiamo ancora costruendo la cosa giusta.
Ad esempio, cerco di ricordare agli altri gli esiti desiderati del progetto all’inizio di ogni riunione di team. Qualcosa tipo "come promemoria, questo progetto aiuterà i viaggiatori dei mezzi pubblici con diverse abilità a raggiungere le loro destinazioni in modo più sicuro e con meno frustrazione."
E se quella Stella Polare dovesse cambiare, cerco di ribadirlo in ogni riunione o aggiornamento di stato: "Come promemoria, questo progetto era iniziato come un’iniziativa per passeggeri disabili, ma ora è un’opportunità per migliorare l’esperienza di tutti i clienti su più reti di trasporto pubblico."
L’altra cosa che faccio è usare il mio ruolo di generalista per porre domande che orientano le decisioni verso il nostro obiettivo. Se il team fosse indeciso tra due approcci, chiederei qualcosa tipo "quale ci aiuterà a rimuovere più attriti dall’esperienza cliente?"
Per quanto riguarda i valori del team e i modi di lavorare, preferisco concludere le riunioni con un promemoria: "Non dimenticate di mantenere le comunicazioni importanti nel canale condiviso se possono aiutare anche gli altri a svolgere il proprio lavoro."
Non solo questo fa sentire i nuovi arrivati meno esclusi se si uniscono a un progetto già avviato, ma contribuisce anche a rafforzare costantemente la missione con tutti gli stakeholder.
5. Una cultura dell’appartenenza
Ma, soprattutto, sto cercando di cambiare mentalità da "trasferimento di conoscenza" a "trasferimento di responsabilità" dando priorità a modalità che aiutino i nuovi membri del team o gli stakeholder a sentirsi "parte" del progetto e a portare il loro vero sé nel lavoro.
A mio avviso, non esiste un unico modo infallibile di farlo, ma credo fermamente che la risposta non sia sommergere le persone di informazioni. Noi umani dobbiamo sfruttare la nostra umanità per occuparci di ciò che è puramente umano: emozioni, ego, comunità e scopo.
Quando le persone non hanno senso di appartenenza, è meno probabile che prendano la parola quando qualcosa sembra fuori posto o che mettano in discussione una decisione che potrebbe mandare il progetto fuori rotta.
Perché Conta di Più Ora
Oggi vedo che il problema dell'onboarding a metà progetto sta diventando sempre più grande. I membri della mia community stanno gestendo progetti che sono una porta girevole di specialisti frazionari, freelance e perfino semplici dipendenti a tempo pieno che vengono spostati fluidamente tra i progetti per essere sempre impiegati.
Allo stesso tempo, gli strumenti di intelligenza artificiale stanno generando aspettative fluide tra gli stakeholder: ci si aspetta che i progetti si muovano più velocemente, gestiscano meglio i cambiamenti e offrano più valore sfruttando approfondimenti dei dati, automazione e capacità decisionale automatica.
In altre parole, i team sono più volatili e il ritmo accelera. Il che significa che il divario di appartenenza si allarga quando tutto si muove più velocemente e cambia più di frequente.
E qui sta il vero rischio: non vogliamo solo costruire la cosa sbagliata più velocemente.
Quando le persone non hanno ownership, è meno probabile che si facciano sentire quando qualcosa non va o che mettano in discussione una decisione che potrebbe mandare il progetto fuori strada.
Per questo l'onboarding continuo non è più facoltativo. Non è un optional o una soft skill. È un imperativo aziendale. Se vogliamo team in grado di adattarsi e generare vero valore in questo panorama di progetti sempre più rapidi e frammentati — ci servono persone che si sentano coinvolte nella visione, non solo informate riguardo ai compiti.
Quindi, i Kickoff Sono Morti?
I kickoff di progetto sicuramente non sono morti. Non per me, non per molti team di progetto.
Personalmente, li adoro. Penso che i kickoff di progetto siano incontri che possono creare legami tra le persone e offrire spazi di dialogo in un momento cruciale del ciclo di vita di un progetto. Li trovo molto umani. Sì, quindi, continuo a fare i kickoff e sarà difficile togliermi questa abitudine.
Quello che faccio in modo diverso, però, è che non riverso tutte le mie speranze e sogni nei kickoff. Non investo così tanta energia nel renderli perfetti, scintillanti o performativi. Non aspiro a trasformarli nella cerimonia definitiva che fa sentire coloro che non erano presenti all'inizio dei cittadini di serie B. E di sicuro non voglio che diventino qualcosa che ci obblighi all'aspettativa di un percorso unico e immutabile.
Perché i progetti non sono una linea retta. Sono come un aquilone nel vento, che va condotto di continuo, a prescindere dagli ostacoli. Il cambiamento è inevitabile. Ed è proprio per questo che dobbiamo investire energia nella preparazione.
Cosa Ne Pensi?
Ma mi piacerebbe sentire anche la tua opinione: i kickoff sono davvero così problematici come li ho descritti? Come affronti l'onboarding nei tuoi progetti — soprattutto quando i membri del team si uniscono a lavoro in corso?
