C’è un momento preciso in cui un team smette di poter lavorare con strumenti improvvisati. Di solito succede tra le otto e le dodici persone. Prima di quella soglia, un foglio Excel ben tenuto, qualche chat dedicata e una cartella condivisa bastano. Dopo, smettono di bastare in modo silenzioso: nessuno si lamenta apertamente, ma le informazioni cominciano a perdersi nei passaggi, le scadenze diventano “indicative”, e la stessa attività viene chiesta due volte a due persone diverse.
A quel punto, nella maggior parte delle aziende, la tentazione è una sola: introdurre uno strumento di project management. È la scelta giusta. Quello che spesso non funziona è il modo in cui viene introdotto.
L’errore più comune non è scegliere lo strumento sbagliato. È replicare al suo interno la stessa frammentazione che si aveva prima.
Una bacheca per ogni cliente. Una bacheca per ogni servizio. Una per ogni tipo di lavorazione. Una per le idee. Una per le riunioni interne. Una per il “da fare quando avremo tempo”. Risultato: trenta o quaranta bacheche, ciascuna usata da due o tre persone, e nessuno che abbia più la visione d’insieme.
Il vero salto organizzativo non è passare da Excel a uno strumento di project management. È capire quante bacheche servono davvero e tenersi a quelle.
Nove volte su dieci, quattro bastano.
Le quattro bacheche essenziali
Le quattro bacheche su cui regge un team marketing di una decina di persone sono queste.
Erogazione. È la bacheca in cui vivono tutti i lavori attivi sui clienti. Una riga per ogni attività in corso, con owner, scadenza, stato. È il cuore operativo. Se viene tenuta bene, qualunque persona del team può aprire la bacheca e capire in trenta secondi cosa sta succedendo e su chi pesa cosa. È la fonte di verità per il meeting settimanale, ed è il primo posto da guardare quando qualcosa si è bloccato.
Consulenze. Vanno tenute separate. Non perché siano “più importanti”, ma perché hanno tempi, output e logiche diversi rispetto all’erogazione ordinaria. Una consulenza ha fasi distinte: analisi, intervista, redazione, restituzione. Ha materiali dedicati. Ha una scadenza precisa che è anche commerciale. Mescolarle con il flusso ordinario significa trasformarle in attività che scivolano, perché competono con dieci task più piccoli e più urgenti che divorano le agende.
Redazione piani. Anche qui, separazione utile. La produzione di piani strategici, piani editoriali, piani di comunicazione ha uno stato proprio: bozza interna, revisione, condivisione cliente, approvazione, finalizzazione. Se vivono nella stessa bacheca dell’erogazione, gli stati non parlano la stessa lingua e ogni filtro diventa complesso da costruire e da leggere. Tenere separata la redazione protegge anche un’altra cosa: la qualità del pensiero. Un piano scritto in mezzo al traffico di task quotidiani non è quasi mai un buon piano.
Archivio completati. È la bacheca che sembra meno importante e che, alla prova del tempo, protegge di più. Tenere i progetti chiusi visibili e ricercabili significa avere una memoria operativa. Chi è arrivato dopo può capire come è stato gestito un caso simile sei mesi prima. Chi ha lavorato su un cliente può recuperare riferimenti senza chiedere a chi c’era. Senza un archivio strutturato, ogni nuovo progetto comincia come se nessuno avesse mai fatto niente di simile, e la conoscenza accumulata dal team resta nella testa delle singole persone.
Quattro bacheche. Non tre, perché la mancanza di una delle quattro funzioni produce problemi prevedibili. Non cinque, perché ogni bacheca in più costa attenzione a tutto il team, ogni giorno.
Cosa viene tagliato (e perché nessuno lo rimpiange)
Ciò che colpisce, quando si arriva a quattro bacheche da una situazione di partenza con quindici o venti, è quante cose vengono tagliate senza che nessuno le rimpianga.
Tipicamente vengono assorbite o eliminate:
— Le bacheche dedicate a singoli clienti, che diventano semplicemente filtri o gruppi all’interno di Erogazione. Una colonna “cliente” ben usata fa lo stesso lavoro di venti bacheche separate, con un decimo della fatica di mantenimento.
— Le bacheche per “idee” e “proposte interne”, che quasi sempre non vengono più aperte dopo le prime due settimane. Le buone idee circolano per altre vie. Le idee che hanno davvero un seguito vanno direttamente in pianificazione, non in una bacheca-limbo.
— Le bacheche per task ricorrenti, che funzionano meglio come automazioni programmate o come check di routine. Mettere un’attività ricorrente in una bacheca a parte significa, di fatto, nasconderla.
— Le bacheche per i progetti in standby, di cui vale la pena parlare a parte perché meritano un discorso dedicato.
La logica sottostante è sempre la stessa: una bacheca esiste se ha uno stato proprio, un ritmo di aggiornamento proprio e un pubblico definito che la guarda regolarmente. Se non ha questi tre elementi, non è una bacheca: è un elenco che peggiora la visibilità del resto.
La trappola dello standby
Un caso speciale merita attenzione, perché è il più comune. Cosa fare dei progetti in standby? Sono attivi ma fermi, oppure fermi ma da non perdere di vista. La tentazione è creare una bacheca dedicata.
È la tentazione sbagliata.
Una bacheca separata per gli standby produce due effetti, entrambi negativi.
Il primo: i progetti in standby smettono di apparire nei flussi quotidiani, quindi smettono di essere monitorati. Spostarli “fuori” significa, in pratica, dimenticarli. Quando il cliente torna a chiedere notizie, si scopre che il progetto è fermo da più tempo di quanto sembrava, e che nel frattempo qualcosa è cambiato.
Il secondo: chi gestisce un cliente in standby si abitua a non aggiornarne lo stato, perché tanto “sta nella bacheca standby”. Quando il progetto si riattiva, metà delle informazioni utili sono andate perse o sono ferme a tre mesi prima.
La soluzione, dove possibile, è tenere gli standby dentro la bacheca Erogazione, con uno stato dedicato e una vista filtrata. Restano visibili. Restano monitorabili. E quando si decide (o si riesce) di riattivarli, basta cambiare lo stato senza spostare nulla.
Più in generale: ogni volta che si pensa “facciamo una bacheca a parte”, vale la pena fermarsi e chiedersi se non sia sufficiente una vista filtrata di quella esistente. Nove volte su dieci lo è. Una vista non costa attenzione al team, perché chi non ne ha bisogno semplicemente non la apre. Una bacheca, invece, costa attenzione anche solo per essere ignorata.
Cosa le bacheche non risolvono
Sarebbe scorretto far credere che quattro bacheche risolvano l’organizzazione di un team marketing. Risolvono il livello di visibilità sui lavori. Non risolvono quello che sta sopra, né quello che sta sotto.
Sopra le bacheche ci sono due cose.
La prima è il momento in cui le si guarda insieme. Una bacheca aggiornata ma mai discussa serve a poco. Un meeting settimanale, anche breve, in cui si scorre la bacheca, si fanno emergere i blocchi e si riallineano le priorità è probabilmente più importante della bacheca stessa. Senza questo rituale, le informazioni sono lì ma non producono decisioni. Sono fotografie di uno stato che nessuno usa per orientare il passo successivo.
La seconda è la chiarezza sui ruoli decisionali. Ogni task ha un owner, ma chi decide la priorità tra task di clienti diversi? Chi decide quando un’attività va rimandata? Chi può rifiutare un’aggiunta a un progetto già pianificato? Una bacheca non risponde a queste domande. Se non hanno risposta a monte, qualunque strumento di project management finisce per essere usato come arena di negoziazione continua, e il PM diventa un mediatore di traffico più che un coordinatore strategico.
Sotto le bacheche ci sono le procedure.
Le bacheche mostrano i task. Le procedure spiegano come si fanno. Sono due livelli diversi. Confonderli porta a bacheche piene di sotto-task che descrivono ogni singolo passaggio operativo, e a quel punto lo strumento diventa illeggibile. Le procedure stanno altrove (in una wiki, in un manuale operativo, in una sezione dedicata) e vanno richiamate dai task, non incorporate dentro.
Un principio di calibrazione
Il principio, semplice, è uno solo: la complessità di uno strumento di project management va calibrata sul team che lo userà, non sul desiderio di controllo di chi lo configura.
Chi configura una bacheca per la prima volta tende a costruirla come se dovesse usarla solo lui. Aggiunge campi, automazioni, stati, etichette, dipendenze. Ogni elemento ha una logica presa singolarmente. Ma il team che la userà ogni giorno non ha lo stesso livello di tolleranza alla complessità di chi l’ha disegnata. Quattro campi sempre compilati valgono più di dodici campi compilati a metà.
Una bacheca “ricca” che il team non aggiorna è meno utile di una bacheca essenziale che il team aggiorna davvero. È un punto che sembra ovvio sulla carta e che viene tradito quasi sempre in fase di setup.
Lo stesso ragionamento si applica al numero di bacheche. Quattro bacheche tenute bene producono ordine. Otto bacheche tenute a metà producono confusione, con il valore aggiunto di un costo di licenza più alto e di una sensazione di disorganizzazione che le persone tendono a interiorizzare come limite proprio anziché come problema di setup.
L’efficacia di chi coordina un team non si misura dalla sofisticazione degli strumenti che ha configurato. Si misura dalla quantità di informazioni utili che il team riesce a estrarre, ogni giorno, senza dover chiedere a nessuno.
Quattro bacheche, in genere, sono sufficienti per renderlo possibile. Tutto il resto è quasi sempre rumore, mascherato da controllo.