Gestione progetti in agenzia: dove si rompe la delivery quando cresci

La delivery non si rompe sui progetti grandi, ma nei passaggi di mano. Dove si perde tempo, come misurare gli sforamenti sui tuoi numeri e un checkpoint in cinque campi da copiare.

La gestione progetti in agenzia non si rompe sui progetti grandi. Si rompe quando ne hai sette aperti insieme e nessuno sa a che punto sono senza chiedere. Il sintomo non è il ritardo. È che il ritardo lo scopri il giorno prima della consegna. Nelle agenzie sotto le venti persone lo stato reale dei progetti vive quasi sempre in tre posti diversi: la chat, la testa del project manager e un file che aggiorna solo lui. Qui trovi dove si rompe la delivery, come misurarlo in una settimana e il modello di checkpoint che usiamo con i clienti.

Lo vediamo in ogni analisi operativa che facciamo. Il problema quasi mai è il tool. È che nessuno ha deciso chi aggiorna cosa, quando, e cosa succede se non lo fa.

Tre cose che puoi fare oggi

I punti chiave

Punto | Dettagli

Il sintomo vero | Non il ritardo, ma il fatto che lo scopri tardi

Dove si rompe | Nei passaggi di mano, non dentro le singole attività

Il numero da guardare | Scarto tra ore preventivate e ore effettive, per progetto

L'errore comune | Cambiare tool prima di aver deciso il processo

Il test | Lo stato progetto si aggiorna in meno di cinque minuti, o è progettato male

Chi lo tiene in piedi | Un owner per progetto, non il founder per tutti

Perché i progetti in agenzia sforano quasi sempre

Il preventivo lo fai su un progetto ideale. Il progetto reale ha il cliente che risponde dopo sei giorni, il feedback che arriva a pezzi, la revisione numero quattro che non era prevista e il collega che nel frattempo è su altri due lavori.

Nessuna di queste cose è un errore di stima. Sono tutte attese. Il punto è che nessuno le conta.

Nelle agenzie che analizziamo lo sforamento nasce quasi sempre in tre punti precisi, e nessuno dei tre sta dentro il lavoro vero.

**Il primo è il passaggio di mano.** Il designer finisce, ma non lo sa nessuno finché non lo dice in chat. Se lo dice a fine giornata, lo sviluppatore parte il giorno dopo. Un passaggio di mano male gestito costa mezza giornata a ogni giro. Su un progetto con sei passaggi sono tre giorni pieni, e non li hai fatturati.

**Il secondo è l'attesa del cliente.** Quasi nessuno traccia quanto tempo un progetto passa fermo in attesa di feedback. Se non lo tracci, quel tempo diventa tuo: il cliente si ricorda solo che avevi promesso il 15.

**Il terzo è il lavoro che non è in nessun piano.** La chiamata di venti minuti, il file da rimandare, la modifica veloce. Ognuna sembra gratis. Sommate a fine mese sono giorni.

Come capisco se il problema è il processo o le persone

Questa è la domanda che i founder fanno più spesso, di solito con una risposta già in testa.

C'è un test che uso, e funziona quasi sempre. Prendi lo stesso tipo di progetto affidato a due persone diverse. Se sfora con entrambe, il problema è il processo. Se sfora con una sola, guarda il carico di quella persona prima di guardare la persona.

L'altro segnale è il numero di eccezioni. Se ogni progetto è diverso "perché quel cliente lì è particolare", non hai un processo. Hai sei processi improvvisati che si somigliano. E un processo che esiste in sei varianti non lo puoi migliorare, perché non sai quale stai migliorando.

Un consiglio: prima di riorganizzare qualunque cosa, prendi il tuo progetto tipo e scrivi solo i passaggi di mano. Chi consegna a chi. Non le attività, i passaggi. Ti bastano dieci minuti e vedrai il collo di bottiglia senza bisogno di un'analisi.

Quanto mi costa uno sforamento

Ti do il metodo, non il mio numero. Il numero che conta è il tuo.

Prendi gli ultimi dieci progetti chiusi. Per ognuno servono due dati: ore preventivate e ore effettive. Se le ore effettive non le hai, prendi i giorni di calendario tra inizio e consegna e usa quelli come proxy, sapendo che è una stima grezza.

Il risultato è quanto ti costa oggi non sapere. Non è una stima nostra e non è un benchmark di settore: sono i tuoi numeri, ed è per questo che regge in una riunione.

Una cosa da sapere prima di farlo: la prima volta il numero sarà brutto. Quasi tutti scoprono di sforare tra il 20 e il 40 per cento e quasi nessuno lo sapeva. Non è una tragedia. È il punto di partenza, e serve solo a decidere dove intervenire per primo.

Cosa deve esserci dentro uno stato progetto

Ho visto sistemi di project management con quaranta campi per progetto. Nessuno li compilava. Ho visto anche fogli con tre colonne che il team aggiornava ogni giorno.

Uno stato progetto serve a rispondere a una domanda sola: posso consegnare quando ho promesso, sì o no. Tutto quello che non serve a rispondere lì è decorazione.

**Il checkpoint settimanale in cinque campi**, da copiare:

Progetto | Fase | Bloccato da | Prossima consegna | Rischio

Sito Rossi | Sviluppo | Feedback cliente su copy | 22/08 | Giallo

Rebrand Bianchi | Design | Niente | 29/08 | Verde

Campagna Verdi | Setup | Accessi ads mancanti | 18/08 | Rosso

Cinque campi. Il rischio è a semaforo, e la regola per assegnarlo è secca: rosso significa che oggi non consegni nella data promessa, giallo che consegni solo se tutto fila, verde che c'è margine. Niente percentuali di avanzamento: sono la cosa più inventata che esista in un'agenzia.

