Lunedì ho fatto un censimento: 43 cartelle di progetto, distribuite su quattro attività, comprese quelle già chiuse. Per ognuna ho aggiunto un campo solo, la data di fine. Risultato: 25 su 43 non ce l'avevano.

Non erano progetti abbandonati. Molti erano vivi, con file aggiornati e lavoro in corso. Ma alla domanda "quando finisce?" non c'era risposta. Da nessuna parte, in nessun documento.

Quando un progetto resta aperto per mesi, la diagnosi standard è sempre la stessa: manca la costanza, manca il tempo, manca la motivazione. Ho smesso di crederci.

La maggior parte dei miei progetti eterni non soffriva di poca disciplina. Soffriva di un errore di classificazione: li chiamavo progetti, ma erano un'altra cosa.

Tiago Forte, l'autore del metodo PARA, traccia la riga in modo netto: un progetto è una serie di attività legate a un obiettivo, con una scadenza. Un'area è una sfera di responsabilità con uno standard da mantenere nel tempo. Il progetto finisce. L'area no, per definizione.

Sembra una distinzione da manuale. Non lo è, perché cambia il tipo di attenzione che la cosa ti chiede. Un progetto vuole attenzione da sprint: blocchi di lavoro, prossima azione, avanzamento misurabile. Un'area vuole manutenzione: controlli periodici, uno standard da tenere. Se tratti un'area come un progetto, ti sembrerà sempre in ritardo, perché aspetti una fine che non può arrivare. Se tratti un progetto come un'area, non chiude mai: lo manutieni all'infinito, e intanto consuma attenzione ogni settimana.

L'errore non si vede a occhio nudo. Nella lista, un progetto vero e un'area travestita sono identici: una cartella con un nome e dei file dentro. La differenza emerge solo quando li costringi a rispondere alla domanda sulla data.

A maggio ho scritto che un progetto senza criteri di chiusura scritti resta "quasi pronto" per sempre. La data di fine è il secondo pezzo dello stesso sistema: i criteri dicono cosa significa finito, la data dice quando.

Lunedì ho dato a ogni cartella una riga di stato leggibile anche da uno script, cioè da un piccolo programma: stato, prossima azione, data di fine, ultimo aggiornamento. Una riga, cinque campi. E ho reso la data di fine obbligatoria: nel mio sistema un progetto senza data non può più esistere.

Per 18 progetti la data c'era già, scritta nei documenti: una scadenza vera, o la data di chiusura per quelli finiti. Per gli altri 25 ho messo una data fittizia a sei giorni, fatta apposta per scadere subito: o trovi una data vera entro domenica, o ammetti che la data non c'è.

La revisione ha dato tre esiti.

Primo: la maggior parte ha ricevuto una data reale. Non perfetta, negoziabile, ma scritta. E già questo cambia il comportamento: un progetto con scadenza al 30 giugno lo guardi in modo diverso da uno che galleggia.

Secondo: uno non aveva nessuna data possibile. La revisione mensile del mio sistema operativo personale: gira ogni mese, per sempre, e va benissimo così. Non è un progetto, è un'area. Riclassificata, senza senso di colpa. Adesso non risulta più "in ritardo": risulta ricorrente, che è la verità.

Terzo: qualche voce, messa davanti alla domanda, non meritava né una data né una riclassificazione. Se non riesci a dire quando una cosa finisce e nemmeno a quale responsabilità continua appartiene, hai trovato una zavorra con un nome da progetto. Si chiude, non si manutiene.

Il punto del sistema non è la riga di metadati. È che la domanda "quando finisce?" ammette solo due risposte: una data, o un'ammissione.

Se c'è una data, hai un progetto. Trattalo da progetto: criteri di chiusura, prossima azione, scadenza che si avvicina.

Se la data non c'è e la responsabilità è reale (la contabilità, la manutenzione del salone, la revisione mensile del sistema), hai un'area. Trattala da area: uno standard da mantenere, controlli a ritmo fisso, zero ansia da completamento. Nel mio sistema le aree ora vivono in cartelle separate, con un nome diverso, proprio per non confonderle mai più con i progetti.

Se la data non c'è e la responsabilità non è reale, chiudi oggi.

Il mio errore, prima del censimento, era tenere tutte e tre le categorie nella stessa lista. E poi chiedermi perché la lista non si accorciava mai. Non si accorciava perché un terzo delle voci non poteva accorciarsi: non aveva una fine da raggiungere.

Prendi la tua lista di progetti. Quella vera: cartelle, lavagna, gestionale, dove sta sta. Accanto a ogni voce scrivi la data di fine.

Venti minuti, tre esiti possibili per ogni riga: una data vera (è un progetto, tienilo); nessuna data ma una responsabilità continua (è un'area: spostala in una lista separata e dalle un ritmo di controllo, non una scadenza); nessuna data e nessuna responsabilità (chiudila oggi, senza funerale).

Se su dieci voci ne riclassifichi tre, non hai perso tre progetti. Hai guadagnato una lista che dice la verità. E una lista che dice la verità è l'unico posto da cui si può decidere qualcosa.

Vuoi il prossimo articolo?
Iscriviti alla newsletter — 3 volte a settimana, lun/mer/ven.