Il campo che fa la differenza è "bloccato da". È l'unico che trasforma la riunione da aggiornamento in decisione. Se in tre progetti su sette c'è scritto "feedback cliente", hai scoperto che il tuo problema non è la produzione: è la gestione delle attese col cliente, e si risolve in modo completamente diverso.

Tool o processo: cosa viene prima

Il processo. Sempre. Ma la risposta onesta è più sfumata di così.

Un tool nuovo non crea un processo che non c'è. Se oggi nessuno aggiorna il file condiviso, domani nessuno aggiornerà il software nuovo, e in più avrai pagato l'abbonamento e speso tre settimane in migrazione. Questo è il motivo per cui la maggior parte delle migrazioni finisce con metà del team che continua a usare la chat.

Detto questo, a volte è vero il contrario, e va detto perché è il caso in cui ci siamo sbagliati anche noi. Se il processo esiste e funziona ma sta in un posto dove il team non lavora, il tool giusto è esattamente quello che serve. Il discriminante è semplice: se il processo lo conoscono tutti e il problema è dove vive, cambia tool. Se il processo non lo sa nessuno, cambiare tool peggiora le cose.

Sull'ordine da seguire, e su cosa va automatizzato per davvero, abbiamo scritto anche [quali processi automatizzare (e in che ordine)](/blog/processi-da-automatizzare-agenzia).

Come si tiene aggiornato senza che diventi un secondo lavoro

Qui casca quasi tutto. Il sistema più bello del mondo muore in tre settimane se aggiornarlo costa più di quanto rende a chi lo aggiorna.

Tre regole che reggono nel tempo.

**Aggiorna chi fa il lavoro, non chi lo coordina.** Se il PM raccoglie gli stati e li ricopia, hai creato un lavoro nuovo e un punto singolo di rottura. Quando il PM è in ferie, il sistema si ferma.

**Un momento fisso, non continuo.** Un aggiornamento settimanale che tutti fanno vale più di un aggiornamento continuo che fa metà del team. Noi lo mettiamo prima della riunione, non dopo: così la riunione parte da dati già scritti e dura la metà.

**Meno campi di quanti ne vorresti.** Ogni campo in più abbassa il tasso di compilazione. Meglio cinque campi veri che dodici vuoti.

Un consiglio: cronometra la compilazione. Prendi una persona, falla aggiornare i suoi progetti e guarda l'orologio. Se ci mette più di cinque minuti a settimana, taglia campi finché non ci sta. Il tasso di adozione dipende quasi solo da questo.

Quello che ho imparato

Due cose, entrambe controintuitive rispetto a quello che pensavo prima di farlo per lavoro.

**La prima: quasi nessuno vuole davvero sapere quanto sfora.** Il calcolo delle ore preventivate contro le effettive lo propongo in ogni analisi. La resistenza non è tecnica, è che il numero fa male e finché non lo guardi puoi raccontarti che il problema è quel cliente lì. Chi lo guarda, però, smette quasi subito di discutere se serve un sistema. Il numero decide la conversazione al posto tuo.

**La seconda: il problema di delivery quasi sempre è un problema di comunicazione col cliente.** Lo pensavo un problema di produzione. Non lo è. Quando conti le ore ferme in attesa di feedback ti accorgi che il tuo team è più veloce di quanto credi, e che stai vendendo tempi che non dipendono da te. La soluzione più efficace che abbiamo messo in campo non è mai stata un tool: è stato scrivere nel preventivo quanto tempo ha il cliente per rispondere, e cosa succede alla data di consegna se sfora.

Da dove partire

Se vuoi capire dove si rompe la tua delivery prima di cambiare qualcosa, il primo passo è il [Process Score](/efficiency). È gratuito, si compila in una decina di minuti e ti restituisce dove stanno le inefficienze e quanto pesano.

Se invece hai già capito il problema e vuoi sapere cosa costa risolverlo, i nostri [prezzi](/prezzi) sono pubblici.

Domande frequenti

Quanti progetti in parallelo può reggere un'agenzia da dieci persone?

Non c'è un numero universale, dipende dalla durata media e dal numero di passaggi di mano. Il segnale di saturazione è pratico: quando le persone lavorano su più di due progetti nella stessa giornata, il tempo perso nei cambi di contesto diventa la voce di costo più grande e invisibile che hai.

Serve un project manager dedicato o basta il processo?

Sotto le dieci persone di solito basta il processo, con un owner per progetto. Il PM dedicato serve quando il coordinamento occupa più di metà giornata di qualcuno che dovrebbe produrre. Prima di assumere, misura quante ore ci vanno davvero.

Notion, Asana o ClickUp: cambia qualcosa?

Sul risultato, poco. Cambiano la curva di apprendimento e quanto è facile piegarli al tuo processo. Scegli quello che il team apre già per altri motivi: l'adozione dipende più dall'abitudine che dalle funzioni.

Come faccio ad aggiornare lo stato se il team non lo aggiorna mai?

Quasi sempre perché aggiornare costa troppo o non serve a chi lo fa. Taglia i campi, sposta l'aggiornamento dentro il momento in cui il lavoro finisce e fai in modo che la riunione usi quei dati. Se la riunione ignora il sistema, il team capisce subito che può ignorarlo anche lui.

Quanto tempo ci vuole a mettere in piedi un sistema del genere?

La versione a cinque campi la costruisci in un pomeriggio. Farla adottare richiede circa un mese, ed è la parte difficile. Chi salta la seconda parte rifà tutto sei mesi dopo.

Ha senso farlo se siamo in cinque?

Sì, ma in versione minima. In cinque il problema non è il coordinamento, è la memoria: cosa succede quando la persona che sa una cosa non c'è. Basta il checkpoint settimanale, niente di più